Safety engineering Study Guide

📖 Core Concepts Safety Engineering – discipline that ensures systems stay “safe enough” even when parts fail. ALARA / ALAPA – design goal: reduce risk As Low As Reasonably Achievable (or Practically). Qualitative vs Quantitative Analysis – Qualitative: “What can go wrong?” (causal links). Quantitative: numeric probabilities, rates, severities. Traditional Hazard Identification – FMEA (bottom‑up) and Fault/Event Tree (top‑down) are the workhorses. Model‑Based Safety – uses formal system models (e.g., STPA) to auto‑derive cause‑effect links. Safety vs Reliability – reliability → avoid any failure; safety → avoid catastrophic outcomes. Probabilistic Risk Assessment (PRA) – combines component failure rates and external event probabilities to compute system‑level risk metrics (e.g., probability of top event). Acceptable Failure Rate – safety‑certified system: \< 1 fatality per $10^{9}$ h of operation. Key Standards – ARP4761 (aerospace), IEC 61508 (electro‑electronic), MIL‑STD‑882 (DoD). --- 📌 Must Remember ALARA/ALAPA: risk reduction ↔ cost trade‑off. FMEA: bottom‑up, functional or component level; assigns probability and criticality. FTA: top‑down Boolean logic; minimal cut sets = smallest combinations causing top event. Event Tree: starts at initiating event, branches to outcomes; yields probability distribution of consequences. Redundancy: needed when single‑failure‑rate cannot meet $10^{-9}$ h⁻¹. Inherent Fail‑Safe: design such that a single failure automatically leads to a safe state without extra devices. Certification Traceability – every safety requirement must be linked to design, code, and test artifacts. PRA Metric Example: $$P{\text{top}} = \sum{\text{minimal cut sets}} \prod{i} Pi$$ where $Pi$ = probability of each basic event. Standards Quick‑Recall: ARP4761 (aerospace), IEC 61508 (E/E/PE), MIL‑STD‑882 (DoD). --- 🔄 Key Processes Conducting an FMEA List system functions (or components). Identify failure modes for each. Determine effects on system performance. Assign probability (using failure rates) and severity. Rank by criticality; prioritize mitigation. Building a Fault Tree (FTA) Define Top Event (undesired outcome). Decompose using AND/OR gates into intermediate events. Continue until reaching basic events (component failures, human error). Perform qualitative analysis → find minimal cut sets. Optionally, compute quantitative probability using basic event rates. Event Tree Analysis (ETA) Start with an initiating event. At each node, branch into success or failure of safety functions. Assign branch probabilities. Multiply along each path to get path probability → sum for each final outcome. Safety Certification Workflow Planning – define safety goals, scope. Analysis – hazard identification (FMEA/FTA/ET). Design – implement safeguards (redundancy, fail‑safe). Implementation – build hardware/software. Verification & Validation – testing, proof of compliance. Configuration Management & QA – maintain traceability. Exit Criteria – documented evidence that all safety requirements are satisfied. --- 🔍 Key Comparisons FMEA vs FTA FMEA: bottom‑up, focuses on failure modes of individual items; good for early design and component‑level detail. FTA: top‑down, focuses on combinations that cause a top event; excels at identifying common‑cause and interaction hazards. Redundancy vs Inherent Fail‑Safe Redundancy: adds extra hardware/software; relies on independent backup paths. Inherent Fail‑Safe: designs the primary system so that a single failure naturally leads to a safe state (no extra devices needed). Qualitative vs Quantitative Analysis Qualitative: “What can go wrong?” – yields hazard lists, minimal cut sets. Quantitative: assigns numbers – produces risk metrics (probability, MTBF). Model‑Based vs Expertise‑Based Model‑Based: formal system model → systematic, repeatable hazard extraction. Expertise‑Based: relies on engineer intuition and experience; may miss subtle interactions. --- ⚠️ Common Misunderstandings “Reliability ≡ Safety” – reliability only concerns non‑critical failures; safety is about catastrophic consequences. “Redundancy alone guarantees safety” – if redundant components share a common‑cause failure mode, safety is not improved. “Qualitative analysis is “just a checklist” – it still requires rigorous causal reasoning; skipping it leads to missing hidden hazards. “If a component meets its spec, it need not be tested again in the safety context” – safety certification demands verification of protective functions under fault conditions. “Low probability = negligible risk” – in high‑consequence systems, even $10^{-9}$ h⁻¹ matters; combine with exposure time to assess risk. --- 🧠 Mental Models / Intuition “Safety as a safety net” – imagine the system as a tightrope walker; redundancy is a second rope, inherent fail‑safe is the walker’s instinct to step back if the rope snaps. “Cut‑Set = Minimal “weak link” chain” – think of a chain; a minimal cut set is the smallest set of links whose break will drop the chain. “Top‑down vs Bottom‑up” – top‑down (FTA) is like tracing a river upstream to find tributaries; bottom‑up (FMEA) is like inspecting every tributary to see if it can feed the river. “Probability multiplication” – each branch in an event tree is an independent coin toss; multiply the odds to get the chance of a particular outcome. --- 🚩 Exceptions & Edge Cases Common‑Cause Failure (CCF) – redundancy fails if a single cause (environmental stress, design flaw) knocks out multiple components simultaneously. Human Error as Initiating Event – not always quantifiable; often treated with conservative probability estimates. Ultra‑High‑Reliability Components – individual parts rarely achieve $10^{-9}$ h⁻¹; must be combined with architectural safeguards. Software Hazards – failure rates are not expressed in h⁻¹; rely on verification, validation, and fault‑injection testing. --- 📍 When to Use Which FMEA → early design, component‑level detail, when you need to prioritize fixes by criticality. FTA → when a specific catastrophic outcome is known and you need to trace all possible cause combinations. Event Tree → after an initiating event is identified (e.g., loss of power) to evaluate downstream safety function success/failure paths. Model‑Based (STPA, etc.) → complex, software‑intensive systems where interactions dominate. Redundancy → when inherent fail‑safe is impossible (e.g., propulsion systems). Inherent Fail‑Safe Design → simple mechanical or hydraulic systems where a single failure can be safely isolated. --- 👀 Patterns to Recognize “Initiating Event → Safety Function → Barrier → Consequence” – typical event‑tree skeleton. Repeated “AND” gates in a fault tree → indicates multiple simultaneous failures required → often a low‑probability cut set. High‑severity, low‑probability hazards → likely candidates for redundancy or inherent fail‑safe measures. Common‑Cause Indicators – same supplier, same environment, similar physical location → flag for CCF analysis. Traceability Matrix – rows = safety requirements, columns = design/code/test artifacts; a filled matrix signals certification readiness. --- 🗂️ Exam Traps Confusing Reliability Goal (e.g., 0.999) with Safety Goal (e.g., $10^{-9}$ h⁻¹) – remember safety targets are orders of magnitude stricter for catastrophic outcomes. Choosing FMEA when the question asks for “minimal cut sets.” – that’s an FTA task. Assuming any redundancy automatically satisfies safety – ignore common‑cause failure; the exam may present “independent” vs “non‑independent” redundant paths. Treating qualitative analysis as “no numbers needed.” – some exam items ask for semi‑quantitative scores (e.g., risk ranking) based on severity × probability. Mixing up “ALARA” vs “ALAPA.” – both mean low risk, but ALARA emphasizes reasonably achievable (cost‑aware), while ALAPA stresses practically achievable (technology‑aware). ---