Introduction:
This is a book about real-time software system development. It is distinct from books about operating systems, networks, languages, scheduling theory, distributed systems, CASE tools and programming languages. Wile these other topics are discussed within the text, they are not the focus of the book.

 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.

 Design:
Here a "design" is regarded as the instrument for reasoning about how a system works. Reasoning about a system using a design as abstraction is distinctly different from the common practice of system developers who function as artisans, relying on intuition for structural decisions and external appearance for judging correctness.

 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.

 Verifying Correctness:
The general notion of verifying the correctness of a design for a time and memory constrained system is glaringly absent from most treatments of real-time system development, with the exception of recent texts on Rate Monotonic Analysis (RNM). While these do acknowledge the problem of scheduling verifiability and also introduce the concept of verifiable scheduling techniques, they deal in only one aspect of real-time: rate monotonic hard real-time scheduling.

 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.

 An Approach:
How do the bridge developers approach this challenge? One way would be to hire an artist to draw a set of pictures of a proper looking bridge. The first picture would show the entire bridge as it might look to an individual standing two miles away from the structure. The artist would continue by drawing close up details of what the beams, road surface and other visible features might look like. When the artist's work is complete, a few hundred expert blacksmiths can be hired to hammer out the individual parts and connect the parts together. It would be up to the blacksmiths to figure out how to put the components together and make the bridge stand, and to test the bridge for "strength" as it gets assembled. A retired blacksmith can be hired to make decisions about materials and guesses about how long it will take to put up the bridge. A concrete crew can be assigned the problem of the footings. A road surfacing team can be hired later to put a good layer of asphalt down as a road surface. Finally, all the blacksmiths could drive the heaviest cars they could find over the bridge to make sure it is safe enough for general use.

 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 Way:
What we really need is to start with an assessment of soil mechanics, wind and snow load, and river dynamics. (Is there a tide? Is this the Mississippi?) From these results an engineering team can assemble a picture (a model) of a bridge whose static and dynamic properties are knowable analytically. The physical properties of every piece of the bridge can be computed prior to spending money on fabrication. This analytical insight is the tool we need to certify the "correctness" of the bridge. If the bridge is built according to plan, it will work. As the bridge is erected, its components can be individually tested within the load range to which they will be subjected in order to verify the correctness of individual pieces. As assemblies are placed on the incomplete structure, strain gauges can measure loading effects on critical members to verify that deformations are within expected limits.

 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:
Real-time system engineers are quite similar to civil engineers. Both disciplines need to produce . good designs. While the civil engineer is constrained by the environment in which the bridge is to be built, so too is the real-time system engineer constrained by the environment in which his or her product is to function. But instead of soil mechanics, tide, snow and wind, the real-time system engineer faces languages, compilers, operating systems, networks, CPU and memory characteristics. Instead of traffic load issues, there are function activation, scheduling, and process requirements. And, just as civil engineers linearize their characterizations of critical properties (such as material elasticity) so too can real-time system engineering (such as CPU utilization). This text presents one particular linearization involving a few practical techniques for assessing characteristics of components that matter to real-time system designers. Others are possible.

 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:
Here Is on opportunity to collect your thoughts on how a design should be created and how It should be used. When you complete the exercise fold your results and tuck them into the book. When you are done with the book, repeat the exercise and compare your final results with your initial results.

 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.

1. Write one page or more describing how a real-time operating system is different from normal commercial operating systems like UNIX.
2. Write one or more pages on how your company designs real-time software. You can be as creative as you wish. Include the notion of fault tolerance.

 Evaluation Criteria:

1. Does the proposal describe how the real-time design will be conducted, or does it simply say experienced people will do the design ?
2. How does the proposed effort expect to validate the design for correctness with regard to memory and performance constraints? (Or does it just say that it will validate without explaining how?) Does the proposed approach defer the issues of time and memory constraints to integration time? (E.g., does it say that first they'll get it to "work" and then worry about making it "fast enough" later?)
3. Does the proposal regard real-time operating systems as fast, efficient and reliable versions of mainstream multitasking operating systems, or is there a precise list of characteristics essential to how they propose to do the design?
4. If the proposal states that a particular scheduling algorithm is to be used, does it explain how this will be done for disk accesses? Does it simply say that a particular scheduling algorithm will be used or does it explain how it will be applied?