This book is about engineering. It is an attempt to clarify the role of the software system engineer in the design of software where its operational correctness is dependent on its ability to work within time and machine capacity constraints identified prior to its design. The view expressed here is that real-time software engineers are responsible creating product designs which address not only the functional characteristics of the product, but the time and storage constraints as well. The created design is seen as a tool for the system developers, rather than a milestone document for the customer.
This is not to say that craft should be absent from a real-time system design. To be effective an engineer has to have a well developed understanding of algorithms, languages, operating systems, database engines, and the other system building blocks. Becoming familiar with components may require some degree of tinkering. Moreover, a creative edge is a basic prerequisite for solving new problems. But the prime contribution of the engineer should not be to pick out components based on a hunch, nor to jot down data and control flow diagrams in an attempt to portray an attractive design. The prime contribution of the engineer should be to present a valid, veritably correct solution prior to the construction of the system.
So what does a valid, verifiable design for a real-time system look like? There are a handful of software engineering texts which focus the student's attention on design languages. Students are sometimes led to believe that the notations themselves are the embodiment of design. Some of these texts promote particular graph-oriented languages for expressing data and control flow. Others promote non-graphical design languages. Ada, for example is promoted as a design language. While there is no doubt that Ada Program Design Language (PDL) plays an important role in Ada software development, it is no more a "design" than is a blueprint of a section of a bridge. It serves to direct implementation, not understanding, just as a blueprint serves to direct fabrication. One can not compute structural strength from a blueprint. Information about the strengths and thermal properties of materials must be added to the blueprint if you wish to compute structural strength. Similarly, information about scheduling and performance must be added to PDL in order for analysts to know whether or not time constraints will be met. Likewise, information about memory usage is needed to verify that the software won't run into memory problems.
The issue is not at all the form of the design. The issue is its substance. And what is the substance of a good design? As an analogy, consider this situation from civil engineering: A high bridge is to be built across a mile-wide, fast river. The bridge is to carry four lanes of vehicular traffic and it must be high because the river has a canal adjacent to it that is used for oceangoing going cargo ships.
Foolish? of course! It would take a great stroke of luck to erect a bridge this way on budget, and on schedule, that could carry its load safely without constant attention from a team of maintenance blacksmiths. It is likely that the bridge will lean, sway in the wind, buckle on hot days, and that sections will fail without warning even though the bridge once held heavier loads during testing. Indeed, it is doubtful that a bridge like this could ever be certified as safe because knowledge of how load is distributed throughout the bridge may not be attainable.
No doubt bridges and other structures have been built using the artisan approach. Success is probable for small scale projects, but not for large scale, complex projects like the bridge described.
The point here is that engineering practice involves an analytical understanding of the work to be accomplished. A design of a system is the vehicle for reasoning about the system. When we rely on an instance of a system as a vehicle for reasoning about how it works, we become restricted to conducting experiments on the system's behavior to answer questions about its character. By contract, a good design gives us the opportunity to predict system behavior for any situation.
Real-Time System Engineers:
The substance of a good design can be documented in a number of ways. Graphic methods showing activity decomposition, data, and control flows are appropriate if they capture information which makes verification and validation possible. PDL formats and standard English are likewise suitable. The format used should fit the organization's needs in regard to project size, experience, support tools and management style. This text does not address the selection of design documentation format except to point out some obvious deficiencies in mainstream formats. But even these deficiencies can be overcome once the design team and management are aware of them and augment the mainstream notations with appropriate time and spatial constraint information.
As you read through this text it is best to give it a careful first. reading so that you become acquainted with the subtitles of real-time engineering concepts. Working through the problems will reinforce your understanding and build up your acumen. When you get to sections discussing Computer-Assisted-Software Engineering (CASE) tools you may be fortunate enough to have access to professional quality tools through your employer or university affiliation. If you do, make use of whatever you have. For those with no CASE tool access, paper and pen work very well.
A Simple Exercise:
Software design is a vital step in the string of activities which form the software development process. But the software development process never gets started for you unless the company you work for happens to have won the competition for the development contract. No one wins a software development competition without a good proposal! An important ingredient of the proposal is the section where you describe how you are going to design the real-time software.
Assume you are on a proposal team. Your job is to explain how you are going to design a real-time software system controlling something critical. Perhaps the system is a component of an aircraft or submarine. The software is stimulated with a number of periodic and non-periodic data packets which must be processed, and which produce time constrained outputs. Figure 1-1 is a generic representation of such a system. Note that some of the processes make use of a disk to store or retrieve data.