Slashdot Mirror
Stack Overflow Could Explain Toyota Vehicles' Unintended Acceleration
New submitter robertchin writes "Michael Barr recently testified in the Bookout v. Toyota Motor Corp lawsuit that the likely cause of unintentional acceleration in the Toyota Camry may have been caused by a stack overflow. Due to recursion overwriting critical data past the end of the stack and into the real time operating system memory area, the throttle was left in an open state and the process that controlled the throttle was terminated. How can users protect themselves from sometimes life endangering software bugs?"
Is there anything Stackoverflow can't do?
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
..."We'll I'm sure somebody on there could!"
.
Prisencolinensinainciusol. Ol Rait!
"How can users protect themselves from sometimes life endangering software bugs?"
Amish buggies typically don't have software throttle failures. Run-away horses can be an issue.... and actually having to share the road with dipshit drivers who don't understand the number of slow moving vehicles (not just buggies) that there are out in farm country are a real danger.
Seriously, software has bugs. Mecanical throttle linkages can stick, too. Life has risks.
How would a mandatory publication of all code as open source [not suggesting liberal licensing here] work out here? Might converge at a collaborative initiative and will most likely be reviewed by all sort of people.
Support Eachother, Copy Dutch Property!
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 !
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"
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.
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
> You could be mauled by a bear when you press the accelerator.
But only if you've purchased the "mauled by a bear" feature and have forgotten to put the "bear" switch in the "off" position before putting the car in gear.
I thought everyone knew that.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Not using recursion in constrained embedded systems is a good start. It's been best practice since I started working with them 15 years ago.
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!)
Recursion is fine if recursion is fine if recursion is fine if recursion is fine if recursion is fine if you do it right.
Seven puppies were harmed during the making of this post.
... you know... i worked for pi technology in milton, cambridge, in 1993. they're a good company. they write automotive control systems, engine control management software, vehicle monitoring software and diagnosis systems and so on. one of the things i learned was that coding standards for mission-critical systems such as engine control have to be very very specific and very very strict. the core rules were simple:
1) absolutely no recursion. it could lead to stack overflows.
2) absolutely no local variables. it could lead to stack overflows.
3) absolutely no use of of malloc or free. it could lead to stack overflows.
now you're telling me that there are actually car manufacturers that cannot be bothered to follow even the simplest and most obvious of safety rules for development of mission-critical software, on which peoples' lives depend? that's so basic that to not adhere to those blindingly-obvious rules sounds very much like criminal negligence.
I have just finished my patent application for the steering wheel mounted Ctrl, Alt, Delete button combination...
Problem solved!**
**Some users may experience complete lack of vehicle control while the system is rebooting.
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
For anyone else that's curious; at first I thought it was double speak, so not to sound as bad.
Stack overflow refers specifically to the case when the execution stack grows beyond the memory that is reserved for it. For example, if you call a function which recursively calls itself without termination, you will cause a stack overflow as each function call creates a new stack frame and the stack will eventually consume more memory than is reserved for it.
Buffer overflow refers to any case in which a program writes beyond the end of the memory allocated for any buffer (including on the heap, not just on the stack). For example, if you write past the end of an array allocated from the heap, you've caused a buffer overflow.
http://stackoverflow.com/quest...
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?
Yo dawg...
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Recursion is lazy, stupid, and above all, DANGEROUS.
Only in the hands of a novice..
It is an elegant solution for certain kinds of problems that can work magic in the hands of one who has mastered the technique. But when applied to the wrong problem, it's what you describe.
As in all things, the right tool for the job is always best. Masters of the trade know their tools well.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
All cases have been unrepeatable
Stack overflows tend to be difficult to reproduce.
Finally! A year of moderation! Ready for 2019?
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.
From the slides:
"Toyota used dangerous recursion"
Not like that safe recursion that other vendors use.
I've known a lot of high-quality developers over my 15 years of professionally developing software. The reason I don't want an automated car is because of these people. People make mistakes, intentionally or otherwise.
When it comes to true high-rel software, like that written to DO-178B Level A (an avionics software standard used for things like fly-by-wire) it's almost never the software per se that's at fault. The stuff is amazingly good. It's also amazingly expensive to write and test. You might also find it frustrating because it brings new meaning to the idea of conservative design. For example, I don't think it allows recursion. I know it doesn't allow dynamic allocation.
There are unforeseen circumstances that the software may not understand.
That's more the point. When things like fly-by-wire systems have problems, it's almost never the software itself, but something that was unforeseen by the system designers.
A foreseen circumstance: I've yet to see a demo of an automated car navigating anything resembling an icy surface (safely or otherwise), let alone in stop & go traffic in a city such as Chicago, where such things are quite common.
Agreed. This technology is interesting, but it's way over-hyped. It's impressive to be able to drive on a nice clear day, but a far cry from the real world, even in Silicon Valley, let alone Chicago.
Ever hear of the flying cars that in the 1960's they said we'd all have soon? I haven't seen any lately. I suspect driverless cars robust enough not to require human intervention when the going gets tough may be developed on the same schedule.
Wrong. I've personally had it happen to me in a '85 Hyundai. The vehicle was relatively new at the time, and had a manual transmission. After tapping the throttle to try to unstick it, I flipped the ignition and stopped the car. Once completely stopped, I restarted, and with my foot on the clutch watched at the tach approached redline until I shut it down again. I was eventually able to get it going again, and headed straight to the dealership. They found nothing, and it never reoccurred.
Yes, I'm well aware that people can hit the wrong pedal...there's no way I did that twice. I believe in my case, the throttle got stuck when I had floored it..those vehicles had very little acceleration.
Just another day in Paradise
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.
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.
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.
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."
shut up jackass. my father-in-law was nearly killed by one of these impossible events.
"They said I probly shouldn't fly with just one eye," "I am Bender. Please insert girder."
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.
MISRA C, which is a mandatory coding standard across pretty much all the automotive industry, does outlaw recursion. So I find this speculation on the cause to be very unlikely, and is just lawyers bringing in "software experts" to speculate. If you want to speculate, there are many other potential software bug causes as well. Some of them would even pass MISRA C coding checks, and not be easily detectable by static analysis.
Masters of the trade know their tools well.
Which is why designers of hi-rel systems never use recursion.
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.
Self proclaimed masters of the trade have no place in safety critical software systems. Can you guarantee that the coder who will be maintaining your code 10 years from now will also be a "master of the trade"?
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.
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.
They didn't speculate. They analysed the source code, which they had clean-room access to, as well as the actual compiler and test harness used by Toyota. Toyota testified that the stack utilisation was 41%, whereas the analysis showed that it was actually 97% *before* the recursion was taken into account. It looks pretty certain that stack overflow could occur. Following the stack are key system structures used to control the scheduling of threads on the CPU, and damage to these structures could cause one or more of the threads to never get any scheduled time. One of the threaded tasks not only controls the throttle, but also the failsafes in case of some scenarios,and also the code that writes fault codes to the battery-backed RAM. Basically, if that task dies, then the throttle is left uncontrolled, the failsafes don't kick in, and no fault codes are written so that the problem is revealed after the fact. It's a terrible design; a disaster waiting to happen.
Uses can protect themselves against this sort of thing by not buying a Toyota until they are compliant with the relevant standards. Only hurting them in the marketplace will get them to fix this problem.
The testimony from both expert witnesses Barr and Koopman are now a matter of the public record and actually make fascinating reading - they'll be especially interesting to computer guys because it goes into a lot of detail about the code design, though frequently translated for the benefit of the court into layman's language. It's going to go down in history I reckon as a classic case of how not to design a safety-critical system.
A great summary and links to the public court documents can be found here: http://www.safetyresearch.net/2013/11/07/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/
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.
I think you could make the case that tail recursion is safe in that it doesn't result in an unbounded stack. You'd really need the toolchain enforcing it though.
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.
why is recursion so bad? it looks like any other code construct to me.
Wealth is the gift that keeps on giving.
Simple, with a car make sure it has a throttle cable and a clutch peddle.
I know I can hear it now, you can't buy a car with a throttle cable and you can't drive standard in a city.
If everyone stopped buying cars with throttle by wire, they would stop making them. The rest of the world drives standard in a city, you can too.
Star Trek, there maybe hope.
Maybe not quite as bad as the Therac but definitely should be taught in engineering school.
>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.
There were actually two visible skid marks. One track from normal braking and another from pulling up the emergency brake.
It wasn't enough.
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.
I know that sometimes its difficult to admit that someone you know well may have made such a stupid mistake, but the probability of your father-in-law being confused/mistaken is a lot more than entire teams of engineers at the world's largest car manufacturer fucking up in such a dangerous manner.
Wealth is the gift that keeps on giving.
Because verifying maximum recursion depth is quite a bit more complex compared to verifying a whole bunch of other constraints
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.
Scala's @tailrec annotation, for example, emits a compiler error if it can't perform TCO.
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
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.
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...
Because its very easy to overflow the stack? Embedded systems tend to have a limited stack space too.
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...
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.
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.
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.
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.
In what car?! All modern mainstream vehicles still use a master cylinder in tandem with a booster and ABS. Even if you lose all engine power, should still be able to apply the brakes. Although it will require more force to push the pedal down, it should still be doable to bring the car to a complete safe stop.
If only the throttle was also required to have a physical linkage!
Unfortunately, once we abandoned the carburetor, there isn't much to link the throttle pedal to any more, and we are stuck with using it pretty like as a mouse. A physical pedal up fuel valve to reduce fuel availability to a level sufficient only to idle the engine might return some measure of physical control. Currently most manufacturers have the computer cut throttle when the brake is pressed, even if the gas is also pressed. (Toyota did not have this during their problem years and added it later). This has the side effect of teaching those idiots who drive an automatic with the left foot riding the brake not to do so. Unfortunately, this functionality is programmed into the same computer, (saving $37), and if that computer has entered stack overflow, it won't help.
But the interesting thing here is that Barr found a situation that (he claims) could in fact cause the engine to receive full throttle, when DOT and NASA could find no such problem and blamed it all on the driver confusing the pedals.
Even if the brakes would have stopped the car (eventually), after applying them fairly firmly for a while (for some values of "while") the car can experience rather sever brake fade. Anyone driving in the mountains has probably experienced this.
Without brake fade, Car and Driver found that from 100mph and up, the braking distance increased three fold, enough to convince the driver that the car was never going to stop. If this occurred after a long downhill, (hot brakes and plenty of fade) and the driver wasn't fully committed to hard panic braking, it seems plausible that a stuck accelerator pedal, or stack overflow, or floor mats, could extend braking distances enough to be deadly. When tested afterwards, the brakes would have appeared to be working again.
If you disallow all of these possibilities you are forced to assume that anyone reporting any unintended acceleration is a total idiot, which, given small the number of events, isn't completely out of the question, but the fact that almost all of these idiots tend to be driving a Toyota is suspicious.
After all, idiocy does not usually manifest itself by a predilection toward a certain brand of car.
Sig Battery depleted. Reverting to safe mode.
It depends on if the ABS and/or brake servo is influenced by the bug and makes it harder to apply the brakes.
Be aware that most brake servos are using the manifold vacuum to increase the brake force. If the engine gets full throttle the vacuum is soon depleted and a much larger force on the pedal is needed which will be experienced as failing brakes.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
You can use recursion if you have something that terminates it.
A stack overflow detection should definitely have been in place causing a termination/restart of that thread/process.
However this highlights that many ECUs in cars today are built by "embedded standards" where there are weak protections between processes because they use proprietary operating systems that seldom sees the extremes but instead relies on "nice" programmers following the "rules".
The main issue is anyway that the car industry today tries to save a cent on hardware and add a large load on development. Most notably is that many ECUs in cars today aren't able to do floating point calculations in hardware - they require software workarounds one way or another because a processor capable of floating point operations costs more.
The ISO 26262 standard will put more demand on the vehicle industry when it comes to software quality.
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?
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!!!
stack overflows kill people.
Stack overflows don't kill people, sudden deceleration does!
>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.
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.
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
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
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.
Cheap india outsourced embedded software specialists beg to differs.
Welcome to the marvelous world of Minimal Cost Driven Development (MCDD).
Stupidity is the root of all evil.
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.
Sorry, recursion is very useful. The non-recursive version is often far more complex, and therefore more bug prone.
That's very poor architecture. Why don't they use protected memory OS/CPU that isolates OS and app? A $100 smartphone has these features, why doesn't a car worth over $20,000 have it?
And because a software error or "bit error" can cause the software to be stuck in the recursion, in an infinite loop. Even when software errors don't exist, "bit flips" due to electrical transients or even due to cosmic radiation are inevitable due to the quite small transistor size in modern processors. And cars are electrically quite noisy environments, so a certain amount of "bit flip" should be expected as normal for any such system.
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).
Because it has the potential to overflow the stack. It's not the only thing that should be forbidden; exception-handling is another one, as is dynamic allocation, and also CPU caches. If you're using any of these things in a mission-critical embedded system, you're doing it wrong.
Why did he take his foot off the brake?
Because he put the car in neutral?
Oh wait...
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
Very interesting. So why is Toyota not following MISRA C coding standards?
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 recursion they seem to be taking about is loops with no fixed limit, e.g. a while loop with a test condition to exit. In theory such a loop could execute indefinitely, so the usual approach is to have some kind of watchdog. I believe Toyota use an embedded OS to prevent tasks hanging that way (probably ITRON, can't remember now).
The problem is that no actual evidence of these flaws has been provided. No code samples. We can't check the analysis.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
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.
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
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.
As far as I remember, MISRA C rules forbid any kind of recursion.
They want their coders back..
---- Booth was a patriot ----
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."
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.
@(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.
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.
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
According to TFA, the OS is multitasking with the OS stack sharing the user stack. The proof of the maximum stack depth that the developers gave was wrong.
Finally! A year of moderation! Ready for 2019?
You mean like https://programmers.stackexcha... ?
They close out "good" questions there too (examples)... came across one the other day (while programming), in fact. It's like the wikipedia notability police all over again. :O
-1, Too Many Layers Of Abstraction
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.
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.
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.
There was no speculation involved. An expert witness (a team of embedded platform engineers) analysed the source code.
Not only did Toyota not follow MISRA C, they didn't even follow their own coding standards. Reading the source code showed recursion was being used and Toyota's own internal standards were not being followed (let alone MISRA C). An 800 page report was produced. If you dig into TFA a bit you can see the 45-odd page presentation that the expert witness gave to the course. The TLDR version of that presentation is that Toyota was grossly negligent in the way they developed this system.
Oolite: Elite-like game. For Mac, Linux and Windows
Sure... but the whole Engine Control Unit project wasnt limited to $100 ? ;)
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."
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?