What goes in an EN 50126 RAMS plan

What a RAMS plan is for

EN 50126-1 defines a lifecycle process for specifying and demonstrating the reliability, availability, maintainability and safety (RAMS) of railway systems. The RAMS plan is the management document that puts that process into practice on a specific project. It sets out which RAMS activities will be performed, in which lifecycle phase, by whom, using which methods, and how the results will be checked and recorded.

A good plan lets a reviewer, an assessor or a new team member answer three questions quickly: what RAMS evidence will this project produce, how will it be produced, and how will anyone know it is complete and correct?

Plan, not report. The RAMS plan describes intended work. Analysis results belong in hazard analysis reports, RAM prediction reports and, ultimately, the safety case. Mixing the two makes both harder to review and keep current.

The checklist

The structure below reflects what EN 50126-1 expects a RAMS management approach to cover, and what reviewers on rail projects typically look for. Adapt the headings to your client's template, but make sure each topic is addressed somewhere.

1. Purpose, scope and system definition

• The system and its boundary, including what is explicitly out of scope.
• The lifecycle phases the plan covers, and the project's position in the overall railway lifecycle.
• The applicable standards, editions and any national or client-specific requirements, and how they are tailored.
• Key interfaces with other systems, contractors and the operator or maintainer.

2. RAMS requirements and targets

• Where the RAM targets come from (contract, operator performance regime, reference systems) and how they will be apportioned to subsystems.
• The safety targets and the risk acceptance principles that apply, for example code of practice, comparison with a reference system or explicit risk estimation.
• How targets will be demonstrated: by analysis, test, in-service data, or a combination.

3. Organisation, roles and competence

• An organisation chart showing RAMS roles and reporting lines, including the RAMS or safety manager.
• Responsibilities for each RAMS deliverable, including those of subcontractors and suppliers.
• Competence requirements and how they are assured.
• Independence arrangements for verification, validation and assessment, appropriate to the safety integrity required.

4. RAMS activities by lifecycle phase

This is the core of the plan. For each lifecycle phase, list the RAMS tasks, their inputs, outputs, responsible party and the gate at which they must be complete. A table works well:

5. Hazard and risk management process

• How hazards are identified, recorded, assessed, controlled and closed.
• The hazard log: format, ownership, review frequency and how it links to safety requirements and evidence.
• The risk matrix or risk assessment method, and who can accept residual risk.
• How hazards are transferred to, or received from, other parties at interfaces and at handover.

6. Analysis methods and tools

• Which techniques will be used and where: FMECA, fault tree analysis, reliability block diagrams, Markov models, HAZOP and so on.
• Data sources for failure rates and how their suitability will be justified.
• Software tools used for analysis, and how confidence in them is established.

7. Verification, validation and assessment

• How each RAMS deliverable will be verified, and by whom.
• How RAMS requirements are traced through to verification evidence.
• Arrangements for independent safety assessment, where required.

8. Data collection and in-service performance

• Failure reporting, analysis and corrective action (FRACAS) during testing, trial running and early operation.
• How in-service data will demonstrate RAM targets and feed back into the hazard log.

9. Supplier management, documentation and change control

• RAMS requirements flowed down to suppliers, and how their deliverables are reviewed.
• The list of RAMS deliverables, document control, and configuration management.
• How design changes trigger impact assessment on RAMS and safety evidence.
• When and how the plan itself will be reviewed and reissued.

Common reasons a RAMS plan fails review

• Generic content. Text copied from the standard without saying what this project will actually do.
• No link to the schedule. RAMS tasks with no phase, gate or owner rarely happen on time.
• Vague independence. Reviewers expect a clear statement of who verifies, validates and assesses, and how independent they are.
• Missing interfaces. Hazards at interfaces between contractors are where gaps appear. The plan should say who owns them.
• Plan never updated. A RAMS plan written at contract award and never revised no longer describes the project by the time of acceptance.

RAMS plan, safety plan or both?

Some projects produce a single RAMS plan; others separate a system safety plan from a RAM plan, especially where the safety regime is governed by different stakeholders or regulators. Either approach is acceptable if the plans are consistent and cross-referenced, and nothing falls between them. Whichever you choose, keep the hazard management process in one place.

A note on the current edition

EN 50126-1 and EN 50126-2 were published in 2017, and an amendment to Part 1 (A1:2024) was published in November 2024 with revised terms and definitions. Check which edition and amendment your contract references before finalising the plan's terminology.