Slashdot Mirror
Should I Take Toyota's Software Update?
kiehlster writes "I'm a software developer, and I know that most software has bugs, but how much trust can we put in the many lines of code found in our automobiles? I have a 2009 Camry that is involved in both of the recent Toyota recalls. As part of the floor-mat issue, they're offering to install a software update that would cause 'the brake pedal to take precedence over the gas pedal if both were pressed,' or, as their latest notice states, 'would cut power to the engine if both pedals were pressed.' In the computer world, we're all taught to install firmware updates only if there is a real problem because a large percentage of firmware updates actually brick the hardware or cause other unforeseen consequences. On a base of 100 million lines of code, can I really trust a software update to work safely when it is delivered in a three-month development cycle? My driving habits don't cause the floor mat to slide much, so I see the update as overkill. What do you think? If it doesn't void the warranty, should I tell them to skip the update?"
First, this is about your safety.
Second, if the update bricks your car, that would be Toyota's fault, not yours and I'm pretty sure they would resolve the issue for you free of charge.
Or, you can keep driving a potentially unsafe vehicle on "firmware update" principles.
There's a lot of cars that have the 'brake takes precedence' feature. The only real reason to not have such a feature is because of trail-braking or hell-toe shifting. Both are racing/performance driving techniques you won't be doing in your Camry. Plus, it is a pure software feature in that if it detects you braking, it will cut throttle. So there's no big issue there.
Also, cars have their computers updated all the time, and it has never been a big deal in the past. The Nissan GTR was the last example that made the news (to cut down on the RPM the launch control used). But really, cars are reflashed all the time. Its not a big deal.
Many other manufacturers have already added a similar piece of code. It really doesn't take to long to debug an interlock. Your primary failure mode will be: if the brake pressed switch fails (ie: the tail lights are stuck on), then the car won't run.
Every interlock has a strong tendency to fail into the safe state. Conversely, omitting interlocks tends to result in fail-dangerous failures, which is what Toyota is experiencing.
Take the update.
My driving habits don't cause the floor mat to slide much, so I see the update as overkill.
Perhaps, but didn’t I read about some people who died in a Toyota, presumably from this exact bug, whose floor mat was found secure in their trunk, exactly where Toyota recommended them to put it when they thought the floor mats were causing the accelerator bug?
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
It's not 100M lines of handwritten code! Every time this comes up everyone (especially those that work with embedded systems) seem to think that there are a ton of code monkeys locked away coding in C or assembly.
I'd be willing to bet that almost all of it is auto generated. Toyota (and nearly everyone else) uses Matlab & Simulink extensively.
The MathWorks tools help Toyota design for the future (PDF)
Toyota Racing Development Makes Faster and More Efficient Engineering Decisions with MATLAB
A simple PID controler with saturation and limits could easily take up 50 "lines of code".
And it's not like Toyota is Mathworks' sole customer. Boeing, GM, Chrysler, Ford, etc ALL use Mathworks.
Just like nearly everyone that works with CAN uses Vector CANape. Everyone that develops ICE powertrains uses AVL
When you start to get to specialized software like what Matlab, CANape, AVL, etc all do, there aren't a ton of options (and no open source solutions). It's cheaper for all of these companies to buy X product and use it than try to write their own.
Agreed... they've already had problems with it and NOT ACCEPTING the fix for it sounds kind of stupid to me. On second thought, maybe the GP should not accept the fix and let Darwin do his magic. Especially since the logic is so simple... if I'm pressing on the brake, don't give the engine gas. Seems like no brainer to me... I mean the fix, not the GP... on second thought, they both do.
Bill
It's my Sig and you can't have it. Mine! All Mine!
Where was the Spanish Inquisition errr... Congress when Ford had to recall 4.5 million cars a few months ago due to their cruise control causing fires?
If you have something that you dont want anyone to know, maybe you shouldnt be doing it in the first place -Eric Schmidt
You are currently modded funny, but I would prefer not to purchase a car that prohibited me from pressing the brake and throttle at the same time and expecting power and braking. You don't need to be James Bond to do left-foot braking, you just need to understand when it is to be used (on the racetrack only). Obviously this situation doesn't apply to a Camry, and I don't know if any of their high performance cars have this same issue. If purchasing a high performance car I would expect the brake and throttle to work independently.
Heck, I even set up my racing pedals on my computer at home to be independent to allow for LFB.
This post brought to you by your friendly neighborhood MBA.
As a user of these software programs, I can tell you how they are Really used:
PHD Uses matlab and simulink to create their motor control algorithms. They port program to the processor of choice and test their algorithm.
Once their algorithm is proved, the firmware engineer uses that code as a template. They re-write all the code to play nicely with the other required code and to improve efficiency. (WTF? Another Memcopy? GARGH! Stop hogging all of my cycles!)
It is a great program for a rapid prototype and proof-of-concept, but it totally fails on actual implementation. I have been to a few microcontroller workshops where people have told the horror stories about the atrocious code created by these programs. In the end, it is just not production quality code.
Which articles were that?
The one I saw was this:
http://www.caranddriver.com/features/09q4/how_to_deal_with_unintended_acceleration-tech_dept
The speed where brakes+full throttle didn't eventually stop the car was 120mph.
And their conclusion:
http://www.caranddriver.com/news/car/10q1/toyota_recall_scandal_media_circus_and_stupid_drivers-editorial
I was on a medical device project using generated code. After three years, management directed us to dump the generated code and hand code it. The two reasons were 1) known bad code the (widely used) tool was generating 2) Code generator company would not certify the generated code, regardless of what we were willing to pay. Required for medical.
My background is as an RF engineer, and I have a reasonable familiarity with EMI engineering.
The utter fucking cluelessness of that article scares me.
"Professor Liu, the story says, compares it to the problem with the jamming of signals on military aircraft.
"The problem is, the expertise for preventing signal jamming rests in the Department of Defense, not the automakers or their suppliers,' Professor Liu says. "
There's a MASSIVE difference between trying to prevent jamming of communications/radar signals, and basic EMI protection engineering of wired electronic circuits. There is PLENTY of experience with the latter in the civilian world, especially within the automotive industry.
Yes, cell phones can cause EMI problems with unshielded equipment, especially GSM phones. The critical systems in a vehicle are without any doubt *shielded*. More details on that later...
Satellite radios are RECEIVERS. (With the exception of satphones - these are incredibly rare.) They can be jammed, but you have to SERIOUSLY fuck up for one of them to interfere with something else. Same for GPS receivers. The most likely way for either of these systems to affect a car negatively is for them to short out and pull excessive current from their power supply. That's what fuses are for.
Large restaurant microwaves are subject to the same restrictions from the FCC as home microwaves. Yeah they can leak a little and they'll jam 2.4 GHz communications, but you could most likely take the magnetron from a microwave oven, point it at a car, and no adverse effects to critical systems would happen.
Why? Because the ignition system within a car is typically the #1 source of interference to anything in or near a car. A malfunctioning ignition system (old spark plug wires, loose spark plug wire connections) is tantamount to a high power spark gap transmitter. Automotive engineers have been dealing with internally generated EMI since the beginning of their industry.
retrorocket.o not found, launch anyway?
You should never roll back at all. I'm in the UK so I always drive manual/stick except for a few months when I had my parents' automatic. On steep inclines you should always use the handbrake to move off; on more shallow inclines you can quickly move the right foot from the brake to the gas whilst slightly moving the clutch up with the left foot to get the clutch to bite. Rolling back a foot would fail a driving test here, and could get you a ticket if the police spot you doing it (although pretty unlikely).
Ok. Case in point, here is a VERY simple switch block. (And this could really be all that they did)
Brake_Override.jpg
If brake is 1, then 0 gets sent to the throttle, otherwise what ever the throttle is gets sent to the throttle.
How many lines of code would you guess that is?
157. (including blank lines between functions).
Want to wager how many the .h file has?
901.
For that little model right there, there were almost 1000 lines of code. Now do you see how you could easily get 100M?
*This is also quick and dirty, I didn't turn on any optimizations it's just the default C generated code to make a .exe (I didn't target any specific embedded device).
**Now in real production these would pull from sensors and it'd probably use a few more lines of code. (You have to read from the A/D, etc)
Last week I took my 2009 Camry into the dealer. Here is what they did:
1) Chopped off about 4cm from the end of the gas pedal. It looks like they did it with a hack saw. The air near the brake pedal smelled like hard plastic that has just been cut.
2) Replaced the old floormat with looked like this:
+-----------+
| |
| |
| |
| |
| |
| |
+-----------+
To one that looks like this:
+---+
| |
+---+ +---+
| |
| |
| |
| |
+-----------+
That way there is a lower chance of the gas pedal touching the floormat. It also means, that the carpet underneath your gas and clutch pedals will get soiled.
3) Updated the firmware. After the update, I did a test where I got the car going 30Mph, and then pressed and held the accelerator. While the accelerator was depressed, I applied the brake with my left foot. After about 1.5 seconds, the engine RPM went down to idle speed. I repeated this test 2 more times. Same result each time.
The firmware update appears to work at least in 3/3 of my test cases.
I hope they didn't use your simple (and informative) example, because if you're stopped at the top of a steep hill (see: San Francisco, city of) you need to use both brakes and accelerator even with an automatic transmission.
As far as I can tell in my re-flashed Camry, hitting the brakes while pressing the accelerator does *not* cut the engine RPM. Of course, I haven't tried this at runaway speeds.