IEEE Technology and Society Magazine - December 2016 - 79

Theory Regarding the Death of Task X
According to the accident theory presented to the jury,
the following 3 things had to happen together just prior
to the accident:
A) The bit corresponding to Task X in the operating
system data structure was somehow flipped from
one to zero, resulting in the death of Task X.
B) At the time of this bit flip, the throttle angle variable
maintained by Task X contained a large value, corresponding to an open throttle. Because Task X never
ran again, the throttle angle variable was stuck at this
value, and the throttle remained open.
C) The Brake Echo Check did not work for some reason.
When the driver stepped on the brake, the Brake
Echo Check did not correctly detect the inconsistency due to the death of Task X and force the throttle
to idle. Because the throttle remained open, the
driver was unable to stop the vehicle by braking.
Let's examine each of these:
■ A is merely hypothetical. No evidence was presented
that this bit was flipped prior to the accident,5 nor
was any specific bug in the software identified that
caused this bit to flip. Instead, the expert identified
what he said were a number of problems in the software that could possibly cause an unspecified memory corruption under some circumstances, which he
speculated might possibly include the corruption of
this bit. More detail will be provided below.
■ B appears to be inconsistent with the facts of the
accident. As will be shown, the driver was slowing
the vehicle on an exit ramp when the expert theorizes Task X died, and therefore the throttle would likely have been at idle.
■ C is merely hypothetical. Even if the bit flipped, and
even if the throttle was open when that happened,
there is no evidence that the Brake Echo Check,
executing on a different processor, would not have
worked correctly to force the throttle to idle. In fact,
as will be shown, the expert did not even speculate
at trial why the Brake Echo Check might possibly fail
under any circumstances. He simply asserted that it
was unreliable without providing any reasons. (He
said that his expert report contained reasons, but
he couldn't recall any of them [Testimony, PDF
page 147].) Moreover, as will be shown, all of the
Brake Echo Check testing he described showed it
working exactly as designed after the death of Task X.
5
None of the expert's testing demonstrated the occurrence of this bit flip,
or any bit flip. Rather, he manually flipped bits to force Task X and other
tasks to die [Testimony, PDF pages 79-81, 173-174, 182, 184, 238-239].
Regarding his lack of evidence from the accident, he appears to explain
this by saying: a) the software did not perform logging [Testimony, PDF
page 190, and Slide 54]; and b) although there were DTCs (diagnostic
trouble codes) stored in battery backed memory on the vehicle, Task X was
responsible for recording most of them [Testimony, PDF pages 51, 62-63,
138-140, and Slide 39].

DECember 2016

∕

The expert emphasized that the
Brake Echo Check fail-safe only acts
if the driver steps on the brake or
releases the brake.

Thus, this theory is not credible as the likely explanation for the accident for at least the following reasons:
a) It requires the nearly simultaneous occurrence of 2
hypothetical failures, A and C.
b) For hypothetical failure A, no evidence was provided
that it occurred at the time of the accident, or under
any circumstances. The expert merely speculated
that it might possibly occur under some circumstances due to problems he claimed to have identified in the software. No connection was established
between any of those claimed problems and the specific bit in question.
c) For hypothetical failure C, no evidence was provided
that it occurred at the time of the accident, or under any
circumstances. In fact, at trial the expert merely proposed that it occurred without even speculating why.
d) Also for C, all of the testing the expert described
showed the Brake Echo Check working exactly
as designed.
e) A and C are independent. Hypothetical failure A is
associated with software on a different processor than
the software associated with hypothetical failure C.
What's more, no argument was made that there was a
dependence between these two hypothetical failures.
The probability of two independent low-probability failures occurring together is much lower (multiplicatively) than the probability of either one occurring
alone. Because no evidence was presented that either
A or C occurred under any circumstances, it is reasonable to treat each of these as very low probability failures.6 The probability of both occurring together, then,
would be expected to be extremely low (all the more
so because not even a speculative reason was offered
as to why C might ever occur).
f) In addition, the theory requires a third item, B. But B
appears to be contradicted by the facts of the
accident. That makes the theory, which already lacks
credibility due to the extremely low probability of A
and C ever occurring together, even less credible.
6

For hypothetical failure A, a single event upset was also suggested as a
potential cause [Testimony, PDF page 72]. Single event upsets are very low
probability failures. The probability of a single event upset affecting a specific bit is even lower.

IEEE Technology and Society Magazine

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