Design Article
2028 - Software quality: economically important & standardized
Paul Anderson, GrammaTech
11/27/2008 1:00 AM EST
 |
| 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.
|
|
|
|
|
Eric Verhulst_Altreonic
1/4/2012 6:20 PM EST
While I follow the line of thought, it has an unfortunate bias. The real value of formal methods and tools lies in the design phase, not in the verification phase (if you use a good code generator that phase might not even be needed).
Software today is a mess because the way it is constructed, not the way it is verified. Most programs have maybe 90% or more of dead code and are very, very inefficient in using memory. The larger they are the more difficult to verify and to debug.
We have developed a distributed RTOS from scratch, even if there was a 15 years of history of manual coding, and used this time formal methods from the very beginning. The result was a much cleaner and efficient architecture. 10 times smaller than the previously hand-coded RTOS. To be precise: about 5 KBytes and except the context switch, all in MISRA checked ANSI-C. We did something similar for a Virtual Machine for binary code: 3 KBytes.
See: http://www.altreonic.com/content/book-opencomrtos-project-out-lessons-learned and http://www.altreonic.com/content/safe-virtual-machine-c
Sign in to Reply