ETCS Level 2 projects depend not only on technical compliance, but also on explicit agreement about operational behavior, responsibilities and validation evidence.

ETCS Level 2 is often introduced primarily as a technology programme. Project discussions typically focus on radio block centres, balises, GSM-R or FRMCS migration, interlocking interfaces, onboard units, braking curves and the anticipated capacity benefits. While all these elements are undoubtedly important, they are rarely the only factors that determine whether a project can be implemented smoothly and validated convincingly.

Based on project experience from ESE GmbH, the most relevant challenges in ETCS Level 2 programmes often emerge elsewhere – namely at the interfaces between operations, requirements engineering, safety assurance, testing and contractual or assessment acceptance. It is at these points that projects are most likely to encounter unclear responsibilities, late clarification needs and integration challenges.

A critical topic where unclear assumptions may occur are operational issues where different stakeholders can have different perspectives. The supplier may assume that the infrastructure manager will keep the existing degraded-mode rules. The infrastructure manager may assume that the supplier will implement the operational concept behind those rules. The operator may assume the driver-machine interface will behave like the legacy ATP. The test team may assume the requirement is already covered by Subset-026 compliance. The assessor may assume the project has justified the operational risk elsewhere. Each assumption may be reasonable on its own. Taken together, however, they can create inconsistencies that may affect operational safety, validation effort and acceptance.

ETCS Level 2 is an operating agreement, not only a product

In ETCS Level 2, the Movement Authority is far more than a digital representation of a lineside signal aspect. It results from the interaction of route request, interlocking state, track occupancy, train position reports, RBC logic, national values, braking models, radio availability, driver procedure and fallback operations. The system is safe only when these elements are specified and validated as one coherent railway behavior.

Based on ESE GmbH’s experience, the discipline often missing is not a better explanation of how ETCS works. The challenge lies in requirements engineering and its link to test strategy and V&V, safety assurance according to EN 50126, EN 50128/EN 50716 and EN 50129. Early validation of the operational concept before integration can reveal conflicting assumptions and expectations.

This observation is neither new nor surprising to the requirements and validation engineers at ESE GmbH. ETCS standards provide a common language, but they do not remove the need to define project-specific operational rules. Baseline conformity alone does not determine how a route is released after a shunting move, how an RBC handover is managed at a boundary, how a temporary speed restriction is authorized, or how a driver recovers from the loss of radio supervision in a specific operational context. These are project requirements. If they are not defined explicitly, they will still be implemented, but rarely in a consistent way.

Where the assumptions hide

Many critical assumptions are embedded in the operational concept, where normal, degraded and emergency operation must be defined in clear and measurable terms. Others reside at the interfaces, where responsibilities between the RBC, interlocking, traffic management system, key management, train detection system and radio network must be explicitly allocated. Further assumptions are often hidden in data and configuration management, including ownership of engineering rules, national values, balise data, RBC area boundaries and change control. They also emerge in human procedures, where drivers, signalers, controllers and maintenance staff need clearly defined actions whenever the technical system reaches its operational limits. The challenge is that such assumptions can remain unnoticed even during formal reviews. Project experience from ESE GmbH validation teams shows that a document can be well formatted, numbered and approved, while still not explicitly stating who decides, what evidence is required, what state transition is allowed, or which operational risk is being controlled. That is why assumption management must be treated as engineering work, not as meeting minutes.

The stakeholder dilemma

A classic problem faced by requirements engineers – not only at ESE GmbH – is the stakeholder dilemma. The parties who hold the most operational knowledge are not always the parties who write the requirements. The parties who write the requirements are not always the parties who implement them. The parties who implement them are not always the parties who must prove them safe. In an ETCS Level 2 programme, that separation is enough to create a path for misunderstandings that may remain unnoticed until later project phases.

Consider a tender that may request: “Provide ETCS Level 2, compliant with the applicable baseline, integrated with the existing interlocking and suitable for current operations.” This sentence looks harmless. It is not. It contains several unstated design decisions.

What does “current operations” mean when the signaling principal changes? Are existing block-release rules retained, replaced, or reinterpreted inside the RBC? Is the traffic management system informative only, or does it trigger route setting? Are temporary speed restrictions entered through an operational tool, through engineering data, or through a safety-controlled workflow? Are fallback operating scenarios designed for capacity, for safety only, or for minimum service?

None of these questions is exotic. They appear in ordinary Level 2 projects. Yet they are often answered informally by the discipline that first encounters the problem. Different disciplines may address parts of the issue separately, which can make it difficult to build a coherent validation argument later on.

~The silent killer is not the known disagreement. It is the agreement that never happened. ~

Why CENELEC assurance does not automatically catch it

The EN 5012x family gives the project a disciplined lifecycle. EN 50126 frames RAMS and lifecycle thinking. EN 50128/EN50716 addresses software development for railway control and protection. EN 50129 expects a convincing safety case for safety-related electronic systems. These standards are essential. But they cannot validate an intention that was never specified.

A safety case can argue, with evidence, that a defined system is acceptably safe. It cannot easily demonstrate that the operational concept selected for a specific project context is complete and appropriate. A verification/validation activity can prove that a requirement has been implemented. It cannot prove that a missing requirement should have existed. An independent assessment can challenge evidence, but it is not a replacement for early, explicit stakeholder agreement.

From the perspective of validation engineers at ESE GmbH, consistent risk-based prioritization is often missing here. Projects spend significant effort on visible compliance items while the high-risk operational assumptions may remain under-analyzed. This is the point where requirements engineering, test strategy and safety assurance must be connected. The hazard log should be linked to the requirement set. Operational scenarios should be treated as an integral part of the engineering and validation approach. The V&V strategy should be developed early enough to inform design maturity. Assessment evidence should be built progressively, so that assumptions are clarified before they become embedded in the project baseline.

The five assumptions that deserve special attention

These five assumptions should not be read as a universal checklist in which every item carries the same weight in every ETCS Level 2 project. They are intended to help each project identify which assumptions require explicit clarification and evidence. In some projects, an assumption may already be closed by the operational concept, national implementation rules, baseline configuration, subsystem safety case or contractual scope. In other projects, the same assumption can become a hidden safety risk if it remains implicit.

In CENELEC terms, the key issue is not whether assumptions exist, but whether they are visible, allocated, validated and carried through the lifecycle. Where an assumption influences operational behavior, degraded-mode strategy, interface logic, engineering data, test coverage or safety argumentation, it should be traceable to a responsible party and supported by engineering or operational evidence.

The following areas therefore deserve early attention, particularly in migration, overlay, degraded-mode and multi-party integration contexts:

1. Boundaries: Where does one RBC area end, where does another authority begin, and what is the operational state during transition?
2. Degraded mode: What service level is permitted after radio loss, train detection failure, OBU failure or RBC unavailability?
3. Responsibility split: Which project party is accountable for the decision, which parties provide the required engineering or operational evidence, and which bodies assess, accept or authorize it — for example the infrastructure manager, railway undertaking/operator, supplier, maintainer, independent assessor or national safety authority?
4. Data validity: What evidence proves that engineering data is complete, consistent, version-controlled and installed in the correct target system?
5. Test coverage: Which scenarios prove integrated behavior rather than isolated compliance with one requirement at a time?

How to make assumptions visible before they become defects

The cure is not to write more requirements. Many projects already have too many. The cure is to write the missing requirements, in the right architecture, with the right evidence. A useful Level 2 requirement set separates system requirements, subsystem requirements, interface requirements, operational requirements, safety requirements and test requirements. It then connects them by traceability, not by hope.

One practical technique is an Assumption Register. It should not be a risk register in disguise. It should record every material assumption that affects architecture, operations, safety, testing, migration or acceptance. Each assumption needs an owner, a decision date, a validation method and a downstream impact if false. The question is not “Do we believe this?” The question is “What breaks if this is wrong?”

A second technique is an Operational Scenario Catalogue. The catalogue should cover normal operation, RBC handover, Start of Mission, level transition, temporary speed restrictions, Staff Responsible (SR) mode, shunting interface, possession, emergency stop, evacuation, recovery after loss of radio supervision, and maintenance access. Each scenario should be linked to the relevant requirements, hazards, interfaces, operating rules and test cases. If a scenario has no corresponding requirement, the project has probably found an unspoken assumption. If a requirement has no corresponding scenario, the project has probably found a paper requirement rather than a validated operational need.

A third technique is early requirements-based simulation or model-based validation. The objective is not to replace engineering judgment. It is to expose contradictory preconditions, missing states and inconsistent timing before they lead to late clarification needs or rework during commissioning. In safety-critical railway work, early discovery helps improve project stability, integration quality and confidence in the validation approach.

What these changes mean for V&V and assessment

A strong V&V strategy for ETCS Level 2 starts from risk and operation, not from a late list of factory tests. It defines which behaviors must be demonstrated by review, analysis, simulation, laboratory test, field test and operational trial. It also defines negative test evidence: combinations of states that must not occur, interfaces that must fail safely, and degraded modes that must not depend on undocumented human improvisation.

For the independent assessor, the most valuable evidence is not a large document pack at the end. It is a visible chain from operational risk to requirement, from requirement to design, from design to test, and from test result to safety argument. This chain is what turns CENELEC compliance from a documentary exercise into real safety assurance.

Successful requirements engineering and validation support in the railway sector, as services offered by ESE GmbH, therefore require more than just a methodical approach. It requires domain knowledge, operational judgment, safety-case awareness and the discipline to ask clarifying questions before design decisions become difficult to adjust.

Conclusion

ETCS Level 2 projects do not rely on technical expertise alone. They can become challenging when the project relies too long on assumptions that were never explicitly stated, allocated, validated or controlled. In this sense, assumption management is not a secondary project-management activity. It is a core engineering discipline that directly affects requirements quality, system integration, V&V planning and the credibility of the safety case.

The practical lesson is therefore clear: every ETCS Level 2 implementation should treat assumptions with the same seriousness as requirements, hazards and interface definitions. If an assumption influences operational behavior, degraded-mode strategy, RBC logic, interlocking interaction, driver procedures, test coverage or safety argumentation, it must be made visible. It needs an owner, a decision path, supporting evidence, traceability to requirements and a defined method of validation.

From the perspective of requirements engineers working in the railway sector, this is where many projects can gain control earlier. Supporting customers in this area is one of ESE GmbH’s core areas of expertise, particularly in requirements engineering, traceability, validation strategy and lifecycle assurance. Assumption management helps the project move from informal understanding to explicit agreement, including agreement on what must be validated, by whom, with which evidence and against which acceptance criteria. It forces stakeholders to clarify what the railway is meant to do, how it is allowed to fail, who owns each decision and how the final behavior will be proven before commissioning pressure begins.

So before asking whether the RBC is ready, whether the OBU is certified, whether the test lab is booked or whether the safety case is complete, the project should ask a more fundamental question: which assumptions are still carrying the implementation?

If the answer is unclear, the project may already carry an unnamed risk. A disciplined assumption management approach is the mechanism that gives that risk a name, assigns responsibility for it and helps prevent it from becoming a late integration issue, an unresolved validation question or an incomplete safety argument.