Guide · Level Crossing Monitoring

Level Crossing Track Fault Detection: A Practical Guide

Track detection is the input that drives every level crossing decision — when to activate the flashers, when to start the warning-time clock, and when to declare the train clear. If detection misbehaves, the rest of the system has nothing reliable to act on. A track fault is any condition where the track inputs feeding the crossing don't match the expected pattern of a train movement: stuck inputs, oscillating inputs, missing inputs, or inputs that fire in the wrong order. This guide covers the track fault alarms a monitoring program should raise on the approach and island, the naming conventions used to keep them straight, and the site arrangements that make alarm configuration far less obvious than the alarm logic itself.

Track naming and arrangement

A typical signalled section has two running tracks, named Up and Down. The convention varies between railways — Up is often the direction toward the principal terminus, Down away from it — but the labels are fixed for each line and used consistently in the safety case. At a level crossing, both directions converge on an Island track: the short detection zone immediately at the road, used to register the moment a train arrives where road users and pedestrians are located.

Some jurisdictions name tracks by compass direction instead — eastbound and westbound, or northbound and southbound — particularly in North America. The function is identical; only the labels change.

For monitoring purposes the unifying term is approach track: any track feeding a train movement into the crossing is an approach track in some direction, and the island is the arrival track. A complete monitoring program raises track faults on both.

The track fault alarm set

The following alarms are raised by the on-site logic application when a track input misbehaves. Each is mapped to a severity in the operations console and relayed to the central platform, with SMS fallback when cellular comms are unavailable.

Track Stuck

A track input has been continuously occupied for longer than the configured maximum. Real movements clear in seconds — a stuck track usually means a failed shunt (water across the rails, a broken bond, a vehicle parked on a section), a failed receiver, or a control-circuit fault holding the input asserted. The threshold is set per site against the longest legitimate movement — a slow freight, a station dwell — plus margin.

Track Inactivity Timeout

The inverse problem: a track input hasn't been occupied for an unusually long time. Used primarily to flag rusty rail conditions on low-traffic sections — when there isn't enough wheel traffic to keep the railhead clean, shunt resistance rises and a real train may fail to be detected when it eventually arrives. The alarm gives the maintainer warning before that happens; the threshold is set against expected service frequency for the line.

Track Excessive Activity

A track input oscillates between occupied and unoccupied many times within a short window — far faster than real wheel passages would. The usual cause is marginal shunt: a flaky bond, contamination on the railhead, or voltage drift on the track circuit. The alarm is the leading indicator that detection at that location is becoming unreliable, before it fails outright. The threshold is a count of transitions over a configurable window.

Track Sequence Fault

A set of approach tracks was occupied in the wrong order — for example, an inner approach asserting before the outer approach for an inbound movement. Sequence faults indicate either a real detection failure on one of the approach segments or, more commonly, a movement that didn't traverse the approach in the normal way (a shunt move, a track gang working in section, a reversal). The logic raises the alarm; classification of whether the cause was a real fault or a non-standard movement is a downstream concern.

Axle Counter Reset Event

At axle-counter sites, count integrity has to be re-established whenever the section is known to be empty but the counter doesn't agree — typically after a power cycle, a comms loss to the counter, or a maintenance event. The reset is a logged event rather than an active fault, but it has to surface in the monitoring system because each reset is a manual intervention with safety-case implications. Frequent resets at the same site are a leading indicator of an underlying counter or wiring issue.

Stick Circuit Fault

Where the crossing logic uses directional sticks — auxiliary relays that latch the direction of an approach movement so the controller can deactivate cleanly after the train clears the island — and those stick states are wired back into the monitoring I/O, the logic can check them against the track occupation pattern. A stick set without a matching approach occupation, or an approach occupation with no corresponding stick, indicates either a wiring fault or a logic error in the controller. This alarm is only available when the sticks are exposed as monitoring inputs; many older designs don't expose them.

Alarm	Condition
Track Stuck	Track input occupied for longer than the configured maximum
Track Inactivity Timeout	Track input unoccupied for longer than the configured maximum — rusty rail risk
Track Excessive Activity	Track input transitions occupied/unoccupied more than the configured count per window
Track Sequence Fault	Approach tracks were occupied in the wrong order for the configured direction
Axle Counter Reset Event	An operator-initiated count reset was performed at an axle-counter site
Stick Circuit Fault	Directional stick state doesn't match the corresponding approach occupation

Site arrangements the monitoring logic must handle

The alarm logic above assumes a clean mental model: one approach, one island, trains entering in one direction at a time. Real sites are rarely that orderly. The monitoring logic has to handle a number of physical and operational arrangements explicitly, otherwise the alarms produce false positives — or worse, silently miss real faults.

Single track vs multiple independent parallel tracks

A single-track crossing has one approach in each direction and one island. Parallel-track crossings — two or more running tracks crossing the road independently — have an approach set and an island per track, and the logic has to keep each one on its own timeline. A train arriving on the Up must not be paired with an approach event from the Down. Each track gets its own configured approach set, its own thresholds, and its own alarms.

Multiple physical inputs forming one logical approach

On longer or older approaches the approach itself is divided into several track circuits or axle-counter sections. The monitoring logic combines these into a single logical approach track — typically the OR of all configured segments, so that any segment occupied indicates a train on the approach. The combination is configured per site and per direction; it cannot be inferred from electrical signals alone. The logical track's leading-edge timestamp is what drives activation and the warning-time calculation, while per-segment occupations remain available for diagnostic purposes and for the Track Sequence Fault check.

Crossings on a turnout

A turnout at or just past the crossing produces an asymmetric track layout: two approach tracks (the diverging routes) on one side, one combined track on the other — most commonly when the diverging route leads into a siding. The monitoring logic has to treat the two diverging approaches independently and merge them at the crossing, otherwise an approach occupation on the siding leg looks like a missed alarm rather than a legitimate movement. Per-route approach configuration is the only practical way to express this.

Predictor-only sites (island track only)

Constant warning time predictors don't necessarily expose discrete approach track inputs to the monitoring system — many sites simply provide the predictor's activation output and an island track output. For monitoring purposes the island is sufficient for arrival detection and for Track Stuck, Track Inactivity Timeout, and Track Excessive Activity on the island itself. Approach-side alarms — Sequence Fault in particular — simply aren't available without approach inputs, and that's a configuration property of the site rather than a software limitation.

Axle counter resets

Axle counter sections rely on count integrity, which is lost periodically — after a power cycle, a comms loss to the counter, or a maintenance event. Restoring it requires an operator-initiated counter reset. The monitoring system has to expose every reset as a logged event so that the safety case can account for them, and trend them per site: a counter that resets weekly is telling you something about the underlying installation that a single incident never would.

Shunting movements and other non-revenue operations

Shunting moves through a crossing don't necessarily traverse the approach in the order a service train would. The first symptom is Track Sequence Fault firing on movements that aren't actually wrong — they're just non-standard. The fix isn't to suppress the alarm wholesale; it's to expose a movement classification (revenue, shunt, maintenance) to the monitoring logic where the railway provides it, and either suppress the sequence check for non-revenue moves or label the resulting alarm so the operator can filter it. The same applies to Track Inactivity Timeout, which can fire spuriously on a section where shunt traffic is the dominant activity and the timeout was set for service trains.

Track machines that don't shunt the rails

Rubber-tyred hi-rail vehicles, some smaller track machines, and certain maintenance vehicles don't reliably shunt the track. The monitoring system sees them as "no train present" even when the controller and the operator both know one is there. The implication is that any alarm gated on track occupation — Inactivity Timeout, Sequence Fault, and the Stick Circuit check — may not behave correctly during these movements. The honest treatment is to expose the work-window state to the monitoring logic where the railway provides it, and either suppress or classify alarms during active maintenance windows rather than chase phantom faults the next morning.

What to monitor in practice

For a complete track fault monitoring program, instrument the following at each crossing:

Signal	Purpose
Approach track input(s) — per direction	Source of activation, sequence, and timing — combined per configuration
Island track input	Arrival detection at the road, and source of Track Stuck / Inactivity / Excessive Activity on the island itself
Direction of travel	Selects the correct approach configuration and the expected sequence per movement
Axle counter reset events (where applicable)	Manual interventions — logged per site for trending
Directional stick states (where wired)	Cross-check against approach occupation for the Stick Circuit Fault alarm
Movement classification (where available)	Revenue, shunt, or maintenance — drives sequence and inactivity suppression
Work window state (where available)	Suppress track-occupation-gated alarms during active maintenance windows

Why early detection matters

Track faults rarely jump straight to safety-critical. The usual sequence is one stuck event on a Tuesday, a couple of excessive-activity events the following week, and a Track Stuck event the week after that holds long enough to keep the crossing active for fifteen minutes — at which point a road user has driven through the booms and the incident report has already been opened. Catching the early signals is what prevents that progression.

Most rail safety frameworks require recorded evidence that approach and island detection has been working continuously. AS 7658 in Australia, EN 50129 in Europe, and CFR Title 49 Part 234 in the United States all set obligations around detection integrity and fault response time. Continuous remote monitoring turns those obligations from a periodic inspection exercise into an automatic byproduct of operation, with each alarm logged, trended, and timestamped without additional field work.

Frequently asked questions