Figure 2: Program phase gates and freeze points across the Project, Configuration Authority and Operator swim-lanes.

ETCS Transition Zone Governance

An ETCS Level 2-to-conventional transition must not be reduced to a drawing showing a single transition balise. It involves trackside ETCS, onboard ETCS, the RBC, the interlocking, train detection, radio, balises, odometry, the DMI, driver actions, conventional signalling and operating rules. Every element is a controlled CI whose change can affect safety.

Packets 41 and 46 of SUBSET-026, the Level Transition Order and the Conditional Level Transition Order — define how the transition is commanded. Their content, telegram placement distances, braking assumptions, acknowledgement timing and marker board arrangements are application-specific engineering outputs. They are not universal values that can be copied from another route. A telegram dataset copied from a different route, with different positioning references and a different interlocking application, can pass laboratory testing and fail in field conditions.

A change to a balise telegram requires regeneration from the approved source dataset, independent checking and reconciliation before the site can be used again. The re-test matrix requires that any change to Packet 41 or 46 content normally triggers laboratory packet validation, an onboard scenario test and a transition SIT. Approving “no re-test required” on a safety-significant change requires independent review of the impact assessment rationale. Mixed-fleet operation adds a fleet-compatibility matrix covering vehicle class, onboard software version, Balise Transmission Module (BTM) and antenna arrangement, odometry configuration, braking data, Specific Transmission Module (STM) or National Train Control (NTC) capability and approved routes. An ETCS-fitted train is not automatically compatible with every transition it encounters.

Configuration Status Accounting

The operator CSA model maintains three governed views. The Operational/As-Built view records the configuration accepted and authorised for use. The Construction/As-Designed view records the approved configuration a project is authorised to construct or modify. The Test/As-Tested view records the exact configuration present when verification occurred. These three states must not be collapsed into a single “current revision” field.

The CSA database covers CIs, functional positions, installed instances, versioned components, baselines, requirements, interfaces, changes, test events, defects, hazards, documents, concessions, CVRs, operational restrictions, competency records and maintenance objects. The operator dashboard provides counts of matched, missing and conflicting CIs; open safety-critical and safety-related defects; ETCS dataset versions; fleet compatibility status; transition-zone freeze status; and pending regression tests. Every count must be drillable to records and evidence.

Defects, RAMS and Handover

Defects are classified as Safety Critical (SC), Safety Related (SR) or Non-Safety (NS). An SC defect has caused or could credibly cause loss of a safety function, an unsafe movement authority, loss of protection or invalidation of a safety claim. The immediate response is to stop the affected test or work, isolate or prohibit operation, and notify the Safety Authority and operator. An unclassified defect is treated as SC until classification is complete. Regression assessment is mandatory for any change to safety requirements, interfaces, software, firmware, ETCS packets, telegrams, RBC or interlocking data, operating rules or cybersecurity patches.

The framework requires bidirectional traceability from operational need through system requirement, safety requirement, hazard control, CI allocation, design, verification, test result, defect or concession, safety-case claim and operational condition. SIL is allocated through hazard and risk analysis applied to specific functions. The program must not assign SIL 4 universally to all ETCS-associated items.

The handover package is evidence of genuine operational readiness, not a document delivery exercise. It includes approved as-built drawings, the CI and asset register, the software and application-data register with checksums and release notes, the safety case and application conditions, defect and concession status, FAT, SAT, SIT and trial records, FCA and PCA reports, CVRs, O&M manuals, maintenance plans, competency materials, spares, calibration requirements, the cybersecurity case and CMMS records. Competency records must be configuration-specific: the system, route, fleet, software and DMI version, transition configuration and degraded scenarios covered. Training against a different DMI layout or mode trajectory is a competence gap that must be controlled before operational use.

Rolling-Wave Delivery and Governance Integrity

The program operates on a rolling-wave model. Projects are staggered so that common L0 decisions precede dependent project freezes. Lessons from early projects are introduced through controlled program changes rather than informal copying. Each wave includes a learning review covering baseline changes, recurring defects, interface failures, possession performance, fleet compatibility, cybersecurity issues and standards interpretations.

Possessions require a Possession Configuration Record covering limits, protecting controls, signalling isolations, temporary equipment, TSRs, staged commissioning sequence, pre-work safe state, test state, post-work state, rollback state, decision times and handback evidence. Rollback must be a designed, resourced and rehearsed configuration, specifying the decision authority, latest decision time, predecessor baseline, physical reinstatement tasks, software and data restoration, and the recovery plan.

The entire program operates within one architecture, one CI taxonomy, one standards register, one three-state CSA model and one operator acceptance process. A project that adopts its own numbering scheme, a different version of a standard or a separate CSA record represents a governance failure the program must detect and correct before handover.

Conclusion

Configuration management on a large rail program is an engineering discipline that preserves a demonstrable relationship among requirements, architecture, interfaces, assets, software, application data, tests, hazards, defects and operational acceptance. When that relationship breaks down because a field change was not recorded, a telegram was updated without re-entering the release process, or an operational baseline was promoted before the CVR was complete — the operator manages a railway whose configuration they cannot fully account for.

The framework places the operator as the owner of the Operational/As-Built truth, holds projects accountable for accurate Construction/As-Designed and Test/As-Tested evidence until formally accepted, and requires the Configuration Authority to reconcile those states without substituting administrative completeness for technical verification. For ETCS programs, no generic transition arrangement is universally safe. Every packet, telegram, balise placement, RBC logic set, DMI configuration and mode trajectory is an application-specific engineering output controlled as baseline data for the route, fleet and operating rules to which it applies.

A useful test of whether governance is working is whether auditors can answer these questions from controlled records: What is operating now? Who accepted it and when? What design was authorised? What was physically installed? What exact configuration was tested? Which requirements and hazards does it satisfy? Which defects, concessions and restrictions remain? Can the prior safe configuration be restored? Failure to answer any of those from the authoritative record is a configuration-governance nonconformity.

References

[1]  ISO 10007:2017 — Quality management systems — Guidelines for configuration management.

[2]  ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes.

[3]  EN 50126-1:2017 — Railway applications — The specification and demonstration of RAMS.

[4]  EN 50129:2018 — Railway applications — Safety-related electronic systems for signalling.

[5]  EN 50128:2011+A1:2020 — Software for railway control and protection systems.

[6]  ERA, SUBSET-026 v3.6.0 — ERTMS/ETCS System Requirements Specification.

[7]  ERA, SUBSET-040 v4.0.0 — ERTMS/ETCS Dimensioning and Engineering Rules.

[8]  ERA, SUBSET-041 v4.0.0 — Performance Requirements for Interoperability.

[9]  ERA, SUBSET-091 v3.6.0 — Safety Requirements for Levels 1 and 2.

[10]  ARISO (formerly RISSB), AS 7711:2018 — Signalling Principles.

[11]  ARISO (formerly RISSB), AS 7717:2016 — Signal Testing and Commissioning.

[12]  ONRSR — Interoperability of Railway Operations. Office of the National Rail Safety Regulator.

[13]  IEC 62443 series — Industrial-process measurement, control and automation network security.

[14]  CLC/TS 50701:2021 — Railway applications — Cybersecurity.

About the Author: Rahiman Shaik is a railway systems specialist with more than 27 years of experience in signalling, ETCS, CBTC, testing & commissioning, systems and operational integration, configuration governance, and programme management. The views expressed in this paper are solely those of the author.