EN 50126 RAMS Standard: EN 50126-1 & 50126-2 Explained (2026)

EN 50126 explained: RAMS lifecycle, V-Model, SIL 1–4 allocation, and the key difference between EN 50126-1 (process) and EN 50126-2 (guide). Updated May 2026.

EN 50126 RAMS Standard: EN 50126-1 & 50126-2 Explained (2026)
January 7, 2024 12:37 am | Last Update: May 22, 2026 8:31 am
A+
A-

 

⚡ IN BRIEF

EN 50126 is the European railway standard (harmonised as IEC 62278) that defines the complete process for specifying and demonstrating Reliability, Availability, Maintainability and Safety (RAMS) across the full system lifecycle — from concept to decommissioning. It exists in two parts: EN 50126-1 defines the generic RAMS process and V-Model, while EN 50126-2 provides the application guide for safety. It is the foundation standard upon which EN 50128 (software) and EN 50129 (signalling hardware) are built, and is effectively mandatory for safety-critical railway systems placed into service within the European Union.
  • EN 50126: The Mother of Railway Safety Standards: First published in 1999, EN 50126 (IEC 62278) defines the universal process for specifying and demonstrating Reliability, Availability, Maintainability, and Safety (RAMS) for all railway systems – from signaling to rolling stock. It is the foundational standard upon which EN 50128 (software) and EN 50129 (signalling hardware) are built.
  • The V‑Model Lifecycle: The standard mandates a structured “V‑Cycle” approach: from concept and requirements definition on the left side, through implementation at the bottom, to verification and validation on the right side. Each requirement on the left must be tested on the right – a principle that prevents late‑stage surprises and costly redesigns.
  • RAMS as a Balanced Scorecard: EN 50126 defines four interdependent metrics: Reliability (MTBF – Mean Time Between Failures), Availability (A = MTBF/(MTBF+MTTR)), Maintainability (MTTR – Mean Time To Repair), and Safety (quantified by SIL – Safety Integrity Level). Trade‑offs are essential; improving one often affects another.
  • Safety Integrity Level (SIL) Allocation: The standard introduces a risk‑based approach to assign SILs (1 to 4) to safety functions. For a high‑speed train’s emergency brake, a target of SIL 4 (dangerous failure rate < 10⁻⁹/h) is typical. The process involves hazard identification, risk analysis, and demonstrable evidence that all risks are reduced to tolerable levels.
  • 2026 Integration with Cybersecurity (TS 50701): The 2022 release of TS 50701 (Railway Cybersecurity) has made EN 50126 evolve. Modern RAMS engineering now treats cybersecurity as an integral part of the safety lifecycle, because a cyber‑attack can directly impact availability and safety. The European Union Agency for Railways (ERA) now requires combined safety‑security assessments for new ERTMS projects.

On 17 October 2000, a train derailed at 185 km/h near Hatfield, UK, killing four people and injuring over 70. The official inquiry uncovered a cascade of failures: a rail had developed gauge corner cracking over months, but the maintenance regime had not been designed to detect it. Beyond the immediate cause, the report revealed a deeper systemic issue: there was no universal process to ensure that railway systems – from rails to signaling – were specified, designed, and maintained with a consistent focus on reliability, availability, maintainability, and safety. That gap was filled by EN 50126, the “mother standard” of railway RAMS. Published by CENELEC in 1999 and updated regularly since, EN 50126 defines the complete lifecycle process for railway systems, from concept to decommissioning. It introduces the V‑Model, a structured workflow that forces engineers to plan verification and validation at the same time as requirements definition. It quantifies performance with metrics like MTBF (Mean Time Between Failures) and Availability, and it introduces Safety Integrity Levels (SIL) to manage risk. Today, EN 50126 is mandatory for any new railway system placed into service in the European Union, and its principles are adopted globally. This article provides a detailed guide to the standard, its lifecycle, its metrics, and its integration with modern challenges like cybersecurity.

What Is EN 50126 (RAMS)?

EN 50126: Railway applications – The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) is a European standard (harmonised with IEC 62278) that defines the process for managing the lifecycle of railway systems with respect to reliability, availability, maintainability, and safety. It is not a product standard; it is a process standard that applies to infrastructure managers, railway undertakings, and manufacturers. The standard mandates a systematic approach to:

  • Defining system requirements (both functional and non‑functional) at the start of a project.
  • Identifying hazards and allocating risk reduction targets (Safety Integrity Levels).
  • Verifying that the design meets the requirements through a structured V‑Model lifecycle.
  • Demonstrating, through evidence, that the system achieves the target RAMS parameters.

EN 50126 is the foundation for two companion standards: EN 50128 (software for railway control and protection) and EN 50129 (safety‑related electronic systems for signalling). Together, they form the CENELEC railway safety framework. Compliance with EN 50126 is often a prerequisite for obtaining safety authorisation from National Safety Authorities (NSAs) and for interoperability under the Technical Specifications for Interoperability (TSIs).

1. The RAMS Pillars: Metrics and Trade‑Offs

RAMS is a set of four interdependent characteristics. Understanding them is essential for making engineering decisions.

PillarKey MetricFormula / DefinitionTypical Target (Example: High‑Speed Train)
Reliability (R)MTBF (Mean Time Between Failures)Total operating time / number of failures≥ 100,000 hours (traction system)
Availability (A)A = MTBF / (MTBF + MTTR)Proportion of time the system is ready for use≥ 0.999 (99.9%) for critical subsystems
Maintainability (M)MTTR (Mean Time To Repair)Total repair time / number of repairs≤ 30 minutes (line‑replaceable unit)
Safety (S)SIL (Safety Integrity Level)Tolerable dangerous failure rate per hour (PFH)SIL 4: PFH < 10⁻⁹/h (e.g., ETCS onboard computer)

These metrics are interdependent: improving reliability (higher MTBF) increases availability, but may require more maintainable design to offset longer repair times. The standard requires that RAMS targets be defined early and documented in a RAMS Plan.

2. The V‑Model Lifecycle (The Heart of EN 50126)

The V‑Model is a structured lifecycle that ensures traceability and reduces risk. It comprises three phases:

  • Left side (Requirements & Design): Starting with system definition, the process moves down through hazard analysis, requirements allocation, architecture, and detailed design. Each step produces documentation that defines what the system must do and how it will be built.
  • Bottom (Implementation): The actual manufacturing, coding, or assembly takes place.
  • Right side (Verification & Validation): As the system is assembled, it is tested in reverse order: unit tests correspond to detailed design, integration tests to architecture, system validation to system requirements, and acceptance to the overall concept.

The key principle is traceability: every requirement on the left must have a corresponding test on the right. This prevents the common failure of leaving testing to the end of a project, where problems are found late and are expensive to fix. EN 50126 specifies the deliverables at each stage, such as:

  • System Definition Document
  • Hazard Log (continuously updated)
  • Safety Requirements Specification
  • RAMS Plan (including targets and verification methods)
  • Verification and Validation Reports

3. Safety Integrity Levels (SIL) & Risk Management

EN 50126 adopts a risk‑based approach to safety. The process begins with a hazard identification (using HAZOP, FMEA, or structured brainstorming). Each hazard is assessed for its risk (combination of severity and frequency). The tolerable risk level is then allocated to safety functions, which are assigned a Safety Integrity Level (SIL) from 1 to 4, where SIL 4 is the highest integrity. The SIL determines the required probability of dangerous failure per hour (PFH) and the degree of development rigour (e.g., formal methods, code coverage).

SILPFH (dangerous failures per hour)Typical Railway Application
SIL 4< 10⁻⁹ETCS onboard computer, interlocking safety logic
SIL 310⁻⁹ – 10⁻⁸Train protection system (ATP)
SIL 210⁻⁸ – 10⁻⁷Door control interlock (non‑critical)
SIL 110⁻⁷ – 10⁻⁶Passenger information systems (non‑safety)

The standard requires that all hazards be recorded in a Hazard Log and that evidence (e.g., safety analysis reports, test results) be provided to demonstrate that the safety requirements have been met.

How SIL Requirements Affect Each RAMS Parameter

SIL is often seen as purely a safety metric, but it directly shapes the requirements for all four RAMS parameters. Higher SIL mandates stricter targets across the board:

SIL LevelReliability (MTBF)Availability TargetMaintainability (MTTR)Safety (PFH)
SIL 4≥ 500,000 hrs
Dual-redundant design mandatory
≥ 99.999%
Five-nines target
≤ 4 hrs
Hot-swap / online maintenance
< 10⁻⁹/h
Catastrophic failure forbidden
SIL 3≥ 200,000 hrs
Redundancy recommended
≥ 99.99%
Four-nines target
≤ 8 hrs
Planned maintenance windows
10⁻⁸ – 10⁻⁹/h
Critical but not catastrophic
SIL 2≥ 50,000 hrs
Standard redundancy
≥ 99.9%
Three-nines target
≤ 24 hrs
Next-day maintenance acceptable
10⁻⁷ – 10⁻⁸/h
Marginal severity
SIL 1≥ 10,000 hrs
Basic reliability targets
≥ 99%
Two-nines target
≤ 48 hrs
Standard corrective maintenance
10⁻⁶ – 10⁻⁷/h
Negligible severity
⚠ Note: Values shown are indicative industry benchmarks. EN 50126 requires project-specific target setting based on actual risk analysis — these figures are not normative requirements of the standard itself.

4. Modern Evolution: Cybersecurity Integration (TS 50701)

Originally, EN 50126 did not address cybersecurity. However, the 2022 publication of TS 50701: Railway applications – Cybersecurity (Technical Specification) has changed the landscape. The EU Agency for Railways (ERA) now requires that safety and cybersecurity be treated jointly, because a cyber‑attack can compromise safety‑critical functions (e.g., spoofing a train’s position, causing a collision) or reduce availability (e.g., ransomware on a signalling system). The updated RAMS process therefore includes:

  • Threat modelling: Identifying potential attack vectors (e.g., unauthorised access to the train’s network) alongside physical hazards.
  • Security requirements: Assigned with their own integrity levels (Security Integrity Levels – SIL analogous), integrated into the hazard log.
  • Verification: Security testing (penetration testing, vulnerability scanning) as part of the validation phase.

For example, the Shift2Rail project “X2Rail‑4” integrated cybersecurity into the RAMS process for virtual coupling, demonstrating that a combined safety‑security assessment is feasible and essential. The next revision of EN 50126 (expected 2027) is likely to formally incorporate cybersecurity requirements, reflecting this evolution.

EN 50126-1 vs EN 50126-2: What Is the Difference?

One of the most common points of confusion among engineers new to the CENELEC railway safety framework is the distinction between the two parts of EN 50126. Both were published in their current form in 2017, but they serve fundamentally different purposes.

FeatureEN 50126-1:2017
Generic Process (the “What”)
EN 50126-2:2017
Application Guide (the “How”)
Full titleRailway applications — Specification and demonstration of RAMS — Part 1: Generic RAMS ProcessRailway applications — Specification and demonstration of RAMS — Part 2: Guide to the application of EN 50126-1 for safety
PurposeDefines the mandatory process: the V-Model lifecycle, RAMS targets, hazard management, and documentation requirementsProvides practical guidance: techniques, worked examples, and annexes to help apply Part 1 correctly
Normative?✅ Yes — compliance required for EU safety authorisation⚠ Informative — guidance only, not directly normative
ScopeAll railway systems and subsystems (infrastructure, rolling stock, signalling, etc.)Focused specifically on safety aspects and safety case construction
Key contentSystem lifecycle phases, RAMS Plan structure, hazard log requirements, SIL allocation processFMEA/FMECA techniques, hazard identification methods, safety case templates, worked examples
Who uses itProject managers, systems engineers, National Safety Authorities (NSAs)Safety engineers, assessors, RAMS analysts building the practical safety case

Which Part Do You Need to Comply With?

For regulatory compliance and NSA acceptance, EN 50126-1 is the normative requirement. If your project’s scope requires a formal RAMS demonstration (as required by TSIs), you must comply with Part 1. EN 50126-2 is best understood as an expert companion: it shows how to perform a proper Hazard and Operability Study (HAZOP), construct a safety argument, and apply techniques like FMEA to meet Part 1’s requirements. In practice, most competent RAMS teams use both parts together, with Part 1 as the process map and Part 2 as the technical toolkit.

Comparison: EN 50126 vs. EN 50128 vs. EN 50129

The three CENELEC railway safety standards are often confused. This table clarifies their roles:

StandardScopeKey DeliverablesRelationship to EN 50126
EN 50126Overall lifecycle process for RAMSRAMS Plan, Hazard Log, Safety CaseThe foundation (process standard)
EN 50128Software for railway control and protectionSoftware requirements specification, test reports, code reviewImplements the EN 50126 process for software
EN 50129Safety‑related electronic systems for signallingHardware safety case, FMEDA, reliability dataImplements the EN 50126 process for signalling hardware

All three are mandatory for safety‑critical systems in the EU. They are often applied together, with EN 50126 providing the overarching process, and the other two providing the technical details for software and hardware.

📘 Our Other Standards

Phase 1 — Concept & System Definition

System boundary defined CONCEPT

Document the system scope, interfaces, and operational context. Identify all subsystems that will require RAMS analysis.

RAMS Plan approved CONCEPT

The RAMS Plan must define: RAMS targets (MTBF, availability, MTTR, SIL), responsibilities, methods to be used, and the verification/validation strategy.

Operational profile documented CONCEPT

Operating hours per year, environmental conditions, mission profiles, and expected service life must be defined before reliability targets can be set.

Phase 2 — Risk Analysis & Requirements

Hazard Log initiated DESIGN

All identified hazards recorded with: hazard ID, description, cause, effect, severity, frequency, risk level, and assigned mitigation. Must be maintained throughout the project lifecycle.

SIL allocation completed DESIGN

Each safety function assigned a SIL (1–4) based on risk analysis. Rationale documented and reviewed by an independent safety assessor.

Safety Requirements Specification (SRS) issued DESIGN

Formal SRS document covering all safety requirements, with traceability to hazards in the Hazard Log and allocated SIL levels.

RAMS requirements allocated to subsystems DESIGN

System-level RAMS targets broken down to subsystem level. Reliability block diagrams or fault trees used to verify allocation is consistent.

Phase 3 — Design & Implementation

FMEA / FMECA conducted IMPLEMENTATION

For all safety-critical subsystems. Results feed into the Hazard Log and reliability predictions. FMECA adds criticality ranking to prioritise design improvements.

Reliability predictions completed IMPLEMENTATION

Predicted MTBF calculated using component failure rate data (e.g., IEC 62380, MIL-HDBK-217). Must demonstrate that MTBF target can be met before design is frozen.

Software compliance with EN 50128 verified IMPLEMENTATION

All safety-related software developed under EN 50128. Software Safety Integrity Level (SSIL) must be consistent with the system-level SIL allocation from Phase 2.

Hardware compliance with EN 50129 verified IMPLEMENTATION

Electronic hardware safety case prepared per EN 50129. FMEDA (Failure Modes, Effects and Diagnostic Analysis) completed for all safety-related hardware.

Phase 4 — Verification & Validation

Traceability matrix complete VALIDATION

Every requirement in the SRS has a corresponding test or analysis in the V&V plan. No orphaned requirements or untested safety functions permitted.

Reliability demonstration test passed VALIDATION

Statistical test (or equivalent analysis) demonstrating that the MTBF target is met with the required confidence level — typically 90% per EN 50126-1 guidance.

Independent Safety Assessment (ISA) completed VALIDATION

An independent assessor (not involved in design) reviews and approves the Safety Case. Required by most NSAs for SIL 2 and above.

Safety Case submitted to NSA VALIDATION

The complete safety case — including RAMS Plan, Hazard Log, SRS, FMEA, reliability data, V&V reports, and ISA statement — submitted for formal safety authorisation.

Phase 5 — Operations & Maintenance

Failure data collection system (FRACAS) established OPERATIONS

A systematic Failure Reporting, Analysis and Corrective Action System must be in place to feed operational data back into the RAMS model and validate design-stage predictions.

Maintenance plan validated against MTTR targets OPERATIONS

Planned maintenance intervals and corrective maintenance procedures verified against MTTR targets from the RAMS Plan. Deviations trigger a plan review.

Periodic RAMS review conducted OPERATIONS

Annual review comparing achieved MTBF and availability against targets. Consistently missed targets trigger a formal design or maintenance strategy update.

Note: This checklist is a reference guide based on EN 50126-1:2017. Project-specific requirements may vary depending on the system type, applicable TSIs, and the requirements of the relevant National Safety Authority (NSA). Always refer to the current published standard for normative requirements. You can read this checklist seperately. 

📝 Editor’s Analysis: The Gap Between Process and Reality

EN 50126 provides an excellent process, but its real‑world effectiveness depends on two often‑overlooked factors: data quality and organisational culture. The standard requires quantitative reliability data (MTBF) to be used in design and maintenance. However, many railway operators still lack systematic failure data collection. A 2023 survey by the European Railway Agency (ERA) found that only 35% of infrastructure managers had a fully digitised failure reporting system that feeds into reliability models. Without good data, the RAMS analysis becomes a theoretical exercise, not a practical tool.

Moreover, the V‑Model is often applied as a “tick‑box” exercise, with traceability matrices created but not used to drive decisions. The result is that projects still suffer late‑stage failures because verification was not aligned with requirements. The next evolution of EN 50126 should mandate the use of digital twins and model‑based systems engineering (MBSE) to automate traceability and provide real‑time feedback from operations to design. Until then, the standard remains a necessary but insufficient condition for safe, reliable railways – a framework that demands not only process compliance but also a culture of data‑driven, rigorous engineering.

— Railway News Editorial

Frequently Asked Questions (FAQ)

1. Is EN 50126 mandatory for all railway projects in Europe?

EN 50126 is not a law itself, but it is referenced in the Technical Specifications for Interoperability (TSIs) and is required by many National Safety Authorities (NSAs) as part of the safety authorisation process. For new or significantly upgraded rolling stock and infrastructure placed into service on the trans‑European network, compliance with EN 50126 (along with EN 50128 and EN 50129 for safety‑critical subsystems) is de facto mandatory. For purely domestic lines or non‑safety‑critical equipment, national rules may apply, but EN 50126 is increasingly adopted as best practice.

2. What is the difference between “verification” and “validation” in the V‑Model?

Verification answers: “Are we building the product right?” It checks that each phase’s outputs conform to the inputs from the previous phase. For example, a design verification ensures that the detailed design meets the system architecture. Validation answers: “Are we building the right product?” It checks that the final system meets the user’s needs and the original requirements. In the V‑Model, verification happens as you move up the right side (e.g., integration test, system test), while validation occurs at the top‑right (acceptance test). The distinction is critical: verification ensures technical consistency; validation ensures the system actually solves the problem it was intended to solve.

3. How does the “bathtub curve” relate to EN 50126?

The bathtub curve describes the failure rate over a product’s lifetime: high during early “infant mortality” (manufacturing defects), then constant during “useful life” (random failures), then rising during “wear‑out” (aging). EN 50126 uses this concept to inform reliability targets and maintenance strategies. For example, the standard requires that the “useful life” phase be maximised and that maintenance be planned to occur before the wear‑out phase begins. It also influences the reliability demonstration tests: a system may undergo burn‑in to reduce early failures, and reliability growth testing is used to verify that the failure rate during useful life meets the MTBF target.

4. Can a system be SIL 4 compliant if it uses commercial off‑the‑shelf (COTS) components?

Yes, but with significant caveats. EN 50126 and its companion standards (EN 50128, EN 50129) require that all components used in a SIL 4 safety function have a proven safety record or be subjected to rigorous analysis. For COTS components, this typically means: (1) the component must have a failure rate and failure mode data from a reliable source (e.g., SN 29500, IEC 62380); (2) the component must be used within its specified operating limits; (3) the system design must include diagnostic coverage (e.g., redundant channels, self‑tests) to detect failures; and (4) the component must be subject to a “proven‑in‑use” argument based on extensive field experience. For example, many ETCS onboard computers use COTS microprocessors that have been qualified through a combination of manufacturer data and railway‑specific testing. However, for very high integrity, custom‑designed components may still be preferred.

5. How is EN 50126 being updated to address digital railways (AI, 5G, etc.)?

The CENELEC railway working groups are currently revising EN 50126 to reflect new technologies. Key changes expected in the next version (circa 2027) include: (1) integration with cybersecurity (TS 50701) as a formal part of the RAMS process; (2) guidance for the use of artificial intelligence and machine learning in safety‑related functions (e.g., predictive maintenance systems that affect safety); (3) treatment of data communication networks (e.g., 5G, FRMCS) as part of the system, with their own RAMS requirements; and (4) alignment with the EU’s Data Act and the concept of “data spaces” to enable cross‑operator reliability analysis. The new version is also likely to mandate digital traceability using model‑based systems engineering (MBSE) tools, moving away from document‑centric processes. In the meantime, the current version (EN 50126‑1:2017) remains the baseline, with “interpretation notes” issued by the European Union Agency for Railways (ERA) to guide application in new domains.

6. What is the difference between EN 50126-1 and EN 50126-2?

EN 50126-1:2017 is the normative part of the standard — the part you must comply with for safety authorisation. It defines the generic RAMS lifecycle process, the V-Model, the structure of the RAMS Plan, hazard management requirements, and the SIL allocation methodology. It applies to all railway systems and subsystems. EN 50126-2:2017 is informative (i.e., not directly normative) and serves as a practical application guide specifically focused on safety. It provides worked examples, guidance on hazard identification techniques (FMEA, HAZOP, FMECA), and templates for building a safety case under Part 1. In practice: use Part 1 to understand what you must do, and Part 2 to understand how to do it correctly. Both were revised in 2017, replacing the original single-part EN 50126:1999.

7. How does EN 50126 handle the SIL allocation process in practice?

EN 50126 uses a four-step risk-based process for SIL allocation: (1) Hazard Identification — using structured methods (HAZOP, FMEA, structured brainstorming) to list all potential hazards; (2) Risk Estimation — assessing each hazard for its severity (from negligible to catastrophic) and frequency (from incredible to frequent) to produce a risk level; (3) Risk Evaluation — comparing the estimated risk against a defined risk acceptance criterion (often expressed as an ALARP — As Low As Reasonably Practicable — region); (4) SIL Assignment — for risks that exceed the tolerable threshold, a safety function is defined and a SIL (1–4) is allocated that specifies the required probability of dangerous failure per hour (PFH). This process must be documented in the Hazard Log and approved by an independent safety assessor. For complex systems, a risk allocation matrix (mapping severity × frequency to SIL) is used to make the process systematic and auditable.

© 2026 Railway News – RAMS & EN 50126 Reference Guide. All rights reserved.

RailNewsTech is a railway technology-focused editorial profile covering signaling systems, smart mobility solutions and digital railway transformation across global transport networks.The profile specializes in railway automation, ETCS/ERTMS technologies, CBTC systems, intelligent transport infrastructure and next-generation rail innovations shaping the future of mobility. Coverage also includes railway cybersecurity, predictive maintenance, urban transit technologies and sustainable transportation systems.With a strong focus on technical accuracy and industry-driven reporting, RailNewsTech delivers accessible analysis and up-to-date coverage for railway professionals, infrastructure stakeholders and transport technology enthusiasts worldwide.
COMMENTS

This site uses Akismet to reduce spam. Learn how your comment data is processed.

No comments yet, be the first filling the form below.