Sequence-of-Events Recording for Signalling: Getting the Order Right
When a signalling incident happens, the hard question is rarely what changed — it is in what order. Did the signal step down before or after the track circuit dropped? Did the boom start to descend before the approach was proven? Sequence-of-events (SOE) recording answers that by stamping every state change with a precise, synchronised time, so an investigator can lay the events on a single timeline and read cause from effect. This guide covers what SOE captures, why 1 ms resolution is the norm, why time-tagging at the source and synchronising the clocks is what makes the log defensible, and how to keep it trustworthy through chatter and comms outages.
What is sequence-of-events recording?
A sequence-of-events recorder captures digital changes of state and stamps each one with a precise time. An event is any monitored transition worth remembering — a signal aspect stepping down, a track circuit occupying or clearing, a signalling relay picking or dropping, a level-crossing boom leaving its raised limit, a points machine losing detection. Each transition is logged as a line: this input, this new state, at this time.
The idea comes from electrical substations, where operators needed to know whether a breaker tripped before or after a protection relay operated in order to understand a fault. Railway signalling has the same problem in a different guise. During an incident, dozens of inputs can change within a fraction of a second, and the individual changes are far less useful than the order they occurred in. SOE recording exists to preserve that order faithfully enough to stand up in a post-incident investigation.
Why signalling teams need it
Signalling is a chain of interlocked conditions, and most incidents are not a single failure but a sequence: one thing changes, which permits or forces the next, and so on. After the fact, the maintainer and the investigator are trying to answer a causal question — which change led to which — and ordinary time-stamped logs sampled every few seconds are far too coarse to answer it. Two events logged with the same second-resolution timestamp might be a cause and its effect fifty milliseconds apart, or two unrelated coincidences; the log cannot tell you.
A good SOE record turns that guesswork into a timeline. It lets an investigation establish whether a signal reverted before or after a track circuit dropped, whether an interlocking output changed ahead of or behind the relay it was meant to drive, and how a disturbance propagated across a location or between sites. That is the difference between closing an incident with a demonstrated root cause and closing it with a plausible story.
Why 1 ms resolution — and why resolution is not accuracy
Signalling relays and detectors operate on a timescale of tens of milliseconds. To resolve the order of two events that happen close together, the timestamp has to be finer than the events themselves — so 1 millisecond has become the long-standing de-facto resolution for SOE, and it is the resolution the established time-tagged event formats in protocols like IEC 60870-5 and DNP3 are built to carry. It is fine enough to separate a relay pick from the contact it closes, and coarse enough to be practical over field links.
But resolution is not the same as accuracy, and confusing the two is the classic SOE mistake.
- Resolution is the smallest increment a timestamp can express — 1 ms.
- Accuracy is how close a recorder's clock is to true time, and to every other recorder's clock.
A 1 ms resolution is worthless if two location cases disagree about the time by 50 ms: events each of them recorded correctly cannot be ordered against one another, and the cross-site timeline falls apart. The resolution sets the finest interval you can express; the accuracy sets the finest interval you can actually trust. Getting real value out of SOE is mostly a matter of making the second number better than the first.
Time-tag at the source, not at the master
Where the timestamp is applied decides whether the whole record is meaningful. It has to be stamped in the RTU or data logger, at the instant the input changes state — not when the central system later polls the site or receives the message.
The reason is that everything between the field input and the master station adds variable delay. Scan cycles, store-and-forward hops, network jitter, retries, and a congested link can each add tens to hundreds of milliseconds, and none of it is constant. A timestamp applied when the master receives the data therefore records when the event was reported, which is not when it happened — and worse, it reorders events whose messages happened to arrive out of order. Time-tagging at the source, against the recorder's own synchronised clock, is the single practice that makes the sequence defensible. The master's job is to collect the already-stamped events and merge them, never to be the clock.
Tip: When evaluating any monitoring device for SOE duty, ask exactly one question first: where and when is the timestamp applied? If the answer is anything other than "at the input, in the field device, the moment the state changes," the 1 ms in the datasheet is marketing, not forensics.
Synchronising the clocks
For timestamps from different recorders to be comparable, every recorder's clock has to be disciplined to a common reference to well within the 1 ms resolution. There are three building blocks, usually combined.
| Source | Typical accuracy | Role in an SOE system |
|---|---|---|
| GNSS (GPS) receiver | Sub-microsecond to UTC | Absolute reference at the site; the master time source everything else is disciplined to |
| PTP (IEEE 1588) | Sub-microsecond over a LAN with hardware timestamping | Distributes the reference to recorders accurately enough to underrun 1 ms comfortably |
| NTP | ~1 to a few ms on a LAN | Simple and widely supported, but only marginal for 1 ms SOE; fine for coarser logging |
The common arrangement is a GNSS-disciplined clock at the site providing an absolute UTC reference, distributed to the recorders by PTP where the network hardware supports it and by NTP where it does not. PTP reaches sub-microsecond because it timestamps in hardware and can correct for switch delay using boundary or transparent clocks; NTP, timestamping in software, is typically good to about a millisecond on a local network — enough for many purposes but sitting right on the edge of the resolution it is supposed to serve.
One practical caution: a GNSS reference can lose its satellite fix. A well-designed clock holds over on a stable local oscillator when that happens, and — importantly — flags that it is running in holdover so the quality of the timestamps it is handing out is known rather than assumed.
Quality flags: knowing when to trust a timestamp
A forensic record has to be honest about its own uncertainty. That is what the quality flags on an event are for. Alongside the point and its new state and time, a well-formed SOE entry carries markers such as an invalid flag and, critically, a clock-not-synchronised flag that is set whenever the recorder's time source was in holdover or unlocked at the moment of capture.
This matters because an unsynchronised timestamp is not merely less precise — it can be confidently wrong, and an investigator who cannot see that will trust it anyway. Standard protocols make room for exactly this: IEC 60870-5 and DNP3 both attach a quality descriptor to time-tagged events, so a downstream system can show a "time not synchronised" event differently from a fully-trusted one instead of silently treating them alike.
Keeping the log clean: chatter and debounce
Field contacts bounce, and an intermittent or failing input can toggle hundreds of times. Left unfiltered, a single bad actor will bury the events that matter under thousands of meaningless transitions — the SOE equivalent of an alarm flood. Every input therefore needs per-point conditioning:
- Debounce filter — a state change that does not persist for a configured time is suppressed, so contact bounce and momentary glitches never reach the log.
- Chatter filter — an input that changes state more than a set number of times in a window is flagged as chattering and rate-limited, so an unstable point announces itself once instead of ten thousand times.
There is a subtlety in when a debounced event is timestamped. Good practice is to stamp it at the start of the debounce window that later completed successfully — the moment the input actually changed — rather than at the end. That way the filter delays reporting the event by the debounce period but does not distort the recorded time of it, and the sequence stays true even though delivery is slightly deferred.
Surviving a comms outage
SOE is most valuable in exactly the conditions that tend to break communications — storms, power disturbances, a location taking a knock. The record has to survive that, and it does so through store-and-forward. Because each event is time-tagged and written to non-volatile buffer at the source the instant it occurs, the timestamp is fixed locally and does not depend on the link being up. When connectivity returns, the buffered events are uploaded with their original timestamps intact and merged into the central log in the correct order.
The consequence is worth stating plainly: an outage delays delivery, not time-tagging. An SOE record captured right through a comms failure is still forensically usable, because the ordering was locked in at the field device before the link ever mattered. Buffers should be sized so a realistic worst-case outage cannot overflow them before the events are drained.
The protocols that carry time-tagged events
SOE is not a single proprietary feature; the mainstream telemetry protocols already define time-tagged event types with the resolution and quality information the job needs. Using them keeps a monitoring system open and interoperable rather than locking the event history inside one vendor's tool.
| Protocol | How it carries SOE |
|---|---|
| IEC 60870-5-104 / -101 | Spontaneous time-tagged information objects using the CP56Time2a 7-byte timestamp (1 ms resolution) with a quality descriptor |
| DNP3 | Time-tagged event objects (binary input change with time) buffered at the outstation and read in event classes, each with an online/quality flag |
| OPC UA | Events and historical access carrying source and server timestamps plus status codes, for integration into higher-level systems |
Whichever transport is used, the principles are the same: the timestamp is applied at the outstation, buffered against comms loss, carries a quality indication, and is read by the master without the master re-timing it. A monitoring platform that speaks these protocols can gather SOE from mixed equipment and still present one coherent, correctly ordered timeline. (For more on choosing transports, see the companion guide on open protocols for rail data acquisition.)
What to capture in practice
For SOE to answer the questions an investigation actually asks, the right signals have to be instrumented as events in the first place. A practical baseline at a signalling location:
| Signal | Why it belongs in the SOE log |
|---|---|
| Signal aspect / lamp proving changes | Establishes when an aspect stepped up or down relative to everything else |
| Track circuit / axle counter occupancy | The occupancy sequence is the backbone of most incident timelines |
| Key signalling relay pick / drop | Ties interlocking behaviour to the physical outputs it drives |
| Points detection and command | Correlate commanded moves against detection made or lost |
| Level-crossing sequence (strike-in, boom limits, warning start) | Order of the crossing sequence is often the crux of a crossing investigation |
| Power, supply and comms status changes | Separates a real signalling event from a power or link disturbance |
| Clock sync status (locked / holdover) | Records the trustworthiness of the timeline itself over the period |
Where SOE sits relative to the vital system
SOE recording is a non-vital monitoring function. It observes the signalling — reading relay states, detection, and command lines through galvanically isolated or otherwise non-intrusive inputs — and records them. It does not participate in the interlocking logic and it does not clear or hold a signal. That boundary is deliberate: the recorder sits alongside the vital system and its EN 5012x (RAMS) safety case rather than inside it, so adding, extending, or reconfiguring SOE monitoring does not touch the vital circuit or its approval.
The payoff of that separation is that a rich forensic capability can be layered onto existing infrastructure without re-opening the safety case — the monitoring overlay watches the vital system closely while remaining firmly outside it.
Why it matters
Incident investigation drives a large share of signalling engineering effort, and its quality is bounded by the quality of the evidence. A coarse or unsynchronised event log leaves the investigation arguing over an order it cannot prove; a properly time-tagged, clock-synchronised SOE record settles that order in milliseconds and lets the analysis move on to cause. Across a network, that is the difference between recurring incidents whose root cause is never nailed down and a maintenance regime that learns from each event — which is exactly the demonstrable, evidence-based upkeep that RAMS frameworks such as EN 50126 push operators toward.
Frequently asked questions
What is sequence-of-events (SOE) recording?
The capture of digital state changes — a signal clearing, a track circuit occupying, a relay picking or dropping, a boom starting to descend — each stamped with a precise time so the exact order and interval between events can be reconstructed afterward. Its purpose is post-incident analysis: when many things change state within a fraction of a second, the SOE log is what lets an investigator tell cause from effect.
Why is 1 ms resolution used for SOE recording?
Signalling relays and detectors change state on a timescale of tens of milliseconds, so to resolve which of two near-simultaneous events happened first you need a timestamp finer than the events themselves. One millisecond is the long-established de-facto resolution — fine enough to order relay pick and drop, track occupancy, and aspect changes, and the resolution that protocols such as IEC 60870-5 and DNP3 carry in their time-tagged event formats.
What is the difference between time resolution and time accuracy in SOE?
Resolution is the smallest increment a timestamp can express — 1 ms in a typical system. Accuracy is how close each device's clock is to true time and to every other device's clock. A 1 ms resolution is meaningless if two location cases disagree by 50 ms, because events they each recorded cannot be reliably ordered against one another. Trustworthy cross-site SOE therefore depends on synchronising every clock to a common reference to well within the resolution.
Should events be time-tagged at the source or at the master station?
At the source. The timestamp must be applied in the RTU or data logger the moment the input changes state, not when the master station later polls or receives the data. Communications latency, jitter, and scan cycles add tens to hundreds of milliseconds of variable delay, so a timestamp applied at the master reflects when the event was reported, not when it happened. Time-tagging at the source, against a synchronised local clock, is what makes the sequence defensible.
How are the clocks synchronised for SOE across multiple sites?
Each recorder disciplines its clock to a common reference. A GNSS (GPS) receiver at the site gives an absolute UTC reference good to well under a microsecond and is the usual master source. Distributed over a network, NTP delivers roughly 1 to a few milliseconds on a LAN — marginal for 1 ms SOE — while PTP (IEEE 1588), with hardware timestamping and boundary or transparent clocks, reaches sub-microsecond and comfortably underruns the resolution.
Do the SOE timestamps survive a communications outage?
They should. Events are time-tagged and buffered in non-volatile memory at the source the instant they occur, so the timestamp is fixed locally regardless of the link. When connectivity returns, the buffered events are uploaded with their original timestamps intact and merged in correct order. This store-and-forward behaviour is why an SOE record captured through a comms outage is still usable — the outage delays delivery, not time-tagging.
How does SOE handle chattering or bouncing contacts?
Each input is individually filtered with a debounce time and, where needed, a chatter filter. A state change that does not persist for the debounce period is suppressed, stopping contact bounce from flooding the log. Good practice is to timestamp the event at the start of the successfully completed debounce period, so the filter delays reporting but does not distort the recorded event time. Chatter filters cap how many transitions an unstable input can log.
Is SOE recording part of the vital signalling system?
No. SOE recording is a non-vital monitoring function that observes the signalling — reading relay states, detection, and command lines through isolated or non-intrusive inputs — and records them for analysis. It sits alongside the vital interlocking and its EN 5012x safety case rather than inside it, so adding or changing SOE monitoring does not alter the vital circuit. Its value is diagnostic and forensic, not safety-vital control.
Forensic-grade event recording, built in
RailNet Operations time-tags signalling events at the source to 1 ms, disciplines site clocks to GNSS with PTP or NTP, and buffers events through comms outages — surfacing one coherent, correctly ordered timeline in a centralised operations console, IEC 61131-3 compatible and speaking open protocols.
Request Information