All Posts

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