EN 50126 explained: the RAMS lifecycle for railways

Who this is for: RAMS engineers, safety assessors and project managers who need a working mental model of EN 50126 before opening their licensed copy — what it governs, how the 2017 revision is structured, and where it sits relative to EN 50128 and EN 50129. This is reference material, not a substitute for the standard itself, which you must read in full from a licensed source.

What EN 50126 is (and what it isn't)

EN 50126 is the CENELEC standard that defines the RAMS process — Reliability, Availability, Maintainability and Safety — across the whole lifecycle of a railway system, from concept to decommissioning. It is the process framework that tells you when to do risk analysis, what to produce at each stage, and how RAM and safety activities fit together. Its international twin is IEC 62278.

Crucially, EN 50126 is a process standard, not a design standard. It does not tell you how to build a brake, size a cable or write a line of code. It tells you how to specify, apportion, demonstrate and manage RAMS requirements so that the finished system is acceptably safe and available, and — just as important — so that you can demonstrate that to an assessor. If your project is failing its safety assessment, the cause is very often a broken EN 50126 process (missing traceability, late hazard analysis) rather than a bad design decision.

The current edition is EN 50126:2017, published in two parts, which superseded the single-part EN 50126:1999. A first amendment, EN 50126-1:2017/A1, was published in 2024. A further revision of the EN 5012x family is anticipated later this decade, so always confirm the edition and amendment status of the copy you are working from.

EN 50126-1 vs EN 50126-2 (generic process vs safety approach)

The 2017 revision split the standard into two parts with distinct jobs:

EN 50126-1 — the generic RAMS process. It defines the lifecycle, the V-representation, the structure of the RAMS plan, the hazard-management requirements and the approach to SIL allocation. This is the normative "what you must do" part.
EN 50126-2 — the systems approach to safety. It provides methods and guidance for deriving, apportioning and demonstrating safety requirements. It is largely guidance rather than hard normative requirements, and it is where the worked techniques and examples live.

In practice, Part 1 is what your process and audit trail are measured against; Part 2 is what you reach for when you need to justify how you did the safety work.

Where it sits relative to EN 50128 and EN 50129

Think of EN 50126 as the umbrella. Underneath it, two companion standards go deep on specific technologies:

EN 50129 — the safety case for safety-related electronic systems in signalling (hardware and the overall safety justification).
EN 50128 — software for railway control and protection. Note that EN 50128 (and the rolling-stock software standard EN 50657) has since been consolidated into EN 50716:2023, which also brings in cybersecurity considerations. Check which software standard your contract actually cites.

EN 50126 sets the process and the RAMS targets; EN 50128/50716 and EN 50129 tell you how to meet the safety-integrity obligations for software and signalling hardware respectively.

The RAMS lifecycle phases

The headline change in the 2017 revision was a restructured lifecycle. The 1999 edition described fourteen phases; the 2017 edition consolidates the work into twelve phases, arranged as a V. The left (top-down) branch is the refining, development side — from concept down to manufacture. The right (bottom-up) branch is integration, validation, acceptance and operation of the assembled system. The point of the V is that each verification and validation activity on the right maps back to a specification activity on the left.

The twelve phases of EN 50126-1:2017, in order:

#	Phase	What it broadly produces
1	Concept	Scope, purpose, initial RAMS context
2	System definition and operational context	System boundary, operating and maintenance conditions, the RAMS plan
3	Risk analysis and evaluation	Hazard identification, risk assessment, hazard log established
4	Specification of system requirements	RAMS requirements specification
5	Architecture and apportionment of system requirements	RAMS targets apportioned down to subsystems/components
6	Design and implementation	Design meeting apportioned RAMS requirements; RAM predictions, FMEA
7	Manufacture	Production under controlled conditions
8	Integration	Assembly and integration of subsystems
9	System validation	Demonstration that the system meets its RAMS requirements
10	System acceptance	Formal acceptance against agreed criteria
11	Operation, maintenance and performance monitoring	In-service RAMS performance, FRACAS, hazard log maintained
12	Decommissioning	Managed disposal, residual risk handling

(This is a paraphrased structural summary. The normative phase objectives, inputs, requirements and deliverables are set out in the standard itself — consult your licensed copy for the exact wording and clause references.)

A few things worth internalising:

The hazard log is a living artefact, opened early (phase 3) and maintained through operation (phase 11). It is not a document you write once and file.
Apportionment (phase 5) is where system-level RAMS targets are broken down to subsystems and components. Done well, it drives the whole design; done as an afterthought, it produces requirements no one can trace.
Validation and acceptance are distinct. Validation demonstrates the system meets its requirements; acceptance is the formal, contractual sign-off against agreed criteria.

RAMS vs safety — how the four attributes relate

RAMS bundles four attributes, but they are not managed identically:

Reliability, Availability and Maintainability (the RAM side) are about service performance. Will the train run when scheduled? How quickly can a fault be repaired? These are typically expressed as quantitative targets (MTBF, availability percentages, MTTR) and demonstrated with reliability predictions, FMEA/FMECA and in-service data via a FRACAS.
Safety (the S side) is about acceptable risk. It is demonstrated through hazard identification, risk assessment, safety requirements and — for the higher integrity functions — Safety Integrity Levels.

They are managed together because they trade off against each other (a design that improves availability can introduce a hazard, and vice versa) and because they share the same lifecycle, hazard log and evidence trail. But they are assessed differently: RAM against performance targets, safety against risk-acceptance criteria and the safety case. Conflating the two — for example, treating a safety requirement as merely a reliability target — is a classic source of assessment findings.

A practical way to keep them straight: a RAM failure costs you money and reputation (a delayed or cancelled service), whereas a safety failure costs you the risk-acceptance argument. Both matter, but the burden of proof differs. RAM targets can be demonstrated statistically and, to a degree, corrected in service through the FRACAS loop. Safety, by contrast, has to be argued to an acceptance principle before the system enters service — you cannot "run it and see". This is why EN 50126 front-loads hazard identification (phase 3) and insists the hazard log is opened early and maintained throughout: the safety argument is cumulative, and gaps discovered late are expensive or impossible to close retrospectively.

How EN 50126 connects to EN 50128 and EN 50129

The three standards form the classic railway "V". EN 50126 owns the top of the V — the system-level RAMS process, the targets and the apportionment. As you descend into specific technologies:

Software development follows EN 50128 / EN 50716, which defines the techniques and evidence required at each SIL.
Signalling electronic hardware and the safety case follow EN 50129, which defines the structure of the safety case an assessor expects to see (quality, safety and technical evidence).

The SILs apportioned under the EN 50126 process become the input that drives the rigour demanded by EN 50128/50716 and EN 50129. Get the apportionment wrong at the top and you either over-engineer (expensive) or under-engineer (unsafe, and it will not pass assessment) at the bottom.

Guides on EN 50128 SIL levels and the EN 50129 safety case are coming next.

Common pitfalls when applying EN 50126

Patterns that repeatedly cost projects time in assessment:

Risk analysis started too late. If hazard identification happens after the design is frozen, you are retrofitting safety, not engineering it. Phase 3 exists early for a reason.
Weak requirements traceability. Every RAMS requirement should trace up to a hazard or performance need and down to the design evidence that closes it. Broken traceability is the single most common finding.
Apportionment as an afterthought. Targets bolted on late don't drive the design and rarely reconcile at system level.
A hazard log that stops at handover. The log must live through operation and maintenance (phase 11). Open hazards with operational mitigations have to be carried, tracked and communicated to the operator.
Confusing validation with acceptance, or treating EN 50126-2 guidance as optional when the contract makes it normative.
Tailoring without justifying it. The lifecycle is meant to be tailored to the project — you are not obliged to run every phase at full weight for a minor change. But tailoring is a deliberate, documented decision, not a silent omission. An assessor will ask why a phase was scaled down; "we ran out of time" is not an answer the hazard log can carry.
Treating the SIL as the goal rather than the consequence. The SIL falls out of the risk analysis and apportionment; it is not a marketing number to be chosen up front. Starting from "we want SIL 4" and working backwards inverts the process and usually produces an unjustifiable safety argument.

Frequently asked questions

Is EN 50126 mandatory?

The standard itself is voluntary, but it is very commonly invoked contractually and is the recognised means of demonstrating RAMS management in European rail. It also underpins the safety demonstration expected under the interoperability and safety frameworks. In practice, on most mainline projects it is effectively mandatory because your client, your assessor and your TSI conformity route all expect it.

How does EN 50126 map to the CSM-RA?

They are complementary, not the same thing. The Common Safety Method for Risk Assessment (Regulation (EU) 402/2013) is the legal framework for assessing significant changes to the railway system. EN 50126 is the engineering process for delivering and demonstrating RAMS. A well-run EN 50126 hazard-management process produces much of the evidence an AsBo needs under the CSM-RA — see NoBo vs DeBo vs AsBo for who assesses what.

What changed in the 2017 revision?

The 1999 single-part standard became two parts (generic process in Part 1, safety approach in Part 2), the lifecycle was restructured from fourteen phases to twelve, and the treatment of hazard management and SIL allocation was clarified. A 2024 amendment (A1) to Part 1 followed. Always check the exact edition and amendment your project cites.

Does it apply to urban/metro systems?

EN 50126 is written for railway applications generally and the RAMS process is routinely applied to metro, light rail and tram projects. However, urban systems often sit outside the mainline TSI regime and under different national and local safety frameworks, so the process travels well even where the regulatory obligations differ.

Sources

ERA Standards is an independent product and is not affiliated with the European Union Agency for Railways. This guide is general information, not certification advice.