The Brain of the Train: Understanding the On-Board Unit (OBU)

The cab of a modern ICE 3 locomotive contains no trackside signal information directly visible to the driver — no distant yellow, no home red, no advance starter. What the driver sees is a circular speedometer, a digital speed display, a distance bar, a target speed indicator, and a mode display. These are the outputs of the ETCS On-Board Unit — a system that has read the track database, received a movement authority from the Radio Block Centre 50 km away, confirmed its position via a Eurobalise passage 8 minutes ago, and is continuously calculating whether the train’s current 280 km/h speed is within the permitted envelope for the route ahead.

In the equipment rack behind the driver’s cab is the EVC — the European Vital Computer — a beige box approximately the size of a small suitcase, containing duplicated processor boards, redundant power supplies, and the entire ETCS software stack certified to SIL 4. This box is making safety-critical decisions at 50 Hz. Its outputs control whether the traction inverters receive a run command or whether the emergency brake relay opens. The driver is informed of its conclusions; in extremis, the driver is overridden by them.

What Is the ETCS On-Board Unit?

The ETCS OBU is the complete assembly of hardware and software components installed on a train that collectively implement the onboard functions of ETCS — receiving trackside data, calculating movement authorities, supervising speed, and enforcing safe limits. It is not a single device but a system of interconnected components, each with a defined function, communicating via a certified internal data bus.

The OBU performs the same core function regardless of ETCS Level — it supervises the train’s speed against a permitted envelope and intervenes when that envelope is exceeded. What changes between levels is how the movement authority data reaches the OBU: via balise spot transmission (Level 1), via radio from the RBC (Level 2), or via continuous train-position-reporting and dynamic radio authority (Level 3).

OBU Components: The Full Architecture

The EVC: The Safety-Critical Core

The European Vital Computer is the processing heart of the OBU. Its design reflects the fundamental requirement of SIL 4 certification: the probability of a dangerous output — a result that is more permissive than the correct answer — must be less than 10⁻⁵ per hour of operation. This is achieved through redundant architecture:

Modern EVCs typically use a 2-out-of-3 (2oo3) voting architecture — three independent processor channels execute identical calculations simultaneously. Their outputs are compared before any action is taken. If all three agree, the action proceeds. If any one disagrees with the other two, a safe state is entered — traction power is cut, brakes are applied, and the crew is notified of an EVC failure. No dangerous output can be produced by a single processor failure; a second, coincident failure in a different channel would be required, which at SIL 4 failure rates has a vanishingly small probability.

The EVC software is developed under IEC 62279 (railway software safety) using formal specification methods, static analysis, and exhaustive structural testing. A full ETCS EVC software release represents millions of lines of carefully verified code, certified by an independent assessment body before deployment.

The DMI: What the Driver Sees

The Driver Machine Interface is the driver’s window into the ETCS OBU. The ETCS DMI specification (ERA/ERTMS/015560) defines a standardised display layout that must be consistent across all ETCS-equipped trains in Europe, regardless of manufacturer — a driver trained on ETCS in Germany should be able to operate the same DMI in France, Switzerland, or Spain without retraining on a different display.

The DMI displays are divided into functional areas:

• Speed area (left): Circular speedometer showing actual speed; digital speed value; permitted speed (the speed the driver should not exceed); and target speed (the speed the train should be at the next restriction point). Colour coding indicates safe (white/grey), warning (yellow), and intervention (red/orange) states.
• Planning area (right): A vertical “tunnel” display showing the track ahead — distance scale, upcoming speed restrictions, gradient indicators, and the end of authority as a target line. This gives the driver a forward-looking picture of what the braking curve requires.
• Mode/status area (top): Current ETCS mode (FS — Full Supervision, OS — On Sight, SR — Staff Responsible, UN — Unfitted, etc.); RBC connection status; and system health indicators.
• Message area (bottom): Textual messages and acknowledgement requests from the ETCS system.

Odometry: How the OBU Knows Where It Is

Odometry — the measurement of distance and speed from wheel rotation — is the primary real-time positioning mechanism of the ETCS OBU. The ODO subsystem typically combines three independent measurement methods:

• Tachometers: Rotary encoders mounted on axles or bogies measure wheel rotation at high frequency. Speed = (rotations per second) × (wheel circumference). Accuracy is limited by wheel wear, slip, and slide — a wheel with 1% wear on its circumference (about 3 mm diameter reduction on a 920 mm wheel) introduces a ~1% speed and distance error.
• Doppler radar: A ground-facing radar measures the vehicle’s speed relative to the ground surface independently of wheel rotation. Immune to wheel slip and slide; provides ground truth speed for WSP event detection and odometry correction. Accuracy ±0.5–1% of actual speed.
• Accelerometers: Measure longitudinal acceleration; integrated to give velocity and double-integrated to give position. Useful for very short time intervals but accumulates drift over longer periods.

The EVC combines these inputs using a sensor fusion algorithm — weighting each measurement source by its current reliability — to produce a best-estimate speed and position with a declared uncertainty interval. This interval grows continuously between balise passages and is reset when a balise is detected.

ETCS Modes: The OBU State Machine

The ETCS OBU operates in one of several defined modes at any time, each representing a different level of supervision and set of permitted actions. Mode transitions are managed by the EVC state machine:

The STM: Enabling Cross-Border Operation

One of the most important practical aspects of ETCS OBU design is the Specific Transmission Module — the component that allows an ETCS train to operate on routes still equipped with older national ATP systems. Without STMs, an ETCS-equipped locomotive crossing from Germany into Switzerland would lose ATP protection as soon as it entered territory equipped with a different national system.

Each STM is a certified module that interfaces with one specific national ATP system. It reads the outputs of that system — the magnetic field from a PZB magnet, the coded signal from a TVM track circuit, the acoustic tone from an AWS inductor — and translates them into ETCS-compatible speed and authority data that the EVC can use. The EVC transitions to a mode where it supervises speed based on the national system data provided by the STM rather than on ETCS movement authority data.

A locomotive requiring operation across multiple national systems needs multiple STMs installed — one per national system. A typical cross-border locomotive in Western Europe may carry STMs for German PZB, French TVM and KVB, Belgian TBL, Dutch ATB, and UK TPWS in addition to the base ETCS OBU. Managing the software updates, certification renewals, and compatibility testing for this multi-STM configuration is a significant operational and financial burden for cross-border operators — one of the practical challenges that ETCS standardisation was supposed to eliminate but has not yet fully resolved.

OBU Certification and Homologation

An ETCS OBU is not a plug-and-play device. Before a train equipped with a specific OBU can operate on a specific ETCS infrastructure, it must undergo homologation — a formal process that verifies the OBU and the trackside ETCS installation are interoperable, that the OBU software correctly interprets all the data formats and message types used by the specific RBC and balise installation, and that the combined system meets the national safety requirements of the country where it will operate.

The homologation process involves laboratory testing, track testing (the train operating over a test installation to verify all OBU functions in operational conditions), and safety assessment by a national safety authority or accredited notified body. The process typically takes 2–5 years from OBU software delivery to operational approval — a timeline that creates significant challenges for rolling stock operators who need to introduce new trains or upgrade existing trains to operate on ETCS routes.

Editor’s Analysis

Frequently Asked Questions

Q: What is the difference between the OBU and the EVC?

The OBU (On-Board Unit) is the complete system — the entire assembly of hardware and software components that implement ETCS functionality on the train, including the EVC, DMI, BTM, RCM, odometry system, TIU, STMs, and JRU. The EVC (European Vital Computer) is one specific component of the OBU — the safety-certified processing core that performs the safety calculations and generates the brake and traction commands. The EVC is the “brain” within the broader OBU system. Using “OBU” and “EVC” interchangeably is imprecise; technically, an OBU without a functioning EVC cannot operate ETCS, but the EVC is just one element of the larger OBU assembly.

Q: How does the OBU handle a situation where the train’s brakes are not performing as expected?

The ETCS OBU’s braking curve calculation uses declared brake performance parameters — the train’s guaranteed deceleration capability under various conditions — that are stored in the onboard data store (a database of train-specific technical parameters loaded when the driver takes the cab). These parameters are conservative: they represent the worst-case braking performance to ensure the calculated curve provides adequate safety margin even if brakes are not at peak efficiency. If the actual deceleration during a brake application is significantly less than the declared parameters — which could indicate a brake failure or loss of adhesion — the EVC will detect that the train is not decelerating as expected, because its position as tracked by odometry is not following the predicted braking profile. In this situation, the EVC may command maximum emergency braking on all available brake systems simultaneously and alert the driver. WSP (Wheel Slide Protection) simultaneously manages adhesion to maximise the braking force available from the existing wheel-rail contact conditions.

Q: Can an OBU be upgraded with new ETCS software versions without replacing hardware?

In most cases, yes — the OBU hardware is designed to support software updates (baseline updates) that introduce new ETCS versions or fix defects. The ETCS specification has gone through multiple baselines (Baseline 2, Baseline 3, Baseline 3 MR1, Baseline 3 Release 2) and the industry is working toward Baseline 4. Each new baseline may require software updates to the OBU. However, software updates to SIL 4-certified systems are not trivial: each update requires re-testing and re-certification of the modified software, verification that the updated OBU remains interoperable with all the trackside installations it operates on, and a controlled field deployment process. A major baseline upgrade may effectively require the same testing and certification effort as a new installation. Hardware replacement is sometimes required when a new baseline introduces features that the existing hardware cannot support — for example, when FRMCS radio is introduced to replace GSM-R, the radio hardware module in the OBU must be replaced.

Q: What is the Juridical Recording Unit and who can access its data?

The Juridical Recording Unit (JRU) is the ETCS equivalent of an aircraft flight data recorder — it continuously records all safety-relevant events, driver inputs, system states, speed, position, brake applications, and DMI interactions in a tamper-resistant storage medium. The data is used for post-incident investigation to reconstruct exactly what the ETCS system was doing and what the driver was doing in the period leading up to an incident. Access to JRU data is governed by national law and typically restricted to safety investigation bodies, the infrastructure manager, and the rolling stock operator for legitimate investigation purposes. In some jurisdictions, police and regulatory authorities can also access JRU data under specific legal provisions. The JRU records are not routinely accessed during normal operation; they are retrieved specifically following an incident. The retention period is typically 24–48 hours of rolling data, with the option to lock specific periods for preservation as evidence.

Q: Why does OBU homologation take 2–5 years — what is being tested?

The 2–5 year homologation timeline reflects the genuine complexity of verifying that a specific OBU software version correctly handles every message, data format, and edge case that the specific trackside ETCS installation may generate. ETCS specifications are extensive documents with thousands of requirements; a complete test suite covering all specified behaviours comprises thousands of individual test cases. Laboratory testing (using simulated trackside environments) covers most functional requirements. Track testing verifies that the laboratory-tested behaviours are correctly achieved in the real operational environment, including the effects of electromagnetic interference, vibration, temperature variation, and the specific characteristics of the trackside installation’s balise placement, radio coverage, and message timing. National safety authorities then review the test evidence and may require additional testing or analysis before granting operating approval. The timeline also reflects the serial nature of the process — laboratory testing must be substantially complete before track testing can begin, and national approval cannot start until track testing evidence is available. ERA’s ongoing work on a common approval process and standardised test methods aims to reduce this timeline substantially.