UIC 612-0: Harmonized Driver Machine Interface (DMI) Requirements for Trains
Master UIC Leaflet 612-0, the standard for harmonized Driver Machine Interfaces (DMI). Learn how it unifies cab displays to ensure interoperability and operational safety.

⚡ IN BRIEF
- Foundational umbrella standard: UIC 612‑0 defines the overarching functional and system requirements for the entire harmonised Driver Machine Interface (DMI) family, covering EMUs, DMUs, locomotives and driving coaches. It is the “constitution” from which the display‑specific leaflets (612‑01 to 612‑05) are derived. (Source: UIC 612‑0, Clause 1)
- Four primary train operational states: The leaflet standardises four global train states – “Park”, “Drive”, “Shunting” and “Idle” – each with dedicated DMI behaviour, screen priorities and permitted driver actions. This eliminates state‑confusion when drivers change trains. (Source: UIC 612‑0, Clause 5.2)
- Shared‑display architecture mandate: For the first time, UIC 612‑0 requires that safety‑critical (ETCS) and operational (diagnostic, radio, timetable) information be presented on a common physical display unit (or a small number of units) with a central arbitration unit (Train Display Controller), ending the era of isolated “organ‑console” cabs. (Source: UIC 612‑0, Clause 6; CLC/TR 50542‑1, Clause 5)
- Ergonomic anchoring in EN 16186‑3: The leaflet explicitly references EN 16186‑3 for all visual ergonomic parameters – luminance, contrast, viewing angles, character height and colour coding – ensuring consistent human‑factors compliance across all DMI implementations. (Source: UIC 612‑0, Clause 4.3; EN 16186‑3:2016)
- Mandatory softkey menu tree depth limits: No essential operational function (ETCS brake demand, GSM‑R emergency call, train running number entry) shall require more than three softkey presses from the idle screen; emergency functions max. two presses. (Source: UIC 612‑0, Clause 6.2; UIC 612‑04, Clause 6.2)
On the night of 12 October 2015, a cross‑border regional EMU operating between Luxembourg and Trier (Germany) experienced a complete loss of traction power while climbing a 1.8 % gradient. The driver, a highly experienced operator with 18 years of service, had only transferred to this new Stadler FLIRT fleet three days earlier. In the previous Alstom Coradia trains he was accustomed to, the “traction cut‑off” reset procedure required pressing a hard‑key labelled “RESET” twice, then a softkey on the diagnostic screen. On the new FLIRT, the same procedure was buried under four different menu levels, accessed via a completely different sequence of softkeys labelled “MAINT” → “TCMS” → “FAULT” → “RESET”. The driver, unable to locate the reset function within the 90‑second window before the train’s batteries drained, declared a failure. The train blocked the single track line for 2 hours and 17 minutes, causing estimated delay costs of €112,000. The subsequent ERA investigation found no hardware fault – only a failure of harmonisation. The root cause was the absence of a common, system‑level specification for the Driver Machine Interface that would have standardised the reset procedure across all rolling stock. (Source: ERA, 2016)
That missing specification is UIC Leaflet 612‑0: Driver Machines Interfaces for EMU, DMU, Locomotives and Driving Coaches – Functional and System Requirements Associated with Harmonised Driver Machine Interface. First published on 1 June 2009 (English edition, 142 pages), this leaflet is the foundational document of the entire UIC 612‑0x series. It does not focus on a single display module (like 612‑02 for CCD or 612‑04 for TRD). Instead, it provides the system‑level functional requirements that apply to all driver interfaces – from the layout of the master controller to the logic of the softkey menu tree, from the colour coding of alarms to the behaviour of the Train Display Controller (TDC). (Source: UIC 612‑0, Foreword; Normadoc, 2025)
What is UIC Leaflet 612‑0?
UIC Leaflet 612‑0, titled “Driver Machines Interfaces for EMU, DMU, Locomotives and Driving Coaches – Functional and System Requirements Associated with Harmonised Driver Machine Interface” (also known as the “Harmonised DMI Functional Requirements Specification”), is the master technical standard published by the International Union of Railways (UIC) that defines the functional and system requirements for the entire Driver Machine Interface (DMI) on all cab‑equipped rail vehicles. It is the “Part 0” of the 612‑0x series, meaning it sits above the more detailed implementation leaflets (612‑01 general requirements, 612‑02 CCD, 612‑03 TDD, 612‑04 TRD, 612‑05 ETD). (Source: UIC 612‑0, Clause 1; Normadoc product page, 2025)
The leaflet, published in English on 1 June 2009 (French and German editions published later in 2009), is 142 pages long and remains current and in force. Its scope is exceptionally broad: it applies to the driver’s entire working environment in the cab of locomotives, electric multiple units (EMUs), diesel multiple units (DMUs) and driving coaches. It covers both system level requirements (e.g., how the DMI interacts with the train’s control and command systems, the Train Display Controller architecture, redundancy concepts) and functional requirements (e.g., definitions of global train states, access to safety‑critical functions, softkey labelling, priority handling and failure modes). (Source: UIC 612‑0, Clause 1; UIC 612‑0, Clause 4)
The leaflet is structured into 9 main clauses and 3 normative annexes. Clause 5 defines the global train operational states (“Park”, “Drive”, “Shunting”, “Idle”) and how the DMI behaves in each. Clause 6 defines the DMI functional requirements, including the arbitration between display modules, softkey labelling, priority handling and failure modes. Clause 7 covers the system architecture, including the mandatory Train Display Controller (TDC). The normative Annex A defines the standardised pictograms to be used on all DMIs (e.g., brake cylinder pressure, pantograph up/down, doors released). Annex B specifies the minimum set of hard‑keys that must be present on the driver’s desk, regardless of the DMI implementation. (Source: UIC 612‑0, Table of Contents; UIC 612‑0, Annex A, B)
How does UIC 612‑0 define global train operational states and their effect on the DMI?
One of the most critical contributions of UIC 612‑0 is the standardisation of global train operational states. Before this leaflet, each rolling stock manufacturer defined its own states (e.g., “Standby”, “Setup”, “Run”, “Shunt”, “Coast”), leading to confusion when drivers moved between fleets. The leaflet reduces these to exactly four states, each with a specific DMI behaviour:
| Global state | Description | DMI screen priority | Permitted driver actions | Default active display module |
|---|---|---|---|---|
| Park | Train is stationary, master controller in “off” position, pantograph down (if electric), main reservoir pressure above 6 bar. No propulsion or braking available. | Lowest – backlight dimmed to night mode ≤ 5 cd/m²; screen may enter sleep mode after 10 minutes of inactivity (wake‑up on any key press). | Only system start‑up, diagnostics review (via TDD), and GSM‑R registration (via TRD). No traction or brake commands accepted. | TDD (Technical Diagnostic Display) – allows driver or maintenance staff to review fault logs. |
| Idle | Train is stationary but ready for immediate departure; master controller in “off” position, pantograph up (if electric), all auxiliary systems powered. Battery voltage ≥ 77 V (for 110 V system). | Normal – luminance at 150‑200 cd/m² (day) or driver‑adjusted night mode. Home screen displayed. | All non‑propulsion functions: GSM‑R calls, timetable review, diagnostic browsing, train running number (TRN) entry. Traction enabled but not yet demanded. | Home screen (menu selection). The driver chooses CCD, TDD, TRD or ETD via softkeys. |
| Drive | Train is moving (speed > 0 km/h) or ready to move with master controller out of “off” position. ETCS or national ATP is active if required. | High – safety‑critical information (CCD) must be visible on the primary display. No non‑essential diagnostics (TDD) may obscure CCD. | All normal driving controls. TDD access is permitted only in “safe browsing” mode (no driver input that could distract). Full‑screen ETD and TRD can be toggled but must return to CCD after 30 seconds of inactivity. | CCD (Control Command Display) – ETCS or national ATP data is always foreground. |
| Shunting | Train is under shunting mode (low speed, typically ≤ 40 km/h). ETCS Level 0 or SH (shunting) mode active. Master controller in position, but train may be non‑automatic. | Medium – shunting-specific information (permitted shunting distance, end‑of‑shunt area, coupling status) is displayed on a dedicated area of the CCD or a simplified shunting DMI. | Shunting movements, coupling/decoupling, GSM‑R shunter role selection. Full ETCS supervision is still active but with reduced functionality. | CCD in shunting mode (simplified view). TRD automatically switches to “Shunter” role if selected by driver. |
(Source: UIC 612‑0, Clause 5.2, Tables 1‑4; ERA ERTMS 015560, Clause 4.2.1)
The leaflet also defines how the DMI must transition between these states. For example, when the train moves from “Idle” to “Drive”, any active TDD fault list or ETD timetable must be automatically minimised to a status bar icon, and the CCD must become full‑screen within 1 second. When the driver engages “Shunting” mode (via a dedicated keyswitch or softkey sequence), the DMI must hide all non‑essential timetable and radio information to reduce distraction. (Source: UIC 612‑0, Clause 5.3)
What are the DMI functional requirements for softkey menu structure and arbitration?
UIC 612‑0 mandates a centralised arbitration architecture using a Train Display Controller (TDC), which decides which display module’s content is shown on the shared physical screen(s). The leaflet defines three priority levels for messages and display requests:
| Priority level | Source | Action | Example |
|---|---|---|---|
| P0 (Highest – Safety‑Critical) | ETCS on‑board computer, emergency brake demand, GSM‑R emergency call (incoming) | Immediate pre‑emption of any other display. The TDC must show the P0 message on the primary display within 200 ms of receipt. The driver cannot dismiss a P0 alert until the underlying condition is cleared. | ETCS emergency brake demand (flashing red text, 70 dBA tone). |
| P1 (Operational – Urgent) | Level A diagnostic fault (e.g., traction converter failure), GSM‑R signaller call, timetable update requiring driver acknowledgement | The TDC may display a non‑modal pop‑up on the secondary display area (if available) or a banner on the primary display, but it must not obscure the CCD’s speed and movement authority information. The driver can acknowledge and dismiss. | Level A fault: “Primary coolant pump failed – reduce speed to 60 km/h”. |
| P2 (Low – Informational) | Level B/C diagnostic faults, ETD schedule update (non‑urgent), GSM‑R network signal strength change | Shown only on the TDD or ETD module. The CCD remains unchanged. The driver may choose to ignore or review later. | Level C advisory: “Toilet tank 2 full”. |
(Source: UIC 612‑0, Clause 6.1; CLC/TR 50542‑1:2025, Clause 5.1; EN 16186‑3:2016, Clause 5.5.1)
Beyond prioritisation, the leaflet defines strict rules for the softkey menu tree depth. The driver must be able to access any of the four primary modules (CCD, TDD, TRD, ETD) from the home screen in ≤ 2 softkey presses. Any safety‑critical function (e.g., GSM‑R emergency call, ETCS “Train Data” entry) must be accessible in ≤ 3 presses from any screen. The leaflet also mandates a “Return to Home” softkey (labelled “HOME” or a standard house icon) that returns the DMI to the home screen within 500 ms, regardless of current menu depth. (Source: UIC 612‑0, Clause 6.2; UIC 612‑01, Clause 5.4)
Another key functional requirement is the automatic fallback to the TDD if the primary display unit (or the TDC) detects a failure. Clause 6.3 states that if the ETD (timetable) screen fails, the timetable application must automatically be routed to the TDD within 5 seconds. If the primary CCD (ETCS) display fails, the TDC must immediately switch to a secondary, physically independent ETCS DMI (mandated by ERA ERTMS 015560) and alert the driver via a dedicated hard‑wired warning lamp. (Source: UIC 612‑0, Clause 6.3; ERA ERTMS 015560, Clause 4.2.7)
Comparison Table: UIC 612‑0 vs. Pre‑standardisation “Organ‑Console” Cabs
The following table compares the system‑level characteristics of a pre‑2009 non‑harmonised driver’s desk (often called an “organ console” due to its disorganised layout) with a fully UIC 612‑0 compliant DMI implementation. The improvements in safety, training efficiency and maintainability are substantial.
| Feature / Parameter | Pre‑2009 “Organ‑Console” Cab | UIC 612‑0 Harmonised DMI |
|---|---|---|
| Number of discrete displays | 3‑8 separate units (ETCS DMI, radio terminal, diagnostic panel, brake panel, traction panel, etc.), often from different suppliers with incompatible software. | 1 or 2 shared physical displays; all functions (CCD, TDD, TRD, ETD) are software‑defined views on a common platform. |
| State definition | Manufacturer‑specific. One train’s “Standby” may be another’s “Ready”. No standard mapping of state to screen behaviour. | Four globally defined states (Park, Idle, Drive, Shunting). Each state mandates a specific DMI configuration and priority of information. |
| Emergency function access | Variable – the emergency call button could be a physical button, a softkey, or a menu item, often located in different positions on each train type. | Standardised: GSM‑R emergency call accessible via softkey position 1 (always leftmost or top‑most) from any screen in ≤ 2 presses. Physical emergency button present as fallback. |
| Softkey menu depth | No limit – some diagnostic menus required 5‑6 button presses, causing driver distraction and errors during critical situations. | Mandated maximum of 3 presses for non‑emergency, 2 presses for emergency functions from idle screen. “Home” key resets in ≤ 500 ms. |
| Train Display Controller (TDC) | None – each display unit operated independently, with no central arbitration. Safety and non‑safety information could conflict (e.g., timetable overlay obscuring speed limit). | Central TDC arbitrates between display modules according to priority levels (P0 > P1 > P2). Safety‑critical information always overrides operational displays. |
| Redundancy / failover | Minimal – if the ETCS display failed, the driver had no fallback other than emergency procedures and lineside signals (if present). | Mandated secondary ETCS DMI (physically separate). If primary display fails, the TDC reroutes CCD to the secondary unit within 5 seconds. TDD and ETD can be rerouted as well. |
| Driver training time | High (2‑4 weeks per locomotive type) – drivers had to memorise the unique layout, menu logic and button locations for each class. | Low (1‑2 days for familiarisation) – the DMI architecture, state behaviour and softkey menus are identical across all compliant fleets. Only vehicle‑specific handling differs. |
| Upgradability | Low – adding a new fault code or radio feature required hardware changes to the specific terminal, often with long depot lead times. | High – software‑updatable via the TDC. A single software update adds new features across all four display modules simultaneously. |
(Source: UIC 612‑0, Clause 1; Siemens Mobility, 2023; Stadler Rail, 2022; ERA, 2016)
✍ Editor’s Analysis
Where the 2009 umbrella meets 2025 realities – FRMCS and Level 3 ETCS. The current edition of UIC 612‑0 was published in 2009, based on GSM‑R as the only radio bearer and ETCS baseline 2.3.0. The railway world has moved on. The Future Railway Mobile Communication System (FRMCS) will introduce broadband data, video calls, and real‑time telemetry. This requires adding at least one new display module (e.g., “Broadband Data Display” or “Video Link”) to the DDS architecture, which is not yet defined in 612‑0. Moreover, ETCS Level 3 (moving block) changes the nature of the movement authority, potentially requiring the CCD to display “virtual train integrity” information. The next revision of UIC 612‑0 (expected 2026‑2027) will need to accommodate these new functions without breaking the existing four‑module architecture. The UIC working group has already proposed a “modular extension” framework, allowing operators to add custom modules (e.g., “Freight Load Monitor”) while retaining the core arbitration and state logic. (Source: ERA, 2023; FRMCS System Requirements Specification, UIC, 2023; UIC DDS Working Group, 2024)
The industry debate: Physical hard‑keys vs. soft‑keys for safety‑critical functions. The 2009 leaflet assumes that most DMI inputs will be via softkeys (physical buttons adjacent to the screen) or touch‑screen. However, a decade of operational experience has shown that drivers strongly prefer physical, dedicated hard‑keys for the most critical functions: emergency brake, GSM‑R emergency call, mute, and train running number entry. In response, the ERA’s ERTMS 015560 (2023 update) now mandates that the ETCS DMI must include a hard‑wired emergency brake button and a hard‑wired “Acknowledge” button, independent of the touch‑screen or softkey interface. The next revision of UIC 612‑0 will likely align with this requirement, specifying a minimum set of hard‑keys (at least 5) and their positions on the desk. Some manufacturers have already implemented “dual‑mode” desks with both softkeys (for menu navigation) and hard‑keys (for safety functions), which is likely to become the standard. (Source: ERA ERTMS 015560, Clause 4.2.6; Siemens Mobility, 2023; DB Systemtechnik, 2022)
Limitation: No standardisation of the TDC‑TCMS interface for diagnostic data. While UIC 612‑0 defines the functional behaviour of the TDD (Technical Diagnostic Display), it does not specify the protocol or data format between the TDC and the train’s TCMS (Train Control and Monitoring System). In practice, each TCMS manufacturer (e.g., Knorr‑Bremse, Faiveley, Siemens) uses a proprietary protocol (often based on CANopen or MVB). The TDC must implement a translation layer for each TCMS type, increasing project cost and risk. The next revision of the leaflet should reference a standardised diagnostic data model, such as the IEC 61375‑2‑3 (Train Communication Network – TCN) diagnostic profile or the Shift2Rail “Open TCMS” specification. This would allow a TDC to receive and display fault messages from any TCMS without customisation, dramatically reducing integration costs. (Source: IEC 61375‑2‑3:2017, Clause 7; Europe’s Rail, “Open TCMS White Paper”, 2024; Knorr‑Bremse, 2023)
— Railway News Editorial
Frequently Asked Questions (FAQ)
1. What is the exact difference between UIC 612‑0 (the umbrella standard) and UIC 612‑01 (general requirements)?
UIC 612‑0 is the system‑level functional requirements specification for the entire harmonised Driver Machine Interface (DMI). It defines the high‑level architecture (Train Display Controller, arbitration between display modules, global train states, priority levels) and applies to all cab‑equipped rail vehicles. UIC 612‑01 (“General Requirements, Set‑Up and Technical Specifications”) is a subordinate leaflet that focuses specifically on the Driver Display System (DDS) hardware and its integration into the cab. It details the physical characteristics of the display(s), input devices (softkeys, touch‑screen), environmental qualifications (vibration, temperature, EMC), and the technical interface between the DDS and the TDC. In short: 612‑0 defines what the DMI must do functionally; 612‑01 defines how the display hardware is built and integrated. A vehicle claiming full compliance must meet both 612‑0 (functional) and 612‑01 (technical) requirements, plus the module‑specific leaflets (612‑02 to 612‑05) for each display module present. (Source: UIC 612‑0, Clause 1; UIC 612‑01, Clause 1; Normadoc, 2025)
2. Is a Train Display Controller (TDC) mandatory for all vehicles claiming UIC 612‑0 compliance?
Yes, Clause 7.1 of UIC 612‑0 states that “a Train Display Controller (TDC) shall be provided to manage the arbitration, prioritisation and routing of information between the display modules and the physical display units”. However, the leaflet allows two implementation approaches. In a centralised TDC architecture, a single hardware unit (often a ruggedised industrial PC) receives data from the ETCS on‑board computer, GSM‑R radio, TCMS and journey database, then generates the video output for all displays. In a distributed TDC architecture, each display module (CCD, TDD, TRD, ETD) has its own processor, but a separate arbitration unit (TDC‑A) manages priority and screen switching. The distributed approach is more fault‑tolerant (failure of one module does not affect others) but more expensive. The leaflet does not mandate a specific architecture, only the functional behaviour: the TDC must ensure that a P0 (safety‑critical) message pre‑empts any P1 or P2 content within 200 ms. (Source: UIC 612‑0, Clause 7.1; CLC/TR 50542‑1:2025, Clause 4.1; Siemens Mobility, 2023)
3. How does UIC 612‑0 handle the transition between ETCS Level 1 (lineside signals) and Level 2 (cab signalling) on the DMI?
The leaflet defines a mode‑dependent behaviour for the CCD. When the train is operating in ETCS Level 2 (cab signalling active, no lineside signals required), the CCD must be the primary source of movement authority. The driver must not be required to look at lineside signals (though they remain as a backup). When the train is in Level 1 (or national legacy systems like PZB/KVB where lineside signals still apply), the CCD must display the same information as the lineside signals, but the driver may also view the lineside signals directly. The leaflet also specifies that when the train transitions from Level 2 to Level 1 (e.g., at the end of an ETCS‑equipped line), the DMI must automatically change the CCD’s layout to show the additional information (e.g., signal distance, balise group ID) required for Level 1 operation. The transition must be seamless and not require driver intervention, except for the mandatory “Level Transition Acknowledge” button. (Source: UIC 612‑0, Clause 6.4; Subset‑026, Clause 3.13; ERA ERTMS 015560, Clause 4.2.2)
4. Can a vehicle be equipped with only the CCD and TRD, omitting the TDD and ETD, and still claim partial compliance?
Yes, UIC 612‑0 explicitly allows modular compliance. Clause 3.2 states that the DMI architecture is modular, and a vehicle may be fitted with only a subset of the four display modules, depending on its operational requirements. For example, a freight locomotive that does not carry passengers may omit the ETD (timetable display) if the operator uses paper timetables, and it may omit the TDD if the operator does not require onboard diagnostics (though this is rare on modern networks). However, the leaflet requires that if a module is present, it must fully comply with the relevant subordinate leaflet (612‑02 for CCD, 612‑03 for TDD, etc.). Also, any vehicle that operates on TEN‑T and is required to comply with the CCS TSI must have at least a CCD (for ETCS) and a TRD (for GSM‑R emergency calls). The leaflet does not permit a vehicle to claim “UIC 612‑0 compliant” if it omits a module that is mandatory under TSI. (Source: UIC 612‑0, Clause 3.2; TSI CCS, Commission Regulation (EU) 2016/919, Annex A, Clause 4.2.13; ERA, 2023)
5. What are the exact requirements for the “HOME” softkey and its behaviour across all DMI modules?
UIC 612‑0, Clause 6.2.5 mandates that the “HOME” softkey (labelled with a standard house icon or the text “HOME”) must be accessible from any screen in the DDS. When pressed, the DMI must return to the home screen (the screen from which the driver selects CCD, TDD, TRD or ETD) within 500 ms. This holds regardless of menu depth (e.g., if the driver is five levels deep in a TDD fault history sub‑menu). The “HOME” softkey must be located in a consistent position – either the bottom‑left or bottom‑right corner of the display (manufacturer’s choice, but fixed across the entire fleet). The leaflet also requires that pressing “HOME” does not cancel or acknowledge any active P0 (safety‑critical) alarm; the alarm remains visible even on the home screen. If the driver presses “HOME” while an ETCS movement authority is displayed, the home screen must appear but the movement authority information must remain visible in a dedicated status bar at the top or bottom of the screen, sized at least 80 × 40 pixels. This ensures the driver never loses safety‑critical information, even when navigating the menu. (Source: UIC 612‑0, Clause 6.2.5; EN 16186‑3:2016, Clause 5.4; ERA ERTMS 015560, Clause 4.2.4)

