Limitations of existing software design techniques
We begin the main part of this chapter by considering two examples which illustrate the limitations of standard design techniques when used for embedded system development.
Cruise-control system
As a first example, we will consider a cruise-control system (CCS) for a road vehicle. A CCS is often used to demonstrate the effectiveness of real-time software design methodologies (for example, see Hatley and Pirbhai, 1987; Awad et al., 1996). Such a system is usually assumed to be required to take over the task of maintaining the vehi- cle at a constant speed even while negotiating a varying terrain, involving, for exam- ple, hills or corners in the road. Subject to certain conditions (typically that the vehi- cle is in top gear and exceeding a preset minimum speed), the cruise control is further assumed to be engaged by the driver via a push switch on the dashboard and disen- gaged by touching the brake pedal.
As an example, an outline process-oriented (‘structured’) design for such a system is illustrated in Figure 2.2 to Figure 2.5. This design is adapted from that suggested by Hatley and Pirbhai (1987) in a standard text on real-time software design. Starting at the highest level of abstraction, Figure 2.2 shows the ‘context diagram’ for the system. Figure
shows the corresponding Level 1 dataflow diagram, which describes in more detail the processing carried by the process ‘simple cruise control’ in Figure 2.2. Figure 2.4 in turn shows the state-transition diagram associated with ‘main control process’ in Figure 2.3.
To complete this simple design, we need to define more precisely the operation of the two processes ‘set speed’ and ‘maintain speed’. Of these, the second is the more complex and will be discussed here. Hatley and Pirbhai (1987) present the ‘process specification’ given in Figure 2.5 for their version of the ‘maintain speed’ process.
Overall, there are a number of problems with this design solution. For example, little consideration is given to the system architecture to be employed, and the consequences this will have for the rest of the design. In addition, Hatley and Pirbhai (1987) present their version of the control algorithm at the heart of the system (see Figure 2.5) largely
Set: Subject to:
[Note: VTh = Throttle setting; SD = Desired speed; SA = Actual speed. The throttle setting is assumed (here) to be proportional to an output voltage: a 0V output closes the throttle, and an 8V output sets it fully open. The intention is to vary the throttle setting when the actual speed varies by more than 2mph above or below the desired speed. The rate of throttle movement is restricted to 0.8V / second.]
without comment. They do not consider ‘standard’ control techniques, such as ‘proportional-integral-differential’ (PID) control, as solutions to this problem,2 and give no indication how the effectiveness of the chosen approach should be assessed (or even that it should be assessed). This is not particularly unusual in software texts: for example, some ten years later, Awad et al. (1996) describe, in considerably more detail, an object- oriented design for the same cruise control system and, again, largely ignore these issues.
To design many embedded systems successfully, including this cruise control system, requires not just knowledge of software engineering and microcontroller hardware, but also contributions from related technical and engineering fields, often including instru- mentation, digital signal processing, artificial intelligence and control theory. In our experience, such contributions are often essential to the success of real-time software projects, yet they are not part of the formal training of the majority of software engi- neers and are frequently ignored in books and papers on real-time software design.
Alarm clock
Of course, a CCS is a specialized product and it might reasonably be argued that most developers would not expect to tackle the production of such an application without having previous experience in the automotive area. However, similar problems arise if in the simplest of embedded applications.
Assume, for example, that you have been asked to develop an alarm clock applica- tion that operates as follows:
● Time is displayed on an LED display.
● The time may be adjusted by the user.
● An (optional) alarm will sound at a time determined by the user.
A sketch of the required user interface is given in Figure 2.6.
To create the design for such an application in a ‘traditional’ manner, we might begin by drawing a context diagram (Figure 2.7).
As with the CCS, the notation can only assist us in recording design decisions: it cannot assist in making those decisions. For example, in this type of application, a basic require- ment is to display information on the LED display. In most cases, to reduce costs, a multi- plexed display will be used. As we discuss in Chapter 21, in a multiplexed, 4-digit, LED dis- play, we need to refresh the display approximately every 5 ms. The need to update this display at this frequency will have implications for the software architecture of the whole application and must be taken into account very early in the design process. If the design- er of the system is unaware of this basic requirement, then many of the assumptions that underlie the design will be wrong, and a large amount of expensive and time-consuming redesign will be required when the project reaches the implementation phase.
