System test procedure

Verify Train Recording Operation

1)  Log onto the APU-102, System Menu. Start a file capture on your portable computer. This logs all the data you are displaying to a file on the portable. It is recommended to create a file referencing the site name so you can look at it later and compare results.

2)  Run the Dump Data Summary Report (DDS,*) and Dump Data Full Report (DDF,*) for all trains stored on the APU-102. These reports display all the trains recorded on the APU-102 in summary and full composite formats. Press <ESC> to stop the report at any time.

3)  Close the capture file, browse to it if necessary and open the capture file you just created to check the following information in the train files:

Axle Summary

In the DDS portion of the report, make sure that the WDA counts match the WDB counts and the WDAB/WDBA counts match the total number of axles listed in the Axle Summary column. If there are missing axles or the WDA and WDB counts are not the same and the train did not stop, check the wheel detector operation and parameters again. You can tell if the train did not stop by checking the value in the Minimum field in the Speed Summary column.

Reader Summary for AVG

In the DDS portion of the report, make sure the average handshakes on both antennas for the highest speed train is still 3-4 handshakes at the minimum. Check the Tags Read field for each tier to make sure they are approximately the same. If your average handshakes are high (above 4) on both channels and there are a few missing tags on a channel, it is safe to say that those tags are really missing or damaged.

Wheel Detector Alignment Check

The DDF portion of the report is 142 columns wide and you may need to adjust your display to make it easier to read. (remove word wrap, etc.) Compare the measured length of the cars to the tagged length of the cars. A well adjusted wheel detector should have less than 10% variance. Check the report for trains in both directions. It is common to have long measurements in one direction and short in the other. If necessary, redo the wheel detector alignment, especially the “rock the plate" step.

Verify Remote Communications

Modem

1)  Verify remote communications to the APU-102 by dialing the APU-102 phone number using a modem and communications package that supports ANSI Terminal.

2)  Once the modem is connected, press <Enter> once. This should prompt you just as you connected locally to the APU-102 with the Session login menu.

3)  Login and perform the operations in the 5.1 Verify Train Recording Operation section above while connected remotely.

Network

1)  Ping the site by using its IP or hostname.

2)  Verify network communications to the APU-102 by connecting to the APU-102 via Telnet with a communications package that supports ANSI Terminal.

3)  Once connected, press <Enter> once. This should prompt you just as you connected locally to the APU-102 with the Session login menu.

4)  If at the site, connect to the local port. Display the APU-102’s IP settings with the IPCONFIG command. Verify parameter settings for Ethernet. 

5)  Ping an upstream host from the APU-102.

6)  Login and perform the operations in the 5.1 Verify Train Recording Operation section above while connected remotely.

Simulate a Train for Testing Purposes

There are many reasons one may want to simulate a train at a site. Simulated trains allow testing of newly installed hardware or software, communications lines, or parameter settings. There are three different ways to simulate trains: from the trackside, using the switches on the front of the APU-102, or via a software command.

The type of simulation to use depends largely on what type of events are to be tested. If you are testing a newly installed transducer on the rail, the trackside simulations method is best because it tests the system from the wheel sensors forward. To test a newly installed wheel sensor interface card, the switch method could be used, though the trackside method would also be appropriate. To simply test new parameters or host reporting communications, the software command method works well.

From the Track

Simulating a train from the trackside requires a piece of iron or steel and your ability to pretend to be a train. To do this, you must simulate a wheel crossing the sensor.

1)  Pass a piece of metal (such as a hammer or something of equivalent size) over the top of the transducer so that both the “A” and “B” segments are crossed in succession. In cases where a zero speed transducer is used, the “C” transducer must also be crossed. If the APU-102 sees that all segments are crossed, it considers the activity a wheel. Because steady speeds are important, it is best to use a steady pendulum motion when “swiping” over the wheel transducer. Do not, however, allow the metal to sweep back over the transducer, as this will cause the APU-102 to think that the wheel is backing up. Allow the metal to contact the wheel sensor. You are not going to hurt it and will usually give better results.

Now we’re ready to work on a simulated car. When looking for cars, the APU-102 uses two important pieces of information from the wheel transducers: speed and separation. As discussed previously in this manual, the APU-102 calculates the speed by determining the amount of time it takes a wheel to move from one segment to the other. The derived speed is then used to determine the car’s dimensions by calculating the separation between the wheels. The APU-102 knows that a car (or engine) has symmetric dimensions. Short separations between wheels are usually wheel trucks; long separations between wheels are typically the body sections of the car.

2)  Using the steady sweeping motion described above, perform the following for each simulated railcar:

1. a) Sweep (delay 1 second)
2. b) Sweep (delay 4 seconds)
3. c) Sweep (delay 1 second)
4. d) Sweep (delay 2 seconds)
5. e) Repeat

The first two sweeps (separated by 1 second) simulates a two axle truck. The 4 second delay in the middle represents the body of the railcar. The next two sweeps represent the next two axle truck, and the last 2 second delay simulates the coupler section of the car. Omit the last two second delay for the last car of your train!

Create several cars (four simulated cars would be a good start) as it is difficult to create a valid axle/car pattern manually. One of the APU-102's jobs is to identify axles and correctly correlate them into cars. Post processing will remove axles it determines to be invalid.  At least 4 good axles in the appropriate pattern are required to create a valid train. The more cars you simulate, the better the chances of simulating a complete, valid train.

Using the APU-102 Switches

The switch approach is identical to the trackside approach, except that the APU-102’s front panel switches are used instead of a hammer and the transducers. No external acquisition hardware is tested. Each switch represents one segment of the transducer. The WDA switch is the “A” segment and the WDB switch is the “B” segment. Lay your finger on the lid next to the WDA button. Now “swipe” from left to right across all 3 buttons to create an axle (the SYS button will have no effect). Use the same sweep/delay pattern described above to simulate a train.

Via Software Command

This type of simulation differs from the previous two types in that it can be executed remotely. The software simulates a train by adding a sample train to the train list as if it just went by the site. Use the ST command from either the Main or the Supervisory Menu. While this form of simulation does not exercise any of the acquisition processes, it can perform post-processing functions and consist reporting (if Session#.AEIReportOpt.ReportSimulations is enabled). It is assigned a sequence number and will appear in the train directory. The acquisition files for the sample train are stored on the disk as “TRAIN.*”

Audible Status Messages

From time to time, you may hear a single beep or a series of beeps coming from the APU-102 processor card (not the Sonalert). The number of beeps you hear indicates the current status of the APU-102 unit.

Number of beeps	Indicates
1	APU-102 is booting. (486 and LX-800 processors)
long-short-short-short	APU-102 is booting. (LPMTX processor)
1-3-1 pattern	Modem failed to initialize. (AT command error or no response)
11	APU-102 has determined a wheel sensor is stuck active.