Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Government Software Transportation Your Rights Online

NHTSA Has No Software Engineers To Analyze Toyota 459

thecarchik writes "An official from the National Highway Traffic Safety Administration told investigators that the agency doesn't employ any electrical engineers or software engineers, leaving them woefully unable to investigate correctly what caused the most recent Toyota recall. A modern luxury car has something close to 100 million lines of software code in it, running on 70 to 100 microprocessors. And according to consultant Frost & Sullivan, that number will rise to 200 to 300 million lines within a few years. And the software that controls the 'drive-by-wire' accelerators of Toyota and Lexus vehicles is one potential culprit in the tangled collection of issues, allegations, and recalls of many of those vehicles for so-called 'sudden acceleration' problems."
This discussion has been archived. No new comments can be posted.

NHTSA Has No Software Engineers To Analyze Toyota

Comments Filter:
  • by HungWeiLo ( 250320 ) on Tuesday February 23, 2010 @05:19PM (#31250518)

    Here comes DO-178B for cars.

    I wonder what the cost is per line of code?

  • Welp (Score:4, Interesting)

    by Pojut ( 1027544 ) on Tuesday February 23, 2010 @05:22PM (#31250558) Homepage

    Such is the cost of more complicated technology. Although, I will admit, this problem seems awfully widespread for Toyota to have not caught this at some point in their QC/QA process.

    I'm reminded of the "recall" speech in Fight Club...

  • by Anonymous Coward on Tuesday February 23, 2010 @05:41PM (#31250922)

    Certainly not a direct connection but the automobile industry does use CAN (Controller Area Network) to link many systems in the car, it is a shared bus to so say that a bug in one system couldn't effect another may not be entirely accurate.

    One would hope mission critical system have separate buses but with a safety administration with no ability to check, who knows?

  • Re:Heads better roll (Score:5, Interesting)

    by je ne sais quoi ( 987177 ) on Tuesday February 23, 2010 @05:45PM (#31251002)
    I don't why I even respond because I'm sure to get a troll mod but I'd just like to point out that one of the major political parties solution to bad government is no government at all. This poorly functioning government is a direct result of the dual conservative mantras: 1) deregulation of markets is necessary for them to perform well and 2) less government is better. We saw how well #1 worked in the banking industry, this is more of the same. #2 results in chronically understaffed government agencies, or government agencies not able to do what they're supposed to do (e.g. the Republican senators holding up Obama's appointees right now).

    My parents both worked for the FDA and if the NHTSA operates in any similar way to the FDA, it's a shadow of itself in the 1970s. For the FDA that means that there are less food inspectors and no surprise, there is a rise in food poisoning incidents. I wouldn't be surprised if NHTSA is also chronically understaffed. Additionally, even if individual government workers wanted to do their jobs, they are often prevented by doing so because that is not perceived as "business friendly". The political appointees who run the show are in the thrall of private industry, in fact, they are often people taken directly from private industry (e.g. big pharma lobbyists often run the FDA). This "government capture" is the fault of the democrats just as much as the republicans, e.g. Obama lied about hiring lobbyists in his campaign. Basically, we have a non-functioning government and one party's answer to this is the get rid of the thing all together. That is one solution but that wouldn't prevent things like this incident with Toyota.

    I'm sure Toyota will do the right thing though, because that would be in its interests as a good corporate citizen. *snicker*
  • Re:Huh! (Score:5, Interesting)

    by megamerican ( 1073936 ) on Tuesday February 23, 2010 @05:47PM (#31251054)

    If the NHTSA didn't exist Toyota would have had to spend money to fix the problem instead of paying ex-regulators [] to quash multiple investigations.

    Toyota (TM) hired ex-government regulators to kill at least four investigations into problems with its cars in the U.S. That's the conclusion of an investigation by Bloomberg. The news service reports that, "Christopher Tinto, vice president of regulatory affairs in Toyota's Washington office, and Christopher Santucci, who works for Tinto, helped persuade the National Highway Traffic Safety Administration to end probes including those of 2002-2003 Toyota Camrys and Solaras, court documents show. Both men joined Toyota directly from NHTSA, Tinto in 1994 and Santucci in 2003. "

    The same goes for Wall Street. Most of the financial regulators are former high level executives from Goldman Sachs or strong ties to them and other financial institutions.

    I don't understand why we need so many useless regulators who are usually wolves being put in charge of the hen house when the courts could easily handle this. It's going to end up being prosecuted in a court of law anyway and not solved by some magic regulation hand-waving.

  • by binarylarry ( 1338699 ) on Tuesday February 23, 2010 @05:48PM (#31251062) []

    This guy apparently killed a few people and got put in jail for it. Now it looks like he was telling the truth when he said the car wouldn't stop.

  • Re:consultants (Score:5, Interesting)

    by rainmayun ( 842754 ) on Tuesday February 23, 2010 @05:52PM (#31251128)
    I can promise you have independent verification and validation contracts are bread & butter in the federal contracting world. The federal government has made huge strides in the direction of outsourcing almost all technical expertise, and quite a bit of management expertise (google "federal PMO contracts" for lots of random examples). The few civil servants left in many agencies are a kind of sheepherders, managing vast groups of contractors.
  • by mcgrew ( 92797 ) * on Tuesday February 23, 2010 @05:59PM (#31251258) Homepage Journal

    I've seen the comment about a modern car having something like 100 million lines of code in articles before. Now, I am not in any way qualified to say that number is to large or to small. But as an embedded systems software developer, that seems like an INSANE amount of code.

    Someone posted a link to this article [] that confirms it. I can't find the comment with the link; someone must have modded him down past my threshhold. But the article linked itself confirms that it is indeed an insane amount of code, insanely implimented.

    The avionics system in the F-22 Raptor, the current U.S. Air Force frontline jet fighter, consists of about 1.7 million lines of software code. The F-35 Joint Strike Fighter, scheduled to become operational in 2010, will require about 5.7 million lines of code to operate its onboard systems. And Boeing's new 787 Dreamliner, scheduled to be delivered to customers in 2010, requires about 6.5 million lines of software code to operate its avionics and onboard support systems.

    These are impressive amounts of software, yet if you bought a premium-class automobile recently, "it probably contains close to 100 million lines of software code," says Manfred Broy, a professor of informatics at Technical University, Munich, and a leading expert on software in cars. All that software executes on 70 to 100 microprocessor-based electronic control units (ECUs) networked throughout the body of your car.

    It gets worse.

    And unlike most commercial aircraft, which have strict firewalls between critical avionic systems and the in-flight entertainment systems, there is more commingling of information between the electronic systems used to operate the car and those for entertaining the driver and passengers. According to a Wharton Business School article entitled "Car Trouble: Should We Recall the U.S. Auto Industry?," a few years ago, some Mercedes drivers found that their seats moved if they pushed a certain button; the problem was that the button was supposed to operate the navigation system.

  • by 0100010001010011 ( 652467 ) on Tuesday February 23, 2010 @06:06PM (#31251382)

    Most of that code is auto generated. Except for some low level stuff, nothing is written by hand in assembly or C. It's all auto coded from some sort of control toolbox. Most likely Matlab/Simulink.

    Sure enough this is one of the first hits [] on Google.

    Writing that many lines of code would be damn near impossible in the relatively short development cycle.

    Even a simple PID controller could take up a few dozen lines of code even though on screen it's simply represented by 3-4 blocks.

  • And they said in a modern luxury car.

    So that's all the code in the following computers:

    Engine (controls throttle and such)
    Collision avoidance (ABS, traction control, etc. TPMS is usually here, too, because it's sometimes part of the ABS system to save costs)
    Safety (airbags, seatbelt pretensioners, etc.)
    Central convenience (security system, power locks, power windows, cabin illumination, in some cars even the exterior lighting goes through central convenience)
    Instrumentation (yep, there's a computer dedicated to that - and some security functions are sometimes in there)
    Entertainment (navigation, stereo, DVD, etc., etc.)

    And all these systems are interconnected.

    You get in your car (central convenience deactivates security upon receiving the signal, and when you open the door, it illuminates the cabin, alerts the engine computer that a start is imminent, possibly starting fuel pumps, on diesel cars turning on the glow plugs, etc., etc., and notifies the instrument cluster that the door is ajar.)

    You insert your key into the ignition (yes, I know about push-button start,) and start the engine (engine computer starts up, after which the instrument cluster polls the RFID chip on the key. If it can't get a read, it immediately requests that the engine computer shut down.)

    You decide that you want a little heat before you set off, so you use your steering wheel controls (which go through instrumentation) to set HVAC settings, and then you figure some music won't hurt (entertainment.) Then, you remember that you don't know where you're going, so you punch the address into the navigation system, and it feeds directions back to the instrument cluster.

    Now, you put the car into gear. The transmission computer notifies the other computers about this, and the engine computer adjusts the idle fueling to compensate. The instrument computer reflects the gear change. The central convenience module turns on the daytime running lights. The entertainment system might prevent you from using the touchscreen interface. The safety computer may become more persistent about reminding you that you didn't put on your seat belt, and will notify the instrument cluster of this, to annoy you more.

    After you put your seatbelt on, you let off the brake and pull out of your parking space. Obviously, the engine computer and transmission computer are working together here, the instrument cluster is constantly updating the status of those (and the entertainment computer, which is noting the changes in vehicle position.) After you hit 10 MPH, the engine or transmission computer sends a request to the central convenience module to lock the doors.

    Now, you're going down the freeway, and right in front of you, a semi truck loses control, and flips onto its side. You jam on the brakes, which kills engine power immediately (engine computer, and the transmission computer is affected as well, and this all gets fed back to the instrument computer.) Collision avoidance computer activates ABS and (as you're attempting to swerve out of the way) stability control, and notifies the central convenience computer that you're undergoing a panic stop, and to activate the hazards.

    Unfortunately, you don't have enough time and room to stop, and you hit the semi. The safety computer notices this, and fires the seatbelt pretensioners and the appropriate airbags. Once that's done, there's some less immediate concerns. It would be a bad idea to leave the engine running, so the safety computer requests an engine shutdown. The transmission computer may be requested to shift to neutral, to make moving the wreck easier. The entertainment system will be told to stop playing music, and if it's got a system like OnStar (which used to be yet another TWO separate computers off of the entertainment system,) an emergency call initiated. Instrumentation is of course updating the status of all of this. HVAC may be set to off. The collision avoidance computer will still be trying to keep t

  • by SuperBanana ( 662181 ) on Tuesday February 23, 2010 @06:10PM (#31251456)

    Here comes DO-178B for cars.

    The vehicle drivetrain network is very often, if not always, separate from the "entertainment" network; Audi, for example, runs two separate CAN busses for them. The original story hypes things a bit; there may be 70-100 microCONTROLLERS, but half or more of them are "body" (ie windows, sunroof, etc) or "entertainment"(audio, navigation) related and thus don't really need to be reviewed.

    The vast majority of them do very, very simple things, mostly sending CAN bus messages or responding to CAN bus commands. Ie, you move the wiper stalk. The microcontroller for the steering wheel controls says "the stalk moved" either to the wiper motor interface or a 'body control' computer, which then sends a command to the wipers.

    The code review for most of the modules, as a result, is extremely simple- they're just (mostly digital) I/O boxes. Some of them are things like fuel pump modules, which at most have some diagnostic capabilities (like current draw from the pump, pressure sensor, etc.)

    The code review will not be very problematic for engine computers, because (gasp!) they're not made by car manufacturers. Bosch, Magnetti Marelli, Hitachi, and a couple of other companies are the primary producers. And guess what? The code is largely the same car-to-car. Parameters are changed- code doesn't, so much. And car companies share "platforms", which further simplifies things.

    It's not nearly as scary as it sounds.

  • Not news to me (Score:3, Interesting)

    by VGR ( 467274 ) on Tuesday February 23, 2010 @06:17PM (#31251552)

    I can't say I find this surprising. Anyone who has ever worked on software for a US government contractor, or US military contractor, knows the government/military has no one who can analyze the product they pay for. Nearly every software product I've seen delivered is of absurdly poor quality. It would be laughable if the implications of the software's use weren't so disturbing.

  • by Anonymous Coward on Tuesday February 23, 2010 @06:27PM (#31251706)

    Wow, if this is true, then Toyota with-held evidence that could have kept an innocent man out of jail...

  • by gr8_phk ( 621180 ) on Tuesday February 23, 2010 @06:33PM (#31251826)
    It could be software, it could even be hardware. Whatever drives the pedal to the floor is probably driven by a MOSFET. If proper FMEA isn't done people will overlook that a failed-short condition might pull the pedal down. I once worked at a company where I pointed out something similar but much less likely to cause problems and was greeted with anger. Another concern I had, they just didn't see how it related to safety - it was like talking to a rock. I've also worked at places that poured rather large amounts of money into investigating failure modes where the outcome was uncertain. As a personal non-scientific observation, the OEMs take safety seriously and so do some tier-1 suppliers, but it gets worse the farther down the food chain you go. People are human and can make mistakes - and that's why the industry does LOTs of testing on real vehicles.
  • by goffster ( 1104287 ) on Tuesday February 23, 2010 @07:28PM (#31252502)

    I would be more interested in the process of how
    Toyota develops/maintains code. Do they rewrite code for every car?
    When they reuse code, how do they retest assertions?
    How do they do code verification?
    What is their culture when coding problems interfere w/deadlines ?
    Is there a whole crap load of unused code in there because
    they are scared shitless to remove it ?


  • by Cassini2 ( 956052 ) on Tuesday February 23, 2010 @08:24PM (#31253238)

    The testing was very rigorous, even after a couple of lines of code there were code coverage tests, unit tests, static code analysis, tests of the hardware with Vector CANoe, you name it.

    None of these tests are entirely effective when dealing with embedded applications.

    Bluntly, software tests can only prove the existence of a software bug relative to the specification. For an embedded application, toss the specification out, and start looking at real-world failure scenarios. Glitches on the reset line can cause all sorts of interesting results ... and that is just one possible failure mode.

    On a well designed embedded system, most of the dangerous failure modes involve complex unexpected system level interactions.

  • by kidgenius ( 704962 ) on Tuesday February 23, 2010 @08:33PM (#31253342)
    Why not? The FAA hires engineers. With the way cars are going, I am scared to think of how much computer control is being done (drive by wire, brake by wire, etc), with little to no oversight from an regulatory agency ensuring the safety of the cars. I work in aerospace and my boss is an FAA DER. The amount of safety review done on an airplane is insane. I think that at least some of that analysis should be applied to cars, now that we are giving up so much of the control in the vehicles to them. someone quoted DO-178B for cars...not necessarily a bad idea.
  • by Bodero ( 136806 ) on Tuesday February 23, 2010 @10:17PM (#31254388)

    My kids were runover by an out-of-control Mustang about four years ago. There was nothing mechanically wrong with the car. Maybe it was driver error. I don't know, but apparently the accelerator was still stuck to the floor when the police got there. I remember how the cruise control on the cars I've owned will lower the accelerator when the CC is accelerating.

    I had a Mustang with an out of control acceleration problem. I was driving down a country road when all of a sudden it kept accelerating. I stomped on the brakes and managed to bring it to about 10 mph, pulled off the road, then turned off the ignition.

    The culprit? I had stored it all winter long (this was the spring) and squirrels had used my engine compartment as their own winter storage. An acorn had lodged itself in the throttle cable and held it wide open.

    Sometimes what sounds like it might be something more complicated is simple.

  • by Cassini2 ( 956052 ) on Tuesday February 23, 2010 @10:52PM (#31254716)

    There are two major problems with the "shift to neutral" solution:
    1. It doesn't always work.
    2. Only a few auto-mechanic and maybe some race car drives have the reflex to shift the car into neutral.

    Most people will not think of shifting to neutral when a problem is encountered, simply because they never need to do it. I'm an engineer, and if my car takes off, it will take me a while to think of shifting to neutral. A car at full acceleration can cover much ground in less than 1 second.

    The other problem is that I doubt that auto-transmissions will consistently disengage under *fault* conditions.

    Your best chance is to be driving a manual transmission. Every manual transmission driver knows to hit the clutch and brakes at the same time, and will do it instinctively. Additionally, the manual transmission is less vulnerable to simultaneous failure modes than the modern computer controlled automatic transmission. For instance, if you are high gear in a manual transmission, it won't automatically down-shift to apply more torque to the wheels when you brake the car to slow it down. Additionally, if the manual transmission is in low gear, it won't up-shift automatically if the car engine takes off. The engine may rev-high, but in low gear, at least you won't be going fast. The manual transmission is much safer in runaway engine conditions.

  • by rickb928 ( 945187 ) on Wednesday February 24, 2010 @12:08AM (#31255340) Homepage Journal

    And safety, not peformance.

    Instead of testng code, evaluating the design process, pretending the NHTSA can even begin to become expert in software design, how about applying the old standards to the new systems?

    For instance, braking safety. I was listening to and reading the testimony from Rhonda Smith [], where she even describes shifting her Lexus into neutral. Neutral?

    A simple test, and I'm not an engineer, but shouldn't a car come to a stop with 'maximum' brake effort, despite the acclerator position? This is solvable in software - if the brakes are going into lock, and ABS is engaged, engine power and/or transmission state have to be compelled to answer the driver's command to stop. Traction control is already being used in many cars; NHTSA should be able to make a test capable of verifying that even multiple malfunctions are overcome.

    Crap, my wife's 1995 Saab 900SE has a mode where the ECU shuts down the fuel pump if the engine stops running, on the assumption that something is terribly wrong, and spewing gas to a stopped engine is pointless if not dangerous. How do I know this? Her car developed a habit of stalling at stops. The real cause was a defective vapor recovery canister, causing loss of vacuum and low RPMs, and the ECU saw that as a stopped engine and made sure it stopped.

    Certainly there are other states that can be tested for performance and safety, not some quality of performance standard. Most cars have 'safe' or 'cripple' modes to protect the drivetrain if something seems wrong, like the transmission in a gear that should not permit the indicated speed. My '95 Explorer does that, and it's only an OBD-I system. Acclerator position, wheel speed, and transmission mode should all correlate, and if something is wrong the system needs to cripple - slow down, set a max speed, etc.

    Aircraft flight control systems are held out as an example of safety and reliability. Most of these, if not all, have to at least ensure the aircraft doesn't exceed the flight envelope and exceed safety limits. This is the sort standard and evaluation the NHTSA needs to focus on.

    Maybe NHTSA needs to borrow a few investigators from the FAA and the military? They should be looking to Boeing, McDonnell, Electric Boat, General Dynamics for expertise in verifying safety in vehicles. Maybe even some NASA people. At least NASA seems to have turned the Shuttle program around a little too late. They certainly have a cautionary tale to tell, and a jaundiced eye towards the assurances of the 'experts' and trusting management.

    Which would go a long way to reinstating a somewhat adversarial relationship between the regulators and the industry. There should be some tension there. Hiring your industry's former employees is not the way to go.

    We can do so much better. We just need to solve the real problems.

  • by PapayaSF ( 721268 ) on Wednesday February 24, 2010 @12:36AM (#31255508) Journal

    Years of deregulation and resource starvation have strangulated our regulatory agencies

    Here's some recent data about the resources available to the DoT, the parent agency of the NHTSA: When the recession started, the Transportation Department had only one person earning a salary of $170,000 or more. Eighteen months later, 1,690 employees had salaries above $170,000 []. Plus the juicy benefits and pension plan. I'll bet all those managers and supervisors raking in the big bucks would agree that their agencies are "resource starved" and that if they only had more money and more power, they could hire two or three software engineers (for the cost of one manager).

"You can have my Unix system when you pry it from my cold, dead fingers." -- Cal Keegan