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?"
You already took the 100 million lines of code when you bought the car.
Now do you want the bug fixes, or would you rather find out what a "fatal exception" means in more physical terms?
Are you for real?
yes
Unpatched PCs are bad enough. If I can't go outside because of morons with unpatched cars, I will be very unhappy.
If it bricks, the Dealer's going to be the one who has to replace it. As far as I look at it, it's zero risk, financially.
Safety wise, it fixes a known bug.
Take the update.
"If we let things terrify us, life will not be worth living."
- Seneca
Think of this a few different ways. First from a liability standpoint, you are considering actively refusing a fix for a known bug that has killed people. If you ever sell your car and it can be proved you actively refused this you could be on the hook both civilly and criminally. Second from a liability standpoint, Toyota is now assuming liability for this, if they brick your car, they are liable for fixing it. Third, this is a known bug that has killed people, are you bloody nuts? This is not a software bug that results in a software crash, this is a software bug that results in a real world crash!
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.
/.
Nobody taught you that. You pulled it out of your ass so you'd sound officious and get a post on
The vast majority of firmware updates work, fix problems and don't brick devices. Much more of this shit that gets by as posts and I'll be begging for Jon Katz to come back.
"Eve of Destruction", it's not just for old hippies anymore...
So based on vague general principles without any specific knowledge of the engineering issues involved you are refusing to install a manufacturer recommended safety fix. In an accident situation this is arguably evidence of a reckless disregard for human life. Good luck with your insurance company.
Yes. Toyota's mechnical fix may not be the actual fix and the root issue may be a software based one.
The software update is a failsafe, think of it as an error catching routine. All programs can benefit from error catching routines, problem is that programmers don't have enough time to program for every error possibility. Toyota has taken the time to add one to their cars.
cc
If you don't take the patch and later have the problem you will likely have lost the ability to sue if necessary. Also, if you live in a state with the concept of "contributory negligence" in it's laws you could be found partially or fully at fault for any accidents that would have been prevented by the patch. Eventually insurance companies are going to realize that they could deny claims in accidents if the driver's car is not fully patched. So yes, take the patch
Even in the most modern car, I find this hard to believe, unless you include the entertainment/nav system in the count.
In my opinion, it doesn't count since this is typically decoupled heavily from the safety-critical components of the car.
It is usually easier to write bug-free microcontroller code (ECUs and such) than general purpose PC code. Also, the distributed nature of most automotive microcontroller code keeps code separated into nice little easily-testable modules.
There are always exceptions, but it's very rare for a firmware update in a vehicle to cause regressions. Nearly all of the time, "bugs" in vehicular firmware are really unanticipated results of intentional design choices. For example, the Partial EMCC (PEMCC) code in early-1990s Chrysler A604 transmission firmware that slowly trashed torque converters was intended to improve fuel economy by partially engaging the torque converter lockup clutch - it turned out this wore out the clutch FAR faster than any of the mechanical engineers anticipated. In 1993 or so, this feature was removed once its contribution to premature transmission wear was discovered. (So yeah, this was a case where a bug really WAS originally a feature!)
retrorocket.o not found, launch anyway?
100 million lines of code? Where are they getting this number? The entire Microsoft ecosystem is about that many lines of code.
Maybe they mean assembly code? I'd imagine that the microcontrollers that a car uses are probably programmed with lots of bare metal assembly coding.
I have an '09 Prius. And I'll be getting that firmware update. It's a feature they should have included in the first place. It's not the best implementation of the brake override I'd like. What I'd really like to have an electrical circuit connection between the brake pedal and the throttle fly-by-wire assembly. When the circuit is tripped, the throttle position output of the assembly drops to 0 regardless of actual pedal position or sensor position. But that would require new hardware.
I'm getting the update because if the engine does start runaway acceleration, the brakes aren't enough to overcome the hybrid system's output. I know the right thing to do would be to put the car into neutral and get it safely off the road. But I don't react well to stressful situations.
I think the anti-Toyota mania is getting a little out of hand. The problem caused 34 deaths in 10 years. Given the tens (hundreds?) of millions of Toyotas on the road, it's actually not a big deal. It's an unimaginable tragedy to the people and families that died, and it should be fixed. But as a public safety issue, more people died of lightening strikes and bee stings during that period. Heart disease kills over 1,000 Americans per day. Let's keep it in perspective.
Now we don't trust their firmware updates? I think their safety record is pretty good. You're driving their car at death-defying speeds, aren't you?
The concept of a firmware update for your car is pretty interesting, though.
To illustrate my point, take a made up piece of code that takes the position of 1 sensor, and uses that to control a servo. Lets say that for whatever reason a peice of the code looks like: ServoPosition =(sensor1 + offset) * ServoOffset
Offset is used to correct for initial installation differences for the sensor, so the sensor can detect where it normally sits at idle(when not pressed) so that it can calculate its real position and not its perceived one. NOW! Lets go one step further and say the offset is suppose to be a static variable the entire time the loop is running.. but what if, WHAT IF, the code doesn't lock the offset variable, and for whatever reason the chip is restarting its program over and over again, increasing the size of the offset variable. Eventually, this could cause the sensors to detect the pedal being floored, when its not. So how do you fix that? Remove the offset variable from the part that could be ran over and over again. Be sure to always set it to 0 when you restart the loop.
And then you wonder if its safe? Really they changed less then 1% of there code you fake developer.
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
There was when under-inflated tires were blowing out and causing rollovers.
Nerd rage is the funniest rage.
'would cut power to the engine if both pedals were pressed.'
Did I read that right? THAT would be fun at speed and trying to pull off to the side of the road to restart the car. Ever tried turning a newer car with power stearing off?
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?
Agreed. This has the feel of a smear campaign to put GM back on top.
No brake and gas at the sametime? That majorly sucks. Albeit, not usually needed but there are situations where you need to press both, besides when doing a burnout on a RWD ...
Drive By Wire in itself is a bit stupid idea ... Servos break more easily tha hydraulic cylinders or legs. Electric connections get loose easier than hydraulic sealings start to leak. Nevermind the lost feeling of brake, gas and clutch pedals.
I drove once a drive by wire car, and i seriously couldn't use it during the winter: I had to take my shoes of to feel the pedals enough to know how much i'm pressing brake or acceleration.
Nevermind the fact that using traditional systems you apply force mostly directly to the brakes, and there can't be any software bugs.
I just wish in 20 years time i can still find "oldschool" cars which does not have drive by wire and issues it may cause, and rather has hard lines.
Did you think about the fact that this "floor mat" issue might not exist if there was traditional pedals with the amount of force being needed to press than in older cars? Not only will you actually feel the throttle position, but it wouldn't so easily be pressed by accident.
Pulsed Media Seedboxes
would cut power to the engine if both pedals were pressed
So anyone who starts from a stop on a steep incline by slowly depressing the brake while simultaneously pressing the gas to avoid rolling back into the vehicle behind them will now stall their vehicle?
The accidents that have occurred as a result of this are tragic. But adding quirky behavior as a stop-gap measure seems ridiculous and sets a bad precedent. Is there anything out there to make sure vehicle behavior is reasonably consistent across different vehicles (or even vehicle firmware versions)? Or are we going to have to be aware of all the different firmware ins and outs between different models and firmware versions.
I've been especially surprised at the fact that so many people seem to think that sudden acceleration is unstoppable. If you're driving a vehicle that suddenly accelerates and you cannot prevent the acceleration PUT THE VEHICLE IN NEUTRAL OR DOWNSHIFT (and yes you can downshift with automatics)! How people can get their driver's license while thinking the only way to slow/stop a vehicle is to press the brake is beyond me. I know panic can set in and can make reacting to unexpected dangerous situations difficult, but isn't that why you had a learner's permit first? My father took me to an empty lot and had me practice reacting to different situations that you can encounter which can be dangerous if you panic (ie: sliding, hydroplaning, slamming on brakes, etc.). Perhaps drivers education courses should focus more on these kinds of situations rather than merely how to obey traffic laws.
Faith is a willingness to accept something w/o complete proof and to act on it. Reason allows you to correct that faith.
It's still 100M lines of code friend, regardless of who or what wrote it.
When you write code and estimate its LOC size, do you also include the LOCs of the trusted libraries you use to build your apps? If you do a printf("%u\n",1), do you count this as one LOC or do you also count the LOCs in printf? When you use a GNU compiler, do you also count the thousands LOCs generated by it in assembler?
Does it really not matter *who/what* wrote it? Pretty myopictardic and useless way of software estimation if you ask me.
KDE, Gnome, Linux, OpenOffice, etc. ARE written in assembly language, for the purposes of this bizarre argument.
The media is taking what's in essential a high-level language (MATLAB and/or other code builders) and counting the source lines it creates to get a huge number.
When we write in C or Java, it creates source lines at a level below that (assembly or VM opcodes). And YES, YES, all those programs are in at least only off the 100 million lines of code by one order of magnitude.
But let's just say one opcode is one byte. It's not, but let's say that for yucks that it is, then OpenOffice would need to be 100 megabytes to possibly have that many lines. OpenOffice writer is only 7MB, but we know it uses libraries and other packages, and so, adding all that crap in willy nilly, we probably get up to at least 100MB, and thus (in silly-think) 100 million lines of code.
But let's step back a second. Let's ask ourselves (and I KNOW that there are people who read this who know the answer) "how big is the PROM/ROM/CMOS RAM whatever on the Toyota car computer?" If it's 128MB then this silliness is (for what it's worth) correct-ish. If it's 64MB, it's INSANE. If it's a lot less, it's just mindlessly wrong.
If you have to bet between your judgement and that of your auto manufacturer, I'd suggest that unless you really know what you're talking about, bet on the auto manufacturer. They're the experts.
Likewise, if you're some independent thinker and have an idea how something works, but the scientific community has significant work in the field, you should generally bet on them rather than you.
For every problem, there is at least one solution that is simple, neat, and wrong.
Yes, people do it all the time when someone is tailgating them.
He drives much too slowly, and then when someone is following him, wishing he would speed up and drive the same speed as everyone else, he taps his brakes.
Of course, tailgating someone so they'll accelerate to my desired speed is also a "stupid asshole tactic". Probably a better bet when encountering someone driving "too slowly" for your tastes is to either pass (if possible) or suck it up, Nancy. Maybe even give them more distance, not less. Even if they are driving so slowly as to create a traffic hazard (not just an inconvenience). Especially then. Because if someone is unintentionally creating a nuisance or a hazard, you ought to keep your distance to avoid making an accident even more likely. And if they're doing it intentionally, it's an even better idea. In no event is tailgating the "offending driver" going to make things better. If you wreck your car to make some kind of point, well, you've still got a wrecked car.
Naturally this doesn't apply to operators of trucks over 1 1/2 ton, who are specifically permitted by most rural and southern states to "run over his slow ass". Yes, mods, that sentence was "sar-cas-tic".
I am not a crackpot.
First, this is about your safety.
I don't give a flying crap about HIS safety. I care about mine! I want you to be able to stop only so you don't hurt me. Go ahead and fly into a field all by yourself, just don't take me with you.