Real-Time Design

The design of real-time software must incorporate all of the fundamental principles and concepts related with high-quality software. Additionally, real-time software poses a group of unique problems for the designer.

•    Representation of context switching and interrupts
•    Concurrency as manifested through multiprocessing and multitasking
•    Inter task synchronization and communication
•    Broad variations in communication rates and data
•    Representation of timing constraints
•    Asynchronous processing
•    Unavoidable and Necessary coupling with operating systems hardware and other external system elements

It is worthwhile to address a group of specialized design principles which are particularly relevant during the design of real-time systems. Kurki-Suono [ KUR93] elaborate the design model for real-time software;

All reasoning whether formal or intuitive, is performed with any abstraction. Thus it is important to understand that type of properties is expressible in the abstraction in question. In connection with reactive systems this is emphasized through the more stringent want for formal technique and through the fact which no general consensus has been reached about the models which should be used. The Rigorous formalisms for reactive systems range forma procedure temporal and algebras logics to concrete state-based models and Petri nets and various schools keep arguing about their relative merits.

He then describes a number of modeling principles which should be considered in the design of real-time software [KUR93]:

Explicit atomicity: It is necessary to describes atomic actions explicitly as component of the real-time design model. An atomic action or event is a well- limited and constrained function which can be executed through a single task or executed concurrently through various tasks. An atomic action is invoked only through those tasks participants who require it and the results of its execution affect only those participants no other components of the system are affected.

Interleaving:While processing can be concurrent the history of some computation should be characterized in a way which can be obtained through a linear sequence of actions.  By starting with an initial state a 1st action is enabled and executed. As a result of this action the stat is change and a 2nd action occurs because various actions can occur in any given state dissimilar results (histories) can be spawned from the similar initial state. This non determinism is essential in interleaved modeling of concurrency [KUR93].

Nonterminating histories and fairness: Processing history of a reactive system is assumed to be infinite.Through this we mean which processing continues indefinitely or stutters until some event causes it to continue processing. The Fairness needs prevent a system from stopping at some arbitrary point.

Closed system principle:  A design model of a real time system should encompass the software and the environment in that the software resides. Actions can thus be partitioned into those for that the system itself s responsible and to those which are assumed to be executed through the environment

Structuring of state:    The real-time system can be modeled as a group of objects within each of model its own state.

Software engineer should consider every of the concepts noted above as the design of real time system evolves.

over last two decades a number of real time software design techniques have been proposed to grapple with some or all of the problems noted above.  Any approaches to real time design extend the design technique discussed in chapter 14 and 21 example for data flow [WAR85], [HAT87] data structure [JAC83] or object  -oriented [LEL90]  techniques. Others introduce an overall separate approach using message passing systems or finite state machine models. Petrinets, or a specialized language as a basis for design.