Embedded Files
Azle Insights
How to quantify safety ?
Throughout our lives we have seen products and systems we use suddenly fail, varying from a mild failures to a disastrous failures. Disasters are dangerous to lives and limbs and their effect lasts beyond the instant of the occurrence of failure. The biggest failures of control systems implemented in traditional software was Therac-25, where a racing condition in the software resulted in patients receiving massive overdoses of radiation. Ethiopian and Lion air crashes of Boeing 737-MAX8 and MAX9 resulting from not imagining possible safety concerns of MCAS system on a new kind of airframe. From another era of failures was the fall of Tocoma Narrows Bridge, where engineers did not imagine aeroelastic flutter’s effect on the overall structure. In 2021 the Champlain Towers South condo building partially collapsed due to long-term corrosion of the concrete structural supports in the parking garage. The problem was identified years earlier but repairs were not completed in time.
This resulted in 98 deaths. While safety design considerations are necessary in electronics, vehicles, furniture, toys, medical devices, pharmaceuticals and appliances, it rarely became an engineering discipline itself. One of the primary challenges being building a language for quantifying and communicating “safety” among engineers and operators in the field.
In 2017, multi million of units of chest drawers were recalled by a famous furniture giant as per the US CPSC, Consumer Protection Safety Commission's website. The reason was tip-over hazard and people especially kids were seriously injured.
ASTM International develops voluntary furniture safety standards, which the U.S. Consumer Product Safety Commission (CPSC) can adopt as mandatory regulations, such as ASTM F2057-23 for clothing storage units, to address hazards like tip-overs and ensure structural integrity, durability, and the minimization of injury risks in furniture design. These standards cover various furniture types, including children's furniture, and involve rigorous testing to assess stability, mechanical hazards, and overall safety performance.
Everything has units of measure, but it is difficult to communicate how much safe a specific system is under given circumstances. What differentiates between a safe product and a product that can fail unpredictably? However companies and engineers often struggle to understand and quantify safety. It only becomes an afterthought after an incident from a product user. Most safety related aspects don't fall under quality control regime and escape the test and validation cycles.
So safety becomes an implicit effort with well defined intentionality, that needs to be captured in the PRD, product requirement document itself. Thus safety is a requirement. We will quickly discuss different methods of quantification and then dive into this novel method called GSN, Goal structured notation.
Prepare and prevent, don't repair and repent.
Quantifying safety means putting a number on how safe something is. It's like giving a "safety score" to a product, a workplace, or a process. There are two main ways to do this: predicting the future before something is used and tracking the past while it's in use. At Azle we are constantly learning and improving our application of ASEE process, born from systems thinking and systems engineering principles.
The method of predicting the future is applicable to designing things such as hardware, software or a bridge. Engineers can access methods to figure out how safe something will be before it's ever built or sold! They try to calculate the odds of something bad happening by careful technical thinking.
A. Predicting the Future (For Designing Things)
Working Backward from Disaster (Fault Tree Analysis): Imagine the worst possible outcome, like a drone falling out of the sky. Engineers then work backward to map out every single tiny thing that could have led to that disaster, like a dead battery, a broken propeller, or a software bug. By knowing the chances of each small failure, they can calculate the overall odds of the big disaster.
Giving Problems a "Danger Score" (RPN, Risk Priority Number): For every way a product could fail, engineers give it three scores from 1 to 10:
Severity: How bad would it be if this happened? (1 = no big deal, 10 = catastrophic)
Occurrence: How likely is it to happen? (1 = extremely rare, 10 = will happen often)
Detection: How easy is it to spot the problem before it causes a failure? (1 = obvious, 10 = impossible to detect)
They multiply these three numbers to get a Risk Priority Number (RPN). A high RPN means it's a very dangerous problem that needs to be fixed immediately.
B. Tracking the Past (For Operational environments & Workplaces)
These methods are like a "report card" for safety in a place like a factory or construction site. They track how many accidents have already happened to measure how safe the environment is.
Injury Rates (Lagging Indicators): This is the most common method. It's a simple idea: how many people got hurt for a set amount of time worked? The most common one is the Total Recordable Incident Rate (TRIR). It answers the question, "For every 100 employees working a full year, how many had an injury that required medical attention?" A lower number is always better.
Effort Scores (Leading Indicators): Instead of just counting accidents after they happen, this method tracks the effort being put into preventing them. It's a way of predicting future safety. Examples include:
Number of Near Misses Reported: How many times did workers report a "close call"? A high number is actually good—it means people are paying attention and reporting problems before someone gets hurt.
Safety Training Completed: What percentage of employees have finished their required safety courses?
Safety Issues Fixed: How quickly are reported safety problems (like a slippery floor) getting fixed?
By using these methods, companies and engineers can move safety from a vague feeling to a concrete number that can be measured, tracked, and improved.
Probabilistic assessment & Performance Indicators
Quantifying safety involves using quantitative metrics and engineering analysis methods to assign a numerical value (like a probability, a rate, or a cost) to the level of risk or safety within a system, process, or operating environment. These methods fall into two main categories: Probabilistic Risk Assessment (used in engineering design e.g. a drone) and Performance Indicators (used in operational environments e.g. the operational airspace in which the drone is flying).
A. Probabilistic Risk Assessment (PRA) Methods (Design/System Safety)
These methods are used, especially in complex, safety-critical systems (like aerospace, nuclear, and automotive), to determine the likelihood of a dangerous event. Risk is quantified as:
Risk = Probability (or Frequency) of an Event × Magnitude of Consequence (Severity)
The key techniques used to calculate the "Probability" include:
A. Fault Tree Analysis (FTA) A top-down, deductive graphical method that starts with an undesired top event (e.g., "System failure resulting in explosion"). It then uses Boolean logic (AND/OR gates) to trace all possible combinations of component failures, human errors, and external events that could lead to that top event. Quantification happens by assigning a known or estimated failure probability to each basic component (often expressed as λ, the failure rate per unit time), the FTA mathematically calculates the overall probability of the top event occurring.
B. Event Tree Analysis (ETA) A bottom-up, inductive graphical method that starts with an initiating event (e.g., "Power loss to critical component"). It then models the sequence of subsequent system and safety feature responses, leading to a set of different possible final outcomes (e.g., "Safe shutdown," "Accident," "Catastrophic failure"). ETA uses the probabilities of successful or failed system responses to determine the overall probability of each final outcome.
C. Failure Mode, Effects, and Criticality Analysis (FMECA) This systematic method identifies all potential failure modes (how a component could fail, e.g., 'short circuit'), their effects on the system, and assigns a Severity, Occurrence, and Detection score. The quantification happens by the scores are multiplied to get the Risk Priority Number (RPN). The RPN provides a prioritized, quantified list of risks that need mitigation.
RPN = Severity × Occurrence × Detection
D. System Safety Metrics: These are common quantitative goals used in system design:
Failure Rate (λ): The frequency with which an item fails (e.g., failures per million hours of operation).
Mean Time Between Failures (MTBF): The average time a system operates before a failure occurs. This is a measure of reliability.
Probability of Failure on Demand (PFD): The likelihood that a safety system fails when it is needed (critical for systems that are dormant, like emergency brakes).
Safety Integrity Level (SIL): A discrete level (1 to 4) of probability of failure for a safety function, used in standards like IEC 61508.
GSN, Goal Structured Notation
We have seen methods of quantifying safety and using those metrics in product design and field operations. But we have not dwelled into how these are communicated with different stakeholders.
Goal Structuring Notation (GSN) is a graphical argumentation notation used to visualize and structure arguments, particularly in safety-critical systems. It provides a clear and concise way to show how evidence supports claims, and how those claims contribute to overall safety goals. GSN diagrams facilitate collaboration and review. They can be shared and discussed among stakeholders to ensure consensus on safety arguments. While GNS system is greatly useful in designing an eVTOL aircraft, the merits go beyond aerospace or medial applications. At Azle we deploy GSN themes even for smaller electronics. It is part of our ASEE process.
Goal Structured Notation (GSN) is a way to clearly and formally show that a system is safe or meets some other important requirement. Think of it as a specialized, rigorous argument map for safety-critical systems. It was developed primarily in the UK by researchers at the University of York's High Integrity Systems Engineering group. GSN provides a graphical way to structure and present the arguments, goals, and evidence needed to make a safety case, which is essentially a structured body of evidence that proves a system is safe for use under defined conditions.
Why use GSN?
Imagine trying to convince a skeptical boss (or a regulator) that a new autonomous car is safe. You wouldn't just say, "Trust me." You'd need to show how you know it's safe. GSN helps you map out that entire convincing process so anyone can follow your logic.
GSN makes the safety argument:
Explicit: It leaves no doubt about what you are trying to prove.
Clear: The graphical symbols make the structure easy to follow.
Complete: It forces you to identify all the evidence you need and all the steps in your reasoning.
Reviewable: It makes it easy for others to audit and find any potential weak spots.
The building blocks of GSN
GSN uses specific shapes (like a flowchart) to represent the different parts of the argument. The main elements are: Goals, Strategies, Solutions or Evidence, Contexts, Assumptions, Justifications. Further these elements are linked using two types of relationships: SupportedBy and InContextOf.
Goals
Represented by a rectangle, a Goal is what you're trying to prove. It's the central claim of the argument.
Example: G1: The system is acceptably safe. Drone can tolerate single component failure.
2. Strategies
Represented by a rhombus or rounded rectangle, a Strategy explains how you will break down a Goal into smaller, more manageable sub-goals. It's the reasoning step.
Example: S1: Argue by dividing the system into its hardware, software, and operational procedures.
3. Solutions or Evidence
Represented by a circle, a Solution is the concrete evidence that directly supports a Goal or Strategy. This is the hard data.
Example: E1: Hardware Failure Report (Document ID: HFR-001).
4. Context
Represented by an oval rectangle, a Context provides necessary background information for understanding a Goal, Strategy, or Solution. This could be definitions, assumptions, or standards.
Example: C1: Acceptable safety is defined as a failure rate of less than indicated in Section 10.
5. Assumption
Represented by an oval rectangle, a Context provides necessary background information for understanding a Goal, Strategy, or Solution. This could be definitions, assumptions, or standards.
Example: A1: Secondary battery will maintain voltage stability within 5%
How the arguments flow
The entire GSN diagram works like a hierarchy:
Start with the Top Goal (e.g., "The airplane is safe to fly").
Use a Strategy to break that Goal down into smaller, simpler Sub-Goals (e.g., "Prove the wings are safe" AND "Prove the engine is safe" AND "Prove the flight control software is safe").
Continue this breakdown until you reach a Sub-Goal that can be directly supported by Evidence (a Solution).
When you look at a GSN diagram, you are tracing the argument from the evidence up to the top claim. If all the evidence is valid, the entire system is proven.
A Simple Example: A Safe Toaster
Let's use a very simple example to see GSN in action: proving a new smart toaster is safe.
Top Goal
G1: The Smart Toaster is safe for domestic use.
Strategy (Breakdown)
S1: Argue by dividing safety into electrical safety and fire safety.
Sub-Goals
G2: The toaster presents no electrical shock hazard.
Context: C2: Based on the IEC 60335 standard for household appliances.
G3: The toaster does not pose an undue fire risk.
Supporting Evidence (Solutions)
To support G2 (Electrical Safety), you might link directly to evidence:
E2: Compliance Certificate from UL Testing Lab.
To support G3 (Fire Risk), you might need another strategy:
S2: Show that the heating element is thermally regulated and the casing is non-flammable.
This leads to final evidence:
E3: Thermal Cut-Off Test Report.
E4: Casing Material Flammability Data Sheet.
In a full GSN diagram, all these boxes would be connected by lines showing the logical relationships (e.g., G1 is supported by S1, S1 decomposes G1 into G2 and G3, etc.). By following every path down to a circle (the evidence), you can be confident that the entire argument holds together. GSN simply provides the map for that confident conclusion.
Google Sites
Report abuse