Static analysis addresses embedded software security challenge
Article By : Mary E. Shacklett
According to LDRA's McElroy, "Apart from static analysis tools, developers should adopt coding standards that are repeatable and as automated as possible."
Embedded software adds functionality and automation to electronic products—but this can often come at the cost of quality assurance, safety and security.
“Because of this, producers of electronics products are mandating security and compliance from themselves and from their suppliers in embedded software as well as in hardware components,” said Jim McElroy, VP of marketing at LDRA, which provides embedded software testbeds and certifications. “Industrial sectors like automotive, aerospace and medical equipment all have quality standards they must meet for electronic devices and equipment, and they also recognise that any failure along their supply chains can cause a major product recall, or generate a situation where lives are actually lost.”
The issue of embedded software quality gained visibility during the Gulf War in the early 1990s, when embedded software inaccurately calculated timing, causing the Patriot intercept missiles to miss their Scud missile targets. This enabled some Scuds to get through to where they harmed or killed soldiers and civilians.
Then several years ago, Toyota experienced sudden acceleration problems with some of its vehicles. “One of the underlying problems with the acceleration was not mechanical—but that the simulation of the software in the system had not been thoroughly tested,” said Peter Schoer, founder and CEO of ARAS, a product lifecycle management software provider.
“The bottom line is that embedded software can have an active life of years, and it must be continually maintained throughout that life cycle,” said Andrew Girson, CEO of Barr Group, an expert systems consultancy. “A failure to follow best practices in producing and maintaining this software can impact safety and life….It’s far less expensive to adopt embedded software practices that lower risk and reduce the potential for error than to deal with the repercussions of a software failure.”
To improve embedded software quality and to reduce risk in products, both McElroy and Girson recommend the adoption of static analysis in embedded software checkouts.
“There are static analysis tools that embedded software developers can use that will automatically read through the source code of a program and identify the spots in the logic that are most likely to cause problems,” said Girson. “This comes early in the process, before the source code is compiled into a binary executable file. The developer won't actually know if a real problem will be caused, but he can be alerted early in the software development process to the most likely trouble spots so he can proactively do something about them at a stage where it is still easy and low-risk to make revisions.”
McElroy said that in addition to static analysis tools, developers of embedded software should also adopt coding standards that are repeatable and as automated as possible. “In this way, if a change must be made in one program, the change can be applied to all other programs that are affected, because you now also have traceability tools that enable you do this,” he said. “It is also very important to regression-test any application that has been modified, to ensure that it will continue to work with other software and hardware that it is intended to work with.”
But methods like these are not all that’s needed to improve the process of developing embedded software.
More institutions of higher learning must also modify their curricula to address the changes that embedded software has brought to electronics products.
“Today, there are many students graduating with computer science degrees and they are being hired to write embedded software for products, but these students are not engineers,” said McElroy. “They are often not sensitised to the safety and security requirements of embedded software as an integral part of product design.” The takeaway for colleges and universities is they need to revisit courses so that engineering principles like safety and security become staples in computer science programs, he said.
Finally, there is also the element of business risk.
“The reality is that many companies make trade-offs,” said Girson. “An engineer might see a need for putting a little more security or safety into a product as a best practice, but the CFO might assess the risk as being so low that the extra time and the investment aren’t warranted.”
The good news is that there are tools capable of static analysis, traceability and troubleshooting that can make embedded software in electronic products better.
“This is a relief to companies, especially as we see more IoT (Internet of Things) products enter the market,” said McElroy. “With IoT, you want to make sure that you are working with certified operating systems, and that they are interacting with software and hardware that is authentic, so that if you are providing IoT-equipped vehicles on roadways that talk to each other, you know that the embedded software in your vehicles running your electronics and your systems is good and that it came from a good source.”