System Design Glossary

As Low As Reasonably Practicable. A risk acceptance principle: a risk is reduced until the cost, time or effort of further reduction would be grossly disproportionate to the benefit gained. In railway safety practice it is mentioned alongside other risk acceptance principles such as GAME and MEM.

The part of overall safety that depends on safety-related systems and other risk reduction measures functioning correctly in response to their inputs, including when faults occur. ISO 26262 defines it as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems.

Functional safety of electrical/electronic/programmable electronic safety-related systems. The generic, cross-industry functional safety standard that defines SIL 1–4 and serves as the basis for sector standards such as ISO 26262 (automotive) and IEC 61511 (process industry).

Safety Integrity Level. A discrete level (1–4, with 4 the most demanding) defined in IEC 61508 for specifying the safety integrity of safety functions. A higher SIL means stricter targets for random hardware failures and more rigorous techniques and measures against systematic faults. The railway standards EN 50126, EN 50128 and EN 50129 adapt the concept; EN 50128 also uses SIL 0 for software.

A structured, documented argument, supported by evidence, that a system is acceptably safe for a specific application in a specific operating environment. EN 50129 defines the structure of the safety case for railway signalling systems; ISO 26262 also requires a safety case for automotive items.

Tolerable Hazard Rate. The maximum acceptable rate of occurrence of a hazard, usually expressed per hour (h⁻¹). In railway practice (EN 50126, EN 50129) the THR allocated to a safety function is used to determine its required SIL.

Railway applications – Specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS). Defines the RAMS lifecycle and processes for the whole railway system. The 2017 edition is split into part 1 (generic RAMS process) and part 2 (systems approach to safety).

Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems. Specifies the software lifecycle, roles and their independence, and the techniques and measures required for each software SIL (0–4). Its successor, EN 50716:2023, merges EN 50128 and EN 50657 into one railway software standard.

Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling. Defines the conditions for acceptance and approval of safety-related electronic signalling systems, including the structure and content of the safety case and evidence of quality and safety management.

Software Safety Integrity Level. Term used in EN 50128:2001 for software integrity levels 0–4. EN 50128:2011 dropped it in favour of the general term SIL (software SIL 0–4), so SSIL is now found mainly in older projects and documents.

European Rail Traffic Management System. The European standard for train control and signalling that enables interoperability across national networks. Its main components are ETCS (train protection) and the railway radio system (GSM-R, with FRMCS as its successor). ETCS has traditionally been described in application levels: Level 0, Level NTC (national system via an STM), Level 1, Level 2 and Level 3. The 2023 revision of the CCS TSI restructured this level concept, so newer specifications may describe it differently.

European Train Control System. The signalling and train protection part of ERTMS. On-board equipment supervises train speed and the movement authority received from the trackside (via balises, or by radio from an RBC) and applies the brakes if the permitted limits are exceeded.

Radio Block Centre. A trackside ETCS computer that issues movement authorities to trains by radio, based on route information from the interlocking and on position reports sent by the trains.

A safety-related signalling system that prevents conflicting train movements: it controls points and signals and sets a route only when the route is clear and all its elements are locked in the correct position. Electronic interlockings are typically developed to SIL 4.

Road vehicles – Functional safety. An international standard (12 parts in the 2018 edition) that adapts IEC 61508 to electrical and electronic systems in series production road vehicles. It covers the safety lifecycle, hazard analysis and risk assessment (HARA), ASIL classification, and requirements for system, hardware and software development.

Automotive Safety Integrity Level. The ISO 26262 risk classification from A (lowest) to D (highest), determined during hazard analysis and risk assessment (HARA) from severity, exposure and controllability. Hazards that do not require an ASIL are classified as QM (quality management).

Automotive SPICE. A process assessment model for automotive system and software development. It rates processes such as system requirements analysis (SYS.2) or software requirements analysis (SWE.1) on capability levels 0–5. OEMs often require it alongside ISO 26262: ASPICE addresses process capability, ISO 26262 addresses functional safety.

Systematic identification of the hazards a system can cause or contribute to, together with an assessment of their severity and likelihood. The results are recorded in a hazard log and drive the safety requirements. In ISO 26262 the corresponding activity is called HARA (Hazard Analysis and Risk Assessment).

FTA. A top-down, deductive method: starting from an undesired top event (for example a hazard), logic gates (AND/OR) break it down into combinations of lower-level faults and failures. Minimal cut sets show which combinations lead to the top event; with failure data, the probability or rate of the top event can be calculated.

Failure Mode and Effects Analysis. A bottom-up, inductive method that systematically examines the possible failure modes of each component or function, their causes and their effects on the system. Extended with a criticality assessment, it becomes FMECA.

The process of identifying the underlying cause(s) of a failure or incident, not just its immediate symptom, so that corrective actions prevent it from recurring. Common techniques include 5 Whys, Ishikawa (fishbone) diagrams and fault trees.

Mean Time Between Failures / Mean Time To Failure. MTTF is the expected time to the first failure (typically used for non-repairable items); MTBF is the expected time between consecutive failures of a repairable item. With a constant failure rate λ, MTTF = 1/λ. Neither is a guaranteed service life.

A safety strategy that uses several independent layers of protection, so that no single failure or error leads to a hazardous outcome.

Providing more than one means of performing a function, so that the failure of one element does not cause the loss of the function. Depending on how the channels are compared and combined, redundancy can improve safety, availability or both. Diversity between channels reduces the risk of common cause failures.

Two-out-of-two. An architecture with two channels that must agree before an output is acted upon; any disagreement leads to the safe state. It offers high safety but lower availability, because a failure of either channel stops the system.

Two-out-of-three. An architecture with three channels and majority voting: an output is accepted when at least two channels agree. A single faulty channel can be outvoted and isolated, so the system can remain both safe and available.

A design principle in which failures lead the system to a defined safe state, such as a signal showing stop or a train braking. It can rely on the inherent behaviour of components (for example safety relays that drop out when de-energised) or on detecting a fault and reacting to it.

The discipline of eliciting, documenting, analysing, prioritising and baselining requirements and controlling changes to them throughout the lifecycle, including traceability and impact analysis of changes.

The ability to follow a requirement in both directions: from its source through derived requirements, design and implementation to verification evidence, and back. It is required by EN 50128, ISO 26262 and ASPICE, and is commonly managed in tools such as IBM DOORS.

V&V. Verification confirms, through examination and objective evidence, that a work product meets its specified requirements ("are we building the product right?"). Validation confirms that the system fulfils its intended use and user needs in its operating environment ("are we building the right product?").

A systematic examination of source code by people other than its author to find defects and check compliance with the design and coding standards (for example MISRA C). In safety-related development, review and inspection records form part of the verification evidence.