IEEE Technology and Society Magazine - December 2016 - 77

roduct liability trials involving embedded software, such as those in
which an automobile driver alleges
that faulty embedded software was
responsible for an accident, require
the same standard of proof as other
civil trials. The plaintiff must convince
a jury that the defendant (for example, the automobile
manufacturer) more likely than not is responsible for
the accident [1]-[4].1 This includes showing that the defendant failed to fulfill their duty, and that the defendant's failure was the cause of the accident (causation) [5]-[12]. The defendant may offer evidence to
counter the plaintiff's arguments. For example, if the
plaintiff's technical expert testifies that in his/her
opinion it is more likely than not that a specific problem in the defendant's embedded software caused the
accident, the defendant might identify flaws in the
analysis. As will be shown, when a non-technical jury
in such a trial is confronted with complex software issues, the verdict they deliver may not be supported by
the facts. The jury can get it wrong.
It is well known that nearly all non-trivial software
has bugs [13]-[15]. Furthermore, because there are virtually an infinite number of different ways of solving a
non-trivial problem using software, one can often find
many opportunities for criticizing software quality,
sometimes using criteria that are highly subjective. As a
result, the plaintiffs in a software trial can be expected
to attack the defendant's software by looking for bugs
and criticizing the software's quality. If they can find
bugs, and show that more likely than not those bugs
caused the accident, then they can establish causation.
They can also use purported measures of software
quality, which may be subjective, to argue that the
defendant failed to fulfill their duty to provide software
of sufficient quality.
This can present unique challenges in software
cases. The plaintiffs' expert can bombard a non-technical jury with criticisms of the defendant's software
that sound convincing, but which may or may not be
justified because of the subjective nature of many
such criticisms. He/she can then conclude that
because the defendant's software is substandard, it
is more likely than not that it was responsible for the
accident. The problem with this line of argument is
that even if bugs or design flaws are found in the
defendant's software, this does not mean the software
caused the accident. The plaintiffs may not have fulfilled
their responsibility to show a connection between the

1
"More likely than not" is sometimes described as "at least 51 percent of
the evidence favors the plaintiff's outcome" [3], or "the evidence shows the
defendant is more than 50% likely to be responsible" [4].

DECember 2016

∕

potential bugs and the accident. The plaintiffs' expert
may convince him/herself that they have found the
cause of the accident, when all they have really found
are potential bugs unrelated to the accident. Alternatively, the plaintiffs' expert may realize that they have
not found a credible connection between the potential bugs and the accident, but they are willing to tell
the jury that more likely than not those bugs are
responsible for the accident. (That would be a violation of ethical standards including IEEE ethical standards [16] and ACM ethical standards [17].) Either
way, the jurors are told by an expert that problems
were found in the software, and in the expert's opinion it is more likely than not that those problems
caused the accident.
In order to illuminate these issues, we will look at
a specific case, the 2013 Oklahoma trial in which a
jury determined that Toyota's engine control software was to blame for reported unintended acceleration that ended in a fatal accident. We are fortunate
in that one of the plaintiffs' software experts made
his trial testimony and slides available to the public
(see links below). This gives those of us in the engineering community a rare opportunity to get a firsthand look at the technical arguments that were
presented. The exper t's post-tr ial commentar y
included the following:
...The second round began with an over 750
page formal written expert report by me in
April 2013 and culminated this week in an
Oklahoma jur y's decision that the multiple
defects in Toyota's engine software directly
caused a September 2007 single vehicle crash
that injured the driver and killed her passenger.
...In a nutshell, the team led by Barr Group
found what the NASA team sought but couldn't
find: "a systematic software malfunction in the
Main CPU that opens the throttle without operator action and continues to properly control
fuel injection and ignition" that is not reliably
detected by any fail-safe. ...Now it's your turn to
judge for yourself. Though I don't think you can
find my expert report outside the Court system,
here are links to the trial transcript of my
expert testimony to the Oklahoma jury and a
(redacted) copy of the slides I shared with the
jury in Bookout et al. v. Toyota [18].
As the expert suggested, I examined his trial
materials and judged for myself. I had a particular
interest in this subject, having previously written an
opinion piece for the Los Angeles Times about
Toyota's investigation into the cause of reported

IEEE Technology and Society Magazine

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