APU102 Presence Circuit Failure Detection

This document covers the presence circuit failure logic employed by all versions of the APU102 mainline AEI software. It also covers methods that can be used to help identify optimal settings to improve failure detection logic on a site specific basis.

WARNING!

The default settings were set by to provide maximum prevention from accidental false presence circuit failure detection. Changing these settings will increase the risk of any of the following: Train consists being split up. Multiple trains being combined. Loss of data.

Changes in 5.10, Build 1

In 5.10, Build 1, the logic was not modified, however the allowable range of values has been increased to allow tighter tuning of the presence Stuck ON detection parameters. A new parameter has been added for additional alarming capability.

The following table details those changes.

Parameter	Original		Build 10
SysDiags.PresenceLoop Sub-Parameter	Min	Max	Min	Max
MinAxles (Sensitivity of detection evaluation)	2	7	1	7
SecondsBetweenTrains	1	7200	1	7200
LowSpeedThresh	4	100	1	100
HighSpeedThresh	15	100	1	100
PresTimeOutAboveSpeed	10	100	1	100
PresenceTimeoutSeconds	15	3600	1	3600
ExcessPresencePeriodWarningTimeout (minutes)	N/A	N/A	0	1440

=

New for v5.10B1

Objectives of Failed Presence Circuit Detection

The presence circuit failure detection logic built into the APU102 mainline software is designed to detect and minimize the effect of two types of presence circuit failures, Stuck OFF and Stuck ON. When the presence circuit is Stuck OFF, consists of trains that stop on site will be split into one or more pieces. When Stuck ON, a single train consist may contain one or more trains or the train may be prevented from being reported entirely.

Presence Stuck OFF Detection

The objective of this type of detection is to identify cases where the presence circuit does not detect the presence of a train and there is clearly a train on site. If wheels are detected, a train is clearly on site. If the presence circuit does not report “active”, the software knows the presence circuit is not functioning properly.

Presence Stuck ON Detection

The objective of this type of detection is to identify cases where the presence circuit is reporting that a train is on site, but in reality is not.

Two methods exist.

• Impossible Deceleration
• Impossible Acceleration

“Impossible Deceleration” Method

This method works very well at high speeds. If a train is moving fast enough that the software knows it is not possible to stop between wheels, it can detect a stuck circuit by knowing it should see another axle within a short time after an axle has passed.

The two parameters that are used in this detection are.

• PresTimeOutAboveSpeed
• PresenceTimeoutSeconds.

The logic implemented is this:

If a wheel is seen traveling at a speed higher than “PresTimeOutAboveSpeed (15mph)” and another wheel is not seen within “PresenceTimeoutSeconds (30 seconds)”, the presence circuit is declared “Stuck ON”.

“Impossible Acceleration” Method

This method is used at low speeds. It takes advantage of the fact that a train cannot accelerate quickly at slow speeds. By watching the speed changes from axle to axle, the software looks for cases where the speed from axle to axle changed too much to be possible in reality. To help prevent false detections, a parameter is included that prevents the software from executing the logic unless a certain amount of time has elapsed (which would be the minimum time between trains that is possible at the site).

The parameters used in this process are.

• SecondsBetweenTrains
• LowSpeedThresh
• HighSpeedThresh

The logic implemented is this:

Given the last two wheels acquired at the site, if the elapsed time between them exceeds “SecondsBetweenTrains (typically 60 seconds)”, and the 1st axle is below “LowSpeedThresh (typically 4mph)”, and the 2nd axle is above “HighSpeedThresh (typically 15mph)”, declare the presence circuit “Stuck ON”.

Maximum Wheel Events Limiter Setting

“MaxWheelEvents” is the maximum “A” and/or “B” events the APU will acquire as a single train.  History: this parameter was not created for presence diagnostics but because of resource limitations on the 486 class APU and were defaulted to 2048 events. A 486 class APU would run out of memory to process anything greater. Early versions would stay in an active record mode, continue to acquire tags and eventually run out of memory. Rather than hang there, the APU code was updated to use the presence override logic to end recording of the train and begin post-processing. If additional axles are detected, it will begin the record process for a new train. It was increased to 4096 with the increased memory and processing power of the Pentium. To use for presence diagnostics, we recommend lowering to a more appropriate value based on site traffic. 2048 is the minimum value and would record approximately 250 cars in through moves. If a lot of stopping and backing occurs on a site, a higher value may be more appropriate.

Presence Override Condition

When in presence override, the APU will ignore the state of the presence circuit and process the train as though there was no presence circuit. It continually monitors the circuit but will not use the presence circuit for train processing until it returns to an idle state. When the APU is in a software determined presence override, it will be indicated in the parameter, “Acquisition.Operating.ExtPresOverride=2.” Normal state is “0”. BTW, The I/O screen for version 5+ will display the raw state of the Presence input, regardless of this setting.

Speed Calculations

The only parameter not discussed at this point is the “MinAxle” parameter. “MinAxles” specifies the number of axles used in the calculation to determine the speed used for presence circuit fail detection processing. The lower the number, the more sensitive the software is to speed change. For maximum sensitivity, specify one axle. The purpose of this parameter is to allow the software to minimize the effect of inaccurate speeds caused by noise or other reasons. Lowering this value is now possible due to the better quality wheel sensor signals produced by newer transducers models.

Because speed calculations are important in all logic employed, lowering the value to 1 will possibly have the greatest impact on the site's presence circuit failure detection performance.

Limits

While the software does well detecting presence circuit failures under many circumstances, there will always be “holes” where detection cannot take place. The software is designed to help identify hardware failures, but under some conditions the software is completely dependent on the presence hardware for proper site operation.

Optimizing Presence Diagnostics Site Parameters

Introduction

This section describes some methods that can be used to tune the site parameters to allow improved detection of presence issues. However, these are in no way absolute and are simply guidelines to help in the process. It will be impossible to achieve 100% loop fail detection at all speed ranges.

Background

The default values used in the APU102 were derived by evaluating some worst case sites. Those sites were composed of mainly locomotive traffic, where speeds could change radically. These values were selected because most customers will use the default settings and we feel it is better to trust the hardware than to split a train in two. However, at sites where typical train traffic patterns occur, there will be opportunities to “tune” the software for better hardware failure detection. We have included parameters to allow customers to adjust these settings to best fit their sites.

Determining Appropriate Values

The key factors in determining the best possible settings from site to site include:

• Train speeds
• Types of movements
• Makeup of trains

Because these factors are not always constant at any site, determining the best possible settings can be difficult. Setting the values too low can cause trains to be inadvertently cut in two during a stop. Setting the values too high can cause stuck presence circuits to combine trains. The best method to help determine the appropriate values involves evaluation of the actual traffic at the site. For best results, the site should be allowed to operate with the default settings until the unit is full of trains (100). To evaluate the data, the tool “readtag.exe” will be required.

Procedures

This section describes two methods for selecting the value for each parameter involved in the presence circuit failure logic: Selection by Theory and Selection by Data Evaluation.

Presence Stuck OFF Detection

No parameters to adjust.

Presence Stuck ON Detection, “Impossible Deceleration Method”

“PresTimeOutAboveSpeed”

Selection By Theory

The ideal setting for this parameter is just above the minimum speed a train could be traveling and possibly stop between two axles. Typically the largest distance between any two axles in a train is the distance between the two inner axles on a railcar.

A good rule of thumb is 100 feet at general traffic sites. In other words, determine the lowest speed a train could possibly stop within 100 feet. For short or empty trains this value would be much higher than fully loaded or long trains.

Specifying a value that is too high will cause trains traveling a little slower than the value to not receive stuck presence circuit detection. Specifying a value too low can cause trains that stop rapidly to be split in two. Using a value shorter than 100 feet would be appropriate if only short cars travel past the site.

Selection by Data Evaluation

Locate all trains possible at the subject site that have actually stopped. Note the speed of the axle just prior to the point where the train stopped. The highest speed found would be a good value to use, but to be safe add a mph or two to the value.

“PresenceTimeoutSeconds”

Selection by Theory

This value should be set by calculating the amount of time 100’ (or whatever your target value you selected) would take to pass at the speed selected for the “PresTimeOutAboveSpeed” parameter. This value is multiplied by 4 for a safety factor. Use the formula below to calculate an appropriate value:

PresenceTimeoutSeconds = (.681 / PresTimeOutAboveSpeed)*(100’*4)

Selection by Data Evaluation

Use “Selection by Theory”.

Presence Stuck ON Detection, “Impossible Acceleration Method”

“SecondsBetweenTrains”

Selection by Theory

This value should be set to the shortest time the site would be idle between trains.

Selection by Site Evaluation

Evaluate the train data at the site and set the value to the shortest time duration between any two consecutive trains.

“LowSpeedThresh”

Selection by Theory

Use “selection by site evaluation”.

Selection by Site Evaluation

Locate all trains that have actually stopped on site. Locate the train with the highest wheel speed just prior to the point where the train stopped. Use this value as the “LowSpeedThresh”.

“HighSpeedThresh”

Selection by Theory

Use “selection by site evaluation”.

Selection by Site Evaluation

Locate all trains that have actually stopped on site. Locate the train with the highest wheel speed just AFTER the point where the train stopped. Add a safety factor to this number (at least 4 or 5) and use this value as the “HighSpeedThresh”.

ExcessPresencePeriodWarningTimeout

The build includes a new parameter called ExcessPresencePeriodWarningTimeout that can be set to allow your maintenance host to be notified if a presence circuit has been stuck on for longer than the period specified.

The APU will send warning messages periodically as long as the presence input is active and there are no wheel events (or no wheel events since the last log message was issued).

The setting is in minutes (max of 1440 which is 24 hours). The appropriate value will need to be determined by evaluating site traffic patterns, especially trains stopping for extended periods. If 0 (default) no notification is made. Activating this parameter will require your maintenance host to recognize the new message #122 (“Pres Circuit Warning”).