Toyota's Killer Firmware 610
New submitter Smerta writes "On Thursday, a jury verdict found Toyota's ECU firmware defective, holding it responsible for a crash in which a passenger was killed and the driver injured. What's significant about this is that it's the first time a jury heard about software defects uncovered by a plaintiff's expert witnesses. A summary of the defects discussed at trial is interesting reading, as well the transcript of court testimony. 'Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.' Anyone wonder what the impact will be on self-driving cars?"
Technology is hard and dangerous (Score:5, Funny)
I'm convinced. I'll give up my career as a computer programmer now, and go use my bare hands for subsistence farming now. Sorry, I was wrong.
Re:Technology is hard and dangerous (Score:5, Insightful)
Re: (Score:3)
Re: (Score:3)
bad stuff happens
"That's is, we're all farmers......"
Re:Technology is hard and dangerous (Score:5, Interesting)
Realistically, you are quite a bit more likely to die in your classic car than you are in a new car despite issues like this.
The new car brakes better, handles better, is an order of magnitude safer in a collision thanks to the crumple zones, airbags, and modern collision testing requirements. It also uses less fuel, and pollutes less.
I like classics too, but I don't have any illusions that they are generally safer or more reliable. I will give you that they are usually easier to fix (assuming they aren't so classic that parts are a problem) but that doesn't make them safer -- and safety was the underlying catalyst for this discussion.
Re:Technology is hard and dangerous (Score:5, Insightful)
Re:Technology is hard and dangerous (Score:5, Interesting)
I agree. I'm hardly a Luddite, but being an embedded hardware/software engineer, I know what kinds of problems can crop up. The use of computers for safety critical functions was pretty well developed years ago in aerospace, but it's very expensive. Developing the software is also very expensive (and dull frankly), and has to meet stringent standards (the higher tiers of DO-178B). It sound like Toyota anyway, haven't even reached the point of good practices, let alone stringent standards. The car makers have decided they want aerospace style control, but without the costs. Good luck with that.
ECU's have been around since the 70's, and became ubiquitous in the 80's. AFAIK the older systems had a mechanical linkage between the gas pedal and the throttle plate. The ECU then read the air flow sensor, and various other sensors, to set the fuel injection and spark timing. Obviously it can fail, but it's a soft fail. The engine won't run, or more likely won't run well. Sudden acceleration or unstoppable engine though? Forget it. With the throttle plate closed there's no way you can get any more than the power produced at idle, no matter what the ECU does.
Re: (Score:3)
Re:Technology is hard and dangerous (Score:4, Informative)
On airliners they're willing to spend just a little more on extremely reliable and redundant hardware than they are on cars. Makes a difference. It also helps if you code to extremely stringent standards like DO-178B Level A, which costs a fortune. Light aircraft don't use fly-by-wire, why do cars need it?
AFAIK the main argument for fly-by-wire on airliners is that it allows for a reduced stability aerodynamic design, which reduces drag and hence fuel consumption. Considering the amount of fuel an airliner consumes, it's worth spending a king's ransom on fly-by-wire. The payback is definitely there. I know of no similar argument for most of the current generation of electronics in cars, and they're certainly not willing to pay the price.
Re:Technology is hard and dangerous (Score:4, Informative)
Probably some kind of poor management decision that will ultimately be blamed on bad engineering.
Re: (Score:3)
Seems to me reliability in engine control software _is_ doable. Toyota just didn't do it.
Probably some kind of poor management decision that will ultimately be blamed on bad engineering.
Only because they can't get away with blaming the floor mats anymore.
Re:Technology is hard and dangerous (Score:5, Informative)
Safety critical systems in automotive applications are fairly rigourous as well. The airbag controller, for example, has a power reserve (a big honkin' cap) so it can trigger the airbags even if the power systems are mangled, dual accellerometers (in case one fails), logging of data, etc.
Brakes are almost always hydraulic with a mechanical backup - malfunctioning ABS cannot defeat the system, etc.
The ECU may not be redundant, but it doesn't matter because if the ECU fails, the engine dies and you try to pull over safely. (in aircraft, you don't want engine failure due to computer failure, so they require dual computers, or computer/magneto).
And fly-by-wire on military jets lets you have better dynamic stability because an unstable aircraft maneuvers faster. Commercial jets are traditional stable designs to begin with. The reason they went fly-by-wire was wire is a LOT lighter than miles of cables, rods, pulleys, hydraulic fluid, etc and has way less error modes (a cable system can fail simply because someone forgot to balance the lengths properly), and makes mechanical assistance much easier to do.
Airbus uses it to avoid having pilot inputs exceed the flight envelope as well.
Re: (Score:3)
They've done a good job of making ABS fail soft, but an ECU that controls the throttle is needlessly asking for trouble. Keep the mechanical linkage to the throttle plate, and the ECU can't force the engine to produce more power than you'd get at idle. That's a simple approach that was used for years. Why did they abandon it? While they had a good track record, it seems like the car companies may be getting over confident about electronic control.
The reason they went fly-by-wire was wire is a LOT lighter ...
Strictly speaking you're right, and FBY doesn't require compu
Re:Technology is hard and dangerous (Score:4, Interesting)
No, it's more than that: it has a penetration through the firewall (which means some kind of rubber grommet usually), and connections to both the throttle pedal and to the throttle body. On top of that, there's usually some extra brackets to route the cable.
When you account for all these things, that's a bunch of assembly steps that some worker has to do, while crawling around under the dashboard and under the hood. That takes a lot of time. With an electronic throttle, you don't have to do all that; the pedals are a complete assembly, the throttle body is part of the engine and all the connections to that are done during engine assembly. The engine is then dropped in, and a few electrical connections made to the wire harnesses that were installed earlier. The pedals are bolted in as a complete assembly, and again all the electrical connections made all at once with a single connector being plugged in. With electrical connections, lots of connections can be made by plugging in a single connector. Not so with bowden cables.
Re: (Score:3)
Drive-by-wire exists because of emissions regulations. The ECU precisely controls the position and rate of the throttle plate to optimise combustion during transient events. The current emissions regulations require strict control of combustion from the moment the first cylinder fires on cold start-up.
Re:Technology is hard and dangerous (Score:5, Insightful)
Re:Technology is hard and dangerous (Score:5, Informative)
Yah I had a jammy throttle in a RX7 I used to drive. Whenever the gas pedal started to get sticky it'd be time to pop the hood and spray it with some WD40.
WD means "water displacer", not lubricant. Should have used a lubricant, not a water displacer. I like silicone products for the engine top, but sometimes I'll just use a general purpose grease.
Re:Technology is hard and dangerous (Score:5, Interesting)
"This is the argument Boeing put forth about Airbus and its fly-by-wire planes...until the gave in. We cannot stop this type of progress, but it would be nice if there was still somewhere a killswitch that was manual and separate from the computer...just as a last resort if possible."
Having researched this issue not very long ago, I can tell you that the issue is not as black-and-white as you make it out to be.
Boeing has been building "fly-by-wire" planes almost as long as Airbus. The major difference (which Airbus aficionados still dispute but which is supported by factual records) is that Boeing put more and better physical ("manual") backup systems in their planes than Airbus did. And the consequences, as shown in the safety record, speak for themselves. Airbus' systems in some cases led to pilots literally sitting horrified in their cockpits watching disaster happen and not being able to do a single damned thing about it.
Kill switches, manual disconnects and backups, etc. all have to be built in. Doing otherwise is just plain irresponsible.
But hey... you're talking about the automotive industry here, remember? The same guys who control engines and entertainment systems with the same CPU, and who put android systems in new vehicles with no way to upgrade them for the life of the car.
Re: (Score:3)
"Actually software control can be more reliable than mechanical, but it has to be designed correctly."
No, they can't, because ultimately they rely on mechanical components, even if those components are plain old electrical spade connectors.
You are displaying the same myopic mindset of those security people [youtube.com] who will design an "unbeatable" electronic combination lock [youtube.com], then mount it with cheap hardware [youtube.com] and a latch spring so weak that dropping the box on the floor will open it. [youtube.com]
If you could make it all solid-state, from top to bottom, with no mechanical components whatsoever, then maybe you could make it s
Re:Technology is hard and dangerous (Score:5, Insightful)
Yeah, the point of crumple zones is that the car gets damaged as opposed to the people inside. In fender benders old cars do better, but in a serious accident you'll be hurt worse in an older car. That doesn't stop me using a old car as my primary transportation, but I am aware that I am taking a risk doing so.
Re: (Score:3)
Re: Technology is hard and dangerous (Score:5, Funny)
A shame that manual transmission didn't stop you posting while driving though.
Re:Technology is hard and dangerous (Score:4, Insightful)
Good points. I guess the 1949 Chevy truck my dad and I rebuilt back in the 1990s wasn't very safe for passengers. You'd get thrown from it or something. But it sure was safe itself. One time we had a car come flying around the corner to close and slammed into the left rear wheel well of the truck. The car was totaled. The truck had a small dent on the fender. (The metal is so much thicker on those old cars, we had to use a sledge hammer instead of a normal body work hammer to take the dent back out). But again, if we were IN the truck when that happened we probably would have not fared so well.
Modern steel is much stronger, the cars just crumple because they are supposed to.
Re: (Score:3)
Crumple zones work in multiple ways, and one of them is to put the vehicle into a state of needing such expensive repair that after a certain (relatively young) age that it no longer makes financial sense to get them back on the road.
While driving a big old early-90s metal Buick, I was in a fairly low speed rear-ender by a new late-2000's fiberglass and plas
Re:Technology is hard and dangerous (Score:5, Informative)
You'd lose that bet.
And likely only once.
http://www.youtube.com/watch?v=xtxd27jlZ_g [youtube.com]
No, you'd be experiencing far greater acceleration forces, as if no portion of the car gives way and soaks up kinetic energy, a greater portion of it will be transferred to anything not bolted securely to the frame (eg: you).
The cabin is under no circumstances a crumple zone. Engine and trunk compartments make great crumple zones. The cabin should be a vehicle's Waterloo.
Re: (Score:3)
"You'd lose that bet. And likely only once."
Likely not.
(1) At what speed was that crash test? My guess is (supported by my guess from the full-speed portion of the video) is that it was not a high-speed crash. Just as I was saying. I was referring to more of a high-speed crash, and the Chrysler is significantly heavier than either of those cars. (You probably can't answer this question because I looked at the site of the folks who made that video and it says it is not searchable right now.)
(2) The 2009 Malibu, while classed as "mid-size", is a
Re: (Score:3)
This reminds me of people who complain that their motorcycle helmets were defective because they cracked the first time they were involved in an accident.
Re:Technology is hard and dangerous (Score:5, Informative)
I apologize if I'm stating the obvious here...
Most older products were over-built for durability because there were not methodologies for engineering minimum material for the required applications. Cars and other things were built with thicknesses of material that were tested and known to work. To reduce that thickness risked approaching an unknown threshold for failure. Trial-and-error was used where budgets allowed to reduce material, but this was an expensive process and in most cases the manufacturer chose to overbuild.
In more recent years, computer modeling has enabled engineers to load test structural designs so that the product can be built with the minimum amount of material required to satisfy the desired application. This benefits the producer, the consumer, and the scrap yard, while delivering overall efficiency.
Re: (Score:3)
I agree. Repeating myself a little, but I think the point is worth making. ECU's have been around since the 70's, and became ubiquitous in the 80's. AFAIK the older systems had a mechanical linkage between the gas pedal and the throttle plate. The ECU then read the air flow sensor, and various other sensors, to set the fuel injection and spark timing. Obviously it can fail, but it's a soft fail. The engine won't run, or more likely won't run well. Sudden acceleration or unstoppable engine though? Forget it.
Re:Technology is hard and dangerous (Score:5, Insightful)
Obviously it can fail, but it's a soft fail. The engine won't run, or more likely won't run well. Sudden acceleration or unstoppable engine though? Forget it. With the throttle plate closed there's no way you can get any more than the power produced at idle, no matter what the ECU does.
That is exactly the thing that makes this jury verdict so suspicious.
The driver was 76 years old at the time. This crash was subject to an NTSB investigation, and investigators found no evidence that it was a software fault or a hardware fault. The crash recorder says the driver pushed the accelerator and was not pushing the brakes, and then the car was hit.
And most interestingly from TFA is the last line. Ten of the 12 jury members said they wanted to punish Toyota.
If he was pushing on the brakes he could have probably overcome most of the force of a sudden accidental acceleration. If he had more time there were other options like shifting to neutral, but he was approaching an intersection.
When I look at it, an older driver and vehicle recording systems saying the accelerator was pressed and the brakes were not, investigators finding no evidence to support the claim of a software failure, and then the jury stating they want to punish Toyota, I don't see this as a good verdict.
Re: (Score:3)
"And most interestingly from TFA is the last line. Ten of the 12 jury members said they wanted to punish Toyota. "
Yeah? And so? What is your point?
The jury heard the testimony from all the witnesses. They saw and heard all the evidence. THEN they wanted to punish Toyota. Yes? So what's wrong with that?
When jurors hear a case about a vicious and brutal child molester, and decide he's guilty, the jury often wants to punish him, too. I'm wondering why you think that's a bad thing.
"When I look at it, an older driver and vehicle recording systems saying the accelerator was pressed and the brakes were not, investigators finding no evidence to support the claim of a software failure, and then the jury stating they want to punish Toyota, I don't see this as a good verdict."
This is the problem with armchair judging. You saw or read that part, and nothing else. But the jury saw that, and much more. It is almost
Re:Technology is hard and dangerous (Score:4, Insightful)
Yes, but software failures like this are a very rare cause of accidents. Vastly more common is human error, which your classic car won't help with. However when some human cockup results in a crash you'll be more likely to be injured or killed thanks to the much poorer crash safety of old cars. This will easily outweigh the tiny reduction in risk from having no software.
Re:Technology is hard and dangerous (Score:5, Funny)
Why the need to push and pull everything to the extreme that they can pushed or pulled to?
It's kind of the unofficial /. posters motto:
Ad absurdum, Ad infinitum, Ad nauseam!
Add Vodka...
"Impact on self-driving cars?" - None (Score:4, Insightful)
Those working on self-driving cars and those that are watching the technology already know that any such car would need an absolutely 100% rock solid OS.
This changes nothing.
Re:"Impact on self-driving cars?" - None (Score:5, Informative)
Re: (Score:3)
Re:"Impact on self-driving cars?" - None (Score:5, Interesting)
Not sure why this was modded flaimbait... this is one of the areas where Ada does generally shine, it is a language built for auditing.
That might turn out to be an important point. Suppose some day two cars of different manufacturers cash into each other. Will comparative code audits find their way to court?
Re: (Score:3)
Mentioning any computer language is by definition flamebait, because entrenched advocates will lash out at
any mention of anything other than their pet language.
The present story suggest the code was C, which was supposed to be written to the Motor Industry Software Reliability Association [wikipedia.org] standard. One of the key features of the standard was the availability of a large number of code verification tools. That may not be the case for other languages.
Its obvious from the story that none of these code analysi
Re: (Score:3)
Probably true, though I'm surprised anyone these days has even heard of Ada. Must be an older moderator, but one who thinks anything he doesn't agree with should be modded down. Better if you'd said safety critical software should be written in Ruby or something.
There are many things I like about Ada, but even the military has given up on it. The F-22 software was written in Ada, but the F-35 software is written in C++. Hmm, considering how the F-35 project is going, maybe they should bring back Ada.
Re: (Score:3)
Ada 83 sucked. Ada 95 fixed most of the problems, and I believe that they're up to Ada 2012.
Re:"Impact on self-driving cars?" - None (Score:5, Funny)
Ada 83 sucked. Ada 95 fixed most of the problems, and I believe that they're up to Ada 2012.
Wow. From 95 to 2012 - they must be using Chrome/Firefox style version numbering :-)
Re: (Score:3)
Probably because ADA was a government design by committee thing
That was the assumption most people made, not the reality. Jean Ichbiah was the chief designer, and worked with a very small team. If you actually learn Ada, you'll see that, whether or not you like it, it's very consistent and well thought out. It's not a bunch of bolt-on features like a committee design.
Re:"Impact on self-driving cars?" - None (Score:5, Insightful)
I'd be happy with a car OS that kills less than 30,000 people per year.
http://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_in_U.S._by_year [wikipedia.org]
Or even less than 10 million accidents a year.
http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html [census.gov]
Re:"Impact on self-driving cars?" - None (Score:4, Interesting)
The car OS is not ok if it kills any people at all (Score:3)
I'd be happy with a car OS that kills less than 30,000 people per year.
If a car manufacturing defect kills anybody at all, then there should be manufacturer's liability for it.
They don't get a free pass just because of the kind of manufacturing defect, there's no privilege against liability just because it's a software defect.
-wb-
Re: (Score:2)
Re: (Score:3)
Ha ha, classic:
"Svenson (1981) surveyed 161 students in Sweden and the United States, asking them to compare their driving safety and skill to the other people in the experiment. For driving skill, 93% of the US sample and 69% of the Swedish sample put themselves in the top 50% (above the median). For safety, 88% of the US group and 77% of the Swedish sample put themselves in the top 50%." cite [wikipedia.org].
Re: (Score:2)
This changes nothing.
Oh it does -- they've been renamed self-blaming cars. 3 Laws of Robotics never saw this coming.
Re: (Score:2)
Those working on self-driving cars and those that are watching the technology already know that any such car would need an absolutely 100% rock solid OS.
This changes nothing.
But then its principal advocate is Google, where good enough gets pushed to production, left to languish and spring cleaned [blogspot.com] out of existence in a couple years.
So in spite of the engineers knowing this, the trend is worrying.
Especially when some of these cars are starting to be drive-by-wire [wikipedia.org] and the trend is that there will exist no physical linkage between the human interface and the cars brakes, engine, steering.
Some how the assurance from and AC that "all is well" and Trust them, they are Scientists, just
Re:"Impact on self-driving cars?" - None (Score:5, Insightful)
Re: (Score:3, Insightful)
Not necessarily. If said cars kill fewer people than humans, it's still an improvement that should be done.
The problems are lawsuits. A drug that saves 90% of cancer patients but kills 1 in 10 independently will have it's ass handed to it in civil. court -- assuming it makes it past the FDA.
Would that outcomes analysis be applied to government activities and civil lawsuit lawyers ' claims of bettering the system as they fatten their wallets.
Self-driving cars will come with an EULA (Score:5, Insightful)
Re:Self-driving cars will come with an EULA (Score:5, Insightful)
Won't do any good. I can agree to a hold-harmless provision (and, despite the language of the EULA, such clauses are not actually universal). What I cannot do, is agree to it for someone else. You'd better believe a pedestrian hit by my self-driving car can sue the living daylights out of them. Heck, as previously mentioned, depending on what the particular problem is, *I* can still sue them.
Re: (Score:3)
Nevermind that, I'd never own (or ride in as the 'driver'/trip planner, whatever) a self-driving car unless it was blatantly legally clear that I am not to be held accountable for its behavior.
Re: (Score:2)
I am sure they will, and they always would have.
But just because you sign that, does not mean that the manufacturer/programmer will not be held responsible for the bus load of kids who drove off a cliff.
' Anyone wonder what the impact will be? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Not having an accident is also data.
Re: (Score:2, Insightful)
As a old mechanic if you believe for one second that autonomous cars are going to maintained and inspected the way that planes are then you got a bridge to sell you.
The question is not can we build these thing to me, the question is can we reliably maintain then in any capacity. As a mechanic I would take on liability for the parts repaired can you imagine the legal infrastructure required to allow someone other then the manufacturer to maintain and build these things. How do you compensate for a wheel bea
Re: (Score:2)
Get from A to B as fast as possible, as safe as possible, or along the most scenic route. What other self-driving features would you want? And why would any other features be brought anywhere near the autopilot systems? Sure, maybe you want a friendly robotic chauffeur/bartender avatar in there with all the extras, that's fine - there's absolutely no reason to give it any more connection to the autopilot than a well-fused text-mode serial port link to give terse orders to the autopilot which you have to
Re: (Score:2)
I don't see why updates for the navigation, entertainment (or anything that's not on the powertrain for that matter) should have anything to do with the ECU...
Relevant paragraph (Score:5, Informative)
2nd link, 5th paragraph:
Re: (Score:2)
It's interesting to me that NASA was looking at it - though I can certainly understand why they would be interested and why they might have some useful insight.
Re:Relevant paragraph (Score:5, Informative)
FTA: "Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration."
The impact on self-driving cars? Documentation. (Score:5, Funny)
A longer chapter on debugging in the first edition of "Programming Self-Driving Cars: The Missing Manual."
Re: (Score:3)
Clearly it will completely stop the auto industry, just like cars that exploded when rear ended stopped the auto industry.
If there's no human fall back, I'll never trust it (Score:4, Insightful)
Re:If there's no human fall back, I'll never trust (Score:5, Funny)
"If there's no human fall back or ability to overthrow the computer's control of the car I'll never drive it."
by definition you wouldn't be driving it.
Re:If there's no human fall back, I'll never trust (Score:5, Interesting)
There was a time after automated elevators first came out when people refused to use them because they didn't trust them without a "human fall back or ability to overthrow the computer's control". Today, when nearly all the elevators we've ever seen were automated, this seems crazy.
In 50 years, when most people have never seen a manually operated car, we'll seem just as crazy for not trusting them.
Re: (Score:3)
Elevators have a mechanical safety that you as a passenger have no control over, so it doesn't address neoritter's demand for a human fall back. And that mechanical safety only protects you from a cable failure. It does nothing to protect you from out of control elevator computers bouncing you up and down the shaft.
Re: (Score:3)
And such a device could easily be put on a car.
Which device, a big red stop button? That's only true for stopping the engine. It wouldn't work for steering or brakes, as would be needed in a self-driving car.
It's also presumptuous to assume his fear is irrational. He stated his reasons (and he sounds like a programmer, so he's not just talking about a bogey man he doesn't understand). If you disagree with him it doesn't necessarily mean his fear is irrational.
Re: (Score:2)
Half of the cars I've had didn't come with ABS, ECU, airbag, security. They all did come with car radio/cassette player.
Re: (Score:3)
Oh certainly, there's lots of reasons to have all sorts of things wireless, and I fully expect all the fancy media systems, etc to go that route. I just don't think the autopilot will be so, any more than the engine control module is today. A wireless kill switch is one thing, but that doesn't need to be connected to the autopilot, just its power line. And so long as the producers aren't shielded from liability for faulty security I would expect them to take a heavily safe route.
That's not to say that I
Electronic throtle control problems (Score:2)
Still happy that my car (not a Toyota) has a stick and thus a mechanical clutch pedal :)
On the other hand, doesn't automatic gearboxes have neutral setting? Wouldn't moving into this be roughly the same as depressing the clutch on a manual gearbox? Of course, the reaction times are longer (since you have to do something unusual when driving an automatic, i.e. touching the shifter while in motion), but for the cases you hear of where they managed to call 911 while figthing to control the vehicle...
wtf (Score:4, Interesting)
'Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.'
Huh? I'm a software engineer and don't understand the relevance of this statement, how can a jury? How does it confirm that there was a defect?
Re:wtf (Score:5, Informative)
Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration.
The jury could confirm there was a defect because they were able to reproduce it with a physical car. They could confirm the code quality was poor because it 1) It didn't follow the required code standards: MISRA C, 2) The cyclomatic complexity was too high 3) Toyota didn't track bugs.
Re: (Score:3)
Where in TFA does it state that they re-produced the problem on a physical car? The testimony says that they did an analysis of the source code in a room, with comments translated from Japanese to English by software. They eventually discovered some potential ways in which it could fail and cause unwanted acceleration, but it does not appear to have been tested or even determined a likely cause of the failure that happened.
Re:wtf (Score:5, Funny)
Are you sure you are a software engineer, and not some programmer with delusions of grandeur?
Re: (Score:2)
A good attorney and expert witness will make it clear to the jury that there are several standard and well-known processes that need to be followed to test software, and that Toyota did not follow them.
Re: (Score:3, Interesting)
'Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.'
Huh? I'm a software engineer and don't understand the relevance of this statement, how can a jury? How does it confirm that there was a defect?
Hate to say this but I think any foreign company on trial in the US is going to get reamed. Americans are very anti-foreign companies. If the company was Chinese, probably guilty on all accounts.
Improper stack analysis does not prove a defect. However, it gives a jury enough rope to hang.
Nothing new (Score:2)
Car makers can and have been sued for defective mechanical designs many times. Now they're getting sued for defective and dangerous software and computer hardware designs. I don't think there's much of a difference between the two when it comes down to it. You were either negligent or not, and whether it's software, hardware, or mechanical stuff doesn't really matter.
No memory parity! (Score:3)
Good lord, they have got to be kidding? If Toyota (or their parts suppliers) are making those kinds of errors, you can bet your ass that other manufacturers will be making them as well.
There needs to be very strict set standards for car control systems. We have standards for OBD, so why not strict, over engineered and thoroughily coded critical systems standards? Even better, why not make them open standards, including the hardware?
Standardising would make parts cheaper as well as stopping manufacturers from building closed black box units that may be of dubious quality. It would also make it easier to maintain and repair modern cars as they get older, and allow third parties to provide new hardware long after the manufacturer loses interest.
As an aside, I do wonder what we're going to do in ten years time when the failure rate for most of the control hardware starts creeping up. Would they fail safely? Would the repair cost be prohibitive?
It would be a sad irony if these environmentally conscious efficiency improving measures resulted in cars being scrapped en masse because the ECU that superseded a $10 throttle cable costs a grand.
Awesome transcript (Score:5, Informative)
I've been reading the transcript. It's fantastic. The expert explains clearly and lucidly in terms that (I imagine are) understandable by non-techies.
The transcriber made some funny mistakes... Let me tell you about "parody bits" and "pointer D references" :)
More Details (Score:5, Insightful)
Couple of details here:
Toyota had no software testing procedures, no peer review, etc. The secondary backup CPU code was provided by a third party in compiled form, Toyota never examined it.
Their coding standards were ad hoc and they failed to follow them. Simple static analysis tools found massive numbers of errors.
They used over ten thousand global variables, with numerous confirmed race conditions, nested locks, etc.
Their watchdog merely checked that the system was running and did not respond to task failures or CPU overload conditions so would not bother to reset the ECU, even if most of the tasks crashed. Since this is the basic function of a watchdog, they may as well not have had one.
They claimed to be using ECC memory but did not, so anything from single bit errors to whole page corruption were undetected and uncorrected.
A bunch of logic was jammed in one spaghetti task that was both responsible for calculating the throttle position, running various failsafes, and recording diagnostic error codes. Any failure of this task was undetected by the watchdog and disabled most of the failsafes. Due to no ECC and the stack issue below, a single bit error would turn off the runnable flag for this task and cause it to stop being scheduled for CPU time. No error codes would be recorded.
They did not do any logging (eg of OS task scheduler state, number of ECU resets, etc), not even in the event of a crash or ECU reset.
The code contained various recursive paths and no effort was made to prevent stack overflows. Worse, the RTOS kernel data structures were located immediately after the 4K stack, so stack overflows could smash these structures, including disabling tasks from running.
They were supposed to be using mirroring of variables to detect memory smashing/corruption (write A and XOR A to separate locations, then compare them on read to make sure they match). They were not doing this for some critical variables for some inexplicable reason, including the throttle position so any memory corruption could write a max throttle value and be undetected.
Instead of using the certified, audited version of the RTOS like most auto makers, they used an unverified version.
Thanks to not bothering to review the OS code, they had no idea the OS data structures were not mirrored. A single bit flip can start or stop a task, even a life-safety critical one.
These are just some of the massive glaring failures at every level of specifying, coding, and testing a safety-critical embedded system.
I am now confident in saying at least some of the unintended acceleration events with Toyota vehicles were caused by software failures due to gross incompetence and negligence on the part of Toyota. They stumbled into writing software, piling hack on top of hack, never bothering to implement any testing, peer review, documentation, specifications, or even the slightest hint that they even considered the software something worth noticing.
Re:The Toyota Way (Score:5, Insightful)
Your post demonstrates a complete lack of understanding of what JIT manufacturing (i.e. lean) is and what it tries to accomplish. Hint: it's not about doing more with less. Further, you either willingly fail to mention Kaizen (continuous improvement) or just aren't aware that THIS is the heart and soul of the true Toyota Way.
Whatever the reasons they failed in software engineering, neither JIT nor Kaizen would be to blame because neither of those try to nor should they translate to "engineer badly".
Re: (Score:3, Insightful)
Actually, there is absolutely zero proof that they did fail.
NASA certain could not find any way to fault the system.
What this decision is based around is a bunch of technical argument that they could have tried harder to prove
that the system could not fail, but with absolutely zero proof that it does or even can fail. No procedure to make
the software fail was presented, no theory of a set of inputs that could result in the theorised output was presented,
only a critique of their testing and analysis procedur
Re:The Toyota Way (Score:5, Interesting)
In a nutshell, the team led by Barr Group found what the NASA team sought but couldn’t find: “a systematic software malfunction in the Main CPU that opens the throttle without operator action and continues to properly control fuel injection and ignition” that is not reliably detected by any fail-safe.
That's proof, not an argument that they could have tried harder to find the system could fail. The bottom line is that its software that puts people's lives at risk. It's reasonable to hold that type of code to a higher standard. There are millions of other cars, trains, and planes out there with similar software but without this type of problem. At some point you should be responsible for the things you create.
Re:The Toyota Way (Score:4, Informative)
Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration. A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.
Re: (Score:3)
If you read the sentence before that: As single bits in memory control each task, corruption due to HW or SW faults will suspend needed tasks or start unwanted ones. It only took a single bit in non-error-detecting RAM getting flipped to cause that particular fault, something that could easily happen due to cosmic rays or minor radioactive contamination in the ECU packaging - and that's before you even take into account all the other potentially memory-trashing code. It's more like a manufacturer deciding
Re:The Toyota Way (Score:4, Informative)
> Again, so far ZERO evidence, proof, or test case has been provided that the software is in any way responsible for this problem.
Re: (Score:2)
http://singularityhub.com/2010/05/12/stanfords-robot-car-slides-into-parking-spot-like-a-badass-video/ [singularityhub.com]
And you want me to try that manually? Do you want me to hit 2 cars and then flip over?
Re: (Score:2)
This is one of those scenarios where the cultural fascination with the concept is going to push it into practice before it's really ready...if it ever is. Open terrain autonomy is not an easily solvable problem as it relies more on contextual awareness via multiple mediums rather than raw reaction time. Humans are still far better at this than any computer. The fact that toyota, likely the most safety conscious car manufacturer in the world, could not account for all possible behaviors of their code in a re
Re: (Score:3)
You mean humans, who get it wrong 10 million times a year in the USA alone [census.gov]?
10M accidents out of 250M drivers isn't a very good error rate.
Re: (Score:2)
Re: (Score:2)
10,000,000 accidents per year in the US alone.
http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html [census.gov]
I can just see the headlines. "Self driving cars cause hundreds of thousands of accidents per year!"
Even though that'd be ~1% of what humans do.
Re: (Score:3)
Re:It is about time!!! (Score:5, Informative)
Any engineering project requires that the engineers have to answer for what they've done. The mantra is, "As an engineer, if you fuckup, someone dies." Every engineer, regardless of discipline, needs to understand this and if they don't, should consider going into Liberal Arts or something equally useless where the worst they can do is fuck up my food or drink order.
Re: (Score:3)
That will be feasible in software when signoff by the equivalent of a PE is required.If PEs couldn't hold a project hostage until it was actually safe, we'd see a lot more cut corners by management. In software, nothing prevents the corner cutting currently.
A software engineer who attempts to dig in and demand more QA and debugging time will be reassigned (possibly to the unemployment line).
Re: (Score:2)
Not necessarily. Some CPUs allow for multiple hardware stacks -- when the interrupt occurs, the CPU also does a stack switch.
Re: (Score:3)
It's an ECU, not a desktop. All those latencies you're used to are OK when you're browsing the internet or programming the Next Big Thing, but they are not acceptable when you're adjusting fuel ratios, timing detonations, responding to impact sensors etc.
You clearly have no idea what you're on about, or why real-time operating systems are real things that have actual niche use.