Please create an account to participate in the Slashdot moderation system


Forgot your password?
Software Transportation Technology

Should I Take Toyota's Software Update? 750

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?"
This discussion has been archived. No new comments can be posted.

Should I Take Toyota's Software Update?

Comments Filter:
  • by Anonymous Coward on Friday February 26, 2010 @12:12PM (#31285912)

    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?

    • by Rakshasa Taisab ( 244699 ) on Friday February 26, 2010 @12:19PM (#31286038) Homepage

      Good luck getting any money from Toyota or your insurance company if you _don't_ take that update.

      Besides, there's not 100 million lines of code in _that_ particular part, they won't be updating your blinkenlights firmware and such at the same time.

      • by schlesinm ( 934723 ) on Friday February 26, 2010 @12:50PM (#31286652) Homepage
        The dealer is doing the firmware update as part of the recall. If they brick your car because the firmware modification goes wrong, then they replace the bricked part. There is no risk on that side. So the big question is do you want a fix for a known bug or do you want to keep the buggy firmware. And as the parent says, if you don't do the upgrade, then if the bug happens to you the insurance company and manufacturer will deny your claim because you refused to fix the bug.
        • Re: (Score:3, Insightful)

          by netsharc ( 195805 )

          Presumably they will deny his claims not just for this particular bug, but for anything he wants to claim!

        • by cgenman ( 325138 ) on Friday February 26, 2010 @01:47PM (#31287676) Homepage

          I would add that the "floor mat" excuse always sounded like BS to me. I'm guessing there is a firmware bug in there somewhere that they can't find that just registers the gas pedal as down. They'd never admit to that, as it would reduce the public perception of security of drive-by-wire systems, and might introduce expensive public testing procedures.

          In that case, your only chance is the brake overriding the gas (a process which should have been true from the beginning anyway). Of course, it might be something else and you might still be screwed... unknown computer bugs are like that.

          • by ckaminski ( 82854 ) <> on Friday February 26, 2010 @02:24PM (#31288360) Homepage
            Which is why I don't like push-button ignition. If my car ever goes into hyperdrive because of a stuck throttle, I take comfort in knowing I still have a kill switch, and I grew up driving tractors and cars without power steering or power-assist braking, so I can cope.

            How can I trust that that push-button ignition will still shut off the car? I know it's conceivable that even a key-start ignition might turn all ignition control over to an ECM, but who's done that?
            • Re: (Score:3, Interesting)

              by Cassini2 ( 956052 )

              Currently, the key-start circuit cuts power to a significant portion of the engine controls. There is no way the engine can run, unless the ignition switch fails shorted. However, you are right. With modern technology, the ignition switch could be made fly-by-wire. If the car was an industrial machine, this would be a severe breach of protocol. Actually, for industrial machinery standards, the current ignition switch would not be considered a sufficient safe-disconnect device. However, it is a car. T

            • by clone53421 ( 1310749 ) on Friday February 26, 2010 @02:36PM (#31288604) Journal

              If my car ever goes into hyperdrive because of a stuck throttle, I take comfort in knowing I still have a kill switch, and I grew up driving tractors and cars without power steering or power-assist braking, so I can cope.

              Of course, if your car ever does go into hyperdrive, you’ll probably be several light-years away by the time you can hit the kill switch, and you’ll have hard vacuum to cope with (assuming you haven’t passed right through the core of a nearby star or planet).

            • Re: (Score:3, Informative)

              by frosty_tsm ( 933163 )

              Which is why I don't like push-button ignition. If my car ever goes into hyperdrive because of a stuck throttle, I take comfort in knowing I still have a kill switch, and I grew up driving tractors and cars without power steering or power-assist braking, so I can cope. How can I trust that that push-button ignition will still shut off the car? I know it's conceivable that even a key-start ignition might turn all ignition control over to an ECM, but who's done that?

              Push-button ignition can be turned off by holding down the button (kind of like with a computer). Push-button ignition doesn't stop you from putting the car in neutral.

      • Re: (Score:3, Insightful)

        by Anonymous Coward


        1) What is your basis for claiming it is 100m lines of code.
        2) Just because the recall was announced 3 months ago doesn't mean that when they started working on a fix.
        3) It's not just your inability to get coverage for yourself if this "bug" affects you, you may have personal liability for others you injure in the process.

        • by jellomizer ( 103300 ) on Friday February 26, 2010 @01:28PM (#31287340)

          Number 3 is a good point...

          You get in an accident. You go Well it is a Toyota bug. But Toyota goes well we gave you the fix you said "I don't know if I should install it, I mean it is a patch it just may not fix the problem"

          Basically if you install it, there is a problem it is Toyota fault not you... If you don't then it is your fault.

          I also fail to see where this Millions of Lines of code comes from. I haven't ever see anything that has a million of lines of code. I have seen groups of software when packaged together will be millions of lines of code. Even the Linux Kernel it is broken into a bunch of smaller programs, so a fix doesn't effect millions lines of code.

          When some one says it is millions of lines of code it is them bragging how much effort they put into making the application deployable... However if there is a bug that needs to be fixed it is normally part of a module where you need to test to make sure that it doesn't effect around 5000 lines of code.

    • by 0100010001010011 ( 652467 ) on Friday February 26, 2010 @12:23PM (#31286110)

      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.

      • Re: (Score:3, Insightful)

        by e2d2 ( 115622 )

        It's still 100M lines of code friend, regardless of who or what wrote it.

        • by Sir_Lewk ( 967686 ) <> on Friday February 26, 2010 @12:40PM (#31286428)

          That's like using the LOC count of a disassembled program written in C to express the size of the original code.

        • Re: (Score:3, Informative)

          by V!NCENT ( 1105021 )

          The thinking is still fundamentally flawed...

          You see... taking an update the yes or the no is questioned because it could cause flaws when the current version doesn't fail.

          Well guess what, no-brainers; the current version is flawed.

          Just take the damned update and maybe you won't cause a fscking accident. The update could cause a security fail, but it is certain version does cause it.

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

      • by odin84gk ( 1162545 ) on Friday February 26, 2010 @12:50PM (#31286660)

        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.

        • by 0100010001010011 ( 652467 ) on Friday February 26, 2010 @01:06PM (#31286970)

          Then you're using it wrong.

          I work for a rather large corporation that uses Simulink for all of our stuff. Nothing gets re-written. The stuff that goes into production is stuff that IS assembled by the electronics group.

          Other groups that design the control algorithms do use XPC boxes [] to create strategies quickly. Once this is done a software specification is written and given to the group that actually makes the model 'their way' (fixed point, design standards, naming conventions, etc). This gets compiled and put into production ECMs that customers use.

          It's really amazing how settings and maps get pulled from different databases and merged together

          • Re: (Score:3, Funny)

            by Anonymous Coward
            I was really wondering about that link, it looks a bit like another popular link on /.
          • by DerekLyons ( 302214 ) <> on Friday February 26, 2010 @01:33PM (#31287434) Homepage

            So he's using it wrong because he optimizes it and actually evaluates the running code, and you're using it correctly because you treat it as a black box?


            • by RotsiserMho ( 918539 ) on Friday February 26, 2010 @02:48PM (#31288768)
              Or the first guy is using it wrong and taking the chance of introducing even MORE bugs (more cooks in the kitchen) while the second guy is relying on code that has been tested time and time again, not only by the Mathworks, but by all of their customers as well. Tell me, when writing code for Linux do you re-evaluate every line of the kernel or treat it as a black box? One of our largest customers (a Fortune 100 heavy equipment manufacturer) relies on generated code to control their engines. And these are big engines. The Mathworks produces very solid code allowing developers to create control systems very quickly that are time-tested to be reliable. That being said, that doesn't mean Toyota simply didn't connect the blocks wrong in this case. A human is still responsible for the logic.
        • by frog_strat ( 852055 ) on Friday February 26, 2010 @01:14PM (#31287122)
          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.
      • by obarthelemy ( 160321 ) on Friday February 26, 2010 @01:10PM (#31287030)

        There's a tool to write the code.

        Is there a tool to write the tool that writes the code ?

        And then, there's the tool who writes the tool that writes the tool that writes the code.

        • Re: (Score:3, Funny)

          Is there a tool to write the tool that writes the code ?

          If you're using Mathematica, that would be Stephen Wolfram

    • by je ne sais quoi ( 987177 ) on Friday February 26, 2010 @12:23PM (#31286122)
      Not to mention that there is a real chance [] this isn't being caused by floor-mats or sticky pedals at all and that it's the software that's causing this in the first place. My gut is to say that their patch is necessary for the same reason why the phone company uses a program whose job it is to go and find memory that is allocated but not being used and free that memory. It's because the system is so complicated that they don't know what's causing the problem and can't find the answer, so this patch acts as a stop-gap to at least cure the symptom if not the disease.

      I think you'd have to be nuts not to install it.
      • by urulokion ( 597607 ) on Friday February 26, 2010 @12:50PM (#31286650)

        I doubt the primary motivation is because of a suspected software problem. I'd say the primary motivation is because Toyota is the one (or one of the few) car manufacture that didn't have a brake-override feature in their fly-by-wire vehicles. After all of the publicity about the raw away cars, they are pulling out the stops to prevent it from getting worse.

        I think it was Car and Driver who did a test of vehicles which had fly-by-wire throttle systems to see how they handled under runaway conditions. They basically took the cars up to certain speeds (20, 40 and 60 MPH IIRC), kept the throttle depressed, and then tried to stop the car with brakes and emergency breaks. Every vehicle with the brake override system, the engines immediately went down to idle power when the brakes where pressed even with the thottle held down. It was very easy to bring the vehicle to a controlled stop.

        The Toyotas w/o the brake override system could be stopped if you were at slow speeds with a lot of effort on the brakes and emergency brake. At higher speeds, the breaks where not enough to stop the vehicle with only the brakes. They also tried turning the vehicles off which would stop the vehicle, but the driver had to manhandle the vehicle w/o benefit of power steering and power brakes.

        Side note: The Toyota Prius has a surprising amount of power at full ouput. That's when the gas engine is driving the wheels, teh eletric drive motor is drawing off teh traction battery to drive the wheels, and the gas engine is driving a secondary motor/generator to creating electricity which is feed to the eletric drive motor. The secondary motor/generator is normally used to recharge the traction battery when the car is operating in usual conditions.

        I was doing 65-75 MPH up the foothills in Arizona and Southern California. I was outdoing a lot of other vehicles with power engines. My cruise control kept at the set speed and didn't slow down at all. Unfortunately the Prius can only maintain that kind of output as the traction battery charge lasts. And the gas milage really sucks in that mode.

      • the car even with the throttle wide open.

        Motor Trend's own test of a Camry found that even with the accelerator wide open the brakes can overcome the engine, easily in fact. Better yet, it still stopped shorter than the Taurus with no accelerator problems! []

        so take the update, its not like your car hasn't already have a program, one declared defective.

      • by Andy Dodd ( 701 ) <atd7.cornell@edu> on Friday February 26, 2010 @01:17PM (#31287150) Homepage

        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.

    • by Oxford_Comma_Lover ( 1679530 ) on Friday February 26, 2010 @12:28PM (#31286226)

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

      Hint: this is a feature, not a bug. And even if you're reviewing very closely, it's not something that it takes three months to avoid messing up. if(X&&Y) Z=Y;

      When the two pedals work at the same time, it can result in pretty horrible accidents. Unless your driving style uses both pedals at the same time in a way that increases your safety (in which case you're James Bond and you don't ask slashdot questions), just take the update.

      • Re: (Score:3, Informative)

        by fprintf ( 82740 )

        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 throttl

  • huh? (Score:4, Insightful)

    by pele ( 151312 ) on Friday February 26, 2010 @12:13PM (#31285924) Homepage

    Are you for real?

  • yes (Score:4, Insightful)

    by samyem ( 664095 ) on Friday February 26, 2010 @12:13PM (#31285926) Homepage
    • Re:yes (Score:5, Insightful)

      by Anonymous Coward on Friday February 26, 2010 @12:15PM (#31285962)

      Uh - if the dealership "bricks" your car by applying the update they will fix it for free. This question is just plain stupid - get the damn update. If something ever happens and you crash your car the first thing they will say is that you declined to apply their update and so they are not liable.

  • by rotide ( 1015173 ) on Friday February 26, 2010 @12:13PM (#31285928)

    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.

    • Re: (Score:3, Funny)

      by lymond01 ( 314120 )

      What if he's modded out the car -- body kit, $5,000 rims, playstation monitors on the window blinds, booming stereo and sub bolted to the trunk. I mean, it's a Camry, and if a car is meant to be tricked out, it's that perennial family sedan. :-)

      • Re: (Score:3, Funny)

        by Sir_Lewk ( 967686 )

        What if he's modded out the car -- body kit, $5,000 rims, playstation monitors on the window blinds, booming stereo and sub bolted to the trunk.

        Then he is a tasteless idiot?

  • Umm... yes (Score:5, Insightful)

    by Anonymous Coward on Friday February 26, 2010 @12:13PM (#31285930)

    Unpatched PCs are bad enough. If I can't go outside because of morons with unpatched cars, I will be very unhappy.

  • Take the update (Score:5, Insightful)

    by FrYGuY101 ( 770432 ) on Friday February 26, 2010 @12:14PM (#31285936) Journal
    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.
    • Re:Take the update (Score:5, Insightful)

      by Goobermunch ( 771199 ) on Friday February 26, 2010 @12:16PM (#31285986)

      A bug that you know about. If, by chance, you find yourself in an accident, and get sued, I doubt a jury is going to look kindly on the "I passed up on the fix for the known bug because I thought it might brick my car" defense. If you pass on the deal, you are essentially taking full responsibility for Toyota's bad code.

      That's not a good choice.


  • by Rik Sweeney ( 471717 ) on Friday February 26, 2010 @12:14PM (#31285940) Homepage

    The car in front is a Toyota because the accelerator pedal is stuck down

  • Are you kidding? (Score:5, Interesting)

    by Spazmania ( 174582 ) on Friday February 26, 2010 @12:14PM (#31285952) Homepage

    Take the upgrade. Shipping firmware always has bugs. Always. As a system administrator, the first thing I do out of the box is download and install the current firmware while it's still under warranty. And if they brick your computer they'll replace it.

  • by Linker3000 ( 626634 ) on Friday February 26, 2010 @12:15PM (#31285970) Journal

    Yes, but make sure you drive the Toyota round a large sandbox for a few days first...maybe you live near a sandy beach or golf course with large bunkers. At a pinch, do your kids have a playpit in the garden? Cat litter tray?

  • by BadAnalogyGuy ( 945258 ) <> on Friday February 26, 2010 @12:16PM (#31285976)

    There's the chance that the update may turn off any jailbreaks you've already got working. Worst case scenario is that it detects a jailbreak and bricks your car, like you said.

    I'd stick with the white hat hackers who are providing jailbreaking instructions and forgo any manufacturer updates.

    The worst that can happen is that your car becomes susceptible to the sudden acceleration "problem" and you lose control and wipe out a family or farmer's market. But you're inside the car so you'll be fine.

    Plus, you'd have to go down to the dealership and they're going to ask you if you've had any problems and a huge rigmarole just to end up with essentially the same performance you've had all along.

    Too many risks and too few benefits. I'd say no.

  • Get the Flash (Score:5, Informative)

    by nicholasjay ( 921044 ) on Friday February 26, 2010 @12:16PM (#31285984)

    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.

  • Apply the update (Score:5, Informative)

    by Cassini2 ( 956052 ) on Friday February 26, 2010 @12:16PM (#31285990)

    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.

  • Seriously? (Score:5, Informative)

    by clone53421 ( 1310749 ) on Friday February 26, 2010 @12:19PM (#31286036) Journal

    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?

    • Re: (Score:3, Informative)

      by JWSmythe ( 446288 )

      Citations would have been good. Here they are for reference. There could be more.

      December 26, 2009: A Toyota Avalon crashes into a lake in Texas after accelerating out of control. All four occupants die. Floor mats are ruled out as a cause because they are found in the trunk of the car.


      Four Jehovah's Witnesses died when a 2008 Toyota Avalon they were riding inside raced out of control and plummeted into a pond on December 26. ...
      Speculations had swelled over whether the car's mat had become stu

  • Absolutely (Score:5, Insightful)

    by onyxruby ( 118189 ) <onyxruby&comcast,net> on Friday February 26, 2010 @12:19PM (#31286042)
    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!
  • by HotNeedleOfInquiry ( 598897 ) on Friday February 26, 2010 @12:21PM (#31286082)
    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.
    • Re: (Score:3, Insightful)

      by Nimey ( 114278 )

      Ah, never thought I'd miss JonKatz, but kdawson makes me wonder sometimes...

    • Re: (Score:3, Informative)

      by Aladrin ( 926209 )

      While I disagree with the 'large percentage of firmware updates actually brick' bit, he's correct that it's pretty common practice not to update firmware unless there's a known bug that -is- affecting you.

      However, that applies to non-mission-critical appliances like home routers and not to death machines like cars or any device that could cost someone a -lot- of money if it goes down.

      And you should never do the firmware update on a 'live' system for the same reason. So if he's actually driving the car whil

    • by SuiteSisterMary ( 123932 ) <> on Friday February 26, 2010 @01:16PM (#31287132) Journal

      I believe, truely and honestly, that the submitter thinks that he's expected to go to, click on 'support,' 'downloads,' 'firmware,' 'by make and model,' and download a binary file which goes onto a USB key.

      I believe that the submitter then thinks there will be instructions like 'pop the cover on the fuse panel, and insert the USB key containing the firmware upgrade in the USB slot. Start the car while holding both the 'rear window defroster' and 'left turn signal' down. The car will start in firmware upgrade mode and automatically start upgrading the firmware. DO NOT POWER OFF THE CAR DURING THIS TIME.'

  • by Anonymous Coward on Friday February 26, 2010 @12:22PM (#31286092)

    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.

  • by computerchimp ( 994187 ) on Friday February 26, 2010 @12:22PM (#31286094)

    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.


  • If you don't (Score:5, Insightful)

    by cmiller173 ( 641510 ) on Friday February 26, 2010 @12:22PM (#31286100)
    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
  • by h00manist ( 800926 ) on Friday February 26, 2010 @12:22PM (#31286106) Journal
    Take a look at the statistics for death causes for people under 60, and you will find almost everyone who doesn't die old dies in a car. Study why cities are large but there's lots of empty space with no people, and what causes urban sprawl [], and you will find roads and parking lots fill all the space. Look at what wasted labor there is in society, and you will find that producing and maintaining one high-price high-waste transportation system per citizen is quite a bit of work when horses managed do to better than that quite some time ago, not to mention electricity and electric computer system transport. And PRT [] more recently. Then read about pollution, and oil wars. Then get back in your car anyway, without even writing a letter to someone.
    • Take a look at the statistics for death causes for people under 60, and you will find almost everyone who doesn't die old dies in a car.

      Nonsense. [] Yes, motor vehicle accidents are the leading cause of death in the US for those between the ages of 15 and 34 (peaking at around 1 out of 3 deaths for the 15-24 age group) but it is nowhere close to "almost everyone" no matter what age group you choose. But don't let actual data get in the way of a good sound bite.

      Look at what wasted labor there is in society, and you will find that producing and maintaining one high-price high-waste transportation system per citizen is quite a bit of work when horses managed do to better than that quite some time ago...

      If horses were actually more efficient economically, we would still be using horses. If you think horses are cheap as a means of transportation, you clearly have never tried to use t

  • 100 million LOC (Score:3, Insightful)

    by Andy Dodd ( 701 ) <atd7.cornell@edu> on Friday February 26, 2010 @12:23PM (#31286118) Homepage

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

  • Well (Score:3, Insightful)

    by ShooterNeo ( 555040 ) on Friday February 26, 2010 @12:25PM (#31286176)

    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.

  • by urulokion ( 597607 ) on Friday February 26, 2010 @12:26PM (#31286198)

    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.

    • Re: (Score:3, Insightful)

      by karnal ( 22275 )

      Putting the car in neutral should also disconnect the throttle fly-by-wire assembly. Unless someone likes constantly revving their engine in neutral (this is for the automatic transmission style only) it wouldn't cause anyone any real grief.

      As we get more and more involved with electronics in cars though, there's also the issue that the ECM could ignore the fact that you put the car in neutral. My wife's car has a gear selector that I know is electronic; couple that with electric throttle and push-button

  • by Shihar ( 153932 ) on Friday February 26, 2010 @12:27PM (#31286220)

    Well, Toyota is giving hearings on capital hill, they have taken a non-trivial finical hit, and I think their president is one piece of bad news away from sepaku. Yeah, you can probably trust that they did everything in their power not to screw it up. I probably would take a potentially unknown problem on a firmware updates that is being watched by dozens of agencies and internal company auditors over a firmware that is known bad with a questionable dedication to quality. Even if their is a problem, it is a safe bet that it will be detected very early due to the number of eyes on it.

    Having been inside of a company that has had to do a recall, I can say that nothing sharpens a company's overzealous safety instincts and risk avoidance mania than a major recall. Recalls, especially the type that Toyota is experiencing, are a complete disaster for the company. They are extremely expensive both in terms of cost and reputation. I am pretty sure that the internal state of Toyota right now is a safety mania that trumps all else that would make a Puppeteer proud. In fact, you can probably rest assured that Toyota is currently wildly overshooting the 'proper' levels of safety. It will probably be a few quarters before they unwind to more reasonable levels.

    You need to consider it from the perspective of a manager. If you, as a manager, are in charge of a critical safety component, what is in your best interest? Yeah, you could try and cut a corner and skim an extra 2% profit that your boss might or might not notice, but if it backfires and YOU result in a safety issue, especially in the current environment, you should get a friend with a sword and a basket for your head and save the company the trouble. Right now, kudos in Toyota are earned by being a safety nut and being the one to discover and 'fix' some absurdly low probability safety concern, not for squeezing the budget a little further. Speaking as someone who has been in a company in full recall mode, if there is ever a time to trust that a company really is putting safety first, now is the time.

  • by guanxi ( 216397 ) on Friday February 26, 2010 @12:32PM (#31286300)

    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.

  • I call shanagans. (Score:4, Insightful)

    by moogied ( 1175879 ) on Friday February 26, 2010 @12:33PM (#31286322)
    I highly doubt this guy is a developer. If he was he would understand how fixing a peice of already running software goes... especially with a known bug. Almost all patches are done in short development cycle because its an easy fix once you find what caused it.

    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.

  • Crap! That sucks! (Score:3, Insightful)

    by Skal Tura ( 595728 ) on Friday February 26, 2010 @12:57PM (#31286794) Homepage

    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.

  • Flawed Fix (Score:4, Insightful)

    by Temujin_12 ( 832986 ) on Friday February 26, 2010 @01:08PM (#31287002)

    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.

  • by sjames ( 1099 ) on Friday February 26, 2010 @01:39PM (#31287524) Homepage Journal

    Firstly, it's not the floormats. Even Toyota has backed away from that as an explanation. The current theory is that it's the accelerator pedal sticking, but that doesn't jibe well with all of the incident reports either. Given that, I wouldn't count on your driving habits or removing the floormats to solve the problem.

    You should also consider that if you have a problem later and the update hasn't been done, guess what they'll blame?!

    In general, the modification sounds like a very good idea. If for whatever reason your car decides to go full throttle against your wishes, I'm sure you'd like one extra chance to convince it otherwise.

    As others have pointed out, you have already accepted 100 million lines of their code without knowing anything about their software practices.

  • by rcb1974 ( 654474 ) on Friday February 26, 2010 @02:01PM (#31287936) Homepage
    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.
  • by Improv ( 2467 ) <> on Friday February 26, 2010 @02:18PM (#31288270) Homepage Journal

    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.

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"