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?"
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.
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!
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
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?
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)