The Safety Case Never Stops Learning

The V-model is a centerpiece in functional safety. Requirements and design run down the left side, verification and validation climb the right, and every test traces back to the requirement it proves. It is a clear, disciplined way to bring a system to certification, and experienced safety engineers recognize it as the industry standard in functional safety.

The V describes how a system is developed. It says much less about what happens once that system is running in the world, generating evidence every day, and evidence that can potentially impact the safety case. This is where a new model becomes useful.

From a V to an O

The V has a beginning and an end, but as we've discussed previously in last week’s article The Living Safety Case, the safety case doesn't ever really cross the finish line. After deployment, a system enters a long stretch of life the V doesn't picture: overall operation, maintenance and repair, and modification. Robots run shifts in conditions no lab fully reproduced. Technicians replace worn parts, sometimes with components that aren't identical to the originals. Engineers push fixes and add features. Each of these touches the safety case. A repair can change a failure rate, a modification can move a hazard or introduce a new one, and even routine operation produces evidence, like near misses and unexpected behavior.

In short, evidence keeps arriving after certification. So rather than a V-model, we've started thinking of the safety lifecycle as an O-model (see Fig. 1), an iterative loop that continues for the duration of the autonomous system's operation, and even decommissioning. The O is simply a picture of a feedback loop that already exists in practice.

The Living Safety Case = The O Model

None of this is new to the standards. As the first piece in this series described, IEC 61508 carries the safety lifecycle through operation, maintenance, and modification (see Fig. 2).

Other standards, like ISO 21448, which addresses safety of the intended functionality, go further. ISO 21448 calls for a field monitoring process, planned before release and run during operation, so that hazardous scenarios nobody foresaw are caught and fed back into the analysis. The loop is written down. The challenge is running it.

What it looks like when evidence flows back

The O-model illustrates more than a robot's safety case after deployment. The same loop runs during development, where verification and validation results flow back into the requirements they test. For example, a team tightens a safety requirement, shrinking the protective zone around a mobile robot from three meters to two so it can work more efficiently in tight aisles. That night, automated simulation runs the new configuration, and in one scenario the robot fails to stop in time when a simulated worker steps out at the end of an aisle.

In a loop, that failure does not sit in a test report waiting for someone to notice. It logs straight back against the requirement that changed, so the team sees the cause and the consequence side by side. The requirement gets revisited, the zone is adjusted, and the safety case records why (see Fig. 3).

After deployment, the loop works the same way. A repair with a non-identical part, a modification that moves a hazard, a near miss on the warehouse floor: each should find its way back to the requirement, safety function, or hazard it concerns, just as the simulation failure did. In both cases, the connection depends on something unglamorous: knowing, at all times, which requirement a test verifies, which safety function that requirement supports, and which hazard the function mitigates.

The safety case has always worked this way, as a feedback loop that runs from development through the life of the system. What has changed is the industry around it. With Industry 4.0, automation and physical AI generate more evidence, from more sources, more often, and a safety case maintained in spreadsheets takes more manual effort to keep current with each pass around the loop. As robotics matures, and safety teams mature with it, naming that loop out loud makes it easier to plan for, staff, and build tools around (see Fig. 4).

Naming the loop also changes how a team treats new information. In a linear process, a test failure or a near miss becomes a ticket: investigated, resolved, and closed, while the safety case never hears about it. In a loop, the same event becomes a trigger that raises the question from the first piece in this series: does this reopen the risk assessment, or does it only call for a targeted retest? Most events will not reopen anything. The point is that each one gets looked at, so the ones that matter do not slip through.

Why the loop raises the stakes on traceability

Thinking of the safety case as a loop puts new weight on traceability. A loop only works if evidence can travel, and evidence travels poorly when the safety case is scattered. Hazards in one spreadsheet, requirements in another tool, test results in a third, field data in systems the safety team rarely sees: every pass around the loop means stitching those pieces back together by hand.

That is the case for bringing the artifacts of the safety case into one connected workspace, where a hazard, the safety function that mitigates it, the requirements behind that function, and the tests that verify them all sit side by side. When new evidence arrives, whether from a simulation run or a repair in the field, it has an obvious place to land, and everything it touches is visible at a glance.

Building toward the loop

Closing the loop does not require a new standard or a new philosophy. It requires three practical things: traceability that keeps hazards, safety functions, requirements, and tests connected; a way to bring new evidence, whether from tests, changes, or the field, back to the right place in that chain; and a functional safety management process that defines who reviews that evidence and how decisions get recorded.

The V brings a system to certification, and it remains the right way to build one. The loop is what keeps that certification meaningful as the system lives in the world.

Next in this series: what a safety case is actually made of, and why every link in the chain matters.

Fennec Engineering is a team of functional safety engineers who build software. The ASAP Platform connects hazards, safety functions, requirements, and tests so new evidence has somewhere to go.