Software is under attack from every direction: it fails too often; it’s easy to hack; and it’s expensive. The first and last problems are those that are focusing the minds of the large chipmakers the most in a way that could see changes finally come to the way embedded software is put together.
Despite the punishingly high development and mask costs of SoC devices on leading edge processes, such as 28nm and 16nm, analysis by firms such as IBS has shown that software has managed to surge ahead, representing the largest single component of a project’s budget. This relentless rise in software development cost has attracted the attention of EDA companies, who see an opportunity to start to bring automation into the field. All agree that code is expensive, because it can be considered ‘artisinal work’.
Between them, the EDA companies have made progress in developing software checking tools – tools to check memory leaks and tools to ensure data compatibility between classes and data structures. But progress remains slow in improving the ability to do more lines of code, while verification of the software remains a challenge. One EDA company runs regressions continuously on its code using 4000 servers.
Verification challenges
Verification looks to be the area in which changes in methods and technology will come first – driven by the needs of markets that are perceived to have the highest development costs, such as safety critical systems, but then trickling down into other areas such where reliability, availability and serviceability (RAS) are important.
Richard York, vice president of embedded marketing at ARM, says: “The needs of RAS and safety overlap. A vast majority of stuff in safety has nothing to do with safety; it’s about quality and how you define the product you want to build. How do you track those requirements through the design process? How do you make sure you’ve tested the product so that it conforms to the requirements? And then capture an audit trail that covers all those things.”
The core approach used in safety-critical systems development is that of the V model. The left-hand side of the V starts with clearly defined requirements. From there, the system is refined and elaborated to implementation. The right-hand side of the V implements the tests, starting with low-level tests of the implementation rising towards the final check that ensures all requirements have been satisfied.
“All of it is just good common sense quality design processes and creating a usable chain of documentation,” York says. “You document the assumptions of use and the expectations that can be placed on the features you’ve implemented. That gives you the ability to audit all the way through the design chain even if the implementation is jumping from one company to another.”
Jim McElroy, vice president of marketing at LDRA, says chipmakers have begun to see the advantages of building more rigorous software processes, based on experience with having to deliver compliance packages for ISO 26262 to support sales to automotive or medical-industry customers.
Although adopting a requirements-driven process implies a strict waterfall development flow that is only compatible with large projects with long lead times, this need not necessarily be the case, says Rod Chapman, director of Protean Code. He argues that some aspects of agile development can be applied to the high-integrity approach.
Some requirements can easily be defined in advance with very little knowledge of the final application, such as the need for a machine tool to only activate when a safety curtain is in place. Other more detailed requirements can be created and iterated during development itself. The key to doing this successfully is continuous integration: bringing successive code modules into a prototype that evolves over time. Repeated regression tests ensure that each new version does not reactivate old bugs and that the prototype continues to satisfy the requirements defined up to that point. As EDA companies have foundm regression carries a cost.
“Agile [software development] tends to assume the plentiful availability of target hardware where you can do regression testing in five minutes. That’s good for people building web services. You can always fire up more servers on Amazon web services to get more processor power, but those building embedded systems often don’t have any target hardware at all until late in the project,” Chapman says.
“Maybe we shouldn’t do more testing, but more static analysis,” Chapman says, pointing to the ability of formal tools to take on much of the work needed during regression testing, although it will not completely replace dynamic verification, whether on simulators or hardware prototypes. The approach could rekindle interest in the adoption of formal-verification techniques.
Attempts in the late 1980s to bring formal verification to software development largely failed. But hardware designers have successfully applied formal verification to reduce the amount of time it takes to verify complex designs.
“If there is one lesson from hardware, it is they were 20 years ahead of us in learning static verification. The hardware community is a decade ahead of us in formal verification. There are plenty of success stories of getting this to work,” Chapman notes.
Other static techniques, such as architectural analysis, could become increasingly important in embedded software, driven by the experience of safety-critical systems. Neil Langmead, technical consultant at Emenda described in a recent verification seminar organised by consultancy and tools supplier TVS how analysis can support more maintainable systems. “Many of the safety standards talk about modularisation and complexity. We can analyse that,” he said.
Looking at dependencies
Tools such as Lattix Architect will look at the dependencies between code modules to ensure that they follow a predictable pattern and do not result in code in, for example, a data management layer accessing a module several layers above it in the application domain without going through defined interfaces between the two. Techniques such as programming by contract, originally developed by Bertrand Meyer for his Eiffel language, in which the interfaces between modules have clearly defined rules that must be obeyed by both parties have also re-emerged.
Although the existing framework for developing safety-critical system can inform other sectors, the problem space for high-integrity systems is becoming fuzzier. Applications such as self-driving vehicles raise issues of how to verify systems comprising many independent embedded systems designed by different teams and where the failure modes are difficult to pinpoint. Some of them will be caused by deliberate exploits of code that was not identified as vulnerable during development.
Professor Christoph Grimm of the University of Kaiserslautern says it is becoming too difficult to analyse all the possible failures of a system. “What’s worse than uncertainty is being uncertain about what uncertainty is. We should focus on the resilience of the system, rather than just correctness.”
“For cyber-physical systems we should, in order to be able to guarantee safety security and dependability, be able to model all uncertainties and attacks in a comprehensive way at design time without focusing on individual point-to-point connection. We need to prove resilience and show that a system is able to cope with a variety of modes injected by an attacker.”
Efforts to build new verification techniques in the safety-critical field to deal with systems-of-systems problem such as automated vehicles could lead to an improved ability to deal with the increasing sophistication and aggressiveness of hacks across the software industry, but it could still take a long time for many of the techniques to trickle down.
“The economic incentive scheme for software is really odd. There are good practices out there but they are still not being adopted,” Chapman concludes.