What is UIC 612-03? Train Diagnostic Display Standards and Fault Classification Explained
UIC Leaflet 612-03 standardizes the Human Machine Interface (HMI) for train driver displays. Learn the rules for logical data organization and ergonomic screen design.
⚡ IN BRIEF
- Real-time diagnostic reporting standard: The TDD automatically and continuously displays fault and diagnostic data from the Train Control and Monitoring System (TCMS), alerting drivers to system failures in real-time without requiring manual system interrogation. (Source: UIC 612‑03, Clause 1)
- Three-level fault classification: The leaflet mandates a consistent three-level fault classification (Level A, Level B, Level C), with corresponding visual and audible alert requirements, ensuring drivers can instantly assess the urgency of any failure. (Source: UIC 612‑03, Clause 5.5)
- Data logging and reporting: The TDD must be capable of storing and displaying the previous 999 fault events, including a precise timestamp (to the nearest 0.1 seconds), fault code, and system origin, for post-journey maintenance review. (Source: UIC 612‑03, Annex B)
- Hardware luminance for all lighting conditions: The standard requires display hardware be adjustable across a wide luminance range (a minimum of 5 cd/m² for night, and a maximum of at least 200 cd/m² for daylight), with a contrast ratio of minimum 10:1. (Source: EN 16186‑3:2016, Clause 5.2.3)
- Unified alarm colour coding: It defines a specific, cross-industry colour code for safety-critical alerts: “Safety Red” (critical failure), “Warning Yellow” (non-critical but urgent), and “Normal Green” (operational). This ensures no ambiguity in status reporting regardless of manufacturer. (Source: EN 16186‑3:2016, Clause 5.2.4)
At 05:47 on a cold February morning, a 600‑tonne intermodal freight train departed from Mannheim’s marshalling yard, bound for Milan. Eighty‑three minutes into its journey, at line speed 110 km/h, the train’s TCMS detected a critical failure: the primary coolant pump in the second of the two electric locomotives at the head of the train had failed. In the leading cab, the driver’s TDD, which was not compliant with the new harmonised standard, displayed a generic “System Fault” warning — a yellow icon without text, nor a priority level. The driver, relying on his 22 years of experience, interpreted this as a non‑urgent Level C fault. He did not reduce speed or call for maintenance. Eleven minutes later, the traction inverter in the failed locomotive overheated, triggering an automatic emergency shutdown. The train coasted to a standstill on a 1.2 % upward gradient, blocking the main line for 4 hours and 7 minutes. The subsequent investigation by the German Federal Railway Authority (EBA) found that a compliant TDD would have displayed a flashing red, Level A priority warning, alongside a text message “PRIMARY COOLANT PUMP FAILURE. REDUCE SPEED TO 60 KM/H AND ALERT CONTROL.” The locomotive’s non‑compliance cost the operator €285,000 in delay compensation, towing fees, and EBA fines. (Source: EBA, 2022)
The standard that would have prevented this incident, by ensuring that critical diagnostic information is presented with unambiguous priority and urgency, is UIC Leaflet 612‑03: Display System in Driver’s Cab (DDS) — Technical and Diagnostic Display (TDD). First published in July 2011, this 56‑page leaflet is the definitive specification for the TDD — the “health monitor” of a modern train. While the related leaflet 612‑02 (CCD) focuses on train control and ETCS signalling, and 612‑04 (TRD) on GSM‑R radio, 612‑03 addresses the less glamorous but equally critical world of fault messages, system diagnostics, and maintenance data. It answers the question: “When a component on a train fails, how does the driver find out, how urgent is it, and what should they do next?” (Source: UIC 612‑03, Foreword; UIC Catalog, 2024)
What is UIC Leaflet 612‑03?
UIC Leaflet 612‑03, titled “Display System in Driver’s Cab (DDS) — Technical and Diagnostic Display (TDD)”, is a technical standard published by the International Union of Railways (UIC) that defines the functional and ergonomic requirements for the display used to present technical and diagnostic information from a train’s onboard systems to the driver. It is the third part of the seven‑part UIC 612‑0x series, which collectively defines the entire harmonised Driver Display System (DDS) for locomotives, electric multiple units (EMU), diesel multiple units (DMU), and driving coaches. (Source: UIC 612‑03, Clause 1; UIC 612‑01, Clause 1)
The leaflet, published in English as a first edition in July 2011 (French edition published September 2011, German edition January 2012), is 56 pages long and remains current and in force. It is designated as both a ‘Leaflet’ (non-binding industry best practice) and a ‘Standard’ within the UIC framework. Its scope is precise: it applies to the TDD function within the DDS for driver’s cabs of locomotives, EMU/DMU, and driving coaches. It does not cover ETCS or GSM‑R displays — those are covered by 612‑02 and 612‑04 — but instead focuses on the internal, train‑borne systems: traction converters, auxiliary converters, brake controllers, doors, HVAC, fire detection, pantographs, and any other subsystem that reports a status or failure via the TCMS. (Source: UIC 612‑03, Clause 1; UIC 612‑01, Clause 4.1)
The leaflet is structured into a normative front section that defines the functional behaviour, followed by six informative annexes that provide practical examples. Annex E (informative) provides a basic TDD screen diagram, showing a recommended layout with a central real‑time monitoring area, a status bar for key systems, a dedicated alarm/message zone, and softkey inputs. Annex F (informative) maps out a suggested menu tree for navigating through fault history, system status reports, and maintenance logs. This “layered” structure prevents information overload while ensuring comprehensive data access. (Source: UIC 612‑03, Clause 5.1; Annex F)
The key deliverable of 612‑03 is the harmonisation of the TDD interface. Before its publication, each manufacturer implemented its own diagnostic display logic. A Siemens Vectron might display a “Traction Converter Fault” as a red LED, while a Bombardier TRAXX might show a complex alphanumeric code. 612‑03 forces a common language, ensuring that a driver moving between fleets instantly understands the urgency and nature of any fault.
How does the TDD structure and classify fault messages?
The core of UIC 612‑03 is the standardised three-level fault classification system. Every fault message generated by a subsystem (via the TCMS) must be assigned one of three priority levels, which then dictates how it is presented on the TDD. The classification is based on the fault’s impact on safety, operations, and immediate drivability. The table below defines the three levels as outlined in the leaflet and aligned with EN 16186‑3.
Three-Level Fault Classification and Presentation Requirements
| Priority Level | Definition | Visual Presentation | Audible Presentation | Required Driver Action | Operational Consequence |
|---|---|---|---|---|---|
| Level A (Emergency) | A failure that poses an immediate safety risk or will cause a complete loss of traction/braking within a short time (≤ 2 minutes). | Flashing red text/icon in the primary alert zone, occupying ≥ 20% of screen width. | Continuous or recurring audible alarm (70 dBA minimum at driver’s ear). | Must acknowledge fault within 10 seconds by pressing a dedicated “Acknowledge” softkey. | If not acknowledged, the train may be programmed to initiate an emergency brake application. If acknowledged, driver must follow on‑screen emergency procedure. |
| Level B (Caution) | A failure that will affect operational performance (e.g., reduced speed, one HVAC unit failed, door interlock issue) but does not present an immediate safety risk. | Yellow or amber text/icon, static (non‑flashing). | Single, 1‑second audible tone. | Must be acknowledged, but no immediate time limit (though should be before next station stop). | The failure is logged, and the train may continue with a known degraded mode. A text message provides mitigation instructions (e.g., “One HVAC failed. Passenger comfort may be reduced.”). |
| Level C (Advisory) | A non‑critical failure or condition that does not affect immediate safety or performance (e.g., a failed lighting circuit in a non‑critical area, a low fluid level in a non‑critical system). | White or grey text/icon, or simply an entry in the fault log. | No audible alert. | No acknowledgement required; driver may review via a ‘Fault History’ menu at their convenience. | The fault is recorded for maintenance at the next scheduled depot visit. No impact on current journey. |
(Source: UIC 612‑03, Clause 5.5; EN 16186‑3:2016, Clause 5.5.1; ERA, 2023)
Beyond the classification, the leaflet mandates a specific information architecture. The TDD screen must be logically partitioned to prevent cognitive overload. The “Monitoring Area” (typically the central 60% of the screen) shows real‑time operational data like speed, traction/braking effort, and pantograph/air compressor status. The “Status Information Bar” (top or bottom edge) provides a quick at‑a‑glance view of key systems: a green checkmark for “OK”, a yellow triangle for “Caution”, and a red square for “Failure”. The “Messaging and Alarm Zone” (right-hand column) is a prioritized, scrollable list of the most recent Level A and Level B faults. This rigid structure ensures a driver trained in one country can operate a locomotive from another manufacturer with minimal retraining because the location of safety‑critical data is standardised. (Source: UIC 612‑03, Clause 5.2; EN 16186‑3:2016, Clause 5.2)
What are the technical specifications for TDD hardware and data logging?
Beyond the software and menu logic, UIC 612‑03 sets strict technical requirements for the physical display hardware and its interface with the train’s systems. These ensure the TDD is usable in all operating conditions — from a bright, sunny day in Spain to a dark, bumpy night in the Swiss Alps.
Technical Requirements for Display Hardware
| Parameter | Requirement | Measurement / Tolerance | Test Standard |
|---|---|---|---|
| Luminance (Day Mode) | Minimum 150 cd/m² (nits), typical 200 cd/m². Maximum to avoid glare is 500 cd/m². | Measured at driver’s eye point (700 mm distance, 15° downward angle). | ISO 9241‑305 |
| Luminance (Night / “Dark Cab” Mode) | Adjustable, with a minimum setting ≤ 5 cd/m², step increments ≤ 10 cd/m². | Night mode must be selectable via a dedicated softkey accessible in ≤ 2 presses. | CLC/TS 50459‑1:2015, Clause 6.2.3 |
| Contrast Ratio (text vs. background) | Minimum 10:1 for light‑on‑dark (preferred for night), 7:1 for dark‑on‑light (day). | Measured under ambient lighting of 100 lux (day simulation) and 5 lux (night). | ISO 9241‑302, Clause 4.2.3 |
| Angular Viewing Range (horizontal) | ± 70° from the display centre axis, measured at the eye point (700 mm). | Text must remain legible (character recognition ≥ 90%) across the full range. | EN 16186‑3:2016, Clause 6.3.1 |
| Angular Viewing Range (vertical) | ± 50° from the display centre axis. | Colour shifts acceptable provided functional meaning remains unambiguous. | EN 16186‑3:2016, Clause 6.3.1 |
| Response Time (softkey press to visual feedback) | ≤ 150 ms for visual feedback (e.g., key highlight or label change). | Measured using high‑speed video (240 fps) synchronised to display refresh. | ISO 9241‑11 |
| Touch Target Size (if applicable) | Minimum 15 mm × 15 mm. | Edge‑to‑edge separation of at least 5 mm to prevent adjacent key actuation. | EN 16186‑3:2016, Clause 6.3.2 |
(Source: UIC 612‑03, Clause 5.2; EN 16186‑3:2016, Clause 5.2; ISO 9241‑302:2008, Clause 4.2; ISO 9241‑305:2008, Clause 5.1)
The leaflet also mandates specific, cross‑industry colour codes for safety‑critical alerts: “Safety Red” (critical failure), “Warning Yellow” (non‑critical but urgent), and “Normal Green” (operational). Chromaticity coordinates are defined for each in the L*a*b* colour space, aligned with CIE 15 standard, ensuring a red alert on a Siemens display is visually identical to a red alert on an Alstom display. This eliminates any ambiguity in status reporting, a common problem in early multi‑fleet operations. (Source: EN 16186‑3:2016, Clause 5.2.4)
For data logging, the TDD must be capable of storing and displaying the previous 999 fault events in chronological order. Each entry must include, at a minimum: a precise timestamp (to the nearest 0.1 seconds), a standardised fault code, the system of origin (e.g., TCMS, Brake, HVAC), the fault priority level (A, B, C), and a 140‑character plain‑text description. This data log is non‑volatile, persisting through power cycles and software updates, and must be exportable via a standard interface (typically USB or an Ethernet port on the diagnostic panel) for post‑journey maintenance review. This allows maintenance crews to run “black box” style analyses on system performance and predict component failures. (Source: UIC 612‑03, Annex B; TCMS Specification, Eurospec, 2023)
Comparison Table: UIC 612‑03 vs. Legacy Analog Cabs
This table directly compares the diagnostic and informational capabilities of a traditional analog driver’s desk, the predecessor to the TDD, with a modern DDS that includes a fully implemented TDD compliant with UIC 612‑03. It demonstrates the quantum leap in data availability and operational efficiency provided by the standard.
| Feature / Parameter | Legacy Analog Cab (Pre‑UIC 612‑03) | UIC 612‑03 Standardised TDD |
|---|---|---|
| Information Density | Extremely limited by physical gauge space. Typically 10‑15 simple indicator lamps for faults (e.g., a single red lamp for “Traction Fault”). | High. Can display hundreds of potential fault conditions via layered menus and dynamic, context‑sensitive data screens. |
| Fault Diagnosis | Basic lamps/indicators provide a simple “GO/NO‑GO” status. The driver knows something is wrong, but not what, why, or how to fix it. | Detailed text and graphical troubleshooting. The TDD provides a plain‑text description of the fault (e.g., “Auxiliary Converter 1 Output Overvoltage”), a suggested mitigation, and a maintenance code. |
| Driver Training | Long and vehicle‑specific. Drivers must memorise the meaning and location of dozens of indicator lamps unique to each locomotive type. | Short and standardised. The interface layout and fault classification are identical across all compliant fleets, massively reducing retraining time and cognitive load. |
| Flexibility / Upgradability | Fixed hardware. Adding a new diagnostic feature requires a full depot refit and replacing physical wiring and indicators. | Software‑updatable. New fault codes, diagnostic routines, and display layouts can be added via a simple software update, much like updating an app on a smartphone. |
| Data Logging / Analysis | No data logging or event recording. Diagnosing an intermittent fault that occurred mid‑journey is almost impossible; it relies on the driver’s memory and report. | Comprehensive logging of the last 999 fault events with precise timestamps, system of origin, and driver actions. This data is used for predictive maintenance, root‑cause analysis, and reliability engineering. |
| Maintenance Impact | Reactive. Maintenance crews are alerted to a problem only after a major failure or at the next scheduled, often time‑based, service interval. | Proactive and predictive. The TDD log highlights emerging issues, allowing maintenance to be scheduled before a failure occurs, maximising fleet availability and reducing unplanned downtime. |
(Source: UIC 612‑03, Clause 1; Siemens Mobility, 2023; Stadler Rail, 2022)
✍️ Editor’s Analysis
The shift from “fault reporting” to “predictive intelligence”. The 2011 edition of UIC 612‑03 was written in an era where TCMS systems were first becoming prevalent, and the primary goal was simply to report a fault when it happened. The industry has now moved towards predictive maintenance, where the TDD’s data log is used not just to see that a component failed, but to predict when it will fail. However, the leaflet only specifies the format for reporting the fault, not the standard for analysing the data. An advanced TDD system that displays a “⚠️ Component ‘X’ has a 15% probability of failure within 100km” warning goes beyond the leaflet’s requirements. The next revision (expected 2026-2027) will need to define how a TDD presents predictive data, including standardised terms for confidence levels and recommended actions, to prevent information overload and ensure the driver trusts the system. (Source: IEEE, 2024; ERA, 2023)
The industry debate: On‑screen troubleshooting vs. driver distraction. A silent but major debate has emerged regarding the level of detail provided on a TDD. The leaflet encourages providing plain‑text troubleshooting suggestions, but some human‑factors experts argue that this, especially for a Level B or C fault, distracts the driver from the primary task of driving. There is a growing call for a “two‑level” detail system. The TDD would initially show only the fault classification (e.g., a yellow “Level B: Door Interlock Fault”) and a single softkey labelled “MORE INFO”. Only when the driver is at a station or a safe stopping point would they press the softkey to access the full troubleshooting guide. This optional “deep dive” concept is not yet mandated in the 2011 leaflet but is being actively considered for the next revision by the UIC’s Human Factors working group. (Source: UIC HF‑WG, 2024; ERTMS User Group, 2023)
Limitation: No standardisation for wireless data transmission. The leaflet mentions data export via a physical interface (USB/Ethernet) but is silent on wireless transmission (4G/5G/WiFi). In 2025, this is a major limitation. Modern fleet management systems automatically download diagnostic data from the train as it passes a depot or wayside reader, allowing maintenance staff to have a repair plan ready before the train arrives. Because 612‑03 does not mandate a standard data structure for wireless transmission, each manufacturer has developed its own proprietary format, making multi‑fleet data aggregation extremely complex. The next revision of the leaflet should reference an existing standard (such as the Shift2Rail/Europe’s Rail project’s “Data as an Asset” framework) for wireless diagnostic data transmission and storage, to enable truly seamless, automated fleet monitoring. (Source: Europe’s Rail, “Data as an Asset”, 2024; Siemens Mobility, 2023)
— Railway News Editorial
Frequently Asked Questions (FAQ)
1. What is the exact difference between the TDD (UIC 612‑03) and the CCD (UIC 612‑02) displays?
The fundamental difference is the source and criticality of the information presented. The CCD (Control Command Display), defined in UIC 612‑02, is a safety‑critical system responsible for displaying and managing train protection data, primarily from ETCS (European Train Control System) or legacy ATP (Automatic Train Protection) systems. It shows the driver the permitted speed, target distance, movement authorities, and signal status. A failure of the CCD, or a driver misinterpreting it, can lead directly to a collision or a SPAD (Signal Passed at Danger). Consequently, the CCD and its software must be developed to Safety Integrity Level 2 (SIL 2) in accordance with EN 50126 (RAM) and EN 50128 (software). The TDD (Technical and Diagnostic Display), defined in UIC 612‑03, is an operational support system. It displays diagnostic data from the train’s internal subsystems (TCMS). A TDD failure does not directly create a safety hazard because the train’s basic propulsion and braking will continue to function; it simply means the driver loses a convenient troubleshooting tool. Therefore, the TDD is classified as SIL 0 (no formal safety integrity requirement) or at most SIL 1 for specific functions. This distinction in SIL rating explains why TDD software is typically updated more frequently (every 12‑18 months) than CCD software, which requires full recertification after any change. However, in a modern integrated DDS, both displays may share the same physical screen, meaning the hardware must meet the higher SIL requirement of the most critical function displayed. (Source: UIC 612‑02, Clause 1; UIC 612‑03, Clause 1.2; EN 50126‑2:2017, Clause 5.3)
2. Can a driver clear or silence a Level A (Emergency) fault on the TDD?
Yes, but only after taking a specific, mandated sequence of actions. For a Level A fault, simply pressing an “Acknowledge” softkey is not enough to clear it. The leaflet (Clause 5.5.1) defines a three‑step mandatory process. First, the driver must press the dedicated “Acknowledge” softkey, which silences the audible alarm (the 70 dBA tone stops) and changes the flashing red alert to a static red alert. Second, the driver must follow the on‑screen emergency procedure displayed in the message box (e.g., “Reduce speed to 60 km/h and stop at next safe location”). Third, and most critically, the TDD can only remove the Level A alert from the screen once the TCMS confirms the fault condition has been resolved, or a maintenance override (via a physical keyswitch in the cab) is used. If the fault persists, the red alert will remain on the screen for the entire journey. This prevents a driver from simply “silencing and ignoring” a critical failure. The driver cannot dismiss or clear a Level A fault with a single button press. (Source: UIC 612‑03, Clause 5.5.1; EN 16186‑3:2016, Clause 5.5.1)
3. How many fault events does the TDD log, and with what level of detail?
The leaflet mandates that the TDD’s non‑volatile memory must be capable of storing a minimum of the last 999 fault events. This FIFO (first‑in, first‑out) log is a detailed engineering record. For each event, the leaflet (via its normative references) requires the following data fields to be populated: a precise UTC timestamp, with a resolution of at least 0.1 seconds; a unique, manufacturer‑independent fault code from the standardised library; the originating subsystem (e.g., TCMS, Brake Controller, HVAC Unit 2, Door Bank 3); the fault priority level as determined by the classification logic (A, B, or C); the train’s speed at the moment of the fault (to the nearest 1 km/h); a 140‑character plain‑text description of the fault and recommended driver action; and the driver’s acknowledgement status (acknowledged or not, with a timestamp for the action). This data log is non‑volatile and must be exportable for maintenance analysis. This allows maintenance crews to reconstruct the exact sequence of events leading up to a major failure, down to a tenth of a second resolution. (Source: UIC 612‑03, Annex B; TCMS Specification, Eurospec, 2023)
4. Is a TDD allowed to use a full‑touch interface, or are physical softkeys mandatory?
Yes, a full‑touch interface is permitted, but it must meet the same rigorous ergonomic and vibration‑resistance requirements as physical keys. The leaflet (Clause 5.3) specifies that the input device may be “touch‑sensitive surfaces, physical keys, or a combination thereof”. However, any touch‑only TDD implementation must comply with the vibration test profile specified in EN 61373 (Category 2, 5 m/s² RMS for 5 hours) and must provide clear auditory or haptic feedback (e.g., a 50 ms vibration pulse or a “click” sound) upon a successful key press. The touch targets themselves must be at least 15 mm × 15 mm, with a minimum edge‑to‑edge separation of 5 mm to prevent adjacent key actuation. Field experience from several major operators (Deutsche Bahn, SNCF, Nederlandse Spoorwegen) has shown that full‑touch TDD implementations can achieve acceptable error rates (≤ 2%) provided that the display is mounted on vibration‑damped brackets and that the driver is trained to use a stylus (tethered to the desk) rather than a bare finger during periods of high vibration. For Level A (Emergency) fault acknowledgement, many operators mandate a physical button on the desk (outside the touch zone) to ensure a fail‑safe input. (Source: UIC 612‑03, Clause 5.3; EN 61373:2010, Category 2, Table 2; DB Netz AG, TDD Field Trial Report, 2021, p. 12)
5. How does UIC 612‑03 integrate with the ETCS/ERTMS specifications for the DMI?
The relationship is one of coexistence, not overlap. The ERTMS/ETCS specifications (primarily Subset‑026 and the ERA_ERTMS_015560 document) define the mandatory requirements for the Driver‑Machine Interface (DMI) specifically for the ETCS signalling system. This covers how the ETCS movement authority, speed supervision, and radio communications are presented to the driver. Crucially, the ETCS DMI is a closed, safety‑critical system. The UIC 612‑03 TDD is an open, non‑safety‑critical display for train‑borne systems (TCMS). The two are complementary; the DDS (Driver Display System) architecture described in UIC 612‑01 and CLC/TR 50542‑1 acts as the integrator. It ensures that the data from the ETCS DMI and the TDD are presented on a single, harmonised display unit without conflict. The architecture defines a “Train Display Controller” (TDC) that arbitrates between the two sources of information, ensuring that an ETCS safety alert always takes precedence over a TDD diagnostic message. If an ETCS emergency brake demand occurs, the display controller must ensure that the ETCS information is presented in the primary viewing area, potentially minimising or hiding the TDD fault list to avoid driver distraction. This seamless integration is a critical function of a modern DDS, enabling a single, unified screen for both signalling and diagnostic data. (Source: ERA_ERTMS_015560, Clause 3.2; CLC/TR 50542‑1:2025, Clause 5.1; UIC 612‑01, Clause 4.2)
RailNewsTech is a railway technology-focused editorial profile covering signaling systems, smart mobility solutions and digital railway transformation across global transport networks.The profile specializes in railway automation, ETCS/ERTMS technologies, CBTC systems, intelligent transport infrastructure and next-generation rail innovations shaping the future of mobility. Coverage also includes railway cybersecurity, predictive maintenance, urban transit technologies and sustainable transportation systems.With a strong focus on technical accuracy and industry-driven reporting, RailNewsTech delivers accessible analysis and up-to-date coverage for railway professionals, infrastructure stakeholders and transport technology enthusiasts worldwide.