Agile development of real-time systems
Agile development of real-time systems
Earlier we raised two issues on whether agile development is desirable and whether it is feasible. Before we argue on how to effect agile development of real-time systems, we first argue why agile development is a good idea.
Even though some real-time systems have well-defined requirements from the outset, many do not. As an example consider a dock for music players. There are well-defined real-time requirements in terms of generating the USB signals (at 11 MHz), USB frames (at 1 kHz), and the delivery of real-time audio data to a word clock (of, for example, 48 kHz).
But interaction between those components may not be well-defined, for example, the relation between a host-defined 1 kHz USB-frame-clock and a device defined 48 kHz word-clock may be non-trivial since host and device may each have their own crystal clock.
In systems like this there are in general three reasons why an agile development method (Figure 2, below) can be exceedingly useful:
1. Standards are often open to interpretation and only settle after years. When following a traditional development method one would implement a complete system, following one interpretation of the standard, and during the final testing the discovery would be made that the implementation of the standard does not interoperate with other implementations.
2. End-user requirements as to how the device should behave will change. Putting a strict deadline on the user-requirements may be an easy way to manage the process, but will ultimately disappoint the end-user.
3. A special case is the development of systems as part of a standardization process. This, by nature, requires an agile development method, and helps to quickly converge on a standard that is tried and tested.
Click on image to enlarge.
In all those cases an agile development method is desirable. In order to effectively use an agile development method, we must enable a quick and iterative development cycle. In the case of real-time systems, this means that the real-time characteristics have to be met on every iteration of the development cycle. This requires:
1. Software to be composable and still meet timing requirements. This means that two software components can be composed together without disturbing each others timing requirements;
2. A timing analyzer that checks real-time properties of the program, in addition to the normal tool chain used in the development process.
A concurrent architecture with predictable timing by its very nature presents us with composability. Two threads with known timing properties can be scheduled concurrently retaining their timing properties.
Within a thread, a timing analyzer establishes the timing properties of that thread and checks those against the required timings specified by the system designer. (Just like the compiler checks types and function arguments.)
This verification process is only feasible if the underlying architecture has predictable timing properties - but it leads to a dramatic shortening of the testing process since many timings of the program are either known to be met, or known to be failing.
The time that it takes to go through a compilation and timing analyser is in the order of seconds or minutes, as opposed to the hours that unit testing and a full regression may take.
What this means for agile development is that a team of programmers can spin through an iteration cycle. If they break timings they will know quickly, and they can correct those timing deficiencies, until they are confident that all timings are met. It reduces the number of (time consuming) regressions, and the remaining tests can focus instead on complex timing and functional properties.
In order to speed up regression tests, plug-ins can be made for the simulation environment that enables the most important regressions to be ran automatically in a simulation environment, requiring only a small number of tests to be executed on real hardware.
Loading comments... Write a comment