[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.
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.)
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.