Telemetry from the Code Line


Summary

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:


Reports and Charts

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

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


G. T. Paine
Washington Grove, Maryland