Train Processing Overview

After the train reaches the site, the APU-102 train processing operates in the following three cycles:

Acquisition Cycle	Captures all wheel and tag events and saves them to solid state disk.
Post Cycle	Analyzes the data captured by the acquisition cycle and locates where the railcars and locomotives are in the train. Produces a front-to-back listing of all railcars and locomotives in the train. This list is called the “clean consist” of the train.
Reporting Cycle	Delivers the train consist report to the host.

Acquisition Cycle

Acquiring Axles and Tags

The acquisition cycle captures the train information after the train is sensed by the APU-102 and the acquisition software starts acquiring data. The APU-102 constantly watches for the first indication of train movement. The APU-102 recognizes the approach of the train as the first wheel (or axle count) of the train passes over the wheel detector or the presence detector, if used. Either of these signals results in the APU-102 sending a command to activate the Reader Logic Board and the AR2200 RF unit to begin reading tags. The software activates the antennas that read the tags and begins capturing the train data. This cycle continues until the train completely passes the site. If the train stops, the presence detector holds the session open until the train clears the site. Once the train has cleared the site, the captured data is saved to the solid state disk, the antennas are turned off, and the cycle terminates and prepares for the next cycle.

Post Cycle

Processing Axles

The post cycle processes the train’s data into a consist based on the axle and wheel data. Once the acquisition cycle completes, the post cycle handles the captured data. The axle data is processed to determine speed and direction of movement. The axle data is then scanned for wheel patterns that are recognizable as cars and locomotives. (See 2.2.1 Axle Acquisition Subsytem.) This processing results in a preliminary consist based upon axles alone. The APU-102 always has to assume all cars are untagged until proven otherwise.

Processing Tags

The next step in the post cycle applies the tags to the axle consist. Processing is done to ensure that the tags are placed on the right cars. Each tag is analyzed with respect to the axle-based consist, and any discrepancies are noted.

“Fix-up” Processing

“Fix-up” logic is run to further process the consist. It includes multi-track processing to eliminate stray tags, handling known exceptions, specialty cars, and erroneous tag data for inclusion or exclusion in the final consist. Finally, a “clean consist” of the train, with tags included, is produced.

Reporting Cycle

The reporting cycle delivers the train to the host. Once the train has been processed into a clean consist, the train is added to the host reporting process queue. Here, the train remains until the software is able to make contact with the host system. Once connected to the host, the clean consist data is converted into a form that can be understood by the host system. The newly formatted host-specific report is then delivered to the host and removed from the queue.

AEI Subsystems

Axle Acquisition Subsystem

In the axle acquisition subsystem the APU-102 receives inputs from two wheel detector segments that provide signals for identifying cars, locomotives, and determining train direction and speed. The axle acquisition side of the AEI system establishes initial train presence and begins the acquisition cycle.

A wheel detector has two elements, or segments, at a fixed distance, required for calculating axle direction and speed: an “A” side wheel detector segment and a “B” side wheel detector segment.

Refer to the axle acquisition block diagram in 2.10 Train Processing Block Diagrams for a system overview. For detailed information on how the axle acquisition subsystem interfaces with the APU-102 system, refer to 2.7 APU-102 Data Processing.

RFID Subsystem

The RFID subsystem is responsible for getting the information from the electronic tags mounted on the train to the APU-102. It consists of the AI1200 Reader Module, the AR2200 RF Unit and the antennas and tags. The antennas mounted on the sides of the tracks are turned on as each train passes. Each car tag then sends its data to the antenna, and the antenna passes the data to the APU-102.

Refer to the tag acquisition block diagram in 2.10 Train Processing Block Diagrams for an overview of this system. For detailed information on how the RFID subsystem interfaces with the APU-102 system, refer to 2.7 APU-102 Data Processing.

Communications

All data collected by the APU-102 relevant to a consist or movement of a train is sent to the host system. Host communication include direct serial, dial-up modem, wired network, cellular network.

NetModem

NetModem is a feature used by networked APU-102s. It allows up to 10 locally networked APU-102s to share one dial-up modem and phone line for reporting. The APU-102 with the connected modem acts as the NetModem Server. The APU-102s using the server are the NetModem Clients.

Multi-Session Concept

Because more than one customer may want to receive train consists from the same site, (foreign road billing, interchange, industry, etc) multiple APU-102 sessions or “virtual” APU sessions are set up in the software. To install a second virtual APU-102 box (or session) at the site, the software is told to create a second APU. Depending on software version, one APU-102 unit supports from four up to ten virtual APU sessions on one computer. Each virtual session is configured according to the needs of the railroad it supports. Each session on the APU is capable of reporting consist and maintenance reports to the host of your choice. Each session may be configured according to the railroad it supports. Railroads frequently do not use the same conventions. This means railroad A, for example, will call the APU-102 site "Site ABC" running North and South, and railroad B will want to call the site "Site XYZ" running East and West. They usually want their consist reports formatted differently as well. While most use the AAR Standard S-918A (T-94), there are many options within the standard. This is why it is important that each railroad has its own virtual APU session.

When accessing the site, the first question the software asks is which session you want to access. Each session has its own password protection, just like each physical computer would. Once you gain access to your session, you are considered in your own session. This means that any parameters you change affect only the current virtual APU session.

The multi-session concept has many other advantages. Because each session can be configured independently, customers often configure different sessions for different purposes.

Example: A customer sets up session 1 for standard consist and maintenance reporting to its normal host system, then configures session 2 to report different types of information (such as scale reports) to other facilities on their railroad. This works out well, since session 2 is able to deliver the information quickly to the facility that needs it. This happens often when the host system to which the AEI reports are sent cannot handle the type of data the other facility needs.

User Interface with Remote Access Inquiries

The system can accept remote access inquiries at any time. If a train is passing at the time a remote access is being attempted, the system answers the call and alerts the user of a train passage in progress, then continues with the remote request.

The local, remote (modem), and network ports of the APU-102 are always active and waiting to detect a carriage return on any port. The system then requests a session choice and then the session password. After a valid password has been processed, the user is logged on and the system awaits the command to process a routine. The APU-102 starts the requested user function after receiving a valid command.

NetMenu

Using a structure similar to NetModem, NetMenu allows one inbound dial-up modem connection to connect to several devices on the same local network. The APU-102 with the connected modem acts as the NetMenu Server. It is usually the same APU-102 as the NetModem server. A menu is setup in the parameter editor of the NetModem Server with a Name and Path to the individual devices. They can be connected via network or pass through any network connected APU-102 to one of their AUX data ports. (i.e., a HotBox detector interfaced serially to an APU-102). Once connected, select the desired device, and proceed with its normal login.

Power Monitoring

AC Power Monitoring

Most AEI sites are battery powered with the battery level maintained by a battery charger. If the AC power is lost, the site can operate on batteries from a few hours to several days, depending on site configuration, battery capacity, and train traffic. An input to the APU-102 is designed to monitor the status of the AC power at the site. The APU-102 accepts a low voltage AC input that represents the status of the AC power source that is supplied to the APU-102 instrument house or "hut". If the APU-102 detects that the AC power has failed, it is noted in the system log. If maintenance reporting is enabled, the system initiates a report to the maintenance host. A site identification and AC power fail message is then sent. It is on the same circuit breaker as the battery charger so a tripped breaker will also give an AC fail notification. When AC power is restored, the complementary message is logged and sent.

Most AEI sites are battery powered with the battery level maintained by a battery charger. If the AC power is lost, the site can operate on batteries from a few hours to several days, depending on site configuration and train traffic. An input to the APU-102 is designed to receive a “Low Battery Voltage” message from the LVD-2000 when the battery voltage drops to the warning level. If the APU-102 receives this message, the system initiates a call to the maintenance telephone number. A site identification and power-fail message is then sent. When battery voltage is restored to operational levels, the LVD-2000 sends a “Power Restored” message to the APU-102.

DC Power Monitoring

Note: This feature is optional and requires an LVD-2000. Rev. C is switchable for a 24-volt or 12-volt sourced system. Voltage levels are detailed in Appendix F: Specifications.

An input to the APU102 can be configured to receive a “Low Battery Voltage” status indicator from the LVD-2000 when the battery level drops to the warning level. It is noted in the system log. If maintenance reporting is enabled, the APU-102 initiates a report to the maintenance host. A site identification and DC power-fail message is then sent. When the battery voltage is restored to full charge, the LVD-2000 indicates status to the APU-102 and the complementary message is logged and sent.

While in DC power fail condition, the batteries will continue to drain and are continually monitored. Before they reach a level that would make the APU-102 inoperable and possibly cause damage to the batteries, the LVD-2000 disconnects all external loads, the power to all connected APU-102 and all the auxiliary equipment they control. When the battery charger is restored, the level is detected, and power is restored to the APU-102. When the APU-102 boots to the AEI application, it in turn restores power to all its auxiliary equipment.

APU-102 Data Processing

Collecting Data

System Parameters That Affect Data Processing

References to APU application software parameters occur frequently in this chapter. They are listed as “parameters that affect this processing.” For a complete list of APU-102 parameter options and defaults, refer to Appendix A: System Parameters. To view current system parameters from the Display Parameters screen (DP command on either system menu) or edit system parameters from the Edit Parameters screen (EP command on the Supervisory Menu)

Timebase Synchronization and Time Correlation

One of the most important fundamentals of how the APU-102 processes real-time data is the concept of timebase synchronization. All data captured by the APU-102 must be cross referenced to other data on the unit, possibly from other sources. Time is the element that relates all train events to one another regardless of the source. For this process to work, all time references must relate to one event. In the case of the APU-102, the first event seen for each train is the synchronizing event. When the APU-102 sees the first event for each train, typically a wheel transducer signal, it resets a master clock to zero. This event is called the Time-Zero, or T-Zero event, since it represents the event that defines the starting point of the train. Any subsequent data event seen by the APU-102 is timestamped with the current value based on that clock. Everything that the APU-102 captures as the train goes by, such as wheel events, tag events, and scale events, etc, gets stamped with the time from this clock.

Why Does the APU-102 Use Timebase Synchronization?

The APU-102 performs almost all its processing for the train after the train clears the site during the post cycle phase of the record cycle. The APU-102 stores all captured events in separate files called tag files. These tag files contain a pile of events that are each timestamped from the master system clock. Since the data in these tag files is timestamped from the same system clock, the software can analyze any part of the train at any point in time.

When Is Data Considered a Train?

Normal Train Passage

The APU-102 senses a train by either an external presence detector or wheel detector activity. Once either is detected, the APU-102 begins capturing, timestamping, and logging all data it reads. Once it has determined that the train has cleared the site, the APU-102 scans the data for anything that looks like a train. It pulls out the appropriate data, making sure not to fill the disk with non-train activity (See the note below). Fix-up processing is run to refine the consist. The train is assigned a unique sequence number. Sequence numbers on the APU-102 range from 1 to 9999 and are always sequential. Every sequence number that is assigned a train is submitted to the report process for delivery to the host.

NOTE

Electrical noise, lightning, or even a truck on the road sensed by the presence detector can cause false alarms. If less than two valid axles are found or there is contradictory information in the data, the train is not saved. (See Aborting Trains later in this article.)

Trains That Reverse Out of the Site

Normally, the APU-102 only saves trains that pass through the site. If a train pulls in, then backs out of the site, the train is not saved. There is an exception to this rule, however. If the owner session (session 1) has the “ReportReverseExits” parameter enabled, the APU-102 saves and reports trains that reverse out of the system. Once the train is deemed “real” by the APU-102, it is assigned a sequence number. The APU-102 saves the “net forward” result of the train. For example, the train passes 10 cars forward past the AEI site and reverses out, it saves and reports the 10 cars that went forward. The reverse part of the move is not reported.

Parameters that affect this processing include:

Session1.AEIReportOpts.ReportReverseExits

Detecting That the Train Has Gone

The APU-102 has two ways to tell whether the train is at the site or has cleared the site; the wheel detectors and the presence detector. First, if it sees wheel activity via the wheel detectors, it knows a train is still present. If it no longer sees wheel activity, it checks the state of the presence detector. If the presence detector indicates that there is no train, the APU-102 assumes the train is gone.

If the train is traveling fast enough, the software can calculate the amount of time it takes for the largest separation between the wheels of a car it detects to pass the site. After that period of time, if no more axles are seen, the train is determined to have passed the site. If the train is traveling slow enough that it could possibly stop before the next wheel rolls over a wheel detector, the APU-102 relies on presence detectors to maintain the presence.

Example: If a wheel goes by the site at 4 mph, we can assume that we should see another wheel within approximately 150 feet. The APU-102 calculates how much time would elapse for 150 feet at 4 mph and adds a little cushion of time to that value. After that period of time elapses and it sees no more wheels, the APU-102 assumes the train has gone.

In reality, most trains can stop from a speed of 4 mph within 150 feet. If it does, the APU-102 would cut the train in half. To prevent this, specific parameters allow you to set the speed at which the APU-102 is allowed to automatically timeout the train. If the train is traveling slower than this speed, the signal from the presence detector is used.

Parameters that affect this processing include:

SysDiags.PresenceLoop.PresTimeOutAboveSpeed

SysDiags.PresenceLoop.PresenceTimeoutSeconds

Aborting Trains

The APU-102 acquisition cycle is responsible for capturing and saving trains. However, if it encounters data that it cannot resolve into a train, the activity is aborted. This can be caused by acquisition device problems (particularly faulty wheel detectors), false presence, processing failures, or lack of enough data to constitute a train (one axle, for example). There are also non-failure causes for aborted trains. Certain types of train movement, such as reverse exits, hi-rail vehicles, maintenance of way vehicles, or adjacent track activity can generate an aborted train.

When the APU-102 aborts a train, it is preserved on the disk for future reference and can be downloaded for off-line evaluation. Due to limited disk space, 4.x software only saves the last aborted train. 5.0+ saves 100 train files. They can range from 2 files per train to 10 or more depending on where in the post-processing the abort was determined.

Data Storage on the APU-102

File Types

The APU-102 stores all train data on the solid-state disk. Each type of data is stored in its own file. The following two types of data files are stored on the disk for each train:

Raw Data Files

These files are created by the acquisition cycle. They contain exactly what the acquisition devices reported to the APU-102. To maintain purity in the data, no processing is done on these files. Since they are always in their original state, they are very useful for debugging acquisition problems after the train clears. Wheel detector, tag reader, and presence detector problems can be diagnosed by analyzing these files.

Post Processed Files

These files are the result of each step of processing that occurs during post cycle processing. Each step of the processing is stored as another individual file to allow analysis of each stage.

Disk Manager

Because of the storage requirements for the data and limited capacity, the AEI application contains a Disk Manager to maintain free space by removing train data files that are no longer needed. They are removed on a first-in, first out basis. To reduce the amount of disk space used, the disk manager in the AEI application software can be instructed to remove either raw or post processed data files from the disk as well.

Parameters that affect this processing include:

DiskManager.SaveRawData

DiskManager.SaveProcessedData

Hardware Subsystems

Axle Acquisition Subsystem

Detecting Presence, Speed, and Direction

Wheel detectors provide the system with three key pieces of information: presence, direction, and speed. Each wheel detector configuration the APU-102 uses consists of a minimum of two segments. Each segment of the wheel detector produces a signal as the wheel passes. Train presence, or one axle count, is determined when a wheel passes over both segments.

Because there are at least two segments placed a fixed distance apart, the APU-102 is able to determine speed. As previously mentioned, each segment's signal is independently timestamped by the master system clock as it occurs. (See 2.7.1.2 Timebase Synchronization and Time Correlation.) By measuring the time it takes the wheel to travel the fixed distance from one segment to the other, the software is able to calculate speed. Speed detection is paramount to the APU-102. If the speed calculated by the system is incorrect, the cross-checking mechanisms in the software are thrown off. The software processing would also be affected because it locates car and locomotive patterns in the wheel data. The processing would lose the ability to accurately measure dimensions, which would cause the results to falter.

The two-wheel detector segments also determine direction. The left segment is identified as the A segment, and the right segment is identified as the B segment. If the wheel passes from A to B, the wheel detector reports a left to right movement. If the wheel passes from B to A, it must be moving right to left. System parameters for orientation (E/W, W/E, N/S, S/N) and direction (L/R, R/L) may be set to determine the direction of left to right and right to left. See Appendix A: System Parameters for information on setting parameters.

Some wheel detectors have three and four segments (A, B, C and A, B, C, D respectively). This feature contributes to accurate direction detection. (Refer to the sections Types of Wheel Detectors and Slow Speed and the “C” Pulse.)

Parameters that affect this processing include:

Session#.SiteInformation.TrackOrientation

Session#.SiteInformation.TrackDirection (change not recommended)

These parameters need to be setup on all active sessions and could be different. The owner railroad (Session1), may call the site N-S, Session2 may call it E-W.

Types of Wheel Detectors

Wheel detectors, also known as “transducers,” may be one of three types.

Passive magnetic
Active zero speed
Tiefenbach Zero Speed.

Passive Magnetic Transducer

Passive magnetic transducers are essentially a coil of wire wrapped around a magnet and mounted to the rail. As the wheel passes, it causes the “flux” pattern around the coil to change. This change produces a signal that indicates to the APU-102 that a wheel has passed. The passive magnetic transducer uses “A” and “B” pulses to identify train direction. This type of transducer works only with moving trains. As the wheel speed approaches zero, the signal level may not be sufficient for the transducer to sense the change in the flux pattern. Passive magnetic transducers are only recommended for sites where trains keep moving.

Active Zero Speed Transducer

The active zero speed transducer is similar to the passive transducer, except that it contains electronics that allow the APU-102 to track where the wheel is on the transducer. Active zero speed transducers are recommended at sites where slowing and/or stopping occurs because, unlike passive magnetic transducers, they can sense slow and stopping trains. The Servo brand active zero speed configuration used on the APU-102 contains four pulses: the A and C pulse (contained in the WDA segment) and the B and D pulse (contained in the WDB segment). The added pulses in the hardware help identify train direction. (See Slow Speed and the “C” Pulse later in this chapter.) The WDA and WDB segments are housed in two separate units. The C pulse, in conjunction with the A and B pulse, is all that is necessary to determine direction.

Tiefenbach Zero Speed Transducer

The Tiefenbach Zero Speed transducer, like the active zero speed, is a dual segment transducer and senses slow and stopping trains via a C pulse. The segments of the transducer, however, are housed in one unit instead of two and utilize just the A, B, and C pulses. The C pulse is software driven by the overlap of the A and B segment detection. The pulse moves either in the direction A-C-B or B-C-A, which helps determine actual direction and wheel position, regardless of speed or irregular train movement. On the transducer enclosure, “SII” represents the A segment and “SI” represents the B segment. The Tiefenbach transducer is used with the TDA-105 wheel detector signal amplifier for proper operation with the TDA-104 card.

Slow Speed and the “C” Pulse

Slow speed sites pose a particularly tricky problem for wheel transducers. At speeds approaching zero, the wheel can do a surprising amount of quick forward and reverse movements (typically caused by a train’s slack action). To a system that depends on accurate wheel counts and knowing which way a wheel is moving at all times, this could create problems.

Example: A two-wheel truck is located exactly on top of a transducer. One wheel is on the left of the transducer, and the other is on the right. Due to slack action or some other phenomenon, the train jerks forward causing the right-side wheel to cross the B segment of the transducer. Before the right-side wheel crosses the A side segment, the car lurches backward. Now the left side wheel rolls up and stops on top of the A segment. What the software sees is a B to A movement, and it can only assume that right side wheel crossed all the way through the transducer. Oops! We just lost a wheel.

If the site is utilizing an active zero-speed or Tiefenbach transducer, this circumstance would not pose a problem for the APU-102. To prevent this type of movement from affecting data collection, a third “Center” transducer was developed. This “Center” signal is referred to as the “C” pulse. It allows the software to absolutely qualify which direction the wheel is moving. A wheel cannot pass from the A to B segment or from the B to A segment without passing the C segment as well. If the software sees an A and B combination but no C pulse, it knows that there was no actual movement across the transducer since the C pulse never got it. In the above example, if the wheel actually did move through, it would have seen the combination “B” then “C” then “A”.

There are two ways for the hardware to generate the C pulse. In some cases, the C pulse is an actual transducer segment that produces an independent signal. In other cases, it is a “virtual” C pulse. The virtual C pulse is derived by the acquisition software sensing that the A and B transducer signals are overlapping. This is only possible on transducers with a very short segment separation.

Parameters that affect this processing include:

Acquisition.Operating.WheelDetectorSeparation

Acquisition.Operating.WheelDetectorGain

Acquisition.Operating.WheelDetectorThreshold

Acquisition.Operating.WheelSensorOrientation

Acquisition.Operating.WheelDetCsegMode

Acquisition.Operating.WheelDetCsegDebounce

Other related information includes:

DDF Report Discussion
DDW Report Discussion
WDA/WDB/WDAB/WDBA counts

RFID Subsystem

The RFID subsystem operates on a principle called “modulated backscatter.” Upon a train’s approach, the APU-102 application software instructs the AI1200 reader module to activate the RFID subsystem. The AI1200 reader module turns on the RF unit, which drives the antennas with a continuous wave RF signal (in the 900MHz range). As a tag passes through the RF field, it reflects its programmed information back to the antennas.

AI1200 Reader Module

The AI1200 reader module is a self-contained computer module that communicates with the APU-102 via an RS232 connection. It is responsible for:

Activating the RF power to the antennas
Interpreting and validating tag information read by the RF units
To read the tags mounted on the railcars, the APU-102 supports up to three AI1200 readers. The reader is designed to provide an error free method of gathering the data encoded on the train’s tags and passing it upon request to the main APU-102 application software.
On-board buffers allow each AI1200 reader to store up to 1000 tags before the APU-102 software must read them out. In the event that tags begin to back up, which may occur at busy sites, buffering provides the APU-102 additional time to process tag data. The APU-102 reads the tags from the AI1200 as the train is passing. Due to the AI1200’s buffering ability, the APU-102 must log the timestamps for the tags before the tag data is actually delivered from the AI1200. This means that the timestamp must be logged at the time that the tag is first seen by the reader. The AI1200 allows this by providing “valid tag” pulse signals for each antenna. These pulses are triggered by the AI1200 when it first encounters a unique tag. The APU-102 monitors these pulses and inserts a timestamp into a first-in, first-out (FIFO) queue for each antenna. As a tag is read from the reader, the timestamp is retrieved from the appropriate queue entry and stored with the tag.
Tags that are reported with a minus (-)1 or 99999999 for a tag timestamp (depending on the utility used) indicate a failure by the system to associate a timestamp for a tag. The software may read a tag from the AI1200, but the corresponding timestamp queue may be empty. This could be caused by equipment or cabling failures, AI1200 programming errors, or site setup problems.
Another important function of the AI1200 reader module is to facilitate what is called uniqueness logic. This logic prevents the AI1200 from storing the same tag more than once per read cycle. If uniqueness logic is overridden, each handshake accumulated for a tag would result in the tag being buffered by the AI1200. This would cause the AI1200 buffers to overflow and tags would be lost.

AR2200 RF Unit

The AR2200 RF unit is a dual-output radio transmitter/receiver which, on command from a Transcore (formerly Amtech) reader, generates an RF signal in the 915 MHz radio frequency band (902-928 MHz) and delivers the signal to the antenna for broadcast. The RF unit generates the RF power necessary to read a tag. It also contains receiver and preamplifier circuitry to preprocess the tag signal returned through the antenna. The RF unit also receives and demodulates the reflected tag signal returned through the antenna, then preamplifies and conditions the demodulated signal before sending it to the reader. RF output power is on whenever the Reader is on.

The RF unit has dual-antenna output and may be configured in one of two modes: normal mode or compatibility mode. In Normal Mode (Multiplexed), a single AI1200 Reader card and AR2200 RF module is connected to two antennas through terminals identified as “0” and “1” on the RF module. In Compatibility Mode (Dedicated), two AI1200 Reader cards and two AR2200 RF modules, each operate one antenna full-time. One antenna is connected to the first RF module, through the terminal identified as “0” and the second antenna is connected to the second RF through the terminal identified as “1.” The unused antenna port must have a terminator installed.

Antennas

The type, quantity, and location of antennas installed vary depending upon site requirements. Antennas may be mounted low or high on the side of the track or on the ground between the tracks. When the RF unit is transmitting, the RF energy radiates outward from the antenna in an egg-shaped pattern. The width of that pattern at the target is called the read lobe or read window.

There are two types of antennas: Parapanel and Log Periodic. A site may use one pair of Parapanel antennas or a combination of Parapanel and Log Periodic.

Parapanel antennas have an average lobe width of 16 feet. These antennas, mounted at the side of the track, are the standard configuration for single-track AEI sites.

Log Periodic (or Low Profile) antennas are typically used at double-track sites where there is a height restriction between the tracks, or intermodal sites high above the side of the tracks to read cargo tags. They have an average lobe width of 6-10 feet. The APU-102 needs to know what the actual read lobe is to properly place tags on the cars. Parameters that affect this processing include:

Acquisition.Reader1.Ant0PassiveLobe

Acquisition.Reader1.Ant1PassiveLobe

Acquisition.Reader2.Ant0PassiveLobe

Acquisition.Reader2.Ant1PassiveLobe

Acquisition.Reader3.Ant0PassiveLobe

Acquisition.Reader3.Ant1PassiveLobe

RFID Tags

Tag Handshakes

Tag handshakes are an important piece of data that is carried along with each tag. As a tag moves through the RF field (lobe), the tag sends its data (is read) to the AI1200 as many times as it can before leaving the lobe. This count is referred to as the tag “handshake” count. Reader subsystem performance is gauged in large part by the number of handshakes that are counted for each tag.

Handshakes are reported in the raw data stream from the AI1200 equipment appended to each tag’s data. Because the reader must deliver the tag to the software application before all of its handshakes have been accumulated, there is a one tag per antenna delay. This means that the handshake count for a tag is appended to the data of the next tag read on the corresponding antenna. In all reports generated by the APU-102 (except for the raw tag data dump “DDT”), this lag has been compensated for.

Handshakes and RFID Subsystem Performance

Handshakes are a key tool in analyzing the performance of the RFID subsystem. If the subsystem is in trouble, the average handshake counts for a train begins to drop. Obviously, if the handshake count drops to zero, the reader did not see the tag. Handshake counts of one (1) indicate a very real possibility that the system has missed tags.

Many factors can contribute to declining or poor handshake counts. Possibilities include damaged or misaligned antennas, RF units, cable losses due to cable damage or excess cable length, or even train speeds that are faster than the configuration was meant to support. Tag density is also an issue.

Tag Density

The reader subsystem operates on the principal that the strongest tag in the field gets read. For example, if one tag in the RF field is competing against another tag, only one tag wins. At the very least, both tags will probably get read, but typically they will have lower handshakes than normal. It is similar to trying to listen to two radio stations at the same time.

Handshake counts can also vary based upon the RFID subsystem configuration. At sites where restricted clearance is an issue, the low-profile antennas must be used to meet clearance guidelines. This type of antenna does not perform at the same level as the typical parapanel antenna. It is closer to the rail, angled to the optimum tag height and usually doesn’t have as much gain as a parapanel. Also, some configurations use “dedicated RF units” to provide a full time RF field. This configuration normally has higher handshake counts due to the absence of the “multiplexing” algorithms used by the reader. The multiplexing function allows one RF unit to support two antennas. In doing this, the reader constantly switches back and forth between the two antennas. This reduces the amount of RF airtime to approximately 40% on each antenna. Slower sites generally use multiplexing, while high speed sites (especially those that are also a restricted clearance site) use dedicated RF units.

Other related information includes:

R Command
RFON Command
RST Command
DDT Command
“Tag Synch Error” maintenance message
AI1200.INI file

Presence Detector Subsystem

The external presence, provided by the presence detector, holds a current APU-102 acquisition session open if a train has stopped. This signal keeps the system from timing out and resetting to receive a new train when one is stopped at the site.

Presence Override

You may deactivate the presence detector via the Acquisition.ExtPresOverride function on the Edit Parameters menu. The default is zero (0) to use the external presence. Changing the value to one (1) directs the APU-102 to ignore the presence detector. When the override function is activated, presence detectors will not initiate train presence and will not keep the acquisition cycle active, as if there was no presence detector at all. The wheel detectors would be the only method for detecting presence and would rely on time outs. This function is used in two circumstances: when no external presence equipment exists at the site or to disregard presence reporting temporarily for diagnostic or troubleshooting purposes. A value of two (2) indicates the APU’s software has determined the presence detector is stuck on and will ignore the presence signal for acquisition. The AEI application constantly monitors the presence input and the presence is cleared, the software will clear the override and go back to using presence in its acquisition processing.

Parameters that affect this processing include:

Acquisition.Operating.ExtPresOverride

Acquisition.Operating.Aux1Pin3Mode

Acquisition.Operating.Aux1Pin3ModeTimeout

Presence Detector Timeouts

Site-specific presence detector timeouts may be set in the APU-102 application software.

Parameters that affect this processing include:

SysDiags.PresenceLoop.MinAxles

SysDiags.PresenceLoop.LowSpeedThresh

SysDiags.PresenceLoop.HighSpeedThresh

SysDiags.PresenceLoop.PresTimeOutAboveSpeed

SysDiags.PresenceLoop.PresenceTimeoutSeconds

SysDiags.PresenceLoop.SecondsBetweenTrains

SysDiags.PresenceLoop.ExcessPresencePeriodWarningTimeout

For instructions on using the override and timeout functions, refer to the Edit Parameters (EP) function in 4.0 APU-102 User Interface and Acquisition Parameters in Appendix A: System Parameters.

Multi-Track Processing

When an AEI site is installed in close proximity to another track, tags WILL get read from adjacent tracks. We do not want to report a tag on our consist unless we are absolutely sure it belongs on our train.

Confidence Logic

One way to weed out the stray tags is to use “Confidence Logic”; to only report a tag with a high level of confidence. The lowest confidence level (Level 3) is to report all tags. Level 3 is fine for a track with no possibility of picking up stray tags. With an unprotected adjacent track, level 3 could report a car that is not on our train (a BAD thing). The second level of confidence (Level 2) will apply a single tag, but only if it fits the car (length, axle count, read in appropriate location, etc). The highest (Level 1) being both tags were read for any given car. The downside to level 1 and 2 is many singly tagged cars will go unreported. We still report the car based on axle pattern but report it as an untagged car.

Parameters that affect this processing include:

Session#.AEIReportOpts.ConfLevel

Multi-track processing is a dynamic way to deal with the stray tags. Where there are adjacent tracks, a complete AEI system is installed on all tracks. They operate independently but share acquisition data and knowledge of activity on their own track with the adjacent APU-102s. The communication channel also provides a “heartbeat” to adjacent APU-102s to indicate the communications channel is operational even if there is no data to exchange. The acquisition start cycle on one APU-102, starts the acquisition clock on the other interconnected APU-102s so “everybody is on the same page” for post-processing.

Inter-Track Communication (ITC)

ITC was designed for double-track installations. 2 APU-102s share acquisition data via a serial connection. They also provide presence awareness to the adjacent APU-102 when their own track is occupied via hard-wired control signals between the APU-102s. Activity on any connected APU-102 starts the acquisition clock on all. ITC logic determines which tags belong to our train (and which ones don’t). If the APU-102 can’t determine if the tag belongs its train, it does not use it in makeup of the consist. (If in doubt, throw it out). Refer to the AEI System Site Installation Guide for additional information on equipment installation.

Parameters that affect this processing include:

Acquisition.ITC1.ChannelFileName

Acquisition.ITC1.InterferenceUnitLocation

Acquisition.ITC1.ITCSpeedThresh

Dynamic Adjustment of Confidence Logic

The confidence level can dynamically adjust down depending on presence indication or loss of communications with the adjacent APU-102(s). If the adjacent track has a train, the confidence logic drops to the DTA confidence level (Double Track Active). If communication from the adjacent track’s APU-102 is lost, we have to assume worst case and the confidence logic drops to the ITCF confidence level (InterTrack Communication Fail).

Parameters that affect this processing include:

Session#.AEIReportOpts.ConfLevel

Session#.AEIReportOpts.DTAConfLevel

Session#.AEIReportOpts.ITCFConfLevel

XTrack Version 5.2+ (Experimental) –

XTrack is currently used only[PEM1] by Comet Engineering and should not be used unless directed by Comet. It provides data collection capabilities for up to 10 tracks in a high-density yard environment. The data collected is used for development of future multi-track algorithms that will be available in later releases.

Parameters used by the XTrack Data collection are:

Acquisition.XTrack.Track#.Enabled

Acquisition.XTrack.Track#.Mode

Acquisition.XTrack.Track#.IPAddress

Acquisition.XTrack.Track#.LocationXOffset

Acquisition.XTrack.Track#.LocationYOffset

Acquisition.XTrack.General.Enabled

Acquisition.XTrack.General.ThisTrackNumber

Acquisition.XTrack.General.DebugFlag

ALL interconnected tracks are identified on all APU-102s and are setup identically except for “ThisTrackNumber”. The X-Y offsets reference the leftmost antenna as X=0 and Track 1 as Y=0. Offsets are in feet.

== 2.7.3 Host Reporting ==

Host reporting may be activated and deactivated through the Edit Parameters command in the APU-102 application software. The table below displays the commands used to modify Host Reporting with the “HR” command:

Command	Result
HR	Display current Host Reporting option.
HR,OFF	Deactivate Host Reporting.
HR,INI	Initialize Host Password to default. (Compass Host)
HR,ON,N	Activate; report only new trains.
HR,ON,A	Activate; report all trains.
HR,ON,#	Activate with Age Threshold. # = Age Threshold in hours (0-9)
HR,ON,####	Retransmission request. (#### = Sequence number of requested train.)
HR,NOW	Resets reporting timeouts to 0 to allow immediate reporting. 5.10B2+

For more information, see 4.0 APU-102 User Interface and the HostReportingOption parameter in the Session1.AEIReportOpts section of Appendix A: System Parameters.

Parameters that affect this processing include:

Session1.AEIReportOpts.HostReportingOption

Session1.AEIReportOpts.TrainAgeThreshold

Header and Tag Formats

The List Clean Consist (L) function in the APU-102 application software allows you to display tag information in various formats. Entering the L command with an optional extension determines the format that displays. The optional List Clean Consist extensions are the Compass Format (LC), TCS Format (TL), T94 Format (LT94), and Full Consist Format (LF).

Refer to 4.0 APU-102 User Interface for command operating instructions and Appendix B: Host Reporting Formats.

Connecting to Other Wayside Equipment

At the wayside sites where the APU-102 resides, there is often more than one type of system within close proximity to another (often in the same bungalow). Most are designed to provide information about train movement, just as the APU-102 does. There are many types of systems that may be found at or near AEI sites. The table below lists a few of them:

System Type	Description
APU-102	Adjacent or multi-track data sharing to handle stray tag reads.
Video	Captures a visual record of the train movements.
Scale	Weighs railcars as they pass.
Hotbox Detector	Detects hot bearing and journals on railcar axles as they pass.
Wheel Impact Load Detector (WILD) System	Detects wheels that contain defects, such as flat wheels.
Acoustic Bearing Detector	Detects bearing and journal failures based upon the sound emitted.
High/Wide Detector	Detects cars and/or cargo that exceed the dimensional tolerances for the location.
Dragging Equipment Detector	Detects objects that are being dragged by the train.

Connecting to additional equipment allows information from each unit to add value to the information contained on other units at the site. Wayside equipment typically connects to the APU-102 via an RS-232 port. Verify the communications protocol (baud rate, data bits, stop bits, parity, flow control, etc.) for the wayside equipment and set the port to match in the APU-102 application software. Newer defect detectors connect via a LAN (Local Area Network) Refer to the AEI System Site Installation Guide for additional information on equipment installation.

Parameters that may affect this processing include:

Ports.AUX#PORT.Name

Ports.AUX#PORT.Driver

Ports.AUX#PORT.Port

Ports.AUX#PORT.BaudRate

Ports.AUX#PORT.WordLen

Ports.AUX#PORT.StopBits

Ports.AUX#PORT.Parity

Ports.AUX#PORT.FlowControl

Ports.ETHERNET.IPAddress

Ports.ETHERNET.SubnetMask

Ports.ETHERNET.Gateway

System Checks

Self Test

On initial boot-up of the APU-102, the solid-state disk integrity is checked, key system files are checked, hardware is initialized, and open files are saved for evaluation or recovery. Depending on the results of these tests, the APU-102 may boot to ROMSHELL/NetMRS for manual diagnostics and recovery. More advanced software versions can initiate automatic recovery if necessary.

During the idle time between train passages, the system performs a self-test, a series of self diagnostics. These diagnostics include a check on the APU RAM, a communication check with the reader logic board, a communication test with the modem, a communication test with the Ethernet port, and other functions to ensure the reliability of the system before the next train approaches. During the record process and immediately after a train has cleared, the system analyses the collected data to determine the health of the acquisition hardware, including presence circuit, axle acquisition subsystem and RFID subsystem. Automatic maintenance reports can be generated depending on parameters set according to the customer’s preference.

For more information, see the SysDiags section of Appendix A: System Parameters.

Check Tag Sequence

An optional check tag can be mounted in selected antennas. The check tag sequence can be executed through the local communications port, remote access port, or telnet session from either system menu. It verifies that the system can control the RFID system, read and process a tag without being on-site. The CT (Check Tag command), explained further in 4.0 APU-102 User Interface, provides a menu item to control this function. The response to the check tag sequence is displayed on the terminal device used to activate the sequence.

The system design includes a tag checking feature of the reader logic board. The check tag sequence verifies that the system can read and process a tag. If activated in the Supervisory Menu, the APU-102 periodically runs this tag check. The failure of the system to properly respond to a check tag operation results in a call to the maintenance phone number. When activated, the system stores the last ten check tags from each antenna.

It is also possible to manually initiate a check tag sequence through either the local communications port or remote access port. The Supervisory Menu, explained further in 4.0 APU-102 User Interface, provides a menu item to control this function. The response to the check tag sequence is displayed on the terminal device used to activate the sequence.

2.9 Operation Example

As the system is started, the APU-102 software initializes the hardware and begins monitoring for a new train arrival. When a train enters into the presence detector field or the first axle event of the first piece of equipment passes the site, the APU-102 begins a record session. As the train passes, each axle event and tag are logged along with a timestamp for each. After the train has left the site, the APU-102 ends the record session. The closing of the record session begins a tag time-out period to allow the system to receive any tags from the reader that have not yet been transferred. An axle identification routine is activated to process (correlate) the raw axle event information (As and Bs) into axles. A car identification routine is activated to process (correlate) the raw axle information into cars. This output is saved as part of the basic raw data necessary to provide the processing functions for the host system information and the user interface. The correlated car information will be matched with the tag data by comparing the timestamps between the axle information and the tag information. “Fix-up” processing is run to refine the accuracy of the consist. The consist is now ready to be transmitted to the host system by the APU.

The APU-102 connects to the host system. After connection, the APU-102 and host negotiate the logon/password sequence if necessary. After a valid logon is processed, the APU-102 transfers the consist to the host. The APU-102 marks as sent, sends additional unsent consists or logs off and disconnects.

For detailed information on APU-102 system software menus, refer to 4.0 APU-102 User Interface.

Train Processing Block Diagrams

The axle acquisition, tag acquisition (RFID subsystem), and host reporting processes are illustrated in the following pages:

Axle Acquisition – Standard Consist AEI System
Tag Acquisition – Standard RF AEI System
Consist Report Process

Axle Acquisition

The layout below demonstrates axle acquisition operation at an AEI site. When a train approaches the site, the APU-102 senses initial train presence via either the wheel detectors or the presence detector (if used). This starts the wheel detector operation – the axle (or wheel) acquisition side of the acquisition cycle. The APU-102 continues to acquire and record train data as long as axles are detected.

Figure 2.1: Axle Acquisition

Tag Acquisition

Standard RF AEI System

When a train approaches the site, the APU-102 senses initial train presence via either the wheel detectors or the presence detector (if used). This starts the RFID subsystem operation – the tag acquisition side of the acquisition cycle. As the tag passes through the RF field, it continues to transmit programmed tag data back to the reader logic board in the APU-102.

Standard RF AEI Site

Figure 2.2: Tag acquisition process

2.10.3 Consist Report Process

Figure 2.3: Report Process Flow