Testing Interlocking and ETCS Interfaces Before Railway Commissioning

Before a railway enters service, every interface between the interlocking and the European Train Control System (ETCS) must be tested to confirm that safety-critical information is exchanged correctly. For quality control and safety teams, overlooked interface defects can lead to commissioning delays, costly rework, or operational risk. This article examines how structured interface testing, traceable requirements, and evidence-based verification support railway system integration services and help teams prepare for a safer, more reliable commissioning process.

The challenge is not simply to prove that two systems can communicate. A valid message may still contain the wrong route status, refer to the wrong track section, arrive too late for its intended use, or be interpreted against a different version of the infrastructure data. Commissioning evidence therefore needs to show that information is correct in context—and that the railway responds safely when that context changes.

Where interlocking and ETCS meet

The interlocking controls and supervises routes using information from trackside equipment and other connected systems. ETCS uses infrastructure and train-related information to supervise train movements. Depending on the ETCS application and system architecture, an interlocking may exchange data with a Radio Block Centre (RBC), while balises provide trackside information to trains. The exact allocation of functions differs between projects and ETCS levels.

In an RBC-based deployment, one question might be whether a confirmed route and its associated conditions are represented correctly in the information used to establish or update a movement authority. That does not mean the interlocking itself necessarily creates the ETCS movement authority. Teams should test the actual functional chain defined by the design, rather than assume a universal division of responsibility.

The interface is wider than a communication link. It includes message definitions, application logic, infrastructure topology, operational rules, time-dependent behaviour and configuration management. A defect in any one of these can make a technically healthy connection unsafe or unusable.

Start with a controlled interface baseline

Before drafting test scripts, establish exactly what is being integrated. A test executed against an outdated data set may be repeatable and still provide little evidence for the system intended for service. The baseline should identify the relevant interlocking and ETCS software versions, trackside configuration, interface specifications, operational assumptions and test-environment limitations.

An interface control document is useful only if the teams on both sides treat it as a controlled agreement. For each exchanged item, reviewers should be able to identify its source, meaning, destination, permitted states and treatment when it is missing, inconsistent or no longer valid. Particular attention is needed where one supplier’s terminology does not map neatly onto another supplier’s data model.

For example, a “route available” indication should not be accepted at face value without checking what conditions make it available, which route identifier it refers to, and how a subsequent change is reported. The same discipline applies to point positions, track occupancy, route release and restrictions, where these are exchanged or used by the project’s design.

A practical baseline review should also resolve the boundary between simulated and physical equipment. If a laboratory substitutes a simulated track circuit or axle counter, the test record must say what the simulator represents and which field behaviours it cannot demonstrate. Otherwise, a successful laboratory result can be mistaken for proof of the whole installation.

Turn requirements into testable evidence

A traceability matrix should connect each relevant interface requirement to its source, design implementation, test procedure, expected result and recorded outcome. Safety requirements should also link to the hazard record and the evidence used to support their acceptance. This makes gaps visible before the commissioning team is under pressure to close paperwork.

Traceability is not a substitute for sound test design. A requirement such as “the system shall process route information safely” is too broad on its own. The team needs observable conditions: the initial track and route state, the input or event, the expected interface behaviour, the relevant timing criteria and the evidence to be captured. Acceptance limits must come from the approved project requirements, not arbitrary values chosen for the test.

Consider a representative sequence in which a route is established and subsequently becomes unavailable. A useful test checks the sequence of state changes across the interlocking, interface and ETCS functions, then compares them with the approved design. It also checks what happens if the change occurs while a train movement is being processed. The expected response depends on the architecture and operational context; it should be specified before the test, not inferred from whatever the equipment happens to do.

Test the exceptions, not just the successful route

Normal-operation tests demonstrate that the intended service can be delivered. They do not, by themselves, demonstrate that conflicting, delayed or absent information is handled appropriately. Interface test planning should include abnormal conditions derived from the hazard analysis and the project’s failure assumptions.

• Communication interruption: Verify detection, indications, safe reactions and recovery for the defined loss-of-link scenarios. Check whether stale information can remain in use beyond its permitted validity.
• Invalid or inconsistent data: Inject malformed, out-of-range or contradictory inputs where the test environment permits, and verify the specified rejection or safe handling.
• Changes during processing: Exercise route cancellation, occupancy changes or point-status changes at relevant stages of the operational sequence.
• Restart and resynchronisation: Check what each subsystem assumes after a restart, how current state is re-established, and whether an operator action is required.
• Degraded operation: Verify the interface behaviour and associated operational controls for the degraded modes included in the approved design.

Failure injection should be controlled. Testers need to know whether a fault is introduced at the application, communication or equipment level, because each method exercises a different part of the safety chain. They also need a safe means of restoring the configuration and confirming that the injected fault has been removed.

Timing and sequence deserve their own review

Many interface defects appear only when events occur close together. A message can be correct in isolation yet arrive after the state it describes has changed. Testers should therefore compare timestamped records from the relevant systems and examine event ordering, timeouts and state transitions against the specified limits.

Clock synchronisation matters for diagnosis, even where it is not itself part of the safety function under examination. If logs cannot be correlated reliably, a team may struggle to distinguish a genuine sequencing defect from a recording artefact. Record the clock source, known offsets and any limitations in the evidence package.

Use laboratory and site testing for different purposes

Laboratory integration is well suited to repeatable scenarios, fault injection and regression testing. It allows teams to investigate combinations of events that may be difficult or disruptive to reproduce on an operational railway. Its strength is control; its weakness is that models, simulators and test configurations may differ from the installed environment.

Site testing provides evidence about the installed configuration and its interaction with physical infrastructure. Depending on scope, this can include checks of data loading, equipment identity, trackside interfaces, communications coverage and end-to-end operational scenarios. Testing with an appropriately equipped train may be needed to confirm behaviours that cannot be established adequately through simulation alone.

Neither stage should be treated as a complete substitute for the other. A useful test strategy states which requirements are covered in the laboratory, which require site confirmation and where both forms of evidence are necessary. It also defines safe access, possessions or other operational controls required for field work under the applicable local arrangements.

Standards provide a framework, not a ready-made test script

ETCS specifications and interoperability requirements establish a technical framework, but the applicable baseline and implementation rules must be identified for the project and jurisdiction. In Europe, the relevant Technical Specifications for Interoperability and referenced ETCS specifications should be checked in their applicable versions, together with national requirements and any authorised project-specific provisions.

The EN 50126 series addresses railway RAMS processes; EN 50128 and EN 50657 concern software for railway control and protection systems in their respective scopes; and EN 50129 addresses safety-related electronic signalling systems. Applicability, edition and contractual obligations need confirmation rather than assumption. Communication-related standards, including EN 50159 where applicable, may also be relevant to the safety argument for transmission systems.

Conformance to an applicable specification, component certification or a supplier’s test report can provide valuable evidence. None automatically proves that a particular interlocking, RBC, infrastructure data set and operational arrangement work together safely. Integration evidence must address the assembled system and the interfaces actually delivered.

Manage changes as a commissioning risk

Late changes are not limited to software. A revised track layout, renamed object, altered route table, balise data update or change to an operational restriction can invalidate an earlier result. The quality team should require each change request to identify affected requirements, configuration items, hazards and previously completed tests.

Regression scope should follow the impact, not a generic percentage of the test suite. A change to a shared interface mapping may require broader retesting than a change confined to an isolated display. Conversely, a seemingly small data correction can affect several routes if that data is reused. The decision and its technical rationale belong in the controlled record.

Defect closure deserves the same scrutiny. A supplier’s statement that an issue has been corrected is not equivalent to an accepted fix. The record should identify the installed version, the root cause or known limitation, the retest result and any residual operational restriction. Open defects should have an owner, an assessed safety impact and an explicit disposition before service entry.

What a credible handover should contain

Commissioning readiness is a decision based on the complete evidence, not a count of passed test cases. Reviewers should be able to reconstruct the tested configuration, trace results to requirements, see which tests were witnessed or independently assessed where required, and understand any deviations from the plan. Logs, test reports and defect records should be consistent with the final delivered baseline.

The handover should also make operational assumptions visible: procedures for degraded working, maintenance responsibilities, known limitations and arrangements for future changes. If a safety measure depends on a human action, the relevant procedure and training evidence need to be available to the parties responsible for operating the railway.

Global Railway-Freight & Engineering (G-RFE) approaches signalling in the context of the wider railway system, where infrastructure, communications and rolling stock must be considered together. For a commissioning review, that perspective is useful when checking whether an apparently local interface change has consequences elsewhere in the operating chain.

Before accepting the final integration package, ask a direct question: can each safety-relevant interface behaviour be tied to an approved requirement, a representative test configuration and an unambiguous result? Where the answer is incomplete, identify the missing evidence and its owner before the commissioning window makes that gap harder to resolve.