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.
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.
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.
See below for links to traffic and anomaly reports available from these sources.
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.
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:
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:
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.
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.
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.
Drop a note to george (at) codeline-telemetry.com.
G. T. Paine
Washington Grove, Maryland