Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Toyota's Killer Firmware

Soulskill posted about 9 months ago | from the skynet-draws-first-blood dept.

Transportation 610

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?"

cancel ×

610 comments

Sorry! There are no comments related to the filter you selected.

Technology is hard and dangerous (5, Funny)

i kan reed (749298) | about 9 months ago | (#45272859)

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.

Re:Technology is hard and dangerous (0)

Anonymous Coward | about 9 months ago | (#45272955)

Thank you!

Re:Technology is hard and dangerous (5, Insightful)

neoritter (3021561) | about 9 months ago | (#45273037)

Or we could present this as the new Therac-25 and learn from it. :)

Re:Technology is hard and dangerous (2)

jythie (914043) | about 9 months ago | (#45273093)

"Let's give up now and form an agrarian society!"

bad stuff happens

"That's is, we're all farmers......"

Re:Technology is hard and dangerous (0)

Anonymous Coward | about 9 months ago | (#45273127)

Ummm... no one said that except you. Why the need to push and pull everything to the extreme that they can pushed or pulled to? Does it make you feel more insightful?

Re:Technology is hard and dangerous (-1)

Pentium100 (1240090) | about 9 months ago | (#45273215)

One of the reasons I love my classic car - no software (and no catalytic converter) to worry about. Problems arise because some mechanical part wears out or breaks - that can be seen and it usually results in the engine not running instead of accelerating (probably the only failure that could cause acceleration would be if the throttle return spring broke but even that would require me to press the accelerator to start accelerating, also, since the transmission is manual, even if the spring broke and the car wold not stop accelerating after I release the pedal, I could just downshift). The engine is simpler too.

Re:Technology is hard and dangerous (5, Interesting)

vux984 (928602) | about 9 months ago | (#45273341)

Realistically, you are quite a bit more likely to die in your classic car than you are in a new car despite issues like this.

The new car brakes better, handles better, is an order of magnitude safer in a collision thanks to the crumple zones, airbags, and modern collision testing requirements. It also uses less fuel, and pollutes less.

I like classics too, but I don't have any illusions that they are generally safer or more reliable. I will give you that they are usually easier to fix (assuming they aren't so classic that parts are a problem) but that doesn't make them safer -- and safety was the underlying catalyst for this discussion.

"Impact on self-driving cars?" - None (4, Insightful)

Anonymous Coward | about 9 months ago | (#45272869)

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.

Re:"Impact on self-driving cars?" - None (5, Informative)

neoritter (3021561) | about 9 months ago | (#45272897)

It might change the programming language they decide to use though. Pick a language that's more stable at run-time like Ada (missile programming) etc.

Re:"Impact on self-driving cars?" - None (1)

Anonymous Coward | about 9 months ago | (#45273049)

loop
        -- wait for boom
end loop;

Re:"Impact on self-driving cars?" - None (2)

jythie (914043) | about 9 months ago | (#45273131)

Not sure why this was modded flaimbait... this is one of the areas where Ada does generally shine, it is a language built for auditing.

Re:"Impact on self-driving cars?" - None (1)

neoritter (3021561) | about 9 months ago | (#45273253)

Merely mentioning Ada I think is what got that put there. The language doesn't get the respect it deserves sometimes lol.

Re:"Impact on self-driving cars?" - None (4, Interesting)

erikkemperman (252014) | about 9 months ago | (#45273257)

Not sure why this was modded flaimbait... this is one of the areas where Ada does generally shine, it is a language built for auditing.

That might turn out to be an important point. Suppose some day two cars of different manufacturers cash into each other. Will comparative code audits find their way to court?

Re:"Impact on self-driving cars?" - None (1)

neoritter (3021561) | about 9 months ago | (#45273281)

I think it's because I merely mentioned Ada, lol. That language doesn't get the respect it deserves sometimes.

Re:"Impact on self-driving cars?" - None (1)

quarkalone (607791) | about 9 months ago | (#45273299)

I tend to agree with you.

For good or bad, programming language's choice is relevant.

Re:"Impact on self-driving cars?" - None (1)

Gareth Iwan Fairclough (2831535) | about 9 months ago | (#45273021)

About as stable as the programming used for the apollo missions?

Re:"Impact on self-driving cars?" - None (4, Insightful)

NatasRevol (731260) | about 9 months ago | (#45273047)

I'd be happy with a car OS that kills less than 30,000 people per year.

http://en.wikipedia.org/wiki/List_of_motor_vehicle_deaths_in_U.S._by_year [wikipedia.org]

Or even less than 10 million accidents a year.

http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html [census.gov]

Re:"Impact on self-driving cars?" - None (1)

jythie (914043) | about 9 months ago | (#45273113)

Eh, it does not need to be 100% rock solid, just better then humans. If humans managed to drive around without killing each other such a metric would be necessary, but as it is robotic cars just have to kill fewer people then we do already to be a net gain.

Re:"Impact on self-driving cars?" - None (0)

Anonymous Coward | about 9 months ago | (#45273219)

Have fun convincing the lawyers on that one!

until a bug injures YOU (1)

raymorris (2726007) | about 9 months ago | (#45273333)

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.

Re:"Impact on self-driving cars?" - None (1)

Provocateur (133110) | about 9 months ago | (#45273117)

This changes nothing.

Oh it does -- they've been renamed self-blaming cars. 3 Laws of Robotics never saw this coming.

Re:"Impact on self-driving cars?" - None (1)

icebike (68054) | about 9 months ago | (#45273121)

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.

But then its principal advocate is Google, where good enough gets pushed to production, left to languish and spring cleaned [blogspot.com] out of existence in a couple years.
So in spite of the engineers knowing this, the trend is worrying.
Especially when some of these cars are starting to be drive-by-wire [wikipedia.org] and the trend is that there will exist no physical linkage between the human interface and the cars brakes, engine, steering.

Some how the assurance from and AC that "all is well" and Trust them, they are Scientists, just rings hollow.

Re:"Impact on self-driving cars?" - None (4, Insightful)

mjr167 (2477430) | about 9 months ago | (#45273217)

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?

Re:"Impact on self-driving cars?" - None (3, Insightful)

Impy the Impiuos Imp (442658) | about 9 months ago | (#45273145)

Not necessarily. If said cars kill fewer people than humans, it's still an improvement that should be done.

The problems are lawsuits. A drug that saves 90% of cancer patients but kills 1 in 10 independently will have it's ass handed to it in civil. court -- assuming it makes it past the FDA.

Would that outcomes analysis be applied to government activities and civil lawsuit lawyers ' claims of bettering the system as they fatten their wallets.

Re:"Impact on self-driving cars?" - None (0)

Anonymous Coward | about 9 months ago | (#45273291)

You are assuming some kind of perfect environment where no mistakes will be made. That doesn't make sense. Nothing can be rock solid, nothing can be bug proof. If anything, this shows that even more caution is needed with self-driving cars because we can't even make regular cars correctly still.

So it changes everything, and no amount of Google fanboyism or astroturfing will change that.

What? (-1)

Anonymous Coward | about 9 months ago | (#45272873)

Anyone wonder what the impact will be on self-driving cars?

Google claims their cars are safer than most human drivers.

Would you trust Google on that? You cannot possibly code for every driving scenario, even with collision avoidance systems. Remember, just because YOU didn't drive into someone doesn't omit you from being at fault in every scenario.

Re:What? (0)

Anonymous Coward | about 9 months ago | (#45272943)

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.

Re:What? (1)

epyT-R (613989) | about 9 months ago | (#45273045)

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.

Re:What? (1)

spire3661 (1038968) | about 9 months ago | (#45273239)

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.

Re:What? (0)

Anonymous Coward | about 9 months ago | (#45273307)

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.

Re:What? (1)

NatasRevol (731260) | about 9 months ago | (#45273073)

10,000,000 accidents per year in the US alone.

http://www.census.gov/compendia/statab/cats/transportation/motor_vehicle_accidents_and_fatalities.html [census.gov]

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.

Re:What? (2)

suutar (1860506) | about 9 months ago | (#45273141)

Trust? No, I'd want to see test results. Believe that it's possible? Hell yes.

Re:What? (1)

HiThere (15173) | about 9 months ago | (#45273345)

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.

Self-driving cars will come with an EULA (5, Insightful)

dclozier (1002772) | about 9 months ago | (#45272879)

The owner of a self-driving car will have had to accepted the EULA [wikipedia.org] and accepted not to hold the manufacturer liable for sofware defects. (half joking but I wouldn't rule it out)

Re:Self-driving cars will come with an EULA (5, Insightful)

Anonymous Coward | about 9 months ago | (#45273043)

Won't do any good. I can agree to a hold-harmless provision (and, despite the language of the EULA, such clauses are not actually universal). What I cannot do, is agree to it for someone else. You'd better believe a pedestrian hit by my self-driving car can sue the living daylights out of them. Heck, as previously mentioned, depending on what the particular problem is, *I* can still sue them.

Re:Self-driving cars will come with an EULA (0)

Anonymous Coward | about 9 months ago | (#45273055)

Yes, and your car will come shrink-wrapped; but even if you click "yes" on the in-dash computer screen you still haven't signed anything. The real fun comes in the sales office when you cross out that part of the contract, and walk away if the sales person is unwilling or unable to make the sale. Even then, what happens if you loan the car to a buddy?

Re:Self-driving cars will come with an EULA (2)

epyT-R (613989) | about 9 months ago | (#45273109)

Nevermind that, I'd never own (or ride in as the 'driver'/trip planner, whatever) a self-driving car unless it was blatantly legally clear that I am not to be held accountable for its behavior.

Re:Self-driving cars will come with an EULA (1)

wisnoskij (1206448) | about 9 months ago | (#45273171)

I am sure they will, and they always would have.

But just because you sign that, does not mean that the manufacturer/programmer will not be held responsible for the bus load of kids who drove off a cliff.

The Toyota Way (-1, Troll)

gandhi_2 (1108023) | about 9 months ago | (#45272895)

Idea:

The ideals of The Toyota Way, as embodied in the corporate religion of Lean, may have contributed to overlooking some aspects of software engineering best practices.

Discuss.

Re:The Toyota Way (4, Insightful)

div_2n (525075) | about 9 months ago | (#45272953)

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".

Re:The Toyota Way (-1, Troll)

gandhi_2 (1108023) | about 9 months ago | (#45273105)

I'm merely getting the ball rolling here.

But The Motorola Way, as embodied by the engineer's corporate religion of Six Sigma, would not have trucked with such nonsense. Just saying, brah.

Discuss.

Oh, and I'm sure I've seen it done all wrong. But every time I've seen it, it's been an excuse to never order parts until it's too late because companies are cheap.

Re:The Toyota Way (0)

icebike (68054) | about 9 months ago | (#45273167)

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.

Re:The Toyota Way (0)

Anonymous Coward | about 9 months ago | (#45273181)

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.

Re:The Toyota Way (3, Insightful)

thesupraman (179040) | about 9 months ago | (#45273295)

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.

' Anyone wonder what the impact will be? (5, Insightful)

freakingme (1244996) | about 9 months ago | (#45272913)

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!

Re:' Anyone wonder what the impact will be? (0)

Anonymous Coward | about 9 months ago | (#45272977)

Except for that cars are not only used by companies wanting to keep the features at minimum. They are used by people wanting more and more. Each time a feature is added, there is a risk something else is breaking. Also, there will be all the time tweaking of the program in order to keep the fuel consumption down.

Re:' Anyone wonder what the impact will be? (1)

Immerman (2627577) | about 9 months ago | (#45273191)

Get from A to B as fast as possible, as safe as possible, or along the most scenic route. What other self-driving features would you want? And why would any other features be brought anywhere near the autopilot systems? Sure, maybe you want a friendly robotic chauffeur/bartender avatar in there with all the extras, that's fine - there's absolutely no reason to give it any more connection to the autopilot than a well-fused text-mode serial port link to give terse orders to the autopilot which you have to confirm manually, and if the autopilot manufacturers are held liable for avoidable accidents you can be fairly certain they'll be in no hurry to clog up their system with excess features.

Re:' Anyone wonder what the impact will be? (1)

X0563511 (793323) | about 9 months ago | (#45273229)

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...

Re:' Anyone wonder what the impact will be? (1)

Skiron (735617) | about 9 months ago | (#45273015)

But you need a few more crashes and 'incidents' to get the data to improve the code. More crashes please!

Re:' Anyone wonder what the impact will be? (1)

geekoid (135745) | about 9 months ago | (#45273057)

Not having an accident is also data.

Re:' Anyone wonder what the impact will be? (2, Insightful)

Anonymous Coward | about 9 months ago | (#45273235)

As a old mechanic if you believe for one second that autonomous cars are going to maintained and inspected the way that planes are then you got a bridge to sell you.

The question is not can we build these thing to me, the question is can we reliably maintain then in any capacity. As a mechanic I would take on liability for the parts repaired can you imagine the legal infrastructure required to allow someone other then the manufacturer to maintain and build these things. How do you compensate for a wheel bearing going bad or a brake that is dragging or any othe small thing that will throw the whole calibration off.

Relevant paragraph (5, Informative)

michaelmalak (91262) | about 9 months ago | (#45272927)

2nd link, 5th paragraph:

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. To be clear, NASA never concluded software wasn’t at least one of the causes of Toyota’s high complaint rate for unintended acceleration; they just said they weren’t able to find the specific software defect(s) that caused unintended acceleration. We did.

Re:Relevant paragraph (1)

X0563511 (793323) | about 9 months ago | (#45273245)

It's interesting to me that NASA was looking at it - though I can certainly understand why they would be interested and why they might have some useful insight.

The impact on self-driving cars? Documentation. (5, Funny)

wjcofkc (964165) | about 9 months ago | (#45272929)

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."

Re:The impact on self-driving cars? Documentation. (2)

geekoid (135745) | about 9 months ago | (#45273077)

Clearly it will completely stop the auto industry, just like cars that exploded when rear ended stopped the auto industry.

Stacks (1)

Impy the Impiuos Imp (442658) | about 9 months ago | (#45272935)

> "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.

Re:Stacks (0)

Anonymous Coward | about 9 months ago | (#45273205)

a stack fence and irq counter is page one in Embedded Work,

jrjr

Re:Stacks (1)

LordNimon (85072) | about 9 months ago | (#45273267)

IRQs will piggyback atop the main stack

Not necessarily. Some CPUs allow for multiple hardware stacks -- when the interrupt occurs, the CPU also does a stack switch.

If there's no human fall back, I'll never trust it (5, Insightful)

neoritter (3021561) | about 9 months ago | (#45272941)

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.

Re:If there's no human fall back, I'll never trust (0)

Anonymous Coward | about 9 months ago | (#45273041)

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.)

Re:If there's no human fall back, I'll never trust (1)

raynet (51803) | about 9 months ago | (#45273095)

Half of the cars I've had didn't come with ABS, ECU, airbag, security. They all did come with car radio/cassette player.

Re:If there's no human fall back, I'll never trust (1)

neoritter (3021561) | about 9 months ago | (#45273185)

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.

Re:If there's no human fall back, I'll never trust (1)

viperidaenz (2515578) | about 9 months ago | (#45273325)

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.

Re:If there's no human fall back, I'll never trust (4, Funny)

geekoid (135745) | about 9 months ago | (#45273089)

"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.

Re:If there's no human fall back, I'll never trust (1)

neoritter (3021561) | about 9 months ago | (#45273211)

Lol, you're right. I guess drive should change to ride.

Re:If there's no human fall back, I'll never trust (1)

spire3661 (1038968) | about 9 months ago | (#45273273)

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).

Re:If there's no human fall back, I'll never trust (1)

Immerman (2627577) | about 9 months ago | (#45273311)

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.

Blue screen of DEATH. (0)

Anonymous Coward | about 9 months ago | (#45272947)

Like, literally. Don't flash those custom firmwares onto your cars, kiddies. Unless you want to be on the BLEEDING EDGE.

Re:Blue screen of DEATH. (1)

stewsters (1406737) | about 9 months ago | (#45273027)

But how else will I do my Blues Brothers parking job perfect every time?
http://singularityhub.com/2010/05/12/stanfords-robot-car-slides-into-parking-spot-like-a-badass-video/ [singularityhub.com]

And you want me to try that manually? Do you want me to hit 2 cars and then flip over?

Electronic throtle control problems (1)

kyrsjo (2420192) | about 9 months ago | (#45272979)

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...

Re:Electronic throtle control problems (0)

Anonymous Coward | about 9 months ago | (#45273101)

Every auto I've ever driven has a neutral position, so I really don't understand how these people got themselves into the positions they describe. Bonk the car to neutral, pull over, kill the engine, done.

Really they should lose their licenses for failing to know how to control their vehicles. I've always found it puzzling that we, in the US at least, don't teach basic car control in drivers ed and instead just teach what roadsigns look like.

Re:Electronic throtle control problems (1)

spire3661 (1038968) | about 9 months ago | (#45273293)

Did it ever occur to you that the transmission is fly-by-wire and that a fault in the system would mean that putting the car in neutral does nothing?

Re:Electronic throtle control problems (1)

X0563511 (793323) | about 9 months ago | (#45273283)

On my hybrid, the shift (just like the gas pedal) is just an electronic control. You can masturbate the stick all you want, it won't actually shift unless the computer decides it likes your input.

That said, "pulling the plug" is always an option so long as one recalls that doing so makes it much harder to control. On a Prius, you can hold the power button for a few seconds - or if you're in a rush, three quick taps will cut it as well. The manual refers to this as shutting down the "hybrid system" so I would imagine other controls/systems remain active but the power train dies.

Re:Electronic throtle control problems (0)

Anonymous Coward | about 9 months ago | (#45273339)

It's simple in an automatic.. Just leave it in gear and turn off the key. Don't try to remove the key, just turn it as far as it will go towards off. The engine *will* stop running when you remove power from the ignition and fuel systems and unintended acceleration will no longer be a problem. Once engine RPMs fall below idle, your automatic transmission will be effectively in neutral for every production car made in the last 2 decades.

It may be faster in a manual, just push in the clutch, but I would recommend that you also turn off the key to avoid just letting the engine race and possibly self destruct.

In both cases, coast the car to safety and feel free to use the breaks as necessary to stop. Just expect them to require more pressure if you use them more than once.

Personally, this should be taught in driver's education and considered an essential set of knowledge for written tests. But I have a whole litany of things I think people should know to safely drive that escapes the notice of many folks I've observed.

It is about time!!! (1)

Steve_Ussler (2941703) | about 9 months ago | (#45272983)

That someone hold programmers liable....

Re:It is about time!!! (5, Informative)

c-A-d (77980) | about 9 months ago | (#45273081)

Any engineering project requires that the engineers have to answer for what they've done. The mantra is, "As an engineer, if you fuckup, someone dies." Every engineer, regardless of discipline, needs to understand this and if they don't, should consider going into Liberal Arts or something equally useless where the worst they can do is fuck up my food or drink order.

Re:It is about time!!! (1)

Steve_Ussler (2941703) | about 9 months ago | (#45273123)

We agree!

More Testing (0)

Anonymous Coward | about 9 months ago | (#45272993)

If it can cost you big bucks, you test it more.

wtf (3, Interesting)

schlachter (862210) | about 9 months ago | (#45272995)

'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?

Re:wtf (4, Informative)

ZombieBraintrust (1685608) | about 9 months ago | (#45273099)

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.

The jury could confirm there was a defect because they were able to reproduce it with a physical car. They could confirm the code quality was poor because it 1) It didn't follow the required code standards: MISRA C, 2) The cyclomatic complexity was too high 3) Toyota didn't track bugs.

Re:wtf (5, Funny)

geekoid (135745) | about 9 months ago | (#45273119)

Are you sure you are a software engineer, and not some programmer with delusions of grandeur?
 

Re:wtf (1)

jedidiah (1196) | about 9 months ago | (#45273309)

> Are you sure you are a software engineer, and not some programmer with delusions of grandeur?

Perhaps he understands what all of those fancy sounding words means and is wondering how exactly they add up to "defects". I could certainly see how a lay jury might get bamboozled.

Just "razzle dazzle" them.

You've not even done as much.

Re:wtf (1)

LordNimon (85072) | about 9 months ago | (#45273143)

A good attorney and expert witness will make it clear to the jury that there are several standard and well-known processes that need to be followed to test software, and that Toyota did not follow them.

Re:wtf (2, Interesting)

m00sh (2538182) | about 9 months ago | (#45273177)

'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?

Hate to say this but I think any foreign company on trial in the US is going to get reamed. Americans are very anti-foreign companies. If the company was Chinese, probably guilty on all accounts.

Improper stack analysis does not prove a defect. However, it gives a jury enough rope to hang.

Re:wtf (0)

Anonymous Coward | about 9 months ago | (#45273187)

It doesn't confirm a defect but it does confirm negligence.

also nice job assuming the 5-minute info nugget article expresses everything that happened in the trial

Re:wtf (0)

Anonymous Coward | about 9 months ago | (#45273265)

The transcript from the expert witness states: "So the ultimate conclusion from the presence of these 14 defects is that the software could malfunction."

And this fact - the software has bugs - is taken as a proof that this acceleration issue is because of software with no possibility of actually having been caused by hardware or human errors. Of course, Toyota claims about the quality of the software were rather suspect, too, but still, there is no conclusive proof one way or another.

On the other hand, this might lead into carmakers using black boxes in the future, in order to do proper incident analysis, which should improve safety a lot, so this might actually turn out to be a good thing, whether the acceleration is because of Toyota or not.

Re:wtf (0)

Anonymous Coward | about 9 months ago | (#45273313)

Its not that complicated... well maybe to a jury. Basically its like this:

- The stack is used whenever you make a function call to hold passed variable and return location, etc. (I hope know this as a SW engineer)
- The stack is limited, and is often set low on a per process in RTOS (real-time-OS) environments because there is a lack of RAM and the code is supposed to be simple.
- The "call by pointer" is just a call made using a function pointer instead of directly calling the function. Its easy to overlook when debugging code because you might not know what that pointer is at any point in time. Usually these are used for state tables, but sometimes people get too creative.
- The "task switching" is probably referring the stack used when an interrupt (i.e. the timer interrupt which causes the scheduler to run in this case) occurs. The interrupt uses the same stack as the process it interrupted.
- Libraries often mask multiple calls which increase the stack depth without the developer realizing
- Local variables in a function increase the stack depth
- Memory protection, which could be used to protect the stack, is not that common in embedded systems. This is because embedded usually runs a single-purpose, specialized, and optimized application. If one process/thread fails, the whole thing is considered failed. Memory protection is nice, but in embedded it mostly helps with debugging while having performance penalties.
- Run-time stack monitoring is not that common in real time environments (in my experience) sometimes they use high-water marks for post-run analysis.
- When a stack overflows, often it runs into the stack for another process - and even if you don't, you overwrite something.

Real-time embedded is its own specialty. I did it for ~15 years. Some of the techniques would be considered antiquated on a PC, but they are really efficient and give you complete control of the hardware. You can do things with 1/10th or 1/100th the hardware you need on a PC with a real OS, and you can achieve predictability. There are lots of guidelines on things to avoid (i.e. recursion, certain aspects of OO, etc) and good embedded practices (use static memory vs dynamically allocated if possible, etc). Its not uncommon to hire intelligent guy fresh out of college who writes neat code that runs great on a PC then has to be rewritten for the target box.

Re:wtf (1)

suutar (1860506) | about 9 months ago | (#45273335)

The jury hears more than two sentences extracted from a summary of talking points.

Re:wtf (0)

Anonymous Coward | about 9 months ago | (#45273343)

It would appear that your experience isn't in safety-critical embedded software. On such systems, you need to either verify that you have enough stack space for the worst possible case, or at least monitor the stack usage at run time and explicitly handle the situation where you run out of stack (rather than e.g. letting the stack overlap the heap, resulting in data corruption). Toyota did such an analysis, but there were so many mistakes they may as well not have bothered.

But if you read the EDN article, you'll see that this is just one specific instance of a development process which is closer to "hacking" or "coding" than anything which could reasonably be termed "engineering". It may be acceptable for lowest-bidder web development or knocking up a bunch of excel macros, but it's not considered acceptable for a safety critical system.

None of this proves that a specific accident WAS caused by software defects. But civil suits don't require such proof. The fact that the overall software quality was far below what is generally considered acceptable for safety-critical applications is sufficient to find the manufacturer liable. Basically, if you're designing something where mistakes can be fatal, and you don't want to be sued, you have to do your job properly.

Driver error and floor mats (1, Informative)

Anonymous Coward | about 9 months ago | (#45273009)

Remember when Toyota and DOT concluded the problem was driver error and improperly fitted floor mats?

Good; hold the hacks accountable (0)

Anonymous Coward | about 9 months ago | (#45273017)

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.

Uh, multiple failures? (2)

scrout (814004) | about 9 months ago | (#45273019)

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.

Re:Uh, multiple failures? (1)

X0563511 (793323) | about 9 months ago | (#45273315)

I have a 2013 Prius.

1. On mine at least, they made modifications so that brake input will override throttle input. I don't know if this is mechanical, or software.
2. You can either hold the power button in for a few seconds, or give it three quick taps. This will shut down the "hybrid system" as they call it.
3. The parking brake (note my use of 'parking' not 'emergency') does a good job at holding the car still, but it sucks terribly at stopping a moving vehicle. This is not unique to this car, either. That said it also sucks at holding it still if you give it any throttle input - but that's not unique to this car either.
4. You have no direct transmission control. It's an electronic jog stick dressed up as a shift lever. Remember, this is a CVT and not a traditional manual or automatic transmission.

Mandatory OO code from here on in. (-1)

Anonymous Coward | about 9 months ago | (#45273023)

"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." If they wrote that firmware using C# or Java instead of C and ASM, those people wouldn't have been harmed. Quit bitching about RAM and CPU usage, put a real computer in the thing, with a real stress-tested and proven kernel like Linux, and use a modern programming language. 512MB of RAM and 500MHz isn't worth peoples' lives.

Re:Mandatory OO code from here on in. (2)

X0563511 (793323) | about 9 months ago | (#45273331)

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.

Nothing new (1)

Russ1642 (1087959) | about 9 months ago | (#45273151)

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.

No memory parity! (2)

gallondr00nk (868673) | about 9 months ago | (#45273165)

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.

Don't look now, but... (0)

Anonymous Coward | about 9 months ago | (#45273199)

Intellectual Innovations is busily patenting CAPTCHAs on highways.

Implications for Obabacare (0)

Anonymous Coward | about 9 months ago | (#45273305)

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 ?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>