Developair, represented in Israel by ITEC, highlights a critical yet often overlooked cause of delays in safety-critical railway systems: ambiguous low-level software requirements.
While railway safety risks are usually associated with hardware failures, human error, or infrastructure degradation, in recent years, unclear requirements in control system software have emerged as a major disruption factor. A clear example can be found in the rollout of the European Rail Traffic Management System (ERTMS)—specifically its core signaling component, the European Train Control System (ETCS). Designed to unify and modernize signaling across Europe, ETCS deployment was hindered by interoperability failures, repeated delays, and mounting integration costs.
The Promise and the Problem of ETCS
ETCS replaces multiple national train protection systems with a standardized control framework, improving both safety and operational efficiency. With several operational levels—from Level 1’s trackside balises to Level 2’s continuous radio-based supervision—its architecture is designed for flexibility.
However, decentralized implementation meant that dozens of suppliers developed onboard units, trackside infrastructure, and central systems based on their own interpretations of the same specifications. The lack of precise, unambiguous definitions resulted in inconsistent implementations—despite all vendors claiming compliance with the same requirements.
Where the Specification Fell Short
The ETCS System Requirements Specification (SRS) provided a broad natural-language definition of system behaviors but left several critical aspects open to interpretation:
Level Transition Behavior – Timing constraints, fallback modes, and error handling for transitions between ETCS levels were vaguely defined, leading to inconsistent vendor implementations and failed interoperability tests.
Mode and State Transitions – Without precise transition rules, systems either failed to upgrade modes when safe or downgraded too early, creating operational inefficiencies.
Braking Curve Discrepancies – Variations in tolerance, rounding, and environmental input handling caused differences in braking performance, affecting safety and train spacing.
The consequences included multi-year project delays in several European countries, failed certifications, and significant cost overruns.
Industry Response
To address these issues, the industry introduced:
Refined Requirements – Updates to ETCS Subset-026 and Subset-034 with explicit behavioral definitions.
Formal Methods & Model-Based Design – Use of formal specifications and modeling tools to define and validate behavior before implementation.
Model-Based Testing – Structured test cases derived from formal models to detect ambiguities early.
Updated Baselines – New ETCS baselines with greater clarity and testability.
Rely – A Structured Language for Clarity
Developair’s Rely language was created to remove ambiguity from safety-critical software requirements. Inspired by the EARS methodology, Rely combines the readability of natural language with the precision of formal methods.
Key features include:
Single, unambiguous interpretation for each requirement.
Scenario-based syntax (WHEN / IF / THEN).
Built-in support for timing, constraints, and state transitions.
Automatic parsing, simulation, and testing of requirements.
How Rely Could Have Prevented ETCS Failures
Clarifying Timing & Transitions – Converts vague instructions into precise definitions (e.g., “Idle state for 50 cycles → transition to Standby”).
Standardizing Mode Transitions – Ensures uniform conditions and outcomes across all implementations.
Consistent Safety-Critical Computations – Defines exact formulas, tolerances, and rounding methods to prevent performance discrepancies.
Powered by a Generative AI assistant, Rely can also transform informal natural-language specifications into formal, verifiable requirements—reducing ambiguity, streamlining authoring, and ensuring consistency across the lifecycle.
