❓ Frequently Asked Questions

Reliability is the probability that a system performs its required function under given conditions for a given time. It answers the question "does it keep working?"

Safety is freedom from unacceptable risk. It answers the question "what happens when something fails?" A safe design detects faults and moves to a safe state, or keeps the residual risk acceptable.

The two can pull in opposite directions: a train that stops at every detected fault is safe but not very available, while a highly reliable system can still fail dangerously. RAMS engineering balances both.

Defence in depth means several independent layers of protection against the same hazard, so that no single failure leads directly to an accident.

A simplified example from ERTMS/ETCS train control:

• The interlocking sets and locks a route only when points and track sections are in the correct state.
• The Radio Block Centre (RBC) grants a movement authority (MA) only up to a safe end point.
• The on-board ETCS supervises speed and braking curves and applies the brakes automatically if the driver does not react.
• The brake system itself is fail-safe: loss of brake pipe pressure applies the brakes.

Each layer is designed so that if it fails, another one still prevents the hazardous event.

In a 2oo2 architecture two independent channels compute the same safety function and their results are compared. An output is only allowed when both channels agree; any disagreement drives the system to its safe state.

Advantage: a random hardware fault in one channel is detected by the comparison instead of producing a dangerous output. Diversity between the channels (different hardware, compilers or software) can additionally address common-cause and systematic faults.

Trade-off: availability. A failure of either channel stops the function, which is why 2oo3 is used where both safety and availability matter.

More in the article: 2oo3 architecture: safety and availability

Systematically, starting from analysis rather than from test ideas:

• FMEA / FTA: identify failure modes, their effects and the combinations of failures that lead to hazards.
• Derived test cases: sensor failures, loss of communication, power interruptions, timeouts and corrupted data.
• Fault injection: provoke the failures on the target or in simulation and check the reaction.
• Safe reaction: verify that every credible failure leads to a defined safe state within the required time.
• Traceability: link each analysed failure mode to the requirement and the test that covers it.

EN 50128 assigns railway software a safety integrity level from 0 to 4. The 2001 edition called it SSIL; the 2011 edition simply refers to the software SIL. The level follows from the system SIL allocated through EN 50126 and EN 50129.

The higher the level, the more techniques in the standard's Annex A tables become highly recommended or mandatory, for example formal or semi-formal methods, structural code coverage and independent verification and validation. SIL 4 is typical for interlocking and train protection functions.

SIL 0 (basic integrity) does not mean "no requirements": the standard still expects a controlled development process with quality management and configuration management.

Note: EN 50716:2023 now replaces EN 50128 and EN 50657, but EN 50128 is still the reference on many running projects.

ASIL (Automotive Safety Integrity Level): ISO 26262, levels A to D plus QM for items without safety requirements. It is determined in the HARA from the severity, exposure and controllability of each hazardous event.

Railway SIL: EN 50126/50129 for systems and EN 50128 for software, levels 1 to 4 for systems and 0 to 4 for software. It is allocated from the tolerable hazard rate (THR) of a safety function.

Both scale the rigour of development and verification with risk, but there is no official one-to-one mapping between the two scales. Comparisons such as "SIL 4 ≈ ASIL D" are rough orientation at best.

EN 50126: RAMS (reliability, availability, maintainability, safety). The overall railway system lifecycle, risk assessment and allocation of safety requirements.

EN 50128: software for railway control and protection systems. Lifecycle, roles, techniques and documentation for each software SIL.

EN 50129: safety-related electronic systems for signalling. System and hardware safety, and the structure of the safety case.

In short: EN 50126 sets the framework, EN 50129 covers the system and its safety case, and EN 50128 covers the software.

There is no honest general figure. It depends mainly on:

• the integrity level, scope and novelty of the system
• the maturity of the development process and of the existing evidence
• how early the independent safety assessor is involved
• the quality and traceability of requirements, analyses and test reports

Assessment is not a gate to bolt on at the end. Planning it in the safety plan from the start is what keeps it predictable.

Early rather than late. Ideally from the concept and requirements phase, before the architecture is fixed. Good moments to engage:

• Requirements phase: safety requirements derived from hazard analysis shape everything downstream.
• Architecture phase: redundancy, diagnostics and safe states are hard to retrofit.
• Before independent assessment: to check that the process and evidence meet the standard.
• Mid-project review: to catch gaps while they are still cheap to fix.

Closing safety gaps after implementation usually means reworking design, code and evidence.

Typically:

• deriving safety requirements from hazard analysis (hazard log, HARA)
• writing clear, verifiable requirements with acceptance criteria
• traceability from requirements to design, tests and verification results
• change and configuration management of the requirements baseline
• setting up or tidying up the requirements tool (e.g. IBM DOORS) and the review workflow

The goal is a structured, traceable set of requirements that the team, the customer and the assessor can all work with.

Yes. Typical topics:

• Gap analysis: review existing requirements, design and evidence against the applicable standard.
• Change impact analysis: assess how a modification affects safety requirements and existing evidence.
• Assessment support: structure the evidence and documentation an assessor needs.
• Upgrades: update the architecture or requirements for new functions or regulations.

Working on an existing system is harder than starting from scratch, but often unavoidable for long-lived railway and automotive systems.

Railway: ERTMS/ETCS and signalling under CENELEC EN 50126/50128/50129, at Bombardier Transportation (ZWUS), later Alstom.

Automotive: system-level ASPICE, ISO 26262, FMEA and FTA.

The principles of functional safety carry over between domains even though the standards differ. If you work in another field, get in touch – many lessons transfer.

• Blog – articles on functional safety, requirements and system architecture
• Glossary – definitions of safety and RAMS terms
• Tools – calculators for everyday engineering work
• Resources – standards, books and reference material

ALARP (As Low As Reasonably Practicable) is a risk acceptance principle: risk must be reduced until the cost of further reduction would be grossly disproportionate to the safety benefit. It does not demand zero risk.

Demonstrating ALARP usually involves:

• identifying the hazards and estimating their risk
• showing that the residual risk lies in the tolerable region
• listing the further risk reduction measures considered and justifying why those not implemented are not reasonably practicable
• recording the argument and decisions in the hazard log and the safety case

EN 50126 describes ALARP alongside other risk acceptance principles such as GAME and MEM. In the EU railway sector, risk acceptance follows the Common Safety Method for risk assessment (CSM-RA), using codes of practice, a reference system or explicit risk estimation.

Requirements: IBM DOORS / DOORS Next, Polarion, Jama Connect and Codebeamer are common examples in railway and automotive projects.

Modelling: UML/SysML tools such as IBM Rhapsody for architecture and design models linked to requirements.

Safety analyses: dedicated FMEA/FTA tools or, for smaller scopes, well-structured spreadsheets or scripts, as long as the results are versioned and traceable.

The tool matters less than the discipline: bidirectional traceability (requirements ↔ design ↔ code ↔ tests), baselines and controlled change are what an assessor checks.