Software and runaway acceleration

On October 24th of 2013, a state-court jury in Oklahoma determined that software in the electronic throttle system was defectively designed.

I had surmised that the cases of runaway acceleration in some Toyota cars resembled a situation I have encountered a number of times in testing software. The problem is called spinning; the symptom is when a software program consumes a lot of CPU cycles but is unresponsive to external inputs and causes the whole computer to run slow or become completely unusable. Typically, the only remedy is to somehow stop the program or power cycle the computer.

There are a few reasons that a program can get into the state of spinning, but the actual behavior is very similar in every case. The program reaches a point in which it tries to do something and because it is unsuccessful, it tries to do it again. This particular situation is a common one in software and in most cases, a program can handle the situation without a problem.

But in the case of a spinning program, the algorithm to deal with the unsuccessful attempt provides no path for reporting or backing off. Instead the program retries the attempt time and time again with a very short interval between. It is from this situation that the name spinning derives. Think of the logical flow of software in which a test is made and the result is negative; the subsequent branch is to go back up and try again. Software that is prone to spinning falls into the same loop and repeats it.

What are some algorithmic reasons for a spinning process? Here are two I have seen: a program does a check for a status that is "always there," but something occurs so that it is not. There are two sections of a program which update the same memory element, one locks the element so that it can update it but it is then interrupted, leaving the second section of code unable to proceed but continuing to check anyway.

Unlike an animal, software will not tire of this. And if the loop is sufficiently unencumbered, the program will consume all available CPU time. This tightly looping section of software then precludes other activity on the processor. In an automobile, the throttle controls how much gasoline is sent to the engine. If it gets in a predicament in which it only has a signal to send more and there is nothing to change this, a car will run without restraint.

I once came upon a Toyota car that had charged out of control in a parking lot. It had hit a parking brick, leapt over it, then crashed through a line of bushes and stopped when it hit a tree. The driver was a woman of about 60 years. She said she had pulled into the lot and turned the car in a half circle to pull into a spot facing the street. But as she straightened the car to enter the space it lurched forward uncontrollably until it hit the tree.

It would not have been unreasonable to ascribe the situation to a panicked driver who mistakenly pushed down on the accelerator instead of the brake as she pulled into the parking space. However, there was one factor which suggested to me that was not the case. If you have ever been in a vehicle that has rammed and then bounced over an obstruction you will know what I mean. It is hard to keep a foot on the accelerator pedal when a car makes such violent movements.

Based on these assumptions and observations, how can software be blamed for this situation? In modern automobiles, there are hundreds of thousands if not millions lines of code. A good portion is given over to the control of gas and air that is sent to the engine. This type of control provides a powerful mechanism to regulate not only the amount of gas, but also the timing for when it reaches the cylinders of the engine. Normally, one would expect some kind of feedback mechanism to provide an indication to limit the input of gasoline.

But consider a situation in which a car is turning and changing speed while it attempts to park. As a car turns each wheel spins at a different speed. It is conceivable that software helps to synchronize and control the rate of tire rotation through the turn. In the case witnessed, it is possible that the timing of the change from acceleration to braking may be different from what is normally encountered during driving.

Here is how it may happen. Presuppose a state exists in which only the software controls acceleration and braking; or one that is initially triggered by a driver's action, such as applying pressure on the brake pedal, but then makes detailed adjustments which involve minute increases in acceleration to ensure an even, smooth stop. These are likely very short bursts that are countered by feedback from sensors measuring the rotational speed of the wheels. While in the mode of acceleration even though the brake pedal is being pushed and acceleration is indicated by the software, a change occurs in the state representing the pedal. This occurs in an incredibly short interval of time and interrupts the signal that normally ends acceleration, but because the other change has arrived the software cannot exit the routine and it begins applying acceleration with no way to counteract it.

As mentioned earlier, this mode of failure resembled situations encountered during testing of other software applications. With the ever increasing reliance on computation in the function of an automobile, it will be no surprise when other failures only seen in less mechanized applications show themselves. This type of failure is also an indication of the increasing movement away from human control over mechanical devices and the difficulty in separating the human responsibility from the machine malfunction.