Real-time concepts for Software/Hardware Engineering

Transcription

1 Real-time concepts for Software/Harware Engineering Master s thesis of M.C.W. Geilen Date: August 996 Coaches: ing.p.h.a. van er Putten ir.j.p.m. Voeten Supervisor: prof.ir.m.p.j. Stevens Section of Information an Communication Systems Faculty of Electrical Engineering Einhoven University of Technology

2 Abstract The SHE metho is a metho for the specification an esign of istribute communicating harware / software systems. Part of this metho is the formal specification language POOSL. POOSL is an object oriente language for the specification of parallel communicating processes. In its current version, POOSL is unable to escribe timing behavior. Since many of the systems that nee to be esigne are real-time systems, POOSL nees to be extene with timing primitives. Such an extension is stuie in this report. Existing real-time algebras an real-time programming an specification languages are stuie. Important aspects of real-time specification are iscusse an concepts are chosen as a basis for the extension of POOSL. The language POOSL is extene with time. The meaning of existing POOSL primitives in relation to time is investigate an a new primitive is ae that can specify quantifie timing behavior:. Further, the communication between processes is extene with timing to moel the occupation of a channel uring communication. After this, all necessary changes to the POOSL language are liste completely. The formal semantics of POOSL allows the use of tools such as verification an behavior preserving transformations. These tools are base on equivalence relations between POOSL specifications. These relations are reefine for the new language. Furthermore, the relationship between time an untime specifications is investigate. It is possible to efine an abstraction function that computes from a time POOSL specification, its untime equivalent. Finally, the expressive power of the new language is stuie. A number of typical aspects of realtime are investigate, such as moeling computation time, moeling communication time, timeouts, etcetera.

3 Contents Introuction 3 SHE an POOSL 4. The SHE metho The language POOSL Real-time systems 6 4 Timing concepts 8 4. Introuction Properties of the real-time extension The notion of abstract time Properties of process algebras an languages Overview of the most important characteristics Overview of real-time programming languages The selection of timing concepts an primitives 9 5. Introuction Evaluation of concepts Extening the semantics of POOSL 3 6. Introuction Aing the time relation to POOSL Introuction Timing of processes The choice Time an interrupts Time an guare commans Parallel composition an synchrony Aing a elay primitive Introuction The elay statement The elay statement with expressions Evaluation an execution Timing of the renez-vous Introuction Blocking a channel uring communication Specification of channel elays Implementation of channel elays

4 CONTENTS 7 Moifications to POOSL Introuction Axioms an rules for aing time to POOSL Axioms an rules for aing a elay-comman to time POOSL The channel elay Other moifications Relations between time specifications Introuction Bisimulations an equivalences Isomorphism Semantics conservation Abstraction function Evaluation of the ae primitives 5 9. Introuction Moeling computation time Timeout construction Watchog construction Communication elays Broacasting messages Absolute time Perioic execution Grain of interruptability Conclusions 57 A Formalism, notations an efinitions 58 A. Process algebras A. Definitions an notations B Abstraction function 60

5 Chapter Introuction The SHE metho (Software / Harware Engineering) is a metho for the specification an esign of istribute communicating harware / software systems. Part of this metho is the formal specification language POOSL (Parallel Object Oriente Specification Language). POOSL is an object oriente language for the specification of parallel communicating processes. In the current version of SHE, real-time constraints are escribe in ifferent Timing Requirement ocuments. These requirements cannot be expresse in POOSL. POOSL is unable to escribe timing behavior. Quantitative time is absent an behavior relate to timing is expresse as non-eterministic behavior. Since POOSL escriptions are in principle executable an can be use for simulation, it woul be esirable that these simulations woul also tell something about the timing behavior of communicating processes. Their behavior can then be checke against timing requirements. For this to be possible, new primitives are neee in POOSL that can express characteristics of the communicating objects with respect to time. A esigner can then escribe the time it takes to perform a computation, the time that a process is require to wait for communication, or verify whether interrupts are hanle in time etcetera. In this report, an extension of the language POOSL is stuie that allows specification an verification of timing properties in a POOSL moel. The POOSL language is base on the process algebra CCS (Calculus of Communicating System) of Milner [Mil89]. It is not possible in the context of this report, to give a full introuction to process algebras. The reaer is therefore assume to be familiar with the concepts an notations use in this kin of formalisms. A very tiny introuction is given in appenix A, together with references to better introuctory texts. Furthermore, familiarity with POOSL an its semantics is presume. This information can be foun in [Voe95B] 3

6 Chapter SHE an POOSL. The SHE metho A lot of information systems that are being esigne are implemente with a combination of haran software components. There are a number of esign methos for harware systems as well as methos for software engineering. However, there are not many methos that successfully support the esign of combine harware / software systems. At the Digital Information Systems group of the faculty of Electrical Engineering at Einhoven University of Technology, an object-oriente metho for co-specification, analysis an esign of software/harware systems is being evelope. the metho carries the name SHE, an acronym for Software Harware Engineering[PVS95]. SHE integrates informal an formal techniques an consists of a metho framework an a formal specification language POOSL[Voe95A] (Parallel Object Oriente Specification Language). The SHE metho is an object-oriente metho an shoul therefore lea to a minimum number of esign iterations an enable the reuse of previous esigns. The metho incorporates informal graphical tools, that are neee in the early phases of analysis an esign an for easy communication with non-expert customers. The metho also incorporates a rigorous formal specification language that allows unambiguous specification an the use of automate tools for verification, simulation, structural transformations etcetera. Some of these tools are being evelope. The framework of the SHE metho consists of four quarants, which will be briefly iscusse. Essential Behavior Moel This moel contains the escription of the original requirements. Object class moels are use to escribe ifferent object classes. Message flow iagrams visualize communication between objects. Instance structure iagrams show the actual instances of the various objects an ifferent bounaries. SHE istinguishes several kins of bounaries. Abstraction bounaries encapsulate collections of objects. Concurrency bounaries restrict their insie to be implemente sequentially. Distribution bounaries restrict the knowlege of objects insie, about the location of collaborating objects outsie. Implementation bounaries escribe a borer erive from the physical or logical structure of the system. Architecture Structure Moel An Architecture Structure Moel escribes physical or logical structure an timing requirements. It consists of an Architecture Structure Diagram, an Architecture Response Time Requirements ocument an an Architecture Decisions Statement. The Architecture Structure Diagram graphically represents the structure of a moel. In the Architecture Decisions Statement, all esign ecisions concerning the architecture are ocumente an motivate. 4

7 .. THE LANGUAGE POOSL 5 Implementation Structure Moel This moel escribes the implementation structure an consists of Implementation Structure Diagrams, an Implementation Decisions Statement an the Implementation Response Time Requirements. Implementation Structure Diagrams visualize the implementation structure. The Implementation Decisions Statement ocuments an motivates the implementation ecisions. Furthermore the Implementation Response Time Requirements, resulting from the implementation ecisions are ocumente. Extene Behavior Moel This moel escribes aitional behavior information, that is not in the Essential Behavior Moel, but which is the result of implementation ecisions.. The language POOSL The formal part of the SHE metho, the specification language POOSL[Voe95A], is an objectoriente language for the specification of parallel istribute communicating processes. POOSL is use for prescriptive specification, which means that a POOSL specification represents a possible implementation of the problem, but that other implementations might be equally vali. Some other languages are escriptive. They formally escribe what the system shoul o an not how the system shoul o it. This in orer to prevent overspecification of the system an to leave the esigner all freeom to choose an optimum solution. A prescriptive language has been chosen, because escriptive languages ten to be much harer to unerstan an to use. The anger of overspecification is not so much of a problem in practical situations. One is satisfie with a goo solution an is not necessarily intereste in the best solution. POOSL is use to specify the behavior of parallel istribute communicating processes an its concurrency an communication mechanism are base on Milner s CCS (Calculus of Communicating System)[Mil89]. POOSL has much expressive power. It incorporates static process objects an ynamic ata objects. Processes communicate using a synchronous renez-vous, aopte from CCS. The usual conitional, control an select statements, as well as interrupt an abort statements can be use. In orer to simplify the implementation of finite automaton behavior, the possibility of tailrecursion is ae. This is the ability to call a new metho from within another metho, while at the same time terminating the calling metho. This means that after the calle metho terminates, the calling metho will not be resume. Furthermore, the POOSL language is able to express hierarchy in a system in a way that is similar to that of CCS, by generating new clusters, using parallel composition, channel hiing an channel relabeling as in CCS.

8 Chapter 3 Real-time systems Software/harware systems that are esigne are often real-time systems. Real-time systems have some special requirements that o not apply to normal (software) systems. Timeliness an reliability, e.g., are of great importance. Young efines a real-time system to be [You8]: any information processing activity or system which has to respon to externally generate input stimuli within a finite an specifie elay Often the istinction is mae between har an soft real-time systems. Har real-time systems are those, in which it is absolutely necessary that responses occur within the specifie ealine. In soft real-time systems, response times are important, but the system will function correctly if ealines are occasionally misse. Important characteristics of real-time systems are[bw89]: Timeliness. Dealines shoul be met. If ealines are misse, appropriate action shoul be taken. The environment requires a response from the system within a fixe amount of time. A language to support the esign of such systems shoul be able to eal with time. Reliability. In many real-time applications, it is important that the system is robust an fault-tolerant. Parallelism. Often real-time systems are istribute an consist of a number of processes operating concurrently. The esign metho shoul support this parallelism. POOSL oes this by using parallel processes. The following features are important for methos that inten to support the esign of real-time systems: Maintainability. It shoul be easy to make small moifications or corrections to a esign. Reusability. A esign metho shoul allow easy reuse of components that have been esigne earlier. Moularity. The implementation of a subsystem shoul be encapsulate. Other part of the system can only cooperate with the subsystem by a efine interface. This allows the moification of the subsystem without implications for the rest of the esign. It supports the maintainability an reusability of the esign. Scheulability analyzability. Sometimes it is possible to analyze a specification for its execution time. This information can be use to scheule the computations on the available resources in such a way that ealines are guarantee to be met. It woul however require some severe restrictions on the programming language, because unboune loops, recursion an ynamic memory use cannot be allowe. 6

9 7 Many of the moern methos use the object-oriente paraigm. It has better moularity, maintainability an reusability than other languages that are function-oriente. The object-oriente paraigm is characterize by: Encapsulation. An object encapsulates the ata an the coe that efine the object. Access to the object is restricte to the exporte services of the object. Encapsulation leas to moularity. Inheritance. Inheritance is the ability to create a new class of objects, as a specialization of an existing class. The new class inherits all the properties an services of the base class. Multiple inheritance is the ability to create a new class inheriting the properties from more than one parent class. Polymorphism. This is the ability to use an object instance of which the actual class is etermine at run-time. A instance can, e.g., be specifie to be of class fruit an can be implemente by an object of class apple or of class banana. Where apple an banana are inherite classes of fruit. The language POOSL is an object-oriente language that supports parallelism. Although it oes not support inheritance an polymorphism (at this time), this makes it a suitable language to support reliability, parallelism, moularity an reusability. It oes not support scheulability analyzability, because that requires a restriction to the power of the language. One of the most important aspects of real-time esigns, timeliness is not supporte by POOSL. It lacks the necessary timing primitives to express the timing behavior of the concurrent processes. The extension of POOSL is intene to give POOSL these timing primitives.

10 Chapter 4 Timing concepts 4. Introuction In orer to escribe an analyze the behavior of real-time parallel processes, a number of languages, tools an algebras have been evelope. Some of the first algebras are Hoare s CSP[Hoa78] (Communicating Sequential Processes) an Milner s CCS[Mil89] (Calculus of Communicating Systems). Next to a number of algebras, also a number of programming languages supporting concurrency have been constructe. For a long time the concept of time was not expressible in these algebras or languages. In the last ecae however, methos are introuce that are also able to express real-time behavior or realtime constraints. Real-time extensions have been mae to many of the popular process algebras, an real-time programming languages have been introuce. POOSL is a formal specification language, base on the communication principles of CCS. It shoul therefore be possible to apply some of the ieas of real-time process algebras an languages to POOSL. In this chapter, the principles an characteristics of a number of existing (real-time) process algebras an programming/specification languages are iscusse. Some of the notation of process algebras an the rules that efine their meaning are explaine in appenix A. 4. Properties of the real-time extension A new formal language, base on POOSL, is to be create, that can express real-time aspects of the esign as well. A lot of work has alreay been one on POOSL. To make sure that (part of) this work can be retaine, there are a few constraints for this extension [NS9]. The untime version of POOSL will be enote as UPOOSL an a real-time extene version as TPOOSL. Subset. Processes of untime POOSL are still vali processes in the time extension. This way, POOSL escriptions written for UPOOSL are still (syntactically) vali in the context of TPOOSL. Semantics conservation. The behavior of an untime POOSL process an its equivalent in the real-time extene version shoul be the same, if only execution of actions is observe an not timing. This requires that the rules of the transition system by which UPOOSL is efine[voe95a], remain vali as long as they apply to UPOOSL processes. Isomorphism. It is require that the theory of UPOOSL is isomorphic to the subset of UPOOSL process equivalents in TPOOSL, in orer for the theoretical evelopments in UPOOSL to remain vali. Expresse formally: Any processes P, Q of UPOOSL are equivalent (P Q, for some equivalence relation on UPOOSL processes) if an only if P an Q are equivalent in TPOOSL for the corre- 8

11 4.3. THE NOTION OF ABSTRACT TIME 9 sponing equivalence relation in TPOOSL (P T Q ). Where P an Q are the TPOOSL equivalents of P an Q respectively. Isomorphism is closely relate to semantics conservation. The latter states that untime processes syntactically remain the same (P is syntactically ientical to P ). Furthermore it states that the equivalence relations are relate, such that that the actions of the time processes match the actions of the untime processes.. Abstraction: It is esirable that it will be possible to efine an abstraction function from TPOOSL processes to UPOOSL processes that gives for any time POOSL process, its untime equivalent, i.e. the process with the same behavior as far as only (external) actions are observe. In chapter 8 these requirements will be verifie for the propose extension of POOSL. From a more pragmatic point of view it is furthermore esirable that extensions to POOSL will be logical an appealing to the intuition of the user. 4.3 The notion of abstract time A POOSL escription is an abstract moel of a complex real worl. By making an abstraction of all the complicate etails, it is easier to reason about an to esign systems. As behavior of POOSL escriptions is an abstraction of real behavior, also the timing properties of a moel will only be abstractions of reality. Since a POOSL specification oes not tell anything about an actual implementation, the real-time properties are not exactly known. Furthermore these properties can epen on other activities in the environment an are often stochastic rather than eterministic. Therefore time specifications in a POOSL escription will be estimates of the time require for real worl computations. 4.4 Properties of process algebras an languages In orer to compare the features of existing real-time algebras an languages, an examine their strong an weak points, a number of typical characteristics of these algebras will be reviewe. Many of these characteristics are escribe in [NS9] In table 4., a number of the existing process algebras are shown. Some of them have real-time primitives.. Synchronous vs. asynchronous A system is calle asynchronous if there are no assumptions about the relative spees of processing an communication between istribute systems. In synchronous systems, the processing an communication times of istribute systems are relate.

12 0 CHAPTER 4. TIMING CONCEPTS Name Reference Concurrent processes ot calculus CIRCAL Circuit Calculus [Mil85] CCS Calculus of Communicating Systems [KOO9] SCCS Synchronous CCS DtCCS Discrete time CCS [RV95] TeCCS Temporal CCS [MT90] TiCCS Time CCS [Yi9] TPCCS Time Probabilistic CCS [HJ90] RtCCS Real-Time CCS [ST9] CSP Communicating Sequential Processes [Hoa78] TCSP Time CSP [RR86] ACSP Asynchronous CSP [BH9] RtACSP Real-time ACSP ACP Algebra of Communicating Processes ACP ρ Real-time ACP [BB9] TPA Time Process Algebra [NS9] U-LOTOS Urgent LOTOS TPL Temporal Process Language ATP Algebra of Time Processes PARTY Process Algebra with Real-Time from York [HZF93] Table 4.: Existing process algebras In a synchronous algebra, all processes cooperate in lock-step. This is usually expresse by a rule such as P P a Q Q b P Q a,b P Q. This rule expresses that if process P can o action a an process Q can o action b, than P an Q operating in parallel have to perform their actions together. It is also possible to enforce this synchronization only for a certain subset of actions. In an asynchronous algebra processes interleave their actions, This is expresse by the rules: P P a P Q P a Q Q Q a P Q P a Q P P a Q Q ā P Q P τ Q. They inicate that P an Q can perform their actions inepenently, but not simultaneously (unless it is a communication between P an Q).. Time-omain Process algebras that incorporate timing information assign actions of a system to elements

13 4.4. PROPERTIES OF PROCESS ALGEBRAS AND LANGUAGES of a certain time omain. A time omain is either ense or iscrete(sparse). In a ense time omain, there is no smallest istance between any two istinct time points. Some languages make explicit use of a ense time-omain. Others explicitly use iscrete time. In particular some languages incorporate iscrete time steps as a special kin of action, for instance a tick of some explicit clock. In some languages both time omains can be use. If a ense time omain is use, special care has to be taken for Zeno s paraox. In a ense time omain it is possible to create an infinite number of time transitions, where the total time elapse will never excee a fixe point in time. E.g.: / /4 /8 P P P 3 P 4... where the total elapse time will never excee. 3. Must- vs may- vs wait-timing Consier the parallel composition of the following processes: E = u : N IL E = : u : N IL E 3 = 3 : w : N IL where the actions u have to synchronize. Three ifferent interpretations can be istinguishe [Hui94]: Must-timing. At time 0, E cannot synchronize with E (nor with E 3 ) an creates a temporal ealock. E E E 3 is then in temporal ealock, because E will not let time avance. A local ealock always results in a global ealock (let δ enote the temporal ealock behavior): P δ δ May-timing. At time 0, E cannot synchronize with E an creates a non-temporal ealock (can no longer perform any actions, but is willing to let time pass), thus allowing E 3 to perform action w at time 3. A local ealock leas to the eath of the local process, but oes not result in a global ealock. P δ P Wait-timing. The first two interpretations are only possible in case a process is not always allowe to wait for communication. In this case the interpretation is: at time 0, E cannot synchronize with E, therefore E will let time pass, synchronizing with E at instant. In general, languages that incorporate a possibility of time lock, use must-timing. Languages that are (temporal) ealock-free will use may- or wait-timing.

14 CHAPTER 4. TIMING CONCEPTS 4. Time constraining operators A number of time constraining primitives are introuce in real-time languages an algebras. Some of the important primitives are: Time lock primitive. This primitive moels a temporal ealock. A temporal ealock isables the progress of time. Delay primitive. This is an operator that elays execution for a fixe amount of time. Time Stampe actions. These are actions, labele with a point in time, inicating when they are to be execute. Unboun iling. This primitive explicitly allows a process to wait before continuing execution. It can be use to allow a process to wait for synchronization with the environment. It can also be use implicitly in every communication action(arbitrary waiting). 5. Time-out operator Some languages have an explicit time-out primitive, mostly in the form of: P, Q t. P, Q t behaves as P, except when P oes not perform an action within time t, in which case it behaves as Q. In some languages, time-outs can be constructe using other primitives. Another operator, which resembles the timeout operator P, Q t, is a watchog. It means, behave as P for at most time t, if P has not terminate within time t, continue behaving as Q after this time. 6. Message passing There are several ways to implement communication in a real-time language or algebra. The most important characteristics are asynchronous vs. synchronous communication an binary vs. multiway communication. Asynchronous. Processes o not synchronize when they communicate. E.g. by using a FIFO buffer in a communication channel. Binary synchronization. Messages can only be passe between processes. These processes synchronize when a communication takes place. Multi-way synchronization. Multiple processes can simultaneously synchronize an communicate. This is useful to moel broacasting messages. In none of the languages or algebras the communication or synchronization over a message channel is associate with time. 7. Persistency In some algebras (TiCCS an TCSP) the progress of time cannot suppress the ability to perform an action. This property is calle persistency an is formally expresse as: P, Q, P,, a : P a P P Q P : Q a P

15 4.4. PROPERTIES OF PROCESS ALGEBRAS AND LANGUAGES 3 This property is not satisfie by ATP, TPL, TPCCS, TeCCS an ACP ρ. A time-out construction oes not necessarily lea to non-persistency. If ap + ; Q Q then it oes, but if ap + ; Q ap + Q then it oes not, because then it is not the progression of time, but the (non-eterministic) choice between ap an Q that isables the action a. In the case of strict action urgency (escribe later), an algebra is trivially persistent, because the possibility to perform an action prevents the process to let time pass. 8. Finite variability A process has the finite variability (non-zenoness, well-timeness) property if it can perform only finitely many actions in a finite time interval. The only algebras for which every process satisfies this requirement are TCSP an ACSP. This is achieve by enforcing a system-elay between two actions of a sequential process. This assumption seems to be the only solution to ensure finite variability, but it yiels an unnecessarily complicate theory. Moreover a fixe system-elay between actions is arbitrary. The property of finite variability also hols for the synchronous calculus SCCS, in which the execution of an action is performe in a unit of time. 9. Non-eterministic (probabilistic) choice-operator Some languages have a non-eterministic choice operator (e.g. ): ap bq. This operator inicates that non-eterministically a choice will be mae between ap an bq, irrespective of whether the environment wants to synchronize on a or on b. Some languages have a probabilistic choice operator: [p ]P + [p ]Q with p + p =. It moels a non-eterministic choice, where P is chosen with probability p an Q with probability p. This can be useful for simulations in which there is some extra knowlege about the statistical behavior of the processes. 0. Synchrony of time In all languages that were stuie, time progresses synchronously in all processes. Timesteps can only be mae simultaneously by all processes. All algebras make use of a twophase moel. In the first phase all processes perform as much actions as possible. In the secon phase all processes make a time step together. Only in algebras like CIRCAL, ifferent processes can perform time-steps inepenently. These algebras moel iscrete timesteps as a (special kin of) synchronous action.

16 4 CHAPTER 4. TIMING CONCEPTS Synchrony of time seems esirable, because in reality time progresses synchronously for all processes. There is however a rawback. Two processes that are physically istribute an therefore not synchronize can behave strongly synchronize in the moel. E.g., if the two processes are instances of the same process class, their timing specifications are ientical an therefore they can operate in perfect synchrony in the moel. In the real worl, this woul not be possible. A stochastic aspect of the behavior that causes the processes to operate asynchronously, must be moele explicitly.. Arbitrary waiting If a process wants to communicate with another process, but the other process is not reay for communication, there are two possible ways the total system can behave. The first possibility is that this occurrence is conceive as an error. The total system gets in temporal ealock, because the process that wants to communicate is not willing to let any time pass. A process that is willing to wait for communication must then be specifie by using a special primitive. The other option is to make the willingness to wait implicit for all communication. In some languages, the latter option is chosen. These languages usually contain the following rule: ap ap. Action urgency Many real-time languages incorporate some form of action urgency (maximal progress). This property inicates that all atomic actions that can take place, must take place before time will avance any further. If this property oes not hol, progress cannot be guarantee because the process might choose to wait forever. In some languages, action urgency hols only for internal actions. Communication with other processes may wait (in the case the other processes are not yet reay for communication). 3. Dealock freeness Dealock is a situation in which a system can no longer make any progress. In time algebras there are two ifferent kins of ealock. These are temporal an non-temporal ealocks. A system is in temporal ealock if the semantics of the system oes not allow the time to avance. E.g., if a process requires immeiate communication, but there is no communication partner. A system is in non-temporal ealock if time can still avance but the system can never perform any action. A real-time language is consiere to be ealock-free if it is impossible to construct a temporal ealock. This can be formalize as: P α Act T, P : P α P All languages that have this property use wait-timing to prevent temporal ealock.

17 4.4. PROPERTIES OF PROCESS ALGEBRAS AND LANGUAGES 5 4. Actions take zero-time In most languages actions are moele to take zero time. This is to prevent overlap in time between parallel actions. With overlap in time, the interleaving of actions is no longer possible. To ensure finite variability, some languages like ACP ρ, TeCCS, ATP, Tic an PARTY moel actions to take a fixe (small) amount of time. This ensures that only a finite amount of actions can take place in a finite amount of time. In synchronous languages all actions take one step, which is the unit of time. 5. Interrupts / Aborts Abort or interrupt primitives can be use to stop an active process an continue with another (more urgent one). In case of an interrupt, the original process will be resume after termination of the interrupting process. In case of an abort it will not be resume. Examples: P KeyboarEvent P EmergencyStop Only TCSP has an explicit interrupt operator. In some languages interrupts can be constructe using other primitives. In most languages only a timeout can be constructe. This means that a process can only be suspene if it has not performe an action yet. 6. Time eterminism A language is time eterministic if the passage of time can not result in any non-eterministic choices. This means that when a process P oes not perform any action for a uration, the resulting behavior is completely etermine by P an. This can be expresse as: Usually there is a rule such as P, P, P, : P P P P P = P P P Q Q P + Q P + Q. It states that the passing of time will not enforce a choice. 7. Time aitivity For time aitivity (also calle time continuity) it is require that a process can ile for + time units, if an only if it can ile for time units an consequently for time units. In both cases the resulting behavior shoul be the same. Formally, this property is expresse as,, P, P : P P + P : P P P P This property is very esirable. A semantics that violates it oes not match with the intuitive notion of time.

18 6 CHAPTER 4. TIMING CONCEPTS 4.5 Overview of the most important characteristics The most important characteristics of the formalisms are isplaye in the table below for the realtime algebras TCSP A ense must DT + M ACP ρ A ense must TS - B TiCCS A ense wait DU - B TeCCS A iscr. must DTU - B TPCCS A iscr. wait U + B TPL D ATP A iscr. wait U + B SCCS S iscr B + - ACSP A ense wait DU + BA + - RtCCS A iscr. wait U + B TiC S ense both DTUS - B - - PARTY S ense must DT - M Using some of these characteristics one can give a hierarchical overview, as has been one in figure Overview of real-time programming languages Next to the real-time algebras, there are a number of specification or programming languages that are esigne for real-time applications [Sto9]. Not all of them have a formal semantics. Aa. Aa is very wiely use for real-time applications. The avantages are that it is well structure, reaable, moular an it has strong typing. Aa has concurrent processes (tasks) that synchronize through an asymmetric renezvous. A isavantage is that Aa is large an complex an may therefore be har to learn an use. The select statement is very similar to the or statement in POOSL, but in can only be use in combination with accept an elay statements. Esterel [BG9, BMR83]. Esterel is a synchronous language. Actions are carrie out instantaneously. The notion of time is supporte in the form of events. Processes can act on events an they can generate events. Events can also be generate by a global clock. There are no share variables. There is only synchronous communication by means of events with parameters. The synchrony an the immeiate actions can give rise to causality problems. E.g. a temporal paraox [BMR83]: emit e(4) (wait e(v); emit e(5)) A possible interpretation is: since all actions occur simultaneously, e(4) an e(5) will be emitte simultaneously, which means that v woul be the multiset {4, 5}.

19 4.6. OVERVIEW OF REAL-TIME PROGRAMMING LANGUAGES 7 Lustre [CPHP87]. Lustre is a synchronous ata-flow language. The basic ata structure is a stream. Operators combine streams to new streams. Time streams can be introuce to create a notion of time. Moula. In Moula, processes can be synchronize through waits an signals. Occam [Wex89]. Occam is very similar to CSP. It is esigne to support interacting concurrent processes. A program consists of static processes an preetermine fixe communication channels. Sen an receive statements are both blocking as in a renez-vous. It has a non-eterministic guare comman an a primitive timer channel. Processes can be hierarchically constructe using the PAR, SEQ an ALT constructors, to implement parallel, sequential or alternative execution of statements respectively. Hiing channels or encapsulation are not possible. Pearl. Pearl contains explicit ealine specification primitives an requires a real-time operating system to scheule the tasks accoringly. It is a prescriptive language with many primitives for monitors, signal an semaphores. PORTAL. In PORTAL the process is the grain of parallelism. Monitors can be use an processes synchronize through waits an signals. The wait statement can be extene with a elay to implement a wait or a time-out on a signal. Real-Time Eucli. The most important characteristic of Real-Time Eucli is that programs can be analyze for their maximum execution time. This allows them to be scheule, such that all ealines are guarantee to be met. In orer to achieve this, some concessions have been mae to the power of the language. Loops must be boune. Recursion an ynamic storage allocation are isallowe. Timing information nees to be specifie for every process. StateMate. StateMate is a graphical metho to specify statemachines. Transitions of the statemachines can be specifie using the formal language of statecharts. VHDL. VHDL (Very high spee integrate circuits Harware Description Language) is an asynchronous language. Actions that occur at the same time are given a temporal orering, by introucing some infinitesimal time between them, so calle elta-times. Timing is introuce by assignment to signals, x <= E af ter t. This assignment has the following meaning: evaluate E now an assign the resulting value to x after a elay of t timeunits. This is use to moel a propagation elay. The evaluation of E oes not take any time. Synchronization is introuce by the wait statement, which can be use to let a process wait for a signal or wait for some timing constraint. Next to behavioral statements, there are structural statements, which can be use to express hierarchy. The grain of concurrency are the process statements.

20 8 CHAPTER 4. TIMING CONCEPTS Figure 4.: Overview real-time algebras

21 Chapter 5 The selection of timing concepts an primitives 5. Introuction In the previous chapter, ifferent concepts of time an ifferent possible been iscusse. In this chapter these concepts will be evaluate for use in the extension of POOSL. 5. Evaluation of concepts The concepts of section 4.4 will be iscusse. Some have alreay been etermine by POOSL, an some are left to implement with the extension of POOSL.. Synchronous or asynchronous POOSL uses an asynchronous interleaving semantics. Therefore the real-time extene version will use the same asynchronous interleaving of actions.. Time omain No special assumptions will be mae about the time omain use, other than the trivial ones [NS9]. It can be ense or iscrete. It will be enote as T. 3. May-, Must- or Wait-timing The semantics of untime POOSL is such that processes that are able to communicate, will wait for a communication partner to become reay for synchronization. A process cannot turn into a ealock if it cannot communicate. The concepts of must- an may-timing are ifferent. If the synchronization oes not happen at the moment the process becomes reay for communication, the synchronization will never happen, leaving the local process (maytiming) or the global process (must-timing) in temporal ealock. Wait-timing correspons better to the behavior of untime POOSL processes an will therefore be use. Processes will be implicitly allowe to wait for communication. 4. Time constraining operators Some of the iscusse primitive operators can be useful for the extension of POOSL. Dealock primitive. A temporal ealock is an unnatural process. One process that cannot avance, shoul not keep all other processes from avancing. A ealockprimitive is not neee. Delay primitive. A elay-operator is useful, because it is a simple primitive an it can be use in combination with other primitives to construct timeout behavior or moel computation time. 9

22 0 CHAPTER 5. THE SELECTION OF TIMING CONCEPTS AND PRIMITIVES Time-stampe actions. Communication actions cannot be time-stampe, because there is always a secon process necessary that is willing to communicate. Internal actions can be time-stampe, but the same can be achieve using a elay primitive. Unboun iling. Unboun iling is esirable to implement wait-timing. When processes want to communicate, they shoul be able to wait for their communication partner if necessary. It is possible to implicitly allow unboun iling in communication, so no special primitive is neee. This will be one for the POOSL extension. 5. Timeout operator A time-out construction is necessary to moel e.g. time-outs in communication. It can be use to respon to the situation where synchronization between processes oes not take place in time. A timeout operator will not be neee, since timeouts can be constructe using a elay primitive in combination with the choice operator an the concept of action urgency. 6. Message passing Message passing shoul be binary an synchronous, accoring to the renez-vous principle of POOSL. An extension of POOSL with broacasting messages woul be interesting, because this can not yet be moele easily. 7. Persistence Whether the persistence property will hol for a real-time extene version of POOSL will epen on the interaction of POOSL primitives with time. That the passage of time can isable the possibility to perform actions is not unnatural. A timeout on a communication oes this. 8. Finite variability Although finite variability is intuitively a esirable property, there is no goo way to implement it. The concept that actions take zero time is chosen, even if this implies the possibility that an infinite amount of actions can be performe in zero time. 9. The choice operator An explicit non-eterministic choice is not neee, because choices are resolve by time an by the environment. The semantics of the normal choice operator states that actions that are reay simultaneously will be chosen non-eterministically. Moreover a non-eterministic choice can be moele with internal actions (τ): 0. Moel of time P Q = τp + τq Many process algebras use two alternating phases to escribe behavior in time[ns9]. First an asynchronous phase takes place, when all processes perform as many actions an communications as possible an time oes not progress. This phase is followe by a synchronous

23 5.. EVALUATION OF CONCEPTS phase in which all process let time pass simultaneously. This phase is again followe by an asynchronous phase, etcetera. (see figure 5. [NS9]). This way at points in time a number of actions take place. These actions cannot be istinguishe by the time of their occurrence, but they o not happen simultaneously. There exists a temporal orering among them. The actions o not take time. This moel will be use to exten POOSL.. Arbitrary waiting Figure 5.: Two phase execution moel As explaine earlier, processes will be implicitly allowe to wait for communication. If both sening an receiving process are able to wait, some special care has to be taken to ensure that the communication oes take place as soon as possible.. Action urgency In orer to ensure that processes make as much progress as possible, action urgency is necessary. All internal actions of a process will have to be execute before time may avance. The semantics of the parallel composition of processes shoul be such that communication will also take place as soon as possible. 3. Dealock freeness It has been explaine that the time version of POOSL shoul be free of temporal ealock. Dealock for actions, the situation that a process can no longer perform any actions, now or in the future, will still be possible. 4. Actions take zero time Actions will be moele to take zero time, in orer to be able to use the interleaving mechanism of POOSL. The time associate with the actions can be moele with other primitives.

24 CHAPTER 5. THE SELECTION OF TIMING CONCEPTS AND PRIMITIVES 5. Interrupts / aborts The POOSL language contains both an interrupt an an abort primitive. The semantics of these primitives in the presence of time will nee to be efine. 6. Time eterminism The property of time-eterminism esirable. A process behaves eterministically if it is letting time pass. Possible non-eterministic choices will only be mae by internal actions. 7. Time aitivity Time aitivity is a very natural property for a real-time system. The POOSL extension will be esigne to have this property. The calculus Temporal CCS (TeCCS) [MT90] has a number of features in common with the state wishes an can be use as a moel for timing in POOSL. In TeCCS, communication actions are urgent, arbitrary waiting can be achieve using the ile operator δ. In POOSL arbitrary waiting for communication actions will be mae implicit. However communication shoul take place as soon as both parties are reay, which can be enforce by making the τ action of the parallel composition urgent. In TeCCS δap δāq is not urgent, which means that communication oes not have to take place as soon as possible. In TeCCS, it is impossible to guarantee any form of progress. Furthermore, TeCCS has two ifferent choice operators for must- an may-timing. Since arbitrary waiting will be mae implicit in POOSL, their ifference will be irrelevant.

25 Chapter 6 Extening the semantics of POOSL 6. Introuction In the previous chapter properties have been selecte for the extension of POOSL with time an a elay primitive has been chosen to express timing properties in POOSL. In this extension, it will be possible to express most of the necessary timing properties. First a time relation will be ae to POOSL an then a new primitive elay will be introuce. POOSL escriptions without any new timing primitives are intuitively associate with a specific behavior in time. The meaning of existing POOSL escriptions shoul be kept the same, while aing primitives to express the timing behavior that was not expressible in POOSL. The extension shoul furthermore be in conformance with the constraints, state in section 4.. Data computations contain no information about the time consume. They are therefore consiere to be instantaneous in time POOSL. Furthermore, assigning time to computations woul enable two computations to be simultaneously active. In the interleaving semantics of POOSL however, actions are always interleave. Therefore the only ways the execution of an untime POOSL escriptions can take time are: Termination. A process that has terminate can stay inactive an let time go by. Waiting for communication. If a process wants to communicate with the outsie worl, it can wait until the outsie worl is reay. Waiting for a blocking guare comman. If the continuation of an execution is prohibite by a blocking guar, time can pass, possibly enabling the guar in a later moment in time. Furthermore, a number of interactions between time an POOSL primitives will have to be specifie. The choice operator an time (section 6..3). Only actions can enforce a choice. The passage of time nees to be coorinate among all alternatives an urgency nees to guarantee. Interrupts, aborts an time (section 6..4). The way time progresses in interrupte an interrupting or aborting statements must be specifie. Guare commans an time (section 6..5). It nees to be efine, when a guar will be execute an uner what conitions the following statement may let time pass. Parallel composition an time (section 6..6). The time in two or more concurrent processes nees to be synchronize. 3

26 4 CHAPTER 6. EXTENDING THE SEMANTICS OF POOSL 6. Aing the time relation to POOSL 6.. Introuction First, a time relation will be ae to POOSL, in such a way that ol POOSL escriptions are still vali with the interpretation that their execution oes not take any time, except for the cases escribe in the previous section. In orer to o this, the interactions between existing POOSL primitives an the new time relation will be investigate. The meaning of POOSL processes has been formalize with a computational interleaving semantics, specifie by a labele transition system [Voe95B] ( Con f p, Act, { a a Act }) Con f p is he set of all possible POOSL processes in a specific internal state, Act is the set of possible actions an { a a Act } a is a set of transition relations Con f p Con f p. This inicates what processes (configurations) can perform what actions. a Con f Con f means that configuration Con f may perform action a an further behaves as Con f. For the extension of POOSL, a new set of relations will be ae: ( ) Con f p, Act, T, { a a Act}, { T } where T is the time omain an { T } Con f p Con f p is the time relation, that inicates if a process can wait a time. Con f Con f means that configuration Con f may wait for time units, after which it behaves as Con f. 6.. Timing of processes A system consists of a number of process an clusters that operate concurrently an synchronize by communication. The operation of the processes takes time an in orer to create a useful moel of the real worl, time shoul pass synchronously within all processes. Processes can consume time by waiting, computing or by communicating The choice The relation between the choice operator (or) an time will be investigate. In untime POOSL the or comman can be use to leave several possibilities open until a choice can be mae. A choice can, e.g., epen on synchronization opportunities with the environment. In the context of time, this correspons to waiting for the environment to enforce a ecision.

27 6.. ADDING THE TIME RELATION TO POOSL 5 Therefore, in the time version of POOSL, an or statement can let a time go by if an only if all alternatives are reay to let time go by. In the meantime no choice will be mae. This leas to the following rule: S S S S S S S S This can be illustrate by figure 6.. Figure 6.: Possible transitions of the choice operator 6..4 Time an interrupts An interrupt statement S S works like an alternative S that is available in every state of the execution of statement S (see fig. 6.). Therefore the semantics of the statement Figure 6.: Transitions of an interrupt statement with respect to time is ientical to that of the choice statement. The interrupt statement can let time pass if an only if both S an S can let time pass, S S S S S S S S.