The rail sector is undergoing a profound transformation. Initiatives such as the ETCS Level 2 rollout and the migration to digital interlocking systems are intended to increase capacity. In practice, this involves complex coordination across multiple disciplines regarding issues such as how to handle a specific malfunction:

“Should the train be allowed to continue automatically, or should it be brought to a safe stop?”

Operations focus on availability, planning on system robustness, and development on safety logic. What may seem like a minor detail can later have system-wide implications as various experience of teams at ESE GmbH – e.g. concerning requirements engineering and validation management – has shown.

This is precisely where it becomes evident how profoundly the railway system has changed. What used to be a self-contained interlocking system is now a system of systems comprising rolling stock, infrastructure and signalling and safe control technology. If interactions remain unclear or contradictory, this leads to rising costs, delays, and service that falls short of user and operator expectations.

But why do such fundamental problems only become apparent once the technology has already been developed?

We at ESE GmbH came to the conclusion that from a requirements engineer’s perspective, the answer to this question is rarely technical. Most problems do not arise during coding, verification, or commissioning. Typically, the causes lie in very early project phases, such as vaguely worded specifications, implicit and unvalidated operational assumptions, and formally defined interfaces that are interpreted differently in terms of content. Added to this are requirements that appear logical when viewed in isolation but are not coherent when considered jointly.

Thus the real complexity of modern signaling projects lies not in the technology itself, but in the early phase of requirements definition and system scoping.

Or, to put it more bluntly:

We rarely build the wrong thing wrong. Rather, we build the wrong thing right.

This insight is to the team of requirements engineers at ESE GmbH neither new nor surprising. What is new, however, is the extent to which unclear requirements have an impact today. Because the systems are so closely interlinked, errors are amplified throughout the entire project chain.

The Gap: Operational Concepts vs. Technical Specifications

From the perspective of requirements engineers of ESE GmbH, one of the causes often lies in a discrepancy between the involved worlds. It arises where different disciplines meet that pursue the same goal but do not speak the same “language”. Railway operations focus on schedules, capacities, and real-world scenarios such as driving on sight, while signalling and control rely on interlocking logic, block structures, and braking curves.

The challenge is translating operational requirements into technical specifications without losing meaning and context. This is often underestimated in tenders, where requirements are phrased abstractly, for example ensuring a two-minute headway. Such abstraction can overlook important physical and logical constraints of signalling systems.

In reality, headways depend on factors like block spacing, track geometry, and braking performance. If these are not defined early, a gap emerges between expectations and technical feasibility.

The result is specifications that are formally correct but do not optimally support or may even constrain the intended operations.

The Legacy of the Past: Proprietary Legacy Systems vs. Modern Standards

Another key factor is the technological dilemma facing many railway projects. Existing infrastructure relies on relay-based and older electronic interlocking systems, while at the same time there is a push to migrate to digital and standardized solutions such as EULYNX.

This transformation requires a rethinking of processes and functions, yet existing custom solutions are often carried over. As a result, legacy issues persist and prevent benefits such as modularity and interoperability from being fully realized.

The Stakeholder Dilemma: The Tug of War over the “One-Size-Fits-All” Solution

A classic problem faced by requirements engineers – not only at ESE GmbH – is the stakeholder dilemma. Various stakeholder groups bring forward legitimate but often conflicting requirements.

Operations demand maximum flexibility and minimal headways times to optimize capacity and punctuality. Maintenance wants robust systems with low maintenance effort and comprehensive diagnostics. At the same time, regulatory authorities require complete proof of safety integrity.

The fundamental problem lies not in the individual requirements, but in their lack of integration. In many projects, requirements are simply added together instead of being harmonized. Conflicts of interest, such as those between increased functionality and the complexity of a safety case, are not resolved during the requirements phase but are, unfortunately, forwarded to later project phases.

And this is where a structural shortcoming becomes apparent, the absence of a true system integrator at the requirements level. An entity that not only collects requirements but also prioritizes, evaluates, and consistently integrates them into a cohesive system.

The Overengineering Problem: Excessive Complexity in Signalling Systems

Another critical aspect is the tendency toward overengineering. In the pursuit of high functional safety, rare extreme cases are specified as mandatory requirements, creating a trade-off with availability.

While additional safeguards, special logic, and fallback mechanisms may increase functional safety, they also increase system complexity and can indirectly reduce availability. For example, if a specification requires handling simultaneous failures of multiple components, this leads to complex mechanisms that are rarely needed but increase susceptibility to errors as well as testing and operational effort.

From the perspective of  requirements engineers at ESE GmbH, consistent risk-based prioritization is often missing here. Without a clear balance between safety and availability requirements become overloaded, resulting in systems that are neither optimally available nor efficiently manageable.

What does the future offer?

To get a handle on the problems described above, the early project phases shall be reorganized. The key to success lies in professional, future-proof requirements engineering.

One key success factor is the use of Model-Based Systems Engineering (MBSE). Consistent system models replace traditional, text-based specifications in Word or Excel. This makes requirements not only unambiguous but also verifiable at an early stage.

At the same time, CENELEC-compliant requirements engineering must be embedded from the very beginning. Safety assurance in accordance with EN 50126/128/129/176 should not be viewed as a downstream documentation task but must guide the structuring of requirements from day one. Methods such as HAZOP analyses in the concept phase help to systematically identify risks and derive requirements on risk-based basis. This results in a robust safety case as an integral part of the system, rather than a later addition.

Furthermore, the definition phase must become more agile. Through early prototyping, software emulators, or interactive mock-ups, rapid feedback loops shall be established between train dispatchers, planners, and signalling manufacturers. Operational restrictions are thus identified and corrected as early as the design phase.

Finally, the project needs a new key role, the Chief Requirements Engineer. This role serves as a bridge between operations, engineering, and regulatory authorities. Equipped with a clear right of veto, they have the final say over the requirements specification and the courage and authority to consistently eliminate costly overengineering.

Conclusion

To conclude, the chronic failure of modern signalling projects is rarely a software or hardware issue. It is the measurable result of a structural shortcoming in the requirements phase.

If large-scale projects such as the trans-European ETCS Level 2 corridors are to be completed on time and within budget, the rail industry must learn to formulate requirements in a more functional, standardized, and confident manner. Successful requirements engineering which is offered by ESE GmbH in the railway sector therefore requires more than just a methodical approach. It requires systems thinking, clear prioritization, and the courage to consciously limit complexity. In this way, requirements engineering is no longer a bureaucratic end in itself, but rather the decisive factor for success.