Slashdot Mirror
Toyota's Killer Firmware
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?"
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.
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.
The owner of a self-driving car will have had to accepted the EULA and accepted not to hold the manufacturer liable for sofware defects. (half joking but I wouldn't rule it out)
Sure, they will be more safe. Just like in the aviation industry, where each incident/crash is investigated meticulously, and flying has become safer ever since 1903. With non-selfdriving cars 99% of the incidents were caused by human error. Now no more, so we can fix it!
2nd link, 5th paragraph:
Anyone wonder what the impact will be on self-driving cars?
A longer chapter on debugging in the first edition of "Programming Self-Driving Cars: The Missing Manual."
Brought to you by Carl's Junior.
> "and missed RTOS use during task switching"
IRQs will piggyback atop the main stack. Since control does not devolve back to that thread until the IRQ finishes, this is perfectly fine. However you have to consider IRQ's worst-case use atop your thread's worst-case.
We don't use an OS so OS stack use isn't an issue. Obscured recursion as chains of functions call each other in hidden ways is something to consider.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
If there's no human fall back or ability to overthrow the computer's control of the car I'll never drive it. I don't think this will change anything except maybe give the people that are rushing for self-driving cars some pause. Every developer knows the risks of self-driving computer controlled cars (if they don't, well they're naive). Between human error in programming and human maliciousness, there are two camps. People who think they can overcome the possibilities of putting a semicolon in the wrong place and prevent hackers from comprising the software's integrity. And people who realize the first people are fooling themselves.
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".
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...
'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?
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
Remember when Toyota and DOT concluded the problem was driver error and improperly fitted floor mats?
But how else will I do my Blues Brothers parking job perfect every time?
http://singularityhub.com/2010/05/12/stanfords-robot-car-slides-into-parking-spot-like-a-badass-video/
And you want me to try that manually? Do you want me to hit 2 cars and then flip over?
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 relatively simple computer system speaks volumes about how far away we really are from safe autonomous, free range robots. On the road, drunk drivers and idiot soccer moms with cellphones are a lot easier to spot and avoid unlike the way out of box behavior caused by subtle programming bugs in complex hardware. Maybe the day will come, but it certainly won't be here by 2020. For now, I'd rather share the road with humans who get it right most of the time, than with (or be driven by) computers having only the tiniest fraction of the situational awareness.
10,000,000 accidents per year in the US alone.
http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html
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.
There are two types of people in the world: Those who crave closure
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.
some karma... and kinda lukewarm about it.
"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.
The Kruger Dunning explains most post on
Half of the cars I've had didn't come with ABS, ECU, airbag, security. They all did come with car radio/cassette player.
- Raynet --> .
Trust? No, I'd want to see test results. Believe that it's possible? Hell yes.
You mean humans, who get it wrong 10 million times a year in the USA alone?
10M accidents out of 250M drivers isn't a very good error rate.
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.
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.
I'm unsure how you're attempt to paint me as a hypocrite would ever be successful. Economic pressures essentially force me to buy new cars that have computerized control systems. For instance I don't pay as much for car insurance because the newer cars are (in general) deemed safer. That's not to say I try to cut back on certain features where possible. Such as not getting the remote key-less entry and ignition systems installed on my car. If you read the second linked article you'll notice mentions of interrupts that can be done by the human to prevent improper function or restore proper function of the vehicle. In this case (Toyoto), the human interrupts were sent to single points of failure or were inadequate to prevent catastrophe.
Lol, you're right. I guess drive should change to ride.
Its ready NOW. The tech is ready, the people are ready, the politicians and business is NOT ready. We have an incredible fuck-ton of social bullshit to slog through before we will get truly viable, awesome autonomous transport. WE could convert all the carpool lanes into autonomous only tomorrow, wall it off from normal traffic with a barrier and those cars could easily go 100 MPH with incredible safety. Politics and social change will take far longer then the tech will to fully mature.
Good-bye
All personal cars will have self-drive fallback, but there will be roads that wont allow you to self-drive on them. Eventually you will only be able to self-drive on a track or in emergencies (which are logged).
Good-bye
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 procedure that poked a few holes in that.
This is a VERY concerning direction for programmers in the USA, as of course complex software by definition cannot
be proven correct (at least there currently exists no known way). It opens the door for all sorts of development-process
based litigation, which is a very very bad direction for things to take.
Again, so far ZERO evidence, proof, or test case has been provided that the software is in any way responsible for this
problem.
Certainly I'd want an autopilot toggle switch - principally so I could drive it for pleasure or in unexpected / offroad ways. As far as safety is concerned I suspect that the headlines where "human disables malfunctioning/compromised autopilot, saves life" would be dwarfed by those where "human confused by crash avoidance strategy disables autopilot and causes horrible crash"
As for security, it's not *that* hard. Just disable all wireless communication for starters. Once someone has physical access to the car all bets are off anyway, people were cutting brake lines long before anyone ever heard of a buffer overflow attack.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I have a 2013 Prius.
1. On mine at least, they made modifications so that brake input will override throttle input. I don't know if this is mechanical, or software.
2. You can either hold the power button in for a few seconds, or give it three quick taps. This will shut down the "hybrid system" as they call it.
3. The parking brake (note my use of 'parking' not 'emergency') does a good job at holding the car still, but it sucks terribly at stopping a moving vehicle. This is not unique to this car, either. That said it also sucks at holding it still if you give it any throttle input - but that's not unique to this car either.
4. You have no direct transmission control. It's an electronic jog stick dressed up as a shift lever. Remember, this is a CVT and not a traditional manual or automatic transmission.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
The only thing you've mentioned that controls the car is the ABS (and traction control). With the absence of a drive-by wire system, there is a physical link to the throttle the ECU can't override. All it can do is control the idle valve, which has physical limits as to how much air can pass.
Electric power steering may pose a problem, but that's only recently coming in to new cars.
Also old school cruise control that has an actuator that moves the gas pedal.
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
On a societal level that makes sense. If a software bug crashes your car and you're paralyzed, it's little comfor to be told you might have crashed yourself.
If you're a good driver, a firmware bug that crashes your car is a BIG problem. The fact that other people avoided accidents because the software is better than a human isn't exactly relevant.
While it's true that "You cannot possibly code for every driving scenario, even with collision avoidance systems.", you need to remember that neither do people. So saying the car is a safer driver than most people doesn't require perfection. Avoiding liability suits, however, may.
I think we've pushed this "anyone can grow up to be president" thing too far.
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?
For years, some cars have not had mechanical linkages to the automatic transmission; the shifter is just a human interface that plugs into a wire. This started in the luxury market and has wound its way down. Interfaces include joysticks resembling shifters, rotary dials, and push buttons.
The slide has been away from direct mechanical control of various car components for a while. It started with throttles, then it went to brakes (yep...) and now even some steering systems are going to steer-by-wire. Same for push-button ignition control systems. It's pretty horrifying.
Still, plenty of "runaway" cases have involved vehicles with mechanical ignition keys, mechanical transmissions, and mechanical throttles. People are just stupid, uneducated (they think that if they shift out of Drive the car will explode, ditto for shutting off the ignition...poor braking technique, like trying to "ride" the brakes to reduce speed, instead of braking HARD to STOP the car immediately) or get caught speeding and try to use it as an excuse to get out of it.
Please help metamoderate.
In the case of Google's claim, they're backing it up with solid data
Do you have a link to that? Seriously, no snark. All I've seen is hype, but I can't say I've read everything they've published.
What about testing in rain or snow, especially falling snow? Unmapped roads? Heavy pedestrian traffic? Do what extent is their safety record accounted for by the fact that the drivers know when the autonomous mode is likely to get into trouble, and shut it off before that happens?
That there is some theoretical person who can out-perform them doesn't mean they aren't a net benefit (including those who can outperform them). ABS was mandated, despite many people being able to out-perform early versions and even a number of later versions.
I disabled my ABS for a while until Subaru performed a "service bulletin" (voluntary recall in "it's not a recall" language). It was so unknown by dealers, that I called in to make my appointment, gave the bulletin number, and dropped my car off without issue, then they called 6 hours later to state they were unaware of such a bulletin. I came back in with the letter from Subaru, and 2 days later they acknowledged it exists. Weeks later (after they ordered parts), I got the ECU replacement. I used my ABS after that. Before the "non-safety related issue" I'd roll through stop signs and red lights if I was braking hard and hit a pot hole (the ABS would read that as a loss of traction, and disable the brakes until traction was registered as regained, which was 30+ feet). The fix was much better.
Learn to love Alaska
I can agree with you for the most part. But I don't think there's a trend there that would cut wireless. Just look at OnStar and its ability to cut off your engine. The trend in technology right now seems to be, make everything wireless and connected. From TVs to fridges, I don't quite expect cars to be any different. In fact, wasn't it a few years back that Ford (or some other make) was offering cars that had the ability to be mobile hot spots?
Its ready NOW.
How do you come to that conclusion? Not even Google says it's ready NOW.
"If it cant shoot down 100% of missles, then it is useless". So dont build it.
In real life, Isrealiis discovered that 90% effectiveness is a game-changer. There "Iron Dome" anti-missle defense is that accurate. People dont run to the bomb shelters every siren now. Nor do the enmenies attack that often, knowing most will be wasted. At some degree of accuracy people accept "good enough".
Then they were too new. I had a car that pre-dated tape decks (it had an optional 8-track player, but my car was no so equipped).
Learn to love Alaska
Its ready NOW. The tech is ready, the people are ready, the politicians and business is NOT ready.
I doubt it. The tech may be ready, the people implementing that tech are certainly not ready.
About 30% of my searches on Google return a "You searched for A, did you mean B" result. In about half of those instances, I actually get "You searched for A, here are the results for B." So with a Google car, I'm more likely to arrive at the destination safely, but about 15% of the time it will not be the destination I requested, but some other location based on some SW engineer assuming I don't know where I want to go.
I have a couple podcasts I save up for when I travel. In some cases I have months of episodes queued up for a long trip. A couple years ago iTunes started silently unsubscribing those podcasts. I guess the assumption is anything I don't listen to often is something I'll never listen to again. Recently it's even done that for podcasts I listen to weekly and don't store many back episodes. So with an Apple iCar, I'm more likely to arrive at the destination safely, but only at destinations anticipated by the engineers at Apple. And one day I'll try to visit my mother, and the display in the iCar will say it's been so long since I visited, the car assumed she was dead and deleted her address and route to her house.
I don't doubt the tech, I question the people the behind the tech. The reason Google returns results for something other than what I searched for isn't a technical issue. The reason iTunes seemingly randomly unsubscribes me from podcasts is not a technical issue.
For Google, I love the "did you mean B" options when I search for A. But give me the choice to search for B, don't just return results for B. For iTunes, I'm fine with a dialog box, "You haven't played this podcast for a while, still want to subscribe," but don't just silently unsubscribe, especially if it's going to happen for podcasts I do listen to often.
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-
Its shocking how you conflate these ideas. the engineering principles that go into serving up itunes is VASTLY different then making autonomous vehicle code. THe people who work on autonomous cars have very different backgrounds and degrees then those that design music websites. No one cares if you lose a podcast, its not anywhere near the scrutiny machine code gets.
"About 30% of my searches on Google return a "You searched for A, did you mean B" result. In about half of those instances, I actually get "You searched for A, here are the results for B." So with a Google car, I'm more likely to arrive at the destination safely, but about 15% of the time it will not be the destination I requested, but some other location based on some SW engineer assuming I don't know where I want to go."
If you fail to human verify your results before embarking, that is your own fault. Searching for information is a negotiation, the more precise data you put in, the more favorable your results will be. You cant be a moron and expect it to do everything. The only problem you described is that you cant accurately communicate to the system your intentions.
Good-bye
Sure, but you can't run an engine with a pre-emptive multi-tasking OS.
You need accurate timing in the sub-millisecond range.
I've love to see Linux controlling ignition and fuel delivery to an engine revving at 9000rpm.
Even a 4cyl engine at that speed needs accurately timed ignition pulses at 300 times per second.
To get ignition timing to 0.1 degrees at 9000rpm, that's 1.85 microseconds. About 900 clock cycles at 500MHz. Twice per second for 4cyl.
There is a point where a real-time OS is a requirement.
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.
Anyone wonder what the impact will be on self-driving cars?
In soviet Russia, self-driving cars impact you!
Yes, but you only need to solve it ones. And every year it gets better.
The Kruger Dunning explains most post on
So does this mean we can finally hold Microsoft accountable for all the crap they've foisted on the taxpayers through government purchases?
I'm feeling really positive about Google robotic cars driving themselves ...
Positive they'll be sued when they kill people, that is.
Especially kids. People don't care what your excuse is for that.
-- Tigger warning: This post may contain tiggers! --
Chris Urmson presented some data at this keynote, but AFAIK nothing has been published yet. Basically they showed that they stop and start more smoothly and spend less time in near-accident situations then even their professional drivers. They've logged over 300k vehicle miles with zero Google caused accidents, meanwhile MARTA has a target accident rate of 2.85 accidents per 100k miles, and wasn't able to achieve that in most of the previous 12 months!
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
I think you meant "none before I hack the OS".
Ooh, wonder what happens if I send these signals all at the same time when it's not expecting it?
Crash ... Tinkle
Cool.
-- Tigger warning: This post may contain tiggers! --
Did you read TFA?
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.
Doesn't work that way. You need a real-time OS as light as possible (less lines of code = less chances of bugs) and hardened hardware.
I've got better things to do tonight than die.
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 would be surprised by a networked navigation computer/robotic chauffeur/etc. I just don't think there is any reason to integrate it into the autopilot. There's no reason it couldn't just relay navcomp style "turn left in 1/4 mile" type instructions over a simple high-security text mode serial link with an extremely limited vocabulary. So long as the autopilot itself is heavily defended against intrusion the worst that's likely to happen is that a distracted passenger gets driven to a dangerous destination (the observant passenger would presumably flip the override switch)
Actually, for nefarious purposes the ideal autopilot hack would likely be to simply swerve suddenly into oncoming traffic, preferably into a cement truck or something, in which case it will all be over before a human could even reach the override switch - so perhaps an override delay would be advisable to prevent a panicked rider from screwing up the collision avoidance while still giving them time to take over for any less immediate threats. Maybe a two-stage switch - flip off the autopilot, then 20 seconds later press the button on the wheel to confirm that you really mean it and are in control - just to avoid the scenario where a panicked person tries to take control, gets stunned/unnerved/disoriented by the extreme recovery maneuverings, and proceed to drive themselves off a cliff.
In fact we probably want multiple autopilot settings - On and Off of course, but also "panic mode" where the autopilot takes over when a collision in imminent but still avoidable - great for when the kids are learning to drive, or you decide to go for a drive after you've had a few. And maybe something like a co-piloted "driving instructor mode" as well.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
> Again, so far ZERO evidence, proof, or test case has been provided that the software is in any way responsible for this problem.
I had a car that didn't have a tape deck and only five buttons for the radio. ...
And we LIKED it.
-- Tigger warning: This post may contain tiggers! --
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
Unlike what other technology? Not fire or electricity or television or smartphones or atlatls.
...if it ever is.
How do you find out until you let it loose?
Just in case that wasn't enough:
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.
You can drive at 16 in plenty of places in the US. I got mine at 15 (though I'm 38 now and don't know if that's still true).
I thought there were standards for C in automotive and aerospace applications which disallowed the use of pointer arithmetic.
Yeah, sounds like it's more hype than reality at this point. What they've done is very impressive, but I suspect it's a long way from working in true real world conditions.
I think so -- here you go.
[Post on slashdot instead]
CLI paste? paste.pr0.tips!
What I've seen is that people don't apply the brakes. They may apply them 10% or 20%, burning them up without stopping the car, but in the Audi case, I remember one of the defenses being they showed a triggered acceleration, and someone easily controlling it with the brakes, indicating that the problem was that the people weren't standing on the brakes. That helped lead to the discovery that they were standing on the accelerator mistakenly.
The longer cases of Toyota showed evidence of brake damage. That indicates that there was actual acceleration, and the brakes were applied, though inadequately. There is no car available in the US with an engine more powerful than the brakes.
Learn to love Alaska
*gasp* 5 seconds? Seriously, what 'did you eat earlier' when /that/ happens?!
CLI paste? paste.pr0.tips!
You were extremely right 10 years ago. You are still pretty much correct today. But I sure hope you will be mostly wrong in another 10 years.
For truly risky applications, I want to use a tool that makes it extremely hard to shoot myself in the foot, while still meeting the required performance parameters. No more mutable state. Use static code analysis to make sure stack overflows can't even happen. A language where NPEs can't happen, because we use some form of Option parameter. Now, tools like that are often too slow for most embedded systems today, but a man can dream.
Thanks for the heads up. I've bought a number of Toyotas, and been satisfied. Last time was a 2006 model. Pretty good, but I've heard from a number of sources that they've gone down hill since then. A shame. A reputation like they had takes decades to build, but can be destroyed in a few years. Maybe they've been infected by American management thinking.
I was reading through comments hoping to find some general opinion of whether or not Barr's findings could have applied to practically any software stack. You usually don't have to work very hard when reading through code before you spot a bug or two. But in my experience most of these bugs are never (or rarely) exposed because they lie in corner cases. But in the case of Toyota's electronic throttle control system, you'd have higher expectations.
It sure sounds like Barr's group indeed found code of "unreasonable quality." I'm just not sure how to put that into proper context. One can always spend more time and money on code analysis and robustness improvements. Did Toyota really fall short of reasonable expectations? It sounds to me like they did, but I'm only hearing one side of the argument.
Did you set the presets by pulling the buttons out, then pushing them back in?
Learn to love Alaska
Elevators use a mechanical safety device that was invented by Elisha Otis in 1854. Prior to that elevators were rightly considered death traps. Take out that mechanical safety device and I wouldn't trust them either.
What if the ECM were implimented as a finite state machine, wouldn't such programming defects be avioded or much easier to detect. Impliment all the low-level stuff as small fast functions and call them from a FSM implimented in software.
It's going to mean that building the control platform for these things is going to have to have MUCH stricter tolerances, and be gone over much more rigorously. And there's going to have to be comprehensive testing of the subsystems, both individually and as a whole.
People's lives are at stake here, and the automakers would do well to be properly paranoid about it.
Look back at Grimshaw v. Ford Motor Co.
Now think of this as "Ford Pinto II".
Chas - The one, the only.
THANK GOD!!!
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).
>> "Anyone wonder what the impact will be on self-driving cars?"
No but as a car enthusiast who enjoys driving I'm praying it will kill the idea stone dead. I can forsee the day when after self-driving cars actually work, it will quickly become illegal for humans to drive at all.
That thing was essentially in replay-mode.
CLI paste? paste.pr0.tips!
I did not see anything the article that proved the driver was not at fault. If the firmware was truly at fault, there should many, verifiable episodes of sudden acceleration. That the driver did not have the situational awareness and common sense to gain control of the vehicle (whether from operator error or software issues) suggests operator error was the probable cause.
You can tear ANY system apart and discover flaws; software is not perfect. A verdict like this simply means a low bar for plaintiffs to get an easy payday.
-- Posted from my parent's basement
put a real computer in the thing
No. A correctly designed and implemented system does not need an excess of power because the amount of computing power necessary is a precisely known quantity.
Safety critical code correctly deals with problems the typical business software programmer has never ever pondered. Recovering from corrupt memory, for example.
The answer isn't a huge CPU and gobs of github best-effort-ware The correct answer is competent design coupled with quality engineering. Hard, expensive work in other words. This actually happens. One can not say it is not possible.
The only real question is; why doesn't it happen at Toyota and other manufacturers? The answer is indifference. The effort is not made, the resources are not spent.
Lack of resources is not the problem. Toyota, for instance, is arguably the largest auto manufacturer on Earth. They certainly have the resources. Whereas NASA was dealing with ~$10e9 annual budgets when they developed STS software, Toyota earned ~$224e9 billion in FY2013. They could to the job right and the cost would be a rounding error.
Hammer them with a big enough judgement and perhaps they'll have the motivation.
Maw! Fire up the karma burner!
Valves stick , actuators fail.
The Kruger Dunning explains most post on
What the GP said is correct. They found potential issues but never proved that any of them ever actually happened or caused the accident.
Your statement that there are millions of other vehicles that don't have these issues is unfounded as well. There almost certainly are potential bugs and defects that could cause an accident out there, but the probability of it happening is so low we don't know about it. In fact we know that some people have found themselves unable to stop their cars in the past due to software issues.
It is impossible to know if complex software is completely fail-safe. You can't test every possible set of inputs and hardware faults for an infinite amount of time. You can be pretty confident and minimize the risk though, which is what they are claiming Toyota failed to do.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
... the GP was concerned about overriding software control.
Brake lines also burst, tires fail, wheels fall off, humans spontaneously combust...
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" :)
Then maybe overly complex computers should be kept away from critical/risky processes that risk human life? Gratuitous automotive electronic control systems, like toyota's electronic throttle, really should not be when a cable works just as well. KISS works best for things like this.
At some point you should be responsible for the things you create.
only to a point, otherwise no one would make much of anything in order to avoid sue-happy vultures. Perhaps a better way to deal with this is a design process that requires justification for complexity. Why use a programmable microcontroller to drive a throttle when a cable works just as well? Is an ECU really necessary at all, or does it just provide a bunch of newfangled featuritis that give toyota management and possibly state bureaucrats the warm and fuzzies?
The old scotty quote applies here: "The more they overdo the plumbing the easier it is to stop up the drain."
You ask point about engineering, but why slam liberal arts majors?
You sound like a self centered ass without the ability to consider other people and motives; which makes for a horrible engineer.
The Kruger Dunning explains most post on
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.
What portion of those are due to faulty software?
GGP said "no procedure to make the software fail was presented" which just isn't true. Multiple links in the summary say they reproduced the fault. Whether that fault is what happened in this exact case is a different matter.
but the probability of it happening is so low we don't know about it
I think that's the point. This problem happened at a high enough rate that we did find out about it. I understand you are trading the features that come with software complexity with the risk that comes with being unable to completely verify the code. When that risk results in a fault that happens a significant, noticeable rate then you have a problem. As you said, when you combine that with poor practices (mentioned in multiple links) you get closer to seeing them as liable.
it doesn't address neoritter's demand for a human fall back
My point was that a simple and extremely reliable mechanism prevents the most likely cause of injury or death. It doesn't rely on software (neoritter's fear) or even a power source.
It does nothing to protect you from out of control elevator computers bouncing you up and down the shaft.
No, but the big red stop button does. It bypasses computer control. It's long been common, and very good, design practice to put in some sort of very simple and reliable override in case the more complex control machinery (not even necessarily a computer) fails.
Hard to know since we don't have 250M autonomous cars on open roads being subjected to the uncertainties of traffic every day. We've only a few taken out on very well planned routes. If Toyota can't get a 'simple' microcontroller programmed correctly, I have no faith in any car manufacturer, any programmers really, in getting something many orders of magnitude more complicated correct. We can't even buy consumer internet routers with firmware that isn't loaded with vulnerabilities and bugs. A crashed router results in the loss of connectivity and can be reset.
Free roaming autonomous machines that correctly interpret the environment do not exist yet. We don't have the sensor technology, microprocessor performance, nor do the AI design for it. Navigating a plane though the sky is easier than navigating (sub)urban streets full of unknowns like kids and pets running around, or an icy patch in the road. The last thing I'd want is a bunch of these roaming the streets, one software bug/bored teenager script kid hack away from mauling someone or their property.
There's a lot more work to be done before these things are set loose on the road.
And such a device could easily be put on a car.
My point is that neoritter's fear of computer controlled cars is more an instinctive reaction to their novelty rather than a rational assessment of their dangers. He doesn't trust cars not controlled by humans because, based on his past experience, cars are supposed to have human operators. He has no problem with elevators no longer having human operators because, based on his past experience, elevators are supposed to be fully automated.
No it's not. People are always ready to trade freedom for safety, and safety for even the whiff of added convenience. That's why we have this hellpit of 'social change' you speak of. Even what you suggest (walling them off) would be a massive undertaking and hardly worth it. Better to just build high speed trains.
People are people. At the end of the day, it's the same political and social group dynamics at play. Who wants control over what, who wants this or that to do something else, etc.. so while you're right that embedded software meant for controlling machines is a lot different from a web search engine, the 'attitude' of the culture prevails. Also, the costs involved in writing bug free code skyrocket very quickly as complexity goes up, so assuming these things are 'ready now' is childish idealism at best. Needless complexity is never a good idea. At best it offers some cutesy features that work sometimes. At worst, it gets in the way at a critical moment and causes serious problems.
The moment the human has to verify everything is the moment the machine is now getting in the way of the process. Just let the human drive then! Give him a satnav and he's ready to go.. Why should everything be a damn 'negotiation?' Computers are supposed to do what they're told, not argue with the user. Google doesn't understand this anymore. They've got the passive aggressive 'concern troll' help style down pat. I would not want this in my car...even as a satnav system, nevermind something that controls the vehicle directly.
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.
The worst they can do with your food/drink order is... also kill you. Recent conversation at a restaurant:
Me: "Do you use a separate oil for cooking your chips?"
Them, cheerily: "No, but our chips are gluten-free!"
Me: "When you cook gluten-free chips in oil that's been used to cook gluten food, the chips aren't gluten-free any more."
Them: *blank look of incomprehension*
While gluten won't kill me outright if I accidentally eat some, consider those who are allergic to things like peanuts or shellfish....
millions of miles? There's more to it than distance traveled. How many of these cars? 6? 12? 20? Let me know when they get it up to a few hundred-thousand in a single urban area, and have run the simulation for a year or so at least. Frankly, though, I wouldn't want to be one of the pedestrian guinea pigs in that study. ..you did read my whole post right? There's a lot more to driving safely than simple reaction time.
if you have any lethal food allergy you should not ever eat restaurant food.
high end restaurants have high pressure environment(and thus error prone)
fast food and diners tend to have a DGAF environment (and thus error prone)
Snowden and Manning are heroes.
Unlike what other technology? Not fire or electricity or television or smartphones or atlatls.
none of those technologies involve free roaming autonomous robots that could decide to maul someone because of faulty hardware or programming. The closest one is fire, and, btw, we still don't have 100% control of that one, and so it is used only in restricted, contained areas for specific tasks and then put out with processes in place to ensure it stays out. The equivalent here is to give the human a steering wheel, throttle, and brake control, and at that point, the human should just drive the damn car.
How do you find out until you let it loose?
With the way people screech about safety these days? You don't. Just because someone managed to figure out how to cook a chicken leg on a little camp fire doesn't mean he should now set the whole forest on fire just to see what happens. You're so ready to demonize human drivers to justify replacing them with something even less adequate? wtf?
No thanks... at least, not yet. Also, there's the political issues over control of the vehicle. These cars will come with remote control and tracking 'features', guaranteed. No thanks to that too.
We have life support systems in hospitals that work pretty well.
A bunch of programmers wrote the code that run those.
Only a couple of "unintended acceleration" issues apparently.
My point wasn't that elevators are completely safe (indeed, several dozen people in the US die every year in elevator accidents). My point is that it never occurs to us that they shouldn't be trusted without a human operator.
Point to a world where consumers hold liability and responsibility for their car, their ECU and their braking behavior even though unintended acceleration is at fault.
http://www.carscoops.com/2013/10/toyota-wins-bellwether-case-on.html
I had a car that didn't have a tape deck and only five buttons for the radio. ...
Ah, but did it have tubes? And a single speaker in the middle of the dash? Was it covered with real chrome?
My car for which you could say yes for all of that also had a transmission with five buttons. Wicked cool for smoke starts.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Every person knows the risks of human drivers, if they don't, well they are naive. between human error, human inattention and human maliciousness. There are two camps, people who think they are the greatest driver to bless the earth and can deal with any situation in the blink of an eye, even if it's caused by some malicious human idiot; and people who realize few people are as special as the first people think they are.
Rocket Surgeon.
There is a point where a real-time OS is a requirement.
You don't need an RTOS. You can have an ASIC do the low level control, and it may be even more precise than a program running on an RTOS could be.
Then the app running on a conventional OS tells the ASIC what to do on a higher level (based on driver etc inputs) - which doesn't have to be done every 1 microsecond. Every millisecond could be good enough. The human driver won't be alternating the throttle from full to off and back every millisecond. Do it right and it doesn't have to be dangerous or a mess, might even work better.
"Computer Tech Analogy": A CRT's electron beam puts dots on the screen at very precise sub microsecond moments, but the display can be controlled just fine by a program in a conventional OS, no need for an RTOS. All you need to do is split the work properly.
Having a program on an RTOS in a CRT control the electron beam might be doable but is probably a bad idea.
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.
Natural != (nontoxic || beneficial)
No, they get a pass because it kills less than DFU errors. ;-)
Sleep your way to a whiter smile...date a dentist!
So one example we've already talked about is the internal data structures within the operating system. They missed it because they never looked at the operating system. They got this operating system in binary from their chip supplier and they never looked inside it to see what was in there.
The implementation of OS they used was not compliant with OS interface specification.
Let me guess - they manually created this condition? Of course they did. It means nothing. If you let me go poke around in electronics to simulate various potential failure modes I'll find a way to make them fail in just about any way they possibly can.
"Your honor, we found that by cutting the ground wire and shorting these two wires we could shock the shit out of the consumer of this product. I move for an immedaite $10bn fine!"
How did they reproduce it, by tampering with the electronics? Yes, that is how they reproduced it. This makes it meaningless.
Vehicle tests where they explicitly created the condition _manually_. It's meaningless. You could hand over the ECU board for _any_ vehicle and someone could find a way to _tamper_ with it to cause acceleration like that. So fucking what? It's not proof.
Real time operation by itself does not preclude a preemptive multitasking operating system. The hardware itself is a larger problem if large amounts of state must be maintained for task switches and memory management. Features like Intel's System Management Mode are particularly crippling.
I though what they meant with killer was something game-changing. Turns out, it is literally a killer.
The fact that NatasRevol (and I) would be happy with less deaths from the driverless cars than what would have been caused by human drivers does not mean there would be no need to improve. It just means we would be happy because there would have been improvement and that a path to further improvement has been opened (you can only lower road deaths to a certain degree as long as there are users in the loop)
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
http://wiki.osdev.org/Context_Switching
It seems context switching from user to kernel space on a 2.8GHz P4 takes 481ns, on a 200MHz P2 it takes about 1335ns.
Switching back takes 330ns and 900ns respectively.
If you've had to switch address space as well, add another few hundred nano seconds.
So you've lost a microsecond just doing context switches.
Your IRQ thats triggered your ignition timing event also has a variable amount of latency to deal with, since you don't know what address space is going to be active when it occurs.
That's just plain ol' x86. It's getting better, slowly. Over a decade the CPU speed went up 14x but the context switching cost only went down 3x.
But then you're not doing OO programming, you're going VHDL/Verilog.
Someone is also going to be writing a driver for your custom ASIC in C as well.
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 not to ground the case at all and just hoping nothing will come loose and short to it.
I guess that "killer app" just got a new meaning.
If you post as an AC, don't expect me to spend a mod point on you.
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-
What if the 'defective' car also dramatically reduces the overall number of road deaths?
Don't the needs of the many outweigh the needs of the one? Even if you're a lawyer? Oh, wait, that requires a heart...
No sig today...
I got my permit at 15 and my license at 16. Some states will even give a license to a 14 year old.
Has anyone bought the "handful of Xanax" option yet? If not, dibs!
Whilst there are many aspects about the film I, Robot that I have problems with, this very issue is covered when the female scientist is scared because Wil Smith decides to take manual control of the car they're in.
The comments about TBW making assembly cheaper are well-founded and accurate, but there's WAY more than just that:
TBW let's you get rid of the idle speed solenoid / idle speed bypass motor, which handles high idle during warmup and anti-stall during big drop throttle. Instead, the ECU can move the throttle plate directly. More control authority, less under/overshoot, more stable idle, less idle fuel consumption - not to mention a savings of between 1 (PWM idle solenoids like Honda) to as many as 6 wires (stepper motor systems like Mitsubishi)
TBW allows you to change the ratio between delta pedal and delta throttle - and do so *dynamically*. You can do this by changing the linkage and cam on a mechanical throttle, but it's a big deal and not easy to tune. With TBW, it's a lookup table or a function. If you have a powerful car with a big throttle body, this can pay HUGE fuel savings and vehicle control dividends at low throttle plate angles, where tiny tiny differences in throttle plate angle make huge differences in airflow.
TBW makes traction control / stability control WAY easier - and it doesn't crackle and bang like spark retard systems do.
And that's just the tip of the iceberg.
Just because you can't imagine the benefits don't mean they aren't there.
Want to learn about race cars? Read my Book
Their are some advantages of having the ECU control the throttle in a modern car. Drive-ability is one of them. It allows the ECU to match engine torque and transmission shift points successfully. And this is a big contributor to fuel economy improvements on gas engine vehicles. It allows you to lug the engine at WOT in a much higher gear on small grades or flat roads and when you press the accelerator pedal further, it will force a down-shift. These are mapped into the ECU and adaptive coefficients are determined by the driver during the first few minutes of driving the car after a battery disconnect.
Someone who can create worlds in a box doesn't really sound too much like a dull weirdo to me... especially if they let me play around in their world.
Yes, they reproduced it using their debugger to flip a bit in memory that killed a critical task. Their argument was that it could randomly get flipped in a real car due to electrical noise, cosmic rays or faulty RAM, but they never actually reproduced such a random failure. They only ever simulated what would happen in that extremely unlikely event.
The rate at which the problem happened is unknown since other factors were not ruled out. In particular the fact that the carpet could cause the accelerator pedal to stick is a prime suspect. In the specific case that this lawsuit was about telemetry showed that the driver didn't press the brake pedal at all, despite saying he did, while the accelerator was pressed. That implies that the most likely explanation is that he pressed the accelerator by mistake, thinking it was the brake. Of course, the telemetry could be wrong, but the chances of both these unlikely events (ECU failure and black box failure) are extremely low.
The jury members said they wanted to punish Toyota. I don't think the judgement has anything at all to do with the likely cause of the accident. NASA said the ECU code was fine, these guys claim it was sloppy but couldn't even read the comments because they were in Japanese. They say that the function names and variables were in English, but if you have ever looked at Japanese code you would know that it's more like a Japanese dialect of English were some words have subtly different meanings.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
In this case, she was justified as in that era people didn't drive, esp. in high traffic at speed. This is like putting a 15yo in dense interstate traffic. (if you've ever taught anyone to drive, you would shudder at the thought)
Except there are no "professional (software) engineers" -- there's no PE process for programmers.
A PE would not put his (or her) seal on something they do not approve of. If the manager is the ass pushing an unsafe design, then he can put his seal (and professional career) on the line. Note: a PE can be held criminally liable for his errors.
It is about bloody time that a software developer is held accountable for delivering dangerous buggy firmware. As a purchaser, I have often been frustrated by how this industry has conditioned us to believe that this is normal and must be accepted. Indeed we are usually expected to subscribe to a continuing service to update delivered software for bug fixes. Can you imagine this happening with any kind of hardware delivery. Professionals in the motor vehicle must deliver a product quality that is consistent with the standards of that industry - even if it is software.
Heavy is the head that wears the tinfoil hat.
Unless it is disabled which may not be possible on some hardware, system management mode can easily generate at least 2 orders of magnitude more latency with a low end starting at just 100us. Even without system management mode, poorly written drivers can cause havoc.
When I had to deal with trying to use desktop hardware in real time applications, I qualified it with a simple test routine which toggled a visible I/O pin in response to an interrupt and measured the latency externally on an oscilloscope. The visual histograms were very informative. System management mode was a killer but access to I/O devices like mass storage or networking was often as bad.
I look forward to doing the same test on embedded ARM hardware running Linux or BSD in the near future but I suspect my final solution will be to continue using custom programming on low end embedded controllers for local real time tasks. At least with ARM there is the possibility of having to deal with multiple processors and only one instruction set.
Go back to the 8051. It won't let you down.
Like you, I'm not sure which safety mechanism Stormy thinks we'll install on a car but if they are referring to the big red button...
A big red stop button should work just fine for all those systems. One of the neat side effects of the new electric power steering systems is that they can turn themselves without your help at all and do it with great precision so it makes for easy self-steering. There is however still an actual linkage between the rack and steering wheel. The ABS pump is also completely automatic but there is still a standard vacuum master cylinder with a real connection to the pedal. If you were to cut power to those 2 items then they will shutdown along with the engine when the E-Stop is pressed and you will retain a very rudimentary level of control of the vehicle. Just like today should your engine shutdown while in motion. Now eventually we will eliminate those hard links and go true drive by wire but going by previous vehicle evolution, there is no reason to suspect first gen self drivers to have those backups eliminated. If they did that, whether rational or irrational, fear would dissuade adoption.
if Toyota managed to cock up their software so badly...how bad is the code of other manufacturers?
Never let a lack of data get in the way of a good rant.
For whatever reason the one of the original links was no longer available when I revisited one of the links in the OP today:
http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
But Google Cache still has a copy...
http://webcache.googleusercontent.com/search?q=cache:http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
Again, something that "could" happen. Meaningless.
You're a stupid asshole....sorry, the far likelier is NOT people hitting the wrong pedal, floor mats or that BS.
I have a first generation Prius, which is not even included in such cases. But I had an unintended acceleration. It happened when I lifted my foot OFF the pedal. And you know what, it felt exactly likely when the cruise control kicks in to accelerate up a hill. And I do believe that was what was involved.
But shit for brains folks like you who just simply assume humor error. At like the fucking morons who wrote up the crash report blaming the F-22 crash on pilot error for not keeping his plane in the air when it ran out of oxygen.
YES, a few people likely did something dumb like that. But hey, let's look at statistics. That would happen with any car, and many many cars have much closer together pedals. No, something technical was going on here.
***
"They eventually "fixed" the problem by moving the brake and accelerator pedals further apart, and putting in a brake-gearshift interlock"
And let me point out, that it was also a significant change, and therefore would have had a different firmware for the electronics control module as well. All your statement proved is that they added some extra measures on the next version. But that the next version was modified, and thus the issue eliminated. There is no proof which resulted in the fix, the pedal change vs the electronics update.
Remember, if you're in a car and its accelerating, breaks aren't working....
1. STAY CALM
2. SHIFT THE VEHICLE INTO NEUTRAL
3. BRAKE or COAST VEHICLE TO A STOP
****
Seriously when you hear the 911 calls about these sort of things, you wonder why every 911 operator is not trained to simply say "Please shift your vehicle into NEUTRAL"
I always hated the 8051 series but would have used an embedded x86 if available.
I have been using PIC in this application for years but am looking to switch to bare metal ARM so I will have a unified instruction set from the bottom to top. One disadvantage in some cases though is that most or all of the lowest end ARM embedded processors draw a lot more power.
I mentioned 8051 because it's simple and fast to switch context, you just change memory banks. You can do the same thing in 8 bit PIC's, they usually have 2 or 4 banks.