Government investigation: No evidence Toyota electronic throttles malfunctioned
reuters.com
reuters.com
[0] http://detnews.com/article/20110208/AUTO01/102080381/Feds-cl...
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!
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.
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.)
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.
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.
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.
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.
For instance Boeing used Ada [0] because it can quickly assert all of the conditionals at compile time.
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.
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.
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.
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.
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.