English for Safety-Critical Systems: ISO 26262, FMEA, and Safety Cases
Learn the English vocabulary safety engineers use — ASIL, FMEA, fault trees, safety cases, fail-safe design — with example sentences for regulatory and technical contexts.
Safety-critical systems — in automotive, aerospace, medical devices, rail, and industrial control — require a specific vocabulary rooted in international standards like ISO 26262, IEC 61508, and DO-178C. Engineers working in these domains must write and read precise technical documents, safety cases, and regulatory submissions. This guide covers the essential English vocabulary.
Core Safety Vocabulary
| Term | Definition |
|---|---|
| ASIL | Automotive Safety Integrity Level — a risk classification from ASIL A (lowest) to ASIL D (highest) in ISO 26262 |
| SIL | Safety Integrity Level — the equivalent classification in IEC 61508 (SIL 1 to SIL 4) |
| FMEA | Failure Mode and Effects Analysis — a systematic method for identifying potential failures and their consequences |
| Fault tree analysis (FTA) | A top-down method for analysing the causes of an undesirable event |
| Safety case | A structured argument with evidence that a system is safe for a specific use in a specific environment |
| Fail-safe | A design principle where a failure results in the safest possible state |
| Fail-operational | A design principle where a system continues to function despite a failure |
| Hazard | A potential source of harm |
| Risk | The combination of the probability of harm and the severity of that harm |
| Mitigation | A measure that reduces the probability or severity of a hazard |
FMEA Vocabulary and Structure
Failure Mode and Effects Analysis is a systematic table-based method. Understanding the vocabulary lets you read and write FMEA documents.
| FMEA Column | Definition |
|---|---|
| Failure mode | The way in which a component or function could fail |
| Effect | The consequence of the failure mode at the system level |
| Cause | The mechanism that leads to the failure mode |
| Severity (S) | A rating (typically 1–10) of how serious the effect is |
| Occurrence (O) | A rating of how likely the failure mode is to occur |
| Detection (D) | A rating of how easily the failure can be detected before it causes harm |
| RPN | Risk Priority Number — S × O × D; used to prioritise corrective actions |
| Corrective action | A design or process change that addresses the failure mode |
Example FMEA row (plain English description): “The throttle position sensor may provide an erroneous high reading (failure mode). This could cause unintended acceleration (effect). The cause is sensor drift due to temperature cycling. Severity: 9. Occurrence: 3. Detection: 4. RPN: 108. Corrective action: add a redundant sensor with cross-validation logic.”
Fault Tree Vocabulary
Fault tree analysis uses Boolean logic gates to model combinations of failures.
| Term | Meaning |
|---|---|
| Top event | The undesirable event being analysed |
| Basic event | A root-level failure that cannot be decomposed further |
| Intermediate event | A fault that results from a combination of lower-level events |
| AND gate | All inputs must occur for the output to occur |
| OR gate | Any input is sufficient to cause the output |
| Cut set | A combination of basic events whose simultaneous occurrence leads to the top event |
| Minimal cut set | The smallest set of basic events sufficient to cause the top event |
Safety Case Language
A safety case is a structured argument. The language is formal, precise, and evidential.
Safety case argument structure (Goal Structuring Notation):
- Goal: “The braking system is safe for use in road vehicles operating at speeds up to 200 km/h under normal and adverse weather conditions.”
- Strategy: “Argument over the life cycle phases: requirements, design, implementation, and verification.”
- Sub-goal: “The braking system requirements are complete and correct.”
- Evidence: “The requirements were reviewed by an independent safety assessor and found to be compliant with ISO 26262 Part 8.”
Formal language patterns in safety documents:
- “It shall be demonstrated that…”
- “The system is required to…”
- “Evidence of compliance is provided in…”
- “This claim is supported by…”
- “The following residual risks have been identified and accepted…”
Regulatory Document Language
Safety standards use modal verbs with specific meanings:
| Modal | Standard meaning |
|---|---|
| shall | Mandatory requirement |
| should | Recommended but not mandatory |
| may | Permitted but not required |
| can | Describes a capability, not a requirement |
This is different from everyday English. In safety documents, “shall” is always a hard requirement — non-compliance must be justified.
Example Sentences
- “The parking brake actuator has been assigned ASIL B based on the HARA, given a moderate probability of occurrence and a critical severity at vehicle speeds below 10 km/h.”
- “The FMEA identified a high-RPN failure mode on the power supply module; the corrective action is to add redundant power rails with independent monitoring.”
- “The safety case for the autonomous emergency braking function spans twelve assurance levels and is supported by simulation data, hardware-in-the-loop test results, and independent assessor sign-off.”
- “A fail-safe response has been designed: if communication between the primary and secondary control units is lost, the system shall default to maximum braking assistance.”
- “The fault tree analysis identified three minimal cut sets for the top event ‘unintended lateral movement’; all three have been addressed in the revised architecture.”
In Practice: Navigating Communication in a Safety Case Review
Let’s be honest – translating complex engineering concepts from your native language into precise English can feel like navigating a dense forest. It’s not just about knowing the definitions of terms like “ASIL” or “FMEA”; it’s about consistently using them correctly within the specific context of safety-critical systems development. A common stumbling block for non-native speakers is subtle differences in phrasing that can significantly impact clarity and, crucially, demonstrate a thorough understanding to your colleagues.
During a recent code review of a new sensor integration module for an automotive application (targeting ISO 26262), I noticed a particularly interesting exchange. The developer, let’s call him Jian, had implemented a redundant system where the primary sensor reading was continuously compared against a backup reading derived from a completely independent source. His PR description simply stated: “Redundant sensor monitoring.” While technically accurate, it lacked the necessary detail for a safety-critical environment. My comment, aiming to be constructive and clear, focused on the reasoning behind the redundancy. I suggested, “Jian, could we elaborate on the justification for this redundant monitoring? Specifically, what failure modes are we mitigating with this approach, and how does it align with our FMEA analysis? Adding a sentence detailing the ASIL level associated with this module’s safety requirements would also strengthen the documentation.” This shifted the conversation from a simple observation to a deeper discussion about risk mitigation and traceability – elements vital for a robust safety case.
Another situation arose during a Slack discussion regarding a proposed change to the system’s fail-safe mechanisms. The initial proposal, drafted by a team member whose first language was Spanish, used phrases like “the system will automatically stop” without specifying how this stopping occurred or what diagnostic checks were in place. This lack of detail raised immediate concerns. A subsequent clarification, prompted by my pointing out the need for quantifiable criteria – “Can we define the conditions that trigger the automatic stop? What are the measurable parameters we’re monitoring to ensure a safe shutdown?” – helped refine the design and ultimately built confidence in its safety implications.
Understanding this nuanced communication is key. It’s not enough to just know what you’re saying; it’s about conveying why you’re saying it, always linking back to established analysis like FMEAs and ensuring traceability through your documentation. This level of precision builds trust and demonstrates a commitment to the stringent requirements of ISO 26262.
Here’s an example illustrating how grep can be used to search for specific keywords within log files related to safety monitoring, a common task during incident investigation:
grep -i "sensor_failure" /var/log/system_monitoring.log | sort | uniq -cThis command searches the /var/log/system_monitoring.log file for instances of “sensor_failure” (case-insensitive), sorts the results by frequency, and then displays a count of each occurrence. This output can be invaluable when reviewing logs after an anomaly or potential safety issue – clearly demonstrating the ability to extract critical data from complex systems.