
Toyotas Unintended Acceleration and the Big Bowl of “Spaghetti” Code (2013) - UberMouse
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code
======
hliyan
This is appalling:

    
    
        Toyota had more than 10,000 global variables.
    
        “And in practice, five, ten, okay, fine. 10,000, no, we're done. 
        It is not safe, and I don't need to see all 10,000 global 
        variables to know that that is a problem,” Koopman testified.
    

and:

    
    
        Toyota’s failure to check the source code of its second CPU, 
        supplied by Denso —even as executives assured Congress and 
        NHTSA that the cause of UA couldn’t be in the engine software
    

and:

    
    
        He was critical of Toyota watchdog supervisor – software to 
        detect the death of a task -- design. He testified that Toyota’s
        watchdog supervisor “is incapable of ever detecting the death 
        of a major task. That's its whole job. It doesn't do it.
    
        Instead, Toyota designed it to monitor CPU overload, and, 
        Barr testified: “it doesn't even do that right.
    

and:

    
    
        Barr also testified that Toyota’s software threw away error codes
        from the operating system, ignoring codes identifying a problem with 
        a task.
    

When the news first broke a few years ago, given Toyota's reputation for
quality and process, I thought this was an American industry lead witch-hunt
of a Japanese competitor. But if this testimony is correct, what Toyota
engineers have done is unforgivable.

~~~
engi_nerd
> “And in practice, five, ten, okay, fine. 10,000, no, we're done. It is not
> safe, and I don't need to see all 10,000 global variables to know that that
> is a problem,”

At an old job, my boss asked me to take a look at a business critical
application to see if it could be improved upon. It had some deficiencies that
were really hampering things.

I got the source from a coworker (this is when I worked on rockets, so none of
us were or are professional software people, but even my dumb engineer self
knows this is not how it should be). I opened up the folder. Lots and lots of
files with little apparent structure. Ah, there was a file called "MAIN". I
opened it. Visual Basic 6. Over 29,000 lines for global variable declarations
alone. The actual program logic heavily used a commercial library designed to
(shudder) make VB6 development more like making macros in spreadsheets. The
original programmer then implemented the main program logic in this hellish
abomination. The logic took up another 50,000 lines or so.

I told the boss that it would be easier to write a new program from scratch
then attempt to understand it.

Has anyone seen a program with more globals than this?

~~~
scrollaway
Nowhere near as many, but I had to deal with this very recently and this
little WSJ gem showed up:

[https://github.com/ewfelten/Tracking-Report-
Card/blob/master...](https://github.com/ewfelten/Tracking-Report-
Card/blob/master/alexa_us500_041412_mozmill.js)

I'll let the code speak for itself.

~~~
nl
That looks like autogenerated code. That's a different beast altogether.

~~~
carussell
It is. Mozmill is a testing framework. What we're looking at there is a file
containing automated tests (which I think should be _fairly_ obvious to
someone looking at that file...)

~~~
scrollaway
I'm well aware of what it is. Like I said, I had to deal with it recently - I
didn't just pull it out of thin air.

What you're looking at is a horror beyond comprehension. There's much better,
more maintainable ways to write automated tests.

~~~
carussell
I guess we'll have to disagree, especially about this part:

> horror beyond comprehension

"Horror"? No, but I guess that's debateable (apparently). But "beyond
comprehension"? Absolutely no. Even if we say the repetition offends our
aesthetics, I can't even imagine what sort of issue you had to deal with where
this file posed a problem. Anything you could possibly want to do with it
should be serviceable inside of 5 minutes, except in the dumbest of Notepad-
quality (i.e., little more than a text control) editors. That includes
rewriting the whole thing to be less offensive, if that's your slant.

This file is nothing compared the types of things mentioned upthread, things
which, again, exist in a context of actual production code.

------
thaumaturgy
There are a bunch of neat comments from past threads about this if you search
HN for "Michael Barr":

"On a cyclomatic-complexity scale, a rating of 10 is considered workable code,
with 15 being the upper limit for some exceptional cases. Toyota’s code had
dozens upon dozens of functions that rated higher than 50. Tellingly, the
throttle-angle sensor function scored more than 100, making it completely and
utterly untestable."
[https://news.ycombinator.com/item?id=7711771](https://news.ycombinator.com/item?id=7711771)

"For example, [http://www.edn.com/design/automotive/4423428/Toyota-s-
killer...](http://www.edn.com/design/automotive/4423428/Toyota-s-killer-
firmware--Bad-design-and-its-consequences) quotes Barr's claims: 'Toyota’s
electronic throttle control system (ETCS) source code is of unreasonable
quality.' 'Toyota’s source code is defective and contains bugs, including bugs
that can cause unintended acceleration (UA).'"
[https://news.ycombinator.com/item?id=8906513](https://news.ycombinator.com/item?id=8906513)
(and the linked article has a link to slides which are enlightening)

A number of comments at
[https://news.ycombinator.com/item?id=6636811](https://news.ycombinator.com/item?id=6636811),
"Toyota's firmware: Bad design and its consequences"

------
meesterdude
So, take this into account, and add in self driving cars. The complexity
involved in these, and the coordination required, is nontrivial and its clear
from the article they do NOT have a good handle on things.

I mean, most cars do seem to get around OK, so I'm partly amazed that under
the hood, things could really be so scary. But we can't be lazy about adding
complexity and systems, especially as more faith is placed on them.

That this is not NASA grade code (or anything close) does not give me any warm
fuzzies. It reeks of unprofessionalism, greed, and laziness.

There needs to be a sane-software assesment. People rely on products with an
ever increasing amount of source code - it would be interesting if a third
party could come along and certify that a given codebase is not a big scary
unmaintainable mess; not to say there won't be bugs or issues, but that these
guys are at least _trying_ to make a well designed system, and aren't doing a
bunch of crazy stupid things.

~~~
Sanddancer
There are standards, Toyota simply chose to ignore all of them. Standards such
as MISRA [1] and DO-178C [2] exist for the purpose of ensuring software
quality in safety-critical situations. Most embedded software development
environments even include tooling to help verify that you're not doing the
things that are unsafe. The problem lies more in that automakers aren't
required to use any such standard, unlike what the FAA has required for
decades.

[1]
[http://en.wikipedia.org/wiki/Motor_Industry_Software_Reliabi...](http://en.wikipedia.org/wiki/Motor_Industry_Software_Reliability_Association)
[2]
[http://en.wikipedia.org/wiki/DO-178C](http://en.wikipedia.org/wiki/DO-178C)

~~~
lambdaelite
Toyota couldn't ignore these (voluntary) standards given that MISRA-C nor the
earlier DO-178 didn't exist at the time the code was developed.

~~~
Sanddancer
MISRA-C dates from 1998, and DO-178B, which was the previous revision of
DO-178, dates from 1992.

~~~
lambdaelite
Yeah, I mistyped (should read "...later DO-178..."). You're quite correct that
DO-178B was around then, but the C revision was not.

According to testimony, Toyota's coding standard was in place in 1997, before
the first MISRA-C publication.

------
yaakov34
This issue returns to Hacker News and to public consciousness every few
months, and each time there is something missing: namely, some kind of direct
proof that an actual failure of this software resulted in unintended
acceleration, anywhere, ever. Let alone a case of runaway acceleration which
the driver is unable to stop with the brakes (requiring a simultaneous brake
failure). Since the accelerator pedals in these Toyota vehicles have been
pressed no fewer than tens of trillions of times in recent years, that's not
an appalling safety record at all. In fact, stuck pedals (whether due to bad
lubricants or rolled-up floor mats) are many orders of magnitude more likely
to cause stuck throttle than software failures, while runaway vehicles (ones
with brakes not working either) are generally caused by "pedal
misapplication", i.e. stomping on the gas instead of the brakes.

The fact that software has an execution pathway leading to something bad does
not mean that this pathway can ever be entered, since in a closed realtime
system like this, it is not possible to receive every combination of inputs,
unlike in a system loading user data from a file. This is not to say that
Toyota shouldn't clean up and verify its code, but the moral panics over what
this code says about programmers, the human condition, Japan, etc. etc. are
unwarranted.

Quote from
[http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...](http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls):

On February 8, 2011, NASA and the NHTSA announced the findings of a ten-month
study concerning the causes of the Toyota malfunctions of 2009. According to
their findings, there were no electronic faults in the cars that could have
caused the sudden-acceleration problems.

~~~
tunesmith
Every time this article comes up on hacker news there are a few comments that
show up talking about how no one was able to _prove_ that the bugs _definitely
caused_ the crashes, and thus the criticisms of Toyota are overblown. I'm left
wondering how on earth to reconcile those viewpoints with general software
engineering (which is a huge part of what this community is about), where we
regularly see articles about new concurrency frameworks, fault-tolerant
programming, formal methods to prove correctness of code, etc. If it's
important enough for Amazon to use TLA+ to prove correctness of DyanmoDB then
shouldn't it be considered outrageous that Toyota doesn't do the same thing
for something that is potentially an accelerating death machine?

~~~
Gibbon1
The reason generally given is that in at least standard cars the brakes can
apply far more torque than the engine can. It's telling how naive people are,
they think the problem is 'unintended acceleration' A mechanical engineer
thinks the problem describe is 'unintended brake failure'

~~~
jessaustin
And if the brakes won't stop the car, try the key switch! An engine that is
not running will not cause acceleration. (Sure there are probably some oddball
push-button ignitions that can't be turned off while in gear, but most
vehicles _can_ be.)

~~~
fr0sty
Turning off the ignition may deactivate your airbags* which could make a bad
situation worse.You would be much better off attempting to shift your car into
Neutral first.

* This was what made the GM Ingnition switch problem so deadly. The engine shut off (taking power steering and vaccuum-assist braking with it) and the airbags deactivated making any subsequent crash less survivable.

~~~
jessaustin
You're right that shifting is better. That is a pretty terrible failure mode
for airbags, however. How much would it cost to put a big reliable capacitor
in the airbag circuit, to keep the power on for 30 seconds? A dollar?

------
hackuser
In the 1990s an engineer for one the U.S. automakers told me that the code in
their cars was a black box. Nobody knew how it functioned; all they could do
was watch the input and output, and add patches as needed to modify the
output.

Maybe the engineer was talking about code for a specific component, but
perhaps Toyota's software isn't unique.

~~~
r00fus
Exactly my thoughts. I bet any company when put under the spotlight would show
some really bad practices/anti-patterns.

Is that however, a problem with the industry? I can't help think of Fight
Club's "recall" equation here...

------
kensai
"In 1998 that standard had a Rule No. 70 called -- I don't remember the exact
language. But function should call themselves. And the rules basically are the
same in but they changed the numbering system, so in the standard this rule,
same rule is No. 16.2. So this violation of the MISRA C rule."

"What was NASA's view about this recursion? A So NASA's view, NASA was
concerned about stack -- possible stack overflow. They had a couple of pages
devoted to it, about five pages. I pulled some quotes here. Recursion could
exhaust the stack space leading to memory corruption and run time failures
that may be Yes. In what way? The stack can overflow due to this recursion in
the Camry. And create memory corruption? And that would create memory
corruption, that's difficult to test -- detect in testing."

Man, some elementary stuff here. They changed the specs numbering and did not
update their manuals as well as forgetting that recursion in very costly in
memory and could overwrite the stack... Jee, these are things a C programmer
learns from day one, even in CS50...

------
PhantomGremlin
There is, to me, a more interesting question:

If not Toyota, then who? Which auto manufacturers do it right? And is there
any public evidence to support that? If not, then I'm probably just as "safe"
or "unsafe" in any other brand of car as in a Toyota.

~~~
alexvoda
This is mere speculation but the software in Tesla cars is probably at least
decent since they dared reuse some of the technology on the Spacex Dragon V2
capsule.

I think this is one field in desperate need of open sourcing. Anyone who has
the capability and the desire should be able to audit the software.
Modifications should be prevented by signing, unless the user signs that he
assumes full legal responsibility for the effects of the modifications and has
the vehicle recertified as roadworthy.

~~~
Cthulhu_
Open sourcing it is nice and all from an idealist standpoint, but given the
complexity of the software (millions of LOC), the fact that all the software
would be used in commercial companies, and simply the area itself (cars), do
you really think the community would pick up on it? I doubt it. Plus, the
researcher did audit it - 18-20 months' work, and that was just analyzing it,
not actually improving or fixing it.

Plus there is no car manufacturer ever that would allow anyone to change the
firmware on their own.

------
plumeria
Here are the slides Barr used in his presentation:
[http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...](http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf)

------
btilly
Please add (2013) to the title.

People may have forgotten this because it was in the news a few years back.
But Toyotas randomly experienced "unintended acceleration" due to software
bugs.

Many reported incidents were undoubtably due to the problem that people in a
panic can step on the wrong pedal and will misremember what they did. Others
were due to a floor mat that could jam the pedal. But some were Toyota's
fault.

~~~
nikanj
Was that ever proven? Did Toyota ever come out with a software patch that had
to be installed in all cars made by them?

I remember them replacing carpets that might get stuck, and this
[http://www.thetruthaboutcars.com/2010/03/the-best-of-ttac-
th...](http://www.thetruthaboutcars.com/2010/03/the-best-of-ttac-the-
audi-5000-intended-unintended-acceleration-debacle/)

~~~
tomcorrigan
It was never proven because it never happened. The wikipedia article has much
more detail.:
[http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...](http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls)

It is not merely coincidental that all unintended acceleration events occurred
in automatic cars. Also, a widespread unintended acceleration problem has not
been observed in Toyota cars outside the USA.

It's a shame that so many on HN are so swift to condemn Toyota

~~~
lloeki
> It is not merely coincidental that all unintended acceleration events
> occurred in automatic cars. Also, a widespread unintended acceleration
> problem has not been observed in Toyota cars outside the USA.

If my car went nuts on acceleration the first thing I'd do would be to jump on
the clutch pedal and apply brakes (and possibly set the stick to neutral) but
that's because most cars here are manual thus that's what we learn to
operate†. Pursuing on that line: once at a stop, cut the ignition and disaster
is averted. Start again and you're probably fine due to the reboot. Then drive
to nearest Toyota to complain, but since "nothing" (i.e no damage, no injury)
really happened, you'll get a shrug and a reflash.

† In a country where people learn only on automatic cars, setting back to
neutral is most probably not reflex (if mechanically possible at all)

------
userbinator
Things were so much simpler when the only problems that could cause unintended
acceleration were mechanical in nature. A broken return spring, seized
linkage, etc. My daily driver has a mechanical throttle (although it is
electronically fuel-injected), and honestly I can't see much point in "drive-
by-wire" for cars.

But, on the other hand, even despite so many _possible_ bugs, AFAIK no one has
been able to demonstrate one instance of unintended acceleration even with
extensive testing.

~~~
bri3d
Drive-by-wire is good for a lot of efficiency technologies because it enables
the elimination of the throttle plate, and therefore of many kinds of
throttling losses (see MultiAir, ValveTronic, ValveMatic, etc.). It also
enables simpler cruise control and traction/stability control systems. The
addition of computers to cars is mostly a plus (IMO) but the hidden complexity
is frightening to say the least.

------
_ati
Similar to the aerospace and medical may be there should be strict regulations
in terms of processes to be followed for development in the automobile
industry also. Usually in medical, failing the audit would restrict the
producer to sell the product in market for 1 year. May be something similar
could be enforced in automobile industry also. Ofcourse it might increase the
cost of cars but atleast they will be lot more safer.

------
bliti
These are safety-critical systems. It still is mind numbing that the quality
of the code is so bad. After this came out, I've assumed all modern fuel-
injected Toyota's suffer from the same lack of safety. I don't think other
automakers may be better.

I own a Toyota, but it has a mechanical throttle body. :)

------
swang
So many questions remain...

How do I tell which Toyotas are affected? Do they all have these problems?
What, if anything, did Toyota do to fix their software engineering processes?

I ask because my parents have a 2005 or 2006 Toyota Sienna, and I don't feel
very comfortable with them driving it now.

~~~
MichaelGG
If you're concerned about safety, look into the stats. With the number of
accidents happening overall, I wouldn't be surprised if even a known flaw
doesn't increase risk a whole lot. There's probably dominating factors, such
as location (weather, etc.) and distance driven at which times, or which model
of vehicle.

Maybe I'm wrong and this is a significant risk, but the approach should be the
same. Even if they found and fixed one problem, the stats would still tell you
which cars are safest. It could very well be that other vendors are worse,
just haven't been investigated.

~~~
peterfirefly
Toyota cars are some of the safest on the road in the US according to the
safety statistics -- even if (big if) some of them had problems with
"unintended acceleration".

This tells us that even if (big if) the issue was real, it was actually never
important. Also funny that it never was an issue outside of the US.

~~~
thescrewdriver
Which safety statistics? IIHS crash test reports or actual road statistics?

~~~
peterfirefly
The latter.

~~~
thescrewdriver
Do you have a link? I'm genuinely interested.

------
bootload
_" Defects in the car’s electronic throttle control system (ETCS) were
directly responsible for the Camry’s sudden acceleration and resulting
crash."_ [0]

I couldn't find an exact description of how the driver crashed. Was it using
the on-board cruise control or normal throttle use? Never use the cruise
control. Must ask when I get my car serviced if it has electronic or
mechanical throttle body cf @bliti

[0]
[http://www.usatoday.com/story/money/cars/2013/10/25/toyota-s...](http://www.usatoday.com/story/money/cars/2013/10/25/toyota-
sudden-acceleration-lawsuit/3187369/)

~~~
catshirt
it was a symptom of neither cruise control or normal throttle use. the way the
issue manifested is actually pretty terrifying:

"Koua insists that his 1996 Toyota Camry sped up to between 70 and 90 mph
despite heavy braking."

[http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...](http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls)

out of context, but "we're in trouble, there's no break"

[https://www.youtube.com/watch?v=03m7fmnhO0I](https://www.youtube.com/watch?v=03m7fmnhO0I)

~~~
bootload
thx @catshirt, I note this about my Camry: _" Toyota Australia announced that
its accelerator pedals are made by a different supplier and that there is no
need for a recall of Australian made vehicles"_.

Reading through the notes I see trying to turn the engine off while going
effects various electrical sub-systems. Me, I'd try putting the car in neutral
(auto).

A couple of years ago the alternator blew in my car. The battery had enough
charge to let me drive +30km home after a re-start by a local RAC. When I
drove the car the three kilometres to the shop, the charge started to drop and
battery failure light (alternator failure) clicked on.

First the car started loosing systems: seat-belts, overdrive, ABS... etc. This
continued, till I bunny hopped the car into the garage where everything
stopped working. No doubt a sticky accelerator is scarier than the lurching I
had in busy traffic, kept going till the end. Power steering was the last to
go, then the engine itself.

------
cpeterso
Does Google (or Tesla or Uber) use Ada for their self-driving car projects? I
am afraid that answer is likely C++.

I noticed that this article mentions MISRA-C but not Ada. I thought I had read
the Toyata used SPARK Ada. Michael Barr's slides have more technical details
about Toyota's C code:

[http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...](http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf)

------
ilitirit
Software that can modify any aspects of a vehicle's handling should be
subjected to a higher level of testing and scrutiny than things like airbags
and safety belts. A faulty cruise-control component is demonstrably more
dangerous than a faulty safety belt.

------
JabavuAdams
Please edit the title to read "Toyota's", not "Toyotas".

------
thrillgore
10,000 god damn global variables. It would be very difficult to expect some
kind of unit testing with that many straggling race conditions bouncing
around. Wow.

------
michaelfeathers
> Toyota had more than 10,000 global variables. “And in practice, five, ten,
> okay, fine. 10,000, no, we're done. It is not safe, and I don't need to see
> all 10,000 global variables to know that that is a problem,” Koopman
> testified.

I wonder why people want to believe 5 or 10 are okay.

~~~
jfoutz
Check engine light? Passenger without a seatbelt?

I mean, it's an embedded system, resources are scarce. There are more elegant
solutions, yes. But a pattern of setting an error condition from a bunch of
different sensors, that's checked from a bunch of locations seems reasonable.
At least, not insane.

------
e40
Any ideas if other Japanese car makers have the same problem with their
software?

------
thrownaway2424
Counting global variables is just silly. I think any number of global
variables is perfectly fine.

~~~
thrownaway2424
Lots of downvotes, no rebuttals.

~~~
Crito
You might as well claim that you think that dogshit makes for a fine
breakfast. It doesn't warrant a rebuttal.

------
tulb
hi

