Slashdot Mirror
Stack Overflow Could Explain Toyota Vehicles' Unintended Acceleration
New submitter robertchin writes "Michael Barr recently testified in the Bookout v. Toyota Motor Corp lawsuit that the likely cause of unintentional acceleration in the Toyota Camry may have been caused by a stack overflow. Due to recursion overwriting critical data past the end of the stack and into the real time operating system memory area, the throttle was left in an open state and the process that controlled the throttle was terminated. How can users protect themselves from sometimes life endangering software bugs?"
Is there anything Stackoverflow can't do?
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
..."We'll I'm sure somebody on there could!"
.
Prisencolinensinainciusol. Ol Rait!
"How can users protect themselves from sometimes life endangering software bugs?"
Amish buggies typically don't have software throttle failures. Run-away horses can be an issue.... and actually having to share the road with dipshit drivers who don't understand the number of slow moving vehicles (not just buggies) that there are out in farm country are a real danger.
Seriously, software has bugs. Mecanical throttle linkages can stick, too. Life has risks.
How would a mandatory publication of all code as open source [not suggesting liberal licensing here] work out here? Might converge at a collaborative initiative and will most likely be reviewed by all sort of people.
Support Eachother, Copy Dutch Property!
No software. No seat belts. No automatic..anything.
Idiot drivers hit the gas pedal instead of the brake and instead of owning up to their incompetence as a drivers, they blame the car instead. The Toyota sudden acceleration problem disproportionately affects the elderly and inexperienced drivers. It also a uniquely an American problem and it occurred during a deep recession where GM and Chrysler were going bankrupt and Americans needed some FUD against Toyota because supporting American car companies was the jingoism of the day. The toyota sudden acceleration is more of a case study of an American moral panic and mass hysteria perpetrated by the media than it was an engineering problem.
Suddenly Toyota lawyers sued this website http://stackoverflow.com/ and claimed they are victims too.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Honestly, not much, except perhaps demand better software. Better processes, better languages. I'm just hypothesizing here but it might not have happened if they had e.g. followed better development standards like the MISRA C standard, or don't use C at all, use Ada or something. Better QA processes might have caught it before it went into production, e.g. using a dynamic stack profiling tool, input fuzzing, whatever. Fundamentally a system like this should have an independant hardware watchdog timer to at least try and make it fail-safe in the event of a CPU crash. Finally any motor vehicle ought to have a manual cutoff switch wired into the fuel pump or ignition circuit so that when the CPU shits it's bits you can still turn the damn thing off before you crash crash.
-73, de n1ywb
www.n1ywb.com
"We've demonstrated how as little as a single bit flip can cause the driver to lose control of the engine speed in real cars due to software malfunction that is not reliably detected by any fail-safe," Michael Barr, CTO and co-founder of Barr Group, told us in an exclusive interview. Barr served as an expert witness in this case
Emphasis mine.
Yes, a single bit flip can cause unpredictable behavior in any code. You could say that without any analysis. A single mistake in sign can get you a goose egg in the Algebra paper. So many people could have won the lottery if only one digit was different. These are well known. But can != did. Did that stack overflow? Did it actually happen? That is the question.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Quite simply the absolute control should not be handed over to the computer. Basically doing something like pulling on the handbrake should basically physically cut the throttle. Or stomping on the brakes should activate a simple solenoid that cuts the throttle. This mechanism should be 100% separate from the computer and override most computer outputs.
I see this as critical in a driverless car. There needs to be a way for people to pull the plug and there needs to be a way for people to phone in an emergency. So if someone is lying in a pothole being run over by car after car, or the bridge is failing, there needs to be a way for 911 to say that a stretch of road is now cut off. The key is that this cannot be ab abusable by officials. I do not want my car grinding to a halt because the police are looking for some runaway or a bank was robbed.
Not using recursion in constrained embedded systems is a good start. It's been best practice since I started working with them 15 years ago.
Recursion is fine if recursion is fine if recursion is fine if recursion is fine if recursion is fine if you do it right.
Seven puppies were harmed during the making of this post.
The death penalty for programmers that write such code will bring an end to software !
FTFY
... you know... i worked for pi technology in milton, cambridge, in 1993. they're a good company. they write automotive control systems, engine control management software, vehicle monitoring software and diagnosis systems and so on. one of the things i learned was that coding standards for mission-critical systems such as engine control have to be very very specific and very very strict. the core rules were simple:
1) absolutely no recursion. it could lead to stack overflows.
2) absolutely no local variables. it could lead to stack overflows.
3) absolutely no use of of malloc or free. it could lead to stack overflows.
now you're telling me that there are actually car manufacturers that cannot be bothered to follow even the simplest and most obvious of safety rules for development of mission-critical software, on which peoples' lives depend? that's so basic that to not adhere to those blindingly-obvious rules sounds very much like criminal negligence.
I have just finished my patent application for the steering wheel mounted Ctrl, Alt, Delete button combination...
Problem solved!**
**Some users may experience complete lack of vehicle control while the system is rebooting.
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
For anyone else that's curious; at first I thought it was double speak, so not to sound as bad.
Stack overflow refers specifically to the case when the execution stack grows beyond the memory that is reserved for it. For example, if you call a function which recursively calls itself without termination, you will cause a stack overflow as each function call creates a new stack frame and the stack will eventually consume more memory than is reserved for it.
Buffer overflow refers to any case in which a program writes beyond the end of the memory allocated for any buffer (including on the heap, not just on the stack). For example, if you write past the end of an array allocated from the heap, you've caused a buffer overflow.
http://stackoverflow.com/quest...
First rule of real time: No recursion.
I've known a lot of high-quality developers over my 15 years of professionally developing software. The reason I don't want an automated car is because of these people. People make mistakes, intentionally or otherwise. There are unforeseen circumstances that the software may not understand. A foreseen circumstance: I've yet to see a demo of an automated car navigating anything resembling an icy surface (safely or otherwise), let alone in stop & go traffic in a city such as Chicago, where such things are quite common.
Yeah, but we know today who pays: the insurance company of the at-fault driver (provided they have the legally required insurance - I think collision is required in all US states). Failing that, the at-fault driver. Failing that, the dead at-fault driver's estate.
The question at hand is, in the case of an automated car, who is at fault (when the automated car is deemed to have caused the accident)? The manufacturer, because, it must have been a design/implementation flaw? The owner? The driver (because owner/driver aren't necessarily the same)? It becomes more difficult when you divest yourself from current paradigms of car transport. Oh, I sent my 6 year old daughter to school as a passenger, and along the way it ran over someone. There was no driver (the daughter was a passenger), but the car still killed someone. Am I at fault because I ordered the car to make the trip? Is the manufacturer at fault because the car didn't detect and prevent the collision that killed the other party? Is my 6 year old daughter at fault, because she was the only human occupant? This is the question that is being posed.
Even easier is to just TURN IT OFF using the key and get on the breaks. Trust me, the car WILL stop running and come to a full stop fairly quick.
Not if it's a diesel engine.
Yes, people do make mistakes. Often while driving. The test shouldn't be whether automated cars make mistakes, but rather whether they do better than an average driver. Can they deal with icy roads as well as an average driver? That bar's pretty low, even here in Edmonton.
Once they've reached that average competence and start being deployed, they'll also improve rapidly over time; computers have the potential to be much safer drivers than humans. They'd know where other cars are and where they're going, they'd be able to apply brakes to wheels independently with lightning reactions, and would not be subject to health conditions, intoxication, aging, or inexperience.
I'm not sure how far off we are, but it's definitely coming.
Let's not stir that bag of worms...
From the slides:
"Toyota used dangerous recursion"
Not like that safe recursion that other vendors use.
I've known a lot of high-quality developers over my 15 years of professionally developing software. The reason I don't want an automated car is because of these people. People make mistakes, intentionally or otherwise.
When it comes to true high-rel software, like that written to DO-178B Level A (an avionics software standard used for things like fly-by-wire) it's almost never the software per se that's at fault. The stuff is amazingly good. It's also amazingly expensive to write and test. You might also find it frustrating because it brings new meaning to the idea of conservative design. For example, I don't think it allows recursion. I know it doesn't allow dynamic allocation.
There are unforeseen circumstances that the software may not understand.
That's more the point. When things like fly-by-wire systems have problems, it's almost never the software itself, but something that was unforeseen by the system designers.
A foreseen circumstance: I've yet to see a demo of an automated car navigating anything resembling an icy surface (safely or otherwise), let alone in stop & go traffic in a city such as Chicago, where such things are quite common.
Agreed. This technology is interesting, but it's way over-hyped. It's impressive to be able to drive on a nice clear day, but a far cry from the real world, even in Silicon Valley, let alone Chicago.
Ever hear of the flying cars that in the 1960's they said we'd all have soon? I haven't seen any lately. I suspect driverless cars robust enough not to require human intervention when the going gets tough may be developed on the same schedule.
I had my car suddenly accelerate on me before. I was driving along and suddenly the pedal felt really strange and it start accelerating, even when I took my foot off the pedal. I turned off the car and pulled over. Turns out the rubber mat I put in to protect the inside of my car from wet/snow had somehow managed to flop on top of the pedal and pushed it down. When I heard about these Toyotas accelerating on their own, it's the first thing I thought of.
During the trial, embedded systems experts who reviewed Toyota's electronic throttle source code testified that they found Toyota's source code defective, and that it contains bugs -- including bugs that can cause unintended acceleration.
I'm currently weighing your hunch against the industry experts who reviewed the source code, identified specific flaws in detail in an 800+ page report, and testified to their findings, presumably under oath. I'm on the fence here, it's a tough call. I'll let you know what I decide.
Although I'll admit I get the feeling that there is some kind of conspiracy going on here, probably related to an Obama Muslim invasion. I mean, what are the odds that the "several hundred [people] contending that Toyota's vehicles inadvertently accelerated" all happened to be fans of Toyota's with the same electronic throttle control system?
Ok. it's very real. happened to my father-in-law several times before any news broke of this. so claiming it's the driver is pointless waste of time. now you can actually suggest something helpful.
"They said I probly shouldn't fly with just one eye," "I am Bender. Please insert girder."
Did they also discover a flaw in the brakes such that they could not overcome the engine power? This was the point of the parent post, I think. Modern cars have sufficient braking force to completely stop the engine even at full throttle. So if the driver is "stepping on the brake really hard," the car should stop in spite of a stuck throttle, unless a simultaneous brake system failure can be demonstrated.
This same thing happened to Audi in the 1980s and as far as anyone can tell, objectively, it was at most a flaw in pedal placement that made the driver more likely to mistake the gas pedal for the brake while stomping something down to the firewall. They solved it by moving the pedals a little.
You cannot really go by the driver's self-reported experience alone, when the concern is that the driver may be confused. They may have an extremely firm belief about what happened, and that belief may be mistaken.
Are you sure? Diesels have electronic controls these days. Even before that, how did you shut them off normally?
MISRA C, which is a mandatory coding standard across pretty much all the automotive industry, does outlaw recursion. So I find this speculation on the cause to be very unlikely, and is just lawyers bringing in "software experts" to speculate. If you want to speculate, there are many other potential software bug causes as well. Some of them would even pass MISRA C coding checks, and not be easily detectable by static analysis.
I think it was actually two problems. There was the problem reported by Wozniak, where cruise control would start to accelerate, but tapping on the brakes would fix the problem. It was a bug, but it wasn't life-threatening at all.
Then there is the problem of the car going wildly out of control, unable to stop even when the brakes are applied. That one seems to be a case of foolish driver syndrome.
"First they came for the slanderers and i said nothing."
he was sitting at a stop sign waiting for a train to pass when the car inexplicably accelerates and lurched forward.
Why did he take his foot off the brake?
"First they came for the slanderers and i said nothing."
Many of these uncontrolled acceleration cases involved hybrid Toyota vehicles. In addition to the electronic throttle, Toyota's Hybrid Synergy Drive uses brake by wire, so the computer can dynamically use any desired combination of regenerative and friction braking, based on the hybrid battery charge state and the severity of the driver's control input on the pedal. These cars also eschew mechanical control for the gear-shift and the push-button ignition switch, relying on interface through the ECU.
It thus seems entirely plausible that a stack overflow, race condition or other crash/freeze/whatever could result in a wide-open throttle with no brakes and no gear-shift or ignition off control. if this is the case, it represents a epic lack of fail-safe design. It certainly doesn't help prevent operator error when Toyota uses a non-PRNDL shift pattern on their hybrids, to say nothing of the lack of industry standardization of the behavior of push-button ignition.
Almost all safety systems in Ontario have not been designed or written by a PEO licensed engineer. The PEO is the same organization that tried to get Microsoft to stop using the term "Microsoft Certified Systems Engineer (MCSE)" and largely lost. If you start analyzing real and deployed systems, you will be shocked at what you find.
Yes, there are a few very well designed machines out there that do hardware and software interlocks properly, and in an obviously safe fashion. These are the exception, and I am delighted to find the few exceptions that exist.
However, if you want excellent examples of obviously unsafe things, consider:
- The gas pumps at Shell, Esso, and Petro-Canada. How many brands have an Emergency Stop button? One?
- Toyota cars have a push to start button that is also a push and hold to stop button. So how do you stop the car quickly? Shouldn't a car that has push-button start, also have a push-button stop, that is a different button and works quickly? Why would Toyota follow the Microsoft standard of using a start button to stop, instead of following the very well thought out emergency stop button standards?
- Hospitals have implemented a number of computer systems that are networked, and make the job of nurses quicker, easier and more productive. This reduced nursing costs considerably, and fewer nurses are looking after more patients. However, these systems are not reliable, and the official backup plan is that a nurse will step in and do the job manually if the system fails. Unfortunately, many of these core systems are also running on Microsoft Windows (often Windows XP.) One virus, or one bad update, written by a non-engineer, to wipe out many core systems. A major hospital had its Internet linked systems disrupted because too many people watched Olympic hockey (over the critical internal network.) Has any engineer approved any of this? Does any hospital have enough nurses to cover off in the event of a computer failure?
- Most servo-motor drives are sold with a "not recommended that power be cut by an emergency stop/safety system" warning buried somewhere in the documentation. Ignoring this, and assume braking resistors are used, and power is really cut. Most motors will follow an exponential stopping curve, and appear to coast to a stop. A mechanical engineer doing a PSHSR (Pre-Start Health and Safety Review) will expect the machine to stop quickly, and not coast. The cheapest way to do that is to dynamically brake into braking resistor under full software and transistor control. The second cheapest way is to use a parking brake, but those are not rated for safety and only a fraction of the servo-motor market uses parking brakes anyway. How many PEO licensed mechanical engineers doing PSHSR reviews have passed systems with incorrect software E-STOP circuits and Safety Circuits, and failed E-STOP circuits and Safety Circuits that cut power to the motors in hardware?
Do not depend on the PEO and statutes to keep you safe ...
They didn't speculate. They analysed the source code, which they had clean-room access to, as well as the actual compiler and test harness used by Toyota. Toyota testified that the stack utilisation was 41%, whereas the analysis showed that it was actually 97% *before* the recursion was taken into account. It looks pretty certain that stack overflow could occur. Following the stack are key system structures used to control the scheduling of threads on the CPU, and damage to these structures could cause one or more of the threads to never get any scheduled time. One of the threaded tasks not only controls the throttle, but also the failsafes in case of some scenarios,and also the code that writes fault codes to the battery-backed RAM. Basically, if that task dies, then the throttle is left uncontrolled, the failsafes don't kick in, and no fault codes are written so that the problem is revealed after the fact. It's a terrible design; a disaster waiting to happen.
Uses can protect themselves against this sort of thing by not buying a Toyota until they are compliant with the relevant standards. Only hurting them in the marketplace will get them to fix this problem.
The testimony from both expert witnesses Barr and Koopman are now a matter of the public record and actually make fascinating reading - they'll be especially interesting to computer guys because it goes into a lot of detail about the code design, though frequently translated for the benefit of the court into layman's language. It's going to go down in history I reckon as a classic case of how not to design a safety-critical system.
A great summary and links to the public court documents can be found here: http://www.safetyresearch.net/2013/11/07/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/
Anyone who knows anything about coding, or just has an interest in this case can read a great summary here: http://www.safetyresearch.net/2013/11/07/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/ which also has links to the testimony of the expert witnesses to the court.
The testimony makes fascinating reading, and is based on analysis of the actual source code in clean-room conditions. If after reading it you still think this isn't a software problem, maybe you need to turn in your geek badge right now.
One problem caused by this fault is that if the throttle gets stuck in the open position (the exact amount is redacted from the public record, but it looks to be >30%), then the vacuum assist to the brakes is greatly reduced (after all, normally the throttle closes when you move your foot to the brake pedal, so you get full vacuum assist). The upshot is that the driver would need to apply far more pedal pressure than they're used to to get full braking - combined with the fact that the engine is pulling hard it will feel like the brakes have simultaneously failed. Turning off the ignition might help with the acceleration, but not with replenishing the vacuum assistance.
There is a lot more to this than simple driver error. Read the court testimony, it's a real eye-opener and in fact a really great read: http://www.safetyresearch.net/2013/11/07/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/
but the brake pedal is also just a switch. if the computer is malfunctioning, that can explain the lack of any brake application too.
Wealth is the gift that keeps on giving.
Well, one of the interesting features, IIRC, was that no mapping was done by the AI, it drove strictly "by the seat of its pants", and had no trouble performing precisely controlled power-slides that would make most drivers shit their pants. If we're discussing the challenges of driving on ice I think that's very relevant. I don't remember if it had any specific moving-obstacle-avoidance code, but plenty of other projects are tackling that. Conceptually at least it shouldn't be difficult to combine one AI that says "go there" and "that apparently small obstacle has this much larger 'potential collision volume' ", etc. with a second AI that can put that car wherever it wants to regardless of the road conditions. I mean if the thing can flawlessly powerslide an indycar through a rainy slalom course I really doubt its little brother is going to have any trouble with maneuvering a normal car in bad weather.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I know that sometimes its difficult to admit that someone you know well may have made such a stupid mistake, but the probability of your father-in-law being confused/mistaken is a lot more than entire teams of engineers at the world's largest car manufacturer fucking up in such a dangerous manner.
Wealth is the gift that keeps on giving.
In what car?! All modern mainstream vehicles still use a master cylinder in tandem with a booster and ABS. Even if you lose all engine power, should still be able to apply the brakes. Although it will require more force to push the pedal down, it should still be doable to bring the car to a complete safe stop.
Life is not for the lazy.
The brakes are never adequate to overcome the power of open throttle. NEVER. One is expected to stop pressing the throttle when applying the brakes, that's why one is taught to use one foot for both functions, so that one does not push both pedals at the same time.
Braking subjects lots of parts to massive thermal changes. Those changes significantly reduce the effectiveness of the brakes after only a small amount of use. That's why race cars and other performance vehicles that are expected to have *ahem* spirited driving have much more expensive brake components, that fade less.
Lastly, look at burnout competitions. In those, someone spins their tires for as long as possible, generating smoke and noise, usually either the longest-burning or the crowd favorite wins. Unless a car has been modified to allow only the non-drive wheels to apply brakes, then the same brakes holding the car still (from a standing stop position mind you, not starting out in-motion) are easily overcame by the drivetrain. Yes, the drive wheels spinning in a burnout competition have their brakes applied and it doesn't do a thing to stop the wheels. Sometimes even the non-drive-wheel brakes are overcome in a burnout competition, and the car crashes into something.
My daily driver is a '95 Impala SS. 260hp, 330lbft torque. Tires are 255mm wide, about 10 inches, and are "W" rated, meaning that they're high-performance for grip and are capable of handling extremely high-speed rotation. On smooth, dry pavement or asphalt it's very hard to do a burnout, the car simply overcomes the brakes and takes off, and that's with probably 75% of the braking force on the front, non-drive wheels. A modern FWD car puts all of its torque into the wheels that would normally do the lion's share of the braking, so once they're overcome, the rear wheels aren't going to do squat to stop the car.
This error is VERY dangerous. The ignition key should ALWAYS overcome the throttle. The brakes should ALWAYS overcome the throttle. The gear shifter should ALWAYS overcome the throttle. Hell, even the four-way hazards should trip the computer into resetting the throttle algorithm.
Do not look into laser with remaining eye.
Because its very easy to overflow the stack? Embedded systems tend to have a limited stack space too.
I tried to, but didn't find a single source to support your claim. Would you be kind enough to point it out?
Technically knowledgeable people often give very poor names to their efforts.
I thought "Stack Overflow" was great branding for a website aimed at helping programmers solve technical problems. It's a distinctive, cheeky in-reference understood by its intended audience. (And honestly, it didn't hurt that most developers enjoy being made to feel clever about themselves.) That's what a brand is suppose to do, and it partially* explains their overwhelming success. And hey, much better branding choice than ExpertSexChange.com!
*Of course, branding is just one of many things they did right. They also filled a unique niche, understood their community (because it was started by programmers, for programmers), and made the site super-easy to use by (here comes the important part...) NOT crapping over the UI with a fake paywall that sought rent for years' worth good-faith user contributions. However, they are sort of starting to be dicks about subjective questions (such as help with API choices, etc.). That may provide a niche for a new competitor to fill...
-1, Too Many Layers Of Abstraction
I even found some information for you:
http://www.caranddriver.com/fe...
A 268 horsepower Toyota Camery can stop from 70mpg in 190 feet with the engine at full throttle. Only 16 feet longer than not throttle. At 100mph the stopping different was 88 feet.
When they tested a full throttle stop from 120mph, the car slowed to 10mph before the brakes overheated.
Perhaps you should put your foot harder on your brake pedal.
You are american though, so your Impala is probably an automatic. In first gear with the torque converter multiplying the torque it may be able to slowly move the brakes when they're fully applied.
Well, if it was in article comments on the Internet, that's a whole new story... ;)
No one sells a car in the US with exclusive brake-by-wire, because nearly every state mandates the existence of a second braking system independent of the primary braking system. That's often the thing people call the "emergency brake," as compared to the "service brake." For IL, look at Article III at http://www.ilga.gov/legislatio.... They must be separated such that a failure in any one part does not leave the vehicle without brakes. IL also prescribes a maximum stopping distance from a couple of speeds.
Weird. The stock brakes on both the '95 Caprice and '96 Impala SS sitting in my driveway can hold the car in place. That was true when the engine was stock, and is still true after adding a shift kit, PCM tune, cat-back, intake, and valve train upgrades. It's been true on both the factory tires and the substantially wider aftermarket tires. It might be time for you to replace your brake material; you're seemingly endangering the other cars on the road.
When you're trying to power brake, BTW, you'll want to let up on the brakes just a little, and mash the gas. Don't ease in to it. ;)
Use java
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Did they also discover a flaw in the brakes such that they could not overcome the engine power? This was the point of the parent post, I think. Modern cars have sufficient braking force to completely stop the engine even at full throttle
Is this definitely always the case? Under all conditions? There's a huge difference, for example, between holding down the brake while stopped and gunning the engine and slamming on the brake while already travelling 70 miles an hour with the engine similarly gunning. Static vs Dynamic friction for one thing. Not to mention brake exhaustion due to overheating. The pads and rotors heat up and the physical properties of both change, the rotors can warp, moisture can flash into steam and create a nearly frictionless layer, the properties of the brake fluid change, making it less efficient as a hydraulic fluid or possibly even vaporize. Coming to a dead stop once is probably not enough to do that, but if the accelerator goes crazy on the highway, people aren't going to suddenly stop. They will use the brakes to slow down, heating them up while they try to figure out what to actually do, where to pull over, etc. The brakes can heat up very quickly doing that.
Mission critical systems usually have a set of voting computers. Today electronics is cheap and the technology is not new. Maybe inertia prevents them of building something better. Very common in the automobile industry.
In what car?! All modern mainstream vehicles still use a master cylinder in tandem with a booster and ABS. Even if you lose all engine power, should still be able to apply the brakes. Although it will require more force to push the pedal down, it should still be doable to bring the car to a complete safe stop.
If only the throttle was also required to have a physical linkage!
Unfortunately, once we abandoned the carburetor, there isn't much to link the throttle pedal to any more, and we are stuck with using it pretty like as a mouse. A physical pedal up fuel valve to reduce fuel availability to a level sufficient only to idle the engine might return some measure of physical control. Currently most manufacturers have the computer cut throttle when the brake is pressed, even if the gas is also pressed. (Toyota did not have this during their problem years and added it later). This has the side effect of teaching those idiots who drive an automatic with the left foot riding the brake not to do so. Unfortunately, this functionality is programmed into the same computer, (saving $37), and if that computer has entered stack overflow, it won't help.
But the interesting thing here is that Barr found a situation that (he claims) could in fact cause the engine to receive full throttle, when DOT and NASA could find no such problem and blamed it all on the driver confusing the pedals.
Even if the brakes would have stopped the car (eventually), after applying them fairly firmly for a while (for some values of "while") the car can experience rather sever brake fade. Anyone driving in the mountains has probably experienced this.
Without brake fade, Car and Driver found that from 100mph and up, the braking distance increased three fold, enough to convince the driver that the car was never going to stop. If this occurred after a long downhill, (hot brakes and plenty of fade) and the driver wasn't fully committed to hard panic braking, it seems plausible that a stuck accelerator pedal, or stack overflow, or floor mats, could extend braking distances enough to be deadly. When tested afterwards, the brakes would have appeared to be working again.
If you disallow all of these possibilities you are forced to assume that anyone reporting any unintended acceleration is a total idiot, which, given small the number of events, isn't completely out of the question, but the fact that almost all of these idiots tend to be driving a Toyota is suspicious.
After all, idiocy does not usually manifest itself by a predilection toward a certain brand of car.
Sig Battery depleted. Reverting to safe mode.
It depends on if the ABS and/or brake servo is influenced by the bug and makes it harder to apply the brakes.
Be aware that most brake servos are using the manifold vacuum to increase the brake force. If the engine gets full throttle the vacuum is soon depleted and a much larger force on the pedal is needed which will be experienced as failing brakes.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Actually, the best analysis of the situation I have seen came from someone who had investigated a similar problem that was reported for cars with purely mechanical acceleration linkages some years back. They had studied that situation and discovered that overwhelming majority of those experiencing the problem were in a particular age range (I forget now if that age range was 55-65, or somewhat older). Further analysis revealed that most people go through a kinesthesia change during that period (kinesthesia is the awareness of where a body part is based on the sensations you are receiving from it). When going through that change, people often believe that their feet are positioned a few inches from where they actually are. As a result, drivers in this age range are likely to be positive that their foot is on the brake when it is actually on the accelerator. The interesting thing is that once the person becomes used to the change, they are perfectly capable of being aware of where their foot is once more. The person who did that original analysis analyzed the Toyota data and found that the majority of reported cases involved drivers who were in the same age range. When he took out those data points which looked suspicious as to being part of this actual problem(drivers who looked to be cashing in on the publicity of this, either for money or to explain away their own bad behavior, accidents where no one in the vehicle survived, but this was used to explain irrational behavior on the part of the driver, etc) the overwhelming majority of cases were in this age range and most of the remaining were inexperienced drivers.
The truth is that all men having power ought to be mistrusted. James Madison
A Prius does not. More than half the brake power is supplied by regenerative breaking, and if the register for throttle position is at 100, regenerative braking never kicks in, leaving you with the relatively whimpy disc brakes. A prius crash near me last year had the brake pads worn away and smoking when the police arrived.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Division by zero results in positive or negative infinity, depending upon the sign of the numerator.
False. Division by zero is simply undefined. Sometimes you can determine the limit of some function as it approaches a discontinuity due to division by zero, but the limit will depend on the function (not just the numerator) and possibly on which side you approach the discontinuity from. For example, the function x/x has a discontinuity at x=0, but the limit isn't infinity, it's 1. The function 1/x approaches positive infinity as x goes to zero from the right, and negative infinity as x goes to zero from the left; since these are not equal, the limit does not exist at x=0. On the other hand, the limit of 1/(x*x) at x=0 is in fact positive infinity, because the function approaches positive infinity from both sides.
If X divided by zero were actually defined to be "equal to" positive infinity for all X > 0, then you could turn that equation around and say that 0 * infinity = X. Since 1/0 = infinity, 0 * infinity = 1. And 2/0 = infinity, so 0 * infinity = 2. Ergo 1 = 2. (Or not...)
The problem is that infinity isn't a number you can calculate with; it's more of a trend, or a way to express the absence of a finite boundary. An expression is never "equal to" infinity, though it may approach infinity as some other condition changes.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Driver error. When you're stopped you're supposed to keep the brake down (and the wheels straight). The usual reason is in case someone rear ends you. My car even helps out: if you press the brake all the way down it holds it on until you release it completely.
Sure, most people like to do the creeping forward thing. Most people are poor drivers.
I had a Citroen 2CV that did that. Luckily, it was so slow that I could jump out and run ahead and warn people to get out of the way.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."