All Posts

Introduction An FMEDA (Failure Modes, Effects and Diagnostic Analysis) is the quantitative sibling of the FMEA we've written about before. Doing an FMEDA on a circuit means going through every component and asking how this fail could, and what is the effect. We then need to determine the immediate effect of the failure and the overall effect on the system We'll use one example throughout: A battery voltage monitor. A 12 V battery feeds a resistor divider R1/R2 (see figure bel

What is a Reliability Block Diagram (RDB) An RBD is a graphical diagram to qualitatively and quantitatively determine the overall reliability of a system. This helps identify the overall success or failure rate of a system in deployment. The RBD shows the essential components that contribute the success of the system. How to create one? Let's build an example! Consider a simple lightbulb circuit (Fig 1). There is a battery powering a lightbulb through a switch and a current l

A safety analysis is a structured way of looking at a system to find out what could go wrong, how bad it would be, and what needs to be done about it. It starts with understanding the system, then works through finding hazards, judging their risk, adding protections, checking the protections work, and writing everything down. The goal is to catch problems before they happen, rather than reacting to them after an accident. Some of the most common safety analyses are HARA FMEA

Every engineered system fails eventually. Reliability engineering is the discipline of quantifying when and how often they fail, turning vague intuitions about durability into numbers you can design against. This post walks through the core terms in reliability/ safety engineering and their mathematics: the failure rate, the reliability and failure functions, the meaning of MTTF and MTBF, and how to combine component numbers up into a system-level estimate. Failure Rate The f

Introduction The Failure Modes, Effects and Diagnostic Analysis (FMEDA) is where an ISO 26262 safety case gets its key numbers. It looks at each component, its possible failure modes, the effect of each failure on the safety goal, and whether a diagnostic can detect it. From this table, we calculate SPFM, LFM, and PMHF. Yet for most teams, FMEDA is still a manually built spreadsheet. It can take weeks to create and is painful to update after a design change. The two hardest q

In the previous blog, we talked about the mathematics behind different gates in a Fault Tree Analyses. In this blog, we talk about what the results from an FTA mean. Which failures matter most: importance measures Once you can compute the top-event probability, you can ask the next question: Which basic event is actually driving the risk? This is what importance measures quantify, and they're how engineers prioritize. The Fussell-Vesely (FV) measure: the most commonly used, t

In a previous blog post, we have discussed how a fault tree is built, a top-down map of how a system can fail, starting from the worst outcome and branching down to root causes. A tree like that tells you how a system can fail and where its weak points are. But it leaves a crucial question unanswered: how likely is that failure, really? Is the top event a one-in-a-thousand risk or a one-in-a-billion one? Answering that is the job of quantitative fault tree analysis, and it's

While building SLIKWORKS, we used AI to automate much of the safety analysis work. Along the way, we encountered a number of challenges in applying LLMs and other ML models to this domain. These challenges are described in more detail in our SAE publication - AI-Powered FMEA in the Safety-Critical Industry. Below, we outline some of the key challenges we faced. Fig: AI tool challenges in mission-critical systems Hallucinations in LLMs Hallucinations in LLMs refer to instances

In the previous blog post, we looked at the different layers of an operating scenario. In this blog post, we will look at the different abstraction levels, and why it matters for ISO 26262 HARA and SOTIF HARA. The Three Abstraction Levels of Operating Scenarios Each operating scenario can be described in 6 layers as described in the the previous blog post. In addition, each operating scenario can be described in 3 different abstraction levels. Functional scenarios - They are

Why Scenarios Need a Format You cannot test an automated driving function against "traffic." The real world offers an effectively infinite set of situations: every combination of road layout, weather, other vehicles, and split-second timing is its own test case. Scenario-based safety is the industry's answer to that problem, but it only works if scenarios are described in a structured, repeatable way. Without a common format, one engineer's "car cuts in ahead" is another's "a

In the previous blog post, we talked about what a SOTIF HARA is and what is the process to create one. This this blog post we talk about acceptance criteria for SOTIF. Acceptance Criteria: The New Discipline If "unreasonable risk" is the question, Acceptance Criteria (AC) is what makes the answer defensible. AC is the quantified definition of acceptable: a measurable threshold the system must demonstrably meet before its residual risk can be called reasonable. This is what se

Hazards that are not due to malfunctions Classical functional safety assumes something "failed". A sensor failed, a wire shorted, a software routine crashed. ISO 26262 is built around this idea: identify the malfunctions, judge how bad they'd be, and engineer against them. But consider a perception system that saw the road exactly as designed and still failed to recognize a stationary truck in dense fog. Nothing malfunctioned. Every component behaved to specification. The sys

In the previous blog post, we talked about the theory behind the FTA. In this post, we are going to do a concrete example of an FTA A quick example: "Vehicle does not steer" To see how the pieces fit together, take a safety-critical top event from an automated vehicle: the vehicle does not steer. Loss of steering can happen in several independent ways, so directly beneath the top event sits an OR gate: any one branch alone is enough to cause it. Fig: FTA example The first bra

Before a passenger jet, a nuclear reactor, or a car's braking system is ever trusted with human lives, engineers sit down and ask a simple question: what would have to go wrong for this to fail catastrophically? Not "will it fail," but "what exact combination of smaller faults would it take." Answering that question rigorously is the job of Fault Tree Analysis (FTA), one of the most widely used safety and reliability techniques in engineering. What is an FTA ? Fault Tree Anal

Failure Mode and Effects Analysis, or FMEA, is one of engineering's most important safety tools, also and one of its most tedious. In safety-critical industries like automotive and aerospace, building a single FMEA can take an experienced engineer weeks, and most of that time is spent not on analysis but on documentation: typing out failure modes, copying effects and causes, and arguing over risk scores. At SafeLink Innovations, we asked a different question: what if an AI co

Before one deploys a mission-critical system, a simple question has to be answered: what are the safety risks possible in the system? Miss a risk, and it ships into production undetected, awaiting a hazard in the field. Overstate a risk, and millions of dollars are spent in over-protecting a feature that didn’t need it. Every safety budget, every redundant sensor, every line of certified code traces back to how well that question is answered. In ISO 26262, the structured proc

As more safety engineers explore how large language models (LLMs) can support their work, a number of questions come up again and again. Below, we've gathered the ones we hear most often about SLIKWORKS specifically, as well as other LLMs in safety engineering. Our aim is to give you clear answers so you can decide what's right for your team. Does SLIKWORKS support EU GDPR compliance? Yes. SLIKWORKS is built to be GDPR-compliant out of the box, and we've designed our data han

The Origins: Systems Theory Safety engineering has always had to keep pace with the complexity of the systems it protects. In the 1940s and 50s, as nations raced to develop some of the most intricate technologies ever built, Intercontinental Ballistic Missile (ICBM) systems and Early Warning Systems (EWS), traditional approaches to failure analysis quickly revealed their limits. These were not machines where you could simply point to a broken part and trace back a failure. Th

HAZOP (Hazard and Operability Study) was originally developed for the chemical process industry, where facilities routinely handle hazardous materials. In such environments, even small malfunctions in manufacturing processes can lead to serious safety incidents. The methodology was first developed in 1961 as a structured way to systematically identify hazards and operability issues in complex industrial processes. Over time, the approach matured and was formally standardized

THE SAFETY PARADOX The best safety systems aren’t just good at responding to problems, they prevent problems from occurring in the first place. Modern cars have sensors that prevent you from colliding into obstacles. Planes have systems that won’t let pilots make dangerous maneuvers. But, the software that run these safety systems might not have the same kind of built-in safeguards. C and C++ are the programming languages that power most safety-critical systems from aut