2028 - Software quality: economically important & standardized
|November 2028 is the 40th anniversary of ESD. Click here read other 2028 lookbacks.|
In retrospect, the state of software development for embedded systems in 2008 was not much to be proud of. The cost to develop and test software was high, yet almost all code had bugs lurking within. Some bugs were hugely embarrassing, such as the one in the BMW that locked its passengers inside.
Others were life-threatening, but most were simply expensive annoyances. Software was treated as somehow less critical than the hardware, so many of its risks were underestimated or simply ignored. Software development for embedded was still more of a craft than an engineering discipline. The dominant languages, C and C++ were appallingly ill-defined and badly implemented. The defect density of delivered software averaged around five bugs per 1,000 lines.
Attitudes to software quality had already begun to change by 2008 with the emergence of an entire class of static-analysis tools that made it easy to find software bugs. By 2010, their use was considered best practice and they were deployed widely.
However, software developers yearned for additional ways to reduce the risk of bugs. Hardware developers were able to prove that their designs met the specification using model checking, but no such tools were available for software. The use of modeling languages was a step in that direction but didn't completely solve the problem.
The pivotal event that changed the industry was the train crash in Paris in 2012 that killed 60 passengers. Investigators traced the cause back to a software bug in the control software. The software supplier was found to have used sloppy practices during development but under a loophole in EU law could not be held liable for damages.
The outrage this provoked prompted the EU to propose legislation to close the loophole and allow software developers to be sued for damages due to software failures if they couldn't prove that they had used best efforts to attain a defect density of less than five bugs per 10,000 lines. This was a tenfold decrease in typical bug density and was considered very difficult and expensive to achieve using then-current software development practices.