Can embedded projects that call for both custom hardware and software be agile? It’s a question that a conference organized by UK training company Feabhas sought to answer on Wednesday (May 3). The answer is yes, after a fashion. Agile purists should probably look away before they get upset.
“Can embedded be agile?” asked Feabhas CEO Niall Cooling in his opening talk. “By the book? As it stands, it’s not a straightforward thing. You can’t just take a book and apply it to embedded development. But, fundamentally, the answer is yes. But there has got to be a mixture between the evangelical view and the pragmatic.
“The big challenge is one of mindset. But I still see that with people saying you can’t use C++ for embedded.”
Lessons from the past
Rod Chapman, principal engineer at Altran UK, has argued for some time that concepts adopted by the Agile Manifesto, which was developed in 2001 at a ski resort close to Salt Lake City, can be found a decade earlier in the embedded world. And there are things done in high-criticality systems design that can be ported over to mainstream agile development.
“There is stuff we’ve been doing for 20 years that the agile people have completely missed out on,” claimed Rod Chapman, principal engineer at Altran UK.
In hardware engineering, Craig Larman and Victor Basili described in a 2003 edition of IEEE Computer that the X-15 hypersonic jet used incremental development concepts and some of those were used in software written for NASA’s Project Mercury. The same year, Chapman and colleague Peter Amey, then working at Praxis Critical Systems before its acquisition by Altran, described at the ACM’s SigAda conference the use of static verification in concert with concepts from Extreme Programming. Static verification is likely to form a big part of agile processes in embedded systems in much the same way it has become a core part of RTL hardware verification.
Chapman said the first clear proposal for agile-type concepts in safety-critical software appears in work presented by Felix Redmill at the Safecomp conference at the end of the 1980s. Redmill described the idea of incremental delivery of safety-critical systems that he later expanded on in a book.
Embedded versions of agile that gone into use at companies such as Altran, Dyson, and Ericsson have acquired a number of elements from the world of quality engineering, such as kanban boards, speakers noted. Most if not all have seized on concepts such as continuous integration that make heavy use of automated processes.
“I have seen a mechatronic system being built through to deployment in an automated way,” Cooling said, but pointed out the development team had to plan and construct their environment carefully.
“The biggest bugbear at the moment is that many of the tools [used in embedded projects] do not support agile well. The tools we’ve got today haven’t really changed that much. They are fundamentally the same tools as they were in the 1990s,” Cooling said. “We have to change the way we build software. Many companies are, today, completely reliant on the tool to do the build for them. We’ve got to get away from that.”
New wave of tools
Cooling pointed to open-source tools such as Scons and Jenkins as well as the Docker virtual-server technology as providing a set of services that can be harnessed more easily for continuous integration and automated builds for multiple targets. “These are tools that the agile community is using that we can apply,” Cooling said.
The EDA companies, by contrast, have more of a head start through their own adoption of open-source technologies such as Jenkins to support regression-intensive verification plans. In common with hardware engineering, embedded teams such as those at Altran have embraced formal and static verification as part of the continuous-integration process. This is one of the “blind spots” of conventional, desktop-oriented agile development, Chapman noted.
Cooling said the biggest benefit he saw in teams that embraced agile concepts lay in improved communication. However, there are a number of cultural and customer-relationship issues that will control how agile a project can be. Some business models simply do not lend themselves to the idea of incremental delivery and continuous updates, speakers such as Chapman noted.