1.4 Software for Real-Time Applications – Some General Comments
In later chapters, the total design process for real-time systems is described. We'll be looking for answers to questions such as:
- What truly needs to be done?
- How should we specify these needs?
- How can we ensure that we're doing the right job (satisfying the system requirements)?
- How can we make sure that we're doing the job right (performing the design correctly)?
- How can we test the resulting designs for correctness, performance, and errors?
- How do we get programs to work correctly in the target system itself?
Before doing this, let's consider some general problems met in real-time systems work and also dispel a few software myths. And a useful word of advice: don't believe everything you read – question any unsupported assertions (even in this book).
The following quotations have been made (in print) by experienced software practitioners.
"For real-time systems ... programs tend to be large, often in the order of tens of thousands or even of hundreds of thousands of lines of code." This generalization is wrong, especially for deeply embedded systems. Here, programs are frequently small, having object code sizes in the range of 2-64 kBytes (however, two factors, in particular, tend to bloat embedded code: support for highly-interactive graphical user interfaces and support for internet communication protocols). It is a big mistake (one that is frequently made) to apply the rules of large systems to small ones.
"At the specification stage ... all the functional requirements, performance requirements, and design constraints must be specified." In the world of real-time system design, this is an illusion. Ideas like these have come about mostly from the DP world. There, systems such as stock control, accounting, management reporting methods, and the like can be specified in their entirety before software design commences. In contrast, specifications for real-time systems tend to follow an evolutionary development. We may start with an apparently clear set of requirements. At a much later stage (usually, sometime after the software has been delivered), the final, clear, but quite different specifications are agreed.
"Software costs dominate ...." This is rarely true for embedded systems. It all depends on the size of the job, the role of software within the total system, and the number of items to be manufactured.
"Software is one of the most complex things known to man ... Hundreds of man-years to develop system XXX." Well, yes, software is complex. But let's not go overboard about it. Just consider that the development of a new nuclear propulsion for submarines took more than 5,000 man-years (at a very conservative estimate). And it involved large teams, skilled in many engineering disciplines, and based at various geographically separate sites. Is this an "easy" task compared with software development?
"Software, by its nature, is inherently unreliable." I think the assumption behind this is that software is a product of thought, and isn't bounded by natural physical laws. Therefore, there is a much greater chance of making mistakes. This is rather like saying that as circuit theory underpins electronic design, hardware designs are intrinsically less prone to errors. Not so. Delivered hardware is generally free of fault because design, development, and manufacture is (or should be) rigorous, formal, and systematic. By contrast, software has for far too long been developed in a sloppy manner in cottage industry style. The industry (especially the industrial embedded world) has a lack of design formality, has rarely used software design tools, and has almost completely ignored the use of documentation and configuration control mechanisms. Look out for the classic hacker comment: "my code is the design."
The final point for consideration concerns the knowledge and background needed by embedded systems software designers. In the early days of microprocessor systems, there was an intimate bond between hardware and software. It was (and, in many cases, still is) essential to have a very good understanding of the hardware, especially for I/O activities. Unfortunately, in recent years, a gulf has developed between hardware and software engineers. As a result, it is increasingly difficult to find engineers with the ability to bridge this gap effectively. Moreover, larger and larger jobs are being implemented using microprocessors. Allied to this has been an explosion in the use of software-based real-time systems. As a result, more and more software is being developed by people who have little knowledge of hardware or systems. We may not like the situation, but that's the way it is. To cope with this, there has been a change in software design methodologies. Now the design philosophy is to provide a "software base" for handling hardware and system-specific tasks. This is sometimes called "foundation" or "service" software. Programmers can then build their application programs on the foundation software, needing only a minimal understanding of the system hardware. The greatest impact of this has been in the area of real-time operating systems.