By Michael Barr
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
The first safety-critical firmware I worked on had a watchdog timer, a set of self-tests, and a review process that felt, at the time, unusually strict. Years later I would spend a great deal of time reading other people's automotive firmware in litigation, and I learned something that surprised me: the strictness of a process tells you far less about the safety of the resulting product than most people assume, and the paperwork proving the process was followed is not the same evidence as the code itself.
That distinction is the whole subject of this article, because in automotive software cases both sides reach for the same document set and try to make it mean opposite things.
Modern vehicles run tens of millions of lines of code across dozens of electronic control units. When something goes wrong and the question reaches a courtroom, the parties converge quickly on ISO 26262, the functional safety standard for road vehicles. Plaintiffs point at gaps in it. Defendants point at compliance with it. Both are frequently overreading what the standard can establish.
What ISO 26262 actually is
ISO 26262 is a process standard. It describes a lifecycle for developing electrical and electronic systems in production vehicles: how to analyze hazards, how to derive safety requirements, how to allocate them to hardware and software, what verification is expected at each stage, and what documentation should exist to show the work was done.
Three things follow from that word, process, and all three matter in litigation.
It is voluntary, not law. ISO 26262 is an industry consensus standard. It is not a regulation and compliance is not legally mandated in the way emissions or crashworthiness requirements are. Treating it as though it were a legal requirement is an error that invites correction.
It governs how you develop, not how the product performs. The standard tells you to conduct a hazard analysis, not what your hazard analysis must conclude. It tells you to derive safety requirements, not what those requirements must be. A manufacturer can follow the process faithfully and still ship a defect, and a manufacturer can ignore the process entirely and ship something perfectly safe.
Its central artifact is a chain of reasoning. The hazard analysis and risk assessment identifies what can go wrong and how badly. From that comes an ASIL, a rating from A to D reflecting severity, exposure, and controllability, and from the ASIL come the rigor requirements applied to everything downstream. The chain matters more than any single document, because an argument about the product usually turns out to be an argument about where the chain was broken.
What the documents can and cannot establish
The document set in a well-run automotive program is substantial: the hazard analysis, safety goals, the functional and technical safety concepts, requirements at several levels, design documents, verification and test reports, tool qualification records, and a safety case tying it together. In discovery this is a large production, and knowing what each piece can support is the difference between an efficient analysis and an expensive one.
Traceability is the most useful thing in the set. The standard expects each safety goal to trace down through requirements to design to code to test, and back up again. Where that trace is complete, the defense has a strong story. Where it breaks, and it frequently breaks somewhere, the break is a factual finding an expert can describe plainly: this safety goal produced no requirement, or this requirement was never verified, or this code implements no requirement anyone can point to.
A gap is a gap, not a defect. This is the discipline that separates a credible expert from an advocate. Establishing that a requirement went unverified establishes exactly that. It does not establish that the software caused the incident. The causal chain from a process gap to the specific behavior the vehicle exhibited is a separate analysis, and it usually requires the code.
Conversely, a complete document set is not a defense to a code defect. If the software does something the safety concept says it must not, the existence of a well-organized safety case does not change what the software does. Process compliance is evidence about diligence, not about behavior.
The most common failure I see, on both sides, is treating the paperwork as a substitute for examining the software. The paperwork frames the questions. The code answers them.
ASIL, and the argument hiding inside it
ASIL determination is where a surprising number of automotive software disputes actually live, because the rating drives everything downstream. A function rated ASIL D attracts far more rigor than the same function rated ASIL A: stricter coding constraints, more demanding verification, more independence in review.
That means a defendant who assigned a low ASIL bought a lighter process legitimately, if the assignment was sound. Whether it was sound is a technical question about the hazard analysis: was the severity of the worst credible outcome assessed honestly, was exposure estimated from real driving conditions, and was controllability, the assumption about whether an ordinary driver can recover from the failure, defensible.
Controllability is the assumption most worth testing. It is the least measurable of the three inputs and the most convenient to assume favorably. An expert who can explain to a jury what the manufacturer assumed a driver would do, and whether that assumption was reasonable, is often doing the most consequential work in the case.
Where the code still decides it
Underneath the standard sits ordinary software engineering, and ordinary software defects. The failure modes that matter in automotive firmware are the ones that have always mattered in embedded systems: memory corruption, stack overflow, uninitialized data, race conditions between tasks, unhandled error paths, watchdog strategies that reset a system without recording why, and single points of failure in code that the architecture assumed were redundant.
None of these are visible in a safety case. They are visible in the source, and finding them is a source code review like any other, conducted by someone who has written firmware for constrained targets and knows what goes wrong there. Where the code is unavailable or incomplete, reverse engineering the shipped binary is sometimes the only route to the behavior, and it carries its own admissibility considerations.
Coding standards enter here too. Automotive programs commonly adopt a constrained subset of C and check it with static analysis. Whether the rules were actually enforced, and what was done with the violations that were found and waived, is a concrete and checkable question. A waiver log is an underrated document: it records what the team knew and chose to accept.
What each side tends to get wrong
Plaintiffs sometimes stop at the process gap because it is easy to explain and hard to deny. A jury can understand a missing test. But a gap without a causal link invites the obvious response, that the vehicle is not alleged to have failed in the way the missing test would have covered. The stronger structure connects the gap to a specific behavior of specific code in the specific incident.
Defendants sometimes lean on the volume and organization of the safety case as though completeness were the answer. It answers diligence. It does not answer what the software did. And a safety case that is internally inconsistent, where the code does not match the design it claims to implement, is worse than a thin one, because the inconsistency is itself a finding.
Both sides underestimate how much turns on version control. Vehicles receive software updates. The build in the accused vehicle at the time of the incident may not be the build the documents describe, and establishing which software was actually running is a threshold question that occasionally resolves the dispute on its own.
The expert's job
In an automotive functional safety matter the technical expert has to do four things, in order.
Establish what software was actually running in the vehicle at the time. Reconstruct what the system was designed to do, from the safety concept and requirements. Determine what the software actually does, from the code, independent of what the documents claim. Then, and only then, form an opinion about whether the difference between design and behavior explains the incident.
Experts who invert that order, forming the opinion first and assembling document support afterward, produce reports that do not survive deposition and cross-examination. Experts who never reach step three, and rest entirely on the documents, produce reports that a competent opposing expert will characterize as a paperwork audit rather than an engineering analysis.
What we do at Barr Group
Our electronics and software expert witnesses include engineers who have built and reviewed safety-critical embedded software, which is the background this work requires: the analysis lives in firmware for constrained targets, not in application software. We read the safety case for what it frames rather than for what it concludes, and we go to the code for the answers. We are explicit about the difference between a process gap and a defect, and about the causal work needed to connect them, because that distinction is where these opinions are attacked. Our involvement in vehicle software analysis is described in our expert witness case studies, and the same rigor carries into product liability and patent infringement matters involving automotive systems.
The takeaway
ISO 26262 is a valuable map of a development program and a poor substitute for reading the software. It shows you where to look, what should exist, and what the manufacturer told itself it was building. It does not tell you what the vehicle did. In a case that turns on automotive software, use the standard to frame the questions and the code to answer them, keep the distinction between a process gap and a defect scrupulously clear, and be certain, before anything else, that you know which build was running when it mattered.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.