Five ways to make embedded development agile
Agile methods and continuous integration grew out of the Smalltalk and Java communities and are now pretty standard in pure software development environments. However these techniques have so far struggled to gain a foothold in embedded design despite the advantages of less defects and faster releases.
Embedded software and tool development share a lot of the same problems, from developing real time software to the dependence on hardware and physical interfaces, and ultimately you end up testing the applications, says Gallop speaking at the Intelligent Testing Conference in Bristol, UK, this week. “At SN Systems we develop programming tools for very large game software with millions of lines of C++ and we make extensive use of agile and continuous integration practices,” he said.
1. Deliver working software regularly
That may seem obvious, but very often in embedded developments testing happens at the end of a project. That’s a problem that’s driven by the high cost of hardware and manual testing, but agile development says deliver working software regularly. To do this you really need hardware that is allocated permanently so that you can test the code regularly, and you need to incrementally automate the testing process so you can buy time with overnight testing.
2. Use a rugged, test driven development
Unit testing is a key part of agile development, and I/O is a key part of this. Separate out the I/O from the logic as much as possible so that you can test these independently. For example we record stream from a game controller and play them back as test stubs for the I/O, rather than using simulation or simulated test streams.
This is all part of a test driven environment where you write a test, then you write your code, compile it and test it, maybe ten times a day. It may seem a lot but the benefits of producing reliable, tested code regularly pay back quickly.
Use Defect Driven Testing. It may not be possible to test everything (that’s a big discussion) but whenever you fix a bug, you should write a test. As bugs tend to cluster, the area that keep giving you problems will get more tests, improving the quality of the code.
3. Use a Continuous Integration (CI) server, don’t build your own
CI servers are not design for embedded projects but it is possible to use them in the embedded space by using wrappers and presenting the code as Java in a CI tool. This also means using standard formats such as junit.xml.
These tools are based around the Web and databases, and a team with C and C++ skills may not have the right skills, so use the best, modern, web sharing tools such as Ruby, Django or NodeJS. Whatever you do, don’t go building your own in HTML or SQL as this will take up a lot of your valuable engineering time.
4. Keep the build fast
Embedded systems often have very large code bases and archaic build system, which is why they take many hours. The solution is unfortunately that you have to replace the build system to support parallel and distributed builds so that a build can be achieved in ten minutes. You can replace the build system – the code should be the most important thing, and if builds are completed in minutes you save months in development.
With lots of quick builds, it is important to log everything and ‘fail loudly’ – there can be intermittent bugs as a result of pre-production hardware or software, but they could also be real-time issues. This may be the only time you see a bug and you need to capture warnings and static analysis checks on the CI server so other people know as part of the distributed development process.
Developers can fix tens to hundreds of checks in a day, and it is better to fix the checks before you go to a build and it becomes a bug. But it is important to have the right infrastructure to capture and manage all this test data.
5. Automate your build and test
Scarce hardware can also be an issue. We have a batch queue for hardware so we can fire jobs at the board and can parallelize later. This means the board is fully used, and means we can justify having our own hardware as we are running ten builds a day on it.
And you have to acknowledge that no test environment may be right for your project, but that doesn’t stop you using agile techniques and continuous integration. You may have to build your own test environment or adapt an existing one, and there is an upfront cost. But making this as simple as possible and using good software design practices helps to manage that cost.
But t is possible to implement agile techniques and CI in an embedded development, and this brings significant improvements in the quality of the code developed and the length of the projects
SN Systems has been producing development tools for the console industry since 1988, starting with Nintendo. As new platforms appear, SN Systems is able to create stable and sophisticated tools to work with a new target and new features are continually added on request, driving the agile development process. As part of Sony’s SCEI Entertainment division since 2005, SN Systems is able to draw from a range of different resources as well as existing experienced staff. Closer ties to the R&D departments within SCEI means that development tools such as ProDG, Tuner and SN-DBS, can now be designed with even greater amounts of detail and compatibility to SCEI’s hardware development tools.
The Intelligent Test Conference in Bristol was organized by Test And Verification Solutions (TVS) www.testandverificationsolutions.com
www.snsystems.com
Related stories
NXP expands I2C with Agile I/O
Agile code tool optimized across multiple sites and repositories
EU agile project radically slashes software development time
Fixing demotivated engineering teams
Software version management system boosts distributed teams
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
