I've worked in automotive all my life. I had the lucky chance to work for a large Tier 1 supplier of test and engineering services that happened to also act as the project manager for the original MISRA project. Even now, I'm still finding there is more to learn about those early MISRA foundations.

The Foundations of Software Reuse: The 1994 Ideal

The original vision for reusing software was grounded in common-sense engineering. For example, the MISRA Development Guidelines For Vehicle Based Software (from 1994) explicitly laid out the framework for handling software reuse:

3.1.5 Reuse

3.1.5.1 "Off the shelf" (COTS) or commercially available components containing software to be used in a project should be assessed to the required integrity level, and such reuse of existing software should be considered on a case-by-case basis.

3.1.5.2 The software that is intended for reuse should be fully compliant with the requirements of the new system that it is intended to be used in.

3.1.5.3 Software that is intended for reuse, as with all software, should have a standard of documentation such that its functions and interactions are easily understood by people who may not have been the original authors.

3.1.5.4 Software that has performed faultlessly for a number of years in the field may well offer a greater level of confidence in the final product than a wholly new program, provided it is used within the limitations of its design and is not modified.

This maps perfectly to the core tenets of the Safety Element out of Context (SEooC) and the "proven in use" arguments that suppliers rely on today: you can reuse COTS software, but it must be assessed against the new system's requirements (3.1.5.2), and its limitations must be heavily documented for the integrator (3.1.5.3).

However, the modern interpretation—and the resulting liability shield—that we now understand as SEooC has moved a long way from the simple ideals proposed by engineers who just wanted to make safer products.

The Modern Paradox: Autonomy vs. Accountability

With the shift toward software-defined architectures, OEMs and suppliers are forced into a crippling contradiction.

The more an OEM tries to hand off autonomy to its suppliers—seeking to avoid rigid system specifications while pushing for shorter time-to-market and flexible architectures—the more suppliers increase the mountain of blame-shifting. Because you cannot always develop with full knowledge of future failure modes—such as employing AI on a car where you cannot predict every real-world reaction—suppliers are desperately trying to avoid liability for system failures they didn't design, for behaviors that were left unspecified, or for issues that could have been easily avoided with minimal architectural effort at the top level.

This creates a fundamental conflict: a competing desire to share the anticipated information that will be needed, versus the fear of unlimited liability if that information is incorrect, ambiguous, or incomplete. Ultimately, engineers realize that the more they write, the more vulnerable they are to legal exposure.

"SEooC has become the exact opposite of what was desired. It is now a tool for driving teams further apart, separating them behind mountains of paperwork containing far too many words for any integration team to realistically read."

The Weaponization of the Safety Manual

Consequently, SEooC has become the exact opposite of what was desired. It is now a tool for driving teams further apart, separating them behind mountains of paperwork containing far too many words for any integration team to realistically read in the time available.

This is certainly not what the original MISRA authors intended in 1994. The hope was for a free exchange of information and ideas—a list of "mutual to-do's," if you will. It was meant to be a mechanism where a supplier could flag something that was bothering them, so that an easier, safer solution could be engineered at the system level.

Instead, SEooC prevents that system-level discussion. It time-boxes problem-solving and denies suppliers a forum to ask for help for the overall good of the vehicle. As a result, everyone retreats to their silos, developing each isolated component as best they can, getting the features to *somewhat* work on time, while completely ignoring the reality of integration.

The software ultimately arrives at the OEM with a firm, defensive posture on safety. It comes paired with a massive safety manual and mandatory software test libraries that consume 75% of the CPU, yet the actual functions don't work when integrated. 

"The software arrives at the OEM paired with a massive safety manual and mandatory software test libraries that consume 75% of the CPU, yet the actual functions don't work when integrated."

When the entire focus of a rushed development cycle is getting the functionality out the door, how likely is it that the safety architecture is somehow mathematically perfect while the core features are broken?

Unvalidated Assumptions and the Recall Trend

Of course, the safety claims *need* to be "perfect" on paper, because that is the top contractual priority. Without that claim, a mountain of legal work is triggered to figure out who holds the liability. These siloed workflows have long been identified as the root cause of the vast majority of safety-related accidents, yet we continue to permit them under the guise of SEooC.

When an enormous amount of documentation is delivered with your SEooCs—even on a minimum-specification vehicle with the fewest number of modules—the sheer volume of reading already exceeds the time available, even if reading was all the engineering team did. 

So, these safety manuals and Assumptions of Use (AoU) are simply not being read. The assumptions go unvalidated, unchallenged, and ignored. The vehicle goes to launch with these unverified systems, and the industry recall trend continues to increase exponentially.

"Safety manuals and Assumptions of Use (AoU) are simply not being read. The assumptions go unvalidated, unchallenged, and ignored. The vehicle goes to launch with these unverified systems, and the industry recall trend continues to increase exponentially."

A Path Forward: Open Source and Genuine Collaboration

Another paradox is the industry's pushback against the use of open-source software for automotive safety tasks. Ironically, a well-maintained, lower systematic capability open-source repository easily fulfills the four reuse criteria recommended by MISRA all those years ago. 

More importantly, open-source offers a real chance for genuine collaboration among interested parties. It is a system built for the greater good, designed to avoid making the exact same mistakes again and again, rather than acting as a defensive liability shield.

How much longer will the big stick of liability be allowed to prevent engineers from doing what they naturally want to do? It is time to drop the legal shields, collaborate at the system level, and discover solutions that actually work in context.

Further reading:

• MISRA Development Guidelines For Vehicle Based Software.pdf (from 1994)
• ISO 26262: SEooC - Safety Engineering out of Control?
• https://www.codethink.co.uk/trustable-software-framework.html