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/
Problem solved.
..."We'll I'm sure somebody on there could!"
.
Prisencolinensinainciusol. Ol Rait!
How in the world can the StackExchange formun StackOverflow be responsible for such anomolous acceleration events? I mean praise reddit or IRC alternatives to stackoverflow.com all you want, but tone down the rhetoric willya? Sheesh.
"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!
One way would be to insist that automakers do not nickel and dime design vehicles. The critical components related to vehicle safety should be designed for safety first, cost second.
These vehicles go for over $20 000, I should at least have the option to pay an extra $1000 to chuck the electronic crap.
i thought this post was going to be about the website lol
At least in this case switch the car into that little N looking thing on their shifter. Sadly a good portion of the population does not know what that N means.
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.
I mean.. lesson well learned. I will test the throttle now. Ah crap that's right I was fired. Must not do that in the next automotive company, Saturn beware I made buyers be weary of the Toyota Brand. (Glad Lexus drivers have more common sense)
The death penalty for programmers that write such code will bring an end to this OUTRAGE !
There is no such thing as unintended acceleration. All cases have been unrepeatable or shown to be human error.
The Toyota stuff was a bunch of crap that got whipped in to a media frenzy then a bunch of people tried to cash in on it.
The slightly longer answer is, if something like that ever happens, turn off the car and press the brake pedal firmly.
Suddenly Toyota lawyers sued this website http://stackoverflow.com/ and claimed they are victims too.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
if you cant demonstrate it in lab conditions it is just awlawyer speculating about stuff "M'lud I postulate it was the alien space bats wot dun it"
A stack overflow could cause uncontrollable acceleration. The car also could be hit by a meteor. You could be mauled by a bear when you press the accelerator. The engine could catch on fire. Small invisible aliens could hold down the accelerator. The wavefunction of the car could tunnel to a position high above the ground.
I'm no law-talking guy, but I guess "conceivable occurrence allowed by the laws of physics" is pretty much the same level of proof as "preponderance of evidence". Anyway, check, please!
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.
Recursion is lazy, stupid, and above all, DANGEROUS.
Whomever thought recursion was a good idea ought to be taken out back and given a thorough beating.
How can users protect themselves from sometimes life endangering software bugs?
Drive older non digital cars. Come to think of it I can get you a great deal on a factory standard model 1971 Ford Pinto.
Only to idiots, are orders laws.
-- Henning von Tresckow
What's your point? People are killed everyday by cars operated by people (others, or even themselves). I'll take my chances with the computer, thank you
Most of the people who claimed 'sudden' acceleration said it happened while they applied the brake. And I don't care how crazy your engine goes, the brakes wouldn't also happen to go out at that moment too. It's like the Audi's even before the computers did anything more than fuel mixture, folks pressed the wrong petal and blamed it on the car.
(If at first you don't succeed, do it different next time!)
... 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 think it was also related to the push button start feature. Most older drivers are familiar with, turn key, engine shuts off, not hold button for 5 seconds to turn off engine while panicking.
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...
Manual Override
Technically knowledgeable people often give very poor names to their efforts.
First rule of real time: No recursion.
I used to have a truck with a sticky gas peddle. As in I pushed it down and it didnt come back up. I quickly learned a secret... when it happened, I turned the truck off, dropped it to neutral, and breaked.
I knew that when I was 16. Why cant people figure that out 15 years later?
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.
Drive older cars. They're not getting better anyways. Just more complex. e.g. Television for each passenger and 28 cup holders....
In Canada, the public is protected from such software bugs by statute, in the same way the public is protected from medical screw ups: a professional engineer is required by law to write any software code where safety is on the line. Just like when a new bridge is constructed and must be designed and validated by a professional engineer who is an expert in structures and who becomes professionally liable for the project, the same is true for software. If safety is on the line, a professional engineer who is an expert in software and/or computer systems (as the case may be) must design and validate the code and they become professionally liable for the software. Unfortunately, too many companies ignore the law.
Source: Professional Engineers Act of Ontario (http://www.e-laws.gov.on.ca/html/statutes/english/elaws_statutes_90p28_e.htm ) and Professional Engineers Ontario (http://www.peo.on.ca/). There are similar acts and professional associations for all provinces and territories in Canada.
Full disclosure: I'm a professional computer engineer registered in Ontario with PEO.
systemd is the answer.
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...
FTA:
Just to clarify, the "tasks" are equivalent to apps running on smartphones or PCs.
It's sad that a publication targeted to EEs has writers that dumb everything down with this sort of populist pap.
I am becoming gerund, destroyer of verbs.
Or at least avoid any software-controlled devices capable of killing you. And hope you never need a CAT scan. Yeah, can't think of any examples of microwaved people, but you *know* that somewhere in the software there's an extremely rare corner case that will fail to shut off the x-ray source.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
You're one to talk, you can't tell break from brake. Idiot.
From the slides:
"Toyota used dangerous recursion"
Not like that safe recursion that other vendors use.
This drive-by-wire shit would be cool if everything were built to aircraft flight control standards, but it is not nor will it be and proponents need to FACE that reality.
Safeties should be SIMPLE, not cute.
A mechanical throttle with a good old-fashioned return spring is most appropriate for use on street vehicles. Not perfect, but proven to be highly reliable.
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.
you *know* that somewhere in the software there's an extremely rare corner case that will fail to shut off the x-ray source
Certainly you should assume there is, and have some sort of "dumb" safety override (e.g. a simple timer, not in software). Doing otherwise in a system like that is madness.
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."
http://en.wikipedia.org/wiki/T...
That close enough to what you were thinking of?
systemd is Roko's Basilisk.
You should check out some of the work done by the more adventurous self-driving car projects - I don't know about ice, but there's one that can drive an open-wheeled indycar around Nurburgring in the rain with professional-class lap times (and if you've ever driven Nurburgring even in a simulator you know it's not exactly easy driving to begin with)
As for liability it would seem pretty obvious: unless the accident was found to be due to improper maintenance, it's due to a faulty product and the manufacturer is at fault. Unless product liability laws are changed, and that would probably be a pretty bad PR move for the carmakers - probably cheaper to simply get a little extra insurance.
Of course the natural extension is that, given proper maintenance, the owner can't possibly be liable for accidents caused by the vehicle in self-driving mode, so if you remove the steering wheel there's no reason to require them to carry liability insurance at all.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Nothing can explain the simultaneous loss of brakes. The brakes on all cars are far more powerful than the engine, and in most cases the stopping distance with an engine that is floored is only 5-10% greater than with the engine at idle.
I would have set up the laws, if it were me to do so, such that owner of auto-drive car must have insurance and insurance must pay. Insurance may attempt to collect from any negligent party.
Integer issue that integer overflow or rounding errors could be another potential cause. But if they figured out it is indeed stack overflow, that's excellent debugging.
Or at least avoid any software-controlled devices capable of killing you. And hope you never need a CAT scan. Yeah, can't think of any examples of microwaved people, but you *know* that somewhere in the software there's an extremely rare corner case that will fail to shut off the x-ray source.
Something like this?
This one was operator error. But you'd think there would be better software checks in place so this would be impossible.
The crazy thing is, is that MRI scanners have required the weight of the patient to be entered for many years so it won't cook the patient with RF pulses. The good new is that the CT incidents in the links above caused a nationwide acknowledgement of the dangers of radiation exposure in CT scanners. So it really helped to create the current generation of scanners with significantly lower dosage.
like, say.. an ignition key? oh, oops..
(yes, i flipped back to the source material)...
-r
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.
In Canada, the public is protected from such software bugs by statute
Unfortunately, too many companies ignore the law.
my father-in-law was nearly killed by one of these acceleration events and he's not even close to elderly. he was sitting at a stop sign waiting for a train to pass when the car inexplicably accelerates and lurched forward. he told me this story before the media broke any of theirs. he said this happened several times with this car and it wasn't a floor mat or anything like that. so I think it's idiotic to completely dismiss this as driver error.
"They said I probly shouldn't fly with just one eye," "I am Bender. Please insert girder."
Wasn't that what caused all the trouble ...
What do you do about imported products? Like cars...
It should not be that hard to handle the stack overflow exception in a safe way.
First make the crash reliable, either by having a read-only page at the end of the stack, or by monitoring the stack pointer on each function call if the hardware is unable to do it
Then once the process crash, detect process termination and stop the car.
Yeah. Seems like leaving out an obvious and fail-safe emergency off switch from your designs for a potentially lethal device is grade-A stupid. I can't imagine what some of those automotive engineers were thinking.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Drove a Mercedes 190D once. Alternator quit on a long distance drive. I only noticed because the radio stopped working.
(Car had a great mileage, too.)
Considering that the discover of X-rays died from radiation-induced cancer (IIRC) it's sad to believe that there was ever any doubt about the risks.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
How may times have you heard about an F-16 experience "unintentional accelleration"? Hire the Avionics engineers from defense contractors to write your drive-by-wire car. It will increase the cost of the car to a few mills but hey it's only money...
Even mechanical throttles have been known to stick every once in a while. It's somewhat amazing that once we evolved away from the push-pull throttle on the steering wheel (around the dawn of the 20th century), the foot controlled throttles have never had a good way to positively 'close' the throttle. Sure you can stomp on it to open, but the best you can do is take your foot off the pedal and hope it returns closed under what ever mechanical or electrical means is provided.
Conversely, Car and Driver performed a test and found "Hit the Brakes", "Shift to Neutral", "Turn Ignition Off" or various combinations of the three are all very viable ways to stop a car...even going 100mph with the throttle wide open.
http://www.caranddriver.com/features/how-to-deal-with-unintended-acceleration
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.
Check out this video where someone demonstrates putting both brakes and throttle to the floor at the same time, and yes, it does stop. It stops even faster with 'brake assist', which automatically cuts the throttle when the brakes are on.
Moderated Usenet
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 ...
there's one that can drive an open-wheeled indycar around Nurburgring in the rain with professional-class lap times
Which doesn't mean driverless cars are much closer to being usable in the real world. Nurburgring, like any race course, consists of a single known path, and you don't have to worry about pedestrians walking across the road without looking.
I have had a stuck accelerator on two cars, my '91 Ford Probe and a '66 Pontiac. In the case of my Probe it was due the throttle cable not retracting properly, a little oil and cleaning solved that problem. On the Pontiac it was the carburetor getting stuck. Most cases I read about are with older drivers, some of whom should no longer be allowed behind the wheel.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
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.
>a professional engineer is required by law to write any software code where safety is on the line.
Uh-huh. Let's take a look at what it takes to become a PE.
Yep, two exams and managing not to get fired for four years is all it takes. If that is sufficient to reassure you that having a PE on the job means that your product will be well designed and safe, all I can say is that you have a very low bar for reassurance.
Though the title of PE has a certain respectability associated with it granted to it by age, for software engineers, its not much different from worthless certificates such as A+ or MCSE.
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?
Maybe because he's an idiot and believed the engine was stronger than the brakes? One local elderly woman admitted that was why she lifted her foot off of the brake after a lamp she had in the front seat fell and jammed the gas pedal down. She hurt several people with her mistaken belief.
I don't have a problem with drive by wire throttle on cars.
Why don't automakers just implement a "master breaker" pull switch within driver reach? If the cars electronics go out of control, just pull the master breaker to cut all power to electronics and let the car come to a stop.
heh guess you never drove a really old rusty car. then again forcing the gas peddle back up or just using the brakes fixed the problem. had a old dodge rv that was good for the cable to stick. of course replacing the cable fixed it.
Easy, do what the Aerospace guys do.
At the top of the stack have some fixed number of memory pages configured as no access. The hardware will issue an interrupt and based on the address at fault a stack overflow can be separated from a generic bad pointer de-reference.
Additionally, recursive algorithms are generally a bad plan for production software. There almost always is a suitable iterative algorithm for the task at hand. Additionally, what on earth would a low level throttle control algorithm be doing that would require a recursive algorithm even in the most naïve implementation.
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.
There was a recall issued on my 2010 RAV4 for that very reason. They replaced the weatherized floor mats (if you have them) and the gas pedal for one that is shorter at the bottom leaving extra room between it and the floor. In my case, it was a simple swap because it's all drive-by-wire (no physical linkage) and I had the normal floor mats that stayed in place with two hooks in the back.
Life is not for the lazy.
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.
Software shouldn't control the throttle of a car your foot should
But it didn't.
Even if the self-driving cars are well coded, what about hackers? Imagine a virus that causes, say, a million vehicles to go berserk some Monday morning during rush hour. Or even just causes a million vehicles to brick themselves. Yes, people can also go berserk, but you likely won't get a million of them doing so at the same time. Have we learned nothing from M5 or iRobot or Terminator? Methinks 'tis about time for a Butlerian jihad.
linquendum tondere
stack overflows kill people.
How many people keep the brake completely floored when stopped? I know I don't - I keep it down enough to stop the idling engine from moving me forward, but I don't doubt that my car would take off if I slammed down the gas pedal while stopped like I normally am.
More of what you said, when the drivers don't have a reason to be less than honest.
Who said he took his foot off the brake? You believe something VERY wrong. You seem to believe that when you are stopped you have the brakes on as strongly as they can be. Not true at all. In actuality, most people are stepping on the brake only enough to stop the car from moving. If you step on the accelerator (and do not increase the pressure on the brake), the car will lurch forward, as you will no longer be applying enough brake to keep the car stopped. I know, you're going to try this to prove me wrong. And when you step on the accelerator, you will subconsciously also step harder on the brake.Have some one ELSE actuate the accelerator while you have the car stopped and you are unable to see what they are doing. Please do this in a large parking lot with a lot of room for error. I know of this because as a youngster (young and stupid still, at that time) my pals and I used to delight in pulling up behind each other at an intersection and pushing the other into it. VERY easy to do. Even easy to do a second time, when they're expecting it. Again - you're not applying the brakes as hard as you think you are.
I really don't know. but I think I read in a lot of comments that these new Toyotas use a brake-by-wire system. even the start/stop button doesn't physically control anything, just another signal for the computer.
Wealth is the gift that keeps on giving.
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.
At least through the mid-late '90s, the American car manufacturers that I dealt with (from the late '80s until then) that were using Motorola MCUs for ECUs had very strict rules that went beyond DO-178B specifically because they were terrified of liability issues (though whether or not this was true in what actually went into production, I can't be certain, just that these were the rules I was told they had to deal with and all our products must supply a way to achieve). I dealt with airline ECUs, also, and never found them to be afraid of caches, for example.
1) no caches, unless the caches could be locked and used effectively as SRAM
2) no DRAM holding any code that was timing dependent (in general, ECUs used only SRAM)
3) the only branch backwards in the code was at the end of the code back to the start of main loop, forget about having function calls.
4) if at any test and set a flag wasn't ready, signal it to be dealt with on the next pass where it could be upgraded to an error
5) any code not written in assembly must be refactored in assembly so that predictable timing could be established
6) in general, everything was polled and interrupts are reserved for panic situations
I did not enjoy working with them and watching them ignore feature after feature that could have improved performance get tossed out the window out of fear or problems that had been pretty completely worked through and resolved before I ever got to college, given enough CPU power and fast enough data paths.
Somewhere around 1994, though, I had the opportunity to start working with the Honda and Ford racing teams, where the culture was understandably different. Able to use 32-bit CPUs to full effect, combined with the 68332's TPU for their timing specific things, allowed them to make the order(s) of magnitude jump in performance to give the soft real time (x can happen before time y, as long as it is guaranteed to happen before time y or a signal is thrown; not the same definition of soft real time everyone uses) approach a fighting chance over the hard real time (x happens at time y, even if delays need to be inserted to make sure that happens; again, not the same definition of hard read time everyone uses) camp. While I am very happy that car manufacturers all seem to have made that jump in every area, knowing that thorough testing of complex code is frequently the first thing management gives short shrift as deadlines approach does keep me open minded to the possibility that software could be the problem in situations like the acceleration issues. I can't recall of a situation where inadvertent acceleration was tracked back to anything ECU related, for what ever that's worth. Other aspects of car management, however...
I might be an old geezer at this point but I feel like the Slashdot from my youth would have phrased this as "A Stack Overflow ..." as opposed to "Stack Overflow ...".
I feel like editors nowadays a) have no clue what they are talking about b) are concerned with clicks over substance.
You do remember correctly http://en.wikipedia.org/wiki/M...
The brakes are never adequate to overcome the power of open throttle. NEVER.
Explain why cars can stop quicker than they accelerate then.
The brakes of any car can apply enough force to lock up the wheels at any speed. The engine can't. Not even a super car can spin the wheels above 100mph.
Sitting at a stop sign with the car in "drive" is a driver error. His foot could slip off the brake and the car would move forwards, wither into traffic or into crossing pedestrians.
This is what we have things like neutral and handbrakes for.
He'd have failed a UK driving test there and then.
I know probably 90% of American drivers do this, but it's still not sensible or safe behaviour.
Because no brakes are better then some brakes, everybody knows that.
Your hair look like poop, Bob! - Wanker.
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.
What about people randomly clipping power lines?
What about people with bombs?
What about people fucking with the traffic signals?
What about attaching the subway, bus, especially the ferry systems near islands.
This isn't the first scale attack possible. It's not even the first scale attack against transit.
I thought so. What a shame. Though I suppose the fact that even she never really acknowledged the health risks of radiation exposure makes the later CAT-scan thing a little... anti-ironic? Is there a word for that?
I'd like to propose a toast to a brilliant woman that gave her life advancing the cutting edge of science. Let it never be said that either women or geeks don't have the fortitude to step boldly into the darkness and brave what demons may reside there.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
even the four-way hazards should trip the computer into resetting the throttle algorithm.
Whoa... lots of idiots turn on hazards while moving, in the middle of a highway. I saw this in Virginia during snowstorms.
Not saying it's right or good, it just happens a lot.
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. ;)
It's been 20 years since automatic transmissions had a physical link between the shifter and the transmission.
A Camry gets 70 MPG? ;)
Anywho, a '95 Impala has a 3.08:1 rear gear ratio and a 4L60e transmission with a fairly low-stall torque convertor.
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.
"The brakes are never adequate to overcome the power of open throttle. NEVER."
Stupidly wrong. Car and driver actually tested this in a disparate group of vehicles, and in all of them the brakes would stop the vehicles even under the worst case scenario they were testing (highway speeds, full throttle in the lowest possible gear). http://www.caranddriver.com/fe...
"Lastly, look at burnout competitions."
This really shows some ignorance. When you're doing a burnout, you apply only a small amount of brakes, this is to stop the vehicle walking forward. Applying the brakes too hard is a common reason people have trouble starting a burnout.
OK, I'll be the first to post it... "Go back to analog control systems". Ford Model T's don't have this problem, and neither do '63 1/2 Mustang convertibles.
why not give the driver an engine kill switch (hardware battery kill switch) similar to a choke or something. problem solved.
Sort of makes you wish for that gas guzzling 1969 427 Camaro SS V8 with the mechanical throttle, dual 4 barrel carbs and enough power off the line to leave your Prius in the dust and all without a computer in sight.
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.
Sort of makes you wish for that gas guzzling 1969 427 Camaro SS V8 with the mechanical throttle, dual 4 barrel carbs and enough power off the line to leave your Prius in the dust and all without a computer in sight.
The only reason it needs all that power is so it can tow a gas tanker to compete with the range of the prius.
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.
I run a small business in India making software for automotive and embedded systems.
Between the car and the engineer, there are multiple middle men (OEMs). These middle men win bids with car companies purely on the 'feature vs cost' basis. Yes, there are standards. Yes there are rules. Yes there are certifications. But, when its a question of the cheapest bidder, it eventually boils down to the engineer quality. And, in India, we have enough idiots with an engineering degree without a clue of engineering, who fit the 'cheap' tag.
MNCs, hire these guys in masses and pay them more than they are worth. They have set the cost for a knows-nothing-does-nothing engineer as $20 per hour. I guess they are able to manage because of the lucrative banking and BPO businesses that they handle.
In the automotive side, OEMs are aggressive with the cost of development. I sit regularly in negotiation meetings which squabble over $11 per man-hour. Automotive software requires strong understanding of programming, electronics, and mechanical systems. There is no way to get such good engineers at $11. And there are competing companies in my line of business who work at less than $10. Basically, they just horde people who were not able to get a job elsewhere. There are companies who hold compliance certification but no development talent. They simply test and rubber stamp code from other cheaper vendors. OEMs engage a 'certification company' and a 'development company' in order to develop a product that is sold to a car company.
So, there you go.
And me, I am done with this domain. I am getting out soon. I am just waiting for my existing commitments to get over.
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.
Lots of companies have bad names. Yes. That's what I said.
I suggest not giving your wife an iq test, in case intelligence is genetic.
Anyone who thinks all software has bugs has never written "Hello World" in assembly.
Perfect, trivial software is clearly possible. Perfect software that's slightly more complex is also clearly possible. We haven't yet accepted that perfect software is possible, but we should demand it (for moderately expensive software, or where bugs will cost you money, for instance). A reasonably intelligent programmer writing a modestly complex program should be able to do so perfectly. That he can't, (because his tools don't help him do so) is infuriating.
Yes, almost all software has bugs. We are way too comfortable with the idea. Software doesn't need to have bugs. We just don't have toolchains and development stacks that encourage perfect software. It's as if engineers decided to only use modeling clay for buildings, because nobody sells steel, and it's too cumbersome to smelt their own.
The profession really is no better off for accepting this sorry state.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
Toyota uses a hydraulic module in the brake lines that simulates brake cylinders moving and applies the regeneration instead. These modules have a fail-safe in that a hard slam on the panel will always engage the brake cylinders. I presume that is mechanical in nature. It is definitely not 'all central computer module'.
Electric steering does use a voting mechanism, AFAIK. It is also more critical than avionics. As one engineer explained: at 6 km altitude, if a computer reboots for 20 seconds, not much happens, and time is left to regain control afterwards - while in a car you've already hit something by then.
And as far as that 'braking can never overcome the engine power' story popping up later: it can not be true, most cars stop in a shorter distance than the can accelerate. And if they don't, what is wrong with car buyers? Need to accelerate off collapsing bridges, but never need to make an emergency stop?
I think everyone needs to protect himself by bringing an anchor which he can throw out of his window, so he can stop his car.
How can users protect themselves from sometimes life endangering software bugs?
Uh. Simple! Don't buy cars where the default is "drive by wire". Plain and simple. In the event of a catastrophic failure like this, you want the HUMAN in control of the vehicle. Period.
Chas - The one, the only.
THANK GOD!!!
Common and correct practice to do this when suddenly slowing in unexpected circumstances, like sudden traffic on the highway. Or, when vehicle is going much slower than normal, like in a snow storm without snow tires, or.... Nothing idiotic about it.
As you say a CAT scan is X-ray.
But an MRI is more like an actual microwave oven, I've been in one of them for 20 minutes and you actually feel you are getting warm all the way through, like you are getting a fever. I asked the technician, he said yes, everyone heats up in an MRI scan.
There are software engineers that use meaningful QA techniques - you destroyed my understanding of reality. I am now in such a deep state of schock that only a glas of obstler can recover me back to life.
Look, I'm going to just throw it out there - this guy couldn't prove anything that happened (as his assumptions relied on there being some feakish conditions).
He also stated that there was no way it was gas, but then couldn't back up that claim. I wondered why he would so strongly testify against something that is clearly unable to be proven either way, until I then read about all the other cases that are waiting. This guy is now sitting on a fortune as a specialist witness.
One word... Friction
One word.... Friction
>10/25/2013 03:35 PM EDT ..."
>"Michael Barr recently testified
>recently
I've heard this story before
A simple EMO button could work wonders. Power down the fuel, inverter, and computer would kill the accelleration and fail safe. Manual steering and brakes still function to maintain control.
The truth shall set you free!
Computers are very capable of dividing by zero. It is well defined by the floating point standard. It's just that Windows per default set a flag that doesn't allow this.
In that case you'd simply turn the engine off. Brakes would then stop the car with only inertia to fight.
That's the problem. Because it's plausible, all of a sudden every person who presses the wrong brake pedal can sue. Supported by specialists who can't prove the theory, but can always say 'Well you can't prove otherwise'.
Without proof, I can theorize that ALL accidents with wire throttle are due to software error. Well, you can't prove me wrong, so I guess I win.
Yes, if you are traveling 55 and the throttle suddenly applies at 100%, your first instinct is not to stomp the brake with maximum force, bringing the car to an abrupt halt, but instead to press the brake progressively to hold speed. Do that for 10 seconds, and your brakes may no longer be strong enough to halt the car.
Audi was improper pedal application, but Toyota looks more like an actual unintended acceleration, followed by poor driver reactions.
Learn to love Alaska
Huh, I had a brain scan once and don't remember noticing any heating. But then again I may have been distracted by the intense kinesthetic hallucinations I was having. Pretty unsettling feeling my body being tied into all sorts of impossible bone-bending pretzels, especially while lying perfectly still in a narrow tube looking out along my (undistorted, obviously) body in that tiny little mirror. I've never heard of anyone else that reacted that way though.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
And as far as that 'braking can never overcome the engine power' story popping up later: it can not be true,
Yes, it can. I've had partial brake failure from a single stop downhill from about 100 mph in a '87 American car with drum rear brakes (starting from cold brakes). If the throttle had been stuck open, that 100 hp 2.5l would have overpowered the brakes.
Note, if I had locked up the brakes at 100 mph, I'd have stopped faster, and the engine wouldn't have been able to overpower the brakes. But, given a little fade, it's enough to tip the scales, especially if someone uses the brakes for 10 seconds to hold the car's speed, not realizing the urgency of the situation.
Learn to love Alaska
"How can users protect themselves from sometimes life endangering software bugs?"
Use Ada.
Cable and all. Problem solved.
Also, just kill the engine via turning your key to "off".
It's easier for a computer to dodge a pedestrian than a person. Often the person will steer for the most open space, which is the same place the pedestrian goes. That's not the most effective dodge. The optimal dodge is to stop in a straight line, regardless of the location of the pedestrian. Unless the pedestrian is elderly, in which case, adjust slightly to avoid them, and brake as hard as possible. Neither is the "human" reaction. People steer, rather than brake. I'm not sure why, but braking is almost always better than steering. Cars stop much faster than people think. People prefer to drive at about 0.1g, starting, steering, and stopping. Most cars will do more than 1g stopping. But people aim for about 1/10th that or a regular basis, and think 2-3 times that is "very hard". I've dropped the anchor a few times for my passengers to feel what a car can do (always safely, of course).
Learn to love Alaska
"Did they also discover a flaw in the brakes such that they could not overcome the engine power?"
Just turn the key to the left and there will be 0 power.
Look we had a "finger print" expert for which the case had to be revisited when it turned out she made it up on the spot, and we had a "fire" expert without any clue which condemned somebody to death. I am in serious doubt of locally taken "experts" for prosecution or for the defense in a legal case. The facts remain that this problem was mostly 1) old person and untrained folk 2) pretty much only in the USA.
Maybe they had a software version specific to the US, but otherwise it does not make sense that this did not happen *at all* in europe where toyota are sold by the truckload in europe, roughly 6 time the number of toyota sold in the USA (usa 150K roughly http://online.wsj.com/mdc/publ... europe 850K roughly http://newsroom.toyota.eu/news...).
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
If the driver's so dumb they don't know shifting to neutral will stop the accleration, may be they should die according to Darwinism.
allows recursion on a system controlling a critical system?
Most things which are needed for such a function can be written as a straight-line program and iteration. I would e ven go so far to say that if you need more complex functions, then spend the 25cent per car for a dedicated microcontroller for the low-level function.
Sorry to affect your american centrism, but it happened in France, too, and the case is quite documented (pardon my french). The police -which were contacted by the driver- had to make room for the car on the motorway, and to find a solution to slow the car down gracefully. In the end, nobody was hurt, but Toyota...
While I do agree that in the litigation-driven country that became the USA, most of these drivers must be full shit, and surfing on the "it's not me, it's the machine" wave, it looks like there is a real software defect.
Stupidity is the root of all evil.
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.
Firmware engineer here. While I don't work on safety critical systems not allowing recursion or dynamic allocation is just standard practice.
Memory leak errors are almost impossible to debug on a microcontroller. So as a preventative measure, standard practice is not to do any dynamic allocation after hitting the main loop. Initialisation is ok, it runs once and never gets freed. Once the system is running however, the risks outweigh the benefits.
Recursion is much the same, it's easy to blow the stack, messy to debug and makes static analysis hard.
While both can be done safely we consider them automatic red flags and any use needs to be accompanied with a justification in the comments. The code is also very carefully checked. Typically the problem is readdressed and another method used.
It's pretty stupid and distracting when a bunch of cars, all in the same road and weather conditions, are flashing their hazards.
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.
That's correct. Neither recursion nor dynamic allocation are allowed. C++ is only barely allowed (it's pretty new at this point), and even there most of the C++ features are not allowed: no dynamic allocation (you can never delete an object), no exception-handling, etc. The operating systems used are extremely simple real-time OSes where every timeslice is planned for, and there's no preemptive multitasking (only cooperative). Basically, everything is made to be as deterministic as possible, and anything that reduces determinism is forbidden.
Another big point: caches are not allowed. So all on-CPU caches are disabled. You can imagine what this does for performance. Caches are bad, because they are non-deterministic (it's too hard to predict how long something will take to run, because you don't know if you'll have a cache hit or not).
Why did he take his foot off the brake?
Because he put the car in neutral?
Oh wait...
So what are you supposed to use then if malloc/free and stack variables aren't allowed? Just interested.
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
How can users protect themselves from sometimes life endangering software bugs?
there was a time when cars didnt have computers. there was also a time when the computers ran a single program instead of an operating system that executes other programs.
why do we have operating systems for the only important function of the car?
Anons need not reply. Questions end with a question mark.
It would have cost almost nothing for the OS and/or the compiler to insert a little code that made sure that the stack couldn't overflow. If those kinds of checks aren't built into the platform and tools, critical and lethal bugs are going to be much more frequent than they ought to be. Given the power and low cost of modern embedded computer hardware, worrying about saving a few percent in CPU cycles is pointless.
To get companies to change their ways, courts should recognize this kind of programming as criminal negligence and punish Toyota and the responsible employees accordingly
Perhaps there is some sort of... hazard?
In the case of the TS, there was a report from NASA that says at page 15 that even at full power with depleted power vacuum brake assist, you can still get the car to stop by braking. And they showed it.
As for your argument of burnout, this is ussuassy done with the hand-brake, that only brake at the rear tires only.
You can get in problems with brakes if you let then run too hot, descending from a hill is a known example of this.
The Toyota sudden acceleration problem disproportionately affects the elderly and inexperienced drivers.
You mean the kind of people who buy Toyotas? With the exception of the GT86 and the LFA, they're horrible to drive anyway. People who drive buy something else.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
...how the probability of being affected by one of these stack overflow bugs, increases with the age of the driver. Just sayin.
The person who says that bug-free software is possible is speaking truthfully, if one can omit hardware errors.
The person who says that it's possible and then starts talking about techniques and tools is fooling themselves. If you have not mathematically proven that your code responds correctly for all possible inputs, you have done nothing.
I don't know where you hubristic half-wits come from, but I wish you would return there. Your first delusion must be that you can or habitually do write bug-free code, which is statistically unlikely. The second is that there is some factor x which if people would only pay heed to, they would be able to write perfect code too.
If you haven't measured performance, you don't know or care about performance. If you haven't proven your software correct, you don't know or care about correctness. Just so you know, proving a program correct is difficult except in trivial cases. That is why code has bugs, and not some horseshit about toolchains. We can write provably bug-free code, and choose not to, because the process is insane and not generally worth it. Nor is it likely to become easier.
Generally, you are right. People do make mistakes. The issue is how frequently they make them.
Software can be simulated at speeds that would tire the average person. This means that the mistakes people embed into software can be stimulated far more frequently than the mistakes that a person actually makes. This testing leads to the mistake a person make having literally hundreds to millions of opportunities to be noticed. With a larger opportunity of detection, the software in a shop that cares about correctness is rarely the culprit.
Now, I agree that one might make the mistake of not noticing an issue, or of testing an item in a way that doesn't catch the issue; however, it is a lot harder to make two mistakes that are so complimentary if you follow best testing practices.
I think software is blamed because the average person has to deal with shoddy desktop applications, and assumes that all software is written equally badly.
Emission and fuel consumption standards can not be met without an ECU. That makes old carburetor or continuous injection engines almost, if not completely, Illegal.
another problem would be an error in the code due to copies thet have been corupted
by a copy machine.
one badly copied letter or number can cause a problem.
all new code should be checked against a known good original copy for
any errors cased by the copying machine process.
MISRA which has become the basis for coding standards for things like Joint Strike Fighter doesn't allow recursion. I wonder to what standard they code to?
It is pretty common to blame users for system malfunctions. And often, that turns out to be correct. However, you being here, chances are you somehow involved in software development and its processes, and have experienced many of its failures. Here, we're talking about software people bet their life on. I do think it's warranted to look very closely and actually rule out that the failure was a technical one, and I find it difficult to imagine an argument against that.
Truth arises more readily from error than from confusion. -Francis Bacon
This bug has cost lives. The reason it seems to come and go every five years to you is because it has to wind through the court system. If you had read the article, I think you'd be better informed. Instead you had to put your two cents in to show the world how bright you are.
If you look at the full development cost of a car - including the cost of parts that were designed for other or earlier models, the prices do hit multiple millions. I remember in the 80s Honda spend $200Million on their Formula 1 engine (turbo charged 4 cyclinder). The cost is spread out.
How reliable? The electronics and sensor behind air bags has proven to be, statistically, remarkably reliable. Even 20 year old cars with oodles of miles on them, don't have air bags blowing up in driver's faces on a regular basis. It can be done.
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.
I always learned (and do) break on the transmission when going down long steep hills - I normally don't have to touch the break pedal at all. On a manual this is obvious how to do (just downshift untill appropriate speed is reached, and don't redline the engine, use the breaks to CHANGE speed, not to keep from running away). On automatics there is (in my tiny experience of these) usually a possibility to force it to a specific gear, basically driving it as a clutchless manual, or at least a "low gear" button/position on the transmission handle.
As one engineer explained: at 6 km altitude, if a computer reboots for 20 seconds, not much happens, and time is left to regain control afterwards
Not true during landing/takeoff at least.
While it takes 6+ seconds to hit 60 mph, the brakes can stop the same car in 2. Brakes should be able to generate much more of a stopping force (at least for a few seconds) than any engine can. Go try it. And if your car can't do it, throw it away and get one that can. BTW, I own two corvettes and a diesel truck with 850 ft-lbs of torque - and brakes win on all of those!
If the gas is controlled by software, why would you think the brake isn't? If one can fail, it's perfectly reasonable to believe that the other would be likely to fail, and at the same time.
Furthermore, depending on where the error occurs, it would be possible for it to appear to the event recorders that the driver released the brake, and hit the gas.
Vacuum assisted braking (most cars) provide enough vacuum reserve to allow for assisted deceleration after the engine has been shut off. You can test this by starting your engine then shut it off while in park. The pedal will still be soft without the engine running but only for the first couple of times you press the pedal. Typical assist systems are 3.8-5.5:1. Meaning you normally do very little of the work required to create the line pressure to the calipers. I'm not sure what happens with the few Mercedes products which used brake by wire during the various system failure modes but I expect that so long as the system has battery power you should be ok.
Power steering when you are at speed doesn't do a whole lot. If you've ever driven a car without it once you are moving at above parking lot speeds you are A-OK.
I doubt very much that any steering column will lock until the key is removed from the ignition, I'm not sure about cars with stop/start buttons and no key slot/socket but that would be software driven.
Some cars have a rev limiter at 3-4k rpm for neutral so even if you do bump it into neutral you won't hurt anything unless the ECM decides to destroy the engine.
Brakes in just about anything you can buy today are going to be more powerful than the engine. You can reach a higher rate of G in decel than accel in pretty much anything made today (particularly for two wheel drive cars) for general consumption (drag racing cars probably don't fit this model). This is of course up to the point where you induce pad or fluid fade. Yet if you use the vacuum reserve correctly you should be able to stop safely if you give the brakes ONE smooth, solid decisive press and hold them firmly until the car has stopped. If you're uncertain and let off then press again the vacuum reserve is going to be depleted and the driver's own lack of training is the means of their end. Driver training is more expensive than an ECM with better code.
BRAKE you illiterate moron!!!!
As far as I remember, MISRA C rules forbid any kind of recursion.
They want their coders back..
---- Booth was a patriot ----
It turns out that Toyota *did* have a hardware watchdog that would initiate a full ECU reset.
However, the designers of the watchdog system, found a problem. If they had a software routine pet the watchdog, then because of CPU starvation, the lag in petting may cause the watchdog to force a system reboot. Toyota solved this problem by moving the watchdog petting to a hardware timer....
What sort of strategy would you use if you can't use local variables?
In the testimony, Barr states that a major problem with the Toyota code was dependence on a huge volume (about 11,000 individual variables) of global variables. So, if globals are bad, and you can't use locals... What do you do?
I've yet to see a demo of an automated car navigating anything resembling an icy surface (safely or otherwise)
You need to watch this. Watch the part where they drive up the ramp.
"First they came for the slanderers and i said nothing."
As you say, you CAN turn off a car when the gear selector is in "drive", but it may not be obvious how to do it.
For example, I have a Toyota with push-button start. When the vehicle is stationary and the gear selector is in Park or Neutral, the button works kind of as you would expect, but the behaviour is different between gear selections (in park, pushing the start/stop button, shuts off the car's electrical systems completely; in neutral, the button merely shuts off the engine, and leaves the accessories on).
HOWEVER, when the gear selector is in Drive (or the vehicle is rolling in neutral with the engine running) then the start/stop button is inhibited. Pushing the button WILL NOT shut off the engine. Pumping the button will have NO EFFECT. In both of these situations, there is no confirmation that the button is doing anything - there is no indicator light, no chime or warning beep. Nothing.
There IS a fail-safe shut-off, but you have to HOLD the start/stop button for 10 seconds continuously, at which point all electrical systems will be shut off. There is no count-down warning buzzer suggetsing that the button is doing something and that you need to hold it a bit longer. no light, nothing. There is also nothing in the manual about this.
I decided to test this out, after reading all these stories about people not being able to shut off a malfunctioning car. I did this on a private road at low speed - and even though I was in full control of the car, and was holding the power button hoping it would shut off, the 10 second delay was long enough for me to begin to wonder whether this strategy was going to do anything at all.
A watchdog won't do anything in this circumstance. However, there are strategies for dealing with this sort of failure.
For example, you can use 2 transducers, which produce signals with different profiles and power than from independent power supplies. E.g. Toyota's DBW accelerator pedal does this. It contains 2 potentiometers - one is powered from 12V and produces a rising voltage with greater pedal pressure. One is powered from 5V and produces a decreasing voltage with greater pedal pressure. The ECU measures both signals and has a table relating one sensor value to the other. If the sensors readings are inconsistent, a failsafe mode is enabled (if one sensor is reading out-of-range, the remaining sensor has authority within a restricted operating range (up to about 10%); if both sensors are out of range, then the ECU interprets this as idle).
A similar principle could be used for control of an electically operated throttle valve. You have a motor control, a spring return, and dual potentiometers on the throttle plate (potentially connected via different mechanical linkages). The ECU can correlated the values of the independent sensors, and can also correlate the motor duty cycle with a table giving the expected duty cycle required for a given throttle position. Whether this type of control is used, I don't know - but it would be possible. It would also detect faults such as a throttle valve becoming stiff or slow to close, or otherwise obstructed.
The question is how much are you prepared to spend on adding redundant systems such as this, and the additional testing and validation that is required to ensure that they work as intended.
This is 100% semantic wankery, because triviality is circularly defined as the magic threshold beyond which bugs become inevitable.
Of course there's an implicit ego frame of reference, because we're all looking for an edge on the margin where the big money lives. They didn't call it a "space race" for nothing. It would be far more pertinent to observe about the human species that bragging rights come from body bags. That's just how we run our affairs on the larger political scales.
I can't stand the intellectual posing that ensues whenever someone espouses the culture of bug mitigation with extreme prejudice. Oh, nothing can ever be perfect—as if that's ever the human standard in anything. Part of this is IQ wanking: the notion that writing bug-free code requires superhuman feats of logical perfection. Successfully reasoning your way out of a wet paper bag has something to do with writing bug-free software, but it's a secondary term at most.
The real key to writing defect-minimized systems is a good understanding of human psychology and mental frailty, keeping notes, and constantly upping your game.
It's a rare piece of software that is more robust than the worst API it programs against. Even if the code behind that API is 100% bug free, you're far from out of the woods, because the API can be designed in such as way as to delegate complexity up hill.
No doubt Opportunity was far from perfect, but it sure as hell sets a god-like bar compared to what passes for quality work in 98% of the make-a-buck sphere.
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.
There is no physical neutral in a synergy transmission. It is simulated by software, and if the computer has crashed, you can't engage it.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Yep, no ignition key in a prius either...next
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
The expert code review revealed 80,000 + standards violation, 10,000 + global variables and a massive pile of spaghetti. Looks just like the usual built by the lowest bidder H1 B / Indian written type code I used to fix as a consultant, the only difference is this code is now in safety critical systems. I think I'll just keep my 94 Toyota after RTFA.
@(stack.overflow) { throttle: "open" } oh darn they dun goofed. oh well! let's close our eyes and hope it never happens again!!
Spent All My Mod Points
Just because it's a retarded idea, doesn't mean an engineer hasn't tried it on a production design.
It's just that the downside of this design choice is a lot more obvious now that we know a condition in which you absolutely do not what a computer between your brakes and your wheels.
Information theory is life. The rest is just the KL divergence.
Using inter-vehicle communication networks (basic ones are already being tested), icy patches will not cause a surprise to every driver (as is the case now). The hazard will be communicated to other vehicles and infrastructure networks/servers the moment the first car detects there is a problem with the road. Other vehicles - those driving behind / in front / in the opposite direction and even those who approach the site only a few hours later will be forewarned. Their systems will be able to make precautions - detour / slow down / etc. Yes, the systems will be even more complex, and there is always a chance for error. The computer will never get tired. You can't touch the response time it can pull off. It can see in the dark, in fog, and it has 360 degree sharp vision instead of a human's mere 6 degrees with 120 deg peripheral vision. If the driver is not distracted, and/or emotionally stressed, fatigued, ill, etc.
There's no question in my mind that computers have the potential to be far far better drivers than humans, but its still a way ahead. The development is very costly, and the legal risks and grey areas are still quite large. It takes a lot of time and money to make a very safe system (which is clearly a necessity). I guess this will happen in layers and iterations. I guess human drivers will not be completely replaced for at least another 20 years, but I would have no second thaughts about handing over the wheel to a capable computer on the highway in 2-3 years.
As for legal questions? The driver will continue to be responsible for the vehicle for a long time When the time comes that no driver will be in the vehicle, you will have a situation that I think is analogous to travelling on a train without a driver. The entity operating the vehicle will be responsible for what happens, with a compulsory insurance for basic cases. Eventually, the manufacturers will be responsible for software- or mechanical failure caused accidents, as is currently also the case.
I have to say it. I hate recursion. it had been mathematically proven that you never need recursion. And you know what your code is almost always more clear without it.
When you use recursion, you explain a problem in terms of itself. When you don't, you explain it in terms of simpler concepts. To understand a recursive function, you almost always have to read it at least twice; once to understand the terminating case and once to understand the non-terminating case.
While I have used recursion to do a few things like parse tree like data, I avoid it. Most recursion I have written was for job interviews (for some reason interviewers think abusing the call stack is clever).
If I was writing coffee for a critical system like an automobile, I would never use recursion. I'd make my own stack in the function and manage it. This way I could control its size and avoid problems.
Abusing the call stack in a critical system just seems like a stupid thing to do.
My 2000 Toyota Camry 4 cylinder, and my wife's 2006 Dodge Grand Caravan both beg to differ with you. Though electronic control of forward gear shifting has been the norm for a couple decades at least, most automatics still use mechanical control for selection of the operating mode (Park, Reverse, Neutral, Drive). Mis-adjustment of the neutral safety switch continues to be a cause of no-start symptoms, even in late model cars. I will grant you that the trend is toward purely electronic controls.
How about *no fault* insurance? The real kind, not the fake kind.
The liability problem could be legislated in a pretty straightforward way. Limit the exposure of the manufacturer to the same level of liability a typical human driver would have. Require owners to hold liability insurance (this is nothing new). Realistically, the insurance companies will have a very good idea of the likelihood of a human driver crashing vs an automated car crashing and will set rates appropriately. I would bet good money that outside of icy/snowy locations, the rates for an automated car will be lower than for a human driver after only a year or two of trial time.
A lot of time we're blinded to the probability of things happening by the scariness of those things. Realistically, being hit by a computer controlled car is no different than being hit by a car driven by a drunk driver, a distracted 30 year old, or an inexperienced 16 year old. The only question is which is more likely to happen per vehicle mile. On dry roads, most accidents are caused by a drive not paying attention or doing something risky. Accidents caused by complex social interactions that a computer couldn't figue out are far rarer than accidents caused by some nitwit playing with his cell phone. If computers completely solve the 80% problem and make the 20% problem 10% worse, I'm OK with that.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
If your concern is that computers will do a worse job of looking at the objects in 3 dimensional space around them and solving the kinematics problems required to avoid obstacles than humans do, I think you can rest easy. Reacting quickly to the sudden appearance of a pedestrian is one thing that a human has almost no chance of beating a human at. Even better, the car's LIDAR system will log what happened so if something does go wrong, we know who is at fault.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
I'm not sure about all of these cars, but I remember from the discussion on one of the earliest of these cases that it wasn't actually possible to stop the car in motion. I think that one was supposed to have a solenoid that actually locked the electronic key in place.
What were the odds of a whole bunch of teen girls claiming to have experienced witchcraft in Salem? Mass hysteria it happens.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Thank you for demonstrating your cluelessness about what the word "professional" means.
Hint: it doesn't have anything to do with having a piece of paper or passing a test or a legal status.
You mean like https://programmers.stackexchange.com/ ?
No, not many (if any) were hybrid Toyotas.
And Brakes still function.
There have only been a very few Brake by wire vehicles, and all of them have had some physical linkage as backup.
Brake-by-wire technology is still under development by some automobile and automotive parts manufacturers industry worldwide and has not been widely commercialized yet. This is mainly due to the safety-critical nature of brake products. So far, Mercedes-Benz (Sensotronic) and Toyota (Electronically Controlled Brake) already use almost fully brake-by-wire systems, on the Mercedes-Benz E-class and SL models and on Toyota's Estima.
Brakes systems sold in the US for passenger vehicles always have physical or hydraulic linkages in addition to any purely electrical system.
This is because US DOT regulations in 49 CFR 571.105 require the brakes still perform with ANY failure in the electrical system, (cut wires, dead battery short circuit, dead computer, etc), and even has requirements for performance with a totally depleted battery (see at S6.2.6A in above). The easiest way to meet these criteria is to add a physical pedal actuated hydraulic brake linkage.
Sig Battery depleted. Reverting to safe mode.
I would tend to agree with dcw3, based on my limited exposure to the industry. I worked in an aerospace company for a few years, and the code I worked on was some of the buggiest code I've ever encountered. The push was to get more features thrown into the software, rather than writing code properly and fixing the existing code. When I first started at the company, the software was crashing every 2 or 3 minutes and often every time the software tried to start up. By the time I left, we finally had it down to every 6 to 48 hours. However, for the environment this software was supposed to be deployed in, even every 48 hours was crashing too often. The code often reminded me of Chuck Forsberg's xmodem, ymodem, and zmodem code, but it actually makes his code look spectacular. Gotos were liberally sprinkled throughout the code, null pointers passed around like they were going out of style, and globals and statics were the cool thing to use in multithreaded code.
Hammer Software http://hammersoftware.ca/ Good service, Creative solutions - Hamilton, ON
1. Modern disc brakes require a power booster, derived from the engine vacuum. I've driven a truck that had a failed power booster, it was extremely difficult to stop it at only 5 miles an hour backing out of the garage (I'm 5'11", 195 pounds, I am not a small guy).
2. At full throttle, the engine is NOT making vacuum, at least very little.
3. Without vacuum, there is no power brakes (after 3 or so pushed on the pedal).
That, my friends, is the problem.
By the way, I have a 2007 Toyota Avalon with this potential problem (accelerator by wire, shift by wire, pushbutton ON/OFF). They've reflashed the computer at least 2 times since this was first made public. The biggest flaw with the "system" is that there is nothing in the owner's manual that you have to keep the ON/OFF pushbutton held in for 4 seconds to stop the engine once you are moving. Toyota's reasoning was that stopping the engine would stop the power brakes (see #2 above), and you would lose power steering (you don't need power steering above 14mph).
I've read that the industry is implementing what Buick has used for years: if several pushes of the ON/OFF pushbutton are tried, it will shut off the engine. That makes a whole lot more sense to me.
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
Normally I would agree with you, but if you dig into TFA you can read the presentation the expert witness provided to the court. In this case it looks like Toyota was pretty negligent in the way they developed the firmware, violating not only industry standard coding practises but their own! The witness and his team produced an 800 page report on the shortcomings of Toyota's engine management system (he had full source code access).
Oolite: Elite-like game. For Mac, Linux and Windows
until you run out of vacuum if the pedal is pushed more than a couple of times....
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
that's the best posting I've read so far.
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
What about people detaching the subway and bus systems? Of course attaching subways near islands could be pretty neat. Watch the fish out the window on your commute...
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.
. . . at full throttle. but what's happening with the vacuum assist at full throttle?
In at least one case, there were brake skid marks (rear wheel, 'emergency' brake) but the car kept on moving and crashed. Yes, ordinarily, four-wheel brakes functioning with vacuum assist will stop a full-throttle vehicle. These events, however, were not 'ordinary.'
People make mistakes, intentionally or otherwise.
And that is a good reason not to have millions of people driving cars. It will be easier and faster to work out most of the bugs in a computer driven car, than to get everyone to drive error free.
If a person has a problem with issues, it affects them and maybe whoever they hit.
If the same software is installed in 50000 cars then the potential of 50000 wrecks where the driver did not have a way to correct the car.
This is actually more scary to me, because at least I have a chance of making corrections if the systems are analog or have analog backup.
I am a software developer, and this scares me.
I work in Alberta and I am a Software Developer. The problem is that having "Engineer" in your title hardly means anything. I worked with many Software Developers and many Software Engineers. Because of the law, the company I work for has to hire a number of Software Engineers. When I compare them side-by-side, I actually do not see any reason to believe that the Engineers in the room would yield better/safer code.
It's been tested under every condition imaginable. Brake power completely dominates engine power. The only situations in which brakes won't stop you is if you have no brake pad, your brakes are actually on fire, or you're in a fully-loaded heavy truck on a steep grade (and grades that steep usually have emergency pull-offs with steep uphill stopping ramps - you may have seen them).
Socialism: a lie told by totalitarians and believed by fools.
You can easily stop with no vacuum assist. It doesn't in any way change how effective the brakes are when firmly applied. It does however totally change how the brakes work and feel, and most drivers these days would have no idea what to do. It's not like we really train drivers after all. I drove a car with no power anything for years, and it's just a very different technique. However, if you stomp the pedal like you'll die if you don't, the car will stop.
Socialism: a lie told by totalitarians and believed by fools.
When did you start posting again?
You can definitely stop with no vacuum assist or any other kind of assist - brakes are really quite strong when firmly applied. You do have to be serious about it though (you can't wear away brake pads quickly, BTW, they'll actually catch fire first, though I'd easily believe they were past due for service in that crash).
Socialism: a lie told by totalitarians and believed by fools.
In what car? I don't know your FIL, so I'll assume he's dumb as a sack of doorknobs, but I'll believe Woz when he said his Prius has the problem on the highway. The brakes still work, however.
There are vastly more people who step on the gas instead of the brake while parked/parking, however, then claim the car malfunctioned.
Socialism: a lie told by totalitarians and believed by fools.
I could be wrong, but you must have had drum brakes. Drum brakes work fine without power assist, they are too sensitive with power assist (lots of surface area on the friction surfaces). I drove a 1970 Chevelle for many years with drum brakes and no power assist.
Disc brakes are another matter.
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
I've had the same problem - had to hook my foot under the gas pedal and lift it. But that's not at all the sort of problem we're talking about here - not a manufacturer's defect in throttle software (certainly not in my '69 240 Z).
Socialism: a lie told by totalitarians and believed by fools.
In Canada, the public is protected from such software bugs by statute, in the same way the public is protected from medical screw ups: a professional engineer is required by law to write any software code where safety is on the line
Bullshit. This is completely false.
Source: Canada imports most its cars. You really think Canada requires Japanese and German car companies to have all their code written in Canada by professional engineers registered with "PEO"?
Canada doesn't even have any car companies. Any such law is pointless if companies are just going to import stuff that was engineered outside the country.
Oh, well, as long as you say so.
- 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?
Don't blame this one on Microsoft. With MS, you have to press the "start" button, then select some drop-down box and select "power off" (or "restart", etc.).
They probably got this from the ATX computer standard. If you're old enough, you may remember that computers (back in the XT and AT days) had on-off power switches that did just that. You flip the lever up to turn it on, then flip it down to turn it off. Of course, this made it impossible for the computer to power itself off (or to power itself on with wake-on-LAN), so when the ATX standard came out, they switched to a front-panel on-off pushbutton: you press it once to turn it on, then press and hold for 3 seconds to turn it off.
Today's push-button-start cars have merely adopted the 20-year-old ATX computer standard. (And for all I know, the ATX people might have gotten it from somewhere else.)
There is really no way in which drum brakes are better than disk brakes (until you start hauling 40 tons of freight). A larger brake surface just means less pressure with the same force: it's a wash Larger brakes do mean less wear and fade, but drum brakes are so bad to begin with that you never come out ahead on that curve (again, unless we're talking heavy equipment).
The shortest stopping distance on a car (with a great driver) will be achieved with no power assist on disk brakes and no ABS. We all have ABS because the skill to stop aggressively without locking up the tires is so rare (and it's really quite hard with power brakes). But finesse isn't what we're talking about here - it's just that people are used to the brakes doing something near the top of the petal travel, not at the very bottom.
Socialism: a lie told by totalitarians and believed by fools.
I agree that drum brakes have their issues: fading, constant adjustment. But I can't agree with the rest of your arguments, based on my 41 years of driving experience and owning and working on over 20 vehicles: drum brakes, disc brakes, foreign and domestic (US).
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
pretty much true for the old Audi sudden acceleration thing. but with drive by wire.... the onus is therefore on the manufacturer/programmer to demonstrate the impossibility of such behavior.
Star Trek transporters are just 3d printers.
http://www.keacher.com/672/tit...
http://www.caranddriver.com/fe...
Or you could, you know, try it in a parking lot. My non-sporty brakes easily overpower my 420 HP engine.
Socialism: a lie told by totalitarians and believed by fools.
What in particular do you disagree with? There's a reason that sports cars led the conversion to disk from drum brakes, after all - they just work better. And it's well known that ABS increases stopping distance over the most skilled braking, but its advantage is so huge for unskilled braking that even most sports cars don't let you turn it off, for fear of lawsuits (and unpowered disk brakes give such great feedback, no mushy pedal can match it).
Socialism: a lie told by totalitarians and believed by fools.
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.
So it's best written in COBOL? (Which allows neither).
Sure... but the whole Engine Control Unit project wasnt limited to $100 ? ;)
I had an Audi and the problem was real. They later came out with a recall but my Audi at a stoplight idling started having the engine rev from 1000 to 3000 and back to while I was stopped at light with foot firmly on brake. Had someone been in front of me on sidewalk when it jumped forward until I pressed on brake harder it could have been a serious accident. It happened several times afterwards but never after they replaced an idle adjust part in the recall. So I understand people being startled but the problem was real.
I think you meant to say "conversion from drum to disk". I do agree that your ABS comment, the unskilled need it.
So I was unaware that racing used unboosted disk brakes, after some research they have to increase the mechanical advantage of the break pedal for that to work. What I was focused on was AS DESIGNED disk brake systems for passenger cars/trucks that must have the power boost. And this all comes back to Toyota's decision to not allow someone to easily turn off the engine when the controller has gone into the weeds.
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
The only difference between reverse, neutral and drive is which clutches in the transmission ECU determines need to be applied.
Automatic transmissions don't have selector forks like a manual transmission. They have a series of clutches that engage various parts of the planetary gears.
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."
My 1988 Caddy has done this 5 times. I've had all the throttle components replaced, but it happened the fifth time about a year ago. Repairguy guessed that the computer rebooted itself and left the throttle control in wide-open position and that there was no reason to believe that replacing the computer would solve the problem. So now I practice shifting to neutral and turning the engine off and back on, which means that it will never happen again. I'm OK with that. OTOH, if this problem occurs throughout the auto industry, we're pretty much all screwed and depend on luck to keep us alive.
Sitting at a stop sign with the car in "drive" is a driver error. His foot could slip off the brake and the car would move forwards, wither into traffic or into crossing pedestrians.
This is what we have things like neutral and handbrakes for. [...]
I know probably 90% of American drivers do this, but it's still not sensible or safe behaviour.
Well. Since we changed our car for one with a (for me unwanted) automatic transmission I also have this behavior...
Thanks to your post I'll try to change !
I should have said "Still smoking"- I'm pretty sure the brake pads *did* catch fire.
After hearing about that crash, my *normal* way of stopping became "shut off cruise control a block before I need to stop". But with this story, I am wondering about my methodology. Though, using the passive regenerative braking is great for my gas mileage.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Yeah, well, if you stomp the break pedal your car should realize you need to stop for the break.
How modern?
My 2002 GMC pickup which is in excellent shape certainly passes this test under normal conditions but if the engine vacuum is lost for whatever reason like the engine stalling, you get one or two pumps of the brake peddle before it becomes so stiff that braking is severely compromised. I found this out the hard way when stopped on a hill with the engine off and I had to push on the brakes hard enough to worry about breaking something (like the steering wheel being used to hold me down to push on the break pedal hard enough to do anything) to stop a gentle roll. Later I tested it by deliberately shutting the engine off while moving.
With older cars I have driven which also had vacuum assisted brakes, they were not nearly so sensitive to the loss of vacuum. I am inclined to think any difference is because of the addition of ABS.
On my 2002 GMC pickup, without vacuum assist you have to push down on the brake pedal so hard to get even a modicum of effect that you alarmingly bend the steering wheel while using it to hold yourself down.
Or you could, you know, try it in a parking lot. My non-sporty brakes easily overpower my 420 HP engine.
Didn't bother to reply to this at first, because why bother arguing with someone who isn't even listening to you. Unless you're suggesting that I drive at highway speeds in a parking lot.
Software tests are also capable of missing certain circumstances. Even 100% coverage doesn't make code bullet-proof. There are bugs that only occur due to circumstance, such as stack overflow or undefined behavior. Normal unit test might not expose latent bugs. Just read this.
The optimal dodge is to stop in a straight line, regardless of the location of the pedestrian.
Richard Petty is oft ac quoted for something similar when asked "how did you miss that car?" His response was "well, I just aimed my car straight at the spinning car". It generally still works well in any sort of auto racing, and also tends to work well even on the highway. If you can get your car to where a car starts to spin, it (being the spinning car) will tend to not be there, if you can get your car there, you'll tend to not wreck. It's not a 100%, but it works fairly wells.
Not trying to be argumentative, but assuming a situation where a new stop sign is installed. A non-auto car has clear right-of-way. An auto-car runs the stop sign (misreads the signs, doesn't have up-to-date) maps. A collision occurs. Which vehicle is at fault? Clearly the automatic vehicle, but who now foots the bills? Is it the manufacturer because they didn't update the maps? Is it the user, because they didn't pay $200 to update the maps? Is it the city/town because they changed the rules? Another reason I don't want a GPS navigated car: it usually takes 1/2 of my 3 mile driver home to get a GPS signal.
But, currently, we have a well established legal order to apply responsibility of damages in case of an accident.
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.
I disagree. The car also shouldn't kill me, or others.
Go watch a bunch of the russion dashcam footage on youtube. Tell me if the car that moved to "avoid" the other car would have had better results going straight? Most of the time, when someone "dodges" a car, they dodge into the empty space, the same space the other car is moving into. It's not scientific, but it is a consistent observation I've had. If both people aimed at the other car, it wouldn't work, but if one does and the other doesn't, it works great. At least with the spinning car, you know they aren't aiming at anything (aiming implies control).
Learn to love Alaska
Sorry, so even if an automated car was safer than most human drivers, you wouldn't want to allow them until what, there's zero possibility of them killing someone?
That's insane.
Let's not stir that bag of worms...
Coming from the aerospace industry, you cannot have software that has bugs.
Ideally, yes, but how do you propose to achieve that ideal?
I'm in the aerospace software industry too, and so far 57,000 defect reports have been generated in the program I work on.
My company's CEO recently informed us employees that we are going to start "executing flawlessly." "What a relief," I thought sarcastically. "Now we'll be able to shut down the database that documents those 57,000 defects."
Please enlighten us as to how your program achieved zero defects.
That that is is that that that that is not is not.
even the four-way hazards should trip the computer into resetting the throttle algorithm.
Whoa... lots of idiots turn on hazards while moving, in the middle of a highway. I saw this in Virginia during snowstorms.
Not saying it's right or good, it just happens a lot.
Holy Crap nardo don't come up to Canada and drive stay south of the friggin' border please! Suppose you are in a situation where you come around a corner and you have a white out crossing the road and you know there is a large 18 wheeler only 300-400 yards behind you. When you hit the white out on the corner you need to slow down to squat mph to see where the hell you are going and your tail lights will dissappear. WHAT SHOULD YOU DO? ONE: immediately hit the ditch, TWO: Stop in the middle of the road and get out to see where the ditch is. THREE: Speed up lose control as your wheels hit the ditch and flip your car and kill your wife and kids. FOUR: Slow down, carefully watch for the sholder of the road and increase the luminosity of your tail lights by pumping the brake lights to warn the semi. FIVE: Slow down, watch the edge of the road carefully and turn on your flashers to warn the semi that you have slowed down due to visibility difficulties.
Chances are if you are a moron who is not accustomed to driving according to the conditions you will just wind up going in the ditch at 70 miles an hour, or worse getting rear ended by the semi!
This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call
The point was, in context, the car should not be allowed to into conditions it's not proven to be able to handle; if it is sent into those conditions, fails and kills someone, who is liable?
People making the cars aren't omniscient, you're not going to be able to predict every situation (especially while there's still human drivers), and the physical parts are always going to be fallible. Automated cars will kill people, and we'll probably never get to the point where they won't.
In the meantime, they could very likely kill less people than humans. And you would rather not do that because of, what, it'll be awkward to assign liability?
Sorry, but that makes you a psychopath.
Again, the reasonable test is whether they do better than human drivers.