Telemetry from the Code Line

Summary

Railway control systems contain information that could be useful for directing track and facility maintenance efforts, and which could be of interest from a planning, regulatory and oversight perspective, but whose potential has been overlooked.
Some communications systems currently in use facilitate access to and sharing of this information.
Potential applications for traffic management and anomaly detection and a live sample of this information, updated daily, are presented.

Introduction

Railway control and signal systems once used company operated trackside wires strung on wooden poles for communications. As the cost of maintaining this infrastructure has increased many carriers have chosen to redirect this message traffic over different media including terrestrial radio, satellite, cellular and buried wire or optical fibre. The choice for a given location depends on a variety of factors; in many cases multiple paths are defined in order to provide network redundancy should one of these modes fail.

When terrestrial radio is used in some cases the signals can be received with a suitably configured data radio and a personal computer running the ATCS Monitor software, much as voice communications are accessible to a scanner. This activity is innocuous, legal, safe and for some, fascinating. About the only consequence of doing this is that anybody in whom interests in railroading (operations in general as well as the signal craft), process control systems, radios, computers and data networks converge is functioning in an area sufficiently abstruse as to be considered an über-geek by society at large -- one learns quickly to refrain from regaling friends, family and acquaintances with details. Extending such an offer to strangers would be a sure fire way to guarantee plenty of personal space in any public place no matter how crowded.

The systems whose signals are thus accessible communicate using standard protocols but the actual configuration of the devices is not documented other than to those responsible for their care and feeding, so a reasonably complete workable decoding for a railway control point entails analysis of logfiles containing the traffic in question to correlate the contents against observed events.

Once this has been done one can use the software to drive a real time display that echoes a dispatcher's model board, adding a visual element to the voice traffic that can be heard among railroad crews, maintenance forces and the dispatcher's office. When this happens the hobbyist often has a more comprehensive view of a situation than many of its direct participants.

This information can be thought of as a telemetry stream and has potential uses beyond real time monitoring.

Contents of the Code Line

The code line traffic consists of messages exchanged between the railway's control system and control points in the field. The message types of interest are controls, messages sent to a control point with a command; and indications, replies sent back to confirm an action or report on the control point's configuration or status. An indication message describes the position of the control point's switches, whether signals are displayed to allow train movements to proceed, and the occupancy of tracks within the control point limits or on track segments approaching it.

Each of these conditions is assigned to particular bits within a message payload. As messages arrive from a particular control point these bits are raised and knocked down (lowered) in patterns corresponding to each event as it occurs. Switches are thrown, interlocks might be applied, signals are displayed, a train approaches the control point, passes through it and departs by way of the opposite side's approach blocks. In some locations approach block out-of-service conditions are also visible through the code line.

Applications

Movement Statistics

Code line message traffic captures events generated by the movement of trains past control points. These can be found by looking for patterns where a run of signal indication bits is followed by an in-plant track occupancy bit for the same track and direction.

Each event specifies a location, date and time, track number and direction. When collected from control points along a particular line these events provide a detailed record of train movements (see figure below). The only pieces missing from the otherwise complete picture is actual identification of each train; their presence can be inferred and their progress tracked from the code line but at that granular a level of detail an external correlation step would be required in order to establish identity. For some applications, such as analysis of overall corridor usage and fluidity, such a step might not be necessary.

Transportation planners are familiar with metrics from sources such as embedded pavement sensors but rail is segregated by carrier and corresponding information is not always readily available, particularly to stakeholders outside the organization. In this case, however, the information is already out there and needs only to be collected.

Code line messages follow standard protocols and once a control point's bit pattern has been established its movement events can be collected for traffic analysis. Data collection requires a radio, an antenna, a computer, and an internet connection ... and, most importantly, a location from which the desired signals can be received. The radio transmissions are highly directional so placement of the receiver within the beam path is an important consideration.

Case in Point

As receivers have come into service, regional and corridor monitoring has become feasible.

Along the east coast coverage is available from the Mid-Atlantic region through the southeast, from Philadelphia down to Florida.
Regional coverage in California is represented by receivers near Sacramento and the San Joaquin Valley covering multiple frequencies and protocols in use on BNSF and UP lines in the region.
Better yet, see the complete map list.

See below for links to traffic and anomaly reports available from these sources.

Limitations

Code line messages are transmitted from distributed point sources but unless receivers are within range the information dissipates into the ether. Existing networks have come into being where somebody has had the time and inclination to set them up; comprehensive coverage is likely to require additional receiver locations. This can be done with minimal time and effort.

Unusual Conditions

Code line message traffic also reflects what happens under unusual conditions. Depending on how the control point is configured its messages might occasionally include indication bits representing any number of situations such as loss of electrical power, snow/ice melter apparatus in operation, manual override locally applied, or a signal lamp having burned out. When this happens the challenge is to determine the triggering event and establish its correlation to the unknown part of the received message.

Other conditions might be manifest by an unexpected sequence of grouping of routine indications. These patterns are present in the code line messages but the information might not necessarily be made available to those who could make effective use of it to diagnose potential problems and undertake timely intervention. In most railroads the Track & Structures Department is separate from the Communications & Signals Department and the two are staffed from different crafts who may lack awareness of information in one that could be useful to the other.

Case in Point

An example of this is what happens when a control point is instructed to change the position of a switch from normal to reverse. The expected sequence would be:

control point reports current switch position (it will do this on its own, typically once a minute or so)
control point receives command to change switch position
control point acknowledges receipt of command
control point reports switch is in motion, which is to say it is in neither its normal or its reverse position. this condition is also known as being "out of correspondence".
control point reports new switch position

The control point's logic will prevent it from altering switch position when the track is occupied. In some cases interlocks are engaged to enforce this with hardware when a route is lined through the control point.

At times, however, the control point may report that a switch is in motion in the absence of a command to change its position. This could happen while a manual override is in effect or during routine testing or maintenance.

It definitely should not be expected to occur while the track is occupied, but sometimes it does happen. Such a sequence would be:

track occupied, switch in normal (or reverse) position
track occupied, switch in motion
track occupied, switch reverts to normal (or reverse) position

Any time a control point reports such a sequence further investigation would seem to be indicated. The switch may or may not actually be moving: some part of it might be loose or out of adjustment, or perhaps a sensor has failed or the electrical signal from it to the control point is impeded, or maybe there's some logic problem within the control point itself. In a sense it doesn't really matter: whatever the underlying condition may be, the device messages are making it clear that some sort of attention is needed.

See It for Yourself

String Line Charts

String line charts are a traditional tool used for rail operations planning. At their essence they are simple graphs of distance against time. Train movements extracted from code line messages can be displayed in this format. For example, the chart below shows traffic on the Union Pacific Valley Subdivision over a 24 hour period as collected by a receiver in Roseville CA.

(click through this thumbnail for higher resolution image)

Notes:

Northbound movements are shown in green; southbound in purple.
The Valley Subdivision runs North from Roseville; the first control point is Sierra at milepost 107.1. Radio propagation varies over the course of the day; the effective receive range is greater at night and shorter during the day. More complete coverage could be obtained by installing another receiver further up the line.
The Sacramento Subdivision crosses the Valley Subdivision at Binney Juction, milepost 141.9; east-west movements (blue and red markers) cross there, and some trains enter or leave the Valley Subdivision at that location.

Reports and Charts

A client computer in Maryland is set to monitor radio code line message traffic in the region and beyond.

Traffic counts by carrier, subdivision, location, track and direction are compiled for over a hundred locations on selected railroad subdivisions around the country (the actual number varies from day to day depending on atmospheric conditions). This report is generated daily a few minutes after midnight; for the current copy see www.codeline-telemetry.com/traffic_summary.htm (uses javascript).
String line charts similar to the example given above are also available; for a list see www.codeline-telemetry.com/strings/stringlines.htm (uses SVG ).
Also available is a list of the day's top 20 control points from a wider (500⁺) set of locations in the US and Canada.
When a switch-out-of-correspondence-under-traffic event occurs in any of these locations the details are collected and summarised into an anomaly report. This report is generated daily a few minutes after midnight; for the current copy see www.codeline-telemetry.com/anomalies.htm (uses javascript).

You'll see when and where the events occurred. The details include which switch, which position it had been in, which tracks were in use and the direction of movement at the time. For control points comprising multiple switches a configuration diagram is included for your convenience.

Those with an interest in railroad operations, capacity management and safety might find them worth perusing.

Comments? Questions?

Drop a note to george (at) codeline-telemetry.com.

Thank you

Dave Houy, author of the ATCS Monitor.
Barry Baines, Richard Barnes, Clark Bauman, Brandon Baxter, Joe Brice, Dave Burroughs, Pat and Bill Caldwell, Mike Collins, Paul Cordingly, Greg Dahbura, Eric Davis, Doug DeLong, Chuck Doubrough, Henry Dralle III, Robb Fisher, Fred Frailey, Peter Furnée, Todd Greimel, Gary Hahn, Mark Hammond, Geoff Hilyard, Deborah King, Kris Klemick, John Kluender, Bob Korth, J Alex Lang, Bill Larduskey, Ken Mazer, Rob McCormack, Steve Miller, Mack Muir, Doug Nipper, John D. Peterson, Frank Scheer, Joe Shaw, Dave Sheppard, Greg Soots, Tokira, Jason Toyger,an anonymous California roof monkey and others for server hosting and other technical contributions.
Many others who have assisted with time, effort, fieldwork, outreach, beta testing, equipment and funding.
Special thanks goes to A2 hosting for providing stellar uninterruptible service! Read full a2 hosting review for more details. In addition we would like to point out a great resource where you can easily find top 10 web hosting sites for non-commercial and open source projects.

G. T. Paine
Washington Grove, Maryland