Toyotas Unintended Acceleration and the Big Bowl of “Spaghetti” Code (2013) (opens in new tab)

I once worked for a billion dollar retail company. Their core back office applications (sales tracking, logistics, orders and fulfillment, staff rosters, etc) were written in COBOL and the inputs and outputs were read from / written to temporary files; kind of like pipes but via temp files in case of job failure. The real problem was that there were about 3,500 COBOL programmes and 2,500 shell scripts all in one directory. All the executables, COBOL and shell alike, were given a 4 digit filename; there was no up to date documentation on what program did what (apart from the source), or in which order they should be run, or the dependencies there in. To top it off end of day processing would take between 12 to 16 hours to run; any major problems and it would start affecting the next day's EOD. There was only one guy in the office (who had been there 15 years) who understood how it all fit together; when he died things got much worse (no he wasn't that old, how he died is another whole war story all together).

I only lasted there 6 months before I left for a start up, in many ways it was too much to bear. A while after I left taxation for retail changed substantially, there was a massive IT stuff up and the billion dollar business wound up being carved up and sold off; several thousand jobs affected, many lost their jobs either directly or indirectly as a result.

Sure this is probably at the worst end of the scale (short of causing deaths) and is rare but it does happen. Billion dollar company succumbs largely because of IT failures. It got to the point that the cost of the technical debt was higher than the carve up losses...

Sounds like you need to submit this to DailyWTF...

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...

I'll let the code speak for itself.

It's a strange feeling when some small webdev are using clean modular testable code while real life businesses are abusing VB in creative ways. Really makes me feel paradigms do matter. My last job involved a huge pile of VB (VBA to be exact) code and again, it was an unstructured mess.

Yes, just about every damn PHP project I inherited that wasn't bound to a framework, or wasn't an existing OSS project.

This is also an interesting contrast to the (I assume higher quality) kind of work being put out by their other engineering departments- how can they make other sound engineering decisions on the rest of the car and it's manufacture, but fail at the software?

Is it something specific to software vs. traditional engineering in Japanese culture, or is it something inherent to software in general? Given the parent's complaints about workplace culture in general, shouldn't the entire car be badly designed?

There was an article about this (in New Yorker, I think...) a few years back, t how Japan has this strange relationship with software.

How it is a hardware-first country. Many reasons were given -- cultural, how "real men build real things", infatuation with appliances, which are seen as being "hardware" in a way, perhaps the langauge barrier i.e. existing software tools using English for menus and inputs etc.

And it is kind of interesting, looking back at a country that many in the 80's feared with surpass and leave the Western world in the dust technology-wise, we haven't seen that much software produced there. Can you think of large well known software from Japan (excluding console games). Vine Linux, SoftEther VPN, TrendMicro, anything else?

One wonders if they see Western software companies and if there is any desire to catch up or try to keep up.

Maybe anyone from Japan can provide a better perspective?

> it's considered lower level to be a software engineer than to be a mechanical or electrical engineer, so the smartest kids do not study computer science (this might have changed since).

Which is very interesting, because in US it is completely opposite (and frankly it is not good either). Is it because US deindustrialized itself last 40 years?

I can state that this matched my experience though I was in the US - this was in the 90s, and in the automotive industry. I used to work at Motorola Automotive and Industrial and our team built the Computer-Aided Manufacturing systems that managed the production lines. It always felt like a tier-2 job compared to process engineering.

This is a genuine question: why can't they outsource their software devel ?

I agree, but I also believe that as an engineer I have an duty to refuse to build something under conditions that, once built, would cause harm to others. Or at least to relay my concerns to management in writing before proceeding.

And sometimes, quitting is the ethical thing to do.

And, at large Japanese companies, people are shuffled around every two years. I had heard this and didn't believe it until I saw it. A distributor of my company would replace people with novices once the previous person had just gotten really good at the job.

If Toyota is doing this, it would explain a lot.

Blow the whistle? Contact regulatory agencies?

Yes, another part of Barr's testimony was a series of proof-of-concept demonstrations on the ECU to demonstrate the ability to kill tasks, leaving the hardware those tasks were controlling in unintended states.

>was it ever demonstrated that unintended acceleration could actually arise from the behavior of this software?

That's entirely the wrong question to ask. The correct question is "has the system design been proven to make it impossible for unintended acceleration to occur?"

> was it ever demonstrated that unintended acceleration could actually arise from the behavior of this software?

No, but the software engineering practices were so bad that it was a moot point.

There's no need to be emotional. Some people jumped to biased conclusions. Others based it on NASA's software review (which we have now found to be flawed). See the report: http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUB...

The criticism of global variable count comes straight from Phillip Koopman, "a Carnegie Mellon University professor in computer engineering, a safety critical embedded systems specialist, authored a textbook, Better Embedded System Software".

So this isn't a web developer providing criticism, but someone with extensive experience in embedded software development. Perhaps reading the article linked before jumping to conclusions might be useful!

Locally-scoped (i.e. static) variables are, by definition, not global variables. The article is pretty clear that the 10,0000 figure refers to truly global variables, and I would hope that the original expert witness has not misled us by referring to static variables as 'global'. (Of course, without being able to see the source, there's no way to make our own judgement.)

Sadly, you would be surprised at the number of embedded systems that store and pass around their state using global variables, despite the obvious stupidity of that approach.

(For the record, I am not a web dev and I did indeed spend several years working in the field of embedded development.)

If you've ever driven a vehicle with them you'd know that air brakes are very, very powerful.

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.

Very awesome comment! I didn't know there were standards, but it's great to see there are. However, Toyota should have followed them. I mean, did they think they knew better? I think with self driving cars, the standards will become more requirements; though I doubt before a series of deaths result from software failure.

Given that a lot of computer vision work is based on randomised algorithms, do you think that these standards would be enough? You could demonstrate 100% MC/DC coverage through a neural net implementation, but the weights are where the faults probably exist, for example.

The HN community at large isn't experienced with software engineering. It seems like there are a handful of commenters who are, but they are a very small minority.

Personally, I'm surprised that the majority of the HN community overlooks or ignores the reports from NASA and Exponent (Toyota's outside expert witness) in favor of the testimony from Barr, the witness for the plaintiffs in the Oklahoma case. (I'm honestly amazed that Barr was allowed as an expert witness) Barr did show that the code "smelled" and that it was possible to inject specific faults to induce an uncommanded acceleration, but he did not show that his proposed failure mode occurred nor that it was probable to occur. In fact, part of his failure mode was that it left no record of a DTC. It's the perfect kind of failure mode for a sympathetic plaintiff to wield against an arrogant defendant with deep pockets: possible that it occurred, possible to demonstrate, understandable for a jury (who hasn't had a BSOD?), and impossible to disprove.

You bring up the practice of software engineering, but I think you need to place it in context of how software engineering was practiced around the time that the electronic throttle system was developed. MISRA, which HN readers are becoming aware of, didn't exist. Proof assistants, which today remain challenging to use and integrate into an SLDC, were even more arcane. In fact, your example of TLA+ wouldn't fly even today since TLA+ doesn't do code generation, and that would be a necessary component of the verification process of a regulated SLDC. I don't think TLA+ existed at the time either. Things certainly have changed!

Sure, they should improve or clean up the code on general principles. However, there are 2 issues here:

1) A lot of these articles imply that some expert has demonstrated how a coding error will cause unintended acceleration. Then when you look at the actual source, it becomes clear that the "demonstration" involves changing the internal state of the controller in all sorts of arbitrary ways, and sometimes rewiring its sensors in an invalid way as well. In other words, this is not a recipe along the lines of "blip the throttle while changing from N to D, press the brake within 0.2 seconds, the throttle will now be wide open". The fact that no such recipe has been found, despite many millions of dollars spent on expert analysis, suggests that it doesn't exist in the wild. Implying that this code is killing people somewhere out there is misleading.

2) Yes, it has been overblown. We know that throttles can stick open, usually due to jammed or sticking linkages and pedals. That's not a huge problem, since brakes are powerful enough to stop cars in this state. I don't think it makes a huge amount of sense to rewrite software to stop software-induced unintended acceleration, which probably doesn't even happen, instead of writing software for lane departure/collision warning/assisted emergency braking and other safety systems, which we know can help drivers avoid accidents.

I guess a third issue here is the American litigation system, which can turn companies into villains without the slightest indication that their products cause any more issues than anybody else's - all it takes is a non-zero probability of failure (true for most products) and a media + legal frenzy.

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'

> Un bon mot ne prouve rien. (A witty saying proves nothing.)

—Voltaire

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

That's a consequence of the use global variables having been recognized as an anti-pattern for a very long time now, and people downvoting the obvious instead of writing a rebuttal.

Maybe you should cite something to back your claim made upthread.

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_...

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

I, too, am left wondering over the paradox of the brake supposedly being powerful enough to hold back any amount of torque the engine and transmission can apply - unless, in the name of anti-skid braking or traction control, the system has the ability to override the driver and release or limit the braking torque.

Furthermore, those explanations of the floor-mat recall that I have checked all say that the mats were suspected of having interfered with the accelerator, not the brake. Toyota subsequently performed a second recall, to correct problems with the accelerator pedal. These both imply that unintended acceleration was at least a significant causative factor in the accidents - unless Toyota and the NHTSA were simply acting in order to be seen doing something.

With regard to proof, the article covers the issue in some detail: after a far-from-exhastive series of investigations, there have already been found so many ways for the software to get into unintended states that only a vanishingly small number of the vast range of possible causes have been considered. Asking for proof of an error is the wrong question to ask: the burden of proof clearly rests with the manufacturer to show that their systems are safe - and Toyota cannot do that with this software.

That Toyota replaced floor-mats is certainly not evidence for the correctness of their software, and nor is the non-appearance of a software patch. The article quotes a concerned Toyota engineer whose statements indicate a culture of denial within the company.

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.

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.

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.