IEEE Technology and Society Magazine - December 2016 - 78

unintended acceleration, and the possibility that
software was to blame [19]. Based on the statements made by the expert, including those above,
as well as favorable articles in various publications
describing his trial testimony, I expected to find a
convincing case built on compelling evidence that
there was indeed "a systematic software malfunction in the Main CPU" that directly caused the automobile accident. Unfortunately, I found instead a
disappointingly flawed theory of causation that is
not credible. (The National Highway Traffic Safety
Administration [NHTSA] apparently agrees with this
assessment [20].)

Product liability trials involving
embedded software require the same
standard of proof as other civil trials.

Thus, this trial serves as an informative case study
demonstrating how a jury can be led to an apparently
incorrect conclusion about software based on technical
arguments that sound convincing, but which do not
withstand technical scrutiny. And as we become increasingly reliant on embedded software in our daily lives, for
example, with the advent of self-driving cars, trucks, and
automotive "autopilot" features, our legal system is likely
to face this issue with increasing frequency.2
Since my review of the trial materials, my company
has been retained by several automobile manufacturers. Confidentiality agreements prevent me from revealing details about those engagements.

Background
I will refer below to the expert's trial testimony and
slides, which can be found at:
■ http://www.safetyresearch.net/Library/Bookout
_v_Toyota_Barr_REDACTED.pdf ("Testimony")
■ http://www.safetyresearch.net/Library/BarrSlides
_FINAL_SCRUBBED.pdf ("Slides")
The expert concluded that the accident was caused
by the death of a critical task within the engine control
software, which he referred to as "Task X." He testified:
So to a reasonable degree of engineering certainty, it's my opinion that it was more likely than not,
2

It remains to be seen if the new federal safety guidelines for autonomous
vehicles, not yet released at the time of this writing, will impact this issue.
As discussed in [19], stricter automotive safety guidelines are overdue.

a task X death, possibly in combination with other
tasks that occurred that day, causing a loss of
throttle control and in [sic] inability to stop the
vehicle's full momentum because of the vacuum
loss. [Testimony, PDF page 192.] See also Testimony, PDF page 187, and Slide 54.
This conclusion does not appear to be supported by
the evidence presented at trial.
Before examining the expert's conclusion in detail,
some background information about Task X, derived from
the above trial materials.3 is required. Also required is
background information, derived from the trial materials,
regarding a fail-safe called the "Brake Echo Check," which
is a key element of the accident theory involving the death
of Task X.
Task X is a periodic task that executes multiple times
per second on the engine control processor (the main
CPU). 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, every n ms4 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.
All the tasks running on the main CPU are managed
by a multitasking operating system. The operating system maintains a data structure containing one bit per
task. If the bit is set, the task is alive and is subject to
task scheduling. If the bit is clear, the task is not running and it will not be scheduled for execution. 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 due to a
software bug or a single event upset, the corruption
would not be detected or corrected.
There is a second processor called the monitor CPU
that executes the Brake Echo Check fail-safe software.
The Brake Echo Check is designed to behave as follows:
If Task X died, and if the driver then stepped on the
brake or released the brake, then about 200 ms later
the Brake Echo Check on the monitor CPU would detect
an inconsistency resulting from the death of Task X on
the main CPU, and would force the throttle to idle.
About 3 s later it would stall the engine. When the throttle is at idle, braking will successfully stop the vehicle.
3

I have not seen Toyota's source code. My descriptions of how Toyota's
software operates are based on the trial materials.
The Slides suggest that Task X runs every 8 ms [Slide 35].

IEEE Technology and Society Magazine

∕

DECember 2016

http://www.safetyresearch.net/Library/Bookout http://www.safetyresearch.net/Library/BarrSlides

Table of Contents for the Digital Edition of IEEE Technology and Society Magazine - December 2016