Do cars have bugs?
Wednesday, 24 March 2010

Automobiles are using increasing numbers of software based systems and not just in the entertainment or sat nav. Many safety critical systems are code - and reliablity is an issue.




As a programmer you must have doubts about the reliability of any software that is placed in a safety-critical system.

I once knew an embedded systems programmer who refused to get in a lift unless is was relay controlled - software in charge just sent him in a cold sweat. I can't imagine how he must react to a drive-by-wire car but my guess is that he has long decided that a bicycle with chain drive, wire actuated brakes and firm physical steering bar is the only option. Object oriented programming just isn't the same thing as engineering that uses real objects.

A recent article in New Scientist magazine - available on their website Electronic car bugs: What drivers need to know - summarises the current situation:

Another area highlighted as a risk factor is the sheer complexity of the software in modern cars. Ford and Toyota have recently issued updates to fix glitches in the software used to control the braking systems in some of their hybrid models. Other manufacturers have at various times reported problems with automatic transmission systems, engine control modules and the software that controls the deployment of airbags.

The article then makes the point that while we have grown accustomed to regular updates to operating systems, browsers and so on, most consumers would meet the same idea applied to their cars with horror. Perhaps justified horror given the simple deduction that the need to update automotive software is an admission that the original just wasn't quite right.

The article also quotes the fact that the largest program to be proven correct stands at 7500 lines of code. Any programmer who has studied the idea of provably correct code knows just how weak this idea is when applied to embedded systems. The best engineering practice we have is to ban the use of constructs which are known to be difficult to control - specifically interrupts and multi-tasking - but this results in a language and tools that are simply too feeble for the job with the result that failures occur in other ways - polling loops that are just too slow and synchronous programming that ignores critical events for too long.

With so many models and makes perhaps the only sensible solution is to force every manufacturer to use a single standard code base for any safety-critical system. At least then we might have the benefit of numbers to flush out the rare errors that are so typical of embedded systems. We all know bugs happen.

Last Updated ( Thursday, 15 April 2010 )