This doesn't mean that Toyota was in the right all along. I still think they got a bad rap for what happened, but apparently I'm in the minority.
More context:
The probe by National Highway Traffic Safety Administration and NASA engineers found that the only causes of the unwanted acceleration were the previously identified sticking accelerator pedals and loose floormats that could jam the pedals.
Exactly. This unintended acceleration was complete media hype from the beginning, which snow-balled out of control after a report of I think 2 times where condensation caused the gas pedal to stick open for a short period of time. Whether this was a hidden or subconscious effort to discredit a non-US car company probably can't ever be proven but the damage is done.
But that's ok. American's historically have the worst memory of anyone on this planet. In a year no-one is even going to remember this fiasco, much less care.
I was in Japan when this controversy was on the front page of every American paper. The people in Nagoya were talking about what puppets of their news Americans are. It's not as if Japanese people are any different. Local people weren't even slightly worried about it. They knew they could ride it out. They knew the claims were total bullshit. It was a transparent effort by the media to drive consumers to the failing American brands. In the end, it failed to persuade Americans to buy mediocrity.
The floormats are pretty obvious and that has happened before. Given that, how hard is it then, if your car doesn't stop accelerating, to simply push the clutch down or switch to neutral, depending on your type of transmission?
That adds complexity; it could falsely trigger when someone was making a left turn in front of oncoming traffic causing them to stall and get creamed. Not saying it isn't still the best choice, but it does have potential downsides.
Who will ever press the brake pedal with their left foot? That sounds like remixing all the routes of neural impulses for braking/accelerating.
I sometimes do it consciously on a parking lot after a good car wash during winter to slightly warm and dry the brake pads to prevent them from getting frozen, and I have to carefully think my foot-pedalling logic twice--no, three times!--to only apply a slight pressure on the brakes while my right foot keeps pushing the accelerator.
If I did that during driving in the traffic, I'd probably alternate between jumping to a 100% halt and rear-ending somebody with screaming tyres.
I was saying adding the mechanism adds complexity and the mechanism could fail; I was not saying we should worry about the person pressing both pedals at the same time during a turn.
That is, in my opinion, one of the worst features ever added to VAG cars. There are plenty of reasons why you would want to feather the throttle and the brake at the same time.
I'm not sure I understand. You mean it should release both throttle and brake at the same time? Or by "feather" do you mean "push"? If so, what are those situations? The only one I can think of is deliberate rubber burning...
Edit: I guess another is for not spooling down the turbo when braking for a corner. If you're worried about that, you are probably far from a normal street driving situation.
1. It can be fairly hard in a panic situation where something bizarre, previously never experienced, and very loud is occurring which also happens to cause you to travel 100 mph.
2. Many drivers really don't have a handle on, and have never actually used, neutral. Many have no clue that you can safely pop into neutral at any speed, too. You're failing to take these facts into account.
Or stand hard on the brakes. Most cars maximum braking power easily exceeds their maximum engine power by a case of 3x. If you don't believe me, see how fast you can deccelerate your car from 60-0 mph. I bet it is a lot faster than you get get from 0-60. This is particularly so when the car is in top gear and thus the gearing has reduced the torque available to the wheels. All cars are capable of being stopped by their own brakes even at wide open throttle. You just have to stand on them hard and ignore the straining engine noise.
The Toyota story was a complete beat up, and incidentally not the first where a totally innocent car has been improperly accused of design problems relating to both incorrect usage and media hype, coupled with greedy lawyers.
And note that they didn't pay a fine for having unsafe cars. They paid a fine because they illegally concealed accident and problem reports from regulators. Even if it turns out that none of these crashes were Toyota's fault, that's pretty inexcusable behavior.
Anyone else kind of scared by the fact that there's 280000 [0] lines of code in a car? I mean, I know there's computers in there, and that they are necessary nowadays, but that seems like an awful lot of code to handle some lights and engine timings.
It's possible that quite a lot of those lines of code might support mostly unnecessary UI-type stuff, eg. the interfaces that let you configure how long the lights remain on for after you remove the key which Top Gear take such pleasure in criticising.
But yeah, it is kind of scary. I'm not really sure I want my car to be "smarter" - keeping it simple seems good. But I guess it is a credit to the industry that AFAIK there haven't been any software disasters that have led to brakes failing and people being killed or similar.
While you're right in that computers control all that integration, you're wrong about being integrated within the car. The 'body' computer (which handles door lights, stereo controls, instrumentation, etc etc) is a completely separate system to the engine management system. One thing most people don't realise is that there isn't one 'central' computer for a car. Rather there are separate computers for each control system - one for the engine, transmission, body, ABS, airbags, suspension (in some cases) - etc etc etc. It's done like this both for separate points of failure and mixing and matching across different model ranges.
Most of the things Top Gear loves to hate can actually be programmed out of your car if you can get a control system that interfaces with it. Things like warning chimes, reminders, etc are generally market-regulation specific, and can easily be switched off as an option within the computer if you have the right gear. One pet hate of mine is auto-locking doors, and in many cars you can turn this off. There is essentially zero chance of me getting carjacked, so it's definitely more trouble thant is worth.
Though it's slightly unsettling, you have to figure that with the millions of cars on the road, that code must be pretty solid considering that there aren't more car-software related incidents occurring.
Any idea what language they use in these vehicles?
I do this type of software development for a living, and you're absolutely right -- it's rock solid.
The embedded control units themselves are coded in a low-level C. The automotive manufacturers develop on top of that in more abstract engineering type languages.
It's fun software to development, given all the hardware integrations involved. Way more interesting than writing line-of-business applications.
Would you be willing to answer a few questions? I'm a recent mechanical engineering graduate (interest in dynamics/control systems) who likes programming. So I'm pretty interested in the type of work you're involved in and want to see if I can get into it somehow. Couldn't find an email in your profile, but mine's ehsanul@ehsanul.com, if you're open to discussion. Thanks!
After studying state estimation and control systems, I'm in no way surprised that there are this many lines of code in a system. I also am not scared of it.
This is how I think about it: Bugs in control systems code are often not visible until some super-weird edge case or some extreme condition is hit. In this case, it's probably too late for the software to really do anything to help you. If it does help, great, if it wasn't there, you'd be screwed anyway. Bugs that affect normal and slightly abnormal operations are very obvious. Essentially, I'm no more worried about the LOC count in my car than I am about a micro-fracture in a bolt that holds my brakes on.
And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot. Or at least, their results cannot be predicted.
The kind argued to be the result of crazy edge cases or super weird conditions cannot. Not in the same absolute fashion.
I'm not saying that you can't find or avoid bugs, or build test suites to catch the majority. But the ones you don't catch have a lot more potentially random results.
The Halting Problem (http://en.wikipedia.org/wiki/Halting_problem) talks about this. For individual algorithms, one can determine if it will halt or not. However, no general algorithm exists. The hard part is that the algorithm to cause the code to halt has to be specially crafted for every algorithm.
The Halting Problem can be sidestepped by having a system say "I don't know" in edge cases. So it's possible to write code that can classify code as "safe" even if it misses some "safe" code that's more complex than it can handle.
There is no "absolute fashion" of avoiding bad conditions in any discipline of engineering. There are just different modes of failure that need to be considered.
In the case of software, you would start with a Hazard Analysis. Designs/code that have high hazard (failure may mean serious injury or death for example) get more scrutiny and better protection. A simple example might be you that have to make a complex calculation that could be catastrophic if it is buggy. That might be mitigated by breaking up the calculation into segments and error checking each segment (e.g., protection against divide by zero deep inside the equation if the wrong set of parameters are input), or by having an additional sanity check on the value that's about to be output to an actuator given current conditions. The point here is to acknowledge that an unseen defect may be lurking in the code, and to try to add protection against it.
There are also predictive techniques that a lot of groups use to estimate defect density. If you expect (based mainly on history) that there will be 1 defect/kLoC found in final test and the test team is only finding 0.1 or they're finding 10, then you need to go back and figure out if the estimates are wrong, the design is screwed up, or the testers are slacking off. In any case, the process should be adjusted.
I don't know when software development will get to the statistically predictable state of modern manufacturing, but it will happen eventually. At least in the bits that are important enough.
> And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot.
What do you suppose type systems are doing? A lot of the time they're proving that something is wrong with your code.
AT&T also did some very comprehensive studies that demonstrated you can predict, with a surprising amount of confidence, which modules of a system will continue to manifest the most bugs, based on existing reports.
I'm an aerospace stress analyst. I doubt there is significantly more predictability in mechanical failures than there is in software failures. With physical parts, there's theory, but it's still up to the human engineer to apply the theory and understand it correctly.
In my field, a case study might be the de Havilland Comet, the first jetliner. Initial versions featured windows with sharp corners. The structure failed at those points because of stress singularities formed at sheet corners. Was the theory of stress concentration factors new? No. But trained engineers overlooked a design aspect that failed. They knew the science, but didn't know to implement it correctly. The exact type of oversight occurs in software engineering as well.
(And now you know why all jetliners today have rounded windows.)
The car industry is going more and more towards closed systems that your local mechanic can't repair without getting licensed and buying specialised readers to understand the car systems.
One possibility is that companies could make cars cheaper with poor quality code. This has higher maintenance costs and they get more from licensing/tools sold to repair. The consumer won't realise the extra burden until after purchase or reviews.
The fact that your local mechanic can't repair things like they used to is not necessarily because the manufacturer elected to write complicated code. It's the environmental regulations that play a huge part in necessitating the hardware (and sometimes software) technology. Much of the technology is needed to get the vehicle within compliance of emissions regulations. Such technology doesn't come cheap -- and is increasingly complex, which necessitates the need for specialized skills and tools to deal with. This is not the type of thing manufacturers can just choose to shortcut, at least not if they want to sell their vehicles in certain countries.
I was referring to the nature of proprietary diagnostic tools that only work with certain cars. Hardware and software is great, but not the consumer is forced to go to a limited supply of only approved dealers who can only diagnose certain software (those software can easily be put out of date by the next generation of cars).
No. Two perspectives on this - currently working alongside Process Control Engineers, and I'd trust these guys to do this kind of work. The mindset and level of detail is complete different from programming in non-critical fields. Our peer review process is comprehensive, and mandatory for all code changes, can be typical for 2+ weeks of dedicated review and analysis on small scopes of change.
Secondly, theres a _lot_ in an ECU. I recently installed a custom ECU into my streeter (Autronic SM4), and the volume of control you have (3D F/A ratio maps, 3D ignition timing, cold start control, knock sensing, fuzzy logic for wear compensation such as dirty injectors / plugs etc) is staggering. On top of this you have exception management (like limp home mode if you blow something up).
It's just like any other programmable logic controller. Additionally for cost savings they probably run the one codebase across a few different models, so not all of it would be executed code.
Have heard of / but haven't used MS. Autronic install will actually be completed by 11/02. They're comparatively cheap and feature complete (3d maps, realtime tuning compensation, boost management etc). Had it recommended by a lot of people so far, and my local shop can tune them =)
At this stage it's a waste, car is stock, but using the lead time to learn the tuning. Next phase is supercharging + NOS kit and related top end work, little bit excited for it.
How is the MS actually structured, seems to have a few components to it?
Yea, I believe the MS uses these sensors: Manifold Pressure, RPM, Intake Air Temp, Coolant Temp., and throttle position - to determine everything. It's very straight forward and pretty hackable - but I never actually did anything other than hook it to the "Stimulator" which was a board that acts as an engine to test the MS unit.
I also used the HPTuners software to tweak my fuel / spark maps on my stock ECU, and it worked very well actually. Good luck with your project!
42 comments
[ 66.5 ms ] story [ 1639 ms ] threadMore context:
The probe by National Highway Traffic Safety Administration and NASA engineers found that the only causes of the unwanted acceleration were the previously identified sticking accelerator pedals and loose floormats that could jam the pedals.
But that's ok. American's historically have the worst memory of anyone on this planet. In a year no-one is even going to remember this fiasco, much less care.
That couldn't have been forseen - it hasn't happened for a generation.
I sometimes do it consciously on a parking lot after a good car wash during winter to slightly warm and dry the brake pads to prevent them from getting frozen, and I have to carefully think my foot-pedalling logic twice--no, three times!--to only apply a slight pressure on the brakes while my right foot keeps pushing the accelerator.
If I did that during driving in the traffic, I'd probably alternate between jumping to a 100% halt and rear-ending somebody with screaming tyres.
Edit: I guess another is for not spooling down the turbo when braking for a corner. If you're worried about that, you are probably far from a normal street driving situation.
2. Many drivers really don't have a handle on, and have never actually used, neutral. Many have no clue that you can safely pop into neutral at any speed, too. You're failing to take these facts into account.
The Toyota story was a complete beat up, and incidentally not the first where a totally innocent car has been improperly accused of design problems relating to both incorrect usage and media hype, coupled with greedy lawyers.
Car and Driver actually put it to the test: http://www.caranddriver.com/features/09q4/how_to_deal_with_u...
Perhaps emergency stop under power needs to be taught as part of driving tests.
[0] http://detnews.com/article/20110208/AUTO01/102080381/Feds-cl...
Most of the things Top Gear loves to hate can actually be programmed out of your car if you can get a control system that interfaces with it. Things like warning chimes, reminders, etc are generally market-regulation specific, and can easily be switched off as an option within the computer if you have the right gear. One pet hate of mine is auto-locking doors, and in many cars you can turn this off. There is essentially zero chance of me getting carjacked, so it's definitely more trouble thant is worth.
Any idea what language they use in these vehicles?
The embedded control units themselves are coded in a low-level C. The automotive manufacturers develop on top of that in more abstract engineering type languages.
It's fun software to development, given all the hardware integrations involved. Way more interesting than writing line-of-business applications.
After studying state estimation and control systems, I'm in no way surprised that there are this many lines of code in a system. I also am not scared of it.
This is how I think about it: Bugs in control systems code are often not visible until some super-weird edge case or some extreme condition is hit. In this case, it's probably too late for the software to really do anything to help you. If it does help, great, if it wasn't there, you'd be screwed anyway. Bugs that affect normal and slightly abnormal operations are very obvious. Essentially, I'm no more worried about the LOC count in my car than I am about a micro-fracture in a bolt that holds my brakes on.
I'm not saying that you can't find or avoid bugs, or build test suites to catch the majority. But the ones you don't catch have a lot more potentially random results.
In the case of software, you would start with a Hazard Analysis. Designs/code that have high hazard (failure may mean serious injury or death for example) get more scrutiny and better protection. A simple example might be you that have to make a complex calculation that could be catastrophic if it is buggy. That might be mitigated by breaking up the calculation into segments and error checking each segment (e.g., protection against divide by zero deep inside the equation if the wrong set of parameters are input), or by having an additional sanity check on the value that's about to be output to an actuator given current conditions. The point here is to acknowledge that an unseen defect may be lurking in the code, and to try to add protection against it.
There are also predictive techniques that a lot of groups use to estimate defect density. If you expect (based mainly on history) that there will be 1 defect/kLoC found in final test and the test team is only finding 0.1 or they're finding 10, then you need to go back and figure out if the estimates are wrong, the design is screwed up, or the testers are slacking off. In any case, the process should be adjusted.
I don't know when software development will get to the statistically predictable state of modern manufacturing, but it will happen eventually. At least in the bits that are important enough.
What do you suppose type systems are doing? A lot of the time they're proving that something is wrong with your code.
AT&T also did some very comprehensive studies that demonstrated you can predict, with a surprising amount of confidence, which modules of a system will continue to manifest the most bugs, based on existing reports.
In my field, a case study might be the de Havilland Comet, the first jetliner. Initial versions featured windows with sharp corners. The structure failed at those points because of stress singularities formed at sheet corners. Was the theory of stress concentration factors new? No. But trained engineers overlooked a design aspect that failed. They knew the science, but didn't know to implement it correctly. The exact type of oversight occurs in software engineering as well.
(And now you know why all jetliners today have rounded windows.)
The car industry is going more and more towards closed systems that your local mechanic can't repair without getting licensed and buying specialised readers to understand the car systems.
One possibility is that companies could make cars cheaper with poor quality code. This has higher maintenance costs and they get more from licensing/tools sold to repair. The consumer won't realise the extra burden until after purchase or reviews.
Vendor lock-in.
Secondly, theres a _lot_ in an ECU. I recently installed a custom ECU into my streeter (Autronic SM4), and the volume of control you have (3D F/A ratio maps, 3D ignition timing, cold start control, knock sensing, fuzzy logic for wear compensation such as dirty injectors / plugs etc) is staggering. On top of this you have exception management (like limp home mode if you blow something up).
It's just like any other programmable logic controller. Additionally for cost savings they probably run the one codebase across a few different models, so not all of it would be executed code.
At this stage it's a waste, car is stock, but using the lead time to learn the tuning. Next phase is supercharging + NOS kit and related top end work, little bit excited for it.
How is the MS actually structured, seems to have a few components to it?
I also used the HPTuners software to tweak my fuel / spark maps on my stock ECU, and it worked very well actually. Good luck with your project!
For instance Boeing used Ada [0] because it can quickly assert all of the conditionals at compile time.
[0] http://archive.adaic.com/projects/atwork/boeing.html