Slashdot Mirror
Toyota's Killer Firmware
New submitter Smerta writes "On Thursday, a jury verdict found Toyota's ECU firmware defective, holding it responsible for a crash in which a passenger was killed and the driver injured. What's significant about this is that it's the first time a jury heard about software defects uncovered by a plaintiff's expert witnesses. A summary of the defects discussed at trial is interesting reading, as well the transcript of court testimony. 'Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.' Anyone wonder what the impact will be on self-driving cars?"
I'm convinced. I'll give up my career as a computer programmer now, and go use my bare hands for subsistence farming now. Sorry, I was wrong.
Those working on self-driving cars and those that are watching the technology already know that any such car would need an absolutely 100% rock solid OS.
This changes nothing.
The owner of a self-driving car will have had to accepted the EULA and accepted not to hold the manufacturer liable for sofware defects. (half joking but I wouldn't rule it out)
Sure, they will be more safe. Just like in the aviation industry, where each incident/crash is investigated meticulously, and flying has become safer ever since 1903. With non-selfdriving cars 99% of the incidents were caused by human error. Now no more, so we can fix it!
2nd link, 5th paragraph:
Anyone wonder what the impact will be on self-driving cars?
A longer chapter on debugging in the first edition of "Programming Self-Driving Cars: The Missing Manual."
Brought to you by Carl's Junior.
> "and missed RTOS use during task switching"
IRQs will piggyback atop the main stack. Since control does not devolve back to that thread until the IRQ finishes, this is perfectly fine. However you have to consider IRQ's worst-case use atop your thread's worst-case.
We don't use an OS so OS stack use isn't an issue. Obscured recursion as chains of functions call each other in hidden ways is something to consider.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
If there's no human fall back or ability to overthrow the computer's control of the car I'll never drive it. I don't think this will change anything except maybe give the people that are rushing for self-driving cars some pause. Every developer knows the risks of self-driving computer controlled cars (if they don't, well they're naive). Between human error in programming and human maliciousness, there are two camps. People who think they can overcome the possibilities of putting a semicolon in the wrong place and prevent hackers from comprising the software's integrity. And people who realize the first people are fooling themselves.
Google claims their cars are safer than most human drivers.
Would you trust Google on that?
No, I would examine actual real-world test data. I would also require some type of regulatory oversight/approval process similar to what exists for physical components.
In the case of Google's claim, they're backing it up with solid data, not just saying "Hey guys, trust us." Also note they are not claiming they're ready to actually begin deploying such cars to consumers.
Like, literally. Don't flash those custom firmwares onto your cars, kiddies. Unless you want to be on the BLEEDING EDGE.
Your post demonstrates a complete lack of understanding of what JIT manufacturing (i.e. lean) is and what it tries to accomplish. Hint: it's not about doing more with less. Further, you either willingly fail to mention Kaizen (continuous improvement) or just aren't aware that THIS is the heart and soul of the true Toyota Way.
Whatever the reasons they failed in software engineering, neither JIT nor Kaizen would be to blame because neither of those try to nor should they translate to "engineer badly".
Still happy that my car (not a Toyota) has a stick and thus a mechanical clutch pedal :)
On the other hand, doesn't automatic gearboxes have neutral setting? Wouldn't moving into this be roughly the same as depressing the clutch on a manual gearbox? Of course, the reaction times are longer (since you have to do something unusual when driving an automatic, i.e. touching the shifter while in motion), but for the cases you hear of where they managed to call 911 while figthing to control the vehicle...
That someone hold programmers liable....
If it can cost you big bucks, you test it more.
'Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.'
Huh? I'm a software engineer and don't understand the relevance of this statement, how can a jury? How does it confirm that there was a defect?
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
Remember when Toyota and DOT concluded the problem was driver error and improperly fitted floor mats?
Good; hold the hacks accountable. This is a great first step. Hold the companies deploying this crap accountable. The next step is to go after the hack developers who write this trash.
The lamest, hackiest, most shameful industry known to mankind where the product is nearly guaranteed to be defective is yep, you guessed it: software development.
So, the brakes cannot override the engine power, since when? The ignition key would be rendered inoperable? The emergency brake would not work? The transmission would lock in gear? No effing way.
So you are driving a really *old* car eh? No?
Or perhaps you have rigged up a "master reset" line for each and every controller in your car? ABS, ECU, PCU, Air Bag controller, Security AND entertainment systems? No?
Then I'm throwing the BS flag or you don't understand what you are saying (or both.)
This is one of those scenarios where the cultural fascination with the concept is going to push it into practice before it's really ready...if it ever is. Open terrain autonomy is not an easily solvable problem as it relies more on contextual awareness via multiple mediums rather than raw reaction time. Humans are still far better at this than any computer. The fact that toyota, likely the most safety conscious car manufacturer in the world, could not account for all possible behaviors of their code in a relatively simple computer system speaks volumes about how far away we really are from safe autonomous, free range robots. On the road, drunk drivers and idiot soccer moms with cellphones are a lot easier to spot and avoid unlike the way out of box behavior caused by subtle programming bugs in complex hardware. Maybe the day will come, but it certainly won't be here by 2020. For now, I'd rather share the road with humans who get it right most of the time, than with (or be driven by) computers having only the tiniest fraction of the situational awareness.
10,000,000 accidents per year in the US alone.
http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html
I can just see the headlines. "Self driving cars cause hundreds of thousands of accidents per year!"
Even though that'd be ~1% of what humans do.
There are two types of people in the world: Those who crave closure
"If there's no human fall back or ability to overthrow the computer's control of the car I'll never drive it."
by definition you wouldn't be driving it.
The Kruger Dunning explains most post on
Half of the cars I've had didn't come with ABS, ECU, airbag, security. They all did come with car radio/cassette player.
- Raynet --> .
Trust? No, I'd want to see test results. Believe that it's possible? Hell yes.
You mean humans, who get it wrong 10 million times a year in the USA alone?
10M accidents out of 250M drivers isn't a very good error rate.
Car makers can and have been sued for defective mechanical designs many times. Now they're getting sued for defective and dangerous software and computer hardware designs. I don't think there's much of a difference between the two when it comes down to it. You were either negligent or not, and whether it's software, hardware, or mechanical stuff doesn't really matter.
Good lord, they have got to be kidding? If Toyota (or their parts suppliers) are making those kinds of errors, you can bet your ass that other manufacturers will be making them as well.
There needs to be very strict set standards for car control systems. We have standards for OBD, so why not strict, over engineered and thoroughily coded critical systems standards? Even better, why not make them open standards, including the hardware?
Standardising would make parts cheaper as well as stopping manufacturers from building closed black box units that may be of dubious quality. It would also make it easier to maintain and repair modern cars as they get older, and allow third parties to provide new hardware long after the manufacturer loses interest.
As an aside, I do wonder what we're going to do in ten years time when the failure rate for most of the control hardware starts creeping up. Would they fail safely? Would the repair cost be prohibitive?
It would be a sad irony if these environmentally conscious efficiency improving measures resulted in cars being scrapped en masse because the ECU that superseded a $10 throttle cable costs a grand.
Kaizen (continuous improvement) or just aren't aware that THIS is the heart and soul of the true Toyota Way.
The other thing that is the heart and sole of the Toyota way is a constant drumbeat of how safe their cars are over the background of failing brakes, stuck accelerators, forced recalls. The more trouble they are in, the louder they scream safety.
Sig Battery depleted. Reverting to safe mode.
It is exactly about doing more with less in the factories I've been in, which is more than half a dozen. Those poor people don't have time to think about anything. They just jam blanks in the machines and hit the cycle start button as fast as they can go.
I'm unsure how you're attempt to paint me as a hypocrite would ever be successful. Economic pressures essentially force me to buy new cars that have computerized control systems. For instance I don't pay as much for car insurance because the newer cars are (in general) deemed safer. That's not to say I try to cut back on certain features where possible. Such as not getting the remote key-less entry and ignition systems installed on my car. If you read the second linked article you'll notice mentions of interrupts that can be done by the human to prevent improper function or restore proper function of the vehicle. In this case (Toyoto), the human interrupts were sent to single points of failure or were inadequate to prevent catastrophe.
Intellectual Innovations is busily patenting CAPTCHAs on highways.
Lol, you're right. I guess drive should change to ride.
Its ready NOW. The tech is ready, the people are ready, the politicians and business is NOT ready. We have an incredible fuck-ton of social bullshit to slog through before we will get truly viable, awesome autonomous transport. WE could convert all the carpool lanes into autonomous only tomorrow, wall it off from normal traffic with a barrier and those cars could easily go 100 MPH with incredible safety. Politics and social change will take far longer then the tech will to fully mature.
Good-bye
All personal cars will have self-drive fallback, but there will be roads that wont allow you to self-drive on them. Eventually you will only be able to self-drive on a track or in emergencies (which are logged).
Good-bye
Actually, there is absolutely zero proof that they did fail.
NASA certain could not find any way to fault the system.
What this decision is based around is a bunch of technical argument that they could have tried harder to prove
that the system could not fail, but with absolutely zero proof that it does or even can fail. No procedure to make
the software fail was presented, no theory of a set of inputs that could result in the theorised output was presented,
only a critique of their testing and analysis procedure that poked a few holes in that.
This is a VERY concerning direction for programmers in the USA, as of course complex software by definition cannot
be proven correct (at least there currently exists no known way). It opens the door for all sorts of development-process
based litigation, which is a very very bad direction for things to take.
Again, so far ZERO evidence, proof, or test case has been provided that the software is in any way responsible for this
problem.
I wonder when the first lawsuit will be filed on behalf of someone who died while trying to
buy medical insurance on the government web site. Will this set the precedent that the
government is responsible for bugs in the government web site ?
Let me regal you of a story of my friend.
4 car pileup. 1st car slammed breaks (they almost missed their turn) next two hit the breaks in time.
Just at the right moment my friend sneezed.
4 car pileup. Lucky it was at low enough speed no one was hurt.
Out of the millions of miles driven by autonomous cars at this point. There have been very few accidents. Of those all were caused by other drivers.
The reaction time of a computer is near instant. My reaction time is 2-5 seconds depending on time of day and what I ate earlier. ( you do follow the 2-3 second rule right and know why its there?)
On the road, drunk drivers and idiot soccer moms with cellphones are a lot easier to spot
yeah usually about when they are ready to hit me.
Certainly I'd want an autopilot toggle switch - principally so I could drive it for pleasure or in unexpected / offroad ways. As far as safety is concerned I suspect that the headlines where "human disables malfunctioning/compromised autopilot, saves life" would be dwarfed by those where "human confused by crash avoidance strategy disables autopilot and causes horrible crash"
As for security, it's not *that* hard. Just disable all wireless communication for starters. Once someone has physical access to the car all bets are off anyway, people were cutting brake lines long before anyone ever heard of a buffer overflow attack.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
The only thing you've mentioned that controls the car is the ABS (and traction control). With the absence of a drive-by wire system, there is a physical link to the throttle the ECU can't override. All it can do is control the idle valve, which has physical limits as to how much air can pass.
Electric power steering may pose a problem, but that's only recently coming in to new cars.
Also old school cruise control that has an actuator that moves the gas pedal.
It's an ECU, not a desktop. All those latencies you're used to are OK when you're browsing the internet or programming the Next Big Thing, but they are not acceptable when you're adjusting fuel ratios, timing detonations, responding to impact sensors etc.
You clearly have no idea what you're on about, or why real-time operating systems are real things that have actual niche use.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
On a societal level that makes sense. If a software bug crashes your car and you're paralyzed, it's little comfor to be told you might have crashed yourself.
If you're a good driver, a firmware bug that crashes your car is a BIG problem. The fact that other people avoided accidents because the software is better than a human isn't exactly relevant.
While it's true that "You cannot possibly code for every driving scenario, even with collision avoidance systems.", you need to remember that neither do people. So saying the car is a safer driver than most people doesn't require perfection. Avoiding liability suits, however, may.
I think we've pushed this "anyone can grow up to be president" thing too far.
On the other hand, doesn't automatic gearboxes have neutral setting? Wouldn't moving into this be roughly the same as depressing the clutch on a manual gearbox?
For years, some cars have not had mechanical linkages to the automatic transmission; the shifter is just a human interface that plugs into a wire. This started in the luxury market and has wound its way down. Interfaces include joysticks resembling shifters, rotary dials, and push buttons.
The slide has been away from direct mechanical control of various car components for a while. It started with throttles, then it went to brakes (yep...) and now even some steering systems are going to steer-by-wire. Same for push-button ignition control systems. It's pretty horrifying.
Still, plenty of "runaway" cases have involved vehicles with mechanical ignition keys, mechanical transmissions, and mechanical throttles. People are just stupid, uneducated (they think that if they shift out of Drive the car will explode, ditto for shutting off the ignition...poor braking technique, like trying to "ride" the brakes to reduce speed, instead of braking HARD to STOP the car immediately) or get caught speeding and try to use it as an excuse to get out of it.
Please help metamoderate.
I would rather have drive by wire in my car.
In the case of Google's claim, they're backing it up with solid data
Do you have a link to that? Seriously, no snark. All I've seen is hype, but I can't say I've read everything they've published.
What about testing in rain or snow, especially falling snow? Unmapped roads? Heavy pedestrian traffic? Do what extent is their safety record accounted for by the fact that the drivers know when the autonomous mode is likely to get into trouble, and shut it off before that happens?
That there is some theoretical person who can out-perform them doesn't mean they aren't a net benefit (including those who can outperform them). ABS was mandated, despite many people being able to out-perform early versions and even a number of later versions.
I disabled my ABS for a while until Subaru performed a "service bulletin" (voluntary recall in "it's not a recall" language). It was so unknown by dealers, that I called in to make my appointment, gave the bulletin number, and dropped my car off without issue, then they called 6 hours later to state they were unaware of such a bulletin. I came back in with the letter from Subaru, and 2 days later they acknowledged it exists. Weeks later (after they ordered parts), I got the ECU replacement. I used my ABS after that. Before the "non-safety related issue" I'd roll through stop signs and red lights if I was braking hard and hit a pot hole (the ABS would read that as a loss of traction, and disable the brakes until traction was registered as regained, which was 30+ feet). The fix was much better.
Learn to love Alaska
I can agree with you for the most part. But I don't think there's a trend there that would cut wireless. Just look at OnStar and its ability to cut off your engine. The trend in technology right now seems to be, make everything wireless and connected. From TVs to fridges, I don't quite expect cars to be any different. In fact, wasn't it a few years back that Ford (or some other make) was offering cars that had the ability to be mobile hot spots?
Its ready NOW.
How do you come to that conclusion? Not even Google says it's ready NOW.
... well NOW you know why (not only) the automotive industry try's to encrypt, lock and proprearitize anything...
"If it cant shoot down 100% of missles, then it is useless". So dont build it.
In real life, Isrealiis discovered that 90% effectiveness is a game-changer. There "Iron Dome" anti-missle defense is that accurate. People dont run to the bomb shelters every siren now. Nor do the enmenies attack that often, knowing most will be wasted. At some degree of accuracy people accept "good enough".
Then they were too new. I had a car that pre-dated tape decks (it had an optional 8-track player, but my car was no so equipped).
Learn to love Alaska
Most of these Toyoda "problems" were caused by people with their foot on the wrong peddle. Those probably didn't make it to court, but you still hear big inflated numbers due to them.
Its ready NOW. The tech is ready, the people are ready, the politicians and business is NOT ready.
I doubt it. The tech may be ready, the people implementing that tech are certainly not ready.
About 30% of my searches on Google return a "You searched for A, did you mean B" result. In about half of those instances, I actually get "You searched for A, here are the results for B." So with a Google car, I'm more likely to arrive at the destination safely, but about 15% of the time it will not be the destination I requested, but some other location based on some SW engineer assuming I don't know where I want to go.
I have a couple podcasts I save up for when I travel. In some cases I have months of episodes queued up for a long trip. A couple years ago iTunes started silently unsubscribing those podcasts. I guess the assumption is anything I don't listen to often is something I'll never listen to again. Recently it's even done that for podcasts I listen to weekly and don't store many back episodes. So with an Apple iCar, I'm more likely to arrive at the destination safely, but only at destinations anticipated by the engineers at Apple. And one day I'll try to visit my mother, and the display in the iCar will say it's been so long since I visited, the car assumed she was dead and deleted her address and route to her house.
I don't doubt the tech, I question the people the behind the tech. The reason Google returns results for something other than what I searched for isn't a technical issue. The reason iTunes seemingly randomly unsubscribes me from podcasts is not a technical issue.
For Google, I love the "did you mean B" options when I search for A. But give me the choice to search for B, don't just return results for B. For iTunes, I'm fine with a dialog box, "You haven't played this podcast for a while, still want to subscribe," but don't just silently unsubscribe, especially if it's going to happen for podcasts I do listen to often.
I'd be happy with a car OS that kills less than 30,000 people per year.
If a car manufacturing defect kills anybody at all, then there should be manufacturer's liability for it.
They don't get a free pass just because of the kind of manufacturing defect, there's no privilege against liability just because it's a software defect.
-wb-
"..over 11,000 global variables.." Should this make for the biggest dailywtf?? In an ECU????
Its shocking how you conflate these ideas. the engineering principles that go into serving up itunes is VASTLY different then making autonomous vehicle code. THe people who work on autonomous cars have very different backgrounds and degrees then those that design music websites. No one cares if you lose a podcast, its not anywhere near the scrutiny machine code gets.
"About 30% of my searches on Google return a "You searched for A, did you mean B" result. In about half of those instances, I actually get "You searched for A, here are the results for B." So with a Google car, I'm more likely to arrive at the destination safely, but about 15% of the time it will not be the destination I requested, but some other location based on some SW engineer assuming I don't know where I want to go."
If you fail to human verify your results before embarking, that is your own fault. Searching for information is a negotiation, the more precise data you put in, the more favorable your results will be. You cant be a moron and expect it to do everything. The only problem you described is that you cant accurately communicate to the system your intentions.
Good-bye
Sure, but you can't run an engine with a pre-emptive multi-tasking OS.
You need accurate timing in the sub-millisecond range.
I've love to see Linux controlling ignition and fuel delivery to an engine revving at 9000rpm.
Even a 4cyl engine at that speed needs accurately timed ignition pulses at 300 times per second.
To get ignition timing to 0.1 degrees at 9000rpm, that's 1.85 microseconds. About 900 clock cycles at 500MHz. Twice per second for 4cyl.
There is a point where a real-time OS is a requirement.
There was a time after automated elevators first came out when people refused to use them because they didn't trust them without a "human fall back or ability to overthrow the computer's control". Today, when nearly all the elevators we've ever seen were automated, this seems crazy.
In 50 years, when most people have never seen a manually operated car, we'll seem just as crazy for not trusting them.
Anyone wonder what the impact will be on self-driving cars?
In soviet Russia, self-driving cars impact you!
Yes, but you only need to solve it ones. And every year it gets better.
The Kruger Dunning explains most post on
Well, this software was proven incorrect by the Barr Group.
This is a very good thing for software engineering in the USA, because the newly required level of professionalism means we will no longer be able to get away with shoddy work, and it means outsourcing will be the first to go.
Toyota have really lost the plot in the last few years. This isn't just a JiT issue.
My Toyota wasn't starting correctly, so I took it to Toyota. I told them the lights remained on when trying to start the car, but it would struggle to turn over. So ... they sold me new starter leads and a new battery (about $400 in total).
I asked a few friends who work with cars who said "you've been bullshitted - if your battery or starter leads don't work, the headlights won't stay on. With a car of your age - it's almost certainly the starter motor, and probably one of the brushes". EVERYONE, except Toyota, told me this.
I went back to Toyota with the continued fault and asked why they had done what they did. They said that the fault could not be reproduced, and that it was very unlikely to be the starter motor, but told me they'd "fix it". They even put in writing that it was "... impossible to diagnose the fault without replacing those parts ..." (ie. their service centre doesn't have test leads or batteries - they had to sell them to me first).
I contacted Toyota Head Office who told me the same message, it is not common for a 15 year old Toyota to have starter motor problems. The dickheads even put it in writing.
Every mechanic I have now spoken to (and I mean every mechanic) said that Toyota were lying through their teeth.
Needless to say, I took the car to someone competent and it turned out to be the starter motor - and a stuck brush. It cost me about $50 to be fixed. That was a year ago.
Totoya are complete pricks, who have no customer loyalty and lie through their teeth. This is not the Toyota I knew from a few years ago. This is a company that's going to the dogs.
I won't buy a Toyota again.
I'm feeling really positive about Google robotic cars driving themselves ...
Positive they'll be sued when they kill people, that is.
Especially kids. People don't care what your excuse is for that.
-- Tigger warning: This post may contain tiggers! --
Chris Urmson presented some data at this keynote, but AFAIK nothing has been published yet. Basically they showed that they stop and start more smoothly and spend less time in near-accident situations then even their professional drivers. They've logged over 300k vehicle miles with zero Google caused accidents, meanwhile MARTA has a target accident rate of 2.85 accidents per 100k miles, and wasn't able to achieve that in most of the previous 12 months!
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Those working on self-driving cars and those that are watching the technology already know that any such car would need an absolutely 100% rock solid OS.
This changes nothing.
I think you meant "none before I hack the OS".
Ooh, wonder what happens if I send these signals all at the same time when it's not expecting it?
Crash ... Tinkle
Cool.
-- Tigger warning: This post may contain tiggers! --
Did you read TFA?
In a nutshell, the team led by Barr Group found what the NASA team sought but couldn’t find: “a systematic software malfunction in the Main CPU that opens the throttle without operator action and continues to properly control fuel injection and ignition” that is not reliably detected by any fail-safe.
That's proof, not an argument that they could have tried harder to find the system could fail. The bottom line is that its software that puts people's lives at risk. It's reasonable to hold that type of code to a higher standard. There are millions of other cars, trains, and planes out there with similar software but without this type of problem. At some point you should be responsible for the things you create.
Doesn't work that way. You need a real-time OS as light as possible (less lines of code = less chances of bugs) and hardened hardware.
I've got better things to do tonight than die.
Oh certainly, there's lots of reasons to have all sorts of things wireless, and I fully expect all the fancy media systems, etc to go that route. I just don't think the autopilot will be so, any more than the engine control module is today. A wireless kill switch is one thing, but that doesn't need to be connected to the autopilot, just its power line. And so long as the producers aren't shielded from liability for faulty security I would expect them to take a heavily safe route.
That's not to say that I would be surprised by a networked navigation computer/robotic chauffeur/etc. I just don't think there is any reason to integrate it into the autopilot. There's no reason it couldn't just relay navcomp style "turn left in 1/4 mile" type instructions over a simple high-security text mode serial link with an extremely limited vocabulary. So long as the autopilot itself is heavily defended against intrusion the worst that's likely to happen is that a distracted passenger gets driven to a dangerous destination (the observant passenger would presumably flip the override switch)
Actually, for nefarious purposes the ideal autopilot hack would likely be to simply swerve suddenly into oncoming traffic, preferably into a cement truck or something, in which case it will all be over before a human could even reach the override switch - so perhaps an override delay would be advisable to prevent a panicked rider from screwing up the collision avoidance while still giving them time to take over for any less immediate threats. Maybe a two-stage switch - flip off the autopilot, then 20 seconds later press the button on the wheel to confirm that you really mean it and are in control - just to avoid the scenario where a panicked person tries to take control, gets stunned/unnerved/disoriented by the extreme recovery maneuverings, and proceed to drive themselves off a cliff.
In fact we probably want multiple autopilot settings - On and Off of course, but also "panic mode" where the autopilot takes over when a collision in imminent but still avoidable - great for when the kids are learning to drive, or you decide to go for a drive after you've had a few. And maybe something like a co-piloted "driving instructor mode" as well.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
You don't trust the engineer, but you trust the 16 year old girl trying to apply makeup and text her boyfriend while driving on the highway?
That's a bogus strawman argument: that hypothetical 16 year old girl is required to have an older adult in the co-pilot seat specifically because we have already agreed that we don't trust her judgement.
> Again, so far ZERO evidence, proof, or test case has been provided that the software is in any way responsible for this problem.
I had a car that didn't have a tape deck and only five buttons for the radio. ...
And we LIKED it.
-- Tigger warning: This post may contain tiggers! --
This is one of those scenarios where the cultural fascination with the concept is going to push it into practice before it's really ready
Unlike what other technology? Not fire or electricity or television or smartphones or atlatls.
...if it ever is.
How do you find out until you let it loose?
Just in case that wasn't enough:
Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration. A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.
What if we let automakers avoid liability by publishing complete design specs and code for their cars. Not just for the computerized parts but for every part. Insurance companies and consumer watchdogs could then analyse and rate them for safety, durability and any other criteria, helping consumers make informed purchasing decisions.
Allowing software developed by unknown third parties to operate undocumented hardware on public roads with only limited testing is just nuts. We have a right to inspect those designs ourselves, or delegate the job to trusted experts of our own choosing.
I'm guessing you haven't been deep into the wiring and electronic control systems of most modern cars yourself.
Brakes are also computer controlled, taking input from the wheel sensors, engine computer, ABS computer and possibly even differential controllers and a vehicle stability system or yaw control computer. So when you hit the brakes, there are a number of computers that decide that you really don't need 100% of the car's braking capacity to control the car in any given situation. They may even decide you're just a bit out of control instead of trying to stop.
I'm not saying that the ergonomic problems are not real. I'm saying there is definitely more going on than can be accounted for by ergonomic problems (in one specific car model) alone.
I thought there were standards for C in automotive and aerospace applications which disallowed the use of pointer arithmetic.
Yeah, sounds like it's more hype than reality at this point. What they've done is very impressive, but I suspect it's a long way from working in true real world conditions.
I think so -- here you go.
[Post on slashdot instead]
CLI paste? paste.pr0.tips!
I don't see why updates for the navigation, entertainment (or anything that's not on the powertrain for that matter) should have anything to do with the ECU...
For the same reason that on many GM cars the radio was integrated into the airbag system: to save money on parts cost (or, if you're cynical, to lock you to paying the manufacturer for high-margin entertainment options if you wanted your car's basic safety functions to work).
*gasp* 5 seconds? Seriously, what 'did you eat earlier' when /that/ happens?!
CLI paste? paste.pr0.tips!
You were extremely right 10 years ago. You are still pretty much correct today. But I sure hope you will be mostly wrong in another 10 years.
For truly risky applications, I want to use a tool that makes it extremely hard to shoot myself in the foot, while still meeting the required performance parameters. No more mutable state. Use static code analysis to make sure stack overflows can't even happen. A language where NPEs can't happen, because we use some form of Option parameter. Now, tools like that are often too slow for most embedded systems today, but a man can dream.
Thanks for the heads up. I've bought a number of Toyotas, and been satisfied. Last time was a 2006 model. Pretty good, but I've heard from a number of sources that they've gone down hill since then. A shame. A reputation like they had takes decades to build, but can be destroyed in a few years. Maybe they've been infected by American management thinking.
I was reading through comments hoping to find some general opinion of whether or not Barr's findings could have applied to practically any software stack. You usually don't have to work very hard when reading through code before you spot a bug or two. But in my experience most of these bugs are never (or rarely) exposed because they lie in corner cases. But in the case of Toyota's electronic throttle control system, you'd have higher expectations.
It sure sounds like Barr's group indeed found code of "unreasonable quality." I'm just not sure how to put that into proper context. One can always spend more time and money on code analysis and robustness improvements. Did Toyota really fall short of reasonable expectations? It sounds to me like they did, but I'm only hearing one side of the argument.
Did you set the presets by pulling the buttons out, then pushing them back in?
Learn to love Alaska
Elevators use a mechanical safety device that was invented by Elisha Otis in 1854. Prior to that elevators were rightly considered death traps. Take out that mechanical safety device and I wouldn't trust them either.
What if the ECM were implimented as a finite state machine, wouldn't such programming defects be avioded or much easier to detect. Impliment all the low-level stuff as small fast functions and call them from a FSM implimented in software.
It's going to mean that building the control platform for these things is going to have to have MUCH stricter tolerances, and be gone over much more rigorously. And there's going to have to be comprehensive testing of the subsystems, both individually and as a whole.
People's lives are at stake here, and the automakers would do well to be properly paranoid about it.
Look back at Grimshaw v. Ford Motor Co.
Now think of this as "Ford Pinto II".
Chas - The one, the only.
THANK GOD!!!
>> "Anyone wonder what the impact will be on self-driving cars?"
No but as a car enthusiast who enjoys driving I'm praying it will kill the idea stone dead. I can forsee the day when after self-driving cars actually work, it will quickly become illegal for humans to drive at all.
I guarantee you not one single person on that jury knew the first thing about computing, software, firmware, electronics, or anything else having to do with the firmware in the toyota.
A jury of incompetent people found firmware to be defective, and so it is, regardless of the actual facts.
This is why the American justice system is broken. Juries are comprised of off-the-street idiots and not people skilled in the analysis of the evidence at hand.
I did not see anything the article that proved the driver was not at fault. If the firmware was truly at fault, there should many, verifiable episodes of sudden acceleration. That the driver did not have the situational awareness and common sense to gain control of the vehicle (whether from operator error or software issues) suggests operator error was the probable cause.
You can tear ANY system apart and discover flaws; software is not perfect. A verdict like this simply means a low bar for plaintiffs to get an easy payday.
-- Posted from my parent's basement
There are millions of other cars, trains, and planes out there with similar software but without this type of problem. At some point you should be responsible for the things you create.
Hyperbole much? Just because similar problems haven't been proven/demonstrated/published doesn't mean they don't exist.
I don't know how much embedded programming you've done, but seeing as how a team of Toyota engineers and a team of NASA engineers couldn't find the problem should give you an idea level of the incredible complexity involved here. Only when poured over by a company dedicated to embedded development, and a good set of symptoms did they eventually find the issue.
The thing we should look at more closely is the training of drivers and the emergency measures that they should be comfortable with taking. Handing someone the keys for life of a few thousand pound machine after just 10-15 minutes of being observed by a lowly paid DMV employee doesn't help.
put a real computer in the thing
No. A correctly designed and implemented system does not need an excess of power because the amount of computing power necessary is a precisely known quantity.
Safety critical code correctly deals with problems the typical business software programmer has never ever pondered. Recovering from corrupt memory, for example.
The answer isn't a huge CPU and gobs of github best-effort-ware The correct answer is competent design coupled with quality engineering. Hard, expensive work in other words. This actually happens. One can not say it is not possible.
The only real question is; why doesn't it happen at Toyota and other manufacturers? The answer is indifference. The effort is not made, the resources are not spent.
Lack of resources is not the problem. Toyota, for instance, is arguably the largest auto manufacturer on Earth. They certainly have the resources. Whereas NASA was dealing with ~$10e9 annual budgets when they developed STS software, Toyota earned ~$224e9 billion in FY2013. They could to the job right and the cost would be a rounding error.
Hammer them with a big enough judgement and perhaps they'll have the motivation.
Maw! Fire up the karma burner!
There are the Linux RT patches. I don't design mission-critical systems per se, but I do a lot of design testing to ensure that electronics do what they're supposed to. If I were designing that system, it probably wouldn't be purely software-controlled. Software might adjust some registers on an FPGA (or control ASIC designed for use in all company-produced engines) that is full of timers and fast (1us-scale) control loops specific to engines. Doing everything in software seems particularly difficult (and expensive in terms of computational hardware).
But I don't know what Toyota and other manufacturers do.
Valves stick , actuators fail.
The Kruger Dunning explains most post on
What the GP said is correct. They found potential issues but never proved that any of them ever actually happened or caused the accident.
Your statement that there are millions of other vehicles that don't have these issues is unfounded as well. There almost certainly are potential bugs and defects that could cause an accident out there, but the probability of it happening is so low we don't know about it. In fact we know that some people have found themselves unable to stop their cars in the past due to software issues.
It is impossible to know if complex software is completely fail-safe. You can't test every possible set of inputs and hardware faults for an infinite amount of time. You can be pretty confident and minimize the risk though, which is what they are claiming Toyota failed to do.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
... the GP was concerned about overriding software control.
Brake lines also burst, tires fail, wheels fall off, humans spontaneously combust...
I've been reading the transcript. It's fantastic. The expert explains clearly and lucidly in terms that (I imagine are) understandable by non-techies.
The transcriber made some funny mistakes... Let me tell you about "parody bits" and "pointer D references" :)
"Anyone wonder what the impact will be on self-driving cars?"
Ok, I'll play.
How about well written and documented code?
I'll stop there.
I don't know how much embedded programming you've done, but seeing as how a team of Toyota engineers and a team of NASA engineers couldn't find the problem should give you an idea level of the incredible complexity involved here.
Apparently the code was awful and undertested, so a lot of the "incredible complexity" was self-inflicted.
I'd be perfectly happy with "criminal negligence" applying when you haven't taken simple and obvious steps to ensure that safety-critical software actually works.
There's obviously a can of worms there regarding what it would apply to, and what would be a reasonable amount of care, but at some point it becomes like not stress testing your brake lines. You should be able to justify a claim that the brakes on a car you sell your work.
Apparently the source code is guarded like a military secret, too, so I guess "working brakes" is some kind of competitive advantage now?
Then maybe overly complex computers should be kept away from critical/risky processes that risk human life? Gratuitous automotive electronic control systems, like toyota's electronic throttle, really should not be when a cable works just as well. KISS works best for things like this.
At some point you should be responsible for the things you create.
only to a point, otherwise no one would make much of anything in order to avoid sue-happy vultures. Perhaps a better way to deal with this is a design process that requires justification for complexity. Why use a programmable microcontroller to drive a throttle when a cable works just as well? Is an ECU really necessary at all, or does it just provide a bunch of newfangled featuritis that give toyota management and possibly state bureaucrats the warm and fuzzies?
The old scotty quote applies here: "The more they overdo the plumbing the easier it is to stop up the drain."
I'm curious just how many cases like this (tremendous harm generated by software not properly developed because of unreasonable management timelines, hiring, etc) will be necessary before some pressure is put on organizations to actually do a good job with their code. It's not like good code is impossible to write. It just takes time and expensive programmers. Companies (and the govt) keep trying to skimp on both, and the result causes untold damages. Knight Capital, the Obamacare site, Toyota.... I would bet any amount of money anyone should care to put forward that the technical people at the company were screaming their heads off about the code not being ready or done correctly, but management decided to push it out or accept it (in the case of contracting) anyway.
Elevators have a mechanical safety that you as a passenger have no control over, so it doesn't address neoritter's demand for a human fall back. And that mechanical safety only protects you from a cable failure. It does nothing to protect you from out of control elevator computers bouncing you up and down the shaft.
What portion of those are due to faulty software?
At what point should management be held responsible for carrying forward with short deadlines, understaffed teams, and refusal to listen to the engineers who scream at the top of their lungs "IT WON'T WORK!" ? Engineers can say 'we need another 6 months for thorough testing' until they're blue in the face, but management never, ever, listens. If your justification is "there MIGHT be something wrong and we should really look for it", no manager is going to listen.
Schedules slip on software projects, it's what they do. And testing is at the end, necessarily, so it ends up being the thing that gets cut most often. Saying 'we can blame the engineers' is not legitimate when all of the engineers know that testing is absolutely necessary, but management cuts it out.
GGP said "no procedure to make the software fail was presented" which just isn't true. Multiple links in the summary say they reproduced the fault. Whether that fault is what happened in this exact case is a different matter.
but the probability of it happening is so low we don't know about it
I think that's the point. This problem happened at a high enough rate that we did find out about it. I understand you are trading the features that come with software complexity with the risk that comes with being unable to completely verify the code. When that risk results in a fault that happens a significant, noticeable rate then you have a problem. As you said, when you combine that with poor practices (mentioned in multiple links) you get closer to seeing them as liable.
See, software engineers are not real engineers.
No liability, no responsibility...there is some id10t who quoted on another software defect saying "who cares, it's not the tacoma narrows bridge..."..typical attitude of software "engineers", just fix it in the next service pack, and go work on your little easter eggs.
I can just imagine..we'll name the next release after the next of kin, and give them a free software upgrade.
Software sold "WITHOUT WARRANTY" or "FITNESS FOR A PARTICULAR PURPOSE", and "CONTAINING KNOWN DEFECTS" , controlling my car? Driving my car? No thanks!
it doesn't address neoritter's demand for a human fall back
My point was that a simple and extremely reliable mechanism prevents the most likely cause of injury or death. It doesn't rely on software (neoritter's fear) or even a power source.
It does nothing to protect you from out of control elevator computers bouncing you up and down the shaft.
No, but the big red stop button does. It bypasses computer control. It's long been common, and very good, design practice to put in some sort of very simple and reliable override in case the more complex control machinery (not even necessarily a computer) fails.
This "killer" firmware must have a subroutine that detects the age of the driver and then invokes the bug. link The Toyota sudden acceleration "problem" is yet another media/lawyer driven hoax. Toyota only recalled only due to political pressure during the mass hysteria.
Hard to know since we don't have 250M autonomous cars on open roads being subjected to the uncertainties of traffic every day. We've only a few taken out on very well planned routes. If Toyota can't get a 'simple' microcontroller programmed correctly, I have no faith in any car manufacturer, any programmers really, in getting something many orders of magnitude more complicated correct. We can't even buy consumer internet routers with firmware that isn't loaded with vulnerabilities and bugs. A crashed router results in the loss of connectivity and can be reset.
Free roaming autonomous machines that correctly interpret the environment do not exist yet. We don't have the sensor technology, microprocessor performance, nor do the AI design for it. Navigating a plane though the sky is easier than navigating (sub)urban streets full of unknowns like kids and pets running around, or an icy patch in the road. The last thing I'd want is a bunch of these roaming the streets, one software bug/bored teenager script kid hack away from mauling someone or their property.
There's a lot more work to be done before these things are set loose on the road.
And such a device could easily be put on a car.
My point is that neoritter's fear of computer controlled cars is more an instinctive reaction to their novelty rather than a rational assessment of their dangers. He doesn't trust cars not controlled by humans because, based on his past experience, cars are supposed to have human operators. He has no problem with elevators no longer having human operators because, based on his past experience, elevators are supposed to be fully automated.
No it's not. People are always ready to trade freedom for safety, and safety for even the whiff of added convenience. That's why we have this hellpit of 'social change' you speak of. Even what you suggest (walling them off) would be a massive undertaking and hardly worth it. Better to just build high speed trains.
Yeah, but they don't say they found a bug that would lead to that particular task becoming dead. The article more generically says that single bit errors caused in some unspecied fashion can lead to dead tasks. So do we assume that without ECC RAM these single bit errors occur frequently enough to affect a small number of cars over a period of a few years? If not, then they haven't proven anything.
People are people. At the end of the day, it's the same political and social group dynamics at play. Who wants control over what, who wants this or that to do something else, etc.. so while you're right that embedded software meant for controlling machines is a lot different from a web search engine, the 'attitude' of the culture prevails. Also, the costs involved in writing bug free code skyrocket very quickly as complexity goes up, so assuming these things are 'ready now' is childish idealism at best. Needless complexity is never a good idea. At best it offers some cutesy features that work sometimes. At worst, it gets in the way at a critical moment and causes serious problems.
The moment the human has to verify everything is the moment the machine is now getting in the way of the process. Just let the human drive then! Give him a satnav and he's ready to go.. Why should everything be a damn 'negotiation?' Computers are supposed to do what they're told, not argue with the user. Google doesn't understand this anymore. They've got the passive aggressive 'concern troll' help style down pat. I would not want this in my car...even as a satnav system, nevermind something that controls the vehicle directly.
Engineers can't write code. Simple as that.
Leave it to the professionals you morons. For some reason every hardware engineer think they can be a programmer. I have spent decades cleaning up their shit.
And such a device could easily be put on a car.
Which device, a big red stop button? That's only true for stopping the engine. It wouldn't work for steering or brakes, as would be needed in a self-driving car.
It's also presumptuous to assume his fear is irrational. He stated his reasons (and he sounds like a programmer, so he's not just talking about a bogey man he doesn't understand). If you disagree with him it doesn't necessarily mean his fear is irrational.
millions of miles? There's more to it than distance traveled. How many of these cars? 6? 12? 20? Let me know when they get it up to a few hundred-thousand in a single urban area, and have run the simulation for a year or so at least. Frankly, though, I wouldn't want to be one of the pedestrian guinea pigs in that study. ..you did read my whole post right? There's a lot more to driving safely than simple reaction time.
Unlike what other technology? Not fire or electricity or television or smartphones or atlatls.
none of those technologies involve free roaming autonomous robots that could decide to maul someone because of faulty hardware or programming. The closest one is fire, and, btw, we still don't have 100% control of that one, and so it is used only in restricted, contained areas for specific tasks and then put out with processes in place to ensure it stays out. The equivalent here is to give the human a steering wheel, throttle, and brake control, and at that point, the human should just drive the damn car.
How do you find out until you let it loose?
With the way people screech about safety these days? You don't. Just because someone managed to figure out how to cook a chicken leg on a little camp fire doesn't mean he should now set the whole forest on fire just to see what happens. You're so ready to demonize human drivers to justify replacing them with something even less adequate? wtf?
No thanks... at least, not yet. Also, there's the political issues over control of the vehicle. These cars will come with remote control and tracking 'features', guaranteed. No thanks to that too.
We have life support systems in hospitals that work pretty well.
A bunch of programmers wrote the code that run those.
Only a couple of "unintended acceleration" issues apparently.
Been in an elevator much? They still have 'Stop' buttons - quite literally big red buttons. Only the latest buttonless (internal to the car) elevators don't have this (and even then it's available in an access panel inside the car).
There was a time after automated elevators first came out when people refused to use them because they didn't trust them without a "human fall back or ability to overthrow the computer's control". Today, when nearly all the elevators we've ever seen were automated, this seems crazy.
In 50 years, when most people have never seen a manually operated car, we'll seem just as crazy for not trusting them.
http://gizmodo.com/380525/guy-trapped-in-elevator-41-hour-ordeal-caught-on-tape
The guy was stuck for 41 hours. It was one of those express elevators, between floors, and no one noticed.
My point wasn't that elevators are completely safe (indeed, several dozen people in the US die every year in elevator accidents). My point is that it never occurs to us that they shouldn't be trusted without a human operator.
So you're telling me that a random selection of people are qualified to pass judgement on this? What a flawed system, a qualified government regulator should be investigating this through science, not the judicial system. Only in America.
I don't consider 300k accident free miles in ideal conditions anywhere near sufficient.
I've personally logged over 500k miles with zero accidents, in a heavy traffic, high snowfall, icy part of the country. When they are testing autonomous cars in the worst road conditions and logging somewhere around 10 million accident free miles I'll take a closer look.
Point to a world where consumers hold liability and responsibility for their car, their ECU and their braking behavior even though unintended acceleration is at fault.
http://www.carscoops.com/2013/10/toyota-wins-bellwether-case-on.html
I had a car that didn't have a tape deck and only five buttons for the radio. ...
Ah, but did it have tubes? And a single speaker in the middle of the dash? Was it covered with real chrome?
My car for which you could say yes for all of that also had a transmission with five buttons. Wicked cool for smoke starts.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Every person knows the risks of human drivers, if they don't, well they are naive. between human error, human inattention and human maliciousness. There are two camps, people who think they are the greatest driver to bless the earth and can deal with any situation in the blink of an eye, even if it's caused by some malicious human idiot; and people who realize few people are as special as the first people think they are.
Rocket Surgeon.
For some things, it depends upon your perspective on whether or not "improvement" from Kaizen is really improvement.
On my Toyota Yaris hatch, the bolt attaching the clutch bracket is accessed from above. I am sure doing this led to an improvement in the time to assemble the vehicle-- but having to remove the steering column and dash to access the clutch pedal bracket is hardly an improvement from my perspective. Quite a few little nits like this on this car.
If "improvement" in software was measured as cost reductions e.g., via reduced QA, you have "improvement" that may be anything but for the consumer.
All that said, I still like my Yari
There is a point where a real-time OS is a requirement.
You don't need an RTOS. You can have an ASIC do the low level control, and it may be even more precise than a program running on an RTOS could be.
Then the app running on a conventional OS tells the ASIC what to do on a higher level (based on driver etc inputs) - which doesn't have to be done every 1 microsecond. Every millisecond could be good enough. The human driver won't be alternating the throttle from full to off and back every millisecond. Do it right and it doesn't have to be dangerous or a mess, might even work better.
"Computer Tech Analogy": A CRT's electron beam puts dots on the screen at very precise sub microsecond moments, but the display can be controlled just fine by a program in a conventional OS, no need for an RTOS. All you need to do is split the work properly.
Having a program on an RTOS in a CRT control the electron beam might be doable but is probably a bad idea.
Couple of details here:
Toyota had no software testing procedures, no peer review, etc. The secondary backup CPU code was provided by a third party in compiled form, Toyota never examined it.
Their coding standards were ad hoc and they failed to follow them. Simple static analysis tools found massive numbers of errors.
They used over ten thousand global variables, with numerous confirmed race conditions, nested locks, etc.
Their watchdog merely checked that the system was running and did not respond to task failures or CPU overload conditions so would not bother to reset the ECU, even if most of the tasks crashed. Since this is the basic function of a watchdog, they may as well not have had one.
They claimed to be using ECC memory but did not, so anything from single bit errors to whole page corruption were undetected and uncorrected.
A bunch of logic was jammed in one spaghetti task that was both responsible for calculating the throttle position, running various failsafes, and recording diagnostic error codes. Any failure of this task was undetected by the watchdog and disabled most of the failsafes. Due to no ECC and the stack issue below, a single bit error would turn off the runnable flag for this task and cause it to stop being scheduled for CPU time. No error codes would be recorded.
They did not do any logging (eg of OS task scheduler state, number of ECU resets, etc), not even in the event of a crash or ECU reset.
The code contained various recursive paths and no effort was made to prevent stack overflows. Worse, the RTOS kernel data structures were located immediately after the 4K stack, so stack overflows could smash these structures, including disabling tasks from running.
They were supposed to be using mirroring of variables to detect memory smashing/corruption (write A and XOR A to separate locations, then compare them on read to make sure they match). They were not doing this for some critical variables for some inexplicable reason, including the throttle position so any memory corruption could write a max throttle value and be undetected.
Instead of using the certified, audited version of the RTOS like most auto makers, they used an unverified version.
Thanks to not bothering to review the OS code, they had no idea the OS data structures were not mirrored. A single bit flip can start or stop a task, even a life-safety critical one.
These are just some of the massive glaring failures at every level of specifying, coding, and testing a safety-critical embedded system.
I am now confident in saying at least some of the unintended acceleration events with Toyota vehicles were caused by software failures due to gross incompetence and negligence on the part of Toyota. They stumbled into writing software, piling hack on top of hack, never bothering to implement any testing, peer review, documentation, specifications, or even the slightest hint that they even considered the software something worth noticing.
Natural != (nontoxic || beneficial)
No, they get a pass because it kills less than DFU errors. ;-)
Sleep your way to a whiter smile...date a dentist!
The problem is not the language. The problem is the garbage tools that are available for it.
There is no single good tool (as in modern IDE or even command line debugger) for it. The top (and probably only one still maintain) one is AdaMulti ... and it sucks.
Pretty much all diesels made in the last decade are drive-by-wire.
So one example we've already talked about is the internal data structures within the operating system. They missed it because they never looked at the operating system. They got this operating system in binary from their chip supplier and they never looked inside it to see what was in there.
The implementation of OS they used was not compliant with OS interface specification.
Let me guess - they manually created this condition? Of course they did. It means nothing. If you let me go poke around in electronics to simulate various potential failure modes I'll find a way to make them fail in just about any way they possibly can.
"Your honor, we found that by cutting the ground wire and shorting these two wires we could shock the shit out of the consumer of this product. I move for an immedaite $10bn fine!"
How did they reproduce it, by tampering with the electronics? Yes, that is how they reproduced it. This makes it meaningless.
Vehicle tests where they explicitly created the condition _manually_. It's meaningless. You could hand over the ECU board for _any_ vehicle and someone could find a way to _tamper_ with it to cause acceleration like that. So fucking what? It's not proof.
Real time operation by itself does not preclude a preemptive multitasking operating system. The hardware itself is a larger problem if large amounts of state must be maintained for task switches and memory management. Features like Intel's System Management Mode are particularly crippling.
I though what they meant with killer was something game-changing. Turns out, it is literally a killer.
The fact that NatasRevol (and I) would be happy with less deaths from the driverless cars than what would have been caused by human drivers does not mean there would be no need to improve. It just means we would be happy because there would have been improvement and that a path to further improvement has been opened (you can only lower road deaths to a certain degree as long as there are users in the loop)
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
FTA: "Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration."
So, let me ask you this -- if the car 'decided' to accelerate due to a bit flip, tin whiskers, or a stuck task, how likely would it be that a 76-year-old person would think to remove their foot from the brake and then reapply their foot to the break? We are talking about someone whose reaction time is measured in seconds, the same seconds that the accident took to occur.
If they experienced this acceleration and they had 1-2 seconds to react, I doubt they would think to operate the brake in a fashion different than the cars made in the 20th century. You can say driver error, but we're talking about a corner case of software failure that requires the driver to react in a counter-intuitive fashion, and within seconds.
Obviously it's more likely that the people who experience this will be drivers who have decades of experience with cars that don't need this alternative braking procedure. Just like it's more likely that they also took 200-300 ms more time to respond than someone 50 years younger. But that DOESN'T mean it is their fault.
This is not so black and white as you frame it. There are always multiple contributing factors to a crash. The software and hardware involved clearly had a role, and that's why the jury ruled that way.
http://wiki.osdev.org/Context_Switching
It seems context switching from user to kernel space on a 2.8GHz P4 takes 481ns, on a 200MHz P2 it takes about 1335ns.
Switching back takes 330ns and 900ns respectively.
If you've had to switch address space as well, add another few hundred nano seconds.
So you've lost a microsecond just doing context switches.
Your IRQ thats triggered your ignition timing event also has a variable amount of latency to deal with, since you don't know what address space is going to be active when it occurs.
That's just plain ol' x86. It's getting better, slowly. Over a decade the CPU speed went up 14x but the context switching cost only went down 3x.
But then you're not doing OO programming, you're going VHDL/Verilog.
Someone is also going to be writing a driver for your custom ASIC in C as well.
Best comment on this thread. I'd mod up if I could.
Yeah, and have the garbage collector say "Sorry, I have more important things to do right now than process your brake input. I'll be right back at you, thanks for playing!"
If you read the sentence before that: As single bits in memory control each task, corruption due to HW or SW faults will suspend needed tasks or start unwanted ones. It only took a single bit in non-error-detecting RAM getting flipped to cause that particular fault, something that could easily happen due to cosmic rays or minor radioactive contamination in the ECU packaging - and that's before you even take into account all the other potentially memory-trashing code. It's more like a manufacturer deciding not to ground the case at all and just hoping nothing will come loose and short to it.
I guess that "killer app" just got a new meaning.
If you post as an AC, don't expect me to spend a mod point on you.
I'd be happy with a car OS that kills less than 30,000 people per year.
If a car manufacturing defect kills anybody at all, then there should be manufacturer's liability for it.
They don't get a free pass just because of the kind of manufacturing defect, there's no privilege against liability just because it's a software defect.
-wb-
What if the 'defective' car also dramatically reduces the overall number of road deaths?
Don't the needs of the many outweigh the needs of the one? Even if you're a lawyer? Oh, wait, that requires a heart...
No sig today...
That's what you get when you hire bricklayers and plumbers to write your code. Can we get the Telegraph editor a Toyota? Kickstarter campaign maybe? :)
Has anyone bought the "handful of Xanax" option yet? If not, dibs!
http://en.wikipedia.org/wiki/Electronic_throttle_control
"Recently, ETC was initially suspected by some to be responsible for alleged incidents of unintended acceleration in Toyota and Lexus vehicles. No evidence of this has been demonstrated, and Toyota has been exonerated by the U.S. National Highway Traffic Safety Administration (NHTSA)."
??
Whilst there are many aspects about the film I, Robot that I have problems with, this very issue is covered when the female scientist is scared because Wil Smith decides to take manual control of the car they're in.
The comments about TBW making assembly cheaper are well-founded and accurate, but there's WAY more than just that:
TBW let's you get rid of the idle speed solenoid / idle speed bypass motor, which handles high idle during warmup and anti-stall during big drop throttle. Instead, the ECU can move the throttle plate directly. More control authority, less under/overshoot, more stable idle, less idle fuel consumption - not to mention a savings of between 1 (PWM idle solenoids like Honda) to as many as 6 wires (stepper motor systems like Mitsubishi)
TBW allows you to change the ratio between delta pedal and delta throttle - and do so *dynamically*. You can do this by changing the linkage and cam on a mechanical throttle, but it's a big deal and not easy to tune. With TBW, it's a lookup table or a function. If you have a powerful car with a big throttle body, this can pay HUGE fuel savings and vehicle control dividends at low throttle plate angles, where tiny tiny differences in throttle plate angle make huge differences in airflow.
TBW makes traction control / stability control WAY easier - and it doesn't crackle and bang like spark retard systems do.
And that's just the tip of the iceberg.
Just because you can't imagine the benefits don't mean they aren't there.
Want to learn about race cars? Read my Book
Their are some advantages of having the ECU control the throttle in a modern car. Drive-ability is one of them. It allows the ECU to match engine torque and transmission shift points successfully. And this is a big contributor to fuel economy improvements on gas engine vehicles. It allows you to lug the engine at WOT in a much higher gear on small grades or flat roads and when you press the accelerator pedal further, it will force a down-shift. These are mapped into the ECU and adaptive coefficients are determined by the driver during the first few minutes of driving the car after a battery disconnect.
I had a car that didn't have a tape deck and only five buttons for the radio. ...
Ah, but did it have tubes? And a single speaker in the middle of the dash? Was it covered with real chrome?
My car for which you could say yes for all of that also had a transmission with five buttons. Wicked cool for smoke starts.
Where we're going, we don't need tubes!
Someone who can create worlds in a box doesn't really sound too much like a dull weirdo to me... especially if they let me play around in their world.
Yes, they reproduced it using their debugger to flip a bit in memory that killed a critical task. Their argument was that it could randomly get flipped in a real car due to electrical noise, cosmic rays or faulty RAM, but they never actually reproduced such a random failure. They only ever simulated what would happen in that extremely unlikely event.
The rate at which the problem happened is unknown since other factors were not ruled out. In particular the fact that the carpet could cause the accelerator pedal to stick is a prime suspect. In the specific case that this lawsuit was about telemetry showed that the driver didn't press the brake pedal at all, despite saying he did, while the accelerator was pressed. That implies that the most likely explanation is that he pressed the accelerator by mistake, thinking it was the brake. Of course, the telemetry could be wrong, but the chances of both these unlikely events (ECU failure and black box failure) are extremely low.
The jury members said they wanted to punish Toyota. I don't think the judgement has anything at all to do with the likely cause of the accident. NASA said the ECU code was fine, these guys claim it was sloppy but couldn't even read the comments because they were in Japanese. They say that the function names and variables were in English, but if you have ever looked at Japanese code you would know that it's more like a Japanese dialect of English were some words have subtly different meanings.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
In this case, she was justified as in that era people didn't drive, esp. in high traffic at speed. This is like putting a 15yo in dense interstate traffic. (if you've ever taught anyone to drive, you would shudder at the thought)
It is about bloody time that a software developer is held accountable for delivering dangerous buggy firmware. As a purchaser, I have often been frustrated by how this industry has conditioned us to believe that this is normal and must be accepted. Indeed we are usually expected to subscribe to a continuing service to update delivered software for bug fixes. Can you imagine this happening with any kind of hardware delivery. Professionals in the motor vehicle must deliver a product quality that is consistent with the standards of that industry - even if it is software.
Heavy is the head that wears the tinfoil hat.
Unless it is disabled which may not be possible on some hardware, system management mode can easily generate at least 2 orders of magnitude more latency with a low end starting at just 100us. Even without system management mode, poorly written drivers can cause havoc.
When I had to deal with trying to use desktop hardware in real time applications, I qualified it with a simple test routine which toggled a visible I/O pin in response to an interrupt and measured the latency externally on an oscilloscope. The visual histograms were very informative. System management mode was a killer but access to I/O devices like mass storage or networking was often as bad.
I look forward to doing the same test on embedded ARM hardware running Linux or BSD in the near future but I suspect my final solution will be to continue using custom programming on low end embedded controllers for local real time tasks. At least with ARM there is the possibility of having to deal with multiple processors and only one instruction set.
Go back to the 8051. It won't let you down.
Like you, I'm not sure which safety mechanism Stormy thinks we'll install on a car but if they are referring to the big red button...
A big red stop button should work just fine for all those systems. One of the neat side effects of the new electric power steering systems is that they can turn themselves without your help at all and do it with great precision so it makes for easy self-steering. There is however still an actual linkage between the rack and steering wheel. The ABS pump is also completely automatic but there is still a standard vacuum master cylinder with a real connection to the pedal. If you were to cut power to those 2 items then they will shutdown along with the engine when the E-Stop is pressed and you will retain a very rudimentary level of control of the vehicle. Just like today should your engine shutdown while in motion. Now eventually we will eliminate those hard links and go true drive by wire but going by previous vehicle evolution, there is no reason to suspect first gen self drivers to have those backups eliminated. If they did that, whether rational or irrational, fear would dissuade adoption.
if Toyota managed to cock up their software so badly...how bad is the code of other manufacturers?
Never let a lack of data get in the way of a good rant.
For whatever reason the one of the original links was no longer available when I revisited one of the links in the OP today:
http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
But Google Cache still has a copy...
http://webcache.googleusercontent.com/search?q=cache:http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
Again, something that "could" happen. Meaningless.
You're a stupid asshole....sorry, the far likelier is NOT people hitting the wrong pedal, floor mats or that BS.
I have a first generation Prius, which is not even included in such cases. But I had an unintended acceleration. It happened when I lifted my foot OFF the pedal. And you know what, it felt exactly likely when the cruise control kicks in to accelerate up a hill. And I do believe that was what was involved.
But shit for brains folks like you who just simply assume humor error. At like the fucking morons who wrote up the crash report blaming the F-22 crash on pilot error for not keeping his plane in the air when it ran out of oxygen.
YES, a few people likely did something dumb like that. But hey, let's look at statistics. That would happen with any car, and many many cars have much closer together pedals. No, something technical was going on here.
***
"They eventually "fixed" the problem by moving the brake and accelerator pedals further apart, and putting in a brake-gearshift interlock"
And let me point out, that it was also a significant change, and therefore would have had a different firmware for the electronics control module as well. All your statement proved is that they added some extra measures on the next version. But that the next version was modified, and thus the issue eliminated. There is no proof which resulted in the fix, the pedal change vs the electronics update.
Remember, if you're in a car and its accelerating, breaks aren't working....
1. STAY CALM
2. SHIFT THE VEHICLE INTO NEUTRAL
3. BRAKE or COAST VEHICLE TO A STOP
****
Seriously when you hear the 911 calls about these sort of things, you wonder why every 911 operator is not trained to simply say "Please shift your vehicle into NEUTRAL"
I always hated the 8051 series but would have used an embedded x86 if available.
I have been using PIC in this application for years but am looking to switch to bare metal ARM so I will have a unified instruction set from the bottom to top. One disadvantage in some cases though is that most or all of the lowest end ARM embedded processors draw a lot more power.
I mentioned 8051 because it's simple and fast to switch context, you just change memory banks. You can do the same thing in 8 bit PIC's, they usually have 2 or 4 banks.