Why Toyota’s software is not a killer
Article By : David Cummings
After delving deeper into the Toyota testimony, embedded systems expert David Cummings has found there was no credible theory based on evidence.
In 2013, an Oklahoma jury found that Toyota's embedded software was to blame for unintended acceleration that resulted in a fatal accident. The embedded software expert who convinced the jury that software was to blame made his trial testimony and slides available to the public and invited us to "judge for ourselves." A flurry of articles in technical publications followed, most of which (to the best of my recollection) described the expert's testimony in favourable terms, accepting the conclusion that software caused the accident. Many of these articles had attention-grabbing titles such as Toyota's killer firmware and Toyota Case: Single Bit Flip That Killed.
Having developed embedded software for many years, and having written an opinion piece in the Los Angeles Times years before the trial about the possibility that Toyota's software was to blame for reported incidents of unintended acceleration, I read the expert's testimony with great interest and excitement. I was expecting to find a convincing argument based on the evidence that the software was indeed to blame for the accident in question.
As I delved deeper and deeper into the testimony, however, my excitement turned to disappointment. It became clear that there was no credible theory based on the evidence. I felt it was important to set the record straight, and so I submitted an article with my technical analysis to the IEEE Technology and Society Magazine. That article was peer reviewed and then accepted for publication in their December 2016 issue.
In this column, I summarise some of my findings (please refer to the IEEE article for a more complete discussion that includes all the technical details).
As discussed in the IEEE article, the plaintiffs convinced the jury that Toyota's embedded software was responsible for the accident by employing the following approach:
First, they bombarded the non-technical jury with criticisms of the quality of Toyota's software from two different software experts. The first expert did not see any of Toyota's source code, but nonetheless his entire testimony, which is also publicly available, was directed toward criticising the quality of Toyota's software. As anyone with extensive experience developing real-world software knows, software quality assessments can be highly subjective.
The second of the two experts, who did examine Toyota's source code, also criticised the quality of Toyota's software. Then he told the jury that "to a reasonable degree of engineering certainty, it was more likely than not" that the death of a task running on the engine control processor (referred to at trial as "Task X") was responsible for the accident, despite the fact that the evidence presented at trial did not support that conclusion.
According to the testimony of the second expert, Task X is a periodic task that executes multiple times per second. One of its many responsibilities is to determine the correct throttle angle setting (how far open the throttle should be) based on how hard the driver is pressing on the accelerator pedal (as well as other factors). Therefore, multiple times per second, Task X wakes up and, among other things, determines the current accelerator pedal position and sets a throttle angle variable accordingly. The throttle angle variable is then used by another part of the software to set the throttle to the angle specified in that variable.
The expert identified a specific bit within an operating system data structure on the engine control processor (the main CPU) that determined whether Task X was alive (schedulable) or dead. According to the expert, this data structure (as well as the throttle angle variable) was not protected by software techniques such as mirroring, or by hardware techniques such as error detection and correction. Therefore, if this data structure became corrupted, the corruption would not be detected or corrected. The expert theorised that the bit for Task X in this data structure was erroneously flipped from one to zero due to a software bug or single event upset (SEU), and that this caused the accident, as described in the next page.