In our increasingly automated world, ensuring safety and reliability of what goes on behind the scenes within embedded software code has reached new levels of criticality, especially following some recent high profile and potentially catastrophic failures. This includes Nissan’s airbag deployment glitch and Toyota’s Prius recall. 2014 even saw the entire UK airspace closed for a day due to a software flaw. These are some select examples from the plethora of coding calamities shockingly still evident in our collective drive towards automation.

So who’s at fault? Is it lazy embedded software engineers not competently writing safety critical code? Is it their superiors not ensuring that individual outputs don’t functions together cohesively or isn’t suitably tested? Is it their company not sufficiently investing in the tools to enable a level of testing appropriate to safety critical applications? Often, it’s all of the above.

Today’s code analysis tools offer an unprecedented level of coverage and scrutiny that simply didn’t exist years ago and it should concern you to learn how much code written years, or even decades ago, is still employed in these safety critical applications today. Continued implementation of such legacy code is sold as “proven by time” which is an interesting argument itself. Software code is fairly unique in that, unlike mechanical or electronic hardware, it logically doesn’t suffer with the degradation that ensures that one day in the future, every piece of equipment we use or own is destined to stop functioning. However, proving embedded software without proper external analysis relies purely on extensive functional testing. With the ecosystem around that code evolving, it’s not unrealistic that conditions not specifically tested can occur, causing an unanticipated and potentially catastrophic failure.

With advanced code analysis tools available, you’d think those deploying legacy code would be clambering to thoroughly test it. However, the perception is often that (due to lack of historical failure) this legacy code is proven through the passage of time, and perhaps the more sinister motive is the concern of the Pandora’s Box that such retrospective analysis to deployed code could potentially open. Surely the argument must be that the investment involved to bring any potentially fallible code up to today’s safety standards is far less than the monetary or reputational cost of failure, particularly if it involves the loss of life.

Tools like VectorCAST/Analytics offer an easily digestible visual representation of code coverage, and we’re not just talking graphs and pie charts. What’s unique is the dynamic GUI that presents code complexity and coverage as an interactive heat map. With traffic light labelling, software developers can zoom in to potentially problematic areas, easily highlighting overly complex or under-tested code. The fully customizable dashboard enables heat map formatting based on number of statements or complexity within each source file; clicking can highlight any suspect function within the code itself.

Shown is the interactive heat map of the VectorCAST/Analytics code analysis tool.

With the right tools available, more stringent safety requirements than ever, and so many examples of where software quality has gone wrong, you’d think that such code analysis suites would sell themselves.

Thankfully the attitude toward software quality in today’s embedded market places safety-critical code quality alongside security, at the top of the priority list. The challenge is convincing vendors to retrospectively analyze their legacy code, because what they don’t know, can hurt them.