I’m writing this in the plain on our way to Uganda :)
There’s been a lot of buzz lately about safety in the automotive world, and ISO 26262 often finds itself in the crosshairs. Some folks argue it’s overkill, too bureaucratic, or slows down innovation. As someone with a special interest in formal system modeling who was knee-deep in the practicalities of software qualification at Apex.AI and leading the Security, Quality and Safety team, I have a slightly different perspective.
Here’s my take on why ISO 26262, with all its strictness, is actually a good thing, especially for those of us wrestling with firmware, operating systems, and hypervisors on ARM architectures.
And spoiler alert:
It’s not the standard itself that’s the issue, it’s how you architect your software.
Decomposition and Freedom From Interference: Back to Basics
One of the fundamental principles of engineering safe systems is decomposition. We break down complex systems into smaller, more manageable components. But here’s the kicker: those components need to be independent. Errors in one shouldn’t cascade into others. This is where freedom from interference (FFI) comes in.
Think of the tragic collapse of the Baltimore harbor bridge. Damage to one pier brought down the whole structure. That’s a lack of FFI with devastating consequences.
In software, achieving FFI is tricky. It often requires leveraging hardware mechanisms like memory protection units (MPUs) and I/O MMUs. A trustworthy OS or hypervisor plays a crucial role in managing these hardware resources and enforcing isolation between software components.
ISO 26262 and the Beauty of Composability
This is where ISO 26262 shines. It encourages a structured approach to software development that aligns with these principles of decomposition and FFI. By mandating rigorous qualification for safety-critical components, it forces us to think carefully about how we architect our software and leverage hardware isolation mechanisms.
Yes, it can be demanding. But here’s the payoff:
- Reduced Risk: FFI minimizes the risk of errors propagating through the system.
- Effort Reduction: Only safety-critical components require the full ISO 26262 treatment.
- Increased Confidence: A well-defined architecture with strong isolation provides greater confidence in the system’s safety.
It’s About Architecture, Stupid!
The problem isn’t ISO 26262. It’s cramming a monolithic software blob into a single address space and then trying to shoehorn it into a safety-critical system. That’s like building a bridge with a single, massive pier and wondering why it’s unstable.
Embrace the principles of decomposition, leverage hardware isolation, and use a trustworthy OS. You’ll find that ISO 26262 becomes less of a burden and more of a guide to building truly safe and reliable systems.
Beyond Linear Equations
My background in formal modeling has instilled in me a deep appreciation for the power of composability. ISO 26262, in its own way, reflects that same philosophy. It’s not just about ticking boxes and generating documentation. It’s about building systems that are inherently safe, reliable, and maintainable. And that’s something worth striving for, even if it means a bit more upfront effort.
