What is the difference between EN 50128 and EN 50657?

EN 50128:2011 covers software for railway control and protection systems (trackside signalling, interlockings, ETCS sub-systems, traffic regulation, central control rooms). EN 50657:2017 covers on-board software on rolling stock that is not classified as signalling: train control, braking, energy management, doors, climate control, passenger information. The two standards share the same methodological backbone (V-model lifecycle, role separation, tool classification, SSIL levels 0 to 4), but they differ in their technical annexes and scope. EN 50128 is the historical reference for signalling software; EN 50657 was published in 2017 to fill the gap that existed on rolling-stock software not tied to signalling, and to stop the forced use of EN 50128 outside its proper scope.

How does EN 50128 relate to IEC 61508?

EN 50128 and EN 50657 are sector-specific railway derivations of the generic IEC 61508 framework on functional safety of electrical, electronic and programmable electronic safety-related systems. IEC 61508 serves as the umbrella standard for functional safety of any programmable system with a safety purpose; when the railway sector applies that approach, it does so through the CENELEC standards EN 50126 (RAMS process at the system level), EN 50129 (signalling systems and safety functions), EN 50128 (signalling software) and EN 50657 (rolling-stock software). Per the introductory clause of IEC 61508, where a sector standard exists, that sector standard prevails on its sector; railway projects therefore apply the CENELEC family directly, without going back through IEC 61508.

What is an SSIL and how does it compare with a SIL?

SSIL stands for Software Safety Integrity Level. It is defined on a scale from 0 to 4, where SSIL 0 means no safety-related requirement on the software and SSIL 4 the most demanding level. The relationship with the IEC 61508 SIL is conceptual rather than strict: a matching numerical level (SIL 3 vs SSIL 3) reflects an analogous criticality, but SSIL determination flows from EN 50129 at the system level, not from the PFD or PFH tables of IEC 61508. SSIL is not allocated to the software in isolation: it derives from a system-level allocation analysis that takes into account hardware barriers, system architecture, operating environment and RAMS requirements.

What are the standards in the CENELEC railway family?

The CENELEC railway framework rests on four main standards. EN 50126 (in several parts) defines the RAMS process (Reliability, Availability, Maintainability, Safety) at programme and system level. EN 50129 defines the requirements for electronic safety-related systems for signalling, and sets out the SIL allocation procedure at system level. EN 50128 details the requirements for signalling software; EN 50657 the requirements for on-board rolling-stock software. Environmental requirements (railway EMC, climatic, mechanical) for rolling stock are covered by EN 50121 (railway EMC) and EN 50155 (electronic equipment on rolling stock). The set is collectively referred to as the "CENELEC railway family" or "railway standards group".

Which separated roles does EN 50128 require?

EN 50128 requires a strict organisational separation of roles to avoid self-validation bias. The defined roles are the Author (Designer, Implementer), the Verifier (verification of internal consistency of the artefacts of a given phase), the Validator (verification that the finished product meets the specified requirements), and the Assessor (Independent Safety Assessor, independent evaluation of the process and of conformity to the standard). The level of independence required scales with the SSIL: at SSIL 1-2, separation by distinct persons within the same team may be enough; at SSIL 3-4, organisational separation can extend to distinct entities (different departments, even different companies). The Assessor is the most independent role and the Assessment Report is a key deliverable to the national safety authority.

What do the T1/T2/T3 tool classes mean?

EN 50128 classifies software development tools according to their ability to introduce a defect into the final product or to mask an existing defect. T1 designates tools whose output cannot directly affect the executable code (text editor, document management tool). T2 designates tools that verify the conformity of the software but do not produce it (static analyser, test framework). T3 designates tools whose output is incorporated directly or indirectly into the executable code (compiler, code generator, linker, loading tool). The classification drives the level of qualification or validation required: a T3 tool used for SSIL 4 work demands strong confidence (compiler qualification, in-service feedback, restricted usage envelope), whereas a T1 tool requires no specific justification.

How does EN 50128 handle pre-existing software?

Pre-existing Software (PES) refers to any software component not developed specifically for the current project and to the standard: commercial off-the-shelf components (COTS), third-party libraries, code reused from an earlier project, real-time operating systems. EN 50128 provides two routes. The first is to qualify the PES (static analysis, code review, dedicated test set, demonstration based on a documented in-service history, also known as Proven In Use). The second is to confine the PES to a non-critical zone of the system architecture, relying on independent barriers (safety wrapper, external monitoring, diversified redundancy). The choice depends on the allocated SSIL and on the system architecture validated under EN 50129.

How does EN 50128 relate to the EU's 4th Railway Package?

The EU 4th Railway Package, adopted in 2016, harmonises authorisation for placing in service and railway safety certification at European level, through the European Union Agency for Railways (ERA). The Technical Specifications for Interoperability (TSIs) impose harmonised technical requirements on the structural sub-systems: Control-Command and Signalling (CCS), Locomotives and Passenger Rolling Stock (LOC&PAS), Wagons (WAG), Infrastructure (INF), Energy (ENE). Each TSI references the CENELEC family (EN 50126, EN 50128, EN 50129, EN 50657) as a recognised means of demonstrating conformity. For on-board ETCS sub-systems of the ERTMS system, the CCS TSI explicitly mandates EN 50128.

EN 50128 and EN 50657: railway software assurance

Author Hugues Orgitello Last updated 27 May 2026 ~15 min read

Guide · EN 50128 / EN 50657

EN 50128 and EN 50657 are the two CENELEC standards that govern software assurance in European rail: the former for signalling and protection software, the latter for on-board rolling-stock software. Both are sector-specific derivations of the generic IEC 61508 framework on functional safety, and both are referenced as a recognised means of conformity by the Technical Specifications for Interoperability (TSIs) adopted under the EU 4th Railway Package. This page sets out the place of the two standards in the CENELEC family (EN 50126, EN 50128, EN 50129, EN 50657), the Software Safety Integrity Level concept (SSIL 0 to 4), the role separation required, the T1/T2/T3 tool classification, the handling of pre-existing software, and the link with ERA and the ERTMS and ETCS sub-systems.

The CENELEC railway family

The CENELEC railway framework rests on four main complementary standards: a process standard at programme level, a system standard for signalling, and two software standards by domain. The set is referred to as the "CENELEC family" or "railway standards group".

Reference	Scope	Main topic
EN 50126	Railway programme and system	RAMS process (Reliability, Availability, Maintainability, Safety) across the lifecycle; governance framework applicable to any railway project (infrastructure, rolling stock, signalling). Published in several parts (50126-1 generic, 50126-2 safety-specific).
EN 50129	Signalling system	Requirements for electronic safety-related systems for signalling. Sets out SIL allocation at system level, the structure of the Safety Case, architecture requirements (barrier composition, diversity, redundancy).
EN 50128	Signalling software	Requirements for software in railway control and protection systems. Software lifecycle, role separation, recommended techniques by SSIL, tool classification, handling of pre-existing software.
EN 50657	Rolling-stock software	Requirements for on-board software on rolling stock that is not covered by EN 50128 (train control, braking, doors, energy, climate control, passenger information). Same methodological backbone as EN 50128, distinct scope.

Environmental standards (railway EMC EN 50121, on-board electronic equipment EN 50155) complete the framework on hardware and qualification topics, but do not deal with software. The functional boundary between EN 50128 and EN 50657 is set by EN 50129: software involved in a function classified as "signalling" falls under EN 50128; on-board rolling-stock software not classified as signalling falls under EN 50657. The boundary is not always crisp in practice (on-board ETCS raises the question), and its interpretation rests with the national safety authority and the independent assessor.

Relation to the generic IEC 61508 framework

EN 50128 and EN 50657 are sector-specific derivations of IEC 61508. IEC 61508 is the umbrella standard on functional safety of electrical, electronic and programmable electronic safety-related systems, published by the IEC in seven parts (61508-1 to 61508-7). It defines the SIL concept on four levels and provides a generic methodological framework.

The introductory clause of IEC 61508 explicitly states that where a sector standard exists, that sector standard prevails on its sector. For rail, the sector standard is the CENELEC family. A railway project therefore applies EN 50126, EN 50128, EN 50129 and EN 50657 directly, without going back through IEC 61508. Several principles and terms from IEC 61508 nevertheless show through in the CENELEC standards: the SIL scale, recommended techniques by level, the risk-based approach, role separation. Knowing IEC 61508 helps when reading the CENELEC standards, but is not a prerequisite.

Other sectors have produced their own IEC 61508 derivations: ISO 26262 for automotive, IEC 61511 for the process industries, IEC 62061 for machinery safety, EN 50402 for gas detection, EN 50271 for detectors in explosive atmospheres. Rail and automotive are among the two sectors that have most formalised their framework, with explicit independent roles and a fine-grained tool classification. For the generic framework, see the IEC 61508 guide.

Software Safety Integrity Level (SSIL)

EN 50128 and EN 50657 use an SSIL scale from 0 to 4 to characterise software criticality. The SSIL drives the level of rigour required across the software lifecycle: recommended techniques, depth of verification, role separation, level of independence in assessment, requirements on tools.

SSIL	Indicative criticality	Applicable profile
SSIL 0	No safety function	Software not tied to a safety function. No specific requirement from the standard, but compliance with the general quality process (typically ISO 9001).
SSIL 1	Low safety	Software whose failure can contribute to a hazardous situation with limited risk. Internal verification sufficient, light role separation.
SSIL 2	Moderate safety	Reinforced verification, strict Author / Verifier separation within the team, independent assessment recommended.
SSIL 3	High safety	Stronger organisational separation (Verifier and Validator in entities distinct from the Author), formal techniques recommended on critical components, independent assessment required.
SSIL 4	Critical safety	Most demanding level. Maximum independence (Assessor in an entity distinct from the design team), formal techniques strongly recommended, deep qualification of T3 tools, very restrictive handling of pre-existing software.

SSIL is not allocated to software in isolation. It derives from a system-level allocation analysis conducted under EN 50129, which takes into account hardware barriers, redundancy and diversity architecture, and the operating environment. Software whose function is protected by an independent hardware barrier can inherit a lower SSIL than the system SIL of the function. This is one of the architectural levers that avoids having to develop everything at SSIL 4 when the system function is classified SIL 4.

The mapping between SSIL and IEC 61508 SIL is conceptual: a matching number reflects a matching indicative criticality. But rigorous allocation flows from EN 50129 in railway, not from the PFD (Probability of Failure on Demand) or PFH (Probability of Failure per Hour) tables of IEC 61508-1.

V-model lifecycle and covered phases

EN 50128 and EN 50657 impose a V-model software lifecycle, broken down into phases that must be traced, verified and assessed. The phases apply at any SSIL; the intensity of techniques and the depth of verification vary.

Planning: Software Quality Assurance Plan, Software Verification Plan, Software Validation Plan, Software Configuration Management Plan, Software Maintenance Plan. These plans are reviewed before the next phase starts.
Software Requirements Specification (SRS): derivation of software requirements from the system requirements (output of EN 50129), treatment of functional, non-functional and safety requirements.
Software architecture: decomposition into modules, identification of critical and non-critical functions, definition of interfaces, choice of fault tolerance techniques.
Detailed design: module design, algorithm choices, data structure definition, consistency and robustness treatment.
Coding: source code written to defined coding rules (language subsets, prohibitions, restrictions on pointer use, dynamic allocation, recursion).
Module and integration verification: unit tests, integration tests, code coverage (statement, branch, MC/DC depending on SSIL), static analysis.
Software validation: validation of software requirements against the executed code, in a representative environment (simulator, test bench, target platform).
System V&V: conformity of the integrated software to the system, system-level test scenarios.
Deployment and commissioning: software transfer to site, integration, running tests, initial in-service feedback.
Operation, maintenance, modification: anomaly handling, change requests, patches, in-service feedback follow-up.
Decommissioning: phased retirement, eventual transfer of historical databases, dossier archiving.

Each phase produces artefacts (plans, specifications, code, test reports, verification reports) that are kept in the configuration dossier. The full dossier is the input to the Independent Safety Assessor, whose report is itself a deliverable to the system-level Safety Case under EN 50129.

Role separation: Author, Verifier, Validator, Assessor

EN 50128 and EN 50657 impose an organisational separation of roles to prevent any one person or one team from being both judge and party on their own deliverables. Four main roles are defined.

Role	Function	Required independence
Author (Designer / Implementer)	Production of software artefacts: specifications, architecture, design, code, unit tests.	No independence constraint between authors; but strict separation from the Verifier and the Validator.
Verifier	Verification of internal consistency of artefacts in a phase (review, static analysis, verification of requirements vs design, design vs code).	SSIL 1-2: distinct person from the Author, same team allowed. SSIL 3-4: distinct team or department.
Validator	Verification that the finished product meets the requirements specified at the start of the project. Validation by testing in a representative environment.	SSIL 1-2: distinct person from the Author. SSIL 3-4: stronger organisational independence, frequently a distinct department.
Assessor (Independent Safety Assessor, ISA)	Independent evaluation of the process and of conformity to the standard. Assessment Report included in the Safety Case.	Maximum independence. For SSIL 3-4, the Assessor is typically an external entity (separate company), accredited and recognised by the national safety authority.

Independence is not symbolic. It is checked against the project organisation chart, the hierarchical reporting line of staff, and the absence of any direct financial link between the Author and the Assessor on the assessed scope. An Assessor who reports to the same project director as the Author is not independent in the sense of the standard. For SSIL 3-4 on high-stake projects (ETCS, interlockings), the national safety authority can explicitly require an external ISA, sometimes designated from an accredited list.

Tool classification: T1, T2, T3

EN 50128 introduces a classification of software development tools based on their ability to introduce a defect into the final product or to mask an existing defect. The classification drives the level of qualification or validation required.

Class	Definition	Typical examples	Required demonstration
T1	Tool whose output cannot directly or indirectly affect the executable code or the data of the finished product.	Text editor, document management tool, plan writing tool, review tracer, bibliography manager.	No specific justification. Verification of usage and mastery by the team.
T2	Tool that supports verification of the software but does not produce its executable code. A T2 failure can mask a defect without introducing one.	Static analyser, test coverage tool, test case generator, review tool, platform simulator.	Capability demonstration: pinned version, documented configuration, in-service feedback, comparison with an alternative tool, tests on reference cases.
T3	Tool whose output is incorporated directly or indirectly in the executable code or data of the finished product.	Compiler, linker, assembler, code generator (MBSE, UML models), loading tool, FPGA configuration tool if the FPGA contains software code.	Strong confidence demonstration: tool qualification (SSIL 3-4 cases), restricted usage envelope (language subset, pinned compilation options), documented in-service history, or validation by dual execution with a diversified tool.

Classification is established per tool and per project, based on actual use. The same tool can be T2 in one project (static analyser used as a review aid) and shift to T3 in another (where it generates annotations embedded in the binary). The classification is documented in the Tool Qualification Report, a deliverable specific to the software dossier for SSIL 3-4.

For C compilers used at SSIL 3-4, the common practice is to pin a specific version, restrict compilation options to a vetted set, apply a language subset (typically MISRA C with documented exceptions), and provide cumulative in-service feedback (number of projects, lines of code, anomalies attributed to the compiler). Formal qualification of a compiler is still rare; in-service feedback is the most used mechanism.

Pre-existing software (PES)

Pre-existing software refers to any software component not developed specifically for the current project and to the standard. This includes commercial off-the-shelf components (COTS), third-party libraries (FAT/FAT32, TCP/IP, cryptography), code reused from an earlier project, real-time operating systems, and chipset drivers. EN 50128 does not forbid it, but imposes specific handling through two routes.

Route 1, PES qualification. The pre-existing component is analysed as if it had been developed specifically: static analysis, source code review where available, dedicated test set, coverage demonstration, evaluation of the coding rules applied during its original development. For components without available source code (closed libraries, proprietary OS), qualification relies on a qualification dossier provided by the vendor (Proven In Use Argument) which documents cumulative in-service feedback: number of installations, operating hours, reported and handled anomalies, component evolutions. The Proven In Use approach is acceptable depending on the SSIL, the available history and the usage domain analysis.

Route 2, containment. The pre-existing component is contained in a non-critical zone of the architecture, behind independent barriers (safety wrapper, external monitoring, diversified redundancy). The argument is that the failure of the pre-existing component cannot reach the critical function, or that its failure is detected and neutralised by another component developed to the standard. This route is common for real-time operating systems: the RTOS handles task scheduling, but the critical function is encapsulated in a supervisor whose integrity does not depend on correct RTOS operation.

The choice between qualification and containment depends on the allocated SSIL, on the system architecture validated under EN 50129, and on the availability of qualification material. At SSIL 4, pure qualification is rarely practical on third-party components, and architectural containment dominates.

Modification and change management

Railway software typically has a lifetime of several decades in operation. Modification management (patches, functional evolutions, adaptations to new hardware, regulatory updates) is explicitly framed by the two standards.

Any modification triggers an impact analysis that evaluates: which requirements are affected, which software components are modified, which components are indirectly affected through their interface, the risk of regression on the safety function, and the re-verification effort required. Depending on the scope of the change, the cycle can be either a targeted re-verification (minor change, limited scope), a full re-validation (major change, architectural impact), or a fresh Independent Safety Assessment (structural change or SSIL change).

The common practice is to track each modification in a Change Request dossier holding the impact analysis, the re-verification scope, the modified artefacts, the test reports, and the Assessor's opinion. The system-level Safety Case is updated accordingly, and the national safety authority may be notified depending on the scope (a "substantial" modification under the Common Safety Method on Risk Assessment, EU Regulation 402/2013).

TSIs, ERTMS and ETCS: the European regulatory context

The 4th Railway Package, adopted in 2016, harmonises authorisation for placing rolling stock in service and railway safety certification at European level. Before the 4th Package, each member state issued its own authorisations; since then, the European Union Agency for Railways (ERA) issues a single authorisation valid across the declared area of use.

The Technical Specifications for Interoperability (TSIs) impose harmonised technical requirements on the structural sub-systems of the railway network:

CCS TSI (Control-Command and Signalling): trackside and on-board signalling, including ETCS and GSM-R/FRMCS sub-systems. Explicitly references EN 50126, EN 50128, EN 50129.
LOC&PAS TSI (Locomotives and Passenger Rolling Stock): passenger rolling stock and locomotives. References EN 50126, EN 50657 for on-board software not in signalling.
WAG TSI (Wagons): freight wagons.
INF TSI (Infrastructure): track, civil works, gauges.
ENE TSI (Energy): traction power sub-systems.
PRM TSI (Persons with reduced mobility) and SRT TSI (Safety in Rail Tunnels): cross-cutting requirements.

ERTMS (European Rail Traffic Management System) is the target European unified control-command system. It comprises two main pieces: ETCS (European Train Control System), the in-cab signalling and automatic train protection system; and GSM-R (being replaced by FRMCS, Future Railway Mobile Communication System), the ground-to-train radio communication system.

On-board and trackside ETCS sub-systems are classified as signalling and therefore explicitly fall under EN 50128 according to the CCS TSI. For other on-board software on rolling stock (train control, braking, doors, energy), the LOC&PAS TSI applies and EN 50657 is the reference standard.

Link with CE marking

Rolling stock and railway sub-systems are not covered by the classical CE directives (machinery, low voltage, generic EMC) in the consumer-product sense: conformity of structural sub-systems is demonstrated through the EC Verification of sub-systems under the TSIs, conducted by a Notified Body (NoBo) designated under the interoperability directive (2008/57/EC, recast as Directive 2016/797). Railway sub-systems thus receive an EC Verification Declaration distinct from the EC Declarations of Conformity of the classical directives.

That said, some on-board equipment can fall under other directives in parallel (EMC under the generic EMC Directive for connected equipment, RED for on-board radio transmitters), with their own requirements. The CE marking page details the general framework of marking and presumption of conformity.

For the standards vocabulary (SIL, SSIL, RAMS, Safety Case, ISA, PES, T1/T2/T3), see the glossary.

Pitfalls observed in the field

Several recurring traps appear on railway software projects, and are worth anticipating before kick-off.

Confusing EN 50128 and EN 50657 on scope. On-board rolling-stock software that indirectly drives a signalling function (for example, a train control unit that talks to the on-board ETCS) can shift under EN 50128 depending on the system interpretation. The boundary is set by EN 50129 at the system level and must be settled very early, ideally before the software specification phase.
SSIL allocation before system allocation. SSIL cannot be chosen in isolation: it derives from the allocation analysis conducted under EN 50129, taking into account the barrier architecture. A project that starts the software at SSIL 4 by default, without system analysis, pays a development and assessment cost well above what is strictly required.
Underestimating T3 tool qualification. Qualifying a C compiler at SSIL 4 demands an in-service feedback dossier that few vendors provide off the shelf. Picking a compiler without a pre-existing qualification dossier can block the project in the final assessment phase. Check that the dossier (often sold as a Compiler Qualification Kit) is available before freezing the toolchain.
PES without a Proven In Use dossier. Reusing a commercial RTOS or an open-source library without a pre-existing qualification dossier forces a heavy internal qualification effort, or makes qualification impossible when source code is closed. The trade-off between Proven In Use (vendor-dependent) and architectural containment (vendor-independent) must be settled before component selection.
Symbolic role separation. Independence between Author, Verifier, Validator and Assessor requires a real organisation chart and a distinct reporting line. An Assessor named on paper but reporting to the same project director as the development team is not independent in the sense of the standard. The national authority's dossier audit will flag this non-conformity.
Confusing EN 50128 with IEC 61508 in rail. Per the introductory clause of IEC 61508, the railway sector applies the CENELEC family directly, not IEC 61508. A dossier that invokes IEC 61508 without EN 50128 or EN 50657 will be sent back by the Assessor. Familiarity with IEC 61508 remains useful as reading material, but does not substitute.
Minor modification handled as a patch without impact analysis. Any modification, however minor, triggers a formal impact analysis. A quick patch without updating the configuration dossier and without the Assessor's opinion can invalidate the Safety Case and lead to suspension of the authorisation for placing in service.