This is appalling:<p><pre><code> 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.
</code></pre>
and:<p><pre><code> 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
</code></pre>
and:<p><pre><code> 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.
</code></pre>
and:<p><pre><code> Barr also testified that Toyota’s software threw away error codes
from the operating system, ignoring codes identifying a problem with
a task.
</code></pre>
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.
There are a bunch of neat comments from past threads about this if you search HN for "Michael Barr":<p>"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." <a href="https://news.ycombinator.com/item?id=7711771" rel="nofollow">https://news.ycombinator.com/item?id=7711771</a><p>"For example, <a href="http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences" rel="nofollow">http://www.edn.com/design/automotive/4423428/Toyota-s-killer...</a> 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).'" <a href="https://news.ycombinator.com/item?id=8906513" rel="nofollow">https://news.ycombinator.com/item?id=8906513</a> (and the linked article has a link to slides which are enlightening)<p>A number of comments at <a href="https://news.ycombinator.com/item?id=6636811" rel="nofollow">https://news.ycombinator.com/item?id=6636811</a>, "Toyota's firmware: Bad design and its consequences"
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.<p>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.<p>That this is not NASA grade code (or anything close) does not give me any warm fuzzies. It reeks of unprofessionalism, greed, and laziness.<p>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 <i>trying</i> to make a well designed system, and aren't doing a bunch of crazy stupid things.
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.<p>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.<p>Quote from <a href="http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls" rel="nofollow">http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...</a>:<p>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.
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.<p>Maybe the engineer was talking about code for a specific component, but perhaps Toyota's software isn't unique.
"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."<p>"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."<p>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...
There is, to me, a more interesting question:<p>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.
Here are the slides Barr used in his presentation: <a href="http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf" rel="nofollow">http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...</a>
Please add (2013) to the title.<p>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.<p>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.
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.<p>But, on the other hand, even despite so many <i>possible</i> bugs, AFAIK no one has been able to demonstrate one instance of unintended acceleration even with extensive testing.
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.
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.<p>I own a Toyota, but it has a mechanical throttle body. :)
So many questions remain...<p>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?<p>I ask because my parents have a 2005 or 2006 Toyota Sienna, and I don't feel very comfortable with them driving it now.
<i>"Defects in the car’s electronic throttle control system (ETCS) were directly responsible for the Camry’s sudden acceleration and resulting crash."</i> [0]<p>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<p>[0] <a href="http://www.usatoday.com/story/money/cars/2013/10/25/toyota-sudden-acceleration-lawsuit/3187369/" rel="nofollow">http://www.usatoday.com/story/money/cars/2013/10/25/toyota-s...</a>
Does Google (or Tesla or Uber) use Ada for their self-driving car projects? I am afraid that answer is likely C++.<p>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:<p><a href="http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf" rel="nofollow">http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...</a>
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.
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.
> 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.<p>I wonder why people want to believe 5 or 10 are okay.