Functional Safety Was the Finish Line. Now It’s the Starting Gate.
The Dangerous Gap Between Documentation and Reality
The functional safety world loves its vocabulary. ISO 26262, ASIL decomposition, hardware-software partitioning, fault-tree analysis, FMEDA tables, safety goals, safety cases, safety of the intended functionality through SOTIF, cybersecurity overlays like ISO/SAE 21434, and the comfort blanket of V-models. For two decades, this scaffolding has given automakers and suppliers a framework to point to when boards ask if their systems are safe. It is rigorous, structured, and auditable. It is also dangerously insufficient.
ISO 26262 taught the industry to reduce risk to an “acceptable” level, and to prove that reduction through quantitative targets. It gave everyone a lexicon for Automotive Safety Integrity Levels, with ASIL D reserved for the most critical functions. It drove processes like FMEA and FMEDA into design reviews and kept auditors in business. SOTIF stepped in to cover scenarios where the system functions as designed, but the intent itself was unsafe, such as an autonomous vehicle interpreting a shadow as a solid object. ISO/SAE 21434 gave cybersecurity a foothold by insisting that threat analysis and risk assessments belong alongside safety cases. These frameworks were necessary, even overdue, when they arrived. They professionalized safety engineering in a software-defined era.
The problem is that the FuSa community now treats these standards as if they were the destination, not the starting point. An ISO 26262 certificate is brandished as if it guarantees real-world safety. A system with completed hazard analysis and risk assessments is assumed to be robust, even though that analysis was based on models and assumptions that collapse under the weight of reality. The audit trail becomes the achievement, rather than the outcome. What happens when the FMEDA was scoped to yesterday’s failure modes, but tomorrow’s integration introduces behaviors never imagined? What happens when ASIL decomposition was crafted to balance cost and compliance, not true operational assurance? The industry pretends that its box-checking is equivalent to resilience. It isn’t.
Consider Tesla, forced to issue over-the-air recalls that now affect millions of vehicles because software features did not behave safely in the real world. Every one of those systems went through hazard analysis and verification steps, and every one of them looked compliant until the fleet data told a different story. The FuSa scaffolding could not prevent a gap between design-time proof and runtime truth. Or take the wave of software-driven recalls across every major OEM in 2024, where infotainment failures cascaded into critical subsystems because integration boundaries were never stress-tested under continuous conditions. Again, standards were followed. Safety cases were signed off. Yet failures reached customers.
If standards were enough, we would not be talking about unintended acceleration crises, Toyota’s electronic throttle debacle, Boeing’s MCAS disaster, or Colonial Pipeline’s ransomware paralysis. Each of those organizations had reams of compliance documentation, layers of safety assurance, and auditors signing off on their diligence. What they lacked was a system of continuous operational assurance that spanned design, validation, deployment, and in-life monitoring. They had static safety. What they needed was dynamic safety.
This is where the industry must grow up. The FuSa world has convinced itself that coverage equals control. Coverage is valuable, but it is retrospective. It maps what you already think might fail. Control requires confronting the unknown. It means accepting that integration is not just a line item in a V-model diagram, but the single greatest source of risk in a connected, software-first system. It means treating safety cases not as an archive, but as a living chain of evidence that can be interrogated in real time, what I call the Software Chain of Record. It means shifting from a mindset of “prove to the auditor we did our diligence” to “prove to ourselves and to the public that our system is continuously safe.”
This does not erase ISO 26262, SOTIF, or ISO/SAE 21434. They remain essential as scaffolding, as the grammar of safety. But they are not the language of assurance. They tell us how to structure requirements, not how to validate behaviors that emerge when dozens of suppliers’ codebases collide inside an electric vehicle architecture. They tell us how to calculate ASIL decompositions, not how to ensure an over-the-air patch does not cascade into a driveline fault two months later. They tell us how to document failure mode analyses, not how to capture evidence of resilience under chaotic real-world conditions.
The uncomfortable truth is that functional safety as practiced today cannot scale to the complexity of the systems it is meant to govern. The deeper truth is that executives know it. That is why boards quietly panic every time a new recall explodes across headlines. They know they can produce binders of compliance evidence, but they also know that when the system fails in public, those binders will not shield them from blame. Regulators, courts, and customers do not care that your FMEDA was thorough. They care that your product failed.
Operational Assurance is the only path forward. It integrates FuSa standards but refuses to stop there. It builds continuous validation into the architecture, not just late-stage testing. It treats integration as a core discipline, not a project milestone. It applies the same versioning and traceability rigor to physical components that software engineers demand of code, what I call Physical Components as Code. It builds a living Software Chain of Record that spans requirements, models, binaries, and runtime telemetry. And it forces leadership to stop treating safety as an engineering problem alone, because safety failures are business failures.
The FuSa community craves the comfort of standards. That craving is understandable. Standards feel like solid ground in a shifting industry. But the ground is already crumbling. Every high-profile failure is evidence that compliance does not equal assurance. The finish line that functional safety once represented is gone. It is now the starting gate. The question for automakers and suppliers is brutally simple: will you keep playing buzzword bingo with ISO clauses while your systems stumble in public, or will you embrace Operational Assurance and build resilience into the heart of your business?
History is unkind to those who confuse documentation with control. The verdict will not be written in your safety cases. It will be written in your failures.
#functionalsafety #iso26262 #softwaredefinedvehicle #operationalassurance #beyondcompliance #safetyculture #fusa
Michael Entner-Gómez is a strategist, technologist, and writer focused on the convergence of the world's most critical infrastructure sectors: energy, transportation, and telecommunications. Using a systems-thinking approach, he helps industry incumbents and disruptors future-proof their operations, scale complex platforms, and navigate the shift to software-defined everything.
This article is not sponsored, not paid, and not written to please. It’s written to inform.