rts

Chapter 1 

System Verification 
Our reliance on the functioning of ICT systems (Information and Communicatiop Technology) is growing rapidly. These systems are becoming more and more complex and are massively encroaching on daily life via the Internet and all kinds of embedded systems such as ~smart cards, hand-held computers, mobile phones, and high-end television sets. In 1995 it was estimated that we are confronted with about 25 ICT devices on a daily basis. Services like electronic banking and teleshopping have become reality. The daily cash flow via the Internet is about 1012 million US dollars. Roughly 20% of the product development costs of modern transportation devices such as cars, high-speed trains, and airplanes is devoted to information processing systems. ICT systems are universal and omnipresent. They control the stock exchange market, form the heart of telephone switches, are crucial to Internet technology, and are vital for several kinds of medical systems. Our reliance on embedded systems makes their reliable operation of large social importance. Besides offering a good performance in terms like response times and processing capacity, the absence of annoying errors is one of the major quality indications. 
It is all about money. We are annoyed when our mobile phone malfunctions, or when our video recorder reacts unexpectedly and wrongly to our issued commands. These software and hardware errors do not threaten our lives, but may have substantial financial consequences for the manufacturer. Correct ICT systems are essential for the survival of a company. Dramatic examples are known. The bug in Intel's Pentium II floating-point division unit in the early nineties caused a loss of about 475 million US dollars to replace faulty processors, and severely damaged Intel's reputation as a reliable chip manufacturer. The software error in a baggage handling system postponed the opening of Denver's airport 


System Verification 


Figure 1.1: The Ariane-5 launch on June 4, 1996; it crashed 36 seconds after the launch due to a conversion of a 64-bit floating point into a 16-bit integer value. 
the worldwide online ticket reservation system of a large airplane company will cause its bankruptcy because of missed orders. 
It is all about safety: errors can be catastrophic too. The fatal defects in the control software of the Ariane-5 missile (Figure 1.1), the Mars Pathfinder, and the airplanes of t'he Airbus family led to headlines in newspapers all over the wor1d and are notorious by now. Similar software is used for the process control of safety-critical systems such as chemical plants, nuclear power plants, traffic control and alert systems, and storm surge barriers. Clearly, bugs in such software can have disastrous consequences. For example, a software flaw in the control part of the radiation therapy machine Therac-25 caused the death of six cancer patients between 1985 and 1987 as they were exposed to an overdose of radiation. 
The increasing reliance of critical applications on information processing leads us to state: 
The reliability of JCT systems is a key issue in the system design process. 

The magnitude of ICT systems, as well as their complexity, grows apace. JCT systems are no longer standalone, but are typically embedded in a larger context, connecting and interacting with several other components and systems. They thus become much more vulnerable to errors the number of defects grows exponentially with the number of interacting system components. In particular, phenomena such as concurrency and nondeterminism that are central to modeling interacting systems turn out to be very hard to handle with standard techniques. Their growing complexity, together with the pressure to drastically reduce system development time ("time-to-market>'), makes the delivery of low-defect ICT systems an enormously challenging and complex activity. 
System Verification 
Hard-and Software Verification 
System verification techniques are being applied to the design of ICT systems in a more reliable way. Briefly, system verification is used to establish that the design or product under consideration possesses certain properties. The properties to be validated can be quite elementary, e.g., a system should never be able to reach a situation in which no progress can be made (a deadlock scenario), and are mostly obtained from the system's specification. This specification prescribes what the system has to do and what not, and thus constitutes the basis for any verification activity. A defect is found once the system does not fulfill one of the specification's properties. The system is considered to be "correct" whenever it satisfies all properties obtained from its specification. So correctness is always relative to a specification, and is not an absolute property of a system. A schematic view of verification is depicted in Figure 1.2. 
system specification 
Design Process properties 

Figure 1.2: Schematic view of an a posteriori system verification. 
This book deals with a verification technique called model checking that starts from a formal system specification. Before introducing this technique and discussing the role of formal specifications, we briefly review alternative software and hardware verification techniques. 
Software Verification Peer reviewing and testing are the major software verification techniques used in practice. 
A peer review amounts to a software inspection carried out by a team of software engineers that preferably has not been involved in the development of the software under review. The 
4 

System Verification 

uncompiled code is not executed, but analyzed completely statically. Empirical studies indicate that peer review provides an effective technique that catches between 31 % and 93 % of the defects with a median around 60%. While mostly applied in a rather ad hoc manner, more dedicated types of peer review procedures, e.g., those that are focused at specific error-detection goals, are even more effective. Despite its almost complete manual nature, peer review is thus a rather useful technique. It is therefore not surprising that some form of peer review is used in almost 80% of all software engineering projects. Due to its static nature, experience has shown that subtle errors such as concurrency and algorithm defects are hard to catch using peer review. 
Software testing constitutes a significant part of any software engineering project. Between 30% and 50% of the total software project costs are devoted to testing. As opposed to peer review, which analyzes code statically without executing it, testing is a dynamic technique that actually runs the software. Testing takes the piece of software under consideration and provides its compiled code with inputs, called tests. Correctness is thus determined by forcing the software to traverse a set of execution paths, sequences of code statements representing a run of the software. Based on the observations during tes~ execution, the actual output of the software is compared to the output as documented in the system specification. Although test generation and test execution can partly be automated, the ,comparison is usually performed by human beings. The main advantage of testing is that it can be applied to all sorts of software, ranging from application software (e.g., e-business software) to compilers and operating systems. As exhaustive testing of all execution paths is practically infeasible; in practice only a small subset of these paths is treated. Testing can thus never be complete. That is to say, testing can only show the presence of errors, not their absence. Another problem with testing is to determine when to stop. Practically, it is hard, and mostly impossible, to indicate the intensity of testing to reach a certain 
defect density -the fraction of defects per number of uncommented code lines. 

Studies have provided evidence that peer review and testing catch different classes of defects at different stages in the development cycle. They are therefore often used together. To increase the reliability of software, these software verification approaches are complemented with software process improvement techniques, structured design and specification methods (such as the Unified Modeling Language), and the use of version and configuration management control systems. Formal techniques are used, in one form or another, in about 10 % to 15% of all software projects. These techniques are discussed later in this 
chapter. 

Catching software errors: the sooner the better. It is of great importance to locate software bugs. The slogan is: the sooner the better. The costs of repairing a software flaw during maintenance are roughly 500 times higher than a fix in an early design phase (see Figure 1.3). System verification should thus take place early stage in the design process. 

System Verification 

Figure 1.3: Software lifecycle and error introduction, detection, and repair costs [275]. 
About 50% of all defects are introduced during programming, the phase in which actual coding takes place. Whereas just 15% of all errors are detected in the initial design stages, most errors are found during testing. At the start of unit testing, which is oriented to discovering defects in the individual software modules that make up the system, a defect density ,of about 20 defects per 1000 lines of (uncommented) code is typical. This has been reduced to about 6 defects per 1000 code lines at the start of system testing, where a collection of such modules that constitutes a real product is tested. On launching a new software release, the typical accepted software defect density is about one defect per 1000 lines of code lines1. 
Errors are typically concentrated in a few software modules about half of the modules are defect free, and about 80% of the defects arise in a small fraction (about 20%) of the modules -and often occur when interfacing modules. The repair of errors that are detected prior to testing can be done rather economically. The repair cost significantly increases from about $ 1000 (per error repair) in unit testing to a maximum of about $ 12,500 when the defect is demonstrated during system operation only. It is of vital importance to seek techniques that find defects as early as possible in the software design process: the costs to repair them are substantially lower, and their influence on the rest of the design is less substantial. 
Hardware Verification Preventing errors in hardware design is vital. Hardware is subject to high fabrication costs; fixing defects after delivery to customers is difficult, and quality expectations are high. Whereas software defects can be repaired by providing 
1 For some products this is much higher, though. Microsoft has acknowledged that Windows 95 contained at least 5000 defects. Despite the fact that users were daily confronted with anomalous behavior, Windows 95 was very successful. 

6 System Verification 

users with patches or updates nowadays users even tend to anticipate and accept this hardware bug fixes after delivery to customers are very difficult and mostly require refabrication and redistribution. This has immense economic consequences. The replacement of the faulty Pentium II processors caused Intel a loss of about $ 475 million. Moore's law -the number of logical gates in a circuit doubles every 18 months -has proven to be true in practice and is a major obstacle to producing correct hardware. Empirical studies have indicated that more than 50% of all ASICs (Application-Specific Integrated Circuits) do not work properly after initial design and fabrication. It is not surprising that chip manufacturers invest a lot in getting their designs right. Hardware verification is a well-established part of the design process. The design effort in a typical hardware design amounts to only 27% of the total time spent on the chip; the rest is devoted to error detection and prevention. 
Hardware verification techniques. Emulation, simulation, and structural analysis are the major techniques used in hardware verification. 
Structural analysis comprises several specific techniques such as synthesis, timing analysis, and equivalence checking that are not described in further detail here. • 
Emulation is a kind of testing. A reconfigurable generic hardware system (the emulator) is configured such that it behaves like the circuit under consideration and is then extensively tested. As with software testing, emulation amounts to providing a set of stimuli to the circuit and comparing the generated output with the expected output as laid down in the chip specification. To fully test the circuit, all possible input combinations in every possible system state should be examined. This is impractical and the number of tests needs to be reduced significantly, yielding potential undiscovered errors. 
With simulation, a model of the circuit at hand is constructed and simulated. Models are typically provided using hardware description languages such as Verilog or VHDL that are both standardized by IEEE. Based on stimuli, execution paths of the chip model are examined using a simulator. These stimuli may be provided by a user, or by automated means such as a random generator. A mismatch between the simulator's output and the output described in the specification determines the presence of errors. Simulation is like testing, but is applied to models. It suffers from the same limitations, though: the number of scenarios to be checked in a model to get full confidence goes beyond any reasonable subset of scenarios that can be examined in practice. 
Simulation is the most popular hardware verification technique and is used in various design stages, e.g., at register-transfer level, gate and transistor level. Besides these error detection techniques, hardware testing is needed to find fabrication faults resulting from layout defects in the fabrication process. 

Model Checking 

1.1 Model Checking 
In software and hardware design of complex systems, more time and effort are spent on verification than on construction. Techniques are sought to reduce and ease the verification efforts while increasing their coverage. Formal methods offer a large potential to obtain an early integration of verification in the design process, to provide more effective verification techniques, and to reduce the verification time. 
Let us first briefly discuss the role of formal methods. To put it in a nutshell, formal methods can be considered as "the applied mathematics for modeling and analyzing ICT systems". Their aim is to establish system correctness with mathematical rigor. Their great potential has led to an increasing use by engineers of formal methods for the verification of complex software and hardware systems. Besides, formal methods are one of the "highly recommended" verification techniques for software development of safetycritical systems according to, e.g., the best practices standard of the IEC (International Electrotechnical Commission) and standards of the ESA (European Space Agency). The resulting report of an investigation by the FAA (Federal Aviation Authority) and NASA (National Aeronautics and Space Administration) about the use of formal methods concludes that 
Formal methods should be part of the education of every computer scientist 
and software engineer, just as the appropriate branch of applied maths is a 
necessary part of the education of all other engineers. 
During the last two decades, research in formal methods has led to the development of some very promising verification techniques that facilitate the early detection of defects. These techniques are accompanied by powerful software tools that can be used to automate various verification steps. Investigations have shown that formal verification procedures would have revealed the exposed defects in, e.g., the Ariane-5 missile, Mars Pathfinder, Intel's Pentium II processor, and the Therac-25 therapy radiation machine. 
Model-based verification techniques are based on models describing the possible system behavior in a mathematically precise and unambiguous manner. It turns out that -prior to any form of verification the accurate modeling of systems often leads to the discovery of incompleteness, ambiguities, and inconsistencies in informal system specifications. Such problems are usually only discovered at a much later stage of the design. The system models are accompanied by algorithms that systematically explore all states of the system model. This provides the basis for a whole range of verification techniques ranging from an exhaustive exploration (model checking) to experiments with a restrictive set of scenarios in the model (simulation), or in reality (testing). Due to unremitting improvements of un

8 System Veriflcation 


derlying algorithms and data structures, together with the availability of faster computers and larger computer memories, model-based techniques that a decade ago only worked for very simple examples are nowadays applicable to realistic designs. As the startingpoint of these techniques is a model of the system under consideration, we have as a given fact that 
Any verification using model-based techniques is only as good as the model of the system. 

Model checking is a verification technique that explores all possible system states in a brute-force manner. Similar to a computer chess program that checks possible moves, a model checker, the software tool that performs the model checking, examines all possible system scenarios in a systematic manner. In this way, it can be shown that a given system model truly satisfies a certain property. It is a real challenge to examine the largest possible state spaces that can be treated with current means, i.e., processors and memories. Stateof-the-art model checkers can handle state spaces of about 108 to 109 states with explicit state-space enumeration. Using clever algorithms and tailored data structures, larger state 
spaces (1020 up to even 10476 states)  can be handled for specific problems.  Even the subtle  
errors  that. remain undiscovered using emulation, testing  and simulation  can  potentially  
be revealed using model checking.  


Figure 1.4: Schematic view of the model-checking approach. 

Typical properties that can be checked using model checking are of a qualitative nature: Is the generated result OK?, Can the system reach a deadlock situation, e.g., when two 

Model Checking 
concurrent programs are waiting for each other and thus halting the entire system? But also timing properties can be checked: Can a deadlock occur within 1 hour after a system reset?, or, Is a response always received within 8 minutes? Model checking requires a precise and unambiguous statement of the properties to be examined. As with making an accurate system model, this step often leads to the discovery of several ambiguities and inconsistencies in the informal documentation. For instance, the formalization of all system properties for a subset of the ISDN user part protocol revealed that 55% (!) of the original, informal system requirements were inconsistent. 
The system model is usually automatically generated from a model description that is specified in some appropriate dialect of programming languages like C or Java or hardware description languages such as Verilog or VHDL. Note that the property specification prescribes what the system should do, and what it should not do, whereas the model description addresses how the system behaves. The model checker examines all relevant system states to check whether they satisfy the desired property. If a state is encountered that violates the property under consideration, the model checker provides a counterexample that indicates how the model could reach the undesired state. The countere_xample describes an execution path that leads from the initial system state to a state that violates the property being verified. With the help of a simulator, the user can replay the violating scenaria; in this way obtaining useful debugging information, and adapt t}le model (or the property) accordingly (see Figure 1.4). 
Model checking has been successfully applied to several ICT systems and their applications. For instance, deadlocks have been detected in online airline reservation systems, modern ecommerce protocols have been verified, and several studies of international IEEE standards for in-house communication of domestic appliances have led to significant improvements of the system specifications. Five previously undiscovered errors were identified in an execution module of the Deep Space 1 spacecraft controller (see Figure 1.5), in one case identifying a major design flaw. A bug identical to one discovered by model checking escaped testing and caused a deadlock during a flight experiment 96 million km from earth. In the Netherlands, model checking has revealed several serious design flaws in the control software of a storm surge barrier that protects the main port of Rotterdam against fiooding. 
E:mmple 1. 1. Concurrency and Atomicity 
rl'lost errors, such as the ones exposed in the Deep Space-I spacecraft, are concerned with classical concurrency errors. Unforeseen interleavings between processes may cause undesired events to happen. This is exemplified by analysing the following concurrent program, in which three processes, Inc, Dec, and Reset, cooperate. They operate on the shared integer variable x with arbitrary initial value that can be accessed (i.e., read), and 

10 System Verification 

Mi111ature
Integrated MICASSon shade Camera Spectrometer 
High gain anrenno 
/ +.<low gain anterui:a Plasma:Expenment for Planetary Exploranon 
¾ lowgain ant<nna 
Kaband anunna 
Sun sensor 
Sun sensor eledronLcs 
Battery 
D,ple,er 
loo propulsion system 
<ig,talcontrol mteifa~ unit Xe feed system panel 

Figure 1.5: Modules of NASA's Deep Space-I space-craft (launched in October 1998) have been thoroughly examined using model checking. 
modified (i.e., written) by each of the individual processes. The processes are 
proc Inc = while true do if x < 200 then x := x + 1 fl od 
proc Dec = while true do if x > 0 then x := x -1 fl od 
proc Reset = while true do if x = 200 then x := 0 fl od 

Process Inc increments x if its value is smaller than 200, Dec decrements x if its value is at least 1, and Reset resets x once it has reached the value 200. They all do so repetitively. 
Is the value of x always between (and including) 0 and 200? At first sight this seems to be true. A more thorough inspection, though, reveals that this is not the case. Suppose x equals 200. Process Dec tests the value of x, and passes the test, as x exceeds O. Then, control is taken over by process Reset. It tests the value of x, passes its test, and immediately resets x to zero. Then, control is returned to process Dec and this process decrements x by one, resulting in a negative value for x (viz. -1). Intuitively, we tend to interpret the tests on x and the assignments to x as being executed atomically, i.e., as a single step, whereas in reality this is (mostly) not the case. ■ 

Characteristics of Model Checking 


1.2 Characteristics of Model Checking 
This book is devoted to the principles of model checking: 
Model checking is an automated technique that, given a finite-state model of a system and a formal property, systematically checks whether this property holds for ( a given state in) that model. 
The next chapters treat the elementary technical details of model checking. This section describes the process of model checking (how to use it), presents its main advantages and drawbacks, and discusses its role in the system development cycle. 
1.2.1 The Model-Checking Process 
In applying model checking to a design the following different phases can be distinguished: 
• Mode ling phase: 
-model the system under consideration using the model description language of the model checker at hand; -as a first sanity check and quick assessment of the model perform some simulations; -formalize the property to be checked using the property specification language. 
• Running phase: run the model checker to check the validity of the property in the system model. 
• Analysis phase: 
-property satisfied? --> check next property (if any); -property violated? --> 
1. 
analyze generated counterexample by simulation; 

2. 
refine the model, design, or property; 

3. 
repeat the entire procedure. -out of memory? -+ try to reduce the model and try again. 



12 System Verification 


In addition to these steps, the entire verification should be planned, administered, and organized. This is called verification organization. We discuss these phases of model checking in somewhat more detail below. 
Modeling The prerequisite inputs to model checking are a model of the system under consideration and a formal characterization of the property to be checked. 
Models of systems describe the behavior of systems in an accurate and unambiguous way. They are mostly expressed using finite-state automata, consisting of a finite set of states and a set of transitions. States comprise information about the current values of variables, the previously executed statement (e.g., a program counter), and the like. Transitions describe how the system evolves from one state into another. For realistic systems, finite-state automata are described using a model description language such as an appropriate dialect/extension of C, Java, VHDL, or the like. Modeling systems, in particular concurrent ones, at the right abstraction level is rather intricate and is really an art; it is treated in more detail in Chapter 2. 
In order to improve the quality of the model, a simulation prior to the model checking can take place. Simulation can be used effectively to get rid of the simpler category of modeling errors. Eliminating these simpler errors before any form of thorough checking takes place may reduce the costly and time-consuming verification effort. 
To make a rigorous verification possible, properties should be described in a precise and unambiguous manner. This is typically done using a property specification language. We focus in particular on the use of a temporal logic as a property specification language, a form of modal logic that is appropriate to specify relevant properties of ICT systems. In terms of mathematical logic, one checks that the system description is a model of a temporal logic formula. This explains the term "model checking". Temporal logic is basically an extension of traditional propositional logic with operators that refer to the behavior of systems over time. It allows for the specification of a broad range of relevant system properties such as functional correctness {does the system do what it is supposed to do?), reachability (is it possible to end up in a deadlock state?), safety ( "something bad never happens"), liveness ("something good will eventually happen"), fairness (does, under certain conditions, an event occur repeatedly?), and real-time properties (is the system acting in time?). 
Although the aforementioned steps are often well understood, in practice it may be a serious problem to judge whether the formalized problem statement (model + properties) is an adequate description of the actual verification problem. This is also known as the validation problem. The complexity of the involved system, as well as the lack of precision 

Characteristics of Model Checking 

of the informal specification of the system's functionality, may make it hard to answer this question satisfactorily. Verification and validation should not be confused. Verification amounts to check that the design satisfies the requirements that have been identified, i.e., verification is "check that we are building the thing right". In validation, it is checked whether the formal model is consistent with the informal conception of the design, i.e., validation is "check that we are verifying the right thing". 
Running the Model Checker The model checker first has to be initialized by appropriately setting the various options and directives that may be used to carry out the exhaustive verification. Subsequently, the actual model checking takes place. This is basically a solely algorithmic approach in which the validity of the property under consideration is checked in all states of the system model. 
Analyzing the Results There are basically three possible outcomes: the specified property is either valid in the given model or not, or the model turns out to be too large to fit within the physical limits of the computer memory. 
In case the property is valid, the following property can be checked, or, in case all properties have been checked, the model is concluded to possess all desired properties. 
Whenever a property is falsified, the negative result may have different causes. There may be a modeling error, i.e., upon studying the error it is discovered that the model does not reflect the design of the system. This implies a correction of the model, and verification has to be restarted with the improved model. This reverification includes the verification of those properties that were checked before on the erroneous model and whose verification may be invalidated by the model correction! If the error analysis shows that there is no undue discrepancy between the design and its model, then either a design error has been exposed, or a property error has taken place. In case of a design error, the verification is concluded with a negative result, and the design (together with its model) has to be improved. It may be the case that upon studying the exposed error it is discovered that the property does not reflect the informal requirement that had to be validated. This implies a modification of the property, and a new verification of the model has to be carried out. As the model is not changed, no reverification of properties that were checked before has to take place. The design is verified if and only if all properties have been checked with reHpect to a valid model. 
Whenever the model is too large to be handled -state spaces of real-life systems may be many orders of magnitude larger than what can be stored by currently available memories -there are various ways to proceed. A possibility is to apply techniques that try to exploit 
System Verification 
implicit regularities in the structure of the model. Examples of these techniques are the representation of state spaces using symbolic techniques such as binary decision diagrams or partial order reduction. Alternatively, rigorous abstractions of the complete system model are used. These abstractions should preserve the (non-)validity of the properties that need to be checked. Often, abstractions can be obtained that are sufficiently small with respect to a single property. In that case, different abstractions need to be made for the model at hand. Another way of dealing with state spaces that are too large is to give up the precision of the verification result. The probabilistic verification approaches explore only part of the state space while making a (often negligible) sacrifice in the verification coverage. The most important state-space reduction strategies are discussed in Chapters 7 through 9 of this monograph. 
Verification Organization The entire model-checking process should be well organized, well structured, and well planned. Industrial applications of model checking have provided evidence that the use of version and configuration management is of particular relevance. During the verification process, for instance, different model <;lescriptions are made describing different parts of the system, various versions of the verification models are available (e.g., due to abstraction), and plenty of verification parameters (e.g., model-checking options) and results ( diagnostic traces, statistics~ are available. This information needs to be documented and maintained very carefully in order to manage a practical model-checking process and to allow the reproduction of the experiments that 
were carried out. 
1.2.2 Strengths and Weaknesses 
The strengths of model checking: 

• 
It is a general verification approach that is applicable to a wide range of applications such as embedded systems, software engineering, and hardware design. 

• 
It supports partial verification, i.e., properties can be checked individually, thus 


allowing focus on the essential properties first. No complete requirement specification is needed. 
• 
It is not vulnerable to the likelihood that an error is exposed; this contrasts with testing and simulation that are aimed at tracing the most probable defects. 

• 
It provides diagnostic information in case a property is invalidated; this is very useful for debugging purposes. 

• 
It is a potential "push-button" technology; the use of model checking requires neither a high degree of user interaction nor a high degree of expertise. 

• 
It enjoys a rapidly increasing interest by industry; several hardware companies have started their in-house verification labs, job offers with required skills in model checking frequently appear, and commercial model checkers have become available. 

• 
It can be easily integrated in existing development cycles; its learning curve is not very steep, and empirical studies indicate that it may lead to shorter development times. 

• 
It has a sound and mathematical underpinning; it is based on theory of graph algorithms, data structures, and logic. 



Characteristics of Model Checking 
The weaknesses of model checking: 
• 
It is mainly appropriate to control-intensive applications and less suited fo.r dataintensive applications as data typically ranges over infinite domains. 

• 
Its applicability is subject to decidability issues; for infinite-state syqtems, or reasoning about abstract data types (which requires undecidable or semi-decidable logics), model checking is in general not effectively computable. 

• 
It verifies a system model, and not the actual system (product or prototype) itself; any obtained result is thus as good as the system model. Complementary techniques, such as testing, are needed to find fabrication faults (for hardware) or coding errors ( for software). 

• 
It checks only stated requirements, i.e., there is no guarantee of completeness. The validity of properties that are not checked cannot be judged. 

• 
It suffers from the state-space explosion problem, i.e., the number of states needed to model the system accurately may easily exceed the amount of available computer memory. Despite the development of several very effective methods to combat this problem (see Chapters 7 and 8), models of realistic systems may still be too large to fit in memory. 

• 
Its usage requires some expertise in finding appropriate abstractions to obtain smaller system models and to state properties in the logical formalism used. 

• 
It is not guaranteed to yield correct results: as with any tool, a model checker may contain software defects.2 


2Parts of the more advanced model-checking procedures have been formally proven correct using theorem provers to circumvent this. 

16 System Verification 


• It does not allow checking generalizations: in general, checking systems with an arbitrary number of components, or parameterized systems, cannot be treated. Model checking can, however, suggest results for arbitrary parameters that may be verified using proof assistants. 
We believe that one can never achieve absolute guaranteed correctness for systems of realistic size. Despite the above limitations we conclude that 
Model checking is an effective technique to expose potential design errors. 

Thus, model checking can provide a significant increase in the level of confidence of a system design. 
1.3 Bibliographic Notes 

'Model checking. Model checking originates from the independent work of two pairs in the early eighties: Clarke and Emerson [86] and Queille and Sifakis [347]. The term model checking was coined by Clarke and Emerson. The brute-force examination of the entire state space in model checking can be considered as an extension of automated protocol validation techniques by Hajek [182] and West [419, 420]. While these earlier techniques were restricted to checking the absence of deadlocks or livelocks, model checking allows for the examination of broader classes of properties. Introductory papers on model checking can be found in [94, 95, 96, 293, 426]. The limitations of model checking were discussed by Apt and Kozen [17]. More information on model checking is available in the earlier books by Holzmann [205], McMillan [288], and Kurshan [250] and the more recent works by Clarke, Grumberg, and Peled [92], Huth and Ryan [219], Schneider [365], and Berard et al. [44]. The model-checking trajectory has recently been described by Ruys and Brinksma [360]. 
Software verification. Empirical data about software engineering is gathered by the Center for Empirically Based Software Engineering (www.cebase. org); their collected data about software defects has recently been summarized by Boehm and Basili [53]. The different characterizations of verification ( "are we building the thing right?") and validation ("are we building the right thing?") originate from Boehm [52]. An overview of software testing is given by Whittaker [421]; books about software testing are by Myers [308] and Beizer [36]. Testing based on formal specifications has been studied extensively in the area of communication protocols. This has led to an international standard for conformance 

Bibliographic Notes 

testing [222J. The use of software verification techniques by the German software industry has been studied by Liggesmeyer et al. [275J. Books by Storey \381] and Leveson [269j describe techniques for developing safety-critical software and discuss the role of formal verification in this context. Rushby [359] addresses the role of formal methods for developing safety-critical software. The book of Peled [327J gives a detailed account of formal techniques for software reliability that includes testing, model checking, and deductive methods. 
Model-checking software. Model-checking communication protocols has become popular through the pioneering work of Holzmann [205, 206]. An interesting project at Bell Labs in which a model-checking team and a traditional design team worked on the design of part of the ISDN user part protocol has been reported by Holzmann [207J. In this large case study, 112 serious design flaws were discovered while checking 145 formal properties in about 10,000 verification runs. Errors found by Clarke et al. [89] in the IEEE Futurebus+ standard (checking a model of more than 1030 states) has led to a substantial revision of the protocol by IEEE. Chan et al. [79J used model checking to verify the control software of a traffic control and alert system for airplanes. Recently, Staunstrup et al. [377]have reported the succesful model checking of a train model consisting of 1421 state machines comprising a state space of 10476 states. Lowe j278], using model checking, discovered a flaw in the well-known Needham-Schroeder authentication algorithm that remained undetected for over 17 years. The usage of formal methods ( that includes model checking) in the software development process of a safety-critical system within a Dutch software house is presented by Tretmans, Wijbrans, and Chaudron \393j. The formal analysis of NASA's Mars Pathfinder and the Deep Space-I spacecraft are addressed by Havelund, Lowry, and Penix [194l, and Holzmann, Najm, and Serhrouchini [210], respectively. The automated generation of abstract models amenable to model checking from programs written in programming languages such as C, C++, or Java has been pursued, for instance, by Godefroid [170], Dwyer, Ratcliff, and coworkers [193], at Microsoft Research by Ball, Podelski, and Rajamani [33) and at NASA Research by Havelund and Pressburger [195]. 
Model-checking hardware. Applying model checking to hardware originates from Browne et al. [66J analyzing some moderate-size self-timed sequential circuits. Successful applications of (symbolic) model checking to large hardware systems have been first reported hy Burch et al. [75] in the early nineties. They analyzed a synchronous pipeline circuit 
1020
of approximately states. Overviews of formal hardware verification techniques can be found in works by Gupta [179], and the books by Yoeli [428] and Kropf [246]. The need for formal verification techniques for hardware verification has been advocated by, among others, Sangiovanni-Vincentelli, McGeer, and Saldanha [362]. The integration of model-checking techniques for error finding in the hardware development process at IBM has been recently described by Schlipf et al. [364J and Abarbanel-Vinov et al. [2]. They conclude that model checking is a powerful extension of the traditional verification pro
18 

System Verification 
cess, and consider it as complementary to simulation/emulation. The design of a memory bus adapter at IBM showed, e.g., that 24% of all defects were found with model checking, while 40% of these errors would most likely not have been found by simulation. 



Prh-,c_\~ \~ 0 J NoL-\ C. Ba..i~r ~ J-1-':11.a.d--o~


C..'-'ec~ ~ , , 

TCTL Model Checking Mr T p,.._~ <i_oot (1?~~ +O~ -f{7' 709 
J 

Note that the resulting formulae are CTL formulae ( or could be understood as such) provided <I>does not contain intervals different from [O,oo). ■ 
In order to verify whether TA I=<I>for TCTL formula <I>.the above result suggests equipping TA with a clock for each subformula of <I>of the form '1iU1 w' while replacing this subformula as indicated in Theorem 9.37. This yields TCTLo formula <I>. As <I>does not contain timing parameters, and any clock constraint can be considered as an atomicproposition, in fact, ~ is a CTL formula! Verifying a timed CTL formula on a timed automaton TA thus reduces to checking a CTL formula on a TA extended with a clock whose sole purpose is to measure the elapse of time that is referred to in the formula. 
9.3.2 Region Transition Systems 
Consider timed autornaton TA and TCTLo formula <I>. It is assumed that TA is equipped with an additional clock as explained in the previous section. The idea is impose an appropriate equivalence, denoted~, on the clock valuations and implicitly on the states of TS(TA) by letting {e',17')~ {e,r/} if e = e' and r1~ r/-such that: 
(A) Equivalent clock valuations should satisfy the same clock constraints that occur in TA and 4>: 
r1~r/ a::;, (rypg iff r/pgforallgEACC(TA)uACC(<I>)) 
where ACC(TA) and ACC(<I>)denote the set of atomic clock constraints that occur 
in TA and <I>,respectively. These constraints are either of the form x ~ c or x < c. 
(B) 
Time-divergent paths emanating from equivalent states should be "equivalent". This property guarantees that equivalent states satisfy the same path formulae. 

(C) 
The number of equivalence classes under~ is finite. 



In the sequel we adopt the following notation for clock values. 
Notation 9.39. Integral and Fractional Part of Real Numbers 
Let d E IR. The integral part of d is the largest integer that is at most d: 
ldJ = max{ c E IN Ic ~ d }. 

The fractional part of dis defined by Jrac(d) = d-ldJ. For example 1 ll7.59267J = 17, fmc(l7.59267) = 0.59267, l85J = 85, and fmc(85) = 0. ■ 



710 Timed Automata 
The definition of clock equivalence is based on three observations that successively lead to a refined notion of equivalence. Let us discuss these observations in detail. 
First observation. Consider atomic clock constraint g, and let 1Jbe a clock valuation (both over the set C of clocks with x E C). As g is an atomic clock constraint, g is either of the form x < c or .1;::;; c for c E IN. We have that 11 I=x < c whenever 17(x)< c, or equivalently, l11(x)J < c. The fractional part of 17(x)in this case is not relevant. Similarly, 1] I=x ::;;c whenever either l77(x)J< c, or l11(x)J= c and frac(x) = 0. Therefore,.,., I=g only depends on the integral part l7J(x)J, and the fact whether frac(1J(x)) = 0. This leads to the initial suggestion that clock valuations 17 and 1}1 are equivalent (denoted ~1) whenever 
lrJ(x)J = lr,'(x)J and frac(17(:i;))= 0 iff .fmc(r/(x)) = 0. (9.1) 
This constraint e11sures that equivalent clock valuations satisfy the clock constraint g provided g only contains atomic clock constraints of the form x < c or x ~ c. (In case one would restrict all atomic clock constraints to be strict, i.e., of the form :1: < c, the fractional parts would not be of importance and the second conjunct in the al.Jove equat_ion may be omitted.) Note that it is crucial for this observation that only natural number constants are permitted in the clock constraints. This equivalence notion is rather simple, leads to a denumerable {out still infinite) number of equivalence classes, but is too coarse. 
Example 9.40. A First Partitioning for Two Clocks 

To exemplify the kind of equivalence classes that one obtains, consider the set of clocks C = 
{:c, y }. The quotient space for C obtained by suggestion (9.1) is depicted in Figure 9.18) where the equivalence classes are 
• 
the corner points (q, p) 

• 
the line segments { (q,y) Ip< y < p+l} and { (:1:,p) Iq < x < q+l }, and 

• 
the content of the squares { (x, y) Iq < x < q+l I\ p <:ti< p+l} 



where p,q E IN and { (x,p) I q < :i: < q+l} is a shorthand for the set of all clock evaluations 17with r7(x)E ]q, q+l[ and r7(y)= p. 
Second observation. We demonstrate the fact that ~1 is too coarse by means of a small example. Consider location ewhose two outgoing transitions are guarded with x ~ 2 {action a) and y > l (action /3),respectively; see also Figure 9.19. Let state s = (£,77) with 1 < 17(x)< 2 and O< 17(y)< 1. Both transitions are disabled, so the only possibility is to let time advance. The transition that is enabled next depends on the ordering of the 
TCTL Model Checking 
(x=3,y=2) , I  
y  2<x<3 ,l<y<2  


2  -~----+--- ..- 
1  . _______________  
1  2  3  X  

--{?;= 3, 0 < y < 1) 
Figure 9.18: Initial partitioning for two clocks . 

y 
2 t--+--+--+--+

2 3 4 

Figure 9.19: Fragment of timed automaton and time passage of two clock Yaluations. 
fractional parts of the clocks :randy: if fra,(11(.1:)) < frac(17(y)), then ,ais enabled before a; if frac(11(;r)) ~ /mc(17(y)), action o is enabled first. Time-divergent paths in s may thus start with a if frac(17(x)) ;:i:.frac(17(y)). and with {3otherwise. This is represented by the fact that delaying leads to distinct successor classes depending on the ordering of the fractional parts of clock, see Figure 9.19 (right part). 
Thus. besides l11(.i:)j and the fact whether frac(11(:r)) = 0. apparently the order of the fractional parts of 11(x) . .r EC is important as well, i.e., whether for :r, y EC: 
frac(17(x)) < frac(11(y)) or frac(11(x)) > fmc(17(y)) or frac(1J(x)) =frac(rJ(y)). 
This suggest:, extending the initial proposal (9.1) for all x,y EC by 

frac(17(x)) ~ fmc(1J(Y)) if and only if Jmc(r/(:r)) ~ frac(,,'(y)), (9.2) 
i.e.. 111:;2 112 iff '71 :;1 112and (9.2) holds. This strengthening will ensure that equivalent states (e.17) and ([, 171) have similar time-divergent paths. 
71:2 Timed .4.uto11m1,, 

!J 

/ iP.1 

I • ◄-------1-=-·-:i< ,l < l. l < y < 2 . .l' -_11 
. 
.. .,. 
~;I



,~. .1· 
~ :3<--.,· < ~-l , .J<, :Lr -JI , 2 .,I 
f· 
u~.-• 


E.m11q1h Y.41. A Semwl Pa-rlit.ioninq for Two Clocks 
Thi~ observation suggests to dccornposc the sqw1rns { (:1:, y) I q < :1: < c1+1 /\ J>< .lJ < p+·1 } into a liue segtne11l. ;111 upper aud lmn:r trin11glc, i.e., t.lte followiug three parts: 
{ (:1:,.IJ) I (f < :r < q+I I\ fl < !J < f)+ l I\ :c-y < q-p }, 
{ (:,:.y) I q < :r < q+l I\ /I< .lJ< p+l I\ :1:-y > q-p }. nnd 
{ (:1:,y) I (J < :1;< q+I I\ fl< !J < p+l I\ :1:-.11= r,-,, }. 
Figure 9.:20 illustrates lhc rcsult.i11g p~rtitiouiug for two clocks. 
• 
Pinal observation. The above const-rai11ts 011 clock equivalence yi<0 ld a den1.111wrnble though not fiuit.e quotie11t.. To obtain n11 equivalence witl, a fin.it<~quotient.. we exploit. the fa(;t t.hnt. in order t.o dec:idc whetber TA I=<I>only tlw dock co11strai11ts occmri11µ; iu 1:4 xml <l> are relevant.. As t,here are 011ly finitely mauy clock cow,tn-,iuts, we cau det.erllline for each clock :t EC' the 111axi111alclock const.rnint, c:,: E IN, say, with which :i: is co111pmed in some dock co11strai11t in eiLhcr Ti\ (as guard or locM.iou inv,1rinnt.) or <D. Si11cc C:1: is the largest constant with which clock :c is cotnparcd it. follows that if 11(:,;)> G:r:, t.lte act.11al vc"due of :i: is irrelcrn11t. (Clock :,; I.hat occms neither iu TA 11or in <I> is snpertl11011:, Hnd can be omittC'd: for these clocks WC' S<'t c_,.= 0.) As 11<·011seq11e11cc1.tlw coustrai11t.s (!J.1) me 011ly rck'vaut if 11(.r)<_,;:c, and q'(.r) ~ (·,.. while~ for (D.2) i11 additio11 11(y) ::;; <.:y a11d 1/'(!J)::;;Cy· 
The above• eo11sideratio11s sugg<'st tlte following uotiou or clock equivalence. 

TCTL Model Checking 
y 

1 2 3 4 
Figure 9.21: Third (and final) partitioning for two clocks (for Cx= 4 and Cy= 2). 
Definition 9.42. Clock Equivalence ~ 
Let TA be a timed automaton: 4>a TCTLo formula (both over set C of clocks), and ex the largest constant with which x E C is compared with in either TA or 4>.Clock valuations r,, r,' E EvaJ(C) are clock-equivalent, denoted r1~ r/ if and only if either 
• 
for any x EC it holds that 17(x)> Cx and 171(x) > Cx, or 

• 
for any x, y EC with r,(x), 171(x) ~ ex and rJ(y),171(y) ~ Cy all the following conditions hold: 


-L17(x)J= li7'(x)J and Jrac(TJ(x)) = 0 iff Jrac(171(x)) = 0, 
-Jrac(ry(x)) ~ frac(TJ(Y)) iff frac(r,'(x)) ~ frac(r/(y)). 
• 
As the clock equivalence~ depends on TA and <I>,strictly speaking one should write ~TA,4> instead of~-The dependency of~ on TA and <Pis limited to the largest constants ex; that is to say, neither the structure of TA nor that of cI>is of relevance to clock equivalence. The equivalence~ is lifted to states of the transition system TS(TA) as follows. For states Si = (€i,'T/i),i = 1, 2: in TS(TA): 

Equivalence classes under ~ are called clock regions. 

714 Tiwed Automata 
Definition 9.43. Clock and State Region 
Let Sa: be c1 clo(:k equivalence on C. The dock region or ,, E En-1/(( ). d<-'110tC'Cl[,,]: 1:,, defined l>y 
1 1
[,,J= { 1J E Eval{C) I 17Sa:IJ }. The :;talc rc_qio-n of s == (( rJ)E TS(TA), denoted [8]:i::;ddh1ed by 

I! 
In t.!te sequel, st,tte ,rnd clock regions an~ oft.e11 iudicatcd ns regions \\'hcu0.vcr it is dcm frorn t.lw rnutext. what. is rne,1111. Clock regions will be denoted hy r, r'. nnd so forth. We oft.cu w;e casual uotations to <h~11ote clock regions or clock valtwtious. For a timed n11to111at.011with two clock::;, :r and .1Js,w, 
{ ( :r, y) 1 < :i: < :2,o< y < L:1:-ii < 1 } 
de11otes t.he dock regio11 of all dock valuations 17 E Eva/( { :1:,y } ) with 
I < r1(:1:)< 1. and O < r7(y) < 1 aml fmr:(11(:c))< .fm<:(,,(y)). 
E:i:amplr 9.44. Light Switch Consider the t;illled automaton over C = { :1:} ror t.lie light swit.clt and the TCTLo fornHtla 
<I>= true. It follows that. the largest constant. with which :t is c:01uparcd is c,.-= 2; tliis is due to the locnt.icm i11vmiant :i; ~ 2. 
.1: ~ l 

8ldlr:h _o.ff' 
switc/t_on 
,-e;;ef. ( :,: ) 
W~! gradually com;truct t.hc regious for this timed nuto1w1.tou b:v considliriug each of the constraints in Definition 9.42 separaldy. Clock valu,ttions IJ.r,' ,l.r(' equivalent if 11(.r) a11d ·1/(:1:)h<'loug to the sauw equivalence class along t.hC' real tin<'. (In geueral, for n clocks this arno1u1ts to considering an 11-dime11sional hyperspace on IR-:,.o,) 
1. Tll<' rC'qnirement 1'.hctt·11(.r)> 2 and IJ'(:,;)> 2 or q(.r) ~ 2 and ,7'(:1:)~ '.2yields th<" partitioniug into the intervals [O, 2] aud (2, ex;,). 

p~V\c.~pl~ 
Cviec,,h-~ "'~ C '-" ""~ \.J Ge.;~r)os:t-P1'~ 

~tfT r~s LOO~ p~~~ G'71-G·9g 
Chapter 9 
Timed Automata 
The logics we haV<' Pnconntcrecl so far an• interpreted over transition systems that desc.riue how a reactive syst.em may evolve from one state to another, Timing aspects an•, however. not covered. That is, indications are given neither about th(• residence time of a state nor about the possihilit_v of taking a transition withi11 a particular time interval. However. reactive systems such as device drivers, coffee machines, comm1mication protocols, and automatic teller machines, to mention a few, must. react. in time they are t-ime-crilical. The behavior of time-critical systems is typically subject. to rather stringent timing constraints. For a train crossing it is essential that on det.e{'ting the approach of a train, the gate is dosed within a certain tiin<-' bound in order to halt car and pedestrian traffic before the train reaches the crossing. For a radiation machine the time period during which a cancer patient is sHbjectecl to a, high dose of radiation is extremely important; a smnll extension of this period is dangerous and can <:ause the µatient's death. 
To put it. in a nutshell: 
CmTcctness ·in limc-c1'ilical systems not only depend:; on the logir.al result (~/' the computation but also on the time at which the results an~ produced. 
As timeli11ess is of vital importance to reactive systems, it is essential that the timing constraints of the system are guaranteed to be met. Checking whether timing co11straint.s are met is the subject of this dmpter. In order t.o express such timing com;traiuts, the strategy will be t.o extend logical formalisms that allow expression of the ordering of events, with a notion of quantitative time. Sud1 extensions allow expression of timiug eonstraints such as: 
"The traffic light will turn green within the next 30 seconds.'' 
673 

Timed Automata 

A first choice to be ma.de is the time donrnin: is it discrete or continuous? A discrete time domain is conceptually simple. Transition systems are used to tnoclel timed systems where each action is assumed to last for a single time unit. ~fore ge11eral delays can be modeled by using a dedicated unobservable action. T (for tick), say. The fact that action a lasts k > 1 time units may be modeled by k-1 tick actions followed (or preceded) by Cl'. This approach typically leads to very large transition systems. Note that ht such models the minimal time cliffere11ce between any pair of actions is a multiple of an ,, priori, fixed, time unit. For synchronous systems. for instance, in which the involve(] processes proceed in a lockstep fashion, discrete time domains are appropriate: 011e time,, unit correspo11cls to 011e dock pulse. In this setting. traditional temporal logics can be used to express timing constraints. The next-step operator can be 11sed to "measure" the.> discrete elapse of time, i.e., 0 <I>nH~an::;that (f> holds c'l.fter exactly one time unit. By defining Ok+ 1 <I>= Ok (O <I>)and O O <I>= <I>,genernl timing constraints can be specified. Usi11g the shorthaud ◊~k <I>= O O <I>V O <I>V . . . V Ok <I>,the above informally st.at.eel timing constrai11t on the traffic light may be cxprc::;sed a:; 
D (red =:, ◊~:m green). 
For syuchronous syste111s, tra.usition sy:;terns and logics snch c1s LTL or CTL can be used to express timing co11straints, and t.rnditional modd checking algorithms snfficc. 
In this monograph we do not want to restrict omselves to synchronous systems, aud will consider--as in Newtonian physics time of a. c.:onti1111ous nature. That is to say, the nonnegative real nm11bers (the set IR~o)will be use<l as time domain. A main advantage b that there is no need to fix a minimal time unit in advance as a continuous time model is invariant against changes of the time scale. This is n10rc adcqnate for asynchronow; systems, such as distributed systems, in which components may proceed at distinct speeds, aud is more an intuitive than a discrete time model. Transition :;ystem representations of asynchronous systems without additional timing information are indeed too abstract t<, adequately model timing co11strai11ts,as illustrated by the following example. 
Example 9.1. A Railroad Crossing 
Consider a railroad crossing, as disc11ssed i11 Example 2.30 (page 51), sec the schemati,· representatiou in Figure 9.1. ror this railroad crossing a control system needs to b,, developed that dose:; the gate on receipt. of a signal indicating that a trai11 is approachiug a.nd ouly opens the gate once the train has signaled that it entirely no::;sed the road. Tl«· safety property that should be established by the control system is that the gates ar<:' always closed when the train is nossiug the road. The complete system consists of thi:' three components: Train, Gate, mid Controller: 
Train II Gate II Controller. 
Timed At1tomata 
675 


Figure 9.1: Railrond crossing (ti111e abstract). 
Tr1tin Conlrolhr Gate 
Figmc 9.2: Transitiou systems for process<>sTrain ([c,ft), Contrnller (midd!P). and Gale 
(right). 
Recall tha.t actions commou to a pair of proce::;ses need to be performed jointly, while• other actions a.re perfon11ed a.utonomom;ly. The transit.ion syste111s of these processes arc depicted in Figure 9.2. It follows that the composite system Train II Gate II Contrvlle1· does uot guarantee tha.t the gate is closed when the train is passing the crossing. This can c•asily he see11 by iuspecti11g an initial fragment of the composite transition system; see Figmc 9.:J it rannot be deduced from the tra.nsitiou system whether, aft.t!r sending the ··approach'' sigual, the train reaches the road before or after the gate has been dosed. 
Under the assumption. thungh, that the train docs not cxc·c•cd a certai11 maximum speed. a lower hound for the dmatiou between t.hc signal '·<tpproach·' and the time iustant at which the train lrns reached the crossiug can b<:>indic.:atPcl.SC'C Figure D.4. Let. us assume that the trni11 needs more tha11 2 minutes to reach the crossing nfter emission of t.hc "approach'' signal. AcC"ordingly. timing nssumptio11s arc made for the controlli•r and the gate. On receiving the ·'approach" signal, after exactly 1 minute the· cont.roller will signal the gate to be lowered. The actual closing of the gate is assumed not to exC't'ed a minute. The hranchi11g in global state (near, l, up) can now be labeled with timing information: 

G7G Tiwe<l 1\uto111ata 
(far, 0, up) 
fLl'J)IV(tCh 
(nell1', 1, up) lower enlcr (near, 2, down) (in, 1, 1q1) Figur<' f.U: Initial fragrn<'nt uf the trnn:,itio11 syst~!111 Tmi,i II Cunlrnlfor II Gale. 
11/Jf)l'l)(J.dl. 

low<'r 
m1sr 
approach -fnr 

e,;t, ( 
delay of execution ti11w 1 minute of~ 1 minute 
Figur<' !)A: The Train (left). Co-ntrolle·r (middle), and Gale (right) with timit1g as:;uw,,tion:;. 
Timed A.11/.u1w1l.ct G77 
G 

near 2 down 
a roach 
far O up 
in I up 
The train can onl.v execute the locnl stnt0 change near <J,,tt~ in c1fler more thau 2 mi11utes. On the other hand. the gat<! is dosed at most 2 1t1i1111tes..'lfter receiving the .. approach'" signal. Therdore. th<' global stat<:' chaHge 
entcr ( • l )
(-near. I. ·up ~ 1.n. . 11.p
> 
n<'ver occ1m;. Tims. tlw gate is always dosed before the train readies th<) crossi11g. The faC't t.hat the ga.t.e remai11s closed a& long ,,s t.he trnin is 011 t.lw crossing is e11smed by the fact that action raise can ouly happen after th<' trnili has indicated e:1:it. ■ 
As a modeling fornwlism for timc-criticc1l syst.eirn,. the Hot.ion of limed o.ntmnata. has heeu developed, all extension oftrausition systems (in fact, program graphs) with duck variables that measme the elapse of time. This model includes means to impose constraints on the resideuce times of states, and on the timing of a('tions. 
9.1 Timed Automata 
Timed a11tornatn model the behavior of time-critical systems. A timed automB.tou is in fact a program graph that is equipped with n finite s<'t of real-val11ed clock variables, called clucks for short. In the sequel w<• assume that the set of clocks is denumernhl0. a11d we will use x. y, and z as clocks. Clocks are <liffereut from the usual variables, as their access is limited: docks may only be inspected, and reset to zero. Clocks ca11 be reset. to ·wro aftc'r which they start increasing their value implicitly as time progresses. All clocks proceed al rate one, i.e., after the elapse of d tim<" units, all clocks advance by 
d. The ,value of a clock thus denotes th<• amount. of time that has bee11 elapsed since its last reset. Clocks can int.uitivdy IH-·<·ow-;idered as stopwatches that can be started aud <'hecked iu<lepeudeHtly of oue another. Conditions on the values of the clocks are used as enabling couditions (i.e .. guards) of actions: only if the condition is fulfilled is the action enabled nnd cap,1.ble of being takf·n: otherwise, the action is disabled. Conditions which depend on clock values arc called dock wnstraints. For the sake of simplicity; it is assumed that cnabliug con<litious only depend on clocks and not on other <lata variables. Clock 

Timed Autornatc1 
coustrnius arc also used to limit. the amount of time that 1nny be ::;peut i11 a location. The 
following definitiou prescribes how constraints over clocks are to be defined. 
Definition 9.2. Clock Constraint 
A dock constrnint over ::;ct C of clocks is for med according to the grarn111c,u· 
.I.J::= _,.< (; I ;J; ~ (· I :,; > r, I J; ~ ('. I _qI\ _(J 
where c E N and a: E C. Let CC(C) deuote the set of clod~ co11strc1i11tsover C'. 
Clock constrnints thM do not, contai11 ally c0Hj1111ctiollsme atomic'. Let. ACC(C) denot,
the set of all atomic-clock constrai11ts over C. 
., 
Clock constraints arc often written in abbrevin.t-cd form, e.g., (:c ~ c 1) /\ (:1:< <:2) may hahhr<'viat.cd by :1: E [ci,c2) or c1 ~ :i: < c:2, Glock difference constraints si1ch as :1:-y < ,· nm lw added nt t.hc expcns<' or a slightly more iuvolved theory. For simplicity, they rn.--.. omit.te<l here and we restrict the discussion to atomic clock constraints that compare · dock with a constant c E N. The decidability of the model-checking problem is not affccl.e(\ if c is allowed to be rational. In this casf' tlw rationals in each formula can be couverted iuto natural numbers by suiLable scaliug. In geueral, we can multiply each constant by the, least common nrnltiple of denominators of all co11sta11ts appearing in all clock constraints. 
Int11itiv<-ly,n timed automaton is a (i;lightly modified) program grnph, whose varial>les ar,.' clocks. The clocks arc used to formulate the real-t,ime assumptions 011 i;ystcm behavior. An edge i11~l timed automaton is labeled wilh a guar<l ( whe11 is iL allowed to take ,u, edge'?). an action (what b performed when Laking the edge'?), nncl a set of clocks (whi<:li clocks arc to be reset'!). A location is equipped with an invariaut tha.t constrains the amount of time that may he spent i11 that location. The formal dt>finit.ion is: 
Definition 9.3. Timed Automaton 
A timed automaton is a tuple T.4 = (Lo('. Act. C. ~, Loc0, hlv, AP. L) where 
• 
Loe is a finite set of locations, , 

• 
Loco ,;;;;Lo<' is a set of initial localions. 

• 
Act is a finite set of act.ioni;, 

• 
C is a finite ::;et of doeks, 


Timed Automata G79 
o c...-, ~ Loe x C'C(C')x Act x 2c x Loe is a t.ransition n•lation. 
• /nu: Loe---,. CC(C) is n11 i11vari<1.nt-c1ssign111e11t: 
fu11ctio11. 
• 
AP is a tiuite set of atomic propositions. and 

• 
L : Loe -2AP is a labeling function for the locatio11s. 


ACC(TA) denotes the set of alolllic dock constraints that occur in eitlier H guard or a locntio11 iuvariant of TA. ■ 
A timed nut.0111atou is a µrogram graph with a finite set C of clocks. Edges are labeled wit.h tnplcs (_r1,n, lJ) where y is a clock c;onstrnint 011 tl1e clocks of the tirned f1uto111<1tcrn. • t· I D c C' • f 1 I 'fl • • • • • t· f' !r<,. D f' •
o-1s au ,1c 1011, cUJ< _ 1s a s<-'t o <·oc<S. • 1e mt111t.1ve 111tcrprctntwn o • '---' • 1s that the timed mitonrnt.on Utll lllOW from loc:1:,tion( t.o locat.iou (' when cloc:k (:011:,;traiut g holds. Besides, when moving from localiou Cto t', nny clock in D will be reset. to zero and actiou o is performed. F11uc:tiouInv Hssigns to each location ;-1 location i11variant thfl.l spec-ities how loug t.lw timed auton1atoll llHlY stny there. For location l, lni:( () constrains the amouut of time t·hat may he spent in (. That is to say, the locntio11 ( shonld be left before the invariant ln:u(l') becomes iuvali<l. If this is not possihlt>-a::, there is no outgoi11g transitio11 cnablccl--no furtlwr progress is possible. f11 the formal semantic-; of timNI automata (set> Definition 9.11) this situatio11 cauoes time progr<'ss to halt. As time progress is no lo11ger possible, this sitnatiou is also k11uw11as ;-).tim.elud:. This ph<~nomenon will be discussed in more detail later. The function L has tht> same role as for trn11sition systems and as~ociates to any locatio11 the set of atomic propositions tlrnt arc valid in that lo<.:atiou. 
Before c-011sidcringl he precise interpretation of t irned autolllata, we give some simple examples. 
For depicting timed autorn,,ta we adopt. the drawing conventions for program graphs. lnvariauts ar<~ indicated inside locatious and arc omitted when they equal true. Edges are labeled with t.he guard, the action, and thf' s<'t of docks to he reset. Empty :-;et.s of docks are often omitted. The same applies to clock co11str<1inU-;t.hat. are co11stautly true. The resettiug of set D of docks is sometimes indicated by resel(D). If t:he actions are irrelevant, they an'. omitted. 
&wmple 9.4. Guards vs. Location Invariants 
Figure 9.5(a) depicts a simple timed antomaton with 01w clock :c and one location (' equipped with a self-loop. The self-loop cau be takeu if clock :i: has at least the value 
2. and when being taken, clock :i:is reset. Initially. by default clock :c has the v,1lue 0. 

680 
Tim<"dAutom~ta 
'i' l·~1lt1t> 
or,. 




-l 


1' 
valrn· 
of .r· 

Figure 9.5: Some timed automata with a siugle clock and 0110 of their evolutions. 
Figure 9.5(b) gives an example of an execut.ion of this timed automaton, by depicting th,.., value of clock ..t vs. the elapsed time since the start of the automaton. Each tim<' the clock is reset to 0. the automaton traverses the self-loop at locatiou e.As In11(€) = true. tinv· can progress without while residing in e.In particular,
any rE>A-;trictio11 a legal ht>havior ,,, this automaton is to stay in location f ad iufinitum. Formally, 
trne:.1=~2,{,c} 
....---3s>
Loe = Loco = {e}. C = { .t}. e f. and /n11( t') = true . 
Labelings and actions are omitted. 
Ti rne<i A.11 touwl,i 
681 
---, 
ap lo1m:r coming J.uw11
{up} 0
true .i.: (; l
reset(:,;) 
:i; ~ l 
goiny up mise 
down
0 {down}
:i: (; 2 tn1.f:
m~ct(:1:) 
Figme 9.G: Timed automaton for the Gate. 
Clrnngiug the timed ant.ornat.ou of Figmc ~l.5(a) :;lightly by incorporat.iug a locat,ioll iuvari<lllt :r; ~ 3 in loc:atio11( leads to the effect that :1: cai111otJ)l'O!,?;l'CS8 unboundedly auyrnorc. Rather, if ;1;;?: 2 (guard) aud :t ~ ;{ ( iuvariant) the outgoiug trnnsition 11111st.lw taken. Note lha.t it i:; not specified at which time irn;tant in the interval [2, 3] the transition i:; takcu, i.e., Lhb is determined 110Hdetnrministi<.:ally. The timed nnto11rnto11 nud nil example of its behavior are ill11st.ratcd iu Fignre 0.5(c) aud (d), respectively. 
Ohscrvc thal the sa111e effect is 110t obtained wheu strengthening the guard iu Figure 9.5(a) iuto 2 ~ :1:~ ;{ while keeping !nu( C) = trnc. T n that. case, the 011tgoing transition ca1t only be taken when 2 (; :1; (; :3-Hs itt the prcivio11s s<:cnario·--but is not forced to be takeu, i.e., it: cm1 simply be ignored by letting time pass while staying itt C. Thi:; i1> illttst.rated in Figure 9 .. 5(e) nnd (f). 
Put i11 a 1mtshcll, inw1riants are the only uieam; to force trausiLion:-; to be taken. ■ 
E:i:ample .9.5. Timed Automaton for lhe C:atf~ 
Consider the gate for the railroad crossing (see Exampl0 0.1, page 674). Assuming that lowering the gate takes al. most a siuglc time uniL, all(! rai1>ing the gate lakes at least on(' aud at most t.wo time 1111it8,the timed automaton for process Gate is t:?;ivcn as in Figure 0.G. \Ve have Act,= { lower, mise} and 
Loe = { up, cominqdown, do11m. _qoingup } 
with Loco= {up}. The trausitions of tlie timed automaton arc 
up com.htgdO'lon coming down down 
ll uc: ,..,_,,.. , .. { ;,: } 
;.t· > I· T 0
down goin_qv.p goingup c:; • • > up
r 
The location coming down with invariant .i; ~ 1 has hc<'n added to model that the maximal delay betwecu tbc occ1trrem:f> of a<"tion lower aud the drn.ng~ to location down is at. most 


682 Timed Au1011wta 
lime ir,8/.. time in.st. .'}Olllfl 11 fl ;3_7 ~ -5.0971 
Iin)f! inst. :raisf! 
2.172-........,---~'
down 
time i11s/. i 
r--
r:0111iny clo(('11 LH8~ 1 :lower :lowe,· 
--~ 
0 1 2 5 G T 
Figure 9.7: Location dingram for tlH' t.imcd m1t.O11wlonGal<~. 
a siugle tirn<' 1111it'. C'lock .r is set to zero 011 th(' occ111-re11c·t-'ul' a<'tion lowt:F a11d tl111-. 
"rncnsur<!:•t the dapsc of t.i111e since t.hnt. occtttT<'ncc. By restridin?; the residence t.ime or comin_q down to :t: ( L the switch to down 111t1sl b<' made within one ti111e nnit.. Note l..hn.i• this wonld not have beeu csl..ahlished by ltnvi11g 11 dired edg<' between lo<:atiuus up 1111<1 down with gumd :r.: ( 1, ns tlw v,ll11e or :r wo11ld not refer to th~, ti111e of' occ111T<mce of lowr-:1'. In a similar w,w,the purpose of location _qoingupwith invarim1l .r ~ 2 is to model tlmr rnising t.he ~<1te takes at. most two time nnit.s. In I he initial location 11.p, 110 constraints ,m, imposed on t.he rcsideuce lillle. i.e., lnrl(-up) = tnK'. The same applies to locat.io11 dow11. Let AP= {up, down} with the labdiug; fuHction L(up) = {up}, L(down) = {down}, mtil 
L(comingdown) = L(goinyup) 0. ~ 
Remm·/,;, 9.6. Location Diagrn.m Every huite behavior of a timed a11to111aton c:au be represc11ted by a location rliaymm. Thb depicts for <•very time im;tant up to som<' a priori fixc'd 11pper bound. the localion of tl1\' timed auto1mtton during that behavior. For Lhe tinwd m1tomaton of the Gale a possil;[,, real-t.itue behavior is i11dicatcd by the location diagra111 i11 F'igmc 0.7. ta 
Parallel Composition of Timed Automata For modeli11g complt>x syste111s it is C'<•Ive11ie11t to allow paralk.,l composition of tirnC'd ,rnlo111ata. This allows fur the llloddiil;; of tillle-crit.ical systems in a compositional rnauner. \Ve considc~r a parallel compositi<:.111 operator. denoted IIH,that is para111eterizcd with a set. of horul::;/wking actions H. Thb operator is sirnilar in spirit to the corresponding operator on transition systems; sec Definition 2.26. page 48: actions in H need t.o be performed jointly by both involved tim,,.d 
I ' 

Ti1m:d Auto11wlc1


--------------------------------G83 
automata.  wht•rea~ ,Ktions out.side H  are  pcrfornwd  a11to11omo11slyiu an  iuterleavcd  fash 
ion.  
Definition  9.7.  Handshaking  for Timed  Automata  

L<'t TA.; = (Lo<:;, Acti, Ci. c.......;,Loc0_;.Inv;, AP;. L;). i = l. 2 he timed a11to111ata with fl~ .,\ct., n A.<:t2, C1 n C2 = 0 and A.Pi ri AP1 = 0. The timed a11tomnto11 T/\1 llnTA2 is defined as 

where L( (('t. f2)) = L 1 { ei)UL2( €2) ,111dlnu( (C1, f..J) = lnu1 ( Ci)l\luv2 (€2)-The transitiou rt•lat:io11'-----is defiued by the following mies: 
• 
for u E fl: 

• 
for o· ~ fl: 



y:o-,l)
!t=et,/J l 
f1 I e', f.2 2 e'2 
Hild 
fJ:e>..D y:a.U
(e,.e2) (l'~, e2) (f I ,C-2) (e,.f~} 
• 
The lorntio11 i11varia11t of a composite loc-atio11 is simply tht> conjunction of the location invariants or its constit11e11ts. For <l E H, the transition in the resulting timed automn.t.011 is guarded by tlw <·onj1111('tio11 of the individual
oft.he guards tirned aut..oma.ta. This <>ntails that an action in II can only be taken when it. is enabled in bot,h t.imed automata. Besides. thf' clocks that are reset in the individual automata are a!l reset. As for transition systems. Ll1<'operat,or !11-1is associative for a fixed set. fl. Let TA1 IIHTA2 llu ... IITAn denote t,ht> J>cuallel composition of timed automata TA I through TA,, where H ~ A.c:t1 n ... n Acl,,, assuming that. all t.imecl automata are compatible, i.e., ea('h pair of TAi and 1)\.i, i -=fj have disjoint sets of atomic proposition!-> and disjoint. clocks. 
E .. wmplc 9.8. Rail.,-on.dOros.sing 
Consider agai11 the railroad crossiug example. \Ve extend the timed automaton for thf' gate (see Example 9.5) with t.imed automata for the cont.roller and the train. The complete system is then given by 
(Train11HI Conlrollr:1·)IIH2 Gate 

Timed Automata 
i 

Tmin Cor1lrolle1· 
Figure 9.8: Timed automata. for the train and the controller . 
where H1 = { approach, e:ril} a11clfl2 = { lower, rats(,}. 
Let us assurne that the train signals its approaching of the gate at least two time units before it enters the railroad crossing. Besides, it is assumed that the train h,1s Hufficieut. speed such that it leaves the crossing five time units after approaching it, ,,t. t.he latest .. The timed antoma.to11 for the Train is depicted in Figure 9.8 (left). 011 approaching tlw gate, clock y is set to zero, and only if y > 2 is the trai11 allowed to enter t.he crossing. The Controller is depicted in Figure 9.8 (right) and is forced to seud the signal "lower'' 
(t.o the Gate) exactly after 011c time unit aft.er the Train has signaled its approaching. 
Figure 9.9 shows the composite timed automaton. The prefix of n possibl<> hehavior of t:lw complete system is sketched iu the location diagram in Figure 9.10. 
Note that this timed automaton contains the location (in, 1, 1tp). In this location. the train is at the crossing while the gate it. still open. However, t.his location turns out to lw unreachable. It can only be reached wheu y > 2, but as y and z are reset at the saul<' time (on entrance of the preceding location), y > 2 implies z > 2, which is impossible du<· 
to the locatiou invariant  z  ~  l.  ■  
9.1.1  Semantics  
The previous exa.mples suggest that  the state  of a timed automaton  is determined  by its  

current location and the current values of all its clocks. In fact, any timed automaton canlike program graphs be interpreted as a transition system. Due to the continuous tinH' domain, these underlying transition systems have infinitely many states (even uncountably 
Timed A11tonwt;1 

m:ise resd(:r) 
(/1t1',0,yoi11r1,q,) 
:t ( 2 
<lJl[IHJ<tch re.,et(y. z) 
, (near.l.9oi119 ·1'11) ' _I/ ( 5 II ~; ( 2 II z ( I 
enter !/ > 2 
,,. ;;:;: I C 
---------, (-in,1,/JOillf! llJJ) !L§ 5 A .c ,s;2 /I :; ,.; l 
Figm<' 9.9: The t.imcd nutomat.011 ( 7hr.inllH, Controller)ll1h Gate. 


686 Timed A11to111at,i 
going up down coming down up 
2 
() 
in near for 

0 2 3 4 5 <, 
Figure 9.10: Location diagram for n behavior of (Tminllr11 Contmll<-'r)llthGfltc. 
many): and arc infinitely branching. Timed automata Cl4.ll thus lw c:om;irtered as finit:(: descriptions of infinite transition systems. The underlying tnu1sitio11 system of a timed automaton results from unfolding. Its state:; consist of a control componeut, i.e., a locatio1,. eof the timed automaton, together with a valuation IJof t.hc clocks. States are thus pai1· of the form (e,11).Let us first consider dock valuations. 
Definition  9.9.  Clock  Valuation  
A clor:k valuation 1Jfor a set C of docks  is a function  ,, : C ---.iR~o, assigning to each clocl.  
x EC  its cmrent  value ·ry(.r).  u  

Let Eva/(C) denote the set of all clock valuations over C. In the following, we ofte11 us,:, notations like [.r = v, y = v'] to denote the clock t>valnation ,, E Eva/( {x. y}) wit.h11(:i:)= 1· and ,,,(:v)= v'. 
'vVe can 110w formally define what it means for a dock constraint. to hold for a clod~ valuation or not. This is done in a similar way as charac;terizi11g the semantics of a tempon logic, namely by defining a satisfadion rdatio11. l11 this case the satisfac:tion relation is a relation between clock valuations (over a set of clocks C) and clock constraints (ow,· 
C). 

Timed Auto11wt11 
687 
Definition 9.10. Satisfaction Relation for Clock Constrnints 
For scl G'of doC'ks . .r EC, 11E Enil(C). (·EN. Hild .r;.y' E CC'(C): let F~ En1/(C)x CC(C) 
be defined l.>y 
q I=lrue 
11 F :r < (: iffr1(:r) < (· 
I/ F ;/; :( (' iff 17(:r) :( c 
IJ I= -, f.J iff 1/~ fl 
11F fl I\ y' iff 1/ f=f.} I\ IJ f=!!' 
• 
Let 11be a dock rnl11nLio11(>11 ('. For posit.i\·c rc,ll r/. 11+d denotes the dock ,·aluation wltcn· all docks of 11arc in<T0,1sed by d. Forntally, (17+d)(.1·) = 11(:1.:)+ d for all docks :r E r. reset .i: in 11dt•11otes th<' clock v,tlunlion whid1 is <'q1wl Lo ,, cxccp(· that clock .1· reset". Fnrnwlly: 
1/(!J) if y =/:-.r
( reset :i.: in ,, )(y) 
{ 
0 if y = :l'. 
For t.hc clock valnatio11 '7 = [x = r.,.11= 4], val11atio1111+9 = [.r = 11➔ D.y = 1:3], and reset :1: in (11+9) = [.r = 0, y = lJ]. Nested oce11rrc·•11c<'sof reset are typically abbrcviatt•d. For iustanr.c, reset :r in ( reset !f in 17) is denoted reset .r. !/ in ·,,. 
Tlwrc c1re Lwo possihl<• ways in whicl1 a timed automaton can proceed: by taki11g a trnu!-Jition in the limed autumato11, or by Jetting time progress whil<• staying in 8 locat io11. In tlie uuderlying tra.usition system, tlw forn,cr is rcprese11ted by a diM-rr:l(' trn11sitio11 and the lcttter by a delay transition. 111the former c-ase. tlw corresponding lrausitiou of tlw 111Hhirlyi11gtransitio11 system is labeled with the actiou of tlw transition i11 lhe timed automaton: iu the latter case, it i:-;lah<•h\ wit Ii ,l positive n·al 1111111hcr indicating the nmount or time that lias <•lapsed. 
Definition 9.11. 'Iransition System Semantics of a Timed Automaton 
Ld TA = (Loe, Act, C, '-, Loco, hw. AP. L) he a timed a11tornato11. The transition system TS(TA) = (8. Ad, ........I, AP', L) wit.It: 
• 8 = Loe x Eva/(C) 

• I= { (eo,11)I to E Loco I\ 11(:r)= 0 for all :1; EC'} 
• AP'= AP u ACC(C) 

Timed Automat;:1 
• 
L'((e,TJ)) = L(e) u { g E ACC(C) Ir1F g} 

• 
the transition relation --+ is defined by the following two rules: 


discrete transition: {e, ·ry) ~ {e', TJ') if the following conditions hold: 
(a) 
there is a transition f, g~D f' in TA 

(b) 
T/I=g 

(c) 
TJ1 = reset D in 17 


(
d) r]'I=Inv(€') delay transition: (£,TJ)....i..,(e, ry+d) ford E ~~o 

(e) 
if 17+dF lnv(e) 


For a transition that corresponds to (a) traversing a transition e9~D e'in the timed automaton TA it must hold that (b) 17satisfies the clock constraint g (ensuring the transition is enabled), and (c) the new clock valuation r/ is obtained by resetting all clocks D in T/should (d) satisfy the location invariant of e'(otherwise it is not allowed to be in £'). Idling in a location (second clause) for some non-negative amount of time is allowed 
(e) if the location invariant remains true while time progresses. For state (f, TJ) such thnt TJF Inv(£), there are typically uncountably many outgoing delay transitions of the form (e,TJ) --4.... as d can be selected from a continuous domain. 
Example 9.12. Light Switch The timed automaton Switch in Figure 9.11 models a switch that controls a light. When off, the switch may be turned on at any time instant. The user may switch off the light at least one time unit after the most recent time the light was switched on. After two timf' units the light automatically switches off. Clock x is used to keep track of the delay since the last time the light has been switched on. (The timed automaton does not distinguish between the switch_off action activated by the user and by the light. This could be mack• explicit by adding an edge from location on to off; with guard x = 2 and action T.) Th.-. following location diagram indicates a possible behavior: 
on off 
b 
I I I 
0 3 4
0.3 1.39 2 2.2 3.783 
Timer/ 1\11lo1.1WlN 
689 

Figme 9.11: A simple light. :;witd1. 
The trnnsir.iou system TS(S111ild1) ha:-; t.lie state space S = {(o.fT,t}If. E ll~~o} u {(011.t, t E IR~o} where t is a shorthaud for the dock ev.-1l11atio11,, with 11(.r) = t. U11cou11tably llH'\.11,Y t.rnusit.ions ema1rnte fron, t.he i11itialst at.e (off. O}. TS( Switch) h,1st l1e followi11g tra.11:;itions for reals cl nud f: (off. t) ~ (off J + d) for all t ~ 0 aud d ~ 0 
:,wttr.h_,.,u
(off. I) (01,.0) for all t ~ 0 
d
(on, t) -. (on, t + d) for all t ~ 0 and d ~ 0 with t -rl ~ 2 
<rr.tll./,_l)lT
(on.t) 1 (off, t) for all 1 ~ (.:::; 2. The set of reacluhle stat.<!Sill TS( Switr.h) fron1 state (o.ff',0) is {(ojJ,t) I/ E IR~o} U {(on.I) IO:::;/.:::;2} n:-; the locatio11 invariant, :c ~ 2 is violated ill any stale (on, t) with f. > 2. A prefix of an exa.lllple pntl1 of TS(Switch) is (off, 0) ~ {ofT, 0.57) switch oa. (on, 0) A (on, v'2) ...!Ll..; h 011
(on, v'2+0.2) s"•itch_nJJ (off. /2+0.2) -~witr.-(on.O) ~ (on, 1.7) ... 
■ 
Run0-1k .9.J.'l. PmnllP[ Com.po.-;·1t1011 For tillH'd autu111ctla\\'t> have 

np to isomorphism. This is due to the fact that Ti\ 1 and TA2 do uot have auy shared variables. Synchrouizat.ion over time passage actious reflects Lhe nalural fact that time proceeds equally fast in both cornpo11e11ts. ■ 


690 
Timed Automata 
The paths in TS(TA) are discrete representations of the continuous-time "behavior" of TA. They indicate at least the states immediately before an<l after the execution of an action a, E Act. However, due to the fact that. e.g .. interval delays may be realized in uncountably many ways, different paths may describe the same behavior (i.e., location diagram). Consider, e.g., the behavior of the light switch of Example 9.12 where the light alternates between off and on while being off for exactly one time unit and on for two time units, i.e., a return to ofJtakes place after exactly three time units. The following three example paths correspond to this contimwus-tim<> behavior: 
r.1 = (o/J,O) (off, 1, (on.O) (on, 2) (off, 2) rr2 = (off, 0) (off, 0.5) (o/J, l) (on, 0) (on. l} (on,2) {o/J,2) 1T3 = (o/J,O) (off,0.J) (o.ff. l) (on,O) (on,O.fi:3) (on, 1.:3) (on. 2) (off, 2) 
The only difference between these paths is the delay transitions. In path 1r1, the one time unit residence in the initial state (off, 0) is realized by means of the delay transitiou (ofl,O) -1....,(off, I). In contrast, the paths 1r2 and 7ra realize this single time urrit by two delay transitions: 
05 05
(off,O) • (off,0.5) • (off, 1) and 
(off,0) ~ (off,0.1) 0•9 (off, 1). 
But the effect of the transition (e, ·ry) di +d2 1 (e,'tJ+d1+d 2) corresponds to the effect of the sequence of transitions: 
In both cases, d1+d2 time units pass without executing an action o E Act. Thereby, 1mcountably many states of the form (e,11+t) with O ~ t ~ d1+(h are passed through. 
Remark 9.14-Multiple Actions in Zero Time 
The elapse of time in timed automata only takes place in locations. Actions o E Act take place instantaneously, i.e., they have a duration of zero time units. As a result, at a single time instant, several actions take place. ■ 
9.1.2 Time Divergence, Timelock, and Zenoness 
The semantics of a timed automaton is given by a transition system with uncountably many states (and transitions). Paths through this transition system correspond to possible 

091
Timed All tornat,1 
behaviors of the timed automatou. Howevn. not t>ver~-such path represents a realistic behavior. This subscctiou treats three <'ssential phcnomenn for timed automata: time divergeuC'e, timelo<'k. mad &cnoness. 
Time Divergence Cousider a location Csuch that for any t < d. for fixed constant d E Ilho-clock valuatiou 11+1.F Jnv(e). A possible ('xec-ution fragment stl'lrting from this location is 

where d; > 0 mad the infinite sequence d1 + cl2+ ... conV<'rges toward d. Snch inlinit<·' path fragments nr<.' called l.imP.-<:011-uf-rgent.A time-convergent path is countcriutuitivc as time advances only up to ,\ certain value whereas by nature time always progresses. For 0xarnple, tlw transition system of the l.imed automato11 for the light switda (:we Fig;ur<:> 
0.11 on page G89) exhibits the ti111e-co11vcrgeut execnt:io11 fraga11eut

which vbits infinitely many states in the interval [½,1]. Time ncwr proceeds beyoHd one. The corresponding path is time-convergent. As timc-co11vergt'nt paths are not realistic, they are not. co11sidcrcd. That is to say, the analysis of t.i11H•dautomata is focused on ti·mc-divergenl paths, i.e., paths in which tillle always progresses. 
In order to formally defi11e time-divergent. paths, kt ns first define tilt> elaps<:>d time of a. path. I11t11itively. the elapsed time of a patli is the total time that elapses along a path. The duration of a11 act.ion o-E Act is &ero; the duratio11 of a delay action d is d. 
Definition 9.15. Elapsed Time on a Path 
Let TA he a timed a11tornaton with the set Act of act.ions. The functio11 E:recTim<' 
Act U IR:;,o -+ IR~o is <lefined as 0 if TE Act
Exer: Time (T) 
-{ d ifT=dElR.:,o-
For infi11ite exec11t.io11 fragme11t. p = so --214s1 --2:L;.s2 ... in TS(TA.) with Ti E Act U IR.>11 l<:>t 
E:r:ccTime (p) LX DcecTimP.(,, ). i=O 
The execution t,iane of finite execution fragments is defined analogously. For the path fragment" in TS(TA) iudnccd by p, Exf.<:Time(11) = Ex1:cTime(p). 
• 

692 Timed A11tomata 

Note that path fragment " may be induced by several execution fragments. However. every pair of execution fragments with the smne path fragment a.re only distinguished hy discrete transitions and not by delay transitions. Hence, E:i:ecTime(rr)is wcll-defiued. 
Definition 9.16. Time Divergence and Time Convergence 
The infinite path fragment ,. is time-divergent if E.1:ecTime(r.)= oo: otherwise, ,. b time-convergent. 
E:i:ample 9.17. Light Switch 
For the light switch described in Example 9.12 (page 688). the path ;r iu TS(Switch) in which on and off periods of 1 minute alternate: 
rr = (o/J,O) (ojJ, 1) (on.O} (on. l) {off, 1) (off. 2) (on,O) (on, 1) (off', 1) ... 
is tirne-diwrgent as ExecT-ime(rr)= l + 1 + 1 + ... = oc. The path 
rr' = (~/f,O) (off, 1/2) (off',3/4) (off. 7/8) (off, 15/16) ... 
in TS(Switch) is time-convergent, as Exec1'ime(1r') = I; (~)i+t = 1 < oo. Ill 
i=O 
Definition 9.18. Time-Dive1·gent Set of Paths 
For states in TS(TA) let: Pathsdiv(s) = { ;r E Paths(s) III is time-divergent }. !l 
That is, Pathsdi.u(s) denotes the set of timc-divergeut pat.hs iu TS(TA) that start in s. 
Although time-convergent paths are not realistic, their existence cannot be avoided. For 
the analysis of timed automata, time-convergent paths arc simply ignored, e.g., a timed 
·•, 
automaton satisfies an invariaut when along all its time-divergent paths the invariant is satisfied. 
Timelock. Stat.f' s in TS(TA) contains a timelork if there is no time-divergent path starting in s. Such states are unrealistic as tim<' cannot progress for ever from these states. Timelocks ,u·0 considered as undesired and need to be avoided when mo<leling n time-critical system by means of a timed automato11. 
Definition 9.19. Timelock 
Let TA be a timed automaton. States in TS(TA) contains i:\ timelock if Path.sc1iv(-~)= 0. TA is timelock-free if no state in Reach(TS(TA)) contains a timelock. !!El 


(1/f 
.r < 2 nset(.r) Figmc 9.12: Timed a11to11rnton 8wi.tr-h1. 

figmc ~J.H: Ti,ued S-witc:h
,1111:omal-O11 2. 
E.mmpl< !J.20. Modi/it'd f,igltt Switch We• modify th<• light swittli sud1 t,hat, t.lw light. is 011 for a period with dma.tiou t. E [l. 2), 
i.e .. th0 light is alwa..v:-;swit.chcd off wit.hiu 2 111i1111tcs;sec th(• timed a11t.ornato11Swit.ci,.1 in Figun· 9.12. T\1<· :-;t.ate {oo,2} ii-i read1able in tn.U1sitio11 systeu, TS(Swilchi), e.g., via tht' execution fraimeut: 
(ojJ,O) swil.ch-on. (on,0)-±.., (on, 2). 
As {on, 2) is a t.Nmiual sta.t.e, PFtthsdio((on.,2)) = 0, and the stitt-e <.:out.ains a timelock. Tirned c.llttomatuu Swilch.1b t.l11rn 11ot. t,i1uclock-frcc. 
J\uy terminal state of n t.rn11sit.io11system that results fru111 a t,imed a11to111atou ('Ontaius a timelock. Tt!rn1iuul states should not. be co11htsed ...,-iU1 t.cnuiunl locations, i.e .. loc.:atious I hat have no 011tgoiug edges. A terminal lurnt.io11 f. ,,·itlt ln-u(C) = lrnc. e.g .. does not result. in a terminal st.at<' i11 the m1<.l<•rl_vingt,rn.usit,iou system, as time 11iay progress i11f for ever. Termiual locations thus do not m•c·es.5,ll'ily yield states with timelocb. 
?\lot only tcnui11al st.ate~ 1w1..,·cu11tai11 tim<'locks. Co11sider, e.g., anotht'r varic111t of the lip;ltl switch where hw( on) .,· < ;i. sec tirned a11lomatou Swilc:h:2ill Figlll'<-' 9.13. Tlw n•ad1ahlc stat.c {on: 2) is 11ol termiuHI. . e.g .. the tin1e-c:01n-ergeut path i11TS(Swit<·h.2): 
(on, 2) (on, 2.D) (on, 2.09) {011.. 2.99!.)' ou. 2.999!}) ... 
<'llHt1t.-1tcsfrom it .. However, A1thsdiu( (on, 2') -0 1:u, the stntc (on. 2) lii"\s no 011tgoiug discrete trausitions (as the guard I ::;;:i; < 2 is violated), aud time cannot. progress beyoud thn'<' (dnc t.o Inv(011.)= .c < 3). St.ate (on,2 1 in TS(Swit<'h2) coutnins a timelock. Tin1<'d a11tomatou Suritch.2is t.hns not t.i111elock-frec. ■ 

69-! Timed Auto11wta 
Zenoness As opposed t.o the pn'scncc of t.iit1e-co11vergent paths. timclocks arc considered as mod<•liug flaws that should be avoided. The latter also npplies to zeuone:;s. Rernll that the executiou of ac:t.iom; ct E A.ct is instautirneolts. i.e., actions take no time. Without further restrictious, a timed automaton may perfonu infinitely many actions in a fi11it0 time intervnl. This phenomeno11 is also called zeno and represents uomealizable behavior. since it would require infinitely fast processors. 
Definition 9.21. Zeno Paths 
Let. TA be n timed automatou. The iufinite path fragrnent ,. i11 TS('lt\) is .,;eno (or: n 
zeuu puth) if it b time-convergent mid iufinit0ly nw.ny actions o E A.cl are executed along 
7i. [l 
Definition 9.22. Nonzenoness 
~-':_i A timed <1uto11111tou'1:4.i:,; ,wn-zr>no if LherE'cloc>snot exist an initial ze110p,,th in TS(T.4.).
' i'
. 
Timed autonrntou TA is t:lrns uon-zcuo if aml ouly if for every path ;; in TS(TA), either 1i is tinw-divcrgcnt or 1T is ti1110-couverient with alrnost 01tly (i.e., nil exc<!pt.for fiuiteJ:y
I 
t many) delay t.rn11sitio11s. 
◄ti I 

Note that 11011-zenoness,as well as t.i111clock freedom, only refers to the n',r1.r:/wblcfrngme111' of the trarn;itio11 system TS(TA). A 11011-zcuotimC'd automaton may possess zeno path~ 
starting i11au 11nreadrnblc state. Similarly, a t.imclock-free timed automaton rnay contain 
1111rcachable timelock states. 


1 
·t I' E:,:ampfo 9.23. Zeno Po.ths of u Light Switch 
Consider yet another \'ariant of the light. switc-h, i11 which the 11ser has the possibilit.v 

to push the on but.ton while the light is 011. While doing so, clock .r is reset. awl tlw 
light stays 011 for at most two units, unless the 11sN pushes the on hut.ton ag,1in: sec: 
timed nutomaton Switch:.! in Figure 9.14. The paths induced by tlw following excc1.1tio11 
fragments of TS(Switch:~) 

0•23 .. ,,.•1t1-/,_,,n 
(o.f/', 0) (on, 0) o.;,: (on, 0.5) "'"'"'·"". (on, 0) (on, 0.25) 
are zeno path:-; duriug which t.he nser presses the 011 hnt.tou infinitely fast., or fm,t.cr and faster. resp('<tively. 
This unrealizn.hlc behavior ca11 ht' avoided by imposing a minimal non-zero delay, c, say. between s11ce0s:-;ivc butto11 pushiugs by the user. This is established by imposing Jiw(on) = 

Timed .4utomata (i!)5 
:r: ~ 1 : switch_ofj' 

1r.set(:1:) 
Figure 9.J:I: Timed a11tomat.uu Swit.ch:1. .1; ~ 100 : switch_off 

:;;,,: 1 : switch 011 
resr I (.f) 
F'igure D.l::,: Ti111ed nutotnaton Switf'I,~. 
:i: ~ c for <: > 0. Note t.hat. r; should he ,\ 11al.11rnl 1111mh<!r. Iu order to mock! a. mi11i111.-\l respousc O < c < 1 where <; is rational, say c = bo,all time constrni11ts iu the timed
1 
a11t.omatou Swi.tch:1 11eedto he rcsc:alecl (s<ie Figure 9.15). Essentially. th<' tirned automaton Switch~ computes with a modifkd time unit.: one time 11nit for :,; iu Switch I correspo11ds 
I • 
LO Too lllllllltCS. 
■ 
To check whether or not. a timed automaton is non-7,cno is algorit-hmicnlly difficult. lusLcad, sufficient condit.io11s are co11sidered that. are silllple to check, f:.g., by a static a11alysis of the timed imtomaton. The following <:riterio11 is hased on t.hc int.nitio11 that a timed a11to111aton i~ 11011-zeno if 011 any of it!-i cont.rot cycles, lime advc\11ces with at least some constant amount (larger thc:1117,cro). This yields: 
Lemma 9.24. Sufficient Criterion for Nonzenoness 
Let TA be a l.imrd automaton w-i.th:;el C of clod~5.mf'h thfLI for every r:ontml r:yde in TA 

Qn:f\11 .G·o 
. . . c: :,, f n will, to= ln. 
them e:1:istsa dock x E C such /.hat 
1. :l: EC; for some O< i::;; n. and 

Tilllcd Aut<mwta 
2. for all cluck cvalua/.ions 'I tfwre exist.,<· E N>o su<"h that 
1J(x) < r, i.111plie:; (11 ~ .<J.1 01· 11111((1)). fur some O< j::;; 11. 
Then: TA i.c;non-zerw. 
Proof: Let. TA be a t.imed automaton over C with .r E C s,ttis(vi11g the t.wo co11straints stated in tht-daim aud i.j the ('Orresponding irn..lices. Ld ,r lw H path in TS(TA) t.hat. perfonns infinitely rnany acliom, <1 E Act. As Ti\ contai11s fiuit.f'ly 111,llly stntc·'S. "trawrscs so111e co11trol cyc:le fn <.......,.€'1 '-) ... <.......,.tn = l'o, Assn me that i ~ j. (t\s locat.iolls 011 ('yc·k,-:; can be re11umbered. tlib is not 11 restriction.) Cousidc•r tlw ]><1th frn~111cntiu TS(TA) that st.art.s nnd ('mis in location tn: 

B,r th<' conslrni11ts sarisficd by TA, dock :,: is resel 011 t.lt(' t.rnnsition f;_ 1 <-; l,. c111d the trn11sitio11 ei-l c........(_; is 1mly possible wheu 1/i-l (:r) ~ c (as for,,, 1(.r) < c. either I.ht• guard or t.hc locc1tio11 i11variant of C;arc violated). This implies that. hy tnwersi1ig th<• cycle fo '--, ... ~ fo time .:tdv1111ccswith at least c > 0 time units. I-le11ct•.r. b t:i111e-divcrge11l and TA b non-zeno. !Iii 
The condition in Lemma 9.24 is co111positio11f1l, i.c·!., if TA all(] TA' both satis(y tbC' constrnints, thell the para!l(~I <:(mtposed t-imc'd t111tornato11TA II TA' also satisfies tile co11strc1ints. This follows directly froui the fact tlwl a co11trol cycle in TA IITi\' consists of c1 control cycle i11'DL or TA', or both. If each ('Olltrol cycle in TA and i11 TA' salisfies the co11st.rai11t that t.i1ne slto11ld advance with al least some positive amount, tlae11 this thus ahm applies to each co11trol ('ydc iu TA '1~4'. Thb property sig11ifica11tly simplifies t.o checking whether n composite timed autolllaton is no11-ze110. In case a timed autotllctton is in Fact 11ntimecl (as no clocks are us<'d or all g11mds and iuvariants are vacuously trne), it. c<1n be collsidered as 11on-zc110, a11d th11s 11ot aft<,c-t the control cyd<:s of otl1er compo11e11t timed autornatn in a composite sysle111. 
E:r:ample fJ.25. Sufficient Condition for No11.zn1,011,css 
The timed auto111,1ton in Figure !l 1,3 (page G95) satisfies the constra.i11Ls i11 Lm1111w 9.2 1L In the control ('yclc off c........on '-<· of}', dock ;1; is reset on off ~ 0,1.. and the guard :1: ~ 100 ensmc:; that when goi11g fro111 location <~ffto on, tilllt-> has ad vc111ced with at least. 100 time units. On the control cycle on c........,on, dock :1: is reset, and the guard :i; ~ l ensures that nt least one tillle unit elapses 011 traversing this control cycle. 
The timed a11t01irnta Train., Gale. c111dController or Example 9.8 (page 683) all satisfy for any control cycle the coustraint:-; in Le11rn1a 9.24. Thi8 can be see11 as follows. Timed 
Timed Automata 
697 
automaton Gaf(' has one control cycle: np ~ ... ~ up. In that. cydt>. dock T is reset 
when moving from local-ion down to goin._q_up.Furthermore. for q(.r) < 1. lo<.:ationuµ is 
uot reachable due t.o tht) guard :r ;,: 1 oil _qoing_v.p'-;. up. This ensures that on traversing 
the control cycle up .___.... .___.up, time advances with at least 01te time unit. The timed 
automaton Train contains the control cycle far<---.... <------;far. However, clock y is reset on 
that cycle before reaching location near. and the guard y > 2 on near ~ in guarantees 
that. on traversing th<' co11trol cycle at. least one (in fact, more than two) time unit has 
<'lapsed. For Controller, the resetti11g of clock z mid guard z=l ensure that also this ti111ecl 
automaton fulfills the constraints of Lemma 9.24. The timed automata Tm.in. Gale and 
Controller arc thus 11011-zeno. As the control cycles in the composed timed automaton 
(Train lJH,Gate) 1111Controller are comprised of tlw constituting timed automata, this
2 
composed timed autonrnton is 11011-zt>no. 
■ 
The previous consiclerat.ions indicate that a timed auto1naton is adequately modt ... Jing a time-critical systt>111whenever it is 11011 zt>no and does tlot rnntain any timelock. Ti111t>lo<'·k free, non-zeno timed automata induce transit.ion systems without terminal states such that aloug any path only finitely many actions are executed in finite time. In contrast to zcno paths and timelocks, ti1ue-co11vergen1· paths will be trcat<'d akin to unfair paths (in fair CTL) and are explicitly excluded for analysis pmposes. 
A delay of d > 0 Lime units can he realized in different ways, in geuerid by n > 0 delay transitions of siZ<-'di through dn with di > 0 such that d = d 1+ ... +dn. As we are only iutere:-;ted in the amount of time aclvan<.:ing, a sequence of delay tran:-;itions labeled witlt dr through dn and a, sequence labeled with cl~through d~. say, such that. I::;~1 cl;= I:~'.:1 d~= 
d, are <.:om;idcrcd equivalent. and denoted by ~ . This relation is used later for defining the semautiu-; of timed CTL. 
Notation 9.26. Sets of Path Fragments 
L0t TA be a timed m1tomaton. For path fra.g1rn'nts in TS(TA) along which infinitely many action:-; arc performed, let 

denote the equivale11<.:f'class containing all infinite path fragments i11duced by t•xccution fragments in TS( TA) of the form 

ti 111~ ptti;.~;~s'~ '>f ti It)(: p(\$5.0g~ r,f ti me J).)SSagE' or rlo timP.•tntits ,/1 tin~~-unju <i'1 litn('-,mils 

698 Timed Automata 
where ki E W, di E IR~o and a, E Act 1 d1 ~ote iu the
such that. I::}::, = d1 • that =;, notations. actions are abstracted away. 
• h I 1 .
fi • f' do rli t: • f' . 
F 
or m 111te pat ragmeut rr E so===> s 1===> ... t 1at. per1orms 111uute y many actions, 
we have ExecTime(ri) = L;~0 d;. Path fragments in so~s1~ ... are time-div<>rgent if and only if Lid; diverges. 
Time-divergent path fragments that perform finitely many actions et E Act (but C'ontain infinitely rn<111ydelay transitious) an• represented in a similar way. except that after the execution of the last action er E Act the advance of time is represented by infinitely many 
l 
===;, transitious. That is, the set 
do d 1 d,, -1 I 1 I .<Jo==>s1 ===> ... ==⇒ .511 ==;, s11+ l ==;,-s,,+2 ===;, ... 
co!ltains all infinite pa.th fragments induced by the execution fragment of the fon11 

ti rue pa;;sa~c of lime J ►a&mgc C ► I 
iuflnitc ti111c passo.q:~.e
do tim~-units d,1 -I time•U1\its 
do tl1
Hence, so==> s1 ==⇒ ... is a uniform notation for all infinite time-divergent path fragments. ■ 
9.2 Timed Computation Tree Logic 
Timed CTL (TCTL, for short) is a real-time variant of CTL aimed to express properties of timed automata. In TCTL, the until modality is equipped with a time interval such that 
<I>U ·' W asserts that a 'II-state is reached within l E J time units while only visiting <!>-stat.es before reaching the IJ/-state. The fa.ct that a deadlock may be reached within thirty time units via legal states only, say. can he expressed as legal U fo.:m] deadlock. where the atomic propositions legal and deadlock have their obvious meaning. Timed CTL is sufficiently expressive Lo allow for the formulation of an important. set of real-time system properties. 
Definition 9.27. Syntax of Timed CTL 
Formulae in TCTL are either state or path formulae. TCTL state formulae over the set AP of atomic propositions and set. C of clocks are formed according to the following grammar: 
<I>::= true I a. I g I <I>/\<I> -.<I>I 3~ I V_p 



Real-Time Systems and Programming Languages 
Ada, Real-Time Java and C/Real-Time POSIX 
Fourth Edition 

Alan Burns and Andy Wellings 
University of York 
"f'.A,."f'
ADDISON-WESLEY 
An imprint of Pearson Education 
Harlow, England • London • New York • Boston • San Francisco • Toronto • Sydney • Singapore • Hong Kong Tokyo • Seoul • Taipei • New Delhi • Cape Town • Madrid • Mexico City • Amsterdam • Munich • Paris • Milan 
Pearson Education Limited 
Edinburgh Gate Harlow Essex CM20 2JE England 
and Associated Companies throughout the world 
Visit us on the World Wide Web at: 
www.pearsoned.co.uk 
First published 1989 
Second edition 1997 
Third edition 2001 
Fourth edition published 2009 
© Pearson Education Limited 1989, 2009 
The rights of Alan Burns and Andy Wellings to be identified as authors of this work have been asserted by them in accordance with the Copyright. Designs and Patents Act 1988. 
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, Saffron House, 6-10 Kirby Street, London EC 1 N 8TS. 
All trademarks used herein are the property of their respective owners. The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners. 
ISBN: 978-0-321-41745-9 
British Library Cataloguing-in-Publication Data 
A catalogue record for this book is available from the British Library 
Library of Congress Cataloging-in-Publication Data 
A catalogue record for this book can be obtained from the Library of Congress 
10987654321 
1312111009 
Typeset in Times Roman 10/12 by 73 Printed in Great Britain by Henry Ling Ltd., at the Dorset Press, Dorchester, Dorset 
The publisher's policy is to use paper manufactured from sustainable forests. 


Chapter 11 Scheduling real-time systems 
11.1  The cyclic executive  11 .10 An extendible task model for  
approach  FPS  
11.2  Task-based scheduling  11.11 Earliest deadline first (EDF)  
11.3  Fixed-priority scheduling  scheduling  
(FPS)  11.12 Dynamic systems and  
11.4  Utilization-based  online analysis  
schedulability tests for FPS  11.13 Worst-case execution time  
11.5  Response time analysis  11.14 Multiprocessor scheduling  
(RTA) for FPS  11.15 Scheduling for power-aware  
11.6  Sporadic and aperiodic  systems  
tasks  11.16 Incorporating system  
11.7  Task systems with D <  T  overheads  
11.8  Task interactions and  Summary  
blocking  Further reading  
11.9  Priority ceiling protocols  Exercises  

In a concurrent program, it is not necessary to specify the exact order in which tasks execute. Synchronization primitives are used to enforce the local ordering constraints, such as mutual exclusion, but the general behaviour of the program exhibits significant non-determinism. If the program is correct then its functional outputs will be the same regardless of internal behaviour or implementation details. For example, five independent tasks can be executed non-preemptively in 120 different ways on a single processor. With a multiprocessor system or preemptive behaviour, there are infinitely more interleavings. 
While the program's outputs will be identical with all these possible interleavings, the timing behaviour will vary considerably. If one of the five tasks has a tight deadline then perhaps only interleavings in which it is executed first will meet the program's temporal requirements. A real-time system needs to restrict the non-determinism found within concurrent systems. This activity is known as scheduling. In general, a scheduling scheme provides two features: 
• 
An algorithm for ordering the use of system resources (in particular the CPUs). 

• 
A means of predicting the worst-case behaviour of the system when the scheduling algorithm is applied. 


366 SCHEDULING REAL-TIME SYSTEMS 
The predictions can then be used to confirm that the temporal requirements of the system are satisfied. 
A scheduling scheme can be static (if the predictions are undertaken before execution) or dynamic (if run-time decisions are used). This chapter will concentrate mainly on static schemes. Most attention will be given to preemptive priority-based schemes on a single processor system. Here, tasks are assigned priorities such that at all times the task with the highest priority is executing (if it is not delayed or otherwise suspended). A scheduling scheme will therefore involve a priority assignment algorithm and a schedulability test. Other scheduling approaches, such as EDF, and multiprocessor and energy issues are also covered in this chapter. The first approach to be review, however, will be the traditional scheme involving the production of a cyclic executive. All issues concerned with programming schedulable systems are covered in the next chapter. 
11.1 The cyclic executive approach 
With a fixed set of purely periodic tasks, it is possible to lay out a complete schedule such that the repeated execution of this schedule will cause all tasks to run at their correct rate. The cyclic executive is, essentially, a table of procedure calls, where each procedure represents part of the code for a 'task'. The complete table is known as the major cycle; it typically consists of a number of minor cycles each of fixed duration. So, for example, four minor cycles of 25 ms duration would make up a 100 ms major cycle. During execution, a clock interrupt every 25 ms will enable the scheduler to loop through the four minor cycles. Table 11.1 provides a task set that must be implemented via a simple four-slot major cycle. A possible mapping onto the cyclic executive is shown in Figure 11.1, which illustrates the job that the processor is executing at any particular time. 
Task Period, T Computation time, C 
a  25  10  
b  25  8  
C  50  5  
d  50  4  
e  100  2  

Table 11.1 Cyclic executive task set. 
i 
Interrupt iInterrupt t Interrupt iInterrupt ..._____a~' I~c a I b I d HI...____ _a~' ____.cI_ a I
____._b I_ b____._l 
Time 
Figure 11.1 Time-line for task set. 

TASK-BASED SCHEDULING 367 
Even this simple example illustrates some important features of this approach. 
• 
No actual tasks exist at run-time; each minor cycle is just a sequence of procedure calls. 

• 
The procedures share a common address space and can thus pass data between themselves. This data does not need to be protected (via a semaphore, for example) because concurrent access is not possible. 

• 
All 'task' periods must be a multiple of the minor cycle time. 


This final property represents one of the major drawbacks of the cyclic executive approach; others include (Locke, 1992): 
• 
the difficulty of incorporating sporadic tasks; 

• 
the difficulty of incorporating tasks with long periods; the major cycle time is the maximum period that can be accommodated without secondary schedules (that is, a procedure in a major cycle that will call a secondary procedure every N major cycles); 

• 
the difficulty of actually constructing the cyclic executive; 

• 
any 'task' with a sizeable computation time will need to be split into a fixed number of fixed sized procedures (this may cut across the structure of the code from a software engineering perspective, and hence may be error-prone). 


If it is possible to construct a cyclic executive then no further schedulability test is needed (the scheme is 'proof by construction'). However, for systems with high utilization, the building of the executive is problematic. An analogy with the classical bin packing problem can be made. With that problem, items of varying sizes (in just one dimension) have to be placed in the minimum number of bins such that no bin is over-full. The bin packing problem is known to be NP-hard and hence is computationally infeasible for sizeable problems (a typical realistic system will contain perhaps 40 minor cycles and 400 entries). Heuristic sub-optimal schemes must therefore be used. 
Although for simple periodic systems, the cyclic executive will remain an appropriate implementation strategy, a more flexible and accommodating approach is furnished by the task-based scheduling schemes. These approaches will therefore be the focus in the remainder of this chapter. 
11.2 Task-based scheduling 
With the cyclic executive approach, at run-time, only a sequence of procedure calls is executed. The notion of task (thread) is not preserved during execution. An alternative approach is to support task execution directly (as is the norm in general-purpose operating systems) and to determine which task should execute at any one time by the use of one or more scheduling attributes. With this approach, a task is deemed to be in one of a number of states (assuming no intertask communication): 
• 
runnable; 

• 
suspended waiting for a timing event -appropriate for periodic tasks; 

• 
suspended waiting for a non-timing event -appropriate for sporadic tasks. 


368 SCHEDULING REAL-TIME SYSTEMS 
11.2.1 Scheduling approaches 
There are, in general, a large number of different scheduling approaches. In this book we will consider three. 
• 
Fixed-Priority Scheduling (FPS) -this is the most widely used approach and is the main focus of this chapter. Each task has a fixed, static, priority which is computed pre-run-time. The runnable tasks are executed in the order determined by their priority. In real-time systems, the 'priority' of a task is derived from its temporal requirements, not its importance to the correct functioning of the system or its integrity. 

• 
Earliest Deadline First (EDF) Scheduling -here the runnable tasks are executed in the order determined by the absolute deadlines of the tasks; the next task to run being the one with the shortest (nearest) deadline. Although it is usual to know the relative deadlines of each task (e.g. 25 ms after release), the absolute deadlines are computed at run-time, and hence the scheme is described as 


dynamic. 
• Value-Based Scheduling (VBS) -if a system can become overloaded (current utilization greater than 100%) then the use of simple static priorities or deadlines is not sufficient; a more adaptive scheme is needed. This often takes the form of assigning a value to each task and employing an online value-based scheduling algorithm to decide which task to run next. 
As indicated earlier, the bulk of this chapter is concerned with FPS as it is supported by various real-time languages and operating system standards. The use of EDF is also important and some consideration of its analytical basis is given in the following discussions. A short description of the use of VBS is given towards the end of the chapter in Section 11.12. 
11.2.2 Scheduling characteristics 
There are a number of important characteristics that can be ascribed to a scheduling test. The two most important are sufficiency and necessity. 
• 
A schedulability test is defined to be sufficient if a positive outcome guarantees that all deadlines are always met. 

• 
A test can also be labelled as necessary if failure of the test will indeed lead to a deadline miss at some point during the execution of the system. 


A sufficient and necessary test is exact and hence is in some sense optimal; 
a sufficient but not necessary test is pessimistic, but for many situations an exact test 
is intractable. From an engineering point of view, a tractable sufficient test with low 
pessimism is ideal. 
A scheduling test is usually applied to the worst-case behavioural description of 
the application. A system is schedulable with respect to a specified scheduling policy if 
it will meet all its timing requirements when executed on its target platform with that 
TASK-BASED SCHEDULING 369 
scheduling policy. A scheduling test is said to be sustainable if it correctly predicts that a schedulable system will be remain schedulable when its operational parameters 'improve' -for example, if a system is schedulable it should remain so if some of its tasks have their periods or deadlines increased, or their resource requirement reduced; or if the application is moved to a faster processor. 
11.2.3 Preemption and non-preemption 
With priority-based scheduling, a high-priority task may be released during the execution of a lower-priority one. In a preemptive scheme, there will be an immediate switch to the higher-priority task. Alternatively, with non-preemption, the lower-priority task will be allowed to complete before the other executes. In general, preemptive schemes enable higher-priority tasks to be more reactive, and hence they are preferred. Between the extremes of preemption and non-preemption, there are alternative strategies that allow a lower-priority task to continue to execute for a bounded time (but not necessarily to completion). These schemes are known as deferred preemption or cooperative dispatching. These will be considered again in Section 11.10.3. Before then, dispatching will be assumed to be preemptive. Schemes such as EDF and VBS can also take on a preemptive or non-preemptive form. 
11.2.4 Simple task model 
An arbitrarily complex concurrent program cannot easily be analysed to predict its worst-case behaviour. Hence it is necessary to impose some restrictions on the structure of real-time concurrent programs. This section will present a very simple model in order to describe some standard scheduling schemes. The model is generalized in later sections of this chapter. The basic model has the following characteristics. 
• 
The application is assumed to consist of a fixed set of tasks. 

• 
All tasks are periodic, with known periods. 

• 
The tasks are completely independent of each other. 

• 
All system overheads, context-switching times and so on are ignored (that is, assumed to have zero cost). 

• 
All tasks have deadlines equal to their periods (that is, each task must complete before it is next released). 1 

• 
All tasks have fixed worst-case execution times. 

• 
No task contains any internal suspension points (e.g. an internal delay statement or a blocking 1/0 request). 

• 
All tasks execute on a single processor (CPU). 


1As the deadline is derived from the task's period it is sometimes referred to as an implicit deadline. It the deadline value is different from the period then the deadline is explicit. 
370 SCHEDULING REAL-TIME SYSTEMS 
Notation Description 
B  Worst-case blocking time for the task (if applicable)  
C  Worst-case execution time (WCET) of the task  
D  Deadline of the task  
I  The interference time of the task  
J  Release jitter of the task  
N  Number of tasks in the system  
p  Priority assigned to the task (if applicable)  
R  Worst-case response time of the task  
T  Minimum time between task releases (task period)  
u  The utilization of each task ( equal to CIT)  
a-z  The name of a task  

Table 11.2 Standard notation. 
One consequence of the task's independence is that it can be assumed that at some point in time all tasks will be released together. This represents the maximum load on the processor and is known as a critical instant. Table 11.2 gives a standard set of notations for task characteristics. 
Each task is assumed to give rise to a (potentially) infinite series of executions. Each execution is known as an invocation (release) of the task or simply as a job. 
11.3 Fixed-priority scheduling (FPS) 
With the straightforward model outlined above, there exists a simple optimal priority assignment scheme for FPS known as rate monotonic priority assignment. Each task is assigned a (unique) priority based on its period: the shorter the period, the higher the priority (that is, for two tasks i and j, ~ < Tj =>Pi > Pj ). This assignment is optimal in the sense that if any task set can be scheduled (using preemptive prioritybased scheduling) with a fixed-priority assignment scheme, then the given task set can also be scheduled with a rate monotonic assignment scheme. Table 11.3 illustrates a five task set and shows what the relative priorities must be for optimal temporal behaviour. Note that priorities are represented by integers, and that the higher the integer, the greater the priority. Care must be taken when reading other books and papers on priority-based 
Task Period, T Priority, P 
a  25  5  
b  60  3  
C  42  4  
d  105  
e  75  2  

Table 11.3 Example of priority assignment. 
UTILIZATION-BASED SCHEDULABILITY TESTS FOR FPS 371 
scheduling, as often priorities are ordered the other way; that is, priority 1is the highest. In this book, priority 1 is the lowest, as this is the normal usage in most programming languages and operating systems. 
11.4 Utilization-based schedulability tests for FPS 
This section describes a very simple schedulability test for FPS which, although not exact, is attractive because of its simplicity. 
Liu and Layland (1973) showed that by considering only the utilization of the task set, a test for schedulability can be obtained ( when the rate monotonic priority ordering is used). If the following condition is true then all N tasks will meet their deadlines (note that the summation calculates the total utilization of the task set): 



t (~:)
::SN(2 1/N -1) (11.1) 
i=l I 
Table 11.4 shows the utilization bound ( as a percentage) for small values of N. For large N, the bound asymptotically approaches 69.3%. Hence any task set with a combined utilization of less than 69.3% will always be schedulable by a preemptive priority-based scheduling scheme, with priorities assigned by the rate monotonic algorithm. 
Three simple examples will now be given to illustrate the use of this test. In these examples, the units (absolute magnitudes) of the time values are not defined. As long as all the values (Ts, Cs and so on) are in the same units, the tests can be applied. So in these (and later examples), the unit of time is just considered to be a tick of some notional time base. 
Table 11.5 contains three tasks that have been allocated priorities via the rate monotonic algorithm (hence task c has the highest priority and task a the lowest). Their 
N Utilization bound 
1  100.0%  
2  82.8%  
3  78.0%  
4  75.7%  
5  74.3%  
10  71.8%  

Table 11.4 Utilization bounds. 
Task Period, T Computation time, C Priority, P Utilization, U 
a  50  12  1  0.24  
b  40  10  2  0.25  
C  30  10  3  0.33  

Table 11.5 Task set A. 
372 SCHEDULING REAL-TIME SYSTEMS Process 50 60 

Executing 
□ Preempted• Deadline missed 
Figure 11.2 Time-line for task set A. 
combined utilization is 0.82 (or 82% ). This is above the threshold for three tasks (0.78), and hence this task set fails the utilization test. 
The actual behaviour of this task set can be illustrated by drawing out a time-line. Figure 11.2 shows how the three tasks would execute if they all started their executions at time 0. Note that, at time 50, task a has consumed only 10 ticks of execution, whereas it needed 12, and hence it has missed its first deadline. 
Time-lines are a useful way of illustrating execution patterns. For illustration, Figure 11.2 is drawn as a Gantt chart in Figure 11.3. 
The second example is contained in Table 11.6. Now the combined utilization is 0.775, which is below the bound, and hence this task set is guaranteed to meet all its deadlines. If a time-line for this set is drawn, all deadlines would be satisfied. 
Although cumbersome, time-lines can actually be used to test for schedulability. But how far must the line be drawn before one can conclude that the future holds no surprises? For task sets that share a common release time (that is, they share a critical instant), it can be shown that a time-line equal to the size of the longest period is sufficient (Liu and Lay land, (1973) ). So if all tasks meet their first deadline then they will meet all future ones. 
C b a C b 
0 10 20 30 40 50 Time__. 
Figure 11.3 Gantt chart for task set A. 
UTILIZATION-BASED SCHEDULABILITY TESTS FOR FPS 373 
Task Period, T Computation time, C Priority, P Utilization, U 
a  80  32  1  0.400  
b  40  5  2  0.125  
C  16  4  3  0.250  

Table 11.6 Task set B. 
Task Period, T Computation time, C Priority, P Utilization, U 
a  80  40  1  0.50  
b  40  10  2  0.25  
C  20  5  3  0.25  

Table 11.7 Task set C. 
A final example in given in Table 11.7. This is again a three-task system, but the combined utility is now 100%, so it clearly fails the test. At run-time, however, the behaviour seems correct, all deadlines are met up to time 80 (see Figure 11.4). Hence the task set fails the test, but at run-time does not miss a deadline. Therefore, the test is sufficient but not necessary. If a task set passes the test, it will meet all deadlines; if it fails the test, it may or may not fail at run-time. A final point to note about this utilization-based test is that it only supplies a simple yes/no answer. It does not give any indication of the actual response times of the tasks. This is remedied in the response time approach described in Section 11.5. 
11.4.1 Improved utilization-based tests for FPS 
Since the publication of the Lui and Lay land utilization bound a number of improvements have been developed. Here two alternative schemes are considered. First a simple reinterpretation of Equation (11.1) can be employed. Rather than the N standing for the 
0 10 20 30 40 50 
Time---•► 

Figure 11.4 Time-line for task set C. 
374 SCHEDULING REAL-TIME SYSTEMS 
number of tasks, it can be defined to be the number of distinct task families in the application. A family of tasks have periods that are multiples of a common value (for example 8, 16, 64 and 128). 
Consider the task sets defined earlier. For task set B (Table 11.6) there are three tasks but only two families (the 80 and 40 periods imply a single family). So the bound for this system is now 0.828 (not 0.78). The utilization of task set Bis 0.775 so is below both bounds. However, if the period of task c is shortened to 14 (from 16) then the utilization of the task set rises to 0.81 (approximately) -this is above the Lui and Layland bound but below the new bound and hence this new task set is correctly deemed schedulable by this new test. 
For task set C (see Table 11.7) there is an even more impressive improvement. Now there is only one family (as the periods are 80, 40 and 20). So the utilization bound is 1.0 and hence this system is schedulable by this test. Although this result shows the effectiveness of this approach there is a drawback with this test -it is not sustainable. Consider a minor change to the characteristics of this task set; let the period of task a move from 80 to 81. This alteration should make the system easier to schedule; a period has been extended and hence the overall utilization has been reduced (though only by a small amount from 1 to 0. 994). But the move from 80 to 81 results in there now being two families and not just one, so the bound drops from 1 to 0.82. The new system cannot be proven to be schedulable (although it clearly is if the original task set was schedulable). 
Another improved utilization-based test was developed by Bini et al. (2007) and has a different form: 
(11.2) 
To give a simple example of the use of this formulation, consider again task set B (Table 11.6) with the minor modification that the period of task a is now 76 (rather than 80). The total utilization of this new system is .796 which is above the bound for three tasks, and hence schedulability is unproven. Note there are now three families so no improvement from the other approach. Applying Equation ( 11.2) 
1.421 * 1.125 * 1.25 = 1.998 < 2 
indicates that the system is schedulable by this test and, indeed, a time-line for this revised task set would show that all deadlines have been met. 
11.5 Response time analysis (RTA) for FPS 
The utilization-based tests for FPS have two significant drawbacks: they are not exact, 
and they are not really applicable to a more general task model. This section provides a 
different form of test. The test is in two stages. First, an analytical approach is used to 
predict the worst-case response time (R) of each task. These values are then compared, 
trivially, with the task deadlines. This requires each task to be analysed individually. 
For the highest-priority task, its worst-case response time will equal its own com
putation time (that is, R = C). Other tasks will suffer interference from higher-priority 
RESPONSE TIME ANALYSIS (RTA) FOR FPS 375 
tasks; this is the time spent executing higher-priority tasks when a low-priority task is runnable. So for a general task i: 

(11.3) 
where Ii is the maximum interference that task i can experience in any time interval (t, t + Ri).2 The maximum interference obviously occurs when all higher-priority tasks are released at the same time as task i (that is, at a critical instant). Without loss of generality, it can be assumed that all tasks are released at time 0. Consider one task (j) of higher priority than i. Within the interval [0, Ri), it will be released a number of times (at least one). A simple expression for this number of releases is obtained using a ceiling function: 
Number_Of-Releases 
= r ;; l 
The ceiling function ( 1 l) gives the smallest integer greater than the fractional number on which it acts. So the ceiling of 1/3 is 1, of 6/5 is 2, and of 6/3 is 2. The definitions of the ceilings of negative values need not be considered. Later in this chapter floor functions are employed; they compute the largest integer smaller than the fractional part meaning that the floor of 1/3 is 0, of 6/5 is 1 and of 6/3 is again 2. 
So, if Ri is 15 and T1 is 6 then there are three releases of task j (at times 0, 6 and 12). Each release of task j will impose an interference of C1. Hence: 
MaximumJnte,ference = 

r ;; lCj 
If C1 = 2 then in the interval [0, 15) there are 6 units of interference. Each task of higher priority is interfering with task i, and hence: 
Ii = I:: rRil C1 
}Ehp(i) Tj 
where hp(i) is the set of higher-priority tasks (than i). Substituting this value back into Equation (11.3) gives (Joseph and Pandya, 1986): 

(11.4) 
Although the formulation of the interference equation is exact, the actual amount of interference is unknown as Ri is unknown (it is the value being calculated). Equation ( 11.4) has Ri on both sides, but is difficult to solve due to the ceiling functions. It is actually an example of a fixed-point equation. In general, there will be many values of Ri that form solutions to Equation (11.4). The smallest such value of R; represents the worst-case response time for the task. The simplest way of solving Equation ( 11.4) is to 
2Note that as a discrete time model is used in this analysis, all time intervals must be closed at the beginning (denoted by '[') and open at the end (denoted by a')'). Thus a task can complete executing on the same tick as a higher-priority task is released. 
376 SCHEDULING REAL-TIME SYSTEMS 
form a recurrence relationship (Audsley et al., 1993a): 
(11.5) 
The set of values {wf, w/, wf, ... , w?,... } is, clearly, monotonically nondecreasing. When w;1= w;i+ 1, the solution to the equation has been found. If wf < R then w;1is the smallest solution and hence is the value required. If the equation does not have a solution then thew values will continue to rise (this will occur for a low-priority task if the full set has a utilization greater than 100% ). Once they get bigger than the task's period, T, it can be assumed that the task wi11 not meet its deadline. The starting value for the process, w?, must not be greater than the final (unknown) solution Ri. As Ri ~ C a safe starting point is C -there are, however, more efficient starting values (Davis et al., 2008). 
The above analysis gives rise to the following algorithm for calculation response times: 
for i in 1 .. N loop --for each task in turn 
n : = 0 w;' := C; 
loop calculate new w1+1 from Equation (11.5) if w;1+1 w;1then 
R; : = w;2 
exit value found 
end if 
if w;i+1 > T; then 
exit value not found 
end if 
n := n + 1 
end loop 
end loop 
By implication, if a response time is found it will be less than T;, and hence less than 
Di, its deadline (remember with the simple task model Di = T;). 
In the above discussion, wi has been used merely as a mathematical entity for 
solving a fixed-point equation. It is, however, possible to get an intuition for wi from the 
problem domain. Consider the point of release of task i. From that point, until the task 
completes, the processor will be executing tasks with priority Pi or higher. The processor 
is said to be executing a Pi-busy period. Consider wi to be a time window that is moving 
down the busy period. At time O(the notional release time of task i), all higher-priority 
tasks are assumed to have also been released, and hence: 
w}= C + I::cj 
jEhp(i) 
This will be the end of the busy period unless some higher-priority task is released a second time. If it is, then the window will need to be pushed out further. This continues with the window expanding and, as a result, more computation time falling into the window. If this continues indefinitely then the busy period is unbounded (that is, there 
RESPONSE TIME ANALYSIS (RTA) FOR FPS 377 
Task Period, T Computation time, C Priority, P 
a  7  3  3  
b  12  3  2  
C  20  5  

Table 11.8 Task set D. 
is no solution). However, if at any point, an expanding window does not suffer an extra 'hit' from a higher-priority task then the busy period has been completed, and the size of the busy period is the response time of the task. 
To illustrate how the RTA is used, consider task set D given in Table 11.8. The highest-priority task, a, will have a response time equal to its computation time (for example, Ra = 3). The next task will need to have its response time calculated. Let w~ equal the computation time of task b, which is 3. Equation ( 11.5) is used to derive the next value of w: 

that is, wl = 6. This value now balances the equation (wl = w1~ = 6) and the response time of task b has been found (that is, Rb = 6). 
The final task will give rise to the following calculations: 
WO =5 
C 
wf= 5 + m3 + r15213 = 11 
w;= 5 + r \' 13 + r :~ 13 = 14 
17 
w~ =5+ 3+

r ';l r:~13= 
w:= 5 + r1; 13 + r :;13 = 20 
w~ = 5+ 27013+ 3 = 20


r r~~l 

Hence Re-has a worst-case response time of 20, which means that it will just meet its deadline. This behaviour is illustrated in the Gantt chart shown in Figure 11.5. 
Consider again the task set C. This set failed the utilization-based test but was observed to meet all its deadlines up to time 80. Table 11.9 shows the response times calculated by the above method for this collection. Note that all tasks are now predicted to complete before their deadlines. 
The response time calculations have the advantage that they are sufficient and necessary -if the task set passes the test they will meet all their deadlines; if they fail 
378 SCHEDULING REAL-TIME SYSTEMS 

a 
0  2  4  6  8  1 0  12  14  16  18  20  
Time__.  
Figure 11.5  Gantt chart for task set D.  


Task Period, T Computation time, C Priority, P Response time, R 
a  80  40  1  80  
b  40  10  2  15  
C  20  5  3  5  

Table 11.9 Response time for task set C. 

the test, then, at run-time, a task will miss its deadline (unless the computation time estimations, C, themselves turn out to be pessimistic). As these tests are superior to the utilization-based ones, this chapter will concentrate on extending the applicability of the response time method. 
11.6 Sporadic and aperiodic tasks 
To expand the simple model of Section 11.2.4 to include sporadic (and aperiodic) task requirements, the value Tis interpreted as the minimum (or average) inter-arrival interval (Audsley et al., 1993a). A sporadic task with a T value of 20 ms is guaranteed not to arrive more than once in any 20 ms interval. In reality, it may arrive much less frequently than once every 20 ms, but the response time test will ensure that the maximum rate can be sustained (if the test is passed!). 
The other requirement that the inclusion of sporadic tasks demands concerns the definition of the deadline. The simple model assumes that D = T. For sporadic tasks, this is unreasonable. Often a sporadic is used to encapsulate an error-handling routine or to respond to a warning signal. The fault model of the system may state that the error routine will be invoked very infrequently -but when it is, it is urgent and hence it has a short deadline. Our model must therefore distinguish between D and T, and allow D < T. Indeed, for many periodic tasks, it is also useful to allow the application to define deadline values less than period. 
An inspection of the response time algorithm for FPS, described in Section 11.5, reveals that: 
• it works perfectly for values of D less than T as long as the stopping criterion 
1+1
becomes w~I > D··t, 

• it works perfectly well with any priority ordering -hp(i) always gives the set of higher-priority tasks. 
SPORADIC AND APERIODIC TASKS 379 

Although some priority orderings are better than others, the test will provide the worstcase response times for the given priority ordering. 
In Section 11. 7, an optimal priority ordering for D < T is defined (and proved). A later section will consider an extended algorithm and optimal priority ordering for the general case of D < T, D = T or D > T. 
11.6.1 Hard and soft tasks 
For sporadic tasks, average and maximum arrival rates may be defined. Unfortunately, in many situations the worst-case figure is considerably higher than the average. Interrupts often arrive in bursts and an abnormal sensor reading may lead to significant additional computation. It follows that measuring schedulability with worst-case figures may lead to very low processor utilizations being observed in the actual running system. As a guideline for the minimum requirement, the following two rules should always be complied with. 
• 
Rule 1-all tasks should be schedulable using average execution times and average arrival rates. 

• 
Rule 2-all hard real-time tasks should be schedulable using worst-case execution times and worst-case arrival rates of all tasks (including soft). 


A consequence of Rule 1 is that there may be situations in which it is not possible to meet all current deadlines. This condition is known as a transient overload; Rule 2, however, ensures that no hard real-time task will miss its deadline. If Rule 2 gives rise to unacceptably low utilizations for 'normal execution', direct action should be taken to try and reduce the worst-case execution times (or arrival rates). 
11.6.2 Aperiodic tasks and fixed-priority execution-time servers 
One simple way of scheduling aperiodic tasks, within a priority-based scheme, is to run such tasks at a priority below the priorities assigned to hard tasks. In effect, the aperiodic tasks run as background activities, and therefore cannot steal, in a preemptive system, resources from the hard tasks. Although a safe scheme, this does not provide adequate support to soft tasks which will often miss their deadlines if they only run as background activities. To improve the situation for soft tasks, a server (or execution-time server) can be employed. Servers protect the tasking resources needed by hard tasks, but otherwise allow soft tasks to run as soon as possible. 
Since they were first introduced in 1987, a number of server methods have been 

defined. Here only two will be considered: the Deferrable Server (DS) and the Sporadic 
Server (SS) (Lehoczky et al., 1987). 
With the DS, an analysis is undertaken (using, for example, the response time 

approach) that enables a new task to be introduced at the highest priority.3 This task, the 
3Servers at other priorities are possible, but the description is more straightforward if the server is given a higher priority than all the hard tasks. 
380 SCHEDULING REAL-TIME SYSTEMS 
server, thus has a period, Ts and a capacity Cs.These values are chosen so that all the hard tasks in the system remain schedulable even if the server executes periodically with period Ts and execution time Cs. At run-time, whenever an aperiodic task arrives, and there is capacity available, it starts executing immediately and continues until either it finishes or the capacity is exhausted. In the latter case, the aperiodic task is suspended (or transferred to a background priority). With the DS model, the capacity is replenished every Ts time units. 
The operation of the SS differs from DS in its replenishment policy. With SS, if a task arrives at time t and uses c capacity then the server has this c capacity replenished 
T.stime units after t. In general, SS can furnish higher capacity than DS but has increased implementation overheads. Section 12.6 describes how SS is supported by C/Real-Time POSIX; DS and SS can be analysed using response time analysis (Bernat and Burns, 1999). 
As all servers limit the capacity that is available to aperiodic soft tasks, they can also be used to ensure that sporadic tasks do not execute more often than expected. If a sporadic task with inter-arrival interval of i and worst-case execution time of C is implemented not directly as a task, but via a server with 7'.1• = Ti and Cs = Ci, then its impact (interference) on lower-priority tasks is bounded even if the sporadic task arrives too quickly (which would be an error condition). 
All servers (DS, SS and others) can be described as bandwidth preserving in that they attempt to: 
• 
make CPU resources available immediately to aperiodic tasks (if there is a capacity); 

• 
retain the capacity for as long as possible if there are currently no aperiodic tasks (by allowing the hard tasks to execute). 


Another bandwidth preserving scheme, which often performs better than the server techniques, is dual-priority scheduling (Davis and Wellings, 1995). Here, the range of priorities is split into three bands: high, medium and low. All aperiodic tasks run in the middle band. Hard tasks, when they are released, run in the low band, but they are promoted to the top band in time to meet their deadlines. Hence in the first stage of execution they will give way to aperiodic activities (but will execute if there is no such activity). In the second phase they will move to a higher priority and then have precedence over the aperiodic work. In the high band, priorities are assigned according to the deadline monotonic approach (see below). Promotion to this band occurs at time D -R. To implement the dual-priority scheme requires a dynamic priority provision. 
11.7 Task systems with D < T 
In the above discussion on sporadic tasks it was argued that, in general, it must be possible for a task to define a deadline that is less than its inter-arrival interval ( or period). It was also noted earlier that for D = T the rate monotonic priority ordering was optimal for a fixed priority scheme. Leung and Whitehead (1982) showed that 
TASK SYSTEMS WITHD < T 381 

Computation Response Task Period, T Deadline, D time, C Priority, P time, R 
a  20  5  3  4  3  
b  15  7  3  3  6  
C  10  10  4  2  10  
d  20  20  3  20  

Table 11.10 Example task set for DMPO. 

for D < T, a similar formulation could be defined -the deadline monotonic priority ordering (DMPO). Here, the fixed priority of a task is inversely proportional to its relative deadline: (Di < Dj =>P; > P1). Table 11.10 gives the appropriate priority assignments for a simple task set. It also includes the worst-case response time -as calculated by the algorithm in Section 11.5. Note that a rate monotonic priority ordering would successfully schedule these tasks. 
In the following subsection, the optimality of DMPO is proven. Given this result and the direct applicability of response time analysis to this task model, it is clear that FPS can adequately deal with this more general set of scheduling requirements. The same is not true for EDF scheduling, see Section 11.11. Once tasks can have D < T then the simple utilization test (total utilization less than one) cannot be applied. 
Having raised this difficulty with EDF, it must be remembered that EDF is the more effective scheduling scheme. Hence any task set that passes an FPS schedulability test will also always meet its timing requirements if executed under EDF. The necessary and sufficient tests for FPS can thus be seen as sufficient tests for EDF. 
11.7.1 Proof that DMPO is optimal 
Deadline monotonic priority ordering is optimal if any task set, Q, that is schedulable by priority scheme, W, is also schedulable by DMPO. The proof of optimality of DMPO will involve transforming the priorities of Q (as assigned by W) until the ordering is DMPO.Each step of the transformation will preserve schedulability. 
Let i and j be two tasks (with adjacent priorities) in Q such that under W: P; > Pj and D; > Dj. Define scheme W' to be identical to W except that tasks i and j are swapped. Consider the schedulability of Q under W'. 
• 
All tasks with priorities greater than Pi will be unaffected by this change to lowerpriority tasks. 

• 
All tasks with priorities lower than Pj will be unaffected. They will all experience the same interference from i and j. 

• 
Task j, which was schedulable under W, now has a higher priority, suffers less interference, and hence must be schedulable under W'. 


All that is left is the need to show that task i, which has had its priority lowered, is still schedulable. 
382 SCHEDULING REAL-TIME SYSTEMS 
Under W, Rj :'.SDj, Dj < D; and D; :'.ST; and hence task i only interferes once during the execution of j. 
Once the tasks have been switched, the new response time of i becomes equal to the old response time of j. This is true because under both priority orderings Cj + C; amount of computation time has been completed with the same level of interference from higher-priority tasks. Task j was released only once during Rj, and hence interferes only once during the execution of i under W'. It follows that: 
R; = Rj :'.SDj < D; 

It can be concluded that task i is schedulable after the switch. 
Priority scheme W' can now be transformed (to W") by choosing two more tasks 'that are in the wrong order for DMPO' and switching them. Each such switch preserves schedulability. Eventually there will be no more tasks to switch; the ordering will be exactly that required by DMPO and the task set will still be schedulable. Hence, DMPO is optimal. 
Note that for the special case of D = T, the above proof can be used to show that, in this circumstance, rate monotonic ordering is also optimal. 
11.8 Task interactions and blocking 
One of the simplistic assumptions embodied in the system model, described in Section 11.2.4, is the need for tasks to be independent. This is clearly unreasonable, as task interaction will be needed in almost all meaningful applications. In Chapters 5 and 6, it was noted that tasks can interact safely either by some form of protected shared data (using, for example, semaphores, monitors, synchronized methods or protected objects) or directly (using some form of rendezvous). All of these language features lead to the possibility of a task being suspended until some necessary future event has occurred (for example, waiting to gain a lock on a semaphore, or entry to a monitor, or until some other task is in a position to accept a rendezvous request). In general, synchronous communication leads to more pessimistic analysis as it is harder to define the real worst case when there are many dependencies between task executions. The following analysis is therefore more accurate when related to asynchronous communication where tasks exchange data via protected shared resources. The majority of the material in the next two sections is concerned with fixed-priority scheduling. The issue of task interactions and EDF scheduling will be considered in Section 11.11.4. 
If a task is suspended waiting for a lower-priority task to complete some required computation then the priority model is, in some sense, being undermined. In an ideal world, such priority inversion (Lauer and Satterwaite, 1979) (that is, a high-priority task having to wait for a lower-priority task) should not exist. However, it cannot, in general, be totally eliminated. Nevertheless, its adverse effects can be minimized. If a task is waiting for a lower-priority task, it is said to be blocked. In order to test for schedulability, blocking must be bounded and measurable; it should also be small. 
To illustrate an extreme example of priority inversion, consider the executions of 

four periodic tasks: a, b, c and d. Assume they have been assigned priorities according 
to the deadline monotonic scheme, so that the priority of task d is the highest and that of 
task a the lowest. Further, assume that tasks d and a (and tasks d and c) share a critical 
TASK INTERACTIONS AND BLOCKING 383 
Task Priority Execution sequence Release time 
a  1  EQQQQE  0  
b  2  EE  2  
C  3  EVVE  2  
d  4  EEQVE  4  

Table 11.11 Execution sequences. 

section (resource), denoted by the symbol Q (and V), protected by mutual exclusion. Table 11.11 gives the details of the four tasks and their execution sequences; in this table 'E' represents a single tick of execution time and 'Q' (or 'V') represent an execution tick with access to the Q (or V) critical section. Thus task c executes for four ticks; the middle two while it has access to critical section V. 
Figure 11.6 illustrates the execution sequence for the start times given in the table. Task a is released first, executes and locks the critical section, Q. It is then preempted by the release of task c which executes for one tick, locks V and is then preempted by the release of task d. The higher-priority task then executes until it also wishes to lock the critical section, Q; it must then be suspended (as the section is already locked by a). At this point, c will regain the processor and continue. Once it has terminated, b will commence and run for its entitlement. Only when b has completed will a be able to execute again; it will then complete its use of the Q and allow d to continue and complete. With this behaviour, d finishes at time 16, and therefore has a response time of 12; c has a value of 6, b a value of 8, and a a value of 17. 

0  2  4  6  8  10  12  14  16  18  
Executing with Q locked  □ Preempted  
■ Executing with V locked  Executing■  
■ Blocked  
Figure 11.6  Example of priority inversion.  


384 SCHEDULING REAL-TIME SYSTEMS 
An inspection of Figure 11.6 shows that task d suffers considerable priority inversion. Not only is it blocked by task a but also by tasks b and c. Some blocking is inevitable; if the integrity of the critical section (and hence the shared data) is to be maintained then a must run in preference to d (while it has the lock). But the blocking of d by tasks c and b is unproductive and will severely affect the schedulability of the system (as the blocking on task dis excessive). 
Priority inversion is not just a theoretical problem; real systems have been known to fail due to this phenomenon. A much publicized 4 case was that of the NASA Mars Pathfinder. Although the Sojourner rover successfully survived the bouncy landing on Mars and was able to collect meteorological data, the spacecraft initially experienced a series of total system resets resulting in lost data. Tasks on the Pathfinder spacecraft were executed as fixed-priority threads. The high-priority data bus management thread and a low-priority meteorological data gathering thread shared an 'information bus' protected by a mutex. A communications thread ran with medium priority. At run-time, the release pattern of the threads was such that the high-priority thread was waiting for the mutex to be released on the information bus, but the lower-priority thread which was using the bus and hence held the mutex lock could not make progress as it was preempted by the relatively long-running medium-priority thread. This resulted in a watchdog timer being triggered as the urgent high-priority data bus thread was missing its deadline. The watchdog initiated a total system reset. The situation then repeated itself again and again. The solution to this problem, once it was identified (which was not easy), was to turn on priority inheritance that was fo11unately supported by the spacecraft's operating system. 
With priority inheritance, a task's priority is no longer static; if a task pis suspended waiting for task q to undertake some computation then the priority of q becomes equal to the priority of p (if it was lower to start with). In the example given a little earlier, task a will be given the priority of task d and will, therefore, run in preference to task c and task b. This is illustrated in Figure 11.7. Note that as a consequence of this algorithm, task h will now suffer blocking even though it does not use a shared object. Also note that task d now has a second block, but its response time has been reduced to 9. With the Mars Pathfinder example once priority inheritance was turned on, the lower-priority thread inherited the data bus thread's priority and thus ran in preference to the medium-priority thread. 
With this simple inheritance rule, the priority of a task is the maximum of its own 

default priority and the priorities of all the other tasks that are at that time dependent 
upon it. 
In general, inheritance of priority is not restricted to a single step. If task d is 

waiting for task c, but c cannot deal with d because it is waiting for task b then bas well 
as c is given d's priority. 
In the design of a real-time language, priority inheritance is of paramount impor

tance. To have the most effective model, however, implies that the concurrency model 
should have a particular form. With standard semaphores and condition variables, there is 
no direct link between the act of becoming suspended and the identity of the task that will 
reverse this action. Inheritance is therefore not easily implemented. With synchronous 
4See http://research.microsoft.com/~mbj/MarsYathfinder/Mars_Pathfinder.html. 
TASK INTERACTIONS AND BLOCKING 385 

Process 
d 
b 
a 
0 2 4 6 8 10 12 14 16 18 
Figure 11.7 Example of priority inheritance. 

message passing, indirect naming may also make it difficult to identify the task upon which one is waiting. To maximize the effectiveness of inheritance, direct symmetric naming would be the most appropriate. 
Sha et al. ( 1990) show that with a priority inheritance protocol, there is a bound on the number of times a task can be blocked by lower-priority tasks. If a task has m critical sections that can lead to it being blocked then the maximum number of times it can be blocked is m. That is, in the worst case, each critical section will be locked by a lower-priority task (this is what happened in Figure 11.7). If there are only n (n < m) lower-priority tasks then this maximum can be further reduced (ton). 
If Bi is the maximum blocking time that task i can suffer then for this simple priority inheritance model, a formula for calculating B can easily be found. Let K be the number of critical sections (resources) in the system. Equation (11.6) thus provides an upper bound on B: 
K 
Bi = L usage(k, i)C(k) (11.6) 
k=I 

where usage is a 0/1 function: usage(k, i) = 1 if resource k is used by at least one task with a priority less than Pi, and at least one task with a priority greater or equal to Pi. Otherwise it gives the result 0. C(k) is the worst-case execution time of the k critical section. Nested resources are not accommodated by this simple formula; they require the usage function to track resources that use other resources. 
This algorithm is not optimal for this simple inheritance protocol. Firstly, it assumes a single cost for using the resource, it does not try to differentiate between the cost of each task's use of the resource. Secondly, it adds up the blocking from each resource, but this can only happen if each such resource is used by a different lower-priority process. This may not be possible for a particular application. For example, if all k resources are only used by one lower-priority task then there would be just one term to include in the equation for B. Nevertheless, the equation serves to illustrate the factors that need to be taken into account when calculating B. In Section 11.9, better inheritance protocols will be described and an improved formula for B will be given. 
386 SCHEDULING REAL-TIME SYSTEMS 
11.8.1 Response time calculations and blocking 
Given that a value for B has been obtained, the response time algorithm can be modified to take the blocking factor into account:5 


that is, 

(11.7) 

which can again be solved by constructing a recurrence relationship: 

(11.8) 

Note that this formulation may now be pessimistic (that is, not necessarily sufficient and necessary). Whether a task actually suffers its maximum blocking will depend upon task phasings. For example, if all tasks are periodic and all have the same period then no preemption will take place and hence no priority inversion will occur. However, in general, Equation (11.7) represents an effective scheduling test for real-time systems containing cooperating tasks. 
11.9 Priority ceiling protocols 
While the standard inheritance protocol gives an upper bound on the number of blocks a high-priority task can encounter, this bound can still lead to an unacceptably pessimistic worst-case calculation. This is compounded by the possibility of chains of blocks developing (transitive blocking), that is, task c being blocked by task b which is blocked by task a and so on. As shared data is a system resource, from a resource management point of view not only should blocking be minimized, but failure conditions such as deadlock should be eliminated. All of these issues are addressed by the ceiling priority protocols (Sha et al., 1990), two of which will be considered in this chapter: the original ceiling priority protocol and the immediate ceiling priority protocol. The original protocol (OCPP) will be described first, followed by the somewhat more straightforward immediate variant (ICPP). When either of these protocols is used on a single-processor system: 
• 
a high-priority task can be blocked at most once during its execution by lower-priority tasks; 

• 
deadlocks are prevented; 

• 
transitive blocking is prevented; 

• 
mutual exclusive access to resources is ensured (by the protocol itself). 


5Blocking can also be incorporated into the utilization-based tests, but now each task must be considered individually. 
PRIORITY CEILING PROTOCOLS 387 

The ceiling protocols can best be described in terms of resources protected by critical sections. In essence, the protocol ensures that if a resource is locked, by task a say, and could lead to the blocking of a higher-priority task (b), then no other resource that could block bis allowed to be locked by any task other than a. A task can therefore be delayed by not only attempting to lock a previously locked resource but also when the lock could lead to multiple blocking on higher-priority tasks. 
The original protocol takes the following form. 

(
1) Each task has a static default priority assigned (perhaps by the deadline monotonic scheme). 

(2) 
Each resource has a static ceiling value defined; this is the maximum priority of the tasks that use it. 

(3) 
A task has a dynamic priority that is the maximum of its own static priority and any it inherits due to it blocking higher-priority tasks. 

(
4) A task can only lock a resource if its dynamic priority is higher than the ceiling of any currently locked resource ( excluding any that it has already locked itself). 


The locking of a first system resource is allowed. The effect of the protocol is to ensure that a second resource can only be locked if there does not exist a higher-priority task that uses both resources. Consequently, the maximum amount of time a task can be blocked is equal to the execution time of the longest critical section in any of the lower-priority tasks that are accessed by higher-priority tasks; that is, Equation ( 11.6) becomes: 
Bi = mlfixusage(k, i)C(k) (11.9)
k=I 

The benefit of the ceiling protocol is that a high-priority task can only be blocked once (per activation) by any lower-priority task. The penalty of this result is that more tasks will experience this block. 
Not all the features of the algorithm can be illustrated by a single example, but the execution sequence shown in Figure 11.8 does give a good indication of how the algorithm works and provides a comparison with the earlier approaches (that is, this figure illustrates the same task sequence used in Figures 11.6 and 11.7). 
In Figure 11.8, task a again locks the first critical section, as no other resources have been locked. It is again preempted by task c, but now the attempt by c to lock the second section (V) is not successful as its priority (3) is not higher than the current ceiling (which is 4, as Q is locked and is used by task d). At time 3, a is blocking c, and hence runs with its priority at the level 3, thereby blocking b. The higher-priority task, d, preempts a at time 4, but is subsequently blocked when it attempts to access Q. Hence a will now continue ( with priority 4) until it releases its lock on Q and has its priority drop back to 1. Now, d can continue until it completes ( with a response time of 7). 
The priority ceiling protocols ensure that a task is only blocked once during each 

invocation. Figure 11.8, however, appears to show task b (and task c) suffering two 
blocks. What is actually happening is that a single block is being broken in two by the 
preemption of task d. Equation (11.9) determines that all tasks (apart from task a) will 
suffer a maximum single block of 4. Figure 11.8 shows that for this particular execution 
sequence task c and task b actually suffer a block of 3 and task d a block of only 2. 
388 SCHEDULING REAL-TIME SYSTEMS 
Process 
d 
C 
b 
a 
0 2 4 6 8 10 12 14 16 18 
□ Executing with Q locked □ Preempted Executing with Vlocked ■ Executing ■ Blocked 
Figure 11.8 Example of priority inheritance -OCPP. 

11.9.1 Immediate ceiling priority protocol 
The immediate ceiling priority algorithm (ICPP) takes a more straightforward approach and raises the priority of a task as soon as it locks a resource (rather than only when it is actually blocking a higher-priority task). The protocol is thus defined as follows. 
• 
Each task has a static default priority.assigned (perhaps by the deadline monotonic scheme). 

• 
Each resource has a static ceiling value defined; this is the maximum priority of the tasks that use it. 

• 
A task has a dynamic priority that is the maximum of its own static priority and the ceiling values of any resources it has locked. 


As a consequence of this final rule, a task will only suffer a block at the very beginning of its execution. Once the task starts actually executing, all the resources it needs must be free; if they were not, then some task would have an equal or higher priority and the task's execution would be postponed. The same task set used in earlier illustrations can now be executed under ICPP (see Figure 11.9). 
Task a having locked Q at time 1, runs for the next four ticks with priority 4. Hence 
neither task b, task c nor task d can begin. Once a unlocks Q (and has its priority reduced), 
the other tasks execute in priority order. Note that all blocking is before actual execution 
and that d's response time is now only 6. This is somewhat misleading, however, as the 
worst-case blocking time for the two protocols is the same (see Equation (11.9)). 
PRIORITY CEILING PROTOCOLS 389 

Process 
d 
b 
a 
0 2 4 6 8 10 12 14 16 18 
Figure 11.9 Example of priority inheritance -ICPP. 

Although the worst-case behaviour of the two ceiling schemes is identical (from a scheduling view point), there are some points of difference. 
• 
ICCP is easier to implement than the original (OCPP) as blocking relationships need not be monitored. 

• 
ICPP leads to fewer context switches as blocking is prior to first execution. 

• 
ICPP requires more priority movements as this happens with all resource usages; OCPP changes priority only if an actual block has occurred. 


Finally, note that ICPP is called the Priority Protect protocol in C/Real-Time POSIX and Priority Ceiling Emulation in Real-Time Java. 
11.9.2 Ceiling protocols, mutual exclusion and deadlock 
Although the above algorithms for the two ceiling protocols were defined in terms of locks on resources, it must be emphasized that the protocols themselves rather than some other synchronization primitive provided the mutual exclusion access to the resource (at least on a single processor system and assuming the tasks do not suspend whilst holding a lock). Consider ICPP; if a task has access to some resource then it will be running with the ceiling value. No other task that uses that resource can have a higher priority, and hence the executing task will either execute unimpeded while using the resource, or, if it is preempted, the new task will not use this particular resource. Either way, mutual exclusion is ensured. 
The other major property of the ceiling protocols (again for single-processor systems and non-self-suspension) is that they are deadlock-free. In Section 8.7, the issue of deadlock-free resource usage was considered. The ceiling protocols are a form of deadlock prevention. If a task holds one resource while claiming another, then the ceiling of the second resource cannot be lower than the ceiling of the first. Indeed, if two resources are used in different orders (by different tasks) then their ceilings must be identical. As one task is not preempted by another with merely the same priority, it follows that once 
390 SCHEDULING REAL-TIME SYSTEMS 
a task has gained access to a resource then all other resources will be free when needed. There is no possibility of circular waits and deadlock is prevented. 
11.1O An extendible task model for FPS 
It was noted earlier that the model outlined in Section 11.2.4 was too simplistic for practical use. In subsequent sections, three important restrictions were removed. 
• 
Deadlines can be less than period (D < T). 

• 
Sporadic and aperiodic tasks, as well as periodic tasks, can be supported. 

• 
Task interactions are possible, with the resulting blocking being factored into the response time equations. 


Within this section, five further generalizations will be given. The section will conclude with a general-purpose priority assignment algorithm. 
11.10.1 Release jitter 
In the simple model, all tasks are assumed to be periodic and to be released with perfect periodicity; that is, if task l has period Tzthen it is released with exactly that frequency. Sporadic tasks are incorporated into the model by assuming that their minimum interarrival interval is T. This is not, however, always a realistic assumption. Consider a sporadic tasks being released by a periodic task l (on another processor). The period of the first task is Tzand the sporadic task will have the same rate, but it is incorrect to assume that the maximum load (interference) s exerts on low-priority tasks can be represented in Equation ( 11.4) or ( 11.5) as a periodic task with period T.~= Tz. 
To understand why this is insufficient, consider two consecutive executions of task l. Assume that the event that releases task s occurs at the very end of the periodic task's execution. On the first execution of task l, assume that the task does not complete until its latest possible time, that is, R1. However, on the next invocation assume there is no interference on task l so it completes within C1. As this value could be arbitrarily small, let it equal zero. The two executions of the sporadic task are not separated by Tzbut by Tz-R1. Figure 11.10 illustrates this behaviour for Tzequal to 20, R1 equal to 15 and minimum C1 equal to 1 (that is, two releases of the sporadic task within 6 time units). Note that this phenomenon is of interest only if task l is remote. If this was not the case then the variations in the release of task s would be accounted for by the standard equations, where a critical instant can be assumed between the releaser and the released. 
To capture correctly the interference sporadic tasks have upon other tasks, the recurrence relationship must be modified. The maximum variation in a task's release is termed its release jitter (and is represented by J). For example, in the above, tasks would have a jitter value of 15. In terms of its maximum impact on lower-priority tasks, this sporadic task will be released at time 0, 5, 25, 45 and so on. That is, at times 0, T -J, 2T -J, 3T -J, and so on. Examination of the derivation of the schedulability equation implies that task i will suffer one interference from task s if Ri is between Oand T -J, 
AN EXTENDIBLE TASK MODEL FOR FPS 391 
Process 
i q Q 
t+15 t+20 Time ---+
IRelease of periodic task 
I Completion of periodic task and 
• release of the sporadic task 
Figure 11.10 Releases of sporadic tasks. 

that is Ri E [O,T -J), two if Ri E. [T -J, 2T J), three if Ri E [2T -J, 3T -J) and so on. A slight rearrangement of these conditions shows a single hit if Ri + J E [O,T), a double hit if Ri + J E [T, 2T) and so on. This can be represented in the same form as the previous response time equations as follows (Audsley et al., 1993b ): 
" 1R-+J.1 1 (11.10)
Ri = Bi + c + ~ I I r. cj 
jEhp(i) J 

In general, periodic tasks do not suffer release jitter. An implementation may, however, restrict the granularity of the system timer (which releases periodic tasks). In this situation, a periodic task may also suffer release jitter. For example, a T value of 10 but a system granularity of 8 will imply a jitter value of 6 -at time 16 the periodic task will be released for its time '1 O' invocation. If response time (now denoted as Rrriodic) is to be measured relative to the real release time then the jitter value must be added to that previously calculated: 

(11.11) 

If this new value is greater than ~ then the following analysis must be used. 
11.10.2 Arbitrary deadlines 
To cater for situations where Di (and hence potentially Ri) can be greater than ~, the analysis must again be adapted. When deadline is less than ( or equal) to period, it is necessary to consider only a single release of each task. The critical instant, when all higher-priority tasks are released at the same time, represents the maximum interference and hence the response time following a release at the critical instant must be the worst case. However, when deadline is greater than period, a number of releases must be considered. The following assumes that the release of a task will be delayed until any previous releases of the same task have completed. 
392 SCHEDULING REAL-TIME SYSTEMS 
If a task executes into the next period then both releases must be analysed to see which gives rise to the longest response time. Moreover, if the second release is not completed before a third occurs than this new release must also be considered, and so on. 
For each potentially overlapping release, a separate window w (q) is defined, where q is just an integer identifying a particular window (that is, q = 0, l, 2, ... ). Equation ( 11.5) can be extended to have the following form (ignoring release jitter) (Tindell et al., 1994 ): 
w;•+'(q) = B; + (q + l)C; + L rw;'/)l Cj (11.12) 
jEhp(i) J 

For example, with q equal to 2, three releases of the task will occur in the window. For each value of q, a stable value of w(q) can be found by iteration -as in Equation (11.5). The response time is then given as: 

(11.13) 

For example, with q = 2 the task started 2T; into the window and hence the response time is the size of the window minus 2T;. The number of releases that need to be considered is bounded by the lowest value of q for which the following relation is true: 
R;(q):::: T; (11.14) 
At this point, the task completes before the next release and hence subsequent windows do not overlap. The worst-case response time is then the maximum value found for each q: 
R; = max R;(q) (11.15)
q=0,1,2, ... 

Note that for D ::::T, the relation in Equation ( 11.14) is true for q = 0 (if the task can be guaranteed), in which case Equations (11.12) and (11.13) simplify back to the original equation. If any R > D, then the task is not schedulable. 
When this arbitrary deadline formulation is combined with the effect of release jitter, two alterations to the above analysis must be made. First, as before, the interference factor must be increased if any higher-priority tasks suffer release jitter: 

The other change involves the task itself. If it can suffer release jitter then two consecutive windows could overlap if response time plus jitter is greater than period. To accommodate this, Equation ( 11.13) must be altered: 

(11.17) 
AN EXTENDIBLE TASK MODEL FOR FPS 393 

11.10.3 Cooperative scheduling 
The models described above have all required true preemptive dispatching. In this section, an alternative scheme is outlined (the use of deferred preemption). This has a number of advantages, but can still be analysed by the scheduling technique based on response time analysis. In Equation (11.7), for example, there is a blocking term B that accounts for the time a lower-priority task may be executing while a higher-priority task is runnable. In the application domain, this may be caused by the existence of data that is shared (under mutual exclusion) by tasks of different priority. Blocking can, however, also be caused by the run-time system or kernel. Many systems will have the non-preemptable context switch as the longest blocking time (for example, the release of a higher-priority task being delayed by the time it takes to context switch to a lower-priority task -even though an immediate context switch to the higher-priority task will then ensue). 
One of the advantages ofusing the immediate ceiling priority protocol (to calculate and bound B) is that blocking is not cumulative. A task cannot be blocked both by an application task and a kernel routine -only one could actually be happening when the higher-priority task is released. 
Cooperative scheduling exploits this non-cumulative property by increasing the situation in which blocking can occur. Let BMAX be the maximum blocking time in the system (using a conventional approach). The application code is then split into nonpreemptive blocks, the execution times of which are bounded by BMAX· At the end of each of these blocks, the application code offers a 'de-scheduling' request to the kernel. If a high-priority task is now runnable the kernel will instigate a context switch; if not, the currently running task will continue into the next non-preemptive block. 
The normal execution of the application code is thus totally cooperative. A task will continue to execute until it offers to de-schedule. Hence, as long as any critical section is fully contained between de-scheduling calls, mutual exclusion is assured. This method does, therefore, require the careful placement of de-scheduling calls. 
To give some level of protection over corrupted ( or incorrect) software, a kernel could use an asynchronous signal, or abort, to remove the application task if any nonpreemptive block lasts longer than BMAX (see Chapter 13). 
The use of deferred preemption has two important advantages. It increases the schedulability of the system, and it can lead to lower values of C. In the solution of Equation (11.4), as the value of w is being extended, new releases of higher-priority tasks are possible that will further increase the value of w. With deferred preemption, no interference can occur during the last block of execution. Let Fi be the execution time of the final block, such that when the task has consumed Ci -Fi time units, the last block has (just) started. Equation (11.4) is now solved for C; -Fi rather than C: 
(11.18) 

When this converges (that is, w;i+ 1 = w?), the response time is given by: 
(11.19) 

In effect, the last block of the task has executed with a higher priority (the highest) than the rest of the tasks. 
394 SCHEDULING REAL-TIME SYSTEMS 
This straightforward application of response time analysis is, however, misleading and may in certain circumstances lead to errors -that is, the analysis is not sufficient. Consider as a simple example a two task system with each task having deadline equal to period. The first task has a period of 6 and a computation time of 2 which is executed as a single non-preemptive block. The other task has a period of 8 and an execution time of 6 split into two 3 unit blocks. The longer period for this task means that it has the lower priority. The first task has a blocking term of 3 which, with its own computation time of 2, gives a response time of 5. The second task is first analysed to see when its first block will complete. This has a computation time of 3 and suffers 2 units of interference and so w?converges simple to the value 5. To this is added the Fi value of 3 to give an overall response time of 8. This appears to imply that the system is schedulable. But this is impossible -the overall utilization of these two tasks is greater than 1 (1/3 + 3/4) which is indisputable evidence of unschedulability. 
So why does the analysis fail on this example? There is a constraint on using Equations (11.18) and (11.19) that is hidden and this example highlights the problem because it does not satisfy this constraint. For these equations to apply, the worst-case response time for each task with preemption must be less than the task's period. If this is not the case then it is possible for the second ( or third ... ) release of the task to be the worst. If releases overlap in this way then the analysis used in the previous section for deadline greater than period must be used. 
For the example, the preemptive worst-case response time of the second task is 10 (two interferences plus execution time of 6) which is greater than 8 and hence the second release must be analysed. The easiest method for computing this is to look at the worst-case response time of a task made up of two serial executions of the second task. Now this new task has a computation time of 12 made up of four 3 unit blocks. Applying Equations (I 1.18) and (11.19) gives a value of w?of 15; when the final 3 is added in this gives a response time of 18 which breaks the deadline value of 16 (for the second invocation). 
It must be emphasized that for most systems with utilization not greater than 1, releases will not overlap and the straightforward use of these equations will provide the correct result -but the constraint must always be checked. 
The other advantage of deferred preemption comes from predicting more accurately the execution times of a task's non-preemptable basic blocks. Modern processors have caches, prefetch queues and pipelines that all significantly reduce the execution times of code. Typically, simple estimations of worst-case execution time are forced to ignore these advantages and obtain very pessimistic results because preemption will invalidate caches and pipelines. Knowledge of non-preemption can be used to predict the speed up that will occur in practice. However, if the cost of postponing a context switch is high, this will militate against these advantages. 
11.10.4 Fault tolerance 
Fault tolerance via either forward or backward error recovery always results in extra computation. This could be an exception handler or a recovery block. In a real-time fault-tolerant system, deadlines should still be met even when a certain level of faults occur. This level of fault tolerance is known as the fault model. If cf is the extra 
AN EXTENDIBLE TASK MODEL FOR FPS 395 

computation time that results from an error in task i, then the response time equation can easily be changed: 

(11.20) 

where hep(i) is the set of tasks with a priority equal to or higher than i. 
Here, the fault model defines a maximum of one fault and there is an assumption that a task will execute its recovery action at the same priority as its ordinary computation. Equation (11.20) is easily changed to increase the number of allowed faults (F): 
~ rRi 1 (11.21)
Ri = B; + C; + L.t -cj + max FCkf 
Tj kEhep(i)jEhp(i) 

Indeed, a system can be analysed for increasing values of F to see what number of faults (arriving in a burst) can be tolerated. Alternatively, the fault model may indicate a minimum arrival interval for faults. In this case the equation becomes: 
Ri=Bi+C+ L rRilcj+ max. (fR;lct) (11.22)
Tj kEhep(1) Tt 
jEhp(i) 

where T1 is the minimum inter-arrival time between faults. In Equations (11.21) and (11.22), the assumption is made that in the worst case, the fault will always occur in the task that has the longest recovery time. 
11.10.5 Introducing offsets 
In the scheduling analysis presented so far in this chapter, it has been assumed that all tasks share a common release time. This critical instant is when all tasks are released simultaneously (this is usually taken to occur at time 0). For fixed-priority scheduling, this is a safe assumption; if all tasks meet their timing requirements when released together then they will always be schedulable. There are, however, sets of periodic tasks that can benefit from explicitly choosing their release times so that they do not share a critical instant. This may result in improved schedulability. One task is said to have an offset with respect to the others. Consider for illustration the three tasks defined in Table 11.12. 
If a critical instant is assumed then task a has response time of 4 and task b has a response time of 8, but the third task has a worst-case response time of 16, which is 
Task T D C 
a  8  5  4  
b  20  10  4  
C  20  12  4  

Table 11.12 Example of a task set. 

396 SCHEDULING REAL-TIME SYSTEMS 
Task T D C 0 R 
a  8  5  4  0  4  
b  20  10  4  0  8  
C  20  12  4  10  8  

Table 11.13 Response time analysis of the task set. 
Task T D C 0 R 
a 8 5 4 0 4 n 10 10 4 0 8 
Table 11.14 Response time analysis of the transformed task set. 

beyond its deadline. For task c the interference from task b is sufficient to force a further interference from a, and this is crucial. However, if task c is given an offset ( 0) of 10 (that is, retain the same period and relative deadline, but have its first release at time 10) then it will never execute at the same time as b. The result is a schedulable task set-see Table 11.13. 
Unfortunately, task sets with arbitrary offsets are not amenable to analysis. It is a strongly NP-hard problem to choose offsets so that a task set is optimally schedulable. Indeed, it is far from trivial to even check if a set of tasks with offsets share a critical instant.6 
Notwithstanding this theoretical result, there are task sets that can be analysed in a relatively straightforward (although not necessarily optimal) way. In most realistic systems, task periods are not arbitrary but are likely to be related to one another. As in the example just illustrated, two tasks have a common period. In these situations it is easy to give one an offset ( of T /2) and to analyse the resulting system using a transformation technique that removes the offset -and hence critical instant analysis applies. In the example, tasks band c (c having the offset of 10) are replaced by a single notional task with period 10, computation time 4, deadline IO but no offset. This notional task has two important properties. 
• 
If it is schedulable ( when sharing a critical instant with all other tasks), the two real tasks will meet their deadlines when one is given the half period offset. 

• 
If all lower-priority tasks are schedulable when suffering interference from the notional task (and all other high-priority tasks), they will remain schedulable when the notional task is replaced by the two real tasks (one with the offset). 


These properties follow from the observation that the notional task always uses more ( or equal) CPU time than the two real tasks. Table 11.14 shows the analysis that would apply to the transformed task set. The notional task is given the name 'n' in this table. 
6One interesting result is that a task set with co-prime periods will always have a critical instant no matter what offsets are chosen (Audsley and Burns, 1998). 
AN EXTENDIBLE TASK MODEL FOR FPS 397 

More generally the parameters of the notional task are calculated from the real tasks a and bas follows: 
T,1 = T,_/2 (or Tb/2 as T,_1 = Th)
1 
ell 
= Max(Ca, Cb) 
D
11 = Min(Da, Db) Pn = Max(Pa, Ph) 

where P denotes priority. 
Clearly, what is possible for two tasks is also applicable to three or more tasks. A fuller description of these techniques is given in Bate and Burns ( 1997). In summary, although arbitrary offsets are effectively impossible to analyse, the judicious use of offsets and the transformation technique can return the analysis problem to one of a simple task set that shares a critical instant. All the analysis given in earlier sections of this chapter, therefore, applies. 
In Section 10.5 offsets are used to control input and output jitter. Typically the input and output activities involve much less computation time than the 'middle' task that implements whatever algorithms are necessary to convert the input value to an output setting. To analyse this program structure it is acceptable to ignore offsets. As noted earlier a system that is schedulable when offsets are ignored remains schedulable when they are added to the implementation scheme. 
11.10.6 Other characteristics 
In addition to the characteristics discussed in the last few sections (e.g. release jitter, non-preemption, fault tolerance, arbitrary deadlines and offsets) there are many other task attributes that have been analysed in the fixed-priority scheduling literature. For example, tasks with precedence, tasks that must meet Nin M deadlines (e.g. 4 in 5) but not every deadline, and tasks that have a set of C values (not just a single maximum). It is not necessary, however, to cover all these topics (and more) in order to complete this treatment of RTA. The key property of RTA is that it is extendable and configurable. New characteristics can be easily accommodated into the theory. 
11.10.7 Priority assignment 
The formulation given for arbitrary deadlines has the property that no simple algorithm (such as rate or deadline monotonic) gives the optimal priority ordering. In this section, a theorem and algorithm for assigning priorities in arbitrary situations is given. The theorem considers the behaviour of the lowest priority task (Audsley et al., 1993b). 
Theorem If task p is assigned the lowest priority and is feasible, then, if a 
feasible priority ordering exists for the complete task set, an ordering exists 
with task p assigned the lowest priority. 

The proof of this theorem comes from considering the schedulability equations -for example, Equation ( 11.12). If a task has the lowest priority, it suffers interference from all 
398 SCHEDULING REAL-TIME SYSTEMS 
higher-priority tasks. This interference is not dependent upon the actual ordering of these higher priorities. Hence if any task is schedulable at the bottom value it can be assigned that place, and all that is required is to assign the other N -I priorities. Fortunately, the theorem can be reapplied to the reduced task set. Hence through successive reapplication, a complete priority ordering is obtained (if one exists). 
The following code in Ada implements the priority assignment algorithm;7 Set is an array of tasks that is notionally ordered by priority; Set (N) being the highest priority, Set ( 1) being the lowest. The procedure Task_Test tests to see whether task K is feasible at that place in the array. The double loop works by first swapping tasks into the lowest position until a feasible result is found; this task is then fixed at that position. The next priority position is then considered. If at any time the inner loop fails to find a feasible task, the whole procedure is abandoned. Note that a concise algorithm is possible if an extra swap is undertaken. 
procedure Assign_Pri (Set : in out Task_Set; N: Natural; Ok: out Boolean) is begin for Kin 1 .. N loop 
for Next in K .. N loop 
Swap(Set, K, Next); 
Task_Test(Set, K, Ok); 
exit when Ok; 

end loop; 
exit when not Ok; --failed to find a schedulable task end loop; end Assign_Pri; 
If the test of feasibility is exact (necessary and sufficient) then the priority ordering is optimal. Thus for arbitrary deadlines (without blocking), an optimal ordering is found. Where there is blocking, the priority ceiling protocols ensure that blackings are relatively small and, therefore, the above algorithm produces adequate near optimal results. 
11.10.8 Insufficient priorities 
In all of the analysis presented in this chapter it has been assumed that each task has a distinct priority. Unfortunately it is not always possible to accommodate this 'one priority per task' ideal. If there are insufficient priorities then two or more tasks must share the same priority. Fortunately, to check the schedulability of shared-priority tasks requires only a minor modification to the response time test. Consider the basis Equation ( 11.4) derived earlier in this chapter, which has a summation over all the higher-priority tasks. If tasks share priorities then this summation must be over all higher-or equal-priority tasks: 

(11.23) 

where hep(i) is the set of higher-or equal-priority tasks (than i). 
7This algor~thm has become known as Audsley's algorithm. AN EXTENDIBLE TASK MODEL FOR FPS 399 
So, if tasks a and b share priority i then a assumes it is getting interference from b and b assumes it is getting interference from a. Clearly if a and bare schedulable when they share priority i then they will remain schedulable if they are assigned distinct but adjacent priorities. The-converse is, however, not true. 
One way to reduce the number of priority levels required for a specific system is to first make sure the system is schedulable with distinct priorities. Then, starting from the lowest priority, tasks are grouped together until the addition of an extra task breaks schedulability. A new group is then started with this task, and the process continues until all tasks are in groups (although some groups may contain only have a single task). A minor variant of the priority assignment algorithm given above can easily implement this scheme. 
Reducing the number of priority levels inevitably reduces schedulability. Tests have shown (Klein et al., 1993) that 92% of systems that are schedulable with distinct priorities will remain schedulable if only 32 levels are available. For 128 priority values this rises to 99%. In will be noted in the next chapter that Ada requires a minimum of 31 distinct priorities, Real-Time POSIX a minimum of 32 and Real-Time Java a minimum of 28. 
11.10.9 Execution-time servers 
Finally, in the description of fixed-priority scheduling the topic of execution-time servers is revisited. As applications and hardware platforms become more complicated it is useful to employ a virtual resource layer between the set of applications and the processor ( or processors) they execute on. An execution-time server both guarantees a certain level of service and ensures that no more resource is allocated than is implied by the 'service contract'. So, for example, two multithreaded applications may co-exist on the one processor. One application receives 4 ms every 10 ms, the other 6 ms. These levels are guaranteed and policed. The first application will definitely get 4 ms, but it will not be allocated more than 4 ms in a 10 ms interval even if it has a runnable high-priority task. 
There have been a number of execution-time servers proposed for FPS (see Section 11.6.2). Here three common ones are described: the Periodic Server, the Deferrable Server and the Sporadic Server. The simple Periodic Server has a budget (capacity) and a replenishment period. Following replenishment, client tasks can execute until either the budget is exhausted or there are no longer any runnable client tasks. The server is then suspended until the next replenishment time. The Deferrable Server is similar except that the budget remains available even after clients have been satisfied a client arriving late will be serviced if there is budget available. Both Periodic and Deferrable Servers are replenished periodically and the budget still available at replenishment is lost. The Sporadic Server behaves a little differently. The budget remains indefinitely. When a client arrives (at time t, say) it can use up the available budget which is then replenished at time t + the replenishment period of the server. 
A complete system can contain a number of servers of these three types. The 

Periodic Server is ideally suited for supporting periodic tasks, the Sporadic Server is 
exactly what is required for sporadic tasks and the Deferrable Server is a good match 
for handling aperiodic work. In the latter case, aperiodic tasks can be handled quickly if 
400 SCHEDULING REAL-TIME SYSTEMS 
there is budget available -but once this is exhausted then the aperiodic tasks will not be serviced and hence an unbounded load on the server will have no detrimental effects on other parts of the system. 
Scheduling these three server types on a fixed-priority system is relatively straightforward. Each server, of whichever type, is allocated a distinct priority. Response time analysis is then used to verify that all servers can guarantee their budget and replenishment period. Fortunately Periodic and Sporadic Servers behave exactly the same as periodic tasks and hence the straightforward analysis for these servers is directly applicable. For Deferrable Servers, the worst-case impact such a server can have on lower-priority tasks occurs when its budget is used at the very end of one period and then again at the start of the next. Conveniently this behaviour is identical to a periodic task suffering release jitter and hence can be analysed using the formulation given in Section 11.10.1. 
It follows from this brief discussion that the schedulability test for a task running on a server involves two steps; first to verify that the server's parameters are valid and second that the response time of the task on that server is bounded by the task's deadline. The worst-case response time for a task executing on a server can be computed in a number of ways. For example, a server that guarantees 2 ms every 10 ms is equivalent to a processor running at 1/5 of its original speed. If all task computation times are multiplied by 5 then standard RTA can be applied (using these new C values).8 A similar approach is taken with variable speed processors -an example of this analysis is given in Section I 1.15. 
11.11 Earliest deadline first (EDF) scheduling 
FPS is undoubtedly the most popular scheduling approach available to the implementors of real-time systems. The next chapter will show how it is supported in a number of languages and operating systems. However, as discussed at the beginning of this chapter, it is not the only approach studied in the real-time scheduling community. This section focuses on an alternative approach, EDF, that has a number of properties that make it almost as important as FPS. Unfortunately, it is currently less supported by languages and operating systems (again see the next chapter). For this reason EDF analysis is not covered here to the same level of detail afforded to FPS analysis. 
11.11.1 Utilization-based schedulability tests for EDF 
Not only did the seminal paper of Liu and Layland introduce a utilization-based test for FPS but it also gave one for EDF. The following equation is for the simple task model introduced in Section 11.2.4 -in particular, D = T for all tasks: 
1 (11.24)

t (C)~ 
i=l Ti 

8With this example, the computed response times may need to have the value 8 added to take into account the 'dead time' before the sever can respond to requests from its client tasks. 
EARLIEST DEADLINE FIRST (EDF) SCHEDULING 401 

Clearly this is a much simpler test than the corresponding test for FPS (Equation (11.1)). As long as the utilization of the task set is less than the total capacity of the processor then all deadlines will be met (for the simple task model). In this sense EDF is superior to FPS; it can always schedule any task set that FPS can, but not all task sets that are passed by the EDF test can be scheduled using fixed priorities. Given this advantage it is reasonable to ask why EDF is not the preferred task-based scheduling method? The reason is that FPS has a number of advantages over EDF. 
• 
FPS is easier to implement, as the scheduling attribute (priority) is static; EDF is dynamic and hence requires a more complex run-time system which will have higher overhead. 

• 
It is easier to incorporate tasks without deadlines into FPS (by merely assigning them a priority); giving a task an arbitrary deadline is more artificial. 

• 
The deadline attribute is not the only parameter of importance; again it is easier to incorporate other factors into the notion of priority than it is into the notion of deadline, for example, the criticality of the task. 

• 
During overload situations ( which may be a fault condition) the behaviour of FPS is more predictable (the lower-priority tasks are those that will miss their deadlines first); EDF is unpredictable under overload and can experience a domino effect in which a large number of tasks miss deadlines. This is considered again in Section 11.12. 

• 
The utilization-based test, for the simple model, is misleading as it is necessary and sufficient for EDF but only sufficient for FPS. Hence higher utilizations can, in general, be achieved for FPS. 


Notwithstanding this final point, EDF does have an advantage over FPS because of its higher utilization. Indeed it is easy to show that if a task set, with restrictions such as deadline equal to period removed, is schedulable by any scheme then it will also be schedulable by EDF. The proof of this property follows the pattern used for proving that DMPO is optimal (see Section 11.7.1 ). Starting with the feasible schedule it is always possible to transform the schedule to one that becomes identical with the one EDF would produce -and at each transformation schedulability is preserved. 
11.11.2 Processor demand criteria for EDF 
One of the disadvantages of the EDF scheme is that the worst-case response time for each task does not occur when all tasks are released at a critical instant. In this situation only tasks with a shorter relative deadline will interfere. However, later there may exist a position in which all (or at least more) tasks have a shorter absolute deadline. In situations where the simple utilization-based test cannot be applied (for example when there is release jitter or when deadlines are shorter then periods) then a more sophisticated scheduling test must be used. In FPS this takes the form ofRTA (calculate the worst-case response time for each task and then check that this is less than the related deadline). For EDF this approach can again be used, but it is much more complicated to calculate these response time values and hence it will not be described here. There is, however, 
402 SCHEDULING REAL-TIME SYSTEMS 
t1 t2 
T 
D I 
~ I ~ -I 
0 3 5 8 10 12 14 
Figure 11.11 PDC example. 

an alternative scheme that checks for schedulability directly rather than via response times. This method, called PDC (Processor Demand Criteria) (Baruah et al., 1990a, b ), is defined as follows. 
Assuming a system starts at time O and all tasks arrive at their maximum frequency, at any future time, t, it is possible to calculate the load on the system, h (t). This is the amount of work that must be completed before t, in other words, all jobs that had absolute deadlines before (or at) t. It is easy to give a formula for h(t): 
h(t)--LN lt---+ It r,. -Dij ~ (11.25) 
i=] l 

To illustrate this formula, consider a single task with T = 5, D = 3 and C = 1, and two possible values oft: t 1 = 12 and t2 = 14. Figure 11.11 illustrates these parameters. The third deadline of the task is at 13 and hence is after t 1 so h (t 1) for this task should be 2. But at t2 = 14 another execution of the task must be completed and so h(t2) = 3. To compute these values easily, T -D is added to t; if this results in a value after the next period then the floor function in Equation (11.25) will correctly add an extra C to the total. So, in the example, T -D = 2, tl + 2 = 14 and hence Ll4/5J = 2. But t2 + 2 = 16 and so L16/5J = 3. 
The requirement for schedulability is that the load must never exceed the time 

available to satisfy that level of load: 
Vt > 0 h(t) :S t (11.26) 

PDC involves applying this equation to a limited number oft values. The number of points is limited by two factors: 
• only values oft that correspond to deadlines of tasks need be checked; 
• there is an upper bound (L) on the values oft that must be checked -this means that an unschedulable system will have h(t) > t for some value oft < L. 
The first reduction comes from the fact that h (t) is constant between deadlines and hence the worst case occurs at a deadline. To calculate the upper bound (L) on the interval that must be checked, two formulae have been developed. The first one comes from the need to check at least the first deadline of each task, and a bound based on utilization (the derivation of all the equations given in the section can be found in the 
EARLIEST DEADLINE FIRST (EDF) SCHEDULING 403 literature referenced in the Further Reading section at the end of this chapter): 


The second bound is derived from the busy period of the system (that is, the time from start-up at time 0 to the first null or background tick where no task is executing -at this time, by definition, the load has been satisfied). This is easily obtained from a recurrence relation similar to that used in FPS: 
N 
wo=Lc 
t i=l r~lwi+l = Ci 
i=I I 

When wi+ 1 = wj then this is the end of the busy period and Lb = wj. Note this busy period is bounded if the utilization of the task set is not greater then 1 (so this is always checked first). 
To obtain the least upper bound, the simple minimum of these two values is used: 

(11.27) 

For example, consider a three task system as depicted in Table 11.15. The utilization of this task set is 0.92. The computed values of La and Lb are 30.37 and 15 respectively; hence the least upper bound is 15. In the time period from 0 to 15 there are five deadlines to check -task a at times 4, 8 and 12, task b at time 10 and task c at time 14. At all of these points Equation ( 11.26) is satisfied and the system is determined to be schedulable. For example h(l5) is 14 and h(12) is 6. 
If the example is now modified to increase the computation time of b to 4 then the utilization is still acceptable (0.987), but it is not schedulable. At time 14, h(t) has the value 15, so h(14) > 14. 
11.11.3 The QPA test 
For non-trivial systems, L can be large and the number of deadlines between 0 and L that need to be checked becomes excessive. Fortunately an efficient scheme has recently been developed that can significantly reduce the number of time points that need to be tested. This scheme, known as QPA (Quick Processor-demand Analysis), exploits the 
Task T D C 
a  4  4  1  
b  15  10  3  
C  17  14  8  

Table 11.15 A task set for EDF. 

404  SCHEDULING REAL-TIME SYSTEMS  
Task  T  D  C  
a b C d e f  4 8 10 12 15 21  4 6 10 8 12 20  1 2 2 3  
Table 11.16 A task set for EDF. 


following property (Zhang and Burns, 2008): rather than progress from Oto L checking each deadline, QPA starts at L and moves backwards towards Ochecking only a necessary subset of the deadlines. 
Let h (L) = s. If s > L then the system is unschedulable. If this is not the case 
(s :S L) then h(t) < t for all values oft: s < t < L. Hence there is no need to check the deadlines within the interval s .. L. To verify this property assume (in order to construct a counterexample) a value t within the range has h (t) > t. Now t > s so h (t) > s. Also h(t) < h(L) as t < L (the function his monotonic int). We must conclude thats > L which contradicts the assumption that s < L. 
Having jumped from L back to h(L), the procedure is repeated from h(L) to h(h(L)), etc. At each step the essential test of h(t) < t is undertaken. Of course if h(t) = t then no progress can be made and it is necessary to force progress by moving from t to the largest absolute deadline (d) in the system such as d < t. 
The QPA test looks at only a small fraction of the number of points that would need to be analysed if all deadlines were checked. An example of the approach is as follows. Six tasks have the characteristics given in Table 11.16. The utilization of this task set is 0.965. The value of Lis 59 and there are 34 deadlines that need to be checked in this interval using PDC. 
Applying QPA results in just 14 points that need to be considered, and these correspond to the following values oft: 59, 53, 46, 43, 40, 33, 29, 24, 21, 19, 12, 9, 5 and 1. In other examples (Zhang and Burns, 2008), QPA typically requires only 1 % of the effort of the original processor demand analysis scheme. 
11.11.4 Blocking and EDF 
When considering shared resources and blocking, there is a direct analogy between EDF and FPS. Where FPS suffers priority inversion, EDF suffers deadline inversion. This is when a task requires a resource that is currently locked by another task with a longer deadline. Not surprisingly inheritance and ceiling protocols have been developed for EDF but, as with earlier comparisons, the EDF schemes are somewhat more complex (Baruah, 2006). 
As priorities are static, it is easy to determine which tasks can block the task currently being analysed. With EDF, this relationship is dynamic; it depends on which tasks (with longer deadlines) are active when the task is released. And this varies from one release to another throughout the hyper-period. 
DYNAMIC SYSTEMS AND ONLINE ANALYSIS 405 

Probably the best scheme for EDF is the Stack Resource Policy (SRP) of Baker ( 1991 ). This works in a very similar way to the immediate ceiling priority protocol for FPS (indeed SRP influenced the development of ICPP). Each task, under SRP, is assigned a preemption level. Preemption levels reflect the relative deadlines of the tasks, the shorter the deadline the higher the preemption level; so they actually designate the static priority of the task as assigned by the deadline monotonic scheme. At run-time, resources are given ceiling values based on the maximum preemption level of the tasks that use the resource. 
When a task is released, it can only preempt the currently executing task if 
its absolute deadline is shorter and its preemption level is higher than the 
highest ceiling of the currently locked resources. 

The result of applying this protocol is identical to applying ICPP ( on a single processor). Tasks suffer only a single block (it is as they are released), deadlocks are prevented and a simple formula is available for calculating the blocking time. The blocking term, once calculated, can be incorporated into PDC and QPA. 
11.11.5 Aperiodic tasks and EDF execution-time servers 
Following the development of server technology for fixed-priority systems, most of the common approaches have been reinterpreted within the context of dynamic EDF systems. For example there is a Dynamic Sporadic Server and a Dynamic Deferrable Server. Whereas the static system needs a priority to be assigned (which is done prerun-time ), the dynamic version needs to compute a deadline each time it needs to execute. 
In addition to these common forms of servers there are also a number that are EDF-specific. These take the form of virtual (but slow) processors that can guarantee C in T. So an aperiodic task that requires to execute for 3C will be guaranteed to complete in 3T if the server has no other work to do. To find more about EDF servers and EDF scheduling in general, the reader is referred to the books by Liu and Buttazzo in the Further Reading section at the end of this chapter. 
11.12 Dynamic systems and online analysis 
Earlier in this chapter it was noted that there is a wide variety of scheduling schemes that have been developed for different application requirements. For hard real-time systems, offline analysis is desirable (indeed it is often mandatory). To undertake such analysis requires: 
• 
arrival patterns of incoming work to be known and bounded (this leads to a fixed set of tasks with known periods or worst-case arrival intervals); 

• 
bounded computation times; 

• 
a scheduling scheme that leads to predictable execution of the application tasks. 


406 SCHEDULING REAL-TIME SYSTEMS 
This chapter has shown how fixed-priority scheduling (and to a certain extent, EDF) can provide a predictable execution environment. 
In contrast to hard systems, there are dynamic soft real-time applications in which arrival patterns and computation times are not known a priori. Although some level of offline analysis may still be applicable, this can no longer be complete and hence some form of online analysis is required. 
The main objective of an online scheduling scheme is to manage any overload that is likely to occur due to the dynamics of the system's enviromnent. It was noted earlier that EDF is a dynamic scheme that is an optimal scheduling discipline. Unfortunately, EDF also has the property that during transient overloads it performs very badly. It is possible to get a cascade effect in which each task misses its deadline but uses sufficient resources to result in the next task also missing its deadline. 
To counter this detrimental domino effect, many online schemes have two mechanisms: 
(I) 
an admissions control procedure that limits the number of tasks that are allowed to compete for the processors; 

(2) 
an EDF dispatching routine for those tasks that are admitted. 


An ideal admissions control algorithm prevents the processor getting overloaded so that the EDF routine works effectively. 
If some tasks are to be admitted, while others are rejected, the relative importance of each task must be known. This is usually achieved by assigning each task a value. Values can be classified as follows. 
• 
Static -the task always has the same value whenever it is released. 

• 
Dynamic -the task's value can only be computed at the time the task is released (because it is dependent on either environmental factors or the current state of the system). 

• 
Adaptive -here the dynamic nature of the system is such that the value of the task will change during its execution. 


To assign static values (orto construct the algorithm and define the input parameters 

for the dynamic or adaptive schemes) requires the domain specialists to articulate their 
understanding of the desirable behaviour of the system. As with other areas of computing, 
knowledge elicitation is not without its problems, but these issues will not be considered 
here (see Bums et al., 2000). 
One of the fundamental problems with online analysis is the trade-off that has 

to be made between the quality of the scheduling decision and the resources and time 
needed to make the decision. At one extreme, every time a new task arrives, the complete 
set of tasks could be subject to an exact test such as those described in this chapter. If 
the task set is not schedulable, the lowest value task is dropped and the test repeated 
(until a schedulable set is obtained). This approach (which is known as best-effort) is 
optimal for static or dynamic value assignment -but only if the overheads of the tests 
are ignored. Once the overheads are factored in, the effectiveness of the approach is 
seriously compromised. In general, heuristics have to be used for online scheduling and 
WORST-CASE EXECUTION TIME 407 

it is unlikely that any single approach will work for all applications. This is still an active research area. It is clear, however, that what is required is not a single policy defined in a language or OS standard, but mechanisms from which applications can program their own schemes to meet their particular requirements. 
The final topic to consider in this section is hybrid systems that contain both hard and dynamic components. It is likely that these will become the norm in many application areas. Even in essentially static systems, value-added computations, in the form of soft or firm tasks that improve the quality of the hard tasks, are an attractive way of structuring systems. In these circumstances, as was noted in Section 11.6.1, the hard tasks must be protected from any overload induced by the behaviour of the non-hard tasks. One way of achieving this is to use FPS for the hard tasks and execution-time servers for the remaining work. The servers can be executed at a given priority level, but can embody whatever admissions policy is desirable and service the incoming dynamic work using EDF. 
11.13 Worst-case execution time 
In all the scheduling approaches described so far (that is, cyclic executives, FPS and EDF), it is assumed that the worst-case execution time of each task is known. This is the maximum any task invocation/release (i.e. job) could require. 
Worst-case execution time estimation (represented by the symbol C but also known by the acronym WCET) can be obtained by either measurement or analysis. The problem with measurement is that it is difficult to be sure when the worst case has been observed. The drawback of analysis is that an effective model of the processor (including caches, pipelines, branch prediction, out-of-order execution, memory wait states and so on) must be available. 
Most analysis techniques involve two distinct activities. The first takes the task and decomposes its code into a directed graph of basic blocks. These basic blocks represent straightline code. The second component of the analysis takes the machine code corresponding to a basic block and uses the processor model to estimate its worstcase execution time. 
Once the times for all the basic blocks are known, the directed graph can be collapsed. For example, a simple choice construct between two basic blocks will be collapsed to a single value (that is, the largest of the two values for the alternative blocks). Loops are collapsed using knowledge about maximum bounds. 
More sophisticated graph reduction techniques can be used if sufficient semantic information is available. To give just a simple example of this, consider the following code: 
for  I  in  1 ..  10  loop  
if  Cond  then  
basic  block  of  cost  100  
else  
basic  block  of  cost  10  
end  if;  
end  loop;  

408 SCHEDULING REAL-TIME SYSTEMS 
With no further information, the total 'cost' of this construct would be 10 x 100 + the cost of the loop construct itself, giving a total of, say, 1005 time units. It may, however, be possible to deduce (via static analysis of the code) that the condition Cond can only be true on at most three occasions. Hence a less pessimistic cost value would be 375 time units. 
Other relationships within the code may reduce the number of feasible paths by eliminating those that cannot possibly occur; for instance, when the 'if' branch in one conditional statement precludes a later 'else' branch. Techniques that undertake this sort of semantic analysis usually require annotations to be added to the code. The graph reduction process can then make use of tools such as ILP (Integer Linear Programming) to produce a tight estimate of worst-case execution time. They can also advise on the input data needed to drive the program down the path that gives rise to this estimation. 
Clearly, if a task is to be analysed for its worst-case execution time, the code itself needs to be restricted. For example, all loops and recursion must be bounded, otherwise it would be impossible to predict offline when the code terminates. Furthermore, the code generated by the compiler must also be analysable. 
The biggest challenge facing worst-case execution time analysis comes from the use of modem processors with multicores, on-chip caches, pipelines, branch predictors and so on. All of these features aim to reduce average execution time, but their impact on worst-case behaviour can be hard to predict. If one ignores these features the resulting estimates can be very pessimistic, but to include them is not always straightforward. One approach is to assume non-preemptive execution, and hence all the benefits from caching and so on can be taken into account. At a later phase of the analysis, the number of actual preemptions is calculated and a penalty applied for the resulting cache misses and pipeline refills. 
To model in detail the temporal behaviour of a modern processor is non-trivial and may need proprietary information that can be hard to obtain. For real-time systems one is left with the choice of either using simpler (but less powerful) processor architectures or putting more effort into measurement. Given that all high-integrity real-time systems will be subject to considerable testing, an approach that combines testing and measurement for code units (basic blocks) but path analysis for complete components seems appropriate with today's technology. 
This brief discussion has only addressed a few of the issues involved with WCET estimation. A comprehensive coverage would perhaps triple the size of this chapter. Interested readers are referred to the Further Reading section of this chapter. 
11.14 Multiprocessor scheduling 
All the analysis presented so far in this chapter has been concerned with the scheduling of concurrent tasks on to a single computer. As processors have become more powerful, the size and complexity of the applications that can fit on to a single processor have increased substantially. However, for a significant class of system, there is the need to move to a multiprocessor execution platform. This can take the form of a relatively simple dual processor or may involve a large multicore chip. The processors may all be of an identical type (homogeneous) or may have quite different characteristics (heterogeneous). Also the links between the processors may be a shared memory bus or an 
MULTIPROCESSOR SCHEDULING 409 
Task T D C 
a  10  10  5  
b  10  10  5  
C  12  12  8  

Table 11.17 Example task set. 

independent network. Whatever the architecture, the scheduling problem for a multiprocessor system is significantly more complicated than the single processor case. Here three issues are addressed, the placement of tasks to processors, the scheduling of any shared network and the implementation of locks in shared-memory multiprocessor architectures. 
11.14.1 Global or partitioned placement 
The first new issue that must be addressed with a multiprocessor platform is placement. This is the mapping of tasks to processors. Two schemes are possible: global and partitioned. As the names imply, a partitioned scheme is a pre-run-time allocation; the dynamic global alternative allocates tasks as they become runnable, and even during execution a task may move from one processor to another. Both placement schemes have their advantages and disadvantages. The partitioned approach has the benefit of not requiring any run-time support and of being able to cater for certain types of systems that the global scheme has difficulty with. Consider a simple three task system that is to be implemented on two identical processors (see Table 11.17). 
The total utilization of the system is 1.66 so it is capable of being scheduled (as 

1.66 < 2). A simple global placement scheme using either fixed priority or EDF would allocate a and b to the two processors. They would then execute until time 5. Now c can be placed on either processor as they are both free, but there are only 7 units of time left before the deadline at time 12. Hence c will fail to meet its deadline. 
The partitioned approach would allocate a and b to one processor ( where they will completely utilize its capacity), leaving the other processor to c which can then easily meet its deadline. A different example, however, will show the benefits of the global scheme. Table 11.18 also has a three task/ two processor configuration. No partitioned scheme can schedule this system. However, a global scheme that starts with d and f for one tick and then executes d and e for the next eight ticks will be able to run f and e for the 10th tick and satisfy all requirements. 
Task T D C 
d  10  10  9  
e  10  10  9  
f  10  10  2  

Table 11.18 A further example task set. 

410 SCHEDULING REAL-TIME SYSTEMS 
The only way to fit this example into a partitioned scheme is to split / into two identical length parts. This artificial decomposition of a software model was criticized earlier within the context of cyclic executives and cannot be recommended. 
The main challenge for the partitioned approach is to generate a valid allocation. Once an allocation has been formed, it is straightforward to analyse each processor in turn using the analysis already available for single processors. Each processor can be scheduled via fixed priorities or EDF -it would even be possible to mix the schemes with EDF on some processors and FPS on others. An allocation must not 'overfill' any processor and hence task mapping is similar to the classic bin-packing problem. Optimal schemes for large numbers of tasks and processors are therefore not possible -heuristics must be employed. 
The challenge for the global scheme is to identify the optimal scheduling policy. For a single processor, EDF is optimal, but no optical scheme is known for general task models executing on multiprocessor platforms. The earlier example in Table 11.17 shows that EDF scheduling would lead to c missing its deadline, but the system is schedulable as evident from the partitioned approach. Not only are there no optimal schemes available, but what policies are available tend not to be sustainable -a schedulable system may become unschedulable if, for example, an extra processor is added. For these reasons, most current systems use a partitioned approach, which also has the advantage, as noted earlier, of run-time efficiency. Nevertheless, for the future, global schemes have the potential to deliver better schedulability. 
Notwithstanding the lack of maturity in this area, it is possible to report some useful results. It was noted at the beginning of this chapter that single processor analysis started from a simple task model (in particular, tasks are independent and periodic, and have deadline equal to period). For uniprocessors, the model has been generalized significantly, but for multiprocessor scheduling, useful results are only really known for the simple task model. Here a number of such results are stated. 
(
1) There is a global scheduling algorithm called pfair that is able to schedule any periodic system with utilization ::: M on M identical processors (Baruah et al., 1996). However, schedules generated by the pfair algorithm tend to have a large number of preemptions, and tasks are frequently required to move from one processor to another. 

(2) 
For FP scheduling with partitioned placement, the following utilization-based sufficient schedulability test has been derived for a first-fit (using decreasing task utilization) placement strategy (Oh and Baker, 1998): 


U:::: M(✓2-1) (11.28) 

(3) A sufficient utilization-based schedulability test is also known for EDF with partitioned first-fit placement. Let Umax denote the largest utilization of any task in 
the system: Umax = max~ 1 ( "t).Letting f3denote LI/ UmaxJ, this test is as follows (Lopez et al., 2004 ): 
U < _f3_M_+_I 
(11.29)
-/3+ 1 
MULTIPROCESSOR SCHEDULING 411 

(4) A sufficient schedulability test is known for global EDF (Goossens et al., 2003), that depends only upon the utilization of the task system and Umax• 
U :'.S M -(M -1) Umax (11.30) 

(5) 
A variant of EDF with global placement, called fpEDF, has been proposed (Baruah, 2004) that 

(a) 
assigns greatest (fixed) priority to tasks with utilization> ½(if there are any such tasks), and 

(b) 
schedules the remaining tasks according to EDF. 



A couple of schedulability tests have been derived for fpEDF. One uses the utilization of the task system: 

(11.31) 
Another, superior, test for fpEDF uses both the utilization of the system and the largest utilization of any task in the system: 

(11.32) 

A direct comparison between all these bounds would be misleading as the bounds are only sufficient. Tighter bounds are possible; indeed a number have been proposed in the literature for some of the above schemes. However, to illustrate the results that these test do provide, a couple of scenarios are defined and the tests applied. Case I has 10 processors (M = 10) with the highest utilization task having a capacity of 0.1. Case II has M = 4 and Umax = 2/3. Table 11.19 gives the maximum utilization that is guaranteed to lead to a schedulable system for each of the scheduling schemes. To compute the average 'per-processor' utilization these values need to be divided by M (which is 10 in the first scenario and 4 in the other). 
11.14.2 Scheduling the network 
The next issue to consider is the communications infrastructure that links the different processors. For bus-based tightly coupled multiprocessors, the behaviour of multilevel 
Scheme Case I Case II 
Partitioned FP (Eqn 11.28)  4.14  1.66  
Partitioned EDF (Eqn 11.29)  9.18  2.50  
Global EDF (Eqn 11.30)  9.10  2.00  
fpEDF (Eqn 11.32)  9.10  2.67  

Table 11.19 Utilization bounds. 

412 SCHEDULING REAL-TIME SYSTEMS 
caches makes worst-case execution time analysis even harder for these platforms. Heterogeneous processors and hierarchical multispeed memories also add significantly to these difficulties. With network-based connections, the messages must themselves be scheduled if end-to-end data flows through the system are to be guaranteed. There are many different network protocols with some being more amenable to timing analysis than others. It is beyond the scope of this book to discuss these different protocols in detail, but two specific schemes are worth noting. 
• 
Time Division Multiple Access (TOMA) -here each processor is allocated a fixed time slot within a specified cycle in which tasks hosted on that processor can generate messages. 

• 
Control Area Network (CAN) -here each message is given a fixed priority and the network supports priority-based arbitration. 


So with TDMA, which is only really applicable to static task allocation, no two processors ever wish to produce messages at the same time. With CAN, competition can occur but priorities are used to order the messages. Being priority-based, the standard RTA presented earlier in this chapter is directly applicable to scheduling CAN. As a message cannot be preempted once it has started to be transmitted, the non-preemptive form of the analysis is the one employed with CAN (see Section 11.10.3), where the parameter C is now the time needed to transmit the message. 
The use of a network within a system opens up a number of issues as well as message scheduling. Unless the hardware architecture is fully connected, routing needs to be addressed. Static and dynamic route-finding are possible. Fault tolerance over message corruption is normally dealt with by the transmission protocol, but extra messages and perhaps alternative routes may be employed and these must be accommodated into the scheduling analysis. 
11.14.3 Mutual exclusion on multiprocessor platforms 
The final issue to address in this short review of the major problems involved in scheduling 
multiprocessor platforms is the provision of mutual exclusion over shared objects. In 
networked systems, these objects are typically controlled by a single thread so there are 
no new problems to solve, but for shared memory systems there is now the need to provide 
protection from true parallel access. The priority inheritance and priority ceiling protocols 
no longer work as they depend on an executing high-priority task preventing a lower
priority task from executing. This clearly will not occur if the lower-priority task is on 
another processor. There are no simple equivalent protocols to those for single processors. 
To implement mutual exclusion in a multiprocessor shared memory system usually 

requires locks that can be contended for globally. When a task holds such a lock it is 
usual to prevent it from being preempted locally (as this would further delay tasks on 
other processors waiting for the lock). When a lock is requested but not granted, the task 
will typically busy-wait on the lock, waiting for it to become free -this is known as 
spinning. Obviously this spinning time will add to the task's execution time and hence 
has to be bounded if the task's interference on lower-priority tasks is to be calculated. A 
system with many globally shared objects and nested usage patterns (i.e. accessing one 
SCHEDULING FOR POWER-AWARE SYSTEMS 413 

object whilst holding the lock on others) will be harder to analyse and the analysis itself is likely to be pessimistic. Also error conditions such as deadlocks and livelocks are now possible whereas they were prevented by some of the single processor protocols. 
Because of these difficulties with global locks, the use of lock-free algorithms is attractive. Here multiple copies of the shared object are supported and if necessary actions are repeated if conflicts over the copies have occurred. To give a simple example, consider an object that is read by many tasks but updated by only one. While the update is happening all reads are made to an old copy of the object. Once the update is finished a single flag is set to make the new copy available to future read operations. If the timing constraints on the system allow concurrent reads and writes then it must be acceptable for the read operation to get the old value -if it had arrived any earlier (or the writing task any later) then the old copy would have been the 'current' one. 
Overall, multiprocessor systems whilst providing more computational power introduce a number of challenges for real-time systems. The move from scheduling a single resource to the coordination of multi-resources is a major one that requires a holistic approach to system scheduling. However, the core of this approach will always be the management of each individual resource. 
11.15 Scheduling for power-aware systems 
All of the scheduling results presented in this chapter have the common form of: given a set of execution time requirements (the Cs), will all the tasks complete by their deadlines (the Ds)? This assumes a fixed speed processor (or processors) so that the worst-case execution time values can be obtained prior to attempting the system-wide scheduling analysis. There are, however, variable speed processors that can give rise to a difference scheduling question -at what speed must the processor execute in order for the tasks to be schedulable? 
Variable speed resources are typically found in power-aware applications, that is in embedded systems that run on batteries. Examples of such systems are mobile devices and nodes in a sensor net. All battery-based systems have the need to preserve energy and thereby extend their operational life or periods between recharges. 
To save power, the voltage to the processor is reduced with the result that it runs slower. But the saving is non-linear. Halving the speed of a processor may quadruple its life. Some processors have variable speed, others support just a finite set of speed settings. From the point of view of the scheduling analysis, the verification problem now has two stages. 
• 
With the processor running at its maximum speed (Max), is the system schedulable? This is a standard test. 

• 
If the system is schedulable, by what maximum factor k can all the C values be increased so that the system remains schedulable? 


There is no simple way to compute k, rather it needs to be found by a branch and bound search. Consider the fixed priority example given in Table 11.20 where the C values are those that are appropriate for the maximum speed of the processor. 
414 SCHEDULING REAL-TIME SYSTEMS 
Task T D C 
a  70  70  5  
b  120  100  7  
C  200  200  11  

Table 11.20 Example task set with maximum speed. 
Task T D C R 
a  70  70  25  25  
b  120  100  35  60  
C  200  200  55  200  

Table 11.21 Example task set with reduced speed. 

This is clearly schedulable (Ra = 5, Rb = 12 and Re = 23). If k is given the value 10 (i.e. execution times are now 50, 70 and 110) then the utilization is greater than 1 so the system is clearly unschedulable. Sok must lie between 1 and 10. Using, for illustration, only integer values for k, the value 6 could be tried next (result unschedulable) then 4 (schedulable) and then 5. The results fork = 5 are shown in Table 11.21. Note the response time for task c is just on its deadline (200\ any increase in any C parameter would cause this task to become unschedulable. Hence k = 5 is the optimum value and it is possible to conclude that the task set is schedulable on a processor with speed Max/5. 
This discussion has focused on statically fixing the processor speed so that all deadlines are Gust) met. In more dynamic systems where the work load fluctuates at run-time it is possible to change the processor's speed whilst continuing to execute the application. For all processors there is a cost (overhead) in making these changes. It is also necessary to take into account the impact on memory performance and I/0 devices savings in processing cost may not lead to overall system economy. 
11.16 Incorporating system overheads 
In all the analysis presented so far in this chapter, the overheads of actually implementing the multitasking system software have been ignored. Clearly for a real system this is not acceptable and hence the scheduling equations need to be expanded to include terms for the overhead factors. The following characteristics are typical of many operating system kernels or language run-time support systems. 
• The cost of a context switch between tasks is not negligible and may not be a single value. The cost of a context switch to a higher-priority periodic task (following, for example, a clock interrupt) may be higher than a context switch from a task to a lower-priority task (at the end of the high-priority task's execution). For systems with a large number of periodic tasks, an additional cost will be incurred for 
INCORPORATING SYSTEM OVERHEADS 415 
manipulating the delay queue (for periodic tasks when they execute, say, an Ada 'delay until' statement). 

• 
All context switch operations are non preemptive. 

• 
The cost of handling an interrupt ( other than the clock) and releasing an application sporadic task is not insignificant. Furthermore, for DMA and channel-program controlled devices, the impact of shared-memory access can have a non-trivial impact on worst-case performance -such devices are best avoided in hard realtime systems. 

• 
A clock interrupt (say every 10 ms) could result in periodic tasks being moved from a delay queue to the dispatch/ready queue. The cost for this operation varies depending on the number of tasks to be moved. 


In addition to the above, the scheduling analysis must take into account the features of the underlying hardware, such as the impact of the cache and pipeline. 
11.16.1 Modelling non-trivial context switch times 
Most scheduling models ignore context switch times. This approach is, however, too simplistic if the total cost of the context switches is not trivial when compared with the application's own code. Figure 11.12 illustrates a number of significant events in the execution of a typical periodic task. 
A -the clock interrupt that designates the notional time at which the task should start (assuming no release jitter or non-preemptive delay-if the interrupts were disabled due to the operation of the context switch then the clock handler would have its execution delayed; this is taken into account in the scheduling equations by the blocking factor B). 
Clock handler \ 
Context Context switch switch 
Task execution 

A B C D E 
Figure 11.12 Overheads when executing tasks. 

416 SCHEDULING REAL-TIME SYSTEMS 
B -the earliest time that the clock handler can complete; this signifies the start of the context switch to the task (assume it is the highest priority runnable task). C the actual start of the execution of the task. D -the completion of the task (the task may be preempted a number of times between C and D). E -the completion of the context switch away from the task. A' -the next release of the task. 
The typical requirement for this task is that it completes before its next release (that is, D < A'), or before some deadline prior to its next release. Either way, D is the significant time, not E. Another form of requirement puts a bound on the time between the start of execution and termination (that is, D-C). This occurs when the first action is an input and the last an output (and there is a deadline requirement between the two). While these factors affect the meaning of the task's own deadline (and hence its response time) they do not affect the interference this task has on lower-priority tasks; here the full cost of both context switches counts. Recall that the basic scheduling equation (11.7) has the form: 
This now becomes (for periodic tasks only): 
Ri = C 5 I + C; + Bi + I: I;i l (C 5 I + C 52 + Cj) (11.33) 
jEhp(i) I J 

where C 5 1 is the cost of the initial context switch (to the task) and C 52 is the cost of the context switch away from each task at the end of its execution. The cost of putting the task into the delay queue (if it is periodic) is incorporated into Ci. Note that in practice this value may depend on the size of the queue; a maximum value would need to be incorporated into C;. 
This measure of the response time is from point B in Figure 11.12. To measure 

from point C, the first C 5 1 term is removed. To measure from point A (the notional 
true release time of the task) requires the clock behaviour to be measured (see Sec
tion 11.16.3). 
For multiprocessor systems the context switch itself may be more complicated if 

global placement is used as tasks may need to migrate from one processor to another. 
This will add to the context switch overhead and will make the prediction of worst-case 
execution time (WCET) more difficult as the cache may not be shared between all the 
processors. 
11.16.2 Modelling sporadic tasks 
For sporadic tasks released by other sporadic tasks, or by periodic tasks, Equation (11.33) is a valid model of behaviour. However, the computation time for the task, C;, must include the overheads of blocking on the agent that controls its release. 
INCORPORATING SYSTEM OVERHEADS 417 

When sporadic tasks are released by an interrupt, priority inversion can occur. Even if the sporadic has a low priority ( due to its having a long deadline) the interrupt itself will be executed at a high hardware priority level. Let rs be the set of sporadic tasks released by inte·rrupts. Each interrupt source will be assumed to have the same arrival characteristics as the sporadic that it releases. The additional interference these interrupt handlers have on each application task is given by: 

where / H is the cost of handling the interrupt (and returning to the running task, having released the sporadic task). 
This representation assumes that all interrupt handlers give rise to the same cost; if this is not the case then / H must be defined for each k. Equation ( 11.33) now becomes: 
2
R = cs' + ci + B; + L 11:'.lccs' + cs + cj) 
jEhp(i) J 

(11.34) 

Within Ada, timing events are also used to release sporadic tasks or to undertake short event-handling activities. As timing events are similar to interrupts they can be modelled in the way shown above. 
11.16.3 Modelling the real-time clock handler 
To support periodic tasks, the execution environment must have access to a real-time clock that will generate interrupts at appropriate times. An ideal system will use an interval timer, and will interrupt only when a periodic task needs to be released. The more common approach, however, is one in which the clock interrupts at a regular rate ( say once every 10 ms) and the handler must decide if none, one or a number of periodic tasks must be released. The ideal approach can be modelled in an identical way to that introduced for sporadic tasks (see Section 11.16.2). With the regular clock method, it is necessary to develop a more detailed model as the execution times of the clock handler can vary considerably. Table 11.22 gives possible times for this handler (for a clock period of 10 ms). Note that if the worst case was assumed to occur on all occasions, over 
Queue state Clock handling time, µ,s 
No tasks on queue  16  
Tasks on queue but none removed  24  
One task removed  88  
Two tasks removed  128  
Twenty-five tasks removed  1048  

Table 11.22 Clock handling overheads. 

418 SCHEDULING REAL-TIME SYSTEMS 
10% of the processor would have to be assigned to the clock handler. Moreover, all this computation occurs at a high (highest) hardware priority level, and hence considerable priority inversion is occurring. For example, with the figures given in the table, at the LCM (least common multiple) of the 25 periodic tasks 1048 µs of interference would be suffered by the highest priority application task that was released. If the task was released on its own then only 88 µs would be suffered. The time interval is represented by B-A in Figure 11.12. 
In general, the cost of moving N periodic tasks from the delay queue to the dispatch queue can be represented by the following formula: 


where CTc is the constant cost (assuming there is always at least one task on the delay queue), C T5 is the cost of making a single move, and C T'n is the cost of each subsequent move. This model is appropriate due to the observation that the cost of moving just one task is often high when compared with the additional cost of moving extra tasks. With the kernel considered here, these costs were: 
CF 24 µs CT5 64 µs CTm 40 µs 

To reduce the pessimism of assuming that a computational cost of Cc-tk is consumed on each execution of the clock handler, this load can be spread over a number of clock ticks. This is valid if the shortest period of any application task, Tinin is greater than the clock period, Tc1k• Let M be defined by: 
Tmin l
M-
rTc1k 

If M is greater than 1 then the load from the clock handler can be spread over M executions. In this situation, the clock handler is modelled as a task with period Tmin and computation time c;1k: 


This assumes M <= N. Equation (11.34) now becomes 
1 12
R;=CS +C;+B;+ L r:;1(CS +cs +C;) 
jehp(i) J 
(11.35)
+ L IR; lI H + I~lc;lk 
kers ITk ITmm 

To give further improvements (to the model) requires a more exact representation of the clock handler's actual execution. For example, using just CF and CP the following 
SUMMARY 419 

equation can easily be derived: 
1 2
R; =CS +C;+B;+ (CS 1 +CS +C;)


L r:;1 
}Ehp(i) J 
+ L rRil IH + l_!!!__lCTc 
kEfs Tk Tclk 
(11.36)
+ L r :; lCT, 
gEfp g 

where rp is the set of periodic tasks. 
It is left as an exercise for the reader to incorporate the three-parameter model of clock handling ( see Exercise 11.16). 
Summary 
A scheduling scheme has two facets: it defines an algorithm for resource sharing and a means of predicting the worst-case behaviour of an application when that form of resource sharing is used. 
Many current periodic real-time systems are implemented using a cyclic executive. With this approach, the application code must be packed into a fixed number of 'minor cycles' such that the cyclic execution of the sequence of minor cycles (called a 'major cycle') will enable all system deadlines to be met. Although an effective implementation strategy for small systems, there are a number of drawbacks with this cyclic approach. 
• 
The packing of the minor cycles becomes increasingly difficult as the system grows. 

• 
Sporadic activities are difficult to accommodate. 

• 
Tasks with long periods (that is, longer than the major cycle) are supported inefficiently. 

• 
Tasks with large computation times must be split up so that they can be packed into a series of minor cycles. 

• 
The structure of the cyclic executive makes it very difficult to alter to accommodate changing requirements. 


Because of these difficulties, this chapter has focused on the use of more dynamic scheduling schemes. The main topic of the chapter has been the fixed priority scheduling of a collection of tasks on a single processor. Following the description of a simple utilization-based test (which is only applicable to a restricted task model), the response time calculations were derived for a more flexible model. This model can accommodate sporadic tasks, task interactions, non-preemptive sections, release jitter, aperiodic servers, fault-tolerant systems and an arbitrary relationship between a task deadline (D) and its minimum arrival interval ( T). 
420 SCHEDULING REAL-TIME SYSTEMS 
Intertask synchronization, such as mutual exclusive access to shared data, can give rise to priority inversion unless some form of priority inheritance is used. Two particular protocols were described in detail in this chapter: 'original ceiling priority inheritance' and 'immediate ceiling priority inheritance'. 
With priority-based scheduling, it is important that the priorities are assigned to reflect the temporal characteristic of the task load. Three algorithms have been described in this chapter: 
• 
rate monotonic -for D = T 

• 
deadline monotonic -for D :s T 

• 
arbitrary -for D > T. 


The other significant scheduling approach is EDF -here theJask with the shortest (earliest) deadline is the one to execute first. EDF has the advantage that it optimally allocates the processor. If an application cannot be scheduled by EDF then it cannot be scheduled by any other approach. For simple systems with D = T then a very simple and exact utilization-based test can be used to check schedulability. When D :sT then Processor Demand Analysis has to be undertaken. An efficient approach to this form of analysis called QPA was introduced and illustrated by examples. 
Also in this chapter a number of other scheduling topics have been referred to (even if they have not been dealt with comprehensively). Amongst these are: worst-case execution time estimation, multiprocessor platforms, dynamic open systems and power-aware applications. Finally attention was focused on the overheads of implementing multitasking application code. It was shown how the standard response time equations can be extended to incorporate parameters to characterize the implementation's run-time behaviour. 
Further reading 
Buttazzo, G. C. (1997) Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications. New York: Kluwer Academic. Davis, R., Zaboos, A. and Burns, A. (2008) Effective exact schedulability tests for fixed priority real-time systems. IEEE Transactions on Computing, 57(9), 1261-1276. 
Ermedahl, A. and Engblom, J. (2007) Execution time analysis for embedded real-time systems, in Handbook of Real-Time and Embedded Systems, I. Lee, J. Y-T. Leung and S. H. Son (eds). Boca Raton, FL: Chapman and Hall/CRC. 
Klein, M. H., Ralya, T., Pollak, B., Obenza, R. and Gonzalez Harbour, M. (1993) A Practitioner's Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems. New York: Kluwer Academic. 
Liu, J. W. S (2000) Real-Time Systems. New York: Prentice Hall. Natarajan, S. (ed.) (1995) Imprecise and Approximate Computation. New York: Kluwer Academic. Rajkumar, R. (1993) Synchronization in Real-Time Systems: A Priority Inheritance Approach. New York: Kluwer Academic. 
EXERCISES 421 

Sha, L. et al. (2004) Real time scheduling theory: A historical perspective. Real-Time Systems, 28(2-3), 101-155. 
Stankovic, J. A., Spuni, M., Ramamritham, K. and Buttazzo., G. C. (1998) Deadline Scheduling for Real-Time Systems: EDF and Related Algorithms. New York: Kluwer Academic. 
Exercises 
11.1 Three logical tasks P, Q and Shave the following characteristics. P: period 3, required execution time I; Q: period 6, required execution time 2; S: period 18, required execution time 5. Show how these tasks can be scheduled using the rate monotonic scheduling algorithm. Show how a cyclic executive could be constructed to implement the three logical tasks. 
11.2 Consider three tasks P, Q and S. P has a period of 100 ms in which it requires 30 ms of tasking. The corresponding values for Q and S are (5,1) and (25,5) respectively. Assume that P is the most important task in the system, followed by Sand then Q. 
(1) 
What is the behaviour of the scheduler if priority is based on importance? 

(2) 
What is the processor utilization of P, Q and S? 

(3) 
How should the tasks be scheduled so that all deadlines are met? 

(
4) Illustrate one of the schemes that allows these tasks to be scheduled. 



11.3 To the above task set is added a fourth task (R). Failure of this task will not lead to safety being undermined. R has a period of 50 ms, but has a processing requirement that is data dependent and varies from 5 to 25 ms. Discuss how this task should be integrated with P, Q and S. 
11.4 Figure 11.13 illustrates the behaviour of four periodic tasks w, x, y and z.These tasks have priorities determined by the rate monotonic scheme, with the result that priority( w) > priority(x) > priority(y) > priority(z). Each task's period starts at time S and terminates at T. The four tasks share two resources that are protected by binary semaphores A and B. On the diagram the tag A (and B) implies 'do a wait operation on the semaphore'; the tag A' (and B') implies 'do a signal operation on the semaphore'. Table 11.23 summarizes the task's requirements. The figure shows the execution histories of the four tasks using static priorities. For example, x starts at time 2, executes a successful wait operation on B at time 3 but unsuccessfully waits on A at time 4 (z has already locked A). At time 
13 it executes again (that is, it now has lock on A), it releases A at time 14 and B at time 15. It is now preempted by w, but executes again at time 16. Finally it terminates at time 17. Redraw Figure 11. 13 to illustrate the behaviour of these tasks if priority inheritance is employed. 

422 SCHEDULING REAL-TIME SYSTEMS 
A A' B B' 
w 
s T 
B A A' B' 

s T 
y 
1117 
s T A A' 
z 

S T 
0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 
I I I I I I I I I I I I I I I I I I I I Time---------
Figure 11.13 The behaviour of four periodic tasks in Exercise 11.4. 
Task Priority Start time Required processor time Semaphores used 
w  10  7  4  A,B  
X  8  2  5  A,B  
y  6  5  4  
z  4  0  5  A  

Table 11.23 Summary of the task's requirements for Exercise 11 .4. 

11.5 Redraw the figure given in Exercise 11.4 to illustrate the behaviour of these tasks if immediate priority ceiling inheritance is employed. 
11.6 With the priority ceiling protocol, it is possible to calculate the maximum time any task can be blocked by the operation of a lower-priority task. What is the rule for calculating this blocking? Illustrate the answer by calculating the maximum blocking time for each task in the following example. A program consists of five tasks, a, b, c, d, e (these are listed in priority order with a having the highest priority), and six resources R 1, ... , R6 (protected by semaphores implementing the priority ceiling protocol). The resource accesses have worst case execution times given in Table 11.24. 
Rl R2 R3 R4 RS R6 
50ms 150ms 75ms 300ms 250ms 175ms 
Table 11.24 Summary of resource access times for Exercise 11.6. 
EXERCISES 423 
Resources are used by the tasks according to Table 11.25. 
Task Uses 
a R3 b Rl,R2 C R3,R4,R5 d Rl,R5,R6 e R2,R6 
Table 11.25 Summary of the tasks' resource requirements for Exercise 11.6. 

11.7 Is the task set shown in Table 11.26 schedulable using the simple utilizationbased test given in Equation (11.1)? Is the task set schedulable using the response time analysis? 
Task Period Execution time 
a  50  10  
b  40  10  
C  30  9  

Table 11.26 Summary of the tasks' attributes for Exercise 11.7. 

11.8 The task set shown in Table 11.27 is not schedulable using Equation ( 11.1) because a must be given the top priority due to its criticality. How can the task set be transformed so that it is schedulable? Note that the computations represented by a must still be given top priority. 
Task Period Execution time Criticality 
a  60  10  HIGH  
b  10  3  LOW  
C  8  2  LOW  

Table 11.27 Summary of the tasks' attributes for Exercise 11.8. 

11.9 The task set given in Table 11.28 is not schedulable using Equation (11.1), but does meet all deadlines when scheduled using fixed priorities. Explain why. 
Task Period Execution time 
a  75  35  
b  40  10  
C  20  5  

Table 11.28 Summary of the tasks' attributes for Exercise 11.9. 

424 SCHEDULING REAL-TIME SYSTEMS 
11.10 In Section 11.6, a sporadic task was defined as having a minimum inter-arrival time. Often sporadic tasks come in bursts. Update Equation (11.4) to cope with a burst of sporadic activities such that N invocations can appear arbitrarily close together in a period of T. 
11.11 Extend the answer given above to cope with sporadic activity which arrives in bursts, where there may be N invocations in a period of T and each invocation must be separated by at least M time units. 
11.12 To what extent can the response time equations given in this chapter be applied to resources other than the CPU? For example, can the equations be used to schedule access to a disk? 
11.13 In a safety-critical real-time system, a collection of tasks can be used to monitor key environmental events. Typically, there will be a deadline defined between the event occurring and some output (which is in response to the event) being produced. Describe how periodic tasks can be used to monitor such events. 
11.14 Consider the list of events (shown in Table 11.29) together with the computation costs of responding to each event. If a separate task is used for each event (and these tasks are implemented by preemptive priority-based scheduling) describe how Rate Monotonic Analysis can be applied to make sure all deadlines are met. 
EVENT Deadline Computation time 
A_Event  36  2  
B_Event  24  1  
C_Event  IO  1  
D_Event  48  4  
E_Event  12  

Table 11.29 Summary of events for Exercise 11.14. 

11.15 How can the task set shown in Table 11.30 be optimally scheduled (using fixedpriority scheduling)? Is this task set schedulable? 
Task T C B D 
a  8  4  2  8  
b  IO  2  2  5  
C  30  5  2  30  


Table 11.30  Summary of tasks for Exercise 11.15.  
11.16 11.17 11.18  Develop a model of clock handling which incorporates the three parameters CTC, CT5 and CTm (see Section 11.16.3). Rather than using a clock interrupt to schedule periodic tasks, what would be the ramifications of only having access to a real-time clock? A periodic task of period 40 ms is controlled by a clock interrupt that has a granularity of 30 ms. How can the worst-case response time of this task be calculated?  

2 

BASIC CONCEPTS 

2.1 INTRODUCTION 
Over the last few years, several algorithms and methodologies have been proposed in the literature to improve the predictability of real-time systems. In order to present these results we need to define some basic concepts that will be used throughout the book. We begin with the most important software entity treated by any operating system, the process. A process is a computation that is executed by the CPU in a sequential fashion. In this text, the terms process and task are used as synonyms. However, it is worth saying that some authors prefer to distinguish them and define a task as a sequential execution of code that does not suspend itself during execution, whereas a process is a more complex computational activity, that can be composed by many tasks. 
When a single processor has to execute a set of concurrent tasks -that is, tasks that can overlap in time -the CPU has to be assigned to the various tasks according to a predefined criterion, called a scheduling policy. The set of rules that, at any time, determines the order in which tasks are executed is called a scheduling algorithm. The specific operation of allocating the CPU to a task selected by the scheduling algorithm is referred as dispatching. 
Thus, a task that could potentially execute on the CPU can be either in execution if it has been selected by the scheduling algorithm or waiting for the CPU if another task is executing. A task that can potentially execute on the processor, independently on its actual availability, is called an active task. A task waiting for the processor is called a ready task, whereas the task in execution is called a running task. All ready tasks waiting for the processor are kept in 
24 CHAPTER 2 

dispatching 
Execution 

scheduling 
preemption 
Figure 2.1 Queue of ready tasks waiting for execution. 

a queue, called ready queue. Operating systems that handles different types of tasks, may have more than one ready queue. 
In many operating systems that allow dynamic task activation, the running task can be interrupted at any point, so that a more important task that arrives in the system can immediately gain the processor and does not need to wait in the ready queue. In this case, the running task is interrupted and inserted in the ready queue, while the CPU is assigned to the most important ready task which just arrived. The operation of suspending the· running task and inserting it into the ready queue is called preemption. Figure 2.1 schematically illustrates the concepts presented above. In dynamic real-time systems, preemption is important for three reasons [SZ92]: 
■ 
Tasks performing exception handling may need to preempt existing tasks so that responses to exceptions may be issued in a timely fashion. 

■ 
When application tasks have different levels of criticalness expressing task importance, preemption permits to anticipate the execution of the most critical activities. 


• More efficient schedules can be produced to improve system responsiveness. 
Given a set of tasks, J ={Ji, ... , ln}, a schedule is an assignment of tasks to the processor, so that each task is executed until completion. More formally, a schedule can be defined as a function <1: R+ ➔ N such that Vt E R+, 3t 1, t2 such that t E [t1, t2) and "r/t' E [t1, t2) a(t) =a(t'). In other words, a(t) is an integer step function and <1(t)=k, with k > 0, means that task Jk is executing at time t, while a(t) =0 means that the CPU is idle. Figure 2.2 shows an example of schedule obtained by executing three tasks: 11, Ji, J3. 
■ At times t1, t2, t3, and t4 , the processor performs a context switch. 
Basic Concepts 
idle idle 
■ 11 .. 


Figure 2.2 Schedule obtained by executing three tasks. Ji, h, and h. 
■ 
Each interval [ti, ti+i) in which cr(t) is constant is called time slice. Interval [x,y) identifies all values oft such that x::; t < y. 

■ 
A preemptive schedule is a schedule in which the running task can be arbitrarily suspended at any time, to assign the CPU to another task according to a predefined scheduling policy. In preemptive schedules, tasks may be executed in disjointed interval of times. 

■ 
A schedule is said to be feasible if all tasks can be completed according to a set of specified constraints. 

■ 
A set of tasks is said to be schedulable if there exists at least one algorithm that can produce a feasible schedule. 


An example of preemptive schedule is shown in Figure 2.3. 
2.2 TYPES OF TASK CONSTRAINTS 
Typical constraints that can be specified on real-time tasks are of three classes: timing constraints, precedence relations, and mutual exclusion constraints on shared resources. 
26 CHAPTER 2 
J I nrtttq :;,, t 
12 ::,, t 
-
J3 
::,, t 


Figure 2.3 Example of a preemptive schedule. 


2.2.1 Timing constraints 
Real-time systems are characterized by computational activities with stringent timing constraints that must be met in order to achieve the desired behavior. A typical timing constraint on a task is the deadline, which represents the time before which a process should complete its execution without causing any damage to the system. Depending on the consequences of a missed deadline, real-time tasks are usually distinguished in two classes: 
■ 
Hard. A task is said to be hard if a completion after its deadline can cause catastrophic consequences on the system. In this case, any instance of the task should a priori be guaranteed in the worst-case scenario. 

■ 
Soft. A task is said to be soft if missing its deadline decreases the performance of the system but does not jeopardize its correct behavior. 


In general, a real-time task Ji can be characterized by the following parameters: 
■ Arrival time ai: is the time at which a task becomes ready for execution; it is also referred as request time or release time and indicated by ri; 
Basic Concepts 
J·I 
;;a
I 
C·I ! 
t 
a·I s µ . -· · d·I
I f I 
Figure 2.4 Typical parameters of a real-time task. 

■ 
Computation time Ci: is the time necessary to the processor for executing the task without interruption; 

■ 
Deadline di: is the time before which a task should be complete to avoid damage to the system; 

■ 
Start time Si: is the time at which a task starts its execution; 

■ 
Finishing time fi: is the time at which a task finishes its execution; 

■ 
Criticalness: is a parameter related to the consequences of missing the deadline (typically, it can be hard or soft); 


• 
Value vi: represents the relative importance of the task with respect to the other tasks in the system; 

• 
Lateness Li: Li = h -di represents the delay of a task completion with respect to its deadline; note that if a task completes before the deadline, its lateness is negative; 


■ 
Tardiness or Exceeding time Ei: Ei = max(O, Li) is the time a task stays active after its deadline; 

■ 
Laxity or Slack time Xi: Xi = di -ai -Ci is the maximum time a task can be delayed on its activation to complete within its deadline. 


Some of the parameters defined above are illustrated in Figure 2.4. 
Another timing characteristic that can be specified on a real-time task concerns the regularity of its activation. In particular, tasks can be defined as periodicor aperiodic. Periodic tasks consist of an infinite sequence of identical activities, called instances or jobs, that are regularly activated at a constant rate. For the sake of clarity, from now on, a periodic task will be denoted by Ti, whereas an aperiodic job by Ji. 
28 CHAPTER 2 
first D·I k th instance instance 
Ci 
't i 
I ! I ! I.
t 
q,i q,i + (k-1) T i
T·I (a) D·I D·I 

Ci Ci J·I 
:9> t




I I I I 
ail dil ai2 di2 
(b) 

Figure 2.5 Sequence of instances for a periodic and an aperiodic task. 
The activation time of the first periodic instance is called phase. If <Piis the phase of the periodic task Ti, the activation time of the kth instance is given by <Pi+ (k ~ l)Ti, where Ti is called period of the task. In many practical cases, a periodic process can be completely characterized by its computation time Ci and its relative deadline Di, which is often considered coincident to the end of the period. Moreover, the parameters Ci, Ti e Di are considered to be constant for each instance. Aperiodic tasks also consist of an infinite sequence of identical activities (instances); however, their activations are not regular. Figure 2.5 shows an example of task instances for a periodic and for an aperiodic task. 
2.2.2 Precedence constraints 
In certain applications, computational activities cannot be executed in arbitrary order but have to respect some precedence relations defined at the design stage. Such precedence relations are usually described through a directed acyclic graph G, where tasks are represented by nodes and precedence relations by arrows. A precedence graph G induces a partial order on the task set. 
■ 
The notation la -< lb specifies that task la is a predecessor of task lb, meaning that G contains a directed path from node la to node lb. 

■ 
The notation la ➔ lb specifies that task la is an immediate predecessor of lb, meaning that G contains an arc directed from node la to node lb. 


Basic Concepts 
J ~ J 2 
~
J I J 2 
J 3 
J I ~ J 4 

J I ~ J 4 J 4 
Figure 2.6 Precedence relations among five tasks. 

Figure 2.6 illustrates a directed acyclic graph that describes the precedence constraints among five tasks. From the graph structure we observe that task J1 is the only one that can start executing since it does not have predecessors. Tasks with no predecessors are called beginning tasks. As 11 is completed, either J2 or J 3 can start. Task J4 can start only when J2 is completed, whereas J5 must wait the completion of 12 and J3. Tasks with no successors, as 14 and Js I are called ending tasks. 
In order to understand how precedence graphs can be derived from tasks' relations, let us consider the application illustrated in Figure 2.7. Here, a number of objects moving on a conveyor belt must be recognized and classified using a stereo vision system, consisting of two cameras mounted in a suitable location. Suppose that the recognition process is carried out by integrating the two-dimensional features of the top view of the objects with the height information extracted by the pixel disparity on the two images. As a consequence, the computational activities of the application can be organized by defining the following tasks: 
■ 
Two tasks (one for each camera) dedicated to image acquisition, whose objective is to transfer the image from the camera to the processor memory (they are identified by acql and acq2); 

■ 
Two tasks (one for each camera) dedicated to low-level image processing ( typical operations performed at this level include digital filtering for noise reduction and edge detection; we identify these tasks as edge1 and edge2); 

■ 
A task for extracting two-dimensional features from the object contours (it is referred as shape); 


30 CHAPTER 2 



Figure 2. 7 Industrial application which requires a visual recognition of objects on a conveyor belt. 
• 
A task for computing the pixel disparities from the two images (it is referred as disp); 

• 
A task for determining the object height from the results achieved by the disp task (it is referred as H); 

• 
A task performing the final recognition ( this task integrates the geometrical features of the object contour with the height information and tries to match these data with those stored in the data base; it is referred as rec). 


From the logic relations existing among the computations, it is easy to see that tasks acql and acq2 can be executed in parallel before any other activity. Tasks edgel and edge2 can also be executed in parallel, but each task cannot start before the associated acquisition task completes. Task shape is based on the object contour extracted by the low-level image processing, therefore it must wait the termination of both edge1and edge2. The same is true for task disp, which however can be executed in parallel with task shape. Then, task H can only start as disp completes and, finally, task rec must wait the completion of Hand shape. The resulting precedence graph is shown in Figure 2.8. 
Basic Concepts 
Figure 2.8 Precedence graph associated with the robotic application. 



2.2.3 Resource constraints 
From a process point of view, a resource is any software structure that can be used by the process to advance its execution. Typically, a resource can be a data structure, a set of variables, a main memory area, a file, a piece of program, or a set of registers of a peripheral device. A resource dedicated to a particular process is said to be private, whereas a resource that can be used by more tasks is called a shared resource. 
To maintain data consistency, many shared resources do not allow simultaneous accesses but require mutual exclusion among competing tasks. They are called exclusive resources. Let R be an exclusive resource shared by tasks la and Jb. If A is the operation performed on R by J0 , and Bis the operation performed on R by Jb, then A and B must never be executed at the same time. A piece of code executed under mutual exclusion constraints is called a critical section. 
To ensure sequential accesses to exclusive resources, operating systems usually provide a synchronization mechanism (such as semaphores) that can be used by tasks to create critical sections of code. Hence, when we say that two or more tasks have resource constraints, we mean that they have to be synchronized since they share exclusive resources. 
32 CHAPTER 2 
wait(s) 
critical 
section 
signal(s) 
-
-
-
shared resource 
I I
R
I I 
-
-
-
wait(s) 
critical 
section 
signal(s) 
Figure 2.9 Structure of two tasks that share an exclusive resource. 

Consider two tasks 11 and 12 that share an exclusive resource R (for instance, a list), on which two operations (such as insert and remove) are defined. The code implementing such operations is thus a critical section that must be executed in mutual exclusion. If a binary semaphore s is used for this purpose, then each critical section must begin with a wait(s) primitive and must end with a signal(s) primitive (see Figure 2.9). 
If preemption is allowed and J1 has a higher priority than Ji, then J1 can block in the situation depicted in Figure 2.10. Here, task 12 is activated first, and, after a while, it enters the critical section and locks the semaphore. While J2 is executing the critical section, task J1 arrives, and, since it has a higher priority, it preempts J2 and starts executing. However, at time t1, when attempting to enter its critical section, it is blocked on the semaphore and J2 is resumed. J1 is blocked until time t2 , when 12 releases the critical section by executing the signal(s) primitive, which unlocks the semaphore. 
A task waiting for an exclusive resource is said to be blockedon that resource. All tasks blocked on the same resource are kept in a queue associated with the semaphore, which protects the resource. When a running task executes a wait primitive on a locked semaphore, it enters a waiting state, until another task executes a signal primitive that unlocks the semaphore. When a task leaves the waiting state, it does not go in the running state, but in the ready state, so that the CPU can be assigned to the highest-priority task by the scheduling algorithm. The state transition diagram relative to the situation described above is shown in Figure 2 .11. 
Basic Concepts 
~  critical section  
- normal execution  
blocked on s  

J I h✓~-llt19111i------;;,, 


t I 
Figure 2.10 Example of blocking on an exclusive resource. 
scheduling 


Figure 2.11 Waiting state caused by resource constraints. 

34 CHAPTER 2 

2.3 DEFINITION OF SCHEDULING PROBLEMS 
In general, to define a scheduling problem we need to specify three sets: a set of n tasks J = { J1, J2, ... , Jn}, a set of m processors P = {Pi, P2, ... , Pm} and a set of s types of resources R = {R1, R 2, ... , Ra}. Moreover, precedence relations among tasks can be specified through a directed acyclic graph, and timing constraints can be associated with each task. In this context, scheduling means to assign processors from P and resources from R to tasks from J in order to complete all tasks under the imposed constraints [B+93). This problem, in its general form, has been shown to be NP-complete [GJ79) and hence computationally intractable. 
Indeed, the complexity of scheduling algorithms is of high relevance in dynamic real-time systems, where scheduling decisions must be taken on-line during taslk execution. A polynomial algorithm is one whose time complexity grows as a polynomial function p of the input length n of an instance. The complexity of such algorithms is denoted by O(p(n)). Each algorithm whose complexity function cannot be bounded in that way is called an exponential time algorithm. In particular, NP is the dass of all decision problems that can be solved in polynomial time by a nondeterministic Turing machine. A problem Q is said to be NP-complete if Q E NP and, for every Q' E NP, Q' is polynomially transformable to Q [GJ79]. A decision problem Q is said to be NP-hard if all problems in NP are polynomially transformable to Q, but we cannot show that QE NP. 
Let us consider two algorithms with complexity functions n and 5n, respectively, and let us assume that an elementary step for these algorithms lasts 1 µs. If the input length of the instance is n = 30, then it is easy to calculate that the polynomial algorithm can solve the problem in 30 µs, whereas the other needs about 3 · 105 centuries. This example illustrates that the difference between polynomial and exponential time algorithms is large and, hence, it may have a strong influence on the performance of dynamic real-time systems. As a consequence, one of the research objectives on real-time scheduling is to restrict our attention to simpler, but still practical, problems that can be solved in polynomial time complexity. 
In order to reduce the complexity of constructing a feasible schedule, one may simplify the computer architecture (for example, by restricting to the case of uniprocessor systems), or one may adopt a preemptive model, use fixed priorities, remove precedence and/or resource constraints, assume simultaneous task 
Basic Concepts 
activation, homogeneous task sets (solely periodic or solely aperiodic activities), and so on. The assumptions made on the system or on the tasks are typically used to classify the various scheduling algorithms proposed in the literature. 

2.3.1 Classification of scheduling algorithms 
Among the great variety of algorithms proposed for scheduling real-time tasks, we can identify the following main classes. 
■ Preemptive. With preemptive algorithms, the running task can be interrupted at any time to assign the processor to another active task, according to a predefined scheduling policy. 
• Non-preemptive. With non-preemptive algorithms, a task, once started, is executed by the processor until completion. In this case, all scheduling decisions are taken as a task terminates its execution. 
■ Static. Static algorithms are those in which scheduling decisions are based on fixed parameters, assigned to tasks before their activation. 
• Dynamic. Dynamic algorithms are those in which scheduling decisions are based on dynamic parameters that may change during system evolution. 
■ Off-line. We say that a scheduling algorithm is used off-line if it is executed on the entire task set before actual task activation. The schedule generated in this way is stored in a table and later executed by a dispatcher. 
• 
On-line. We say that a scheduling algorithm is used on-line if scheduling decisions are taken at runtime every time a new task enters the system or when a running task terminates. 

• 
Optimal. An algorithm is said to be optimal if it minimiz,es some given cost function defined over the task set. When no cost function is defined and the only concern is to achieve a feasible schedule, then an algorithm is said to be optimal if it may fail to meet a deadline only if no other algorithms of the same class can meet it. 

• 
Heuristic. An algorithm is said to be heuristic if it tends toward but does not guarantee to find the optimal schedule. 


Moreover, an algorithm is said to be clairvoyant if it knows the future; that is, if it knows in advance the arrival times of all the tasks. Although such an 
36 CHAPTER 2 
algorithm does not exist in reality, it can be used for comparing the performance of real algorithms against the best possible one. 

Guarantee-based algorithms 
In hard real-time applications that require highly predictable behavior, the feasibility of the schedule should be guaranteed in advance; that is, before task execution. In this way, if a critical task cannot be scheduled within its deadline, the system is still in time to execute an alternative action, attempting to avoid catastrophic consequences. In order to check the feasibility of the schedule before tasks' execution, the system has to plan its actions by looking ahead in the future and by assuming a worst-case scenario. 
In static real-time systems, where the task set is fixed and known a priori, all task activations can be precalculated off-line, and the entire schedule can be stored in a table that contains all guaranteed tasks arranged in the proper order. Then, at runtime, a simple dispatcher simply removes the next task from the table and puts it in the running state. The main advantage of the static approach is that the run-time overhead does not depend on the complexity of the scheduling algorithm. This allows very sophisticated algorithms to be used to solve complex problems or find optimal scheduling sequences. On the other hand, however, the resulting system is quite inflexible to environmental changes; thus, predictability strongly relies on the observance of the hypotheses made on the environment. 
In dynamic real-time systems, since new tasks can be activated at runtime, the guarantee must be done on-line every time a new task enters the system. A scheme of the guarantee mechanism typically adopted in dynamic real-time systems is illustrated in Figure 2.12. 
scheduling 
YESactivation 

__ acceptance t~t 
NO---' 


Figure 2.12 Scheme of the guarantee mechanism used in dynamic hard realtime systems. 
Basic Concepts 
J new 
--~1-"""""'+-•--'--l ____ ,.. t 

J I ~
tJ
------1»-=~---"'~ ...... ----'11-----------:,, t 
-~~: -----,-----u"""""'-'-: l
---1--------------------:,, 
----f=l'I~=------: -+--1 I
--.------""""u""'"'"-., _.,. 
__.~__ :_~ ____ _......._[.__J__._..__.., t 
t 0 
Figure 2.13 Example of domino effect. 

If J is the current task set that has been previously guaranteed, a newly arrived task Jnew is accepted into the system if and only if the task set J' = Ju { Jnew} is found schedulable. If J' is not schedulable, then task Jnew is rejected to preserve the feasibility of the current task set. 
It is worth to notice that, since the guarantee mechanism is based on worst-case assumptions, a task could unnecessarily be rejected. This means that the guarantee of hard tasks is achieved at the cost of reducing the average performance of the system. On the other hand, the benefit of having a guarantee mechanism is that potential overload situations can be detected in advance to avoid negative effects on the system. One of the most dangerous phenomena caused by a transient overload is called domino effect. It refers to the situation in which the arrival of a new task causes all previously guaranteed tasks to miss their deadlines. Let us consider for example the situation depicted in Figure 2.13, where tasks are scheduled based on their absolute deadlines. 
At time to, if task lnew was accepted, all other tasks (previously schedulable) would miss their deadlines. In planned-based algorithms, this situation is detected at time t0 , when the guarantee is performed and causes task Jnew to be rejected. 
In summary, the guarantee test en:sures that, once a task is accepted, it will complete within its deadline and, moreover, its execution will not jeopardize the feasibility of the tasks that have been previously guaranteed. 
38 CHAPTER 2 

Best-effort algorithms 
In certain real-time applications, computational activities have soft timing constraints that shou1d be met whenever possible to satisfy system requirements, however, no catastrophic events will occur if one or more tasks miss their deadlines. The only consequence associated with a timing fault is a performance degradation of the system. 
For example, in typical multimedia applications, the objective of the computing system is to handle different types of information (such as text, graphics, images, and sound) in order to achieve a certain quality of service for the users. In this case, the timing constraints associated with the computational activities depend on the quality of service requested by the users; hence, missing a deadline may only affect the performance of the system. 
To efficiently support soft real-time applications that do not have· hard timing requirements, a best-effort approach may be adopted for scheduling. A besteffort scheduling algorithm tries to "do its best" to meet deadlines, but there is no guarantee of finding a feasible schedule. In a best-effort approach, tasks may be queued according to policies that take time constraints into account; however, since feasibility is not checked, a task may be aborted during its execution. On the other hand, best-effort algorithms perform much better than guarantee-based schemes in the average case. In fact, whereas the pessimistic assumptions made in the guarantee mechanism may unnecessarily cause task rejections, in best-effort algorithms a task is aborted only under real overload conditions. 

Algorithms based on imprecise computation 
The concept of imprecise and approximate computation has emerged as a new approach to increasing flexibility in dynamic scheduling by trading off computation accuracy with timing requirements [Nat95, LNL87, LLN87, LLS+91, L +94). In dynamic situations, where the time and resources are not enough for computations to complete within the deadline, there may still be enough resources to produce approximate results that may at least prevent a catastrophe. The idea of using partial results when exact results cannot be produced within the deadline has been used for many years. Recently, however, this concept has been formalized, and specific techniques have been developed for designing programs that can produce partial results. 
Basic Concepts 
In a real-time system that supports imprecise computation, every task Ji is decomposed into a mandatory subtask Mi and an optional subtask Oi-The mandatory subtask is the portion of the computation that must be done in order to produce a result of acceptable quality, whereas the optional subtask refines this result [SLCG89). Both subtasks have the same arrival time ai and the same deadline di as the original task Ji; however, Oi becomes ready for execution when Mi is completed. If C; is the computation time associated with Ji, subtasks Mi and Oi have computation times mi and oi, such that m; + Oi = Ci. In order to guarantee a minimum level of performance, A1i must be completed within its deadline, whereas Oi can be left incomplete, if necessary, at the expense of the quality of the result produced by the task. 
It is worth to notice that the task model used in traditional real-time systems is a special case of the one adopted for imprecise computation. In fact, a hard task corresponds to a task with no optional part (oi = 0), whereas a soft task is equivalent to a task with no mandatory part (mi = 0). 
In systems that support imprecise computation, the error €i in the result produced by Ji (or simply the error of J;) is defined as the length of the portion of Oi discarded in the schedule. If ai is the total processor time assigned to Qi by the scheduler, the error of task J; is equal to 
€; = o; -u;. 

The average error t on the task set J is defined as 
n 
l= LWi€i, 
i=l 

where w; is the relative importance of Ji in the task set. An error €i > 0 means that a portion of subtask 0; has been discarded in the schedule at the expense of the quality of the result produced by task J; but for the benefit of other mandatory subtasks that can complete within their deadlines. 
In this model, a schedule is said to be feasible if every mandatory subtask Mi is completed in the interval [ai, di]-A schedule is said to be precise if the average error 'l on the task set is zero. In a precise schedule, all mandatory and optional subtasks are completed in the interval [ai, di]. 
As an illustrative example, let us consider the task set shown in Figure 2.14a. Notice that this task set cannot be precisely scheduled; however, a feasible schedule with an average error of 'l = 4 can be found, and it is shown in Figure 2.14b. In fact, all mandatory subtasks finish within their deadlines, 
40 CHAPTER 2 
a-I  d·I  C·I  m·I  O· I  
J I J2 J3 14 15  0 2 4 12 6  6 7 10 15 20  4 4 5 3 8  2 I 2 I 5  2 3 3 2 3  

(a) 
J I 
l 
:,, t 

J2 t ■ { :,, 
t 
J3 
t i 
.Jo t 
J4 





}a { 

:,.  t  
J5  l  I  ),  t  
0  2  4  6  8  10  12  14  16  20  
(b)  
Figure  2.14  An example  of an  imprecise  schedule.  
whereas  not  all optional  subtasks  are  able to complete.  In particular,  a time  

unit of execution is subtracted from 0 1 , two units from 0 3 , and one unit from Os. Hence, assuming that all tasks have an importance value equal to one (wi = 1), the average error on the task set is t = 4. 
2.3.2 Metrics for performance evaluation 
The performance of scheduling algorithms is typically evaluated through a cost function defined over the task set. For example, classical scheduling algorithms try to minimize the average response time, the total completion time, the weighted sum of completion times, or the maximum lateness. When deadlines 
Basic Concepts 
Average response time: tr = Total completion time: tc = m~(fi) -mjn(ai) i i Weighted sum of completion times: n tw = LWdi i=l Maximum lateness: Maximum number of late tasks: n Ntate = L miss(h) i=l where 0 if f-< d· miss(fi) = { 1 oth~t~is~  

Table 2.1 Example of cost functions. 

are considered, they are usually added as constraints, imposing that all tasks must meet their deadlines. If some deadlines cannot be met with an algorithm A, the schedule is said to be infeasible by A. Table 2.1 shows some common cost functions used for evaluating the performance of a scheduling algorithm. 
The metrics adopted in the scheduling algorithm has strong implications on the performance of the real-time system [SSDB95J, and it must be carefully chosen according to the specific application to be developed. For example, the average response time is generally not of interest for real-time applications hecause there is not direct assessment of individual timing properties such as 
42 CHAPTER 2 
di d2 d3 d4
lLI =3 lL2 =2 



(a) J I 
0 2 4 6 8 10 12 14 16 Ill 20 22 24 26 
,.. 
Lma>t= LI =3 
di d2 d3 d4 d5 tLl=2.1 lL2 = -4 lL3 =-S lL4 =-S lLS= -4 

(b) J I 
() 2 4 6 8 IO 12 14 16 18 20 22 24 26 
Lmax = LI = 23 

Figure 2.15 The schedule in a minimizes the maximum lateness, but all tasks miss their deadline. The schedule in b has a greater maximum lateness. but four tasks out of five complete before their deadline. 
periods or deadlines. The same is true for minimizing the total completion time. The weighted sum of completion times is relevant when tasks have different importance values that they impart to the system on completion. Minimizing the maximum lateness can be useful at design time when resources can be added until the maximum lateness achieved on the task set is less than or equal to zero. In that case, no task misses its deadline. In general, however, minimizing the maximum lateness does not minimize the number of tasks that miss their deadlines and does not necessarily prevent one or more tasks from missing their deadline. 
Let us consider, for example, the case depicted in Figure 2.15. The schedule shown in Figure 2.15a minimizes the maximum lateness, but all tasks miss their deadline. On the other hand, the schedule shown in Figure 2.15b has a greater maximum lateness, but four tasks out of five complete before their deadline. 
When tasks have soft deadlines and the application concern is to meet as many deadlines as possible (without a priori guarantee), then the scheduling algorithm should use a cost function that minimizes the number of late tasks. 
Basic Concepts 
v(f;) 
Non real-time 

(· I
fj 
di 
(a) (b) 
v(f;) f • 
f; 
1 
di 
(C) (d) 
Figure 2.16 Example of cost functions for different types of tasks. 

In other applications, the benefit of executing a task may depend not only on the task importance but also on the time at which it is completed. This can be described by means of specific utility functions, which describe the value associated with the task as a function of its completion time. Figure 2.16 illustrates some typical ut.ility functions that can be defined on the application tasks. For instance, non-real-time tasks (a) do not have deadlines, thus the value achieved by the system is proportional to the task importance and does not depend on the completion time. Soft tasks (b) have noncritical deadlines; therefore, the value gained by the system is constant if the task finishes before its deadline but decreases with the exceeding time. In some cases (c), it is required to execute a task on-time; that is, not too early and not too late with respect to a given deadline. Hence, the value achieved by the system is high if the task is completed around the deadline, but it rapidly decreases with the absolute value of the lateness. In other cases (d), executing a task after its deadline does not cause catastrophic consequences, but there is no benefit for the system, thus the utility function is zero after the deadline. 
When utility functions are defined on the tasks, the performance of a scheduling algorithm can be measured by the cumulative valu,e, given by the sum of the utility functions computed at each completion time: 
Cumulative_value =Ln v(fi)i=l 




44 CHAPTER 2 
This type of metrics is very useful for evaluating the performance of a system during overload conditions, and it is considered in more detail in Chapter 8. 

2.4 SCHEDULING ANOMALIES 
In this section we describe some singular examples that clearly illustrate that real-time computing is not equivalent to fast computing, and an increase of computational power in the supporting hardware does not always cause an improvement on the performance of a task set. These particular situations, called Richard's anomalies, have been described by Graham in 1976 and refer to task sets with precedence relations executed in a multiprocessor environment. Designers should be aware of such insidious anomalies so that they can avoid them. The most important anomalies are expressed by the following theorem [Gra76, SSDB95]: 
Theorem 2.1 (Graham) // a task set is optimally scheduled on a multiprocessor with some priority assignment, a fixed number of processors, fixed execution times, and precedence constraints, then increasing the number of prow cessors, reducing execution times, or weakening the precedence constraints can increase the schedule length. 
This result implies that if tasks have deadlines, then adding resources (for example, an extra processor) or relaxing constraints (less precedence among tasks or fewer execution times requirements) can make things worse. A few examples can best illustrate why this theorem is true. 
Let us consider a task set composed by nine tasks J = {J1 , J2, ... , Jg}, sorted by decreasing priorities, so that Ji priority is greater than Ji priority if and only if i < j. Moreover, tasks are subject to precedence constraints that aredescribed through the graph shown in Figure 2.17. Computation times are indicated in parentheses. 
If the above set is executed on a parallel machine with three processors, weobtain the optimal schedule c,• illustrated in Figure 2.18, where the global completion time is tc =12 units of time. 
Now we will show that adding an extra processor, reducing tasks' execution times, or weakening precedence constraints will increase the global completion time of the task set. 
Basic Concepts 
0 
J I (3) J 9 (9) J 8 (4) 
J 2 (2) 

priority(J i ) > priority(] i ) "i i < j 

Figure 2.17 Precedence graph of the task set J; numbers in parentheses indicate computation times. 

J 8 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 

Figure 2.18 Optimal schedule of task set J on a three-processor machine. 
46 CHAPTER 2 

0 2 3 4 5 6 7 8 9 10 II 12 13 14 15 Figure 2.19 Schedule of task set J on a. four-processor machine. 
P1 J I J 5 

0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
Figure 2.20 Schedule of task set J on three processors. with computation times reduced by one unit of time. 

Number of processors increased 
If we execute the task set J on a more powerful machine consisting of four processors, we obtain the schedule illustrated in Figure 2.19, which is characterized by a global completion time of tc = 15 units of time. 

Computation times reduced 
One could think that the global completion time of the task set J could be improved by reducing tasks' computation times of each task. However, we can surprisingly see that if we reduce the computation time of each task by one unit of time, the schedule length will increase with respect to the optimal s<:hedule ~•, and the global completion time will be tc = 13, as shown in Figure 2.20. 
Basic Concepts 
J I (3) J 9 (9) 0 J 8 (4) 
J 2 (2) 
0 
0 J 7 (4) 
J 3 (2) 
0 
J 6 (4) J4 (2) J 5 (4) 
(a) 


0 2 3 4 5 6 7 8 9 10 II 12 13 14 15 16 
(b) 

Figure 2.21 a. Precedence graph of task set J obtained by removing the constraints on tasks ls and 16-b. Schedule of task set J on three processors. with precedence constraints weakened. 
Precedence constraint.s weakened 
Scheduling anomalies can also arise if we remove precedence constraints from the directed acyclic graph depicted in Figure 2.17. For instance, if we remove the precedence relations between task 14 and tasks 15 and J6 (see Figure 2.21a), we obtain the schedule shown in Figure 2.21b, which is characterized by a global completion time of tc = 16 units of time. 
48 CHAPTER 2 
J I 
P2 

0 2 4 6 8 10 12 14 16 18 20 22 


0 2 4 6 8 10 12 14 16 18 20 22 
(b) le= 22 

Figure 2.22 Example of anomaly under resource constraints. If h and J4 share the same resource in exclusive mode, the optimal schedule length (a) increases if the computation time of task J 1 is reduced (b ). Task are statically allocated on the processors. 


Anomalies under resource constraints 
As a last example of scheduling anomalies, we will show how the schedule length of a task set can increase when reducing tasks' computation times in the presence of shared resources. Consider the case illustrated in Figure 2.22, where five tasks are statically allocated on two processors: tasks 11 and h on processor Pl, and tasks h, ]4 and 15 on processor P2. Moreover, tasks h and 14 share the same resource in exclusive mode, hence their execution cannot overlap in time. A schedule of this task set is shown in Figure 2.22a, where the total completion time is tc = 17. 
If we now reduce the computation time of task 11 on the first processor, then 12 can begin earlier and take the resource before task 14 . As a consequence, task 14 must now block over the shared resource and possibly miss its deadline. This situation its illustrated in Figure 2.22b. As we can see, the blocking time experienced by 14 causes a delay in the execution of 15 (which may also miss its deadline), increasing the total completion time of the task set from 17 to 22. 
Basic Concepts 
Notice that the scheduling anomaly illustrated by the previous example is particularly insidious for hard real-time systems because tasks are guaranteed based on their worst-case behavior, but they may complete before their worstcase computation time. A simple solution that avoids the anomaly is to keep the processor idle if tasks complete earlier, but this can be very inefficient. There are algorithms, such as the one proposed by Shen [SRS93], that tries to reclaim this idle time, while addressing the anomalies so that they will not occur. 
Exercises 
2.1 Give the formal definition of a schedule, explaining the difference between preemptive and non-preemptive scheduling. 
2.2 Explain the difference between periodic and aperiodic tasks, and describe the main timing parameters that can be defined for a real-time activity. 
2.3 Describe a real-time application as a number of tasks with precedence relations, and draw the corresponding precedence graph. 
2.4 Discuss the difference between static and dynamic, on-line and off-line, optimal, and heuristic scheduling algorithms. 
2.5 Provide an example of domino effect, caused by the arrival of a task J•, in a feasible set of three tasks. 
[Design] 
Informatics and Mathematical Modelling HHL 97–12–20 
Technical University of Denmark Building 321 DK–2800 Lyngby Denmark 
Hans Henrik Løvengreen: 

Design of Reactive Programs 
Version 1.2 
Summary 

In this note, an approach to design of reactive programs is presented. The method is based on the events that occur between the program (system) and its environment. The events are temporally ordered in order to identify the main processes of the system. Finally, a design consisting of an abstract program is produced. This design may then be analyzed before a final implementation is made. 
Contents 

1 Introduction 1 
2 System identification 1 
2.1 Documentation ..................................... 3 
3 System structuring 4 
3.1 Event sequences ..................................... 4 
3.2 Finding event sequences ................................ 7 
4 Program Structuring 8 
4.1 An abstract programming language .......................... 8 
4.2 Transformation into abstract programs ........................ 10 
4.3 Adding data flow .................................... 11 
c 1997–2001 Hans Henrik Løvengreen 
1 Introduction 
A reactive program responds to external stimuli over time. Such programs typically appear in embedded systems monitoring and controlling a number of external physical devices. 
Reactive systems are often implemented as concurrent programs. The design method presented in this note aims at reaching an abstract design consisting of a number of components interacting with each other. The components may be active ones representing processes or passive ones representing shared data stores (monitors). 
Given an informal requirements specification, the method defines three steps in order to reach a design: 
1. 
System identification The program system is identified by finding the events linking the system and its environment. These events by definition consitute the interface between the system and its environment. The events may be divided into input and output events. Also events are typed to indicate the information they carry. 

2. 
System structuring In this step, the behaviour of the system is characterized. This is done by identifying temporal orders among the system events. The orderings are described in a terse textual notation. This results in a number of event sequences each corresponding to a sequential flow of events. The behaviour expressions are by default put in parallel at the outermost system level, and thus they identify the processes of the system. 

3. 
Program structuring In this step, the event sequences are refined into (CSP-like) abstract programs. During this process, the information flow in the system is determined, and possible monitor components are identified. 


Having reached a design, it is now possible to analyze the system. This may include its functionality (does it work correctly?) or its implementability. Such analysis is outside the scope of this note. 
Implementation of the abstract model is not yet part of this note. Given a basic knowledge concurrent programming techniques, it should cause no problems to reach an implementation in a current programming language, eg. Java or Ada. 
Often embedded systems involve real-time requirements to be satisfied. In this note, it is assumed that the program takes no significant time to react. A further analysis of schedulability is out of the scope of this note. 
The method presented in this note is largely based upon ideas developed by A.P. Ravn, Hans Rischel and Benny Mortensen [RMR87]. 
2 System identification 
By a system, we generally understand a structured collection of entities of a given universe to be considered as a whole. The system boundary divides the universe into thoses entities which are part of the system, and those belonging to the rest of the universe, the environment of the system. The system entities are often called components. 
1 

In the first step of the method, the system boundary is found by identifying the (interface) events that take place between the system and its environment. 
An event is the abstraction of an interaction, ie. an activity involving more than one component. By modelling the interaction as an event, we consider the activity to be atomic: Either the activity results in an overall e ect, or there is no e ect at all. 
For instance, the input of data from a user may involve setting up dialog boxes etc., but only when the user clicks the OK-button, the activity is considered an event. 
Events are abstract entities and need not correspond to physical events like raising the voltage on a line or pressing a button. 
Any timing period should be considered an interface event by it own. This way, the system will become event driven: the system will not act spontaneously, only as reaction to events. 
The proper choice of events that suit the purpose of designing the system is often diÿcult. A guideline is to make events correspond to the activities that the system user would like to consider atomic. 
A technique to find candidates for events is to mark the active verbs of the informal system requirements specification. These may then be analyzed to see whether they correspond to external activities, interface events, or internal activities. 
The events may be partitioned into input events and output events. An input event carry information from the environment to the system and/or is (as least partly) under the control of the environment. An output event carry information from the system to the environment and is often under the total control of the system. The distinction between input and output may, however, not always be clear. 
Data Types 
Events are typed. Each event has an associated data type which represents the information exchanged during the event. Often events are simple signal not carrying other information than the fact that they take place. 
Any well-defined type system could be used for typing events, such as the ML-type system, or types of specification languages such as VDM or Z. 
Here we propose a traditional type system comprising simple types: 
NUMBER  Some number.  
TOKEN  Some unique code.  
{id1, . . . , idn }  Enumeration of distinct symbolic values.  
VOID  Unit type with only one value: () .  
and composite types:  
T1 × . . . × Tn  Cartesian product (record, structure).  
T1| . . . |Tn  Union.  
T − LIST  List of T-elements.  
T − SET  Set of T-elements.  

where the Ts are types. In this note, we shall not dwell upon issues such as type equivalence, subtyping etc. 
2 

2.1 Documentation 
The interface events identified may be documented in an event list which for each event defines its direction (input or output), its data type (perhaps not yet defined), and its legend. 
Futhermore, the relation of events to the environment may be shown in a system diagram showing the units in the environment and the events that link them to the system. 
Example (Taximeter) 
Consider the following informal specification of a simple taximeter: 
The taximeter can be switched on and o . When being switched on, the amount due shown on a display must be reset. While the taximeter is switched on, the amount should be incremented each minute as well as for each 100 meter signal received from the wheels. When switched o , the final amount remains on the display. When a ”KM”-button is pressed, the total distance covered with the taximeter switched on must be shown for 10 seconds on a separate display. 
We start by underlining the active verbs in order to find candidates for events: 
The taximeter can be switched on and o . When being switched on, the amount due shown on a display must be reset. While the taximeter is switched on, the amount should be incremented each minute as well as for each 100 meter signal received from the wheels. When switched o , the final amount remains on the display. When a ”KM”-button is pressed, the total distance covered with the taximeter switched on must be shown for 10 seconds on a separate display. 
We find that most of the marked verbs correspond directly to interface events. However, the reset and incrementation of the amount are internal acitivities whose result can be presented to the user by a common show event. Furthermore, since we assume that the display will not change if not asked to, the requirement that the amount remains, can be accomplished by lack of show events. 
The events are naturally divided into input and output events as follows: EVENT LIST: 
Input event Data type Legend 
On VOID Taximeter is switched on. O VOID Taximeter is switched o . 100m VOID Signal for each 100 meter. KM VOID KM-button pressed. Min VOID Regular signal from minute-clock. 10s VOID Signal 10 sec. after Start10sec. 
3 

Output event  Data type  Legend  
Show  NUMBER  Show number on amount display.  
ShowKm  NUMBER  Show number on distance display.  
ClearKm  VOID  Clears distance display.  
Start10s  VOID  Request for 10 sec. signal.  

We assume that there is a minute-clock that ticks with regularly with a one minute period. If it is desired to synchronize this clock, a StartMin signal could be introduced. For the 10-second clock, we presume that it will signal once 10 seconds after Start10s. 
Finally, we present a system diagram for the taximeter: 


3 System structuring 
In order to determine the system structure, the events are partially ordered according to the sequence in which they should occur in any system behaviour. For this, we use event sequences which characterize independent sequential behaviours of the system. Each independent event sequence gives rise to a major process of the program. 
3.1 Event sequences 
The syntax of event sequence expressions is given by: 
&#3; 

s ::= e | int | [ s ] | s | s1; s2 | s1 [] s2 | s1 k s2 
Here e represents an event, and each s represents an event sequence. 
An event sequence expression describes a behaviour according to the following informal semantics: 
e Event. Represents the occurrence of an event e. 
int Internal. Represents the occurrrence of an anonymous internal event. 
4 

[ s ]  Option.  May behave like s or may internally choose to skip s.  
&#3;s Repetition.  Behaves as s  any number of times.  May terminate at the start of each  
iteration.  

s1; s2 Sequential composition. Behaves first like s1 and then like s2. 
s1 [] s2 Choice. Behaves like s1 or s2 depending on the first events of these. 
s1 k s2 Parallel composition. Behaves like s1 and s2 in parallel. That is, the behaviour of s1 
takes place concurrently with that of s2 except for common events of s1 and s2 which 
must be synchronized. Terminates when both s1 and s2 have terminated. 
Event sequences may be given names using definitions of the form: 
name = s 

Recursively defined event sequences are permitted and may be used in cases where the structure imposed by repetition may be too restrictive. 
Syntax 

The above grammer defines the abstract structure of event sequence expressions. When writing down such expressions, parentheses are used to resolve the ambiguity. However, in order to avoid lots of parentheses, we adopt the convention that the operators binds in the following order: 
&#3; 
; [] k 

where &#3; binds strongest. Eg. the expression: 
A; B&#3; ; C [] C ; D k E 

is understood as ((A;(B)&#3; ; C ) [] (C ; D)) k E 
Semantics 

As semantic model for event sequences, we use a kind of automata or transition system. An event transition graph is directed graph whose edges may be labelled with events. Unlabelled edges correspond to internal events. Each node of the graph correspond to a state of the system. One of the nodes is marked as the initial state. The transition graph represents an abstract device (or machine) which may execute by performing events in cooperation with its environment or by performing internal events by itself. 
In any state represented by a certain node, the system is willing to engage in any event labelling an outgoing edge. Such events are said to be enabled. We may think of the machine as having a button for each event. When an event is enabled, the corresponding button lights up. Now the environment may select and press a lit button. Hereby the machine will move along the edge labelled by that event. If there are several edges labelled with the event, one of them will be chosen by the machine. Now the machine has entered a new state, and a new set of events will be enabled. If a state has one or more unlabelled outgoing edges, the machine has the right to, but no obligation to, chose one of these by itself. 
As an example of an event transition graph consider the following: 
5 
H 


The initial state is marked by an arrow. This graph describes a machine that will initially perform the event A. After that, it may engage in B, or it may internally decide to abondon B in which case it will perform F. If, on the other hand, B is taken, it will be willing to engage in any number of C followed by D sequences. However, inbetween these, also the event E is enabled, and if the environment choses this, only the event G followed by H are possible, after which the machine is back in its initial state. 
We would like this event transition graph to be the meaning of the event sequence 
(A;(B;(C ; D)&#3; ; E [] int; F); G; H )&#3; 
In general, we would like to defi ne the semantics of an event sequence by generating a transition graph. To do this, we need to combine such graphs. For this purpose, it should be possible to mark nodes in transition graphs as terminated, indicating a state where the current behaviour may end. Here we indicate terminated nodes by small open circles. Furhtermore, let −s → denote the graph generated for s where − represent all the edges leaving the initial state, and 
→ represent all the edges leading to thefi nal node. Now, the graph corresponding to an event sequence can be defi ned as follows: 
e 
e
int 


s1 ; s2 
s1 
s2 

The graph of [ s ] is given by the defi nition: 
&#1; 
[ s ] =(s [] int) 

6 
The graph of s1 k s2 is given by interleaving of the graphs of s1 and s2. Normally, however, we are only interested in the graphs of (almost) sequential event sequences. 
From the graph semantics we see that a repetition of, say, an event A can be terminated externally by another event B expressed by A&#3; ; B or terminated internally (eg. modelling a counter reaching some value) expressed by A&#3; ; int. 
3.2 Finding event sequences 
When ordering the events of a system, we aim at having a number of sequential processes running in parallel at the outermost level since this will give the most e ective implementation in most langauges. Thus, we initially try to identify a number of (largely) independent sequential event orderings. 
It is important to stress that the event sequences should describe the meaningful dialogues between the system and the environment. This means that events should appear only in situations where they make sense even though they may occur physically at other times. 
A technique to find such a set of independent behaviour expressions is to proceed as follows: 
1. 
First, only the input events are considered. The inputs events may be compared pairwise and it may be determined whether they are should appear sequentially (;), as alternatives ([]), together in some order (), or whether they are (largely) independent. In the latter case, they are put in separate event sequences. 

2. 
Repetition and perhaps internal events are added to the event sequences. 

3. 
Finally the output events can be inserted after the input events they are caused by. 


This results in a number of independent event sequences which may at last be combined in parallel to make up the total system. 
To be honest, the independent event sequence expression may sometime be only “almost sequential”. The reason being that when adding the output events, we often find that two of these may occur in either order. Rather than making an arbitrary choice, we may put them in parallel and leave it to the implementation phase to find a proper order. 
Sometimes, two (or more) event sequences should synchronize by participating in a common internal activity. In order to reflect this, new named internal events may be introduced and used in several event sequences. 
Example (Taximeter continued) 
Looking at the input events we find that O should follow On. Furthermore, the Min event and 100m only make sense, when the taximeter is switched on, ie. inbetween On and O . Furthermore, Min and 100m may occur at the same places with the same e ect, and thus they are naturally seen as alternatives. The KM event may occur at any time, but the 10s signal only makes sense when showing the distance. Adding repetition, this leaves us with two independent event expressions: 
7 

(On;(Min [] 100m)&#3; ; O )&#3; 
(KM ; 10s)&#3; 
Adding the output events and naming the independent sequences, we get: 
count =(On; Show; ((Min [] 100m); Show)&#3; ; O )&#3; 
inform =(KM ;(Start10s k ShowKm); 10s; Clear)&#3; 
Finally, the two expressions are combined in parallel: 
taximeter = count k inform 
Thus, the taximeter should comprise two concurrent processes. 
4 Program Structuring 
The purpose of this design step is first of all to identify the dataflow in the system and to introduce the data stores needed. These may either be local to a proces taking the form of usual variables, or they may be shared between processes. 
The result of this analysis is documented by an abstract program written in a general process language. Here we choose a CSP-like language where processes communicate over synchronous channels corresponding to the system events. The processes do not share variables. Shared data components are represented by server-like processes called state monitors. 
The rationale of using CSP is that this model clearly separates local computation from interchange of information. The model may readily be implemented in both monitor-based as well as communication-based programming languages. 
4.1 An abstract programming language 
Our CSP-like proces langauge has the following syntax: 
p ::= a | skip | g → p | do p od | exit | 
p1; p2 | p1 [] p2 | p1 k p2 | 
var x : T | chan c : T 

a ::= x := e | c ! e | c ? x g ::= b | c ! e | c ? x | g1, g2 
Here p is a proces, a an action, g a guard, c a channel, x a variable, e an expression, b a boolean expression and T a type. 
8 
Processes 

Processes performs (atomic) actions. The behaviour of a process expression is informally given 
by: 

a Action. Process which performs the action a and then terminates. 
skip Skip. Process that cannot perform any action and just terminates. 
g → p Guarded process. Process which which first passes the guard g and then behaves like the process p. The guard may declare variables whose scope is p. 
do p od Loop. Process which repeatedly performs p. May be terminated by execution af an exit in p. 
exit Exit. Exits the innermost enclosing loop. 
p1; p2 Sequential composition. Process which first behaves like p1. When p1 terminates, it behaves like p2. 
p1 [] p2 Choice. Process which may behave like p1 or p2, depending on the first actions of these. If these are communications, the choice is determined by the current communication capabilities. 
p1 k p2 Parallel composition. Process which behaves like p1 in parallel with p2. Terminates, when both p1 and p2 terminate. Matching communications between p1 and p2 are synchronized. 
var v : T Variable declaration. Declares a variable x of type T. The scope of x is defined to be the rest of the (sequentially composed) process list in which the declaration occurs. 
chan c : T Channel declaration. Declares a channel c over which values of type T may be communicated. The scope of c is defined to be the rest of the (sequentially composed) process list in which the declaration occurs. 
A process which is constructed without parallel composition is called a sequential process. 
Actions 

An action is an atomic activity. An action may either be internal or it may generate a communication event. 
x := e Assignment. Evaluates the value of e and assigns it to x. 
c ! e Output. Evaluates e and outputs it on channel c. 
c ? x Input. Inputs a value from channel c and assigns it to the variable x. The variable x is implicitly declared by the construct. 
The communication is synchronous (as in CSP [Hoa78]), that is, an output action c ! e will wait until a matching input action c ? x can take place in a concurrent process. 
9 
Guards 

A guard is an condition which must be passed before the process can proceed. A guard may be a boolean guard, an input/output guard, or a combination of these. All parts of a guard must be passed atomically for the guard to be passed. A boolean guard is passable only if it evaluates to true. An input/output guard is passed by performing the communication. 
Note: The syntax and semantics allow for several input/outputs to be passed atomically, but this may be hard to implement. 
Types and expressions 
For types we may use the same types as for events, but maybe extended with more concrete types such as Int or Real. We asssume the existence of a standard (mathematical) notation for expressions, that expressions are well-typed, and that no expression evaluation will fail. 
Definitions 

As for event sequence expressions, we may define names for processes and use these. Futhermore processes may be recursively defined. 
Conventions 
We introduce a few convention in order to facilitate writing and reading of abstract programs: 
• As for event sequence expressions, we introduce the convention that the operators bind in the following order (strongest first): 
; → [] k 

When this is not appropiate, we use parentheses or square brackets to indicate the intended structure. Since ;, [], k are associative, we may consider these to apply to lists of processes. 
• 
If the type of a channel is VOID, input and output are just written as c ? and c !. 

• 
Variables may be initialized: var x : T := e corresponding to var x : T; x := e. 


4.2 Transformation into abstract programs 
As can be seen, the syntax of abstract programs resemble that of event sequences. In fact, each independent event sequence can be transformed into an abstract program skeleton by the following modfications: 
• Events are replaced by communications. For each event e, a channel with the same name and type as the event is implicitly declared. Now, each input event I is is refined into an input action: 
I ? x 

and each output event O is refined into an output action: 
O ! e 
10 

• 
Seqential composition of events carry over to processes. 

• 
Likewise for choices. However, the presence of a choice (typically between input events) is usually emphasized by using the communications as guards. For instance, I1; ... [] I2; ... is transformed into: 


[I1 ? x1 → ... [] I2 ? x2 → ...] 
&#3;

• Repetion s is generally replaced by a loop: 
do ps od 

where ps is the transformation of s. 
&#3;

However, whereas termination of s may occur implicly at the start of each iteration, termination of the do loop must be programmed explicitly. If a repetition is terminated by an event (typically an input event) this event must be considered as a possibility at the start of each iteration. If, for instance, the event sequence is (I1; ...)&#3; ; I2, a choice between I1 and I2 must be made at the start of each iteration. If I2 occurs, the loop is left: 
do 
I1 ? x → ... [] I2 ? x → exit od 
If the repetition is terminated by an internal event, this must be transformed into a concrete exit condition. For instance, (I1; ...)&#3; ; int should be transformed into: 
do 
I1 ? x → ... [] 
b → exit od 
where b is some boolean termination condition. 
• 
Parallel composition of output events within an event sequence may be resolved into a specific order. 

• 
Outermost parallel composition of event sequences carry over to the corresponding processes. 


4.3 Adding data flow 
Having generated the abstract program skeleton processes, we now look for data sources for output data. In general, the data needed by an output O ! in some process may have three sources. 
• 
The data may be found as a function f of a recently received data value still present in a local variable x. In this case, the output takes the form O ! f (x). 

• 
The data may be computed from the history of the process itself. In that case, a process-wide variable is introduced, updated in connection with the relevant events, and finally used in the output action. 

• 
The data may be computed using the history of one or more other processes. If so, a state monitor to hold the relevant information produced by the other process(es) is introduced. A state monitor is a passive process which may be operated upon by communicating with it over a set of internal channels. 


11 

If the output data still cannot be calculated, the system simply receives too little information to generate that output! Either more input events must be added, or the events must be processed in more situations. 
Structure diagram 
In order to illustrate the structure as well as the data flow in the system, a structure diagram may be drawn. The diagram should show the internal structure of the program, ie. the processes, the channels, the state monitors, and the external units. In the diagrams, we use circles to represent processes, rectangles to represent state monitors, hexagons to represent external units and arrows to represent internal and external channels. 
Example (Taximeter contd.) 
First, the abstract process skeletons are derived from the event sequences. We get two processes named after the corresponding event sequences. For the Count process, we should note that in each iteration, there are three possible next events: Min, 100m and the terminating O . This can be programmed as shown: 
Count = 
do 
On ?; Show ! ... ; 
do O ? → exit 
[] [Min ? → skip [] 100m ? → skip]; Show ! ... 
od od 
12 

The program illustrates the possibility of having nested choices. The transformation of Inform is straightforward: 
Inform = 
do 
KM ?; ShowKm ! ... ; Start10s !; 10s ?; 
od 

Now we look at the data flow. We see that we need to deliver output to Show and ShowKm. For Show we find that the amount can be calculated on basis of the events occurring in Count. Thus, we can make do with a local variable of the Count process accumulating the amount. 
For ShowKm we find that it cannot be calculated on basis of the events ocurring in Inform itself. But, luckily, it can be calculated from the events processed by Count, since it precisely processes 100m signals when the taximeter is switched on. 
Thus the Count proces has the information needed by Inform. Rather than having them communicate directly, we introduce an intermediate state monitor Dist which can update and deliver the total distance covered with the taximeter on. Communication with the state monitor can be done through channel DistIncr which should make it increment the distance, and channel DistGet which should deliver the current distance. 
This structure may be depicted in a structure diagram showing the processes, monitors and channels of the system: 

13 

Now, the process skeleton may be completed by adding the local variables, and the communications with the state monitor: 
Count = var amount : Real; do 
On ?; amount := StartFee; Show ! amount; 
do O ? → exit 
[] [Min ? → skip [] 100m ? → DistIncr ! ]; amount := amount + DeltaAmount; Show ! amount 
od od 

Inform = 
do 
KM ?; DistGet ? km; ShowKm ! km; Start10s !; 10s ?; 
od 

The Dist monitor itself is readily implemented: 
Dist = var km : Real := 0. 0; do 
DistIncr ? → km := km + 0. 1; [] DistGet ! km → skip od 

References 
[Hoa78] C.A.R. Hoare. Communicating sequential processes. Communication of the ACM, 21(8), August 1978. 
[RMR87] Hans Rischel, Benny Gra Mortensen, and Anders P. Ravn. Konstruktion af form°alsbundne systemer. Teknisk Forlag, 1987. (In Danish). 
14 





Hu~l g (R~~ 
LD~:( iI,.,. c.o,.__ q:>\jh s~ e.--~ 3 
C.C1.-~cto'loo<) Verification by 111odel checking pc.ts l'-t:Y-!~i 
3.1 Motivation for verification There is a great advantage in being able to verify the correctness of computer systems (whether they are hardware, software, or a combination). This is most obvious in the case of safety-critical systems, but also applies to those that are commercially critical, snch as mass-produced chips, mission critical, etc. Formal verification methods have quite recently become usable by industry and there is a growing demand for professionals able to apply them (witness recent job adverts by BT, Intel, National Semiconductor Corp, etc.). In this chapter, and the next one, we examine two applications of logics to the question of verifying the correctness of computer systems, or programs. 
(Formal) verification techniques can be thought of as comprising three parts: 
0 A fimnework for modelling systems, typically a description language or 
s0111e sort; 
e A specification language for describing the properties to be verified: 
o A verification method to establish whether the description of a system satisfies the specification. 
Approaches to verification can be classified according to the following criteria: 
Proof-based vs. model-based. ln a proof-based approach, the system description is a set of formulas r (in a suitable logic) and the specification is another formula 4,.The verification method consists of trying to find n proof that f' f-4,.This typically requires guidance and expertise from the user. 
[n a model-based approach, the system is represented by a finite 
148 

model JI resented b computing automatic, bility. 
In Chap often soun (semantic, models Ji, approach i is based or them. 
Degree of automa 
Extremes 2 assisted tee 
Full-vs. property-1 erty of the typically e: 
Intended domain o 
qnential or is one whic 
(e.g. opera 
Pre-vs. post-devel• early in the lier on in t Intel lost n 
FDIV erro 
This chapter co: terms of the abm based, property-ve reactive systems a currency bugs are of running several non-reproduceablc can help one to fi1 
By contrast, Cl which in terms oft property-verificati, we expect to term 
ang 
rrectness of computer Jination). This is most applies to those that ;, mission critical, etc. ,1e usable by industry J apply them (witness or Corp, etc.). In this ions of logics to the 
111s,or progrmns. 
• as comprising three 
,cription language of 
s to be verified; cription of a system 
ling to the following 
h, the system descripnd the specification is 1sists of trying to find tidance and expertise 
:presented by a finite 
3.1 Motivation for verification 
model JI for an appropriate logic. The specification is again represented by a formnla ef,and the verification method consists of computing whether a model JI satisfies ,p(Jt I=cf,).This is usually automatic, though the restriction to finite models limits the applicability. 
In Chapters 1 and 2, we could see that logical proof systems are often sound and complete, meaning that f' f--cf,(provability) iff f' I=cf, (semantic entailment), where the latter is 'defined as follows: for all models JI, if Jt I=f', then Jt I=ef,.Thus, we see that the model-based approach is potentially simpler than the proof-based approach, for it is based on a single model Jt rather than a possibly infinite class of them. 
Degree of automation. Approaches differ on how automatic the method is. Extremes are fully automatic and fully manual, with many computerassisted techniques somewhere in the middle. 
Full-vs. property-verificatio11.The specification may describe a single property of the system, or it may describe its full behaviour. The latter is typically expensive to verify. 
Intended domain of application, which may be hardware or software; sequential or concurrent; reactive or terminating; etc. A reactive system is one which reacts to its environment and is not meant to terminate 
(e.g. operating systems, embedded systems and computer hardware). 
Pre-vs. post-development.Verification is of greater advantage if introduced early in the course of system development, because errors caught earlier on in the production cycle are less costly to rectify. (Apparently, Intel lost millions of dollars by releasing their Pentium chip with the FDIV error.) 
This chapter concerns a verification method called model checking. In the terms of the above classification, model checking is an automatic, modelbased, property-verification approach. It is intended to be used for concurrent, reactive systems and originated as a post-development methodology. Concurrency bugs are among the most difficult to find by testing (the activity or running several simulations of important scenarios), since they tend to be non-reproduceable, so it is well worth having a verification technique that can help one to find them. 
By contrast, Chapter 4 describes a very different verification technique which in terms of the above classification is a proof-based, computer-assisted, property-verification approach. It is intended to be used for programs which we expect to terminate and produce a result. 

150 Vel'ificationby model checking 
Model checking is based on temporal logic. The idea of temporal logic is that a formula is not statically trne or false in a model, as it is in propositional and predicate logic. Instead, the models of temporal logic contain several states and a fonnnla can be trne in some states· and false in others. Tims, the static notion of trnth is replaced by a dynamic one, in which the formulas may change their trnth values as the system evolves from state to state. In model checking, the models vft are transition systems and the properties ¢ are formulas in temporal logic. To verify that a system satisfies a property. we must do three things: 
0 Model the system using the description language of a model checker. arriving at a model At. 0 Code the property using the specification language of the model checker. resulting in a temporal logic formula ¢. 0 Run the model checker with inputs vft and ¢. 
The model checker outputs the answer 'yes' if JI I=¢ and 'no' otherwise; in the latter case, most model checkers also produce a trace of system behaviour which causes this failure. This automatic generation of such 'counter traces' is an important tool in the design and debugging of systems. 
Since model checking is a model-based approach, in terms of the classification given earlier, it follows that in this chapter, unlike in the previous two, we will not be concerned with semantic entaihnent (r I= ¢ ), or with proof theory (I' 1-¢ ), such as the development of a natural deduction calculus for temporal logic. We will work solely with the notion of satisfaction, i.e. the satisfaction relation between a model and a fomrnla (At I=¢ ). 
There is a whole zoo of temporal logics that people have proposed and used for vaiious things. The abnndance of such formalisms may be organised by classifying them according to their patiicularview of'time'. Linear-time logics think of time as a chain of time instances, branching-timelogics offer several alternative future worlds at any given point of time; the latter is most useful in modelling non-deterministic systems or computations. Another quality of 'time' is whether we think of it as being continuous or discrete. The former would be suggested if we study an analogue computer, the latter might be preferred for a synchronous network. 
In this chapter, we study a logic where 'time' is branching and discrete. Such a logic has a modal aspect to it since the possible future paths of computations allow us to speak of 'possibilities' and 'necessities'; the study of such modalities is the focus of Chapter 5. The logic we now study is called computation tree logic (CTL), due to E. Clarke and E. A. Emerson. This logic has proven to be extremely fruitful in vetifying hardware and communication pre the ve1ification of s answer to the ques of some logic, .ft the underlying satis which we define in i 'system'. 
You should not c Models are abstract which are irrelevant that one does in ca pe1:fectcircles, or E very powerful, for t concern. 
Models of the kin advantage that we r science as having t a unified approach networks, software, states. They could b, language, or actual example, the states second kind of corn underlying computa terms of state transi, 
as a state transition same values for vari: than that of s. You variety of ways, bm entirety as a binary 
We write s -, s' to e from state s in one c 
The expressive p, is generally more ti For example, if we running on a single t of temporal logic , it is in propositional logic contain severa(' e in others. Thus, the' L which the fonnulas '. ·om state to state. In and the properties </i 1 satisfies a property, 
of a model checker, 
>f the model checker, 
.nd 'no' otherwise; in : of system behaviour 
such 'counter traces' ,terns. !rms of the classifica
in the previous two, 
•F <f,), or with proof eduction calculus for f satisfaction, i.e. the 
IIF<f,). veproposed and used may be organised by 1e'.Linear-time logics ,e logics offer several , latter is most useful 
s. Another quality of 
discrete. The former ·, the latter might be 
mching and discrete. ;ib]e future paths of tecessities'; the study gic we now study is and E. A. Emerson. ifying hardware and 
3.1 Motivation for verification 
•communication protocols; and people are beginning to apply it even to 'the verification of software. Model checking is the process of computing an answer to the question of whether JI, s F <f,holds, where <f,is a formula some logic, JI! an appropriate model, s a state of that model and F the underlying satisfaction relation. Of course, <f,is now a formula of CTL, which we define in a little while, and the model ✓ti is a representation of our 
'system'. 
You should not confuse such models .,II with an actual physical system. 
Models are abstractions that omit lots of real features of a physical system, 
which are irrelevant to the checking of <f,.This is similar to the abstractions 
that one does in calculus or mechanics. There we talk about straight lines, 
pe1:fectcircles, or an experiment without friction. These abstractions are 
very powerful, for they allow us to focus on the essentials of our particular 
concern. 
Models of the kind we have in mind are very general indeed. That has the advantage that we may think of a wide spectrum of structures in computer science as having the same type of model. So this allows us to develop a unified approach of model checking for the verification of hardware, networks, software, etc. The fundamental constituents of such models are states.They could be the current values of variables in a C-like programming language, or actual states of physical devices in a network architecture, for example, the states 'busy' and 'available' of some computing resource. The second kind of constituents of these models expresses the dynamics of the underlying computational process. Such dynamical behaviour is captured in terms of state transitions.Thus, one may think of an assignment statement 
X := x+ 1; 
as a state transition from state s to state s', where the latter state stores the same values for variables as s, but for x, in which it stores a value one bigger than that of s. You may think of the set of possible state transitions in a variety of ways, but it is best for our purposes to think of them in their entirety as a binary relation -> on the set of states S: 
--> £ S XS. 
We write s --> s' to express that it is possible for the system to reach state s' 
from state s in one computation step. 
The expressive power of such models stems from the fact that there is generally more than one possible successor state from a given state s. For example, if we have a °language with parallel assignment statements running on a single processor, then we expect to encounter multiple future 
Verffication by model checking 

computation paths depending on the actual scheduler of this parallel activity. See Figure 3.2 (later) for a pictorial representation of such a model. 
3.2 The syntax of comp11tation tree logic Computation tree logic, or CTL for short, is a temporal logic, having connectives that allow us to refer to the future. It is also a branching-time logic. meaning that its model of time is a tree-like structure in which the future is not determined; there are different paths in the future, any one of which might be the 'actual' path that is realised. We work with a fixed set of atomic fonnulas/descliptions (such as 
p, q, r, ... , or Pl, p2, ... ). These atoms stand for atomic descriptions of a system, like 
The printer is busy. 
or 
111ere are currently no requested jobs for the printer. 
or 
The current content of register Rl is the integer value 6. 

and the choice of atomic descriptions obviously depends on our particular interest in a system at hand. 
Definition 3.1 We define CTL formulas inductively via a Backus Naur form (as done for the other logics of Chapters 1 and 2): 
cf>::= _LI T IP I ( •'P)I (<f,I\ <p)I ( cf,V <p)I ( ef,-> cf>)I AX 'PI EX ef,I A[¢ U cf>]I E[r/> U r,b]I AG 4,I EG ¢ I AF rf,IEF ¢. where p ranges over atomic formulas/descriptions. 
Thus, the symbols T and J_ are CTL formulas, as are all atomic descriptions; ,</Jis a CTL formula if rf,is one, etc. We will look at the meaning of these formulas, especially the connectives that did not occur in Chapter 1, in the next section; for now, we concentrate on their syntax. The connectives A.,'(, EX, AG, EG, AU, EU, AF and EF are called temporal connectives. Notice that each of the CTL temporal connectives is a pair of symbols. The first of the pair is one of A and E. A means 'along All paths' (inevitably) and E means 'along at least (there Exists) one path' (possibly). The second one of the pair is X, F, G, or U, meaning 'neXt state', 'some Future state', 'all future states (i E[</J1U ¢2], for e symbols X. F, G a E; similarly, every 
Convention3.2 W to what we did fo (consisting of , EX) bind most tig --,., AU and EU. 
Naturally, we u some examples of not well-formed, i are atomic formul 
• EGr; 

e AG(q-> EGr) according to tt (EGr) 
o A[r U q] e EFE[r U q] e A[p U EFr] 
• EFEGp---+ AF EF (EG p ---+AI 
o AGAFr e A[/11 U A[p2 U o E[A[p1 U p2]U e AG (p---+ A[p U 
It is worth spend construct each of 
o FGr -since F e A,G,p 
o 
F[r U q] 


o 
EF(r U q) 

o 
AEFr e AF[(rUq)/\(f 


It is especially wo construct these. F 
tis parallel activity. 1 a model. 
logic, having con
:mchinb
0 -time Ionic
"' ' 

which the future any one of which 
riptions (such as descriptions of a 
inter. 
alue 6. 
m our particular 
1ckus Naur form 
A.X<J>I EX</JI lFq>. 
atomic descripthe meaning of in Chapter 1, in The connectives Jra/ connectives. Jf symbols. The ths' (inevitably) ly). The second ,e Future state', 
3.2 The syntax of computation tree logic 
'all future states (Globally)' and Until, respectively. The pair of operators in E[</J1 U ¢2], for example, is EU. Notice that AU and EU are binary. The symbols X, F, G and U cannot occur without being preceded by an A or an E; similarly, every A or E must have one of X, F, G and U to accompany it. 
Convention 3.2 We assume similar binding priorities for the CTL connectives to what we did for propositional and predicate logic. The unary connectives (consisting of, and the temporal connectives AG, EG, AF, EF, AX and EX) bind most tightly. Next in the order come /\ and V; and after that come ->, AU and EU. 
Naturally, we use brackets in order to override these priorities. Let us see some examples of well-formed CTL formulas and some examples which are not well-formed, in order to understand the syntax. Suppose that p, q and r are atomic formulas. The following are well-fo1med CTL formulas: 
e EGr; 
e AG(q--+ EGr) -note that this is not the same as AGq--+ EGr, for according to the binding priorities the latter formnla means (AGq) --+ (EG1·) 
e A[r U q] " EF E[r U q] e A[p U EFr] e EFEGp--+ AFr (again, note that this binds as (EFEGp)--+ AFr, not 
EF(EGp--+ AFr) or EFEG(p--+ AFr)!) 
e AGAFr 
" A[p1 U A[p2 U p3]] e E[A[p1 U pz] U p3] e AG(p--+ A[p U (,p /\ A[,p U ql)]). 
It is worth spending some time seeing how the syntax rules allow us to construct each of these. The following are not well-fo1med formulas: 
" FG r -since F and G must occur immediately after an E or an A 
e A,G,p e F[r U q] "EF(rUq) 
e AEFr ., AF [(r U q) /\ (p Ur)]. 
It is especially worth nnderstanding why the syntax rules don't allow us to construct these. For example, take BF (r U q). EF is an operator and so is 
Verification by model checking 

U, so why is this not a well-formed CTL formula? The answer is that U can occur only when paired with an A or an E. The E we have is paired with the 
F. To make this into a well-formed CTL formula, we would have to write EFE[r U q] or EFA[r U q]. 
Notice that we use square brackets after the A or E, when the paired operator is a U. There is no strong reason for this; you could use ordinary round brackets instead. However, it often helps one to read the formula (because we can more easily spot where the corresponding close bracket is). Another reason for using the square brackets is that a particular model checker called SMV, which we will study later in this chapter, adopts this notation. 
The reason AF [(r U q) /\ (p U r)] is not a well-formed formula is that the syntax does not allow us to put a boolean connective (like /\) directly inside A[] or E[ ]. Occurrences of A or E must be followed by one of G, F, X or U; when they are followed by U, it must be in the form A[<f, U 1/JJ. Now, the <f,and the 1Pmay contain /\, since they are arbitrary formulas; so A[(p I\ q) U (-,r--+ q)] is a well-formed formula. Fig.3.1. Th, 
Observe that AU and EU are binary connectives which mix infix and prefix notation. In pure infix, we would write <f,1 AU <f,2, whereas in pure 
* (a) FGrprefix we would write AU( ¢1, ¢2). 
(b) XXr
As with any formal language, and as we did in the previous two chapters, (c) A-,Qit is useful to draw parse trees for well-formed formulas. The parse tree for 
(d) F[r UA[AX -,p U E[EX (p I\ q) U -,p]] is shown in Figure 3.1. 
(e) EXX * (f) AEF1Definition3.3 A subformula of a CTL formula <f,is any formula 1p whose 
* (g) AF [(1parse tree is a subtree of <f,'s parse tree. 
3. State which EXERCISES3.1 
those which We let {p,q,r,s,t} be the set of propositional atoms for all systems of this not well-forr set of exercises. 
(a) -,(-,p: 
1. Write the parse trees for the following CTL formulas: (b) Xq 
* (c) -,AX 
* (a) EGr 
(d) p U (,* (b) AG(q-> EGr) 
* (e) E[(N
* (c) A[p U EFr] 
* (f) (Fr) I• (d) EF EG p-+ AF r (recall Convention 3.2) 
(g) -,(AC
(e) A[p U A[q Ur]] * 4. List all subf
(f) E[A[p U q] U r] q])]).
(g) AG(p-> A[p U (-,p I\A[-,p U q])]). 
2. Explain why the following are not well-formed CTL formulas: 
mswer is that U can ve is paired with the would have to w1ite 
E, when the paired could use ordinary 
o read the formula 1ding close bracket 
a particular model :hapter, adopts this 
1ed formula is that ve (like /\) directly owed by one of G, he form A[¢ U ,p]. itrary fo1mulas; so 
!iich mix infix and 2, whereas in pure 
rious two chapters, The parse tree for 
fo1mula ,p whose 
tll systems of this 
lS: 
formulas: 
3.2 The syntax of computation tree logic 
AU 


I\ 

p q 
Fig. 3.1. The parse tree of a CTL formula without infix notation. 
* (a) FGr 
(b) XXr 
(c) A,G,p 
(d) F[r U q] 
(e) EXXr 
* (f) AEFr 
* (g) AF [(r U q) /\ (p Ur)]. 
3. State which of the strings below are well-formed CTL formulas. For those which are well-formed, draw the parse tree. For those which are not well-formed, explain why not. 
(a) 
,(,p)V(r/\s) 

(b) 
Xq 


* (c) ,AXq 
(d) p U (AX_l_) 
* 
(e) E[(AXq) U (,(,p) V (T /\ s))] 

* 
(f) (Fr)/\ (AG q) 


(g) ,(AGq)V(EGq). 
* 4. List all subformulas of the formula AG (p -+ A[p U (,p I\ A[,p V 
q])]). 
Verification by model checking 
3.3 Semantics of compntation tree logic 

Definition 3.4 A model ./It= (S, -+, L) for CTL is a set of states S endowed with a transition relation ---+ (a binary relation on S), such that every s ES has some s' E S withs---->s', and a labelling function 
L: S ---+&'(Atoms). 

This definition looks rather mathematical; but it simply means that you have a collection of states S, a relation ---+, saying how the system can move from state to state, and, associated with each state s, you have the set of atomic propositions L(s) which are true at that particular state. We write &'(Atoms) for the power set of Atoms, a collection of atomic descriptions. For example, the power set of {p,q} is {(i),{p}, { q}, {p,q} }. A good way of thinking about L is that it is just an assignment of truth values to all the propositional atoms as it was the case for propositional logic (we called that a valuation). The difference now is that we have more than one state, so this assignment depends on which states the system is in: L(s) contains all atoms which are true in state s. 
We may conveniently express all the information about a (finite) model Ji for CTL using directed graphs whose nodes (= the states) contain all propositional atoms that are true in that state. For example, if our system has only three states s0, s1 and s2; if the only possible transitions between states are so ---->s1, so -+ s2, s1 -> so, s1 -+ s2 and s2 ---> s2; and if L(so) ~ {p, q }, L(si) ~ {q, r) and L(s2) ~ {r},then we can condense all this information into the picture in Fignre 3.2. We prefer to present models by means of such pictures whenever that is feasible. 
The requirement that for every s E S there is at least one s' E S such that s -+ s' means that no state of the system can 'deadlock'. This is no severe restriction, because we can always add an extra state sd representing deadlock, together with new transitions s -+ sd for each s which was a deadlock in the old system, as well as s,1 -+ s,1. See Figure 3.3 for such an example. 
Let us define the intended meanings of the CTL connectives. 
Definition 3.5 Let .JI= (S,-,,L) be a model for CTL. Given any sin S, we define whether a CTL formula </>holds in state s. We denote this by 
Jt, s I=¢. 

Naturally, the definition of the satisfaction relation I= is done by structural induction on all CTL formulas: Fig.3.2. A concise 
nre states containi11 
state. 

so .--<~ ( 
"'--._./~ 


',.~, 
s1 

Fig.3.3. On the left 
transitions. On the 
no state can dead! 'deadlock' state cor 
1. Jt,sl= Ta 
2. jf,s I=p ifl 
3. j/, s I=~<I> 
4. .Jl,s I=</>1, 
5. .ti, s I=</>11 
6. .ii, s I=</>1• 
7. Ji,s I=AX AX says:' 
8. .11,s I=EX 
of states S endowed. uch that every s E S, 
ply means that you' he system can movet' 1ou have the set 1lar state. We write.' 1tomic descriptions. }}. A good way of th values to all the ogic (we called that ,m one state, so this ) contains all atoms 
,ut a (finite) model states) contain all le, if our system has ions between states d if L(so) ~ {p, q }, 11 this information s by means of such 
,t one s' E S such 1dlock'. This is no ate sd representing ch s which was a 
•re 3.3 for such an 
~tives. 
ven any sin S, we ote this by 
lone by structural 
3.3 Semantics of computation rree logic 

S3
S3 

no state can deadlock; of course, it is then our understanding that reaching the 
'deadlock' state corresponds to deadlock in the original system. 
l. .,tt,s FT and J!,s ljlJ_ for alls ES. 
2. ..!!,s F p iff p E L(s). 
3. .it, s F ,<{>iff Ji, s ljl<{>. 
4. .i!,s I= <{> iff J!,s and .11,s F </>2.
1 /I cpz F </>1 
5
. .ii, s F efJ1V c/32iff .l/, s F </>1 or j/, s F </32. 

6
. .JI, s F 'Pl--> cfa2iff JI, s lj"ef,1 or .!!, s I= ,/32. 

7. 
JI, s F AX 1>ifffor all s1 such that s ~, s1 we have .,tt, s1 I= q\. Thus, AX says: 'in every next state'. 

8
. .II, s F EX<{> ifffor some s1 such thats ~, s1we have .//, s1F qJ.Thus, 


Verification by model checking 

EX says: 'in some next state'. E is dual to A -in exactly the same way that 3 is dual to 't in predicate logic. 
9. 
At, s I=AG <j,holds iff for all paths s1--+ s2 --+ s3 --,. ... , where s1equals s, and all s; along the path, we have Ji, s; I=<f,.Mnemonically: for All computation paths beginning in s the property <j,holds Globally. Note that 'along the path' includes the path's initial state s. 

10. 
Jt, s I=EG ,pholds iff there is a path s1 -> s2 ---->s3 --+ ... , where s1 equals s, and for all s; along the path, we have ..ll, s; I=<j,.Mnemonically: there Exists a path beginning in s such that <j,holds Globally along the path. 

11. 
Jt,s I=AF <j,holds iff for all paths s1 -> s2 -> ... ,where s1 equals s, there is some s; such that JI!, s; I=<j,.Mnemonically: for All computation paths beginning in s there will be some Future state where <p holds. 

12. 
✓It, s I=EF <j,holds iff there is a path s1 -> s2 -> s3 -> ... , where s1 equals s, and for some s; along the path, we have JI, s; I= ¢. Mnemonically: there Exists a compntation path beginning in s such that ¢ holds in some Future state; 

13. 
JI, s I=A[¢1 U </Jz]holds iff for all paths s1 -> s2 ---+ s3 -> ... , where s1 equals s, that path satisfies ¢ 1U ¢2, i.e. there is some s; along the path, such that Jl,s; F <f,2, and, for each j < i, we have Jlt,sj I=¢1. Mnemonically: All computation paths beginning in s satisfy that <j,1 Until <J,2holds on it. 

14. 
Jt,s I= E[q',1 U ¢2] holds iff there is a path s1 -> s2 -> s3 -> ... , where s1 equals s, and that path satisfies ¢1 U ¢2 as specified in 13. Mnemonically: there Exists a computation path beginning in s such that ¢1 Until ¢2 holds on it. 


For the remainder of this section, we will be concerned with the computational consequences of this definition, and with justifying and explaining its clauses. 
The first six clauses are exactly what we expect from our knowledge of propositional logic gained in Chapter 1. Notice that, for example, the truth value of ,,f, in a state depends on the truth value of ¢ in the same state. This contrasts with the clauses for AX and EX. The truth value of AX¢ in a state s is determined not by the truth value of ¢ in s, but by ¢ in states that are related to s by the relation ---+;ifs --+ s, then this value also depends on the truth value of <j,in s. 
The next four clauses also exhibit this phenomenon, except more so: for example, to determine the truth value of AG¢ involves looking at the trnth 

Fig. 3.4. Unwinding t paths beginning in a J 
value of¢ not only : states as well. In fa value of ¢ in every the current state. 
Clauses 9-14 abu \]seful to visualise a unwinding the tran whence 'computatio state satisfies a CTL Figure 3.2 for the de Figure 3.4. 
The diagrams in F states satisfy the fo: course, we could ad the satisfaction -a illustrate a 'least' wa 
Remark3.6 Notice t 
1 If this task is done by a visualisation of a system 
in exactly the same 
+ ... , where s1 equals . Mnemonically: for ty cpholds Globally. tial state s. "*s3 ......),... , where s1 4't,s; F ¢. Mnemontat ¢ holds Globally 
., where s1 equals s, ally: for All compu'uture state where cp 
--+ s3 --+ ... , where we have .4't,s; F ¢. beginning in s such 
2 ~ s3 ~ ... , where is some s; along the we have ./lt,sj F ¢1. ; in s satisfy that cp1 
~S2~S3~ ... , 
•2 as specified in 13. beginning in s such 
I with the computag and explaining its 
a our knowledge of r example, the truth p in the same state. th value of AX</>in ,, but by cpin states ; value also depends 
except more so: for looking at the truth 
A 1593.3 Semantics of computation tree logic 
S1 8S2 
q,r ~ '\ 
so 
p,q 
Fig.3.4. Unwinding the system of Figure 3.2 as an infinite tree of all computation paths beginning in a particular state. 
value of ¢ not only in the immediately related states, but in indirectly related states as well. In fact, in the case of AG¢, you have to examine the truth value of ¢ in every state related by any number of forward links of -> to the current state. 
Clauses 9-14 above refer to computation paths in models. It is therefore 1,1sefulto visualise all possible computation paths from a given state s by unwinding the transition system to obtain an infinite computation tree, whence 'computation tree logic'. This greatly facilitates deciding whether a state satisfies a CTL formula 1. For example, if we unwind the state graph of Figure 3.2 for the designated starting state so,then we get the infinite tree in Figure 3.4. 
The diagrams in Figures 3.5-3.8 show schematically systems whose starting states satisfy the formulas EF q,,EG ¢, AG cp and AF¢, respectively. Of course, we could add more cpto any of these diagrams and still preserve the satisfaction -although there is nothing to add for AG. The diagrams illustrate a 'least' way of satisfying the formulas. 
Remark 3.6 Notice that, in clauses 9-14 above, the future includes the present. 
1 If this task is done by a computer, then that is a different matter, but we seem to benefit from this visualisation of a system as a tree. 
Vcr(fication by model checking 
0 
Fig. 3.5. A system whose starting state satisfies EF </>. 
Fig. 3.6. A system whose starting state satisfies EG </>. 

This means that, when we say 'in all future states', we are including the present state as a future state. It is a matter of convention whether we do this, or not; see the exercises below for an exclusiveversion of CTL. A consequence of adopting the convention that the future shall include the present is that the formulas (AG p) -> p, p -+ A[q U p] and p -+ EF p are true in every state of every model. 
Fig. 3.; 
Fig. 3.: 
stands for 'until'. 
holds continuo1 actually demands ti for <f,1 to hold conI the states s3 to s9 s, 
) 
fies EF q,. 
es EG q,. 
: inclnding the present hether we do this, or CTL. A consequence :le the present is that Fp are true in every 
3.3 Semantics of computation tree logic 
q, 
q, 
q, 
q, </> 
q, 
Fig. 3.7. A system whose starting state satisfies AG q,. 
q, 
q, 
Fig. 3.8. A system whose starting state satisfies AF q,. 
We now move our discussion to the clauses for AU and EU. The symbol U stands for 'until'. The formula </>1U ¢2 holds on a path if it is the case that ,J,rholds continuously until the next occurrence of ¢z. Moreover, ¢1 U ¢2 actually demands that ¢2 do~s hold in some future state, i.e. it is not enough for <j,1 to hold continuously forever. See Figure 3.9 for illustration: each of the states s3 to s9 satisfies p U q along the path shown, but so to s2 don't. 
Verification by model checking 
-•1 ~ ~ ~ ~ % ~ -~ •w 
qp 

Fig. 3.9. An illustration of the meaning of Until in the semantics of CTL. Each of the states s3 to s9 satisfiesp U q along the path shown. 
Thus, we defined earlier that a particular path so --+ s1 -> s2 --+ ... satisfies </i1U </,2iff: 
® there is some s; along the path, such that s; F </,2,and ® for each j < i, we have Sj F ef,1. 
The clauses for AU and EU given in Definition 3.5 reflect this intuition, for all paths and some path, respectively. Note that the semantics of <t,1U </,2is not saying anything about </,1 in state s;; neither does it say anything abont ef,2 in states Sj with j < i. This might be in contrast to some of the implicit meanings of 'until' in natural language usage. For example, in the sentence 'I smoked until I was 22.' it is not only expressed that the person referred to continually smoked up until he, or she, was 22 years old, but we also would interpret such a sentence as saying that this person gave up smoking from that point onwards. This is different from the semantics of Until in temporal logic. 
It should be clear that we have outlined the formal foundations of a procedure that, given </,,./II and s, can check whether 
./It, s F </, 

holds. In particular, if the given set of states is finite, then we may compute the set of all states satisfying </,.If the model J/t is clear from the context,· we will simply write s F </,instead of Jlt, s F </,.Let us now look at some example checks for the system in Figures 3.2 and 3.4. 
1. 
J/t, so I=p /\ q holds since the atomic symbols p and q are contained in the node of s0. 

2. 
J!, s0 F ,,. holds since the atomic symbol r is not contained in node< 


SQ. 
3. 
J/f, so F T holds by definition. 

4. 
JI, so F EX (q /\r) holds since we have the leftmost computation path so-, s1 ->so-, s1 -> ... in Figure 3.4, whose second node s1 contains, q and r. 

5
. .JI, so F ,AX (q /\ r) holds since we have the rightmost computation•, 


•1 ( 
~ 
path so...., s: only contain 
6. 
Jt, so F ,EF in so such th: so, because t p and,-hold 

7. 
Jl,s2 F BG computation holds in all fi 

8. 
Jl,s2 F AGr beginning in 

9. 
Jt,so F AFr the system re, 

10. 
Jl,so F E[(pl path so --+ s2 (i = 1) satisfi satisfy p /\ q. 

11. 
Jl,so I=A[p l successor stat beginning in .s 


XERCISES 3.2 (elet {p,q,r,t} bet: rexercises. 
1. Consider the s ,antics of CTL. Each of 
11 --> s2 ---+ ... satisfies 
d 
tlect this intnition, for nantics of ¢1 U ef>2is it say anything about , some of the implicit mple, in the sentence :he person referred to Id, but we also would tve up smoking from ; of Until in temporal 
ml foundations of a 
1en we may compute iar from the context, 1s now look at some 
and q are contained 
ot contained in node 
>st computation path 
ond node s1 contains 
:htmost computation 
3.3 Semantics of computation tree logic 
St 
Fig. 3.10. A system with four states. 
path so --> s2 --> s2 -> s2 ---+ ... in Figure 3.4, whose second node s2 only contains r, but not q. 
6. 
Jt, soF ~EF (p/\r) holds since there is no compntation path beginning in so such that we could reach a state where p I\ r would hold. This is so, because there is simply no state whatsoever in this system, where p and r hold at the same time. 

7. 
Jt, s2 I= EG r (note the s2 instead of so!) holds since there is a computation path s2 --> s2 --> s2 -> . . . beginning in s2 such that r holds in all future states. 

8. 
J!t, s2 F AG r holds as well, since there is only one computation path beginning in s2 and it satisfies r globally. 

9. 
Jt, so F AF r holds since, for all computation paths beginning in so, the system reaches a state (s1 or s2) such that r holds. 

10. 
j/,s 0 F E[(p/\q) Ur] holds since we have the rightmost computation path so -+ s2 --> s2 -> s2 -,. . . . in Figure 3.4, whose second node s2 (i = 1) satisfies r, but all previous nodes ( only j = 0, i.e. node so) satisfy p I\ q. 

11. 
Jt,so I=A[p Ur] holds since p holds at so and r holds in any possible successor state of so, so p U r is true for all computation paths beginning in so (so we may choose i = 1 independently of the path). 


EXERCISES 3.2 We let {p, q, r, t} be the set of propositional atoms for all systems of this set of exercises. 
1. Consider the system .,If in Figure 3.10. 

Verification by model checking 
So 
(a) 
Beginning from state so, unwind this system into an infinite tree, and draw all computation paths up to length 4 ( = the first four layers of that tree). 

(b) 
Make the following checks JI, s0 I=</>,where </>is listed below. For that you need to explain why the check holds, or what reasons there are for its failure: 


,,, (i) ,p ---+ I' 
(ii) 
AF t *(iii) ,EGr 

(iv) 
E(t U q) 

(v) 
AF q 

(vi) 
EF q 


(vii) EG r 
(viii) AG(r V q). 
(c) Make the same checks as in (b) but now for state s2. 

2. Consider the following system jf in Figure 3.11. Check the following CTL formulas </>for state so, i.e. determine whether Jt, so I=</>holds: 
(a) 
AF q 

(b) 
AG(EF (p V r)) 

(c) 
EX(EXr) 


(d) AG(AFq). 

3. 
Do the same as in exercise 2, but for state s2. 

4. 
The meaning of the temporal operators AU, EU, AG, EG, AF and EF was defined to be such that 'the present includes the future'. For example, EF pis true for a state if pis trne for that state already. Often one would like corresponding operators such that the future excludes 


the presen 
to defines 
What kind of pn CTL? We list a : include some wo: the following pro 
It is possible t hold: E F ( started /\ 
• For any state, i be acknowledg AG (requested A certain proc, AG (AF enabl, 
• • Whatever hapr locked: AF (AG dead I• 
• From any state AG (EF restar An upwards ti direction when AG (floor=2 /\ 
Here, our aton variables, e.g. fl The elevator ca AG (floor=3 /\ i 
EXERCISES 3.3 
* 1. Express in amount of occurs unt 
2. Explain in patterns al plain Engl tes. 
rstem into an infinite p to length 4 (= the 
1ere ¢ is listed below. :heck holds, or what 
for state s2. . Check the following ther At,so t=¢ holds: 
U, AG, EG, AF and ,ludes the future'. For tt state already. Often at the fi1ture excludes 
3.3 Semantics (~r computaliOll tree logic 
the present. Use suitable connectives of the grammar in Definition 3.1 to define such (six) modified connectives as derived operators in CTL. 
3.3.1 P,·acticrllpatten1s of specijic11tio11s 
What kind of practically relevant properties can we check with formulas of CTL? We list a few of the common patterns. Suppose atomic descriptions include some words such as busy and requested. We may require some of the following properties of real systems: 
• 
It is possible to get to a state where started holds. but ready does not 

hold: EF (started/\ ,ready). 

• 
For any state, ifa request (of some resource) occurs. then it will eventually be acknowledged: AG (requested -+ AF aclmowledgecl). 

• 
A certain process is enabled infinitely often on every computation path: AG (AF enabled). 

• 
Whatever happens, a certain process will eventually be permanently deadlocked: AF (AG deadlock). 

• 
From any state it is possible to get to a restart state: AG (EF restart). 

• 
An upwards travelling elevator ai the second floor does not change its direction when it has passengers wishing to go to the fifth floor: AG (floor=2 /\ direction=up /\ ButtonPressed5 -> 


A[direction=up U floor=5]) Here, our atomic descriptions are boolean expressions built from system variables, e.g. floor=2. 
• The elevator can remain idle on the third floor with its doors closed: AG (floor=3 /\idle/\ door=closed -+ EG (floor=3 /\idle/\ door=closed)). 
EXERCISES 3.3 
* 1. Express in CTL: Whenever p is followed by q (after some finite amount of steps), then the system enters an 'interval' in which no ,occurs until t. 
2. Explain in detail why the CTL formulas for the practical specification patterns above capture the stated 'informal' properties expressed in plain English. 
Verification by model checking 

3. 
Consider the CTL formula AG (p -, AF (s /\ AX (AF t))). Explain what exactly it expresses in terms of the order of occurrence of events p, sand t. 

4. 
Write down a CTL formula which says that p precedes s and t on all computation paths; you may find it easier to code the negation of that specification first. 

5. 
Represent 'After p, q is never true.' as a CTL formula, where this constraint is meant to apply on all computation paths. 

6. 
Find a CTL formula which expresses the following property on all computation paths: 


(a) 
'Between the events q and r, pis never true.' 

(b) 
'Transitions to states satisfying p occur at most twice.'. 


3.3.2 lmp01·ta11t equivale11ces between CTL formulas 

Definition3.7 Two CTL formulas ¢ and 1Pare said to be semantically equiPalent if any state in any model which satisfies one of them also satisfies the other; we denote this by ¢ = 1p. 
Note that we wrote¢ = 1Pin Chapter 1 if the propositional logic formulas ¢ and 1Phad the same meaning no matter what valuation (= assignment of ; truth values) one considers. We may think of such valuations as L(s) for a CTL model with one state s and one transition s -> s. Therefore, we see how< the definition above extends the meaning of = to a larger class of models)· and formulas. 
We have already noticed that A is a universal quantifier on paths and E is the corresponding existential quantifier. Moreover, G and F are also: universal and existential quantifiers, ranging over the states along a particular path. In view of these facts, it is not surprising to find that de Morgan rules. exist for A and E and also F and G: 
--.AF¢ -EG --.4> --.EF</> -AG --.if>. 

On any particular path, each state has a unique successor. Therefore, X is. its own dual on computation paths and we have 
We also have tb 
AFq 
• Yon can check thi ef,1 U ¢2 to be tru true at some futnr In the expression , true in every state state). 
Naturally, any , hold in CTL. Thii 
e.g. we have that _scheme ¢ V --.,t,of propositional logic example, in Chapt of connectives, sin terms of those thn 
This is also tht written --.EX --. by of AU and EU , --.AF--.if>(using (3 E[T U ¢]. Therefc 
: connectives. Also EG, EU, ar 
A[¢ 
;.'This equivalence is illater (Section 3.8 Similarly, AG, A adequate sets, but • \s~t consisting of Al (reduces to EG, EU 
•X are adequate_, mantical/y equiv, 
3.3 Semantics of computation tree logic 

X (AF t))). Explain ccurrence of events 
recedes s and t on )de the negation of 
Jrmula, where this aths. ng property on all 
nost twice.'. 
•r,1111/as 
semantically equiv
m also satisfies the 
onal logic formulas 1 ( = assigmneut of . tions as L(s) for a :refore, we see how ;er class of models 
ifier on paths and G and F are also ; along a particular tt de Morgan mies 
(3.1) 

. or. Therefore, X is 
(3.2) 
We also have the equivalences 
AFrj, = A[TUq,] EF </>= E[T U ,{>]. 
You can check this by looking back at the meaning of the clause for U. For 
'PI U rpz to be true in a state along a path, it is necessary that rj,2 become 
true at some future point and that 4>1is true in every state until that point. 
In the expression above, we let q,1 be T, so that the requirement that rj,1 be 
true in every state until q,2 is vacuously satisfied ( since T is true in every 
state). Naturally, any equivalence which holds in propositional logic will also hold in CTL. This is true even if the equivalence involves CTL formulas: 
e.g. we have that T and (AXp) V ,AXp are equivalent since the formula scheme ef, V ,rp of propositional logic is equivalent to T. Therefore, as in propositional logic, there is some redundancy among the connectives. For example, in Chapter 1 we saw that the set {1-, /\, ,} forms an adequate set of connectives, since the other connectives V, -+, T, etc., can be written in terms of those three. ( Cf. exercise 3, page 71.) 
This is also the case in CTL. Moreover, the connective AX can be written ,EX, by (3.2); and AG, AF, EG and EF can be written in terms of AU and EU as follows: first, write AG rj, as ,EF ,ef, and EG rj, as ,AF ,q, (using (3.1)) and then use AF rj, = A[T U rj,] and EF ,f, = E[T U rj,]. Therefore AU, EU and EX form an adequate set of temporal connectives . 
Also EG, EU, and EX form an adequate set, for we have the equivalence 
A[rj, U 1/J] = ,(E[ •1/J U ( ,rp I\ ,v.1)]VEG ,1p ). (3.3) 
This equivalence is rather harder to demonstrate than the others; we will do it later (Section 3.8.1). 
Similarly, AG, AU and AX form an adequate set. There are many other adequate sets, but we just mention one more, since we will use it later: the set consisting of AF, EU and EX. Since AF can be reduced to EG, this set reduces to EG, EU and EX which we have seen to be adequate . 
Theorem 3.8 The set of operators 1-, , and I\ together with AF, EU and EX are adequate for CTL: any CTL formula can be transformed into a semantically equivalent CTL formula which uses only those logical 
connectives. 
Verification by model checking 

Some other noteworthy equivalences in CTL are the following: 
AG,j, -,j,I\ A,'{ AG <f, EG<J, -cpl\ EXEG,b AF <J,-q,VAXAF<f, EF,j, -¢ V EX EF ¢ 
A[</, U v,] -1pV (</,I\ AXA[</, U 1pl) E[<J, U v;] -1pV (¢/\EXE[¢ U 1pl). 

For example, the intuition for the third one is the following: in order to have AF <J,in a particular state, ¢ must be true at some point along each path from that state. To achieve this, we either have <(,true now, in the current state; or we postpone it, in which case we must have AF<(,in each of the next states. Notice how this equivalence appears to define AF in terms of A,'( and AF itself -an apparently circular definition. In fact, these equivalences can be used to define the six connectives on the left in terms of AX and EX, in a llOn-circularway. This is called the fixed-point characterisation of CTL; it is the mathematical foundation for the model-checking algorithm developed in Section 3.5; and we return to it later (Section 3.9). 
EXERCISES 3.4 
1. Which of the following pairs of CTL formulas are equivalent? For those which are not, exhibit a model of one of the pair which is not a model of the other. 
(a) 
EF ¢ and EG ¢ ,:, (b) EF q,V EF 1pand EF ( q\V 1p) ,:, (c) AF ef,V AF,p and AF(¢ V 1p) 

(d) 
AF ,<f,and ,EG <f, ,:, (e) EF ,¢ and ,AF q, 

(f) 
A[</,1 U A[r/Jz U rf,3]]and A[A[,J,1 U </J2]U ¢1] (Hint: it might make it simpler if you think first about models that have just one·path.) 


(g) 
T and AG q,-+ EG <f, ,:, (h) T and EG ¢ -+ AG¢. 


2. Find operators to replace the ? marks, to make the following equivalences. 
(a) EF,q, = ,??</> *(b) AG(<j,/\1p) = AGrj,?AG,p. 
3. Use the definition of I=between states and CTL formulas to explain why s I=AG AF¢ means that ¢ is true infinitely often along every . path starting at s. 
4. Prove the l 
* , Write pse takes as in: equivalent ( J_, ,, !\, Al 
Let us now look a with mutual exclw a file on a disk or do not have acces 
• editing the same f 
We therefore id arrange that only critical section she should be as small The problem we , process is allowed 
'i found one which 1 has some expectec 
Safety: The proto, any time. 
This safety prope excluded every pn useful. Therefore, • 
Liveness:Whenev, eventually Non-blocking:A i: 
Some rather crude '.>the processes, mai 
• ' might be natural] shared resource 111, property: 
' No strict sequencil sequence. 
, following: 
1]) ]). 
ving: in order to have oint along each path J now, in the current 'q,in each of the next AF in terms of AX ct, these equivalences in terms of AX: and 1t characterisation of I-checking algorithm tion 3.9). 
are equivalent? For :he pair which is not 
J ef,3](Hint: it might 10dels that have just 
he following equiva
formulas to explain y often along every 
3.4 Example: mutual excl11sion 
4. Prove the Equivalences (3.1) and (3.2). 
* 5. Write pseudo-code for a recursive function TRANSLATE which takes as input an arbitrary CTL formula ef; and returns as output an equivalent CTL formula 1p whose only operators are among the set (..L,~,/\,AF, EU, EX}. 
3.4 Example: mutual exclusion Let us now look at a larger example of verification using CTL, having to do with mutual exclusion. When concurrent processes share a resource (such as a file on a disk or a database entry). it may be necessary to ensure that they do not have access to it at the same time. Several processes simultaneously editing the same file would not be desirable. We therefore identify certain critical sections of each process' code and arrange that only one process can be in its critical section at a time. The critical section should include all the access to the shared resource (though it should be as small as possible so that no unnecessary exclusion takes place). The problem we are faced with is to find a protocol for determining which process is allowed to enter its critical section at which time. Once we have 
found one which we think works, we verify our solution by checking that it has some expected properties, such as the following ones: 
Safety: The protocol allows only one process to be in its critical section at any time. 
This safety property is not enough, since a protocol which permanently excluded every process from its critical section would be safe, but not very useful. Therefore, we should also require: 
Liveness: Whenever any process wants to enter its critical section, it will eventually be permitted to do so. Non-blocking: A process can always request to enter its critical section. 
Some rather crude protocols might work on the basis that they cycle through the processes, making each one in turn enter its critical section. Since it might be naturally the case that some of them request accesses to the shared resource more than others, we should make sure our protocol has the property: 
No strict sequencing: Processes need not enter their critical section in strict sequence. 
Ver(fication by model checking 


3.4.1 Tilefi1·stmodelli11gattempt 

We will model two processes, each of which is in its non-critical state (n), or trying to enter its critical state (t), or in its critical state (c). Each individual process undergoes transitions in the cycle n -> t -+ c -+ n -+ ... , but the two processes interleave with each other. Consider the protocol given by the transition system ./It in Figure 3.121. The two processes start off in their non-critical sections (global state s0). State so is the only initial state, indicated by the incoming edge with no source. Either of them may now move to its trying state, but only one of them can ever make a transition at a time ( asynchronous interleaving). So there is a transition arrow from so to s1 and s5. From s1 (i.e. process 1 trying, process 2 non-critical) again two things can happen: either process 1 moves again (we go to s2), or process 2 moves (we go to s3). Notice that not every process can move in every state. For example, process 1 cannot move in state s7, since it cannot go into its critical section until process 2 comes out of its critical section. 
We cau verify the four properties by first describing them as CTL formulas: 
Safety: <J,1~ AG ,(CJ /\ c2). Clearly, AG ,(ci /\ c2) is satisfied in the initial state (indeed, in every state). Liveness: </>2~ AG (t1 -+ AF c1). This is not satisfied by the initial state, for we can find a state accessible from the initial state, namely s1, in 
1 We write P1P2 ... Pmin a nodes to denote that p1,p2, ... , Pm are the only propositional atoms true at s. 
which t1 is path s1 -> s Non-blocking: <f,3~ 
(i.e.so, ss a1 
No strict seqnencin: satisfied; e., for liveness, 
EXERCISES 3.5 
"' 1. 0 bserve thai 
point of vie, 
that process 
good reason 
2? 

The reason livern sion is that non-de1 over another. The I which of the proce, splitting s3 into twc 
The two states s3 ar first modelling atte trying states, but i1 whereas in s9 it is I labelling t1t2. The c 1hink of there beini initial labelling, wh: 
Remark3.9 The fc strict sequencing ar 
In this second n over-simplified, bee: on every tick of th may wish to mode: ticks, but if we inch 
{C}usion. 
a-critical state (n), or , (c). Each individual ---->n -> ... , but the ,e protocol given by rocesses start off in he only initial state, r of them may now ir make a transition sition arrow from so 
•n-critical)again two J to s2), or process 2 move in every state. it cannot go into its ection. :mas CTL formulas: 
itisfied in the initial 
by the initial state, ! state, namely s1, in 
·opositional atoms ttue at s. 
3.4 Example: 11wt11alexclusion 
which t1 is true but AF CJ is false, because there is a computation 
path s1 ---->s3 ---->s7 ---+ s1 -> ... on which c1 is always false. "Non-blocking:c{>3~ AG (111 ---->EX ti), which is satisfied, since every 111 state 
(i.e. so, ss and s6) has an (immediate) t1 successor. 
No strict sequencing: o/4~ EF(c 1/\ E[c1 U (~c1 /\ E[~c2 U ci])]). This is satisfied; e.g. by the mirror path to the computation path described 
for liveness, s5 --> s3 --> s4 -> s5 --+ .... 
Observe that the last three specifications have been written from the point of view of process 1. Can you modify those specifications such that process 2 also meets these constraints? Can you come up with a good reason explaining why we did not add the constraints of process 2? 
The reason liveness failed in our first attempt at modelling mutual exclusion is that non-determinism means it might continually favour one process over another. The problem is that the state s3 does not distinguish between which of the processes first went into its trying state. We can solve this by splitting s3 into two states. 
3.4.2 The seco11d modelling attempt 
The two states s3 and s9 in Figure 3.13 both correspond to the state SJ in our first modelling attempt. They both record that both processes are in their trying states, but in SJ it is implicitly recorded that it is process 1 's turn, whereas in s9 it is process 2's turn. Note that states SJ and s9 both have the labelling 11 t2. The definition of CTL models does not preclude this. We can think of there being some other, hidden, variables which are not part of the initial labelling, which distinguish s3 and s9. 
Remark3.9 The four properties of safety, liveness, non-blocking and no strict sequencing are satisfied by the model in Figure 3. 13. 
In this second modelling attempt, our transition system is still slightly over-simplified, because we are assuming that it will move to a different state on every tick of the clock ( t)1ere are no transitions to the same state). We may wish to model that a process can stay in its critical state for several ticks, but if we include an arrow from s2, or s6, to itself, we will again violate 
Ver{fication by model checking 


representing t1t 2, namely s3 and 89. 
liveness. This problem will be solved later in this chapter when we consider 'fairness constraints' ( Section 3. 7). 
EXERCISES 3.6 
1. Verify Remark 3.9. 
3.5 A model-checking algol"ithm 

In general, interesting transition systems will have millions of states and the fornmla we are interested in checking may be quite long. It is therefore well worth trying to find an efficient algorithm. 
Our usage of the notion of a 'moder . // has included directed graphs and also their unwindings into infinite trees, given a designated initial state. On doing the exercises, you very probably realised that checks on the infinite tree are easier for you to do, since all possible paths are plainly visible. However, if we think of implementing a model checker on a computer, we certainly cannot unwind transition systems into an infinite tree. We need to do checks on finite data structures. This is the reason why we now have to develop new insights into the semantics of CTL. Such a deeper understanding will provide the basis for an efficient algorithm which, given .//, s E S and 4>. computes whether .ii, s I=rp holds. In the latter case, such an algorithm can be augmented to produce an actual path (=run) of the system demonstrating 
that . // cannot sa1 what causes that r There are vario1 
as a computationa formula ¢ and a s1 ·yes· (j/, so I=¢ he inputs could be jm 
. model JI which s, 
If we solve the solution to the first the output set. Co1 for the first, we we 
. in turn, to decide algorithm to solve 
We present an algc 
• the set of states oi not need to be ab!, already seen that ti the propositional c adequate set of teir would simply pre-1 
• output of TRANS . coded in Exercises 
•INPUT: a CTL 111 
.First, change ¢ to • ; of the connectives >earlier in the chapt, Hhat are satisfied ti: 
outwards towards \ Suppose 1p is a : 'subformulas of 1P11 ¢ is any maximal-k : case analysis which 
1ere are now two states'' 
ter when we consider 
ons of states and the ,g. It is therefore well 
I directed graphs and ,ated initial state. On ks on the infinite tree inly visible. However, mputer, we certainly Ne need to clo checks 10w have to develop :r nnclerstanding will en .//, s E S and ,j,, ,ch an algorithm can ystem demonstrating 
3.5 A model-checking algorithm 
.that .// cannot satisfy ¢. That way, we may debug a system by trying to fix what causes that run to refute property ¢. There are various ways in which one could consider 
? j/, soI=</> 
;,as a computational problem. For example, one could have the model j/, the 
formula cf,and a state soas input; one would then expect a reply of the form :'yes' (.//, so I=cf,holds), or 'no' (.ll, so I=cf>does not hold). Alternatively, the ;inputs could be just .JI and ¢, where the output would be all states s of the 'model .II which satisfy ¢. 
If we solve the second of these two problems, we automatically have a solution to the first one, since we can simply check whether sois an element of the output set. Conversely, to solve the second problem, given an algorithm 
cfor the first, we would simply repeatedly call this algorithm with each state in turn, to decide whether it goes in the output set. We will describe an ,algorithm to solve the second problem. 
3.5.1 Tile labellillg algoi·itlim 
'We present an algorithm which, given a model and a CTL formula, outputs .the set of states of the model that satisfy the formula. The algorithm does ;not need to be able to handle every CTL connective explicitly, since we have already seen that the connectives _l, , and /I form an adequate set as far as ,:the propositional connectives are concerned; and AF, EU and EX form an '.· adequate set of temporal connectives. Given an arbitrary CTL formula <{,,we \would simply pre-process ¢, calling the model-checking algorithm with the ioutput of TRANSLATE (cfJ)as input, where TRANSLATE is the function 
•codec! in Exercises 3.4( 5), page 169. Here is the algorithm: 
INPUT: a CTL model JI!= (S,---+,L) and a CTL formula cf,. .OUTPUT: the set of states of .;It which satisfy ¢. 
'iFirst, change¢ to the output of TRANSLATE(<{,), i.e. we write cf,in terms : of the connectives AF, EU, EX, /1, , and J_ using the equivalences given .earlier in the chapter. Next, label the states of .Ill with the subformulas of cf, 
that are satisfied there, starting with the smallest subformulas and working outwards towards ¢. 
Suppose 1p is a subformula of c/Jand states satisfying all the immediate subformulas of 1p have alrea<;ly been labelled. (An immediate subformula of </1is any maximal-length subformula other than ¢ itself.) We determine by a case analysis which states to label with 1p.If 1p is 
Verification by model checking 
Repeat ... 


. . . until uo change. 

Fig.3.14. The iteration step of the procedure for labelling states with subformulas of the form AF1p1. 
J..: then no states are labelled with J... ® p: then labels with p if p E L(s). 
o 1p1/I 1/!2:label s with 1p1/I 1p2 ifs is already labelled both with v,1 and with 
11'2· ® ~1p1: labels with ~1111ifs is not already labelled with 1/!l• o AF1f!1: 
-If any states is labelled with ,p1, label it with AF 1p1. -Repeat: label any state with AF 1/!l if all snccessor states are labelled with AF 1111,until there is no change. This step is illustrated in Figure . 3.14. 
e E[1p1U 1/!2]: 
-If any state s is labelled with 1p2, label it with E[v,1U v,2]. -Repeat: label any state with E[,p1 U 1p2]if it is labelled with 1/!1and least one of its successors is labelled with E[v.11 U 1p2], until there is no.: change. This step is illustrated in Figure 3.15. 
e EX ,p1: label any state with EX 1111 if one of its successors is labelled with 1/Jl. 
Having performed the labelling for all the subformulas of <jJ(including itself), we output the states which are labelled <j,. 
The complexity of this algorithm is O(f • V • (V + E)), where f is the. number of connectives in the formula, V is the number of states and E is the number of transitions; the algoritlun is linear in the size of the formula· and quadratic in the size of the model. 
• Fig. 3.15. The ite of the form E[1/!1 
Instead of usin2 possible to write .probably be mo qifferent approa ,,to deal with EG 
t•EG1P1: -Label all ti -If any state -Repeat: de, is labelled , 
case for EU EG and wh: 
e can improv( 
ay of handlini )ye use EX, El t~ke care to sea 
:ates with subfonnulas 
,th with V'1 and with 
l 1Pl· 
'!, 
r states are labelled illustrated in Figure 
U 1P2]. ,lied with 1p1 and at >2], until there is no 
,ors is labelled with 
. of cf,(including ef, 
,)), where f is the of states and E is size of the formula 
3.5 A model-checking algorithm 
Repeat ... 
~ 

'PlE[,p1 U ,pz] 11'1 ~ 
~ 
. . . until no change. 
iFig. 3.15. The iteration step of the procedure for labelling states with snbformulas '.of the form E[,p1 U 1p2]. 
Handling BG directly 
'Instead of using a minimal adequate set of connectives, it would have been / possible to write similar routines for the other connectives. Indeed, this would '. probably be more efficient. The connectives AG and BG require a slightly 
different approach from that for the others, however. Here is the algorithm •• to deal with BG ,p1 directly: 
• EG1p1: -Label all the states with EG,p1. -If any states is not labelled with 'Pl, delete the label EG1p1. -Repeat: delete the label EGip1 from any state if none of its successors is labelled with BG 'Pl; until there is no change. 
Here, we label all the states with the subformula BG 1p1 and then whittle down this labelled set, instead of building it up from nothing as we did in the case for EU. Actually, there is no real difference betweeu this procedure for BG and what you would do if you translated it into ~AF~ as far as the final result is concerned. 
A variant which is more efficient 
We can improve the efficiency of our labelling algorithm by using a cleverer way of handling BG. Instead of using EX, EU and AF as the adequate set, we use EX, EU and BG instead. For EX and EU we do as before (but take care to search the model by backwards breadth-first searching, for this ensures that we won't have to pass over any node twice). For the EGv, case: 
Verification by model checking 
states satisfying 1p 

Fig. 3.16. A better way of handling EG. 

e restrict the graph to states satisfying 1/J,i.e. delete all other states and their 
transitions; 
find the maximal strongly connected components (SCCs); these are maximal 
regions of the state space in which every state is linked with ( = has a finite 
path to) every other one in that region. " use backwards breadth-first searching on the restlicted graph to find any state that can reach an SCC; see Figure 3.16. 
The complexity of this algorithm is O(f •(V + E)), i.e. linear both in the size of the model and in the size of the formula. 
Example3.10 We applied the basic algolithm to our second model of mutual exclusion with the formula E[,c 2 U c1]; see Figure 3.17. The algorithm labels all states which satisfy c1 during phase 1 with E[,c 2 U CJ].This labels s2 and s4. During phase 2, it labels all states which do not satisfy c2 and have a successor state that is already labelled. This labels states s1 and s3. During phase 3, we label so because it does not satisfy c2 and has a successor state (s1) which is already labelled. Thereafter, the algorithm terminates because no additional states get labelled: all unlabelled states either satisfy c2, or must pass through such a state to reach a labelled state. 
EXERCISES 3. 7 
* 1. Apply the labelling algorithm to check the formulas ¢1, ¢2, ¢3 and q;4of the mutual exclusion model in Figure 3.12. 
2. 
Apply the labelling algorithm to check the formulas ¢1, ¢2, ¢3 and • ¢4 of the mutual exclusion model in Figure 3.13. 

3. 
Explain the construction of formula ¢4, used to express that the .. processes need not enter their critical section in strict sequence. Does,( it rely on the fact that the safety property ¢ 1 holds? 

4. 
Inspecting the definition of the labelling algorithm, explain what . 


St 
0: tin 
2: E[,c2 
S2_..,J..---J' 
0: C1ll2 

1: E[,c2 U ci] 
0: c1t2 1: E[,c 2 
Fig. 3.17. An example exclusion applied to ti 
happens if yo model). 
3.5.2 The 
We present the pseu fin this chapter. Th( CCTL formula, i.e. a CThe program SAT e I.by means of the gr 
·important preconditi< 
;the program simply X(T I\ BF p3), since ,·tree according to the would make sure th '.SAT. However, we u ;'.preprocessing becaus 
:ig lj) 
}. 
other states and their 
'.s); these are maximal d with (= has a finite 
ed graph to find any 
inear both in the size 
ond model of mutual The algorithm labels U CJ]. This labels s2 ,t satisfy c2 and have tes s1 and s3. During has a successor state 1 terminates because either satisfy c2, or 
rnlas ¢1, ef,2, ef,3 and 
rnlas ef,1, ¢2, ef,3 and 
to express that the ;trict sequence. Does lds? rithm, explain what 
3.5 A model-checking algorithm 
so 
0: n1n2 
3: E[,c 2 U ci] 
s1 S5 
0: t1112 

s
S2__,.J---~.f'.. 
0; c1n2 
l: E[,c, 


Fig. 3.17. An example run of the labelling algorithm in our second model of mutual exclusion applied to the formula E[,c 2 U ct]. 
happens if you perform it on the formula p I\ ,p (in any state, in any model). 
3.5.2 The pseudo-code of tlie model c!tecking algm·it!im 
We present the pseudo-code for the basic labelling alg01ithm given earlier 
. in this chapter. The main function SAT (for 'satisfies') takes as input a CTL formula, i.e. a formula over the Backus Naur fom1 in Definition 3.1. The program SAT expects a parse tree of some CTL fomrnla constructed by means of the grammar in Definition 3.1. This expectation reflects an important precondition on the correctness of the algorithm SAT. For example, the program simply would not know what to do with an input of the form X(T /\ EF p3), since this is not a CTL formula (it does not have a parse tree according to the grammar for CTL ). Hence, we also need a parser that would make sure that only .well-formed CTL formulas are being fed into SAT. However, we merely focus on the development of SAT without such preprocessing because this is the prime objective of this section. 
Verification by model checking 

The pseudo-code we write for SAT looks a bit like fragments of FORTRAN or Pascal code; we use functions with a keyword returnthat indicates which result the function should return. We will also use natural language to indicate the case analysis over the root node of the parse tree of <f,.The declaration local var declares some fresh variables local to the current instance of the procedure in question, whereas repeat until executes the command which follows it repeatedly, until the condition becomes true. Additionally, we employ suggestive notation for the operations on sets, like intersection, set complement and so forth. In reality we wonld need an abstract data type, called SETS, together with implementations of these operations, but for now we are interested only in the mechanism in principle of the algorithm for SAT; any (correct and efficient) implementation of sets would do and we study snch an implementation in Chapter 6. We assume that SAT has access to all the relevant parts of the model: S, --+ and L. In particular, we ignore the fact that SAT would require a description of ..$! as input as well. We simply assume that SAT operates directly on any such given model. Note how SAT implicitly translates ¢ into an equivalent formula of the adequate set chosen. 
The algorithm is presented in Figure 3.18 and its subfunctions in Figures 3.19-3.21. They use program variables X, Y, V and W of type SETS. The program for SAT simply handles the easy cases directly and passes more complicated cases on to special procedures, which in turn might call SAT recursivelyon subexpressions. 
Of course, we still need to make sure that this algorithm is correct. This will be handled in Section 3.9. 
3.5.3 The 'state explosion' p1·ohlem 

Although the labelling algorithm (with the clever way of handling EG) is. linear in the size of the model, unfortunately the size of the model is itself exponential in the number of variables and the number of components of the system which execute in parallel. This means that, for example, adding a·,. boolean variable to your program will double the complexity of verifying a property of it. 
The tendency of the state space to become very large is known as the . state explosion problem. A lot of research has gone into finding ways of/ overcoming it, including the use of: 
" Efficient data structures, called ordered binary decision diagrams (OBDDs),, 
functionSAT ( ¢)/* determines the se 
begin case 

</>is T : retun ¢ is J_ : returi ¢ is atomic: r, ¢ is •¢1 : ret, ¢ is ¢1 /\ ¢2 : ,pis ¢1 V ¢2 : ¢ is ¢1 -► ¢2 ¢ is AX,f,1 : r ¢ is EX,t,1 : r, </>is A[¢1 U <j ¢ is E[¢1 U ¢ ¢ is EF </>1: n ¢ is EG¢ 1 : r, ¢ is AF ¢1 : r< ¢ is AG¢1 : r 
end case \end function 

'' Fig. 3.18. The functic . 9f states satisfying th i respectively, if EX, E 
iffunctionSATEx ( ¢)
•/* determines the set 
'local var X, Y '.begin 

X := SAT(¢); Y := {so ES Iso 
returnY end 

which represent s, 
•>i
n Chapter 6 in d, 

• 
Abstraction: we 


,.> relevant to the fo1 
; Partial order redu, 
\• component traces 
be checked is c, model-checkin 
3.5 A model-checking algorithm 

e fragments of FOR-. ·dreturnthat indicates se natural language to rse tree of¢. The dec
o the current instance • rncutes the command 1es true. Additionally, sets, like intersection, an abstract data type, Jerations, but for now 
of the algorithm for ets would do and we e that SAT has access particular, we ignore 
as input as well. We :h given model. Note mula of the adeqnate 
subfunctions in Fignd W of type SETS. ectly and passes more turn might call SAT 
rithm is correct. This 
1 of handling BG) is of the model is itself er of components of orexample, adding a plexity of verifying a 
rge is known as the into finding ways of 
1 diagrams (OBDDs), 
;.functionSAT(</>)/* detem1ines the set of states satisfying ¢ * / · begin 
case 
,J,is T : returnS 
q, is ..L : return0 
¢ is atomic: return{s ES I¢ E L(s)) 
¢ is •¢1 : returnS -SAT(</>1) 
q,is ¢1 /\ ¢2 : returnSAT(q,1) n SAT(q,2) 
</>is</>,V </>2 : returnSAT(</>1)U SAT(</>2) 
¢ is ¢1 -> ¢2 : returnSAT ( ,¢ V ¢2) 
q,is AX </>1: returnSAT ( ,EX ,q,i) 
¢ is EX ¢1 : returnSAT Ex( ¢I) 
¢ is A[</>1 U </>2]: returnSAT( ,(E[ ,¢ 2U ( ·¢1 /\ ,q12)]VEG ·¢2)) 
¢ is E[</>1 U </>2] ¢2)
: returnSATEU(</>1, ¢ is EF¢ 1 : returnSAT(E(T U ¢1)) ¢ is EG¢ 1 : returnSAT(,AF,¢ 1) <fais AF ¢1 : returnSATAF (</>1) </>is AG ¢1 : returnSAT ( ,EF ,q,J) 
end case end function 
Fig. 3.18. The function SAT. It takes a CTL formula as input and returns the set of states satisfying the formula. It calls the functions SATEx, SAT EU and SATAF, respectively, if EX, EU or AF is the root of the input's parse tree. 
functionSAT EX ( ¢) /* determines the set of states satisfying EX¢ */
local var X, Y 
begin 
X :=SAT(¢); 
Y := {soE S Iso-> s1for some s1 E X}; 
returnY 
end 
Fig. 3.19. The function SATEx-It computes the states satisfying¢ by calling SAT. Then, it looks backwards along -> to find the states satisfying EX¢. 
which represent sets of states instead of individual states. We study these 
in Chapter 6 in detail. 
• Abstraction: we abstract away variables in the model which are not relevant to the formula being checked. 
o Partial order reduction: for asynchronous systems, several interleavings of component traces may be equivalent as far as satisfaction of the formnla to be checked is concerned. This can often substantially reduce the size of the model-checking problem. 
Verification by model checking 

function SAT AF ( <p) 
/"' determines the set of states satisfying AP <f,* / local var X, Y begin 
X:=S; 
Y := SAT(¢); repeat until X = Y begin 
X:=Y; 
Y :=YU {s Ifor alls' withs---->s' we haves' E Y} end return Y 
end 

Pig. 3.20. The function SATAF· It computes the states satisfying <f,by calling SAT. Then, it accumulates states satisfying AP <f,in the manner described in the labelling algorithm. 
functionSAT EU ( <f,,VJ)/* determines the set of states satisfying E[<f, U 1p] * / 
local var W, X, Y begin 
W :=SAT(<f,); X :=S; Y := SAT(1p); repeat until X = Y begin 
X:=Y; Y := YU (W n {sIexistss' such thats---+ s' ands' E Y} 
end returnY end 
Pig. 3.21. The function SATEu• It computes the states satisfying <f,by calling SAT. Then, it accumulates states satisfying E[<f, U 1p]in the manner described in the 
labelling algorithm. 
0 Induction: model-checking systems with (e.g.) large numbers of identical, or similar, components can often be implemented by 'induction' on this number. 
0 Composition: break the verification problem down into several simpler verification problems. 
The last four issues are beyond the scope of this book, but references may be found at the ends of Chapters 3 and 6. 
EXERCISES 3.8 
' * 1. For mutual processes to that <p4is fa 
2. Extend the subformulas [Question: v like that for 
* 3. Write the p of deleting 1 
.So far, this chapte one continue in thj checking is that it 
' implementations w /tion, we look at th, '') SMV ('symbolic m : models we have be, of CTL formulas a SMV is freely dii . can be found at th SMV, but provid reader should read SMV takes as ii 
• and some specific, • • word 'true' if the , ing why the spe, program. SMV programs ming language C, Modules can dec!: 'give the initial , 
\sion in terms of t Z:.non-detenninistic I ;ment at all). Non\ abstraction. 
¢ by callingSAT. ed in the labelling 
¢ by callingSAT. r described in the 
bers of identical.> 1duction' on this •• ; 
) several simpler ' 
1t references may 
181
3.6 11,e SMV system 
* 1. For nrntnal exclusion, draw a transition system which forces the two processes to enter their critical section in strict sequence and show that <f,4 is false of its initial state. 
2. Extend the pseudo-code of Section 3.5.2 so that it can deal with subformnlas AG 1/'1,without rewriting it in terms of other formulas. [Question: will your routine be more like the routine for AF, or more like that for EG on page 175? Why?] 
* 3. Write the pseudo-code for SAT EG, based on the description in terms of deleting labels given in Section 3.5.1. 
3.6 The SMV system 
So far, this chapter has been quite theoretical; and the sections after this 
one continue in this vein. However, one of the exciting things about model 
checking is that it is also a practical subject, for there are several efficient 
implementations which can check large systems in realistic time. In this sec
tion, we look at the best-known of the CTL model checkers, which is called 
SMV ('symbolic model verifier'). It provides a language for describing the 

models we have been drawing as diagrams and it directly checks the validity • of CTL formulas on those models. 
SMV is freely distributed and can be found on the internet. Further details 
can be found at the end of this chapter. We do not give a full introduction 
to SMV, but provide just enough information to give the flavour. The serious 
reader should read more about SMV in the references. 
SMV takes as input a text consisting of a program describing a model 
and some specifications (CTL formulas). It produces as output either the 
word 'true' if the specifications hold for all initial states, or a trace show
ing why the specification is false for the model determined by our 
program. 
SMV programs consist of one or more modules. As in the programming language C, or Java, one of the modules must be called main. Modules can declare variables and assign to them. Assignments usually give the initial value of a variable and its next value as an expression in terms of the current values of variables. This expression can be non-deterministic ( denoted by several expressions in braces, or no assignment at all). Non-determinism is· used to model the environment and for abstraction. 




















































 1 

FUNDAMENTALS OF REAL- TIME SYSTEMS     
The term “ real time ” is used widely in many contexts, both technical and conventional. Most people would probably understand “ in real time ” to mean “ at once ” or  “ instantaneously. ” The Random House Dictionary of the English Language (2nd unabridged edition, 1987), however, defines  “ realtime ” as pertaining to applications in which the computer must respond as rapidly as required by the user or necessitated by the process being controlled . These defi nitions, and others that are available, are quite different, and their differences are often the cause of misunderstanding between computer, software and systems engineers, and the users of real - time systems. On a more pedantic level, there is the issue of the appropriate writing of the term “ real - time.” Across technical and pedestrian literature, various forms of the term, such as real time, real - time, and realtime may appear. But to computer, software, and systems engineers the preferred form is real - time, and this is the convention that we will follow throughout this text. 
Consider a computer system in which data need to be processed at a regular rate. For example, an aircraft uses a sequence of accelerometer pulses to determine its position. Systems other than avionic ones may also require a rapid response to events that occur at nonregular rates, such as handling an overtemperature failure in a nuclear power plant. Even without defi ning the term “ real - time,” it is probably understood that those events demand timely or  “ real - time ” processing. 
Real-Time Systems Design and Analysis: Tools for the Practitioner, Fourth Edition. Phillip A. Laplante and Seppo J. Ovaska. © 2012 the Institute of Electrical and Electronics Engineers, Inc. Published 2012 by John Wiley & Sons, Inc. 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

Now consider a situation in which a passenger approaches an airline check in counter to pick up his boarding pass for a certain flight from New York to Boston, which is leaving in five minutes.The reservation clerk enters appropriate information into the computer, and a few seconds later a boarding pass is printed. Is this a real - time system? 
Indeed, all three systems — aircraft, nuclear power plant, and airline reservations — are real - time, because they must process information within a specified interval or risk system failure.Although these examples may provide an intuitive definition of a real - time system, it is necessary to clearly comprehend when a system is real - time and when it is not. 
To form a solid basis for the coming chapters, we fi rst define a number of central terms and correct common misunderstandings in Section 1.1 . These definitions are targeted for practitioners, and thus they have a strong practical point - of - view. Section 1.2 presents the multidisciplinary design challenges related to real - time systems. It is shown that although real - time systems design and analysis are subdisciplines of computer systems engineering, they have essential connections to various other fields, such as computer science and electrical engineering — even to applied statistics. It is rather straightforward to present different approaches, methods, techniques, or tools for readers, but much more difficult to convey the authors ’  insight on real - time systems to the audience. Nevertheless, our intention is to provide some insight in parallel with specific tools for the practitioner. Such insight is built on practical experiences and adequate understanding of the key milestones in the field. The birth of real - time systems, in general, as well as a selective evolution path related to relevant technological innovations, is discussed in Section  1.3 . Section 1.4 summarizes the preceding sections on fundamentals of real - time systems. Finally, Section 1.5 provides exercises that help the reader to gain basic understanding on real - time systems and associated concepts.
 1.1   CONCEPTS AND MISCONCEPTIONS 
The fundamental definitions of real - time systems engineering can vary depending on the resource consulted. Our pragmatic definitions have been collected and refi ned to the smallest common subset of agreement to form the vocabulary of this particular text. These definitions are presented in a form that is intended to be most useful to the practicing engineer, as opposed to the academic theorist.
 1.1.1   Definitions for Real - Time Systems 
The hardware of a computer solves problems by repeated execution of machine - language instructions, collectively known as software. Software, on the other hand, is traditionally divided into system programs and application programs. 
CONCEPTS AND MISCONCEPTIONS 
System programs consist of software that interfaces with the underlying computer hardware, such as device drivers, interrupt handlers, task schedulers, and various programs that act as tools for the development or analysis of application programs. These software tools include compilers, which translate high - level language programs into assembly code; assemblers, which convert the assembly code into a special binary format called object or machine code; and linkers/locators, which prepare the object code for execution in a specifi c hardware environment. An operating system is a specialized collection of system programs that manage the physical resources of the computer.As such, a real - time operating system is a truly important system program (Anh and Tan, 2009 ). 
Application programs are programs written to solve specific problems, such as optimal hall - call allocation of an elevator bank in a high - rise building, inertial navigation of an aircraft, and payroll preparation for some industrial company. Certain design considerations play a role in the design of system programs and application software intended to run in real - time environments. 
The notion of a “ system ” is central to software engineering, and indeed to all engineering, and warrants formalization.
 Defi nition: System 
A system is a mapping of a set of inputs into a set of outputs. 
When the internal details of the system are not of particular interest, the mapping function between input and output spaces can be considered as a black box with one or more inputs entering and one or more outputs exiting the system (see Fig. 1.1 ). Moreover, Vernon lists five general properties that belong to any  “ system ” (Vernon, 1989 ): 
1. 
A system is an assembly of components connected together in an organized way. 

2. 
A system is fundamentally altered if a component joins or leaves it.

 3.
  It has a purpose.

 4.
  It has a degree of permanence.

 5.
  It has been defined as being of particular interest. 


Inputs Outputs 


Figure 1.1. A general system with inputs and outputs. 
4  Camera  FUNDAMENTALS OF REAL-TIME SYSTEMS Display  
Sensors  Real-Time Control System  Actuators  

... 
... 


Figure 1.2. A real - time control system including inputs from a camera and multiple sensors, as well as outputs to a display and multiple actuators. 

Figure 1.3. A classic representation of a real - time system as a sequence of schedulable jobs. 
Every real - world entity, whether organic or synthetic, can be modeled as a system. In computing systems, the inputs represent digital data from hardware devices or other software systems.The inputs are often associated with sensors, cameras, and other devices that provide analog inputs, which are converted to digital data, or provide direct digital inputs. The digital outputs of computer systems, on the other hand, can be converted to analog outputs to control external hardware devices, such as actuators and displays, or used directly without any conversion (Fig. 1.2 ). 
Modeling a real - time (control) system, as in Figure  1.2 , is somewhat different from the more traditional model of the real - time system as a sequence of jobs to be scheduled and performance to be predicted, which is comparable with that shown in Figure  1.3 .The latter view is simplistic in that it ignores the usual fact that the input sources and hardware under control may be highly complex. In addition, there are other, “ sweeping ” software engineering considerations that are hidden by the model shown in Figure  1.3 . 
Look again at the model of a real - time system shown in Figure  1.2 . In its realization, there is some inherent delay between presentation of the inputs (excitation) and appearance of the outputs (response).This fact can be formalized as follows:
 Defi nition: Response Time 
The time between the presentation of a set of inputs to a system and the realization of the required behavior, including the availability of all associated outputs, is called the response time of the system. 
CONCEPTS AND MISCONCEPTIONS 
How fast and punctual the response time needs to be depends on the characteristics and purpose of the specifi c system. 
The previous definitions set the stage for a practical definition of a real - time system.
 Definition: Real - Time System ( I ) 
A real - time system is a computer system that must satisfy bounded response time constraints or risk severe consequences, including failure. 
But what is a “ failed ” system? In the case of the space shuttle or a nuclear power plant, for example, it is painfully obvious when a failure has occurred. For other systems, such as an automatic bank teller machine, the notion of failure is less obvious. For now, failure will be defined as the “ inability of the system to perform according to system specification, ” or, more precisely:
 Definition: Failed System 
A failed system is a system that cannot satisfy one or more of the requirements stipulated in the system requirements specifi cation. 
Because of this definition of failure, rigorous specification of the system operating criteria, including timing constraints, is necessary.This matter is discussed later in Chapter 5 . 
Various other definitions exist for  “ real - time, ” depending on which source is consulted. Nonetheless, the common theme among all definitions is that the system must satisfy deadline constraints in order to be correct. For instance, an alternative definition might be:
 Definition: Real - Time System ( II ) 
A real - time system is one whose logical correctness is based on both the correctness of the outputs and their timeliness. 
In any case, by making unnecessary the notion of timeliness, every system becomes a real - time system. 
Real - time systems are often reactive or embedded systems. Reactive systems are those in which task scheduling is driven by ongoing interaction with their environment; for example, a fire - control system reacts to certain buttons pressed by a pilot. Embedded systems can be defined informally as follows: 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

 Definition: Embedded System 
An embedded system is a system containing one or more computers (or processors) having a central role in the functionality of the system, but the system is not explicitly called a computer. 
For example, a modern automobile contains many embedded processors that control airbag deployment, antilock braking, air conditioning, fuel injection, and so forth. Today, numerous household items, such as microwave ovens, rice cookers, stereos, televisions, washing machines, even toys, contain embedded computers. It is obvious that sophisticated systems, such as aircraft, elevator banks, and paper machines, do contain several embedded computer systems. 
The three systems mentioned at the beginning of this chapter satisfy the criteria for a real - time system. An aircraft must process accelerometer data within a certain period that depends on the specifications of the aircraft; for example, every 10 ms. Failure to do so could result in a false position or velocity indication and cause the aircraft to go off - course at best or crash at worst. For a nuclear reactor thermal problem, failure to respond swiftly could result in a meltdown. Finally, an airline reservation system must be able to handle a surge of passenger requests within the passenger ’s perception of a reasonable time (or before the fl ights leave the gate). In short, a system does not have to process data at once or instantaneously to be considered real - time; it must simply have response times that are constrained appropriately. 
When is a system real - time? It can be argued that all practical systems are ultimately real - time systems. Even a batch - oriented system — for example, grade processing at the end of a semester or a bimonthly payroll run — is real time. Although the system may have response times of days or even weeks (e.g., the time that elapses between submitting the grade or payroll information and issuance of the report card or paycheck), it must respond within a certain time or there could be an academic or financial disaster. Even a word processing program should respond to commands within a reasonable amount of time or it will become torturous to use. Most of the literature refers to such systems as soft real - time systems.
 Definition: Soft Real - Time System 
A soft real - time system is one in which performance is degraded but not destroyed by failure to meet response - time constraints. 
Conversely, systems where failure to meet response - time constraints leads to complete or catastrophic system failure are called hard real - time systems.
 Definition: Hard Real - Time System 
A hard real - time system is one in which failure to meet even a single deadline may lead to complete or catastrophic system failure. 
CONCEPTS AND MISCONCEPTIONS 
Firm real - time systems are those systems with hard deadlines where some arbitrarily small number of missed deadlines can be tolerated.
 Definition: Firm Real - Time System 
 A firm real - time system is one in which a few missed deadlines will not lead to total failure, but missing more than a few may lead to complete or catastrophic system failure. 
As noted, all practical systems minimally represent soft real - time systems. Table  1.1  gives an illustrative sampling of hard, firm, and soft real - time systems. 
There is a great deal of latitude for interpretation of hard, firm, and soft real - time systems. For example, in the automated teller machine, missing too many deadlines will lead to significant customer dissatisfaction and potentially even enough loss of business to threaten the existence of the bank. This extreme scenario represents the fact that every system can often be characterized any way — soft, firm, or hard — real - time by the construction of a supporting scenario. The careful definition of systems requirements (and, hence, expectations) is the key to setting and meeting realistic deadline expectations. In any case, it is a principal goal of real - time systems engineering to fi nd ways to transform hard deadlines into firm ones, and firm ones into soft ones. 
Since this text is mostly concerned with hard real - time systems, it will use the term real - time system to mean embedded, hard real - time system, unless otherwise noted. 
It is typical, in studying real - time systems, to consider the nature of time, because deadlines are instants in time. Nevertheless, the question arises, “ Where do the deadlines come from? ” Generally speaking, deadlines are based on the underlying physical phenomena of the system under control. For 
TABLE 1.1. A Sampling of Hard, Firm, and Soft Real - Time Systems 
System    Real - Time Explanation Classifi cation 
  Avionics weapons delivery system in which pressing a button launches an air - to - air missile  
  Navigation controller for an autonomous weed  killer robot  
  Console hockey game  
Hard   Missing the deadline to launch the missile within a specifi ed time after pressing the button may cause the target to be missed, which will result in catastrophe   Firm  Missing a few navigation deadlines causes the robot to veer out from a planned path and damage some crops Soft Missing even several deadlines will only degrade performance 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

example, in animated displays, images must be updated at least 30 frames per second to provide continuous motion, because the human eye can resolve updating at a slower rate. In navigation systems, accelerations must be read at a rate that is a function of the maximum velocity of the vehicle, and so on. In some cases, however, real - world systems have deadlines that are imposed on them, and are based on nothing less than guessing or on some forgotten and possibly eliminated requirement. The problem in these cases is that undue constraints may be placed on the systems.This is a primary maxim of real - time systems design — to understand the basis and nature of the timing constraints so that they can be relaxed if necessary. In cost - effective and robust real - time systems, a pragmatic rule of thumb could be: process everything as slowly as possible and repeat tasks as seldom as possible. 
Many real - time systems utilize global clocks and time - stamping for synchronization, task initiation, and data marking. It must be noted, however, that all clocks keep somewhat inaccurate time — even the official U.S. atomic clock must be adjusted regularly. Moreover, there is an associated quantization error with clocks, which may need to be considered when using them for time - stamping. 
In addition to the degree of “ real - time ” (i.e., hard, firm, or soft), also, the punctuality of response times is important in many applications. Hence, we define the concept of real - time punctuality:
 Definition: Real - Time Punctuality 
Real - time punctuality means that every response time has an average value, tR, with upper and lower bounds of tR +εU and tR −εL, respectively, and εU,εL → 0+ . 
In all practical systems, the values of  εU and εL are nonzero, though they may be very small or even negligible. The nonzero values are due to cumulative latency and propagation - delay components in real - time hardware and software. Such response times contain jitter within the interval  t ∈ [−εL, +εU ]. Real time punctuality is particularly important in periodically sampled systems with high sampling rates, for example, in video signal processing and software radio. 
Example: Where a Response Time Comes From 
An elevator door (Pasanen et al., 1991 ) is automatically operated, and it 
may have a capacitive safety edge for sensing possible passengers between 
the closing door blades. Thus, the door blades can be quickly reopened 
before they touch the passenger and cause discomfort or even threaten the 
passenger ’ s safety. 
What is the required system response time from when it recognizes that 
a passenger is between the closing door blades to the instant when it starts 
to reopen the door? 
CONCEPTS AND MISCONCEPTIONS 
This response time consists of five independent components (their presumably measured numerical values are for illustration purpose only): 
Sensor Response Time : tS_min = 5 ms, tS_max = 15 ms, tS_mean = 9 ms. Hardware Response Time : tHW_min = 1 μs, tHW_max = 2 μs, tHW_mean = 1.2 μs. System Software Response Time : tSS_min = 16 μs, tSS_max = 48 μs, tSS_mean = 37 μs. Application Software Response Time : tAS_min = 0.5 μs, tAS_max = 0.5 μs, 
tAS_mean = 0.5 μs. Door Drive Response Time : tDD_min = 300  ms, tDD_max = 500  ms, tDD_mean = 400  ms. Now, we can calculate the minimum, maximum, and mean values of the composite response time: tmin ≈ 305  ms, tmax ≈ 515  ms, and tmean ≈ 409  ms. 
Thus, the overall response time is dominated by the door- drive response time containing the required deceleration time of the moving door blades. 
In software systems, a change in state results in a change in the flow - of - control of the computer program. Consider the flowchart in Figure  1.4 . The decision block represented by the diamond suggests that the stream of program instructions can take one of two alternative paths, depending on the response in question. case, if - then, and while statements in any programming language represent a possible change in flow - of - control. Invocation of procedures in Ada and C represent changes in flow - of - control. In object - oriented 




Figure 1.4. A partial program flowchart showing a conditional branch as a change in flow of control. 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

languages, instantiation of an object or the invocation of a method causes the change in sequential flow - of - control. In general, consider the following definition.
 Defi nition: Event 

Any occurrence that causes the program counter to change nonsequentially is considered a change of flow - of - control, and thus an event. 
In scheduling theory, the release time of a job is similar to an event.
 Defi nition: Release Time 
The release time is the time at which an instance of a scheduled task is ready to run, and is generally associated with an interrupt. 
Events are slightly different from jobs in that events can be caused by interrupts, as well as branches. 
An event can be either synchronous or asynchronous. Synchronous events are those that occur at predictable times in the flow - of - control, such as that represented by the decision box in the flowchart of Figure  1.4 . The change in flow - of - control, represented by a conditional branch instruction, or by the occurrence of an internal trap interrupt, can be anticipated. 
Asynchronous events occur at unpredictable points in the flow - of - control and are usually caused by external sources.A real - time clock that pulses regularly at 5 ms is not a synchronous event. While it represents a periodic event, even if the clock were able to tick at a perfect 5 ms without drift, the point where the tick occurs with the flow - of - control is subject to many factors.These factors include the time at which the clock starts relative to the program and propagation delays in the computer system itself.An engineer can never count on a clock ticking exactly at the rate specified, and so any clock - driven event must be treated as asynchronous. 
Events that do not occur at regular periods are called aperiodic. Furthermore, aperiodic events that tend to occur very infrequently are called sporadic.Table 
1.2  characterizes a sampling of events. 
For example, an interrupt generated by a periodic external clock represents a periodic but asynchronous event. A periodic but synchronous event is one 
TABLE 1.2. Taxonomy of Events and Some Typical Examples 

Periodic  Aperiodic  Sporadic  
Synchronous Asynchronous    Cyclic code    Clock interrupt     Conditional branch    Regular, but not fixed - period interrupt   Divide - by - zero (trap) interrupt   Power - loss alarm   

These items will be discussed further in Chapters  2 and 3 . 
CONCEPTS AND MISCONCEPTIONS 
represented by a sequence of invocation of software tasks in a repeated, circular fashion. A typical branch instruction that is not part of a code block and that runs repeatedly at a regular rate represents a synchronous but aperiodic event.A branch instruction that happens infrequently, say, on the detection of some exceptional condition, is both sporadic and synchronous. Finally, interrupts that are generated irregularly by an external device are classifi ed as either asynchronous aperiodic or sporadic, depending on whether the interrupt is generated frequently or not with respect to the system clock. 
In every system, and particularly in an embedded real - time system, maintaining overall control is extremely important. For any physical system, certain states exist under which the system is considered to be out of control; the software controlling such a system must therefore avoid these states. For example, in certain aircraft guidance systems, rapid rotation through a 180 ° pitch angle can cause loss of gyroscopic control. Hence, the software must be able to anticipate and avert all such scenarios. 
Another characteristic of a software - controlled system is that the processor continues to fetch, decode, and execute instructions correctly from the program area of memory, rather than from data or other unwanted memory regions. The latter scenario can occur in poorly tested systems and is a catastrophe from which there is almost no hope of recovery. 
Software control of any real - time system and associated hardware is maintained when the next state of the system, given the current state and a set of inputs, is predictable. In other words, the goal is to anticipate how a system will behave in all possible circumstances.
 Definition: Deterministic System 
A system is deterministic, if for each possible state and each set of inputs, a unique set of outputs and next state of the system can be determined. 
Event determinism means the next states and outputs of a system are known for each set of inputs that trigger events. Thus, a system that is deterministic is also event deterministic. Although it would be difficult for a system to be deterministic only for those inputs that trigger events, this is plausible, and so event determinism may not imply determinism. 
It is interesting to note that while it is a significant challenge to design systems that are completely event deterministic, and as mentioned, it is possible to inadvertently end up with a system that is nondeterministic, it is defi nitely hard to design systems that are deliberately nondeterministic. This situation arises from the utmost difficulties in designing perfect random number generators. Such deliberately nondeterministic systems would be desirable, for example, as casino gaming machines. 
Finally, if in a deterministic system the response time for each set of outputs is known, then the system also exhibits temporal determinism. 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

A side benefit of designing deterministic systems is that guarantees can be given that the system will be able to respond at any time, and in the case of temporally deterministic systems, when they will respond. This fact reinforces the association of  “ control ” with real - time systems.
 The final and truly important term to be defined is a critical measure of real - time system performance. Because the central processing unit  ( CPU ) continues to fetch, decode, and execute instructions as long as power is applied, the CPU will more or less frequently execute either no - ops or instructions that are not related to the fulfillment of a specific deadline (e.g., noncritical “ housekeeping ” ). The measure of the relative time spent doing nonidle processing indicates how much real - time processing is occurring.
 Definition: CPU  Utilization Factor 
The CPU utilization or time - loading factor, U, is a relative measure of the nonidle processing taking place. 
A system is said to be time - overloaded if  U > 100%. Systems that are too highly utilized are problematic, because additions, changes, or corrections cannot be made to the system without risk of time - overloading. On the other hand, systems that are not sufficiently utilized are not necessarily cost - effective, because this implies that the system was overengineered and that costs could likely be reduced with less expensive hardware. While a utilization of 50% is common for new products, 80% might be acceptable for systems that do not expect growth. However, 70% as a target for  U is one of the most celebrated and potentially useful results in the theory of real - time systems where tasks are periodic and independent — a result that will be examined in Chapter  3 . Table  1.3 gives a summary of certain CPU utilizations and typical situations in which they are associated. 
U is calculated by summing the contribution of utilization factors for each (periodic or aperiodic) task. Suppose a system has  n ≥ 1 periodic tasks, each with an execution period of pi, and hence, execution frequency, fi = 1/pi. If task i is known to have (or has been estimated to have) a worst- case execution time of ei, then the utilization factor, ui, for task  i is
  TABLE 1.3. CPU Utilization (%) Zones 

   Utilization (%)      Zone Type      Typical Application   
<26    Unnecessarily safe     Various   
26 – 50    Very safe     Various   
51 – 68  Safe    Various   
69    Theoretical limit     Embedded systems   
70 – 82  Questionable    Embedded systems   
83 – 99  Dangerous    Embedded systems   
100  Critical    Marginally stressed systems   
>100  Overloaded    Stressed systems   

CONCEPTS AND MISCONCEPTIONS 
u =e 

pi. (1.1)
ii 

Furthermore, the overall system utilization factor is 
nn 

pi. (1.2)
U = ui = ei
∑∑ 
i=1 i=1 

Note that the deadline for a periodic task i, di, is a critical design factor that is constrained by ei. The determination of  ei, either prior to, or after the code has been written, can be extremely difficult, and often impossible, in which case estimation or measuring must be used. For aperiodic and sporadic tasks, ui is calculated by assuming a worst - case execution period, usually the minimum possible time between corresponding event occurrences. Such approximations can inflate the utilization factor unnecessarily or lead to overconfi dence because of the tendency to “ not worry ” about its excessive contribution. The danger is to discover later that a higher frequency of occurrence than budgeted has led to a time - overload and system failure. 
The utilization factor differs from CPU throughput, which is a measure of the number of machine - language instructions per second that can be processed based on some predetermined instruction mix.This type of measurement is typically used to compare CPU throughput for a particular application. 
Example: Calculation of the  CPU  Utilization Factor 
An individual elevator controller in a bank of high - rise elevators has the following software tasks with execution periods of pi and worst - case execution times of ei, i ∈ {1, 2, 3, 4}: 
Task 1 : Communicate with the group dispatcher (19.2 K bit/s data rate 
and a proprietary communications protocol); p1 = 500 ms, e1 = 17 ms. 
Task 2 : Update the car position information and manage floor - to - fl oor 
runs, as well as door control; p2 = 25 ms, e2 = 4 ms. 
Task 3 : Register and cancel car calls; p3 = 75 ms, e3 = 1 ms. 
Task 4 : Miscellaneous system supervisions; p4 = 200 ms, e4 = 20 ms. 
What is the overall CPU utilization factor? 
4 
174120
U =∑ei 
pi = +++ ≈031
. 
i=1 500 25 75 200 

Hence, the utilization percentage is 31%, which belongs to the “ very safe ” zone of Table  1.3 . 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

The choice of task deadlines, estimation and reduction of execution times, and other factors that influence CPU utilization will be discussed in Chapter 7 .
 1.1.2   Usual Misconceptions 
As a part of truly understanding the nature of real - time systems, it is important to address a number of frequently cited misconceptions.These are summarized as follows:
 1.
  Real - time systems are synonymous with  “ fast ” systems.

 2.
  Rate - monotonic analysis has solved  “ the real - time problem. ”

 3.
  There are universal,widely accepted methodologies for real - time systems specification and design. 

4. 
There is no more a need to build a real - time operating system, because many commercial products exist.

 5.
  The study of real - time systems is mostly about scheduling theory.


 The first misconception, that real - time systems must be fast, arises from the fact that many hard real - time systems indeed deal with deadlines in the tens of milliseconds, such as the aircraft navigation system. In a typical food industry application, however, pasta - sauce jars can move along the conveyor belt past a filling point at a rate of one every five seconds. Furthermore, the airline reservation system could have a deadline of 15 seconds. These latter deadlines are not particularly fast, but satisfying them determines the success or failure of the system. 
The second misconception is that rate - monotonic systems provide a simple recipe for building real - time systems. Rate - monotonic systems — a periodic system in which interrupt (or software task) priorities are assigned such that the faster the rate of execution, the higher the priority — have received a lot of attention since the 1970s. While they provide valuable guidance in the design of real - time systems, and while there is abundant theory surrounding them, they are not a panacea. Rate - monotonic systems will be discussed in great detail in Chapter 3 . 
What about the third misconception? Unfortunately, there are no universally accepted and infallible methods for the specification and design of real time systems. This is not a failure of researchers or the software industry, but is because of the diffi culty of discovering universal solutions for this demanding field. After nearly 40 years of research and development, there is still no methodology available that answers all of the challenges of real - time specifi cation and design all the time and for all applications. 
The fourth misconception is that there is no more a need to build a real time operating system from scratch.While there are a number of cost - effective, popular, and viable commercial real - time operating systems, these, too, are not 
MULTIDISCIPLINARY DESIGN CHALLENGES 
a panacea. Commercial solutions have certainly their place, but choosing when to use an off - the - shelf solution and choosing the right one are challenges that will be considered in Chapter 3 . 
Finally, while it is scholarly to study scheduling theory, from an engineering standpoint, most published results require impractical simplifi cations and clairvoyance in order to make the theory work. Because this is a textbook for practicing engineers, it avoids any theoretical results that resort to these measures.
 1.2   MULTIDISCIPLINARY DESIGN CHALLENGES 
The study of real - time systems is a truly multidimensional subdiscipline of computer systems engineering that is strongly influenced by control theory, operations research, and, naturally, software engineering. Figure  1.5 depicts some of the disciplines of computer science, electrical engineering, systems engineering, and applied statistics that affect the design and analysis of real - time systems. Nevertheless, those representative disciplines are not the only ones having a relationship with real - time systems. Because real - time systems engineering is so multidisciplinary, it stands out as a fascinating study area with a rich set of design challenges. Although the fundamentals of real time systems are well established and have considerable permanence, real time systems is a lively developing area due to evolving CPU architectures, distributed system structures, versatile wireless networks, and novel applications, for instance. 

Figure 1.5. A variety of disciplines that affect real - time systems engineering. 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

1.2.1   Infl uencing Disciplines 
The design and implementation of real - time systems requires attention to numerous practical issues. These include:
 • 
The selection of hardware and system software, and evaluation of the trade - off needed for a competitive solution, including dealing with distributed computing systems and the issues of concurrency and synchronization.

 • 
  Specification and design of real - time systems, as well as correct and inclusive representation of temporal behavior.

 • 
Understanding the nuances of the high - level programming language(s) and the real - time implications resulting from their optimized compilation into machine - language code.

 • 
  Optimizing (with application - specific objectives) of system fault tolerance and reliability through careful design and analysis.

 • 
The design and administration of adequate tests at different levels of hierarchy, and the selection of appropriate development tools and test equipment.

 • 
Taking advantage of open systems technology and interoperability. An open system is an extensible collection of independently written applications that cooperate to function as an integrated system. For example, several versions of the open operating system, Linux, have emerged for use in various real - time applications (Abbott, 2006 ). Interoperability can be measured in terms of compliance with open system standards, such as the real - time  CORBA  ( common object request broker architecture ) standard (Fay - Wolfe et al., 2000 ).

 • 
Finally, estimating and measuring response times and (if needed) reducing them. Performing a schedulability analysis, that is, determining and guaranteeing deadline satisfaction, a priori. 


Obviously, the engineering techniques used for hard real - time systems can be used in the engineering of all other types of systems as well, with an accompanying improvement of performance and robustness. This alone is a signifi cant reason to study the engineering of real - time systems.
 1.3   BIRTH AND EVOLUTION OF REAL - TIME SYSTEMS 
The history of real - time systems, as characterized by important developments in the United States, is tied inherently to the evolution of the computer. Modern real - time systems, such as those that control nuclear power plants, military weapons systems, or medical monitoring equipment, are sophisticated, yet many still exhibit characteristics of those pioneering systems developed in the 1940s through the 1960s. 
BIRTH AND EVOLUTION OF REAL-TIME SYSTEMS 
1.3.1   Diversifying Applications 
Embedded real - time systems are so pervasive and ubiquitous that they are even found in household appliances, sportswear, and toys. A small sampling of real - time domains and corresponding applications is given in Table  1.4 . An excellent example of an advanced real - time system is the Mars Exploration Rover of NASA shown in Figure  1.6 . It is an autonomous system with extreme reliability requirements; it receives commands and sends measurement data over radio - communications links; and performs its scientific missions with the aid of multiple sensors, processors, and actuators. 
In the introductory paragraphs of this chapter, some real - time systems were mentioned. The following descriptions provide more details for each system, while others provide additional examples. Clearly, these descriptions are not rigorous specifications.The process of specifying real - time systems unambiguously but concisely is discussed in Chapter 5 . 
Consider the inertial measurement system for an aircraft. The software specification states that the software will receive  x, y, and z accelerometer pulses at a 10 ms rate from special hardware. The software will determine the acceleration components in each direction, and the corresponding roll, pitch, and yaw of the aircraft. 
The software will also collect other information, such as temperature at a 1 - second rate. The task of the application software is to compute the actual velocity vector based on the current orientation, accelerometer readings, and various compensation factors (such as for temperature effects) at a 40 ms rate. The system is to output true acceleration, velocity, and position vectors to a pilot ’s display every 40 ms, but using a different clock.
  TABLE 1.4.  Typical Real - Time Domains and Diverse Applications 

Domain  Applications  
Aerospace    Flight control   
Navigation  
  Pilot interface   
Civilian    Automotive systems   
  Elevator control   
  Traffic light control  
Industrial    Automated inspection   
  Robotic assembly line   
  Welding control   
Medical  Intensive care monitors  
Magnetic resonance imaging  
  Remote surgery   
Multimedia    Console games   
  Home theaters   
Simulators  

FUNDAMENTALS OF REAL-TIME SYSTEMS 


Figure 1.6. Mars Exploration Rover; a solar- powered, autonomous real - time system with radio - communications links and a variety of sensors and actuators. Photo courtesy of NASA. 
These tasks execute at four different rates in the inertial measurement system, and need to communicate and synchronize. The accelerometer readings must be time - relative or correlated; that is, it is not allowed to mix an x accelerometer pulse of discrete time instant k with y and z pulses of instant k + 1. These are critical design issues for this system. 
Next, consider a monitoring system for a nuclear power plant that will be handling three events signaled by interrupts.The first event is triggered by any of several signals at various security points, which will indicate a security breach. The system must respond to this signal within one second. The second and most important event indicates that the reactor core has reached an overtemperature.This signal must be dealt with within 1 millisecond (1 ms). Finally, an operator ’s display is to be updated at approximately 30 times per second. The nuclear- power- plant system requires a reliable mechanism to ensure that the “ meltdown imminent ” indicator can interrupt any other processing with minimal latency. 
As another example, recall the airline reservation system mentioned earlier. Management has decided that to prevent long lines and customer dissatisfaction, turnaround time for any transaction must be less than 15 seconds, and no overbooking will be permitted. At any time, several travel agents may try to access the reservations database and perhaps book the same fl ight simultaneously. Here, effective record - locking and secure communications mechanisms 
BIRTH AND EVOLUTION OF REAL-TIME SYSTEMS 
are needed to protect against the alteration of the database containing the reservation information by more than one clerk at a time. 
Now, consider a real - time system that controls all phases of the bottling of jars of pasta sauce as they travel along a conveyor belt. The empty jars are first microwaved to disinfect them. A mechanism fills each jar with a precise serving of specific sauce as it passes beneath. Another station caps the fi lled bottles. In addition, there is an operator ’s display that provides an animated rendering of the production line activities. There are numerous events triggered by exceptional conditions, such as the conveyor belt jamming and a bottle overflowing or breaking. If the conveyor belt travels too fast, the bottle will move past its designated station prematurely. Therefore, there is a wide range of events, both synchronous and asynchronous, to be dealt with. 
As a final example, consider a system used to control a set of traffi c lights at a four- way traffic intersection (north - , south - , east - , and west - bound traffi c). This system controls the lights for vehicle and pedestrian traffi c at a four- way intersection in a busy city like Philadelphia. Input may be taken from cameras, emergency - vehicle transponders, push buttons, sensors under the ground, and so on. The traffic lights need to operate in a synchronized fashion, and yet react to asynchronous events — such as a pedestrian pressing a button at a crosswalk. Failure to operate in a proper fashion can result in automobile accidents and even fatalities. 
The challenge presented by each of these systems is to determine the appropriate design approach with respect to the multidisciplinary issues discussed in Section 1.2 .
 1.3.2   Advancements behind Modern Real - Time Systems 
Much of the theory of real - time systems is derived from the surrounding disciplines shown in Figure  1.5 . In particular, certain aspects of operations research (i.e., scheduling), which emerged in the late 1940s, and queuing theory in the early 1950s, have influenced most of the more theoretical results. 
Martin published one of the first and certainly the most infl uential early book on real - time systems (Martin, 1967 ). Martin ’s book was soon followed by several others (e.g., Stimler, 1969 ), and the influence of operations research and queuing theory can be seen in these works. It is also educational to study these texts in the context of the great limitations of the hardware of the time. 
In 1973, Liu and Layland published their seminal work on rate - monotonic theory (Liu and Layland, 1973 ). Over the last nearly 40 years, signifi cant refi nement of this theory has made it a practical theory for use in designing real - time systems. 
The 1980s and 1990s saw a proliferation of theoretical work on improving predictability and reliability of real - time systems, and on solving problems related to multitasking systems. Today, a rather small group of experts continues to study pure issues of scheduling and performance analysis, while a larger group of generalist systems engineers tackles broader issues relating to the 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

implementation of practical systems. An important paper by Stankovic et al. (Stankovic et al.,1995 ) described some of the difficulties in conducting research on real - time systems — even with significant restriction of the system, most problems relating to scheduling are too difficult to solve by analytic techniques. 
Instead of any single “ groundbreaking ” technology, the new millennium saw a number of important advancements in hardware, viable open - source software for real - time systems, powerful commercial design and implementation tools, and expanded programming language support.These advancements have in some ways simplified the construction and analysis of real - time systems but on the other hand introduced new problems because of the complexities of systems interactions and the masking of many of the underlying subtleties of time constraints. 
The origin of the term  real- time computing is unclear. It was probably fi rst used either with project Whirlwind, a flight simulator developed by IBM for the U.S. Navy in 1947, or with SAGE, the Semiautomatic Ground Environment air defense system developed for the U.S. Air Force in the late 1950s. Both of these projects qualify as real - time systems even by today ’s definitions. In addition to its real - time contributions, the Whirlwind project included the fi rst use of ferrite core memory ( “ fast ” ) and a form of high - level language compiler that predated Fortran. 
Other early real - time systems were used for airline reservations, such as SABRE (developed for American Airlines in 1959), as well as for process control, but the advent of the national space program provided even greater opportunities for the development of more advanced real - time systems for spacecraft control and telemetry. It was not until the 1960s that rapid development of such systems took place, and then only as signifi cant nonmilitary interest in real - time systems become coupled with the availability of equipment adapted to real - time processing. 
Low - performance processors and particularly slow and small memories handicapped many of the earliest systems. In the early 1950s, the asynchronous interrupt was introduced and later incorporated as a standard feature in the Univac Scientific 1103A.The middle 1950s saw a distinct increase in the speed and complexity of large - scale computers designed for scientifi c computation, without an increase in physical size. These developments made it possible to apply real - time computation in the field of control systems. Such hardware improvements were particularly noticeable in IBM ’s development of SAGE. 
In the 1960s and 1970s, advances in integration levels and processing speeds enhanced the spectrum of real - time problems that could be solved. In 1965 alone, it was estimated that more than 350 real - time process control systems existed (Martin, 1967 ). 
The 1980s and 1990s have seen, for instance, distributed systems and non von Neumann architectures utilized in real - time applications. 
Finally, the late 1990s and early 2000s have set new trends in real - time embedded systems in consumer products and Web - enabled devices.The avail
SUMMARY 

ability of compact processors with limited memory and functionality has rejuvenated some of the challenges faced by early real - time systems designers. Fortunately, around 60 years of experience is now available to draw upon. 
Early real - time systems were written directly in microcode or assembly language, and later in higher- level languages. As previously noted, Whirlwind used an early form of high - level language called an algebraic compiler to simplify coding. Later systems employed Fortran, CMS - 2, and JOVIAL, the preferred languages in the U.S. Army, Navy, and Air Force, respectively. 
In the 1970s, the Department of Defense  ( DoD ) mandated the development of a single language that all military services could use, and that provided high - level language constructs for real - time programming. After a careful selection and refinement process, the Ada language appeared as a standard in 1983. Shortfalls in the language were identified, and a new, improved version of the language, Ada 95, appeared in 1995. 
Today, however, only a small number of systems are developed in Ada. Most embedded systems are written in C or C++. In the last 10 years, there has been a remarkable increase in the use of object - oriented methodologies, and languages like C++ and Java in embedded real - time systems.The real - time aspects of programming languages are discussed later in Chapter 4 .
 The first commercial operating systems were designed for the early mainframe computers. IBM developed the first real - time executive, the Basic Executive, in 1962, which provided diverse real - time scheduling. By 1963, the Basic Executive II had disk - resident system and user programs. 
By the mid - 1970s, more affordable minicomputer systems could be found in many engineering environments. In response, a number of important real time operating systems were developed by the minicomputer manufacturers. Notable among these were the Digital Equipment Corporation  ( DEC ) family of real - time multitasking executives  ( RSX ) for the PDP - 11, and Hewlett Packard ’s  Real - Time Executive  ( RTE ) series of operating systems for its HP 2000 product line. 
By the late 1970s and early 1980s, the first real - time operating systems for microprocessor- based applications appeared. These included RMX 80, MROS 68K, VRTX, and several others. Over the past 30 years, many commercial real - time operating systems have appeared, and many have disappeared. 
A selective summary of landmark events in the field of real - time systems in the United States is given in Table 1.5 .
 1.4   SUMMARY 
The deep - going roots of real - time systems were formed during the historical years of computers and computing — before the microprocessor era. However, the first “ boom ” of real - time systems took place around the beginning of 1980s, when appropriate microprocessors and real - time operating systems became 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

TABLE 1.5. Landmarks in Real - Time Systems History in the United States 

   Year   Landmark  Developer  Development  Innovations  
1947    Whirlwind   IBM    Flight simulator     Ferrite core  
memory  
( “ fast ” ),  
high - level  
language 
 1957    SAGE   IBM    Air defense     Designed for  
real - time 
 1958    Scientifi c  Univac    General purpose   Asynchronous  
1103A interrupt 
 1959  SABRE  IBM    Airline reservation   “ Hub - go - ahead ”  
policy   
1962  Basic  IBM    General purpose     Diverse real - time  
Executive scheduling 
 1963  Basic  IBM    General purpose   Disk - resident  
Executive II  system/user  
programs 
 1970s    RSX, RTE     DEC, HP   Real - time    Hosted by  
operating  minicomputers 
systems 
 1973  Rate    Liu and  Fundamental    Upper bound on  
monotonic  Layland theory utilization for  
system schedulable  
systems 
 1970s  RMX - 80,    Various   Real - time    Hosted by  
and  MROS 68K,  operating  microprocessors 
1980s VRTX, etc. systems 
 1983    Ada 83     U.S. DoD  Programming    For mission  
language  critical  
embedded  
systems 
 1995    Ada 95   Community  Programming    Improved version  
language of Ada 83  
2000s  –  –    Various advances    A continuously  
in hardware,  growing range  
open - source, and  of innovative  
commercial  applications  
system software  that can be  
and tools  “ real - time ”  

available (to be used in embedded systems) for an enormous number of electrical, systems, as well as mechanical and aerospace engineers.These practicing engineers did not have much software or even computer education, and, thus, the initial learning path was laborious in most fields of industry. In those early times, the majority of real - time operating systems and communications proto
SUMMARY 

cols were proprietary designs — applications people were developing both system and application software themselves. But the situation started to improve with the introduction of more effective high - level language compilers, software debugging tools, communications standards, and, gradually, also methodologies and associated tools for professional software engineering. 
What is left from those pioneering years approximately 30 years ago? Well, the foundation of real - time systems is still remarkably the same. The core issues, such as the different degrees of real - time and deterministic requirements, as well as real - time punctuality, are continuing to set major design challenges. Besides, the basic techniques of multitasking and scheduling, and the accompanying inter- task communication and synchronization mechanisms, are used even in modern real - time applications. Hence, real - time systems knowledge has a long lifetime. Nonetheless, much fruitful development is taking place in real - time systems engineering worldwide: new specifi cation and design methods are introduced; innovative processor and system architectures become available and practical; flexible and low - cost wireless networks gain popularity; and numerous novel applications appear continuously, for example, in the field of ubiquitous computing. 
We can fairly conclude that real - time systems engineering is a sound and timely topic for junior- senior level, graduate, and continuing education; and it offers growing employment potential in various industries. In the coming chapters, we will cover a broad range of vital themes for practicing engineers (see Fig. 1.7 ). While the emphasis is on software issues, the fundamentals of real - time hardware are carefully outlined as well. Our aim is to provide a comprehensive text to be used also in industrial settings for new real - time system designers, who need to get “ up to speed ” quickly. That aim is highlighted in this fourth edition of Real - Time Systems Design and Analysis, with the descriptive subtitle Tools for the Practitioner. 

Figure 1.7. Composition of this unique text from nine complementary chapters. 
FUNDAMENTALS OF REAL-TIME SYSTEMS 

1.5 EXERCISES 
1.1. Consider a payroll processing system for an elevator company. Describe three different scenarios in which the system can be justified as hard, firm, or soft real - time. 
1.2. Discuss whether the following are hard, firm, or soft real - time systems: 
(a)
  The Library of Congress print - manuscript database system. 

(b) 
A police database that provides information on stolen automobiles. 

(c) 
An automatic teller machine in a shopping mall. 

(d) 
A coin - operated video game in some amusement park. 

(e)
  A university grade - processing system. 

(f) 
A computer- controlled routing switch used at a telephone company branch exchange. 


1.3. Consider a real - time weapons control system aboard a fi ghter aircraft. Discuss which of the following events would be considered synchronous and which would be considered asynchronous to the real - time computing system. 
(a)
  A 5 - ms, externally generated clock interrupt. 

(b)
  An illegal - instruction - code (trap) interrupt. 

(c)
  A built - in - test memory failure. 

(d) 
A discrete signal generated by the pilot pushing a button to fi re a missile. 

(e)
  A discrete signal indicating “ low on fuel. ” 


1.4. Describe a system that is completely nonreal - time, that is, there are no bounds whatsoever for any response time. Do such systems exist in reality? 
1.5. For the following systems concepts, fill in the cells of Table  1.2 with descriptors for possible events. Estimate event periods for the periodic events. 
(a) 
Elevator group dispatcher: this subsystem makes optimal hall - call allocation for a bank of high - speed elevators that service a 40 - story building in a lively city like Louisville. 

(b) 
Automotive control: this on - board crash avoidance system uses data from a variety of sensors and makes decisions and affects behavior to avoid collision, or protect the occupants in the event of an imminent collision. The system might need to take control of the automobile from the driver temporarily. 


1.6. For the real - time systems in Exercise 1.2, what are reasonable response times for all those events? 
REFERENCES 

1.7. For the example systems introduced (inertial measurement, nuclear-power- plant monitoring, airline reservation, pasta bottling, and traffi c light control) enumerate some possible events and note whether they are periodic, aperiodic, or sporadic. Discuss reasonable response times for the events. 
1.8. In the response - time example of Section  1.1 , the time from observing a passenger between the closing door blades and starting to reopen the elevator door varies between 305 and 515 ms. How could you further justify if these particular times are appropriate for this situation? 
1.9. A control system is measuring its feedback quantity at the rate of 100 μs. Based on the measurement, a control command is computed by a heuristic algorithm that uses complex decision making. The new command becomes available 27 – 54  μs (rather evenly distributed) after each sampling moment. This considerable jitter introduces harmful distortion to the controller output. How could you avoid (reduce) such a jitter? What (if any) are the drawbacks of your solution? 
1.10. Reconsider the CPU utilization factor example of Section 1.1 . How short could the execution period of Task 1, e1, be made to maintain the CPU utilization zone no worse than  “ questionable ” (Table 1.3 )? 
REFERENCES 

    D. Abbott, Linux for Embedded and Real - Time Applications , 2nd Edition . Burlington, MA : Newnes , 2006 .
    T. N. B. Anh and   S. - L. Tan  , “Real - time operating systems for small microcontrollers , ” IEEE Micro , 29 ( 5 ), pp. 30–45 , 2009 .
    V.Fay - Wolfe   et al., “  Real - time CORBA , ”IEEE Transactions on Parallel and Distributed Systems, 11 ( 10 ), pp. 1073–1089 , 2000 .
    C. L. Liu   and   J. W. Layland, “Scheduling algorithms for multi - programming in a hard real - time environment , ” Journal of the ACM, 20 ( 1 ), pp. 46–61 , 1973 .
    J. Martin, Design of Real - Time Computer Systems. Englewood Cliffs, NJ : Prentice - Hall , 1967 .
    J. Pasanen,  P. Jahkonen  ,  S. J. Ovaska,  H. Tenhunen  ,and   O. Vainio,“  An integrated digital motion control unit , ” IEEE Transactions on Instrumentation and Measurement,  40 ( 3 ), pp. 654–657 , 1991 .
    J. A. Stankovic,  M. Spuri  ,  M. Di Natale, and   G. C. Buttazzo, “Implications of classical scheduling results for real - time systems , ” IEEE Computer , 28 ( 6 ), pp. 16–25 , 1995 .
    S. Stimler, Real - Time Data - Processing Systems. New York : McGraw - Hill , 1969 .
    P. Vernon  , “Systems in engineering , ” IEE Review , 35 ( 10 ), pp. 383–385 , 1989 . 
A Tutorial on Uppaal 4.0 
Updated November 28, 2006 
Gerd Behrmann, Alexandre David, and Kim G. Larsen 
Department of Computer Science, Aalborg University, Denmark {behrmann,adavid,kgl}@cs.auc.dk. 
Abstract. This is a tutorial paper on the tool Uppaal. Its goal is to be a short introduction on the flavour of timed automata implemented in the tool, to present its interface, and to explain how to use the tool. The contribution of the paper is to provide reference examples and modelling patterns. 
1 Introduction 
Uppaal is a toolbox for verification of real-time systems jointly developed by Uppsala University and Aalborg University. It has been applied successfully in case studies ranging from communication protocols to multimedia applications [35,55,24,23,34,43,54,44,30]. The tool is designed to verify systems that can be modelled as networks of timed automata extended with integer variables, structured data types, user defined functions, and channel synchronisation. 
The first version of Uppaal was released in 1995 [52]. Since then it has been in constant development [21,5,13,10,26,27]. Experiments and improvements include data structures [53], partial order reduction [20], a distributed version of Uppaal [17,9], guided and minimal cost reachability [15,51,16], work on UML Statecharts [29], acceleration techniques [38], and new data structures and memory reductions [18,14]. Version 4.0 [12] brings symmetry reduction [36], the generalised sweep-line method [49], new abstraction techniques [11], priorities [28], and user defined functions to the mainstream. Uppaal has also generated related Ph.D. theses [50,57,45,56,19,25,32,8,31]. It features a Java user interface and a verification engine written in C++ . It is freely available at http://www.uppaal.com/. 
This tutorial covers networks of timed automata and the flavour of timed automata used in Uppaal in section 2. The tool itself is described in section 3, and three extensive examples are covered in sections 4, 5, and 6. Finally, section 7 introduces common modelling patterns often used with Uppaal. 
2 Timed Automata in Uppaal 
The model-checker Uppaal is based on the theory of timed automata [4] (see [42] for automata theory) and its modelling language o ers additional features such as bounded integer variables and urgency. The query language of Uppaal, used to specify properties to be checked, is a subset of TCTL (timed computation tree logic) [39,3]. In this section we present the modelling and the query languages of Uppaal and we give an intuitive explanation of time in timed automata. 
2.1 The Modelling Language 
Networks of Timed Automata A timed automaton is a finite-state machine extended with clock variables. It uses a dense-time model where a clock variable evaluates to a real number. All the clocks progress synchronously. In Uppaal, a system is modelled as a network of several such timed automata in parallel. The model is further extended with bounded discrete variables that are part of the state. These variables are used as in programming languages: They are read, written, and are subject to common arithmetic operations. A state of the system is defined by the locations of all automata, the clock values, and the values of the discrete variables. Every automaton may fire an edge (sometimes misleadingly called a transition) separately or synchronise with another automaton1 , which leads to a new state. 
Figure 1(a) shows a timed automaton modelling a simple lamp. The lamp has three locations: off, low, and bright. If the user presses a button, i.e., synchronises with press?, then the lamp is turned on. If the user presses the button again, the lamp is turned o . However, if the user is fast and rapidly presses the button twice, the lamp is turned on and becomes bright. The user model is shown in Fig. 1(b). The user can press the button randomly at any time or even not press the button at all. The clock y of the lamp is used to detect if the user was fast (y< 5) or slow (y> = 5). 
press? 

(a) Lamp. (b) User. 
Fig. 1. The simple lamp example. 
We give the basic definitions of the syntax and semantics for the basic timed automata. In the following we will skip the richer flavour of timed automata supported in Uppaal, i.e., with integer variables and the extensions of urgent and committed locations. For additional information, please refer to the help 
1 or several automata in case of broadcast synchronisation, another extension of timed automata in Uppaal. 
2 

menu inside the tool. We use the following notations: C is a set of clocks and B (C ) is the set of conjunctions over simple conditions of the form x ⊲⊳c or x − y ⊲⊳c, where x, y ∈ C , c ∈ N and ⊲⊳∈{<, ≤, =, ≥,>}. A timed automaton is a finite directed graph annotated with conditions over and resets of non-negative real valued clocks. 
Definition 1 (Timed Automaton (TA)). A timed automaton is a tuple (L, l0 , C, A, E, I ), where L is a set of locations, l0 ∈ L is the initial location, C is the set of clocks, A is a set of actions, co-actions and the internal τ -action, E ⊆ L × A × B (C ) × 2C × L is a set of edges between locations with an action, a guard and a set of clocks to be reset, and I : L → B (C ) assigns invariants to locations. &#3; 
In the previous example on Fig. 1, y:=0 is the reset of the clock y , and the labels press? and press! denote action–co-action (channel synchronisations here). We now define the semantics of a timed automaton. A clock valuation is a function u : C → R≥0 from the set of clocks to the non-negative reals. Let RC be the set of all clock valuations. Let u0 (x)=0 for all x ∈ C . We will abuse the notation by considering guards and invariants as sets of clock valuations, writing u ∈ I (l ) to mean that u satisfies I (l ). 
AB 

������
&#1;&#1;&#1;&#1;&#1;&#1;
action transition

��������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;
AB 

x<3 
������
&#1;&#1;&#1;&#1;&#1;&#1; 
<B,x=1>

�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;
delay(+1) transition
�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;
�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
x<3 action
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1; 
A BA B 
state: <A,x=1> �������&#1;&#1;&#1;&#1;&#1;&#1;&#1; transition�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;
�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
�������
������&#1;&#1;&#1;&#1;&#1;&#1; 


OK 

������
&#1;&#1;&#1;&#1;&#1;&#1;&#1; &#1;&#1;&#1;&#1;&#1;&#1;
����
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;
�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������

&#1;&#1;&#1;&#1;&#1;&#1;&#1;
&#1;&#1;&#1;&#1;&#1;&#1;&#1; x<3 x<3
��������������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������&#1;&#1;&#1;&#1;&#1;&#1;&#1; <A,x=2> <A,x=3>
�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1; 
invalid �����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;
delay(+2) transition �����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;action ������������������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1; AB &#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;B
������� A �������
����������������������
&#1;&#1;&#1;&#1;&#1;&#1;&#1; 
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;
&#1;&#1;&#1;&#1;&#1;&#1;&#1;�������
������� transition �����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;
&#1;&#1;&#1;&#1;&#1;&#1;&#1; 
������&#1;&#1;&#1;&#1;&#1;&#1; ����
&#1;&#1;&#1;&#1; 
�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;x<3 &#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;x<3
����������������������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�����������
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;�����������
<A,x=3> <A,x=3>
&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;&#1;
invalid state: invariant x<3 violated
Fig. 2. Semantics of TA: di erent transitions from a given initial state. 
Definition 2 (Semantics of TA). Let (L, l0 , C, A, E, I ) be a timed automaton. The semantics is defined as a labelled transition system S, s0 , →, where S ⊆ L × RC is the set of states, s0 =(l0 ,u0 ) is the initial state, and →⊆ S ×(R≥0 ∪A)×S is the transition relation such that: 
d 
′′ ′ 
– (l, u) −→ (l, u + d) if ∀d :0 ≤ d ≤ d =⇒ u + d ∈ I (l ), and 
a 
′ 
– (l, u) −→ (l ,u ′) if there exists e =(l, a, g, r, l ′) ∈ E s.t. u ∈ g , 
′′ 
u =[r → 0]u, and u ∈ I (l ′ ), 
3 
where for d ∈ R≥0 , u + d maps each clock x in C to the value u(x)+ d, and [r → 0]u denotes the clock valuation which maps each clock in r to 0 and agrees with u over C \ r . &#3; 
Figure 2 illustrates the semantics of TA. From a given initial state, we can choose to take an action or a delay transition (di erent values here). Depending of the chosen delay, further actions may be forbidden. 
Timed automata are often composed into a network of timed automata over a common set of clocks and actions, consisting of n timed automata Ai = 
0
(Li,li , C, A, Ei,Ii), 1 ≤ i ≤ n . A location vector is a vector ¯ l =(l1 ,... ,ln). We compose the invariant functions into a common function over location vec
′ 
tors I (¯ l )= ∧iIi(li). We write l ¯[li/li] to denote the vector where the ith element 
′ 
li of ¯ l is replaced by li. In the following we define the semantics of a network of timed automata. 
Definition 3 (Semantics of a network of Timed Automata). Let Ai = 
0 00
(Li,li , C, A, Ei,Ii) be a network of n timed automata. Let ¯ l0 =(l ... ,l ) be the
1 , n initial location vector. The semantics is defined as a transition system S, s0 , →, where S =(L1 × · × Ln) × RC is the set of states, s0 = (¯ l0 ,u0 ) is the initial state, and →⊆ S × S is the transition relation defined by: 
d 
′′ ′ 
– (¯ l, u) −→ (¯ l, u + d) if ∀d :0 ≤ d ≤ d =⇒ u + d ∈ I (¯ l ). 
a ˝gr
′′ 
– (¯ l, u) −→ (¯ l[li/li],u ′) if there exists li −−→ li s.t. u ∈ g , 
′ ′′ 
u =[r → 0]u and u ∈ I (¯ l [li/li]). 
ac?gi ri
′′ ′ 
– (¯ l, u) −→ (¯ l[lj /lj,li/li],u ′) if there exist li −−−→ li and 
c!gj rj 
′ ′ ′′′ 
lj −−−→ lj s.t. u ∈ (gi ∧ gj ), u =[ri ∪ rj → 0]u and u ∈ I (¯ l [lj /lj,li/li]). &#3; 
As an example of the semantics, the lamp in Fig. 1 may have the following states (we skip the user): (Lamp.off,y = 0) → (Lamp.off,y = 3) → (Lamp.low,y = 0) → (Lamp.low,y =0.5) → (Lamp.bright,y =0.5) → (Lamp.bright,y =1000) ... 
Timed Automata in Uppaal The Uppaal modelling language extends timed automata with the following additional features (see Fig. 3: 
Templates automata are defined with a set of parameters that can be of any type (e.g., int, chan). These parameters are substituted for a given argument in the process declaration. 
Constants are declared as const name value. Constants by definition cannot be modified and must have an integer value. 
Bounded integer variables are declared as int[min,max] name, where min and max are the lower and upper bound, respectively. Guards, invariants, and assignments may contain expressions ranging over bounded integer variables. The bounds are checked upon verification and violating a bound leads to an invalid state that is discarded (at run-time). If the bounds are omitted, the default range of -32768 to 32768 is used. 
4 

Fig. 3. Declarations of a constant and a variable, and illustration of some of the channel synchronisations between two templates of the train gate example of Section 4, and some committed locations. 
5 
Binary synchronisation channels are declared as chan c. An edge labelled with c! synchronises with another labelled c?. A synchronisation pair is chosen non-deterministically if several combinations are enabled. 
Broadcast channels are declared as broadcast chan c. In a broadcast synchronisation one sender c! can synchronise with an arbitrary number of receivers c?. Any receiver than can synchronise in the current state must do so. If there are no receivers, then the sender can still execute the c! action, 
i.e. broadcast sending is never blocking. 
Urgent synchronisation channels are declared by prefixing the channel declaration with the keyword urgent. Delays must not occur if a synchronisation transition on an urgent channel is enabled. Edges using urgent channels for synchronisation cannot have time constraints, i.e., no clock guards. 
Urgent locations are semantically equivalent to adding an extra clock x, that is reset on all incoming edges, and having an invariant x<=0 on the location. Hence, time is not allowed to pass when the system is in an urgent location. 
Committed locations are even more restrictive on the execution than urgent locations. A state is committed if any of the locations in the state is committed. A committed state cannot delay and the next transition must involve an outgoing edge of at least one of the committed locations. 
Arrays are allowed for clocks, channels, constants and integer variables. They are defined by appending a size to the variable name, e.g. chan c[4]; clock a[2]; int[3,5] u[7];. 
Initialisers are used to initialise integer variables and arrays of integer vari
ables. For instance, int i = 2; or int i[3] = {1, 2, 3};. 
Record types are declared with the struct construct like in C. 
Custom types are defined with the C-like typedef construct. You can define 
any custom-type from other basic types such as records. 
User functions are defined either globally or locally to templates. Template parameters are accessible from local functions. The syntax is similar to C except that there is no pointer. C++ syntax for references is supported for the arguments only. 
Expressions in Uppaal Expressions in Uppaal range over clocks and integer variables. The BNF is given in Fig. 33 in the appendix. Expressions are used with the following labels: 
Select A select label contains a comma separated list of name : type expressions where name is a variable name and type is a defined type (built-in or custom). These variables are accessible on the associated edge only and they will take a non-deterministic value in the range of their respective types. 
Guard A guard is a particular expression satisfying the following conditions: it is side-e ect free; it evaluates to a boolean; only clocks, integer variables, and constants are referenced (or arrays of these types); clocks and clock di erences are only compared to integer expressions; guards over clocks are essentially conjunctions (disjunctions are allowed over integer conditions). A guard may call a side-e ect free function that returns a bool, although clock constraints are not supported in such functions. 
6 
Synchronisation A synchronisation label is either on the form E xpr ession! or E xpr ession? or is an empty label. The expression must be side-e ect free, evaluate to a channel, and only refer to integers, constants and channels. 
Update An update label is a comma separated list of expressions with a side-e ect; expressions must only refer to clocks, integer variables, and constants and only assign integer values to clocks. They may also call functions. 
Invariant An invariant is an expression that satisfies the following conditions: it is side-e ect free; only clock, integer variables, and constants are referenced; it is a conjunction of conditions of the form x<e or x<=e where x is a clock reference and e evaluates to an integer. An invariant may call a side-e ect free function that returns a bool, although clock constraints are not supported in such functions. 
2.2 The Query Language 
The main purpose of a model-checker is verify the model w.r.t. a requirement specification. Like the model, the requirement specification must be expressed in a formally well-defined and machine readable language. Several such logics exist in the scientific literature, and Uppaal uses a simplified version of TCTL. Like in TCTL, the query language consists of path formulae and state formulae.2 State formulae describe individual states, whereas path formulae quantify over paths or traces of the model. Path formulae can be classified into reachability, safety and liveness. Figure 4 illustrates the di erent path formulae supported by Uppaal. Each type is described below. 
State Formulae A state formula is an expression (see Fig. 33) that can be evaluated for a state without looking at the behaviour of the model. For instance, this could be a simple expression, like i == 7, that is true in a state whenever i equals 7. The syntax of state formulae is a superset of that of guards, i.e., a state formula is a side-e ect free expression, but in contrast to guards, the use of disjunctions is not restricted. It is also possible to test whether a particular process is in a given location using an expression on the form P.l, where P is a process and l is a location. 
In Uppaal, deadlock is expressed using a special state formula (although this is not strictly a state formula). The formula simply consists of the keyword deadlock and is satisfied for all deadlock states. A state is a deadlock state if there are no outgoing action transitions neither from the state itself or any of its delay successors. Due to current limitations in Uppaal, the deadlock state formula can only be used with reachability and invariantly path formulae (see below). 
Reachability Properties Reachability properties are the simplest form of properties. They ask whether a given state formula, ϕ, possibly can be satisfied 
2 In contrast to TCTL, Uppaal does not allow nesting of path formulae. 
7 

Fig. 4. Path formulae supported in Uppaal. The filled states are those for which a given state formulae ° holds. Bold edges are used to show the paths the formulae evaluate on. 
by any reachable state. Another way of stating this is: Does there exist a path starting at the initial state, such that ϕ is eventually satisfied along that path. 
Reachability properties are often used while designing a model to perform sanity checks. For instance, when creating a model of a communication protocol involving a sender and a receiver, it makes sense to ask whether it is possible for the sender to send a message at all or whether a message can possibly be received. These properties do not by themselves guarantee the correctness of the protocol (i.e. that any message is eventually delivered), but they validate the basic behaviour of the model. 
We express that some state satisfying ϕ should be reachable using the path formula E 3 ϕ. In Uppaal, we write this property using the syntax E<> ϕ. 
Safety Properties Safety properties are on the form: “something bad will never happen”. For instance, in a model of a nuclear power plant, a safety property might be, that the operating temperature is always (invariantly) under a certain threshold, or that a meltdown never occurs. A variation of this property is that “something will possibly never happen”. For instance when playing a game, a safe state is one in which we can still win the game, hence we will possibly not loose. 
In Uppaal these properties are formulated positively, e.g., something good is invariantly true. Let ϕ be a state formulae. We express that ϕ should be true 
3
in all reachable states with the path formulae A&#3;ϕ, whereas E &#3;ϕ says that 
3 Notice that A&#3;'= ¬E3 ¬' 
8 
there should exist a maximal path such that ϕ is always true.4 In Uppaal we write A[] ϕ and E[] ϕ, respectively. 
Liveness Properties Liveness properties are of the form: something will eventually happen, e.g. when pressing the on button of the remote control of the television, then eventually the television should turn on. Or in a model of a communication protocol, any message that has been sent should eventually be received. 
In its simple form, liveness is expressed with the path formula A3 ϕ, meaning ϕ is eventually satisfied.5 The more useful form is the leads to or response property, written ϕψ which is read as whenever ϕ is satisfied, then eventually ψ will be satisfied, e.g. whenever a message is sent, then eventually it will be received.6 In Uppaal these properties are written as A<> ϕ and ϕ --> ψ , respectively. 
2.3 Understanding Time 
Invariants and Guards Uppaal uses a continuous time model. We illustrate the concept of time with a simple example that makes use of an observer. Normally an observer is an add-on automaton in charge of detecting events without changing the observed system. In our case the clock reset (x:=0) is delegated to the observer for illustration purposes. 
Figure 5 shows the first model with its observer. We have two automata in parallel. The first automaton has a self-loop guarded by x>=2, x being a clock, that synchronises on the channel reset with the second automaton. The second automaton, the observer, detects when the self loop edge is taken with the location taken and then has an edge going back to idle that resets the clock x. We moved the reset of x from the self loop to the observer only to test what happens on the transition before the reset. Notice that the location taken is committed (marked c) to avoid delay in that location. 
The following properties can be verified in Uppaal (see section 3 for an overview of the interface). Assuming we name the observer automaton Obs, we have: 
– A[] Obs.taken imply x>=2 : all resets o x will happen when x is above 
2. This query means that for all reachable states, being in the location Obs.taken implies that x>=2. 
– E<> Obs.idle and x>3 : this property requires, that it is possible to reachable state where Obs is in the location idle and x is bigger than 3. Essentially we check that we may delay at least 3 time units between resets. The result would have been the same for larger values like 30000, since there are no invariants in this model. 
4 A maximal path is a path that is either infinite or where the last state has no 
outgoing transitions. 
5 Notice that A3 '= ¬E&#3;¬'. 
6 Experts in TCTL will recognise that ' is equivalent to A&#3;(' =) A3 ) 
9 

4 
reset? 
2 



idle taken
loop 
x>=2reset! 
x:=0 
2 4 6 8 "time" 
(a) Test. (b) Observer. (c) Behaviour: one possible run. Fig. 5. First example with an observer. 
‚‚‚‚‚ 


2 4 6 8 "time" 
(a) Test. (b) Updated behaviour with an invariant. 
Fig. 6. Updated example with an invariant. The observer is the same as in Fig. 5 and is not shown here. 
We update the first model and add an invariant to the location loop, as shown in Fig. 6. The invariant is a progress condition: the system is not allowed to stay in the state more than 3 time units, so that the transition has to be taken and the clock reset in our example. Now the clock x has 3 as an upper bound. The following properties hold: 
– A[] Obs.taken imply (x>=2 and x<=3) shows that the transition is taken when x is between 2 and 3, i.e., after a delay between 2 and 3. 
– 
E<> Obs.idle and x>2 : it is possible to take the transition when x is between 2 and 3. The upper bound 3 is checked with the next property. 

– 
A[] Obs.idle imply x<=3 : to show that the upper bound is respected. 


The former property E<> Obs.idle and x>3 no longer holds. 
Now, if we remove the invariant and change the guard to x>=2 and x<=3, you may think that it is the same as before, but it is not! The system has no progress condition, just a new condition on the guard. Figure 7 shows what happens: the system may take the same transitions as before, but deadlock may also occur. The system may be stuck if it does not take the transition after 3 time units. In fact, the system fails the property A[] not deadlock. The property A[] Obs.idle imply x<=3 does not hold any longer and the deadlock can also be illustrated by the property A[] x>3 imply not Obs.taken, i.e., after 3 time units, the transition is not taken any more. 
10 
4 
loop 
2
x>=2 && x<=3 reset! 

2 4 6 8 "time" 
(a) Test. (b) Updated behaviour with a guard and no invariant. Fig. 7. Updated example with a guard and no invariant. 

S0 S1 S2 

S0 S1 S2 

Fig. 8. Automata in parallel with normal, urgent and commit states. The clocks are local, i.e., P0.x and P1.x are two di erent clocks. 
Committed and Urgent Locations There are three di erent types of locations in Uppaal: normal locations with or without invariants (e.g., x<=3 in the previous example), urgent locations, and committed locations. Figure 8 shows 3 automata to illustrate the di erence. The location marked u is urgent and the one marked c is committed. The clocks are local to the automata, i.e., x in P0 is di erent from x in P1. 
To understand the di erence between normal locations and urgent locations, we can observe that the following properties hold: 
– 
E<> P0.S1 and P0.x>0 : it is possible to wait in S1 of P0. 

– 
A[] P1.S1 imply P1.x==0 : it is not possible to wait in S1 of P1. 


An urgent location is equivalent to a location with incoming edges reseting a designated clock y and labelled with the invariant y<=0. Time may not progress in an urgent state, but interleavings with normal states are allowed. 
A committed location is more restrictive: in all the states where P2.S1 is active (in our example), the only possible transition is the one that fires the edge outgoing from P2.S1.A state having a committed location active is said to 
11 
be committed: delay is not allowed and the committed location must be left in the successor state (or one of the committed locations if there are several ones). 
3 Overview of the Uppaal Toolkit 
Uppaal uses a client-server architecture, splitting the tool into a graphical user interface and a model checking engine. The user interface, or client, is implemented in Java and the engine, or server, is compiled for di erent platforms (Linux, Windows, Solaris).7 As the names suggest, these two components may be run on di erent machines as they communicate with each other via TCP/IP. There is also a stand-alone version of the engine that can be used on the command line. 
3.1 The Java Client 
The idea behind the tool is to model a system with timed automata using a graphical editor, simulate it to validate that it behaves as intended, and finally to verify that it is correct with respect to a set of properties. The graphical interface (GUI) of the Java client reflects this idea and is divided into three main parts: the editor, the simulator, and the verifier, accessible via three “tabs”. 
The Editor A system is defined as a network of timed automata, called processes in the tool, put in parallel. A process is instantiated from a parameterised template. The editor is divided into two parts: a tree pane to access the di erent templates and declarations and a drawing canvas/text editor. Figure 9 shows the editor with the train gate example of section 4. Locations are labelled with names and invariants and edges are labelled with guard conditions (e.g., e==id), synchronisations (e.g., go?), and assignments (e.g., x:=0). 
The tree on the left hand side gives access to di erent parts of the system description: 
Global declaration Contains global integer variables, clocks, synchronisation 
channels, and constants. Templates Train, Gate, and IntQueue are di erent parameterised timed au
tomata. A template may have local declarations of variables, channels, and 
constants. Process assignments Templates are instantiated into processes. The process 
assignment section contains declarations for these instances. System definition The list of processes in the system. 
The syntax used in the labels and the declarations is described in the help system of the tool. The local and global declarations are shown in Fig. 10. The graphical syntax is directly inspired from the description of timed automata in section 2. 
12 

Fig. 9. The train automaton of the train gate example. The select button is activated in the tool-bar. In this mode the user can move locations and edges or edit labels. The other modes are for adding locations, edges, and vertices on edges (called nails). A new location has no name by default. Two text fields allow the user to define the template name and its parameters. Useful trick: The middle mouse button is a shortcut for adding new elements, i.e. pressing it on the canvas, a location, or edge adds a new location, edge, or nail, respectively. 
The Simulator The simulator can be used in three ways: the user can run the system manually and choose which transitions to take, the random mode can be toggled to let the system run on its own, or the user can go through a trace (saved or imported from the verifier) to see how certain states are reachable. Figure 11 shows the simulator. It is divided into four parts: 
The control part is used to choose and fire enabled transitions, go through a trace, and toggle the random simulation. 
The variable view shows the values of the integer variables and the clock constraints. Uppaal does not show concrete states with actual values for the clocks. Since there are infinitely many of such states, Uppaal instead shows sets of concrete states known as symbolic states. All concrete states in a symbolic state share the same location vector and the same values for discrete variables. The possible values of the clocks is described by a set of con
7 A version for Mac OS X is in preparation. 
13 

straints. The clock validation in the symbolic state are exactly those that satisfy all constraints. The system view shows all instantiated automata and active locations of the current state. The message sequence chart shows the synchronisations between the di erent processes as well as the active locations at every step. 
The Verifier The verifier “tab” is shown in Fig. 12. Properties are selectable in the Overview list. The user may model-check one or several properties,8 insert or remove properties, and toggle the view to see the properties or the comments in the list. When a property is selected, it is possible to edit its definition (e.g., E<> Train1.Cross and Train2.Stop . . . ) or comments to document what the property means informally. The Status panel at the bottom shows the communication with the server. 
When trace generation is enabled and the model-checker finds a trace, the user is asked if she wants to import it into the simulator. Satisfied properties are marked green and violated ones red. In case either an over approximation or an under approximation has been selected in the options menu, then it may happen that the verification is inconclusive with the approximation used. In that case the properties are marked yellow. 
8 several properties only if no trace is to be generated. 
14 

Fig. 11. View of the simulator tab for the train gate example. The interpretation of the constraint system in the variable panel depends on whether a transition in the transition panel is selected or not. If no transition is selected, then the constrain system shows all possible clock valuations that can be reached along the path. If a transition is selected, then only those clock valuations from which the transition can be taken are shown. Keyboard bindings for navigating the simulator without the mouse can be found in the integrated help system. 
3.2 The Stand-alone Verifier 
When running large verification tasks, it is often cumbersome to execute these from inside the GUI. For such situations, the stand-alone command line verifier called verifyta is more appropriate. It also makes it easy to run the verification on a remote UNIX machine with memory to spare. It accepts command line arguments for all options available in the GUI, see Table 3 in the appendix. 
4 Example 1: The Train Gate 
4.1 Description 
The train gate example is distributed with Uppaal. It is a railway control system which controls access to a bridge for several trains. The bridge is a critical shared resource that may be accessed only by one train at a time. The system is defined as a number of trains (assume 4 for this example) and a controller. A train can not be stopped instantly and restarting also takes time. Therefor, there are timing constraints on the trains before entering the bridge. When approaching, 
15 

a train sends a appr! signal. Thereafter, it has 10 time units to receive a stop signal. This allows it to stop safely before the bridge. After these 10 time units, it takes further 10 time units to reach the bridge if the train is not stopped. If a train is stopped, it resumes its course when the controller sends a go! signal to it after a previous train has left the bridge and sent a leave! signal. Figures 13 and 14 show two situations. 
4.2 Modelling in Uppaal 
The model of the train gate has three templates: 
Train is the model of a train, shown in Fig. 9. Gate is the model of the gate controller, shown in Fig. 15. IntQueue is the model of the queue of the controller, shown in Fig. 16. It is 
simpler to separate the queue from the controller, which makes it easier to 
get the model right. 
The Template of the Train The template in Fig. 9 has five locations: Safe, Appr, Stop, Start, and Cross. The initial location is Safe, which corresponds to a train not approaching yet. The location has no invariant, which means that a train may stay in this location an unlimited amount of time. When a train is approaching, it synchronises with the controller. This is done by the channel synchronisation appr! on the transition to Appr. The controller has a corresponding appr?. The clock x is reset and the parameterised variable e is set 
16 
Approaching. Can be stopped. Cannot be stopped in Crossing 



to the identity of this train. This variable is used by the queue and the controller to know which train is allowed to continue or which trains must be stopped and later restarted. 
The location Appr has the invariant x ≤ 20, which has the e ect that the location must be left within 20 time units. The two outgoing transitions are guarded by the constraints x ≤ 10 and x ≥ 10, which corresponds to the two sections before the bridge: can be stopped and can not be stopped. At exactly 10, both transitions are enabled, which allows us to take into account any race conditions if there is one. If the train can be stopped (x ≤ 10) then the transition to the location Stop is taken, otherwise the train goes to location Cross. The transition to Stop is also guarded by the condition e == id and is synchronised with stop?. When the controller decides to stop a train, it decides which one (sets e) and synchronises with stop!. 
The location Stop has no invariant: a train may be stopped for an unlimited amount of time. It waits for the synchronisation go?. The guard e == id ensures that the right train is restarted. The model is simplified here compared to the version described in [60], namely the slowdown phase is not modelled explicitly. We can assume that a train may receive a go? synchronisation even when it is not stopped completely, which will give a non-deterministic restarting time. 
The location Start has the invariant x ≤ 15 and its outgoing transition has the constraint x ≥ 7. This means that a train is restarted and reaches the crossing section between 7 and 15 time units non-deterministically. 
The location Cross is similar to Start in the sense that it is left between 3 and 5 time units after entering it. 
17 
(stopping) 
train1 (stopped) train2  
(restarting) train3  
Fig. 14. Now train4 has crossed the bridge and sends a leave! signal. The controller can now let train3 cross the bridge with a go! signal. Train2 is now waiting and train1 is stopping. 



train4:leave! 

Controller 

The Template of the Gate The gate controller in Fig. 15 synchronises with the queue and the trains. Some of its locations do not have names. Typically, they are committed locations (marked with a c). 
The controller starts in the Free location (i.e., the bridge is free), where it tests the queue to see if it is empty or not. If the queue is empty then the controller waits for approaching trains (next location) with the appr? synchronisation. When a train is approaching, it is added to the queue with the add! synchronisation. If the queue is not empty, then the first train on the queue (read by hd!) is restarted with the go! synchronisation. 
In the Occ location, the controller essentially waits for the running train to leave the bridge (leave?). If other trains are approaching (appr?), they are stopped (stop!) and added to the queue (add!). When a train leaves the bridge, the controller removes it from the queue with the rem? synchronisation. 
The Template of the Queue The queue in Fig. 16 has essentially one location Start where it is waiting for commands from the controller. The Shiftdown location is used to compute a shift of the queue (necessary when the front element is removed). This template uses an array of integers and handles it as a FIFO queue. 
4.3 Verification 
We check simple reachability, safety, and liveness properties, and for absence of deadlock. The simple reachability properties check if a given location is reachable: 
– 
E<> Gate.Occ: the gate can receive and store messages from approaching trains in the queue. 

– 
E<> Train1.Cross: train 1 can cross the bridge. We check similar properties for the other trains. 

– 
E<> Train1.Cross and Train2.Stop: train 1 can be crossing the bridge while train 2 is waiting to cross. We check for similar properties for the other trains. 

– 
E<> Train1.Cross && Train2.Stop && Train3.Stop && Train4.Stop is similar to the previous property, with all the other trains waiting to cross the bridge. We have similar properties for the other trains. 


18 

The following safety properties must hold for all reachable states: 
– 
A[] Train1.Cross+Train2.Cross+Train3.Cross+Train4.Cross<=1. There is not more than one train crossing the bridge at any time. This expression uses the fact that Train1.Cross evaluates to true or false, i.e., 1 or 0. 

– 
A[] Queue.list[N-1] == 0: there can never be N elements in the queue, i.e., the array will never overflow. Actually, the model defines N as the number of trains + 1 to check for this property. It is possible to use a queue length matching the number of trains and check for this property instead: A[] (Gate.add1 or Gate.add2) imply Queue.len < N-1 where the locations add1 and add2 are the only locations in the model from which add! is possible. 


The liveness properties are of the form Train1.Appr --> Train1.Cross: whenever train 1 approaches the bridge, it will eventually cross, and similarly for the other trains. Finally, to check that the system is deadlock-free, we verify the property A[] not deadlock. 
Suppose that we made a mistake in the queue, namely we wrote e:=list[1] in the template IntQueue instead of e:=list[0] when reading the head on the transition synchronised with hd?. We could have been confused when thinking in terms of indexes. It is interesting to note that the properties still hold, except 
19 
list[len]:=e, add? len++notempty! 
len>0 
empty! len==0 
rem! len>=1 len--, i := 0 

i < len list[i]:=list[i+1], i++ 
Fig. 16. Queue automaton of the train gate. The template is parameterised with int[0,n] e. 
the liveness ones. The verification gives a counter-example showing what may happen: a train may cross the bridge but the next trains will have to stop. When the queue is shifted the train that starts again is never the first one, thus the train at the head of the queue is stuck and can never cross the bridge. 
5 Example 2: Fischer’s Protocol 
5.1 Description 
Fischer’s protocol is a well-known mutual exclusion protocol designed for n processes. It is a timed protocol where the concurrent processes check for both a delay and their turn to enter the critical section using a shared variable id. 
5.2 Modelling in Uppaal 
The automaton of the protocol is given in Fig. 17. Starting from the initial location (marked with a double circle), processes go to a request location, req, if id==0, which checks that it is the turn for no process to enter the critical section. Processes stay non-deterministically between 0 and k time units in req, and then go to the wait location and set id to their process ID (pid). There it must wait at least k time units, x>k, k being a constant (2 here), before entering the critical section CS if it is its turn, id==pid. The protocol is based on the fact that after (strict) k time units with id di erent from 0, all the processes that want to enter the critical section are waiting to enter the critical section as well, but only one has the right ID. Upon exiting the critical section, processes reset id to allow other processes to enter CS. When processes are waiting, they may retry when another process exits CS by returning to req. 
20 

x>k, id==pid
cs wait 
Fig. 17. Template of Fischer’s protocol. The parameter of the template is const pid. The template has the local declarations clock x; const k 2;. 
5.3 Verification 
The safety property of the protocol is to check for mutual exclusion of the location CS: A[] P1.cs + P2.cs + P3.cs + P4.cs <= 1. This property uses the trick that these tests evaluate to true or false, i.e., 0 or 1. We check that the system is deadlock-free with the property A[] not deadlock. 
The liveness properties are of the form P1.req --> P1.wait and similarly for the other processes. They check that whenever a process tries to enter the critical section, it will always eventually enter the waiting location. Intuitively, the reader would also expect the property P1.req --> P1.cs that similarly states that the critical section is eventually reachable. However, this property is violated. The interpretation is that the process is allowed to stay in wait for ever, thus there is a way to avoid the critical section. 
Now, if we try to fix the model and add the invariant x <= 2*k to the wait location, the property P1.req --> P1.cs still does not hold because it is possible to reach a deadlock state where P1.wait is active, thus there is a path that does not lead to the critical section. The deadlock is as follows: P1.wait with 0 ≤ x ≤ 2 and P4.wait with 2 ≤ x ≤ 4. Delay is forbidden in this state, due to the invariant on P4.wait and P4.wait can not be left because id == 1. 
6 Example 3: The Gossiping Girls 
6.1 Description 
Let n girls have each a private secret they wish to share with each other. Every girl can call another girl and after a conversation, both girls know mutually all their secrets. The problem is to find out how many calls are necessary so that all the girls know all the secrets. A variant of the problem is to add time to conversations and ask how much time is necessary to exchange all the secrets, allowing concurrent calls. 
The basic formulation of the problem is not timed and is typically a combinatorial problem with a string of n bits that may take (at most) 2n values for 
21 
2
every girl. That means we have in total a string of n bits taking 2n 2 values (in product with other states of the system). 
6.2 Modelling in Uppaal 
We face choices regarding the representation of the secrets and where to store them. One way is to use one integer and manually set or reset its bits using arithmetic operations. Although the size of the system is limited by the size of the integers, a quick complexity evaluation shows that the state-space explodes too quicly anyway so this is not really a limitation. Another way is to use an array of booleans. The solution with the integer sounds like hacking and in fact it is so specialized that we will have problem to refine the model later. The model with booleans is certainly more readable, which is desirable for formal verification. The second choice is where to store the messages: in one big shared table locally with every girl process. The referenced models are available at http://www.cs.aau.dk/~adavid/UPPAAL-tutorial/. 
Generic Declarations The global declaration contains: 
const int GIRLS = 4; typedef int[0,GIRLS-1] girl_t; chan phone[girl_t], reply[girl_t]; 
This allows us to scale the model easily. Notice that it is possible to declare that arrays of channels are indexed by a given type, which implicitely gives them the right size. This is necessary to use symmetry reduction through scalar sets later. 
The girl process is named Girl and has girl 
t id as parameter. Every girl has a di erent ID. The system declaration is simply: system Girl;. This makes use of the auto-instantiation feature of Uppaal. All instances of the template Girl ranging over its parameters are generated. The number of instances is controlled by the constant GIRLS. 
Flexible Modelling We declare three local functions to the template Girl. Notice that they have access to the parameter id. These functions are used to initialize the template (start()) with a unique secret and to send and receive secrets to other templates (talk() and listen()). We can change these functions but still keep the same model, which makes the model flexible. 
Integers The encoding with integers has meta int tmp; added to the global declarations and the following to the local declaration of the template Girl: 
girl_t g; int secrets; void start() { secrets = 1 << id; } void talk() { tmp = secrets; } void listen() { secrets |= tmp; } 
22 
Initialization is done by setting bit id to one. The initial committed location ensures all girls are initialized before they start to exchange secrets. Then we have a standard message passing using a shared variable with the receiver merging the secrets sent with her own (logical or). The shared variable is declared meta, which means it is a special temporary variable not part of the state, i.e., never refer to such a variable between two states. We assume that these functions are used with channel synchronization. 
Booleans The encoding with booleans has meta bool tmp[girl 
t]; added to the global declarations and the following to the local declarations of the template Girl: 
girl_t g; bool secrets[girl_t]; void start() { secrets[id] = true; } void talk() { tmp = secrets; } void listen() { for(i:girl_t) secrets[i] |= tmp[i]; } 
In this version we use assignment between arrays for talk(). The function listen() uses an iterator. The automaton for models gossip0.xml (with integers) and gossip1.xml (with booleans) is given in Fig. 18. This first attempt captures the fact that we want the model to be symmetric with respect to sending and receiving and is quite natural with symmetric uses of talk() and listen(). The local variable g records which other girl is a given template communicating with. The sender selects its receiver and the receiver its sender. 
start() 
Ringing 
j : girl_t 
j : girl_t 
id != j 
phone[j]? phone[j]! 
listen(), g = j, 
g = j talk() 
Reply Listen 
Fig. 18. First attempt for modelling the gossiping girls. 
Let us first improve the model on three points: 
1. 
The intermediate state Listen should be made committed otherwise all interleaving of half-started and complete calls will occur. 

2. 
One select is enough because we are modelling something else here, namely girl id selects a channel j and any other girl that selects the same channel can communicate with id. 




23 
3. The local variable g contributes badly to the state-space when its value is not relevant, i.e., the previous communication does not need to be kept. We can set it in a symmetric manner upon the start and reset it after communication to id. 
These are typical “optimizations” of a model: Avoid useless interleavings by using committed locations, make sure you model exactly what you need and not more, and “active variable reduction”. The updated model (gossip2.xml/integers, gossip3.xml/booleans) is shown in Fig. 19. The template keeps as an invariant that the variable g is always equal to id whenever it is not sending. In addition, when a channel j is selected, then it corresponds to exactly girl j. Only one committed location is enough but it is a good practice to mark them both. It is more explicit when we read the model. Since the model performs better, we can now check with 5 girls instead of 4 within roughly the same time, which is a very good improvement considering the exponential complexity of the model. 

start(), g = id 
Ringing 
reply[id]! 
Reply
talk() 
Fig. 19. Improved model of the gossiping girls. 
Optimizing Further We can abstract which communication line is used by declaring only one channel chan call. Since the semantics says that any pair of enabled edges (call!,call?) can be taken, we do not need to make an extra select. In addition, processes cannot synchronize with themselves so we do not need this check either. The downside is that we lose the information on the receiver from the sender point of view. We do not need this in our case. We can get rid of the local variable g as well. We could use the sequence talk()-listen()-talk()-listen() with the old functions but we can simplify these by merging the middle listen()-talk() into one and simplifying listen() to a simple assignment since we know that the message already contains the secrets sent. The global declaration is updated with only chan call; for the channel. The updated automaton is depicted in Fig. 20. 
The integer version of the model (gossip4.xml) has the following local functions: 
24 

reply[g]? listen(), g = id 
start() 
Ringing 
Listen 

int secrets; void start() { secrets = 1 << id; } void talk() { tmp = secrets; } void exchange() { secrets = (tmp |= secrets); } void listen() { secrets = tmp; } 
The boolean version of the model (gossip5.xml) is changed to: 
bool secrets[girl_t]; void start() { secrets[id] = true; } void talk() { tmp = secrets; } void exchange() { for(i:girl_t) tmp[i] |= secrets[i]; 
secrets = tmp; } void listen() { secrets = tmp; } 
The exchange function could have been written as 
void exchange() { for(i:girl_t) secrets[i] = (tmp[i] |= secrets[i]); } 
which is almost the same. The di erence is that the number of interpreted instructions is lower in the first case. A step further would be to inline these functions on the edges in the model but then we would lose readability to gain less than 5% in speed. It is possible to further optimize the model by having one parameterized shared table and avoid message passing all-together. We leave this as an exercise for the reader but we notice that this change destroys the nice design with the local secrets to each process. 
6.3 Verification 
We check the property that all girls know all secrets. For the integer version of the model, the property is: 
25 
E<> forall(i:girl_t) forall(j:girl_t) (Girl(i).secrets & (1 << j)) 
We can write a shorter but less obvious equivalent formula that takes advantage of the fact that 2GIRLS − 1 generates a bit mask with the first GIRLS bits set to one: 
E<> forall(i:girl_t) Girl(i).secrets == ((1 << GIRLS)-1) 
The formula for the boolean version is: 
E<> forall(i:girl_t) forall(j:girl_t) Girl(i).secrets[j] 
The formulas use the “for-all” construct, which gives compact formulas that automatically scale with the number of girls in the model. The version with the integers checks with a bit mask that the bits are set. 
Table 1 shows the resource consumption for the di erent models with di erent number of girls. Experiments are run on an AMD Opteron 2.2GHz with Uppaal rev. 2842. The results show how important it is to be careful with the model and 
Girls  4  5  6  
gossip0 gossip1 gossip2 gossip3 gossip4 gossip5  0.6s/24M 1.0s/24M 0.1s/1.3M 0.1s/1.3M 0.1s/1.3M 0.1s/1.3M  498s/3071M 809s/3153M 0.3s/22M 0.5s/22M 0.2s/22M 0.3s/22M  --71s/591M 106s/607M 37s/364M 63s/381M  

Table 1. Resource consumption for the di erent models with di erent number of girls. Results are in seconds/Mbytes. 
to optimize the model to reduce the state-space whenever possible. We notice that we do not even have time in this model. The model with integers is faster due to its simplicity but consumes marginally less memory. 
6.4 Improved Verification 
Uppaal features two major techniques to improve verification. These techniques concern directly verification and are orthogonal to model optimization. The first is symmetry reduction. Since we designed our model to be symmetric from the start, taking advantage of this feature is done by using a scalar set for the type girl t. The second feature is the generalized sweep-line method. We need to define a progress measure to help the search. Furthermore, only the model with booleans is eligible for symmetry reduction since we cannot access individual bits in an integers in a symmetric manner (using scalars). 
Symmetry Reduction The only change required is for the definition of the type girl t. We use a scalar set for the new model (gossip6.xml): 
typedef scalar[GIRLS] girl_t; 
26 


Sweep-line We need to define a progress measure that is cheap to compute and relevant to help the search. It is important that it is cheap to compute since it will be evaluated for every state. To do so, we add int m; to the global declarations, we add the progress measure definition after the system declaration: 
progress { m; } 
Finally, we compute m in the exchange function as follows: 
void exchange() { m = 0; for(i:girl_t) { 
m += tmp[i] ^ secrets[i]; tmp[i] |= secrets[i]; } } 
This measures counts the number of new messages exchanged per communication. 
Girls  4  5  6  7  
gossip6 gossip7  0.1s/1.3M 0.1s/1.3M  0.1s/1.3M 0.1s/1.3M  3.4s/29M 0.3s/21M  399s/1115M 29s/108M  

Table 2. Resource consumption using symmetry reduction (gossip6) combined with the sweep-line method (gossip7). 
Table 2 show that these features give gains with another order of magnitude both in speed and memory. The model still explodes exponentially but we cannot avoid it given its nature. 
7 Modelling Patterns 
In this section we present a number of useful modelling patterns for Uppaal. A modelling pattern is a form of designing a model with a clearly stated intent, motivation and structure. We observe that most of our Uppaal models use one or more of the following patterns and we propose that these patterns are imitated when designing new models. 
7.1 Variable Reduction 
Intent 
To reduce the size of the state space by explicitly resetting variables when they are not used, thus speeding up the verification. 
27 
Motivation 
Although variables are persistent, it is sometimes clear from the way a model behaves, that the value of a variable does not matter in certain states, i.e., it is clear that two states that only di er in the values of such variables are in fact bisimilar. Resetting these variables to a known value will make these two states identical, thus reducing the state space. 
Structure 
The pattern is most easily applied to local variables. Basically, a variable v is called inactive in a location l , if along all paths starting from l , v will be reset before it will be used. If a variable v is inactive in location v , one should reset v to the initial value on all incoming edges of l . 
The exception to this rule is when v is inactive in all source locations of the incoming edges to l . In this case, v has already been reset, and there is no need to reset it again. The pattern is also applicable to shared variables, although it can be harder to recognise the locations in which the variable will be inactive. 
For clocks, Uppaal automatically performs the analysis described above. This process is called active clock reduction. In some situations this analysis may fail, since Uppaal does not take the values of non-clock variables into account when analysing the activeness. In those situations, it might speed up the verification, if the clocks are reset to zero when it becomes inactive. A similar problem arises if you use arrays of clocks and use integer variables to index into those arrays. Then Uppaal will only be able to make a coarse approximation of when clocks in the array will be tested and reset, often causing the complete array to be marked active at all times. Manually resetting the clocks might speed up verification. 
Sample 
The queue of the train gate example presented earlier in this tutorial uses the active variable pattern twice, see Fig. 21: When an element is removed, all the remaining elements of the list are shifted by one position. At the end of the loop in the Shiftdown location, the counter variable i is reset to 0, since its value is no longer of importance. Also the freed up element list[i] in the list is reset to zero, since its value will never be used again. For this example, the speedup in verification gained by using this pattern is approximately a factor of 5. 
Known Uses 
The pattern is used in most models of some complexity. 
7.2 Synchronous Value Passing 
Intent 
To synchronously pass data between processes. 
Motivation 
Consider a model of a wireless network, where nodes in the network are modelled 
28 
list[len]:=e, add? len++notempty! 
len>0 
empty! len==0 
rem! len>=1 len--, 
i := 0 

i < len list[i]:=list[i+1], i++ 
Fig. 21. The model of the queue in the train gate example uses active variable reduction twice. Both cases are on the edge from Shiftdown to Start: The freed element in the queue is reset to the initial value and so is the counter variable i. 
as processes. Neighbouring nodes must communicate to exchange, e.g., routing information. Assuming that the communication delay is insignificant, the handshake can be modelled as synchronisation via channels, but any data exchange must be modelled by other means. 
The general idea is that a sender and a receiver synchronise over shared binary channels and exchange data via shared variables. Since Uppaal evaluates the assignment of the sending synchronisation first, the sender can assign a value to the shared variable which the receiver can then access directly. 
Structure 
There are four variations of the value passing pattern, see Fig. 22. They di er in whether data is passed one-way or two-way and whether the synchronisation is unconditional or conditional. In one-way value passing a value is transfered from one process to another, whereas two-way value passing transfers a value in each direction. In unconditional value passing, the receiver does not block the communication, whereas conditional value passing allows the receiver to reject the synchronisation based on the data that was passed. 
In all four cases, the data is passed via the globally declared shared variable var and synchronisation is achieved via the global channels c and d. Each process has local variables in and out. Although communication via channels is always synchronous, we refer to a c! as a send-action and c? as a receive-action. Notice that the variable reduction pattern is used to reset the shared variable when it is no longer needed. Alternatively, the shared variable can be declared meta, in which case the reset is not necessary since the variable is not part of the state. 
In one-way value passing only a single channel c and a shared variable var is required. The sender writes the data to the shared variable and performs a 
29 
Unconditio nal  Conditional  
One-way c! var := out ‚ ‚ ‚ ‚ ‚  c? in := var, var := 0  c! var := out ‚ ‚ ‚ ‚ ‚  c? in := var, var := 0 cond(in)  
Asymmetric two-way c! var := out d? in := var, var :=0 ‚ ‚ ‚ ‚ ‚  c? in := var d! var := out  c! var := out ‚ ‚ ‚ ‚ ‚ cond1(var) d? in := var, var :=0  c? in := var, var := out cond2(in) d!  
Fig. 22. The are essentially four combinations of conditional, unconditional, one-way and two-way synchronous value passing. 


send-action. The receiver performs the co-action, thereby synchronising with the sender. Since the update on the edge with send-action is always evaluated before the update of the edge with the receive-action, the receiver can access the data written by the sender in the same transition. In the conditional case, the receiver can block the synchronisation according to some predicate cond(in) involving the value passed by the sender. The intuitive placement of this predicate is on the guard of the receiving edge. Unfortunately, this will not work as expected, since the guards of the edges are evaluated before the updates are executed, i.e., before the receiver has access to the value. The solution is to place the predicate on the invariant of the target location. 
Two-way value passing can be modelled with two one-way value passing pattern with intermediate committed locations. The committed locations enforce that the synchronisation is atomic. Notice the use of two channels: Although not strictly necessary in the two-process case, the two channel encoding scales to the case with many processes that non-deterministically choose to synchronise. In the conditional case each process has a predicate involving the value passed by the other process. The predicates are placed on the invariants of the committed locations and therefore assignment to the shared variable in the second process must be moved to the first edge. It might be tempting to encoding conditional two-way value passing directly with two one-way conditional value passing pattern, i.e., to place the predicate of the first process on the third location. Unfortunately, this will introduce spurious deadlocks into the model. 
If the above asymmetric encoding of two-way value passing is undesirable, the symmetric encoding in Fig. 23 can be used instead. Basically, a process can nondeterministically choose to act as either the sender or the receiver. Like before, 
30 
committed locations guarantee atomicity. If the synchronisation is conditional, the predicates are placed on the committed locations to avoid deadlocks. Notice that the symmetric encoding is more expensive: Even though the two paths lead to the same result, two extra successors will be generated. 
c! c? 
var := out in := var, var := out 
cond(var) cond(in) 
d? d! in := var, var := 0 

Fig. 23. In contrast to the two-way encoding shown in Fig 22, this encoding is symmetric in the sense that both automata use the exact same encoding. The symmetry comes at the cost of a slightly larger state space. 
Sample 
The train gate example of this tutorial uses synchronous one-way unconditional value passing between the trains and the gate, and between the gate and the queue. In fact, the value passing actually happens between the trains and the queue and the gate only act as a mediator to decouple the trains from the queue. 
Known Uses 
Lamport’s Distributed Leader Election Protocol. Nodes in this leader election protocol broadcast topology information to surrounding nodes. The communication is not instantaneous, so an intermediate process is used to model the message. The nodes and the message exchange data via synchronous one-way unconditional value passing. 
Lynch’s Distributed Clock Synchronisation Protocol. This distributed protocol synchronises drifting clocks of nodes in a network. There is a fair amount of non-determinism on when exactly the clocks are synchronised, since the protocol only required this to happen within some time window. When two nodes synchronise non-deterministically, both need to know the other nodes identity. As an extra constraint, the synchronisation should only happen if it has not happened before in the current cycle. Here the asymmetric two-way conditional value passing pattern is used. The asymmetric pattern suÿces since each node has been split into two processes, one of them being dedicated to synchronising with the neighbours. 
31 
7.3 Synchronous Value Passing (bis) 
Intent 
To synchronously pass integers with a small range between processes. 
Motivation 
Similarly to the previous value passing pattern, it is useful to send values between processes. However, this pattern is specialized to integers with small ranges, which gives us the benefit to avoid using a shared variable for the communication. 
Structure 
The idea is to use arrays of channels to pass specific integers. The pattern is given for the general case of passing an integer value between MIN and MAX. Declare the array chan send[MAX-MIN+1] with MAX and MIN being either constants or the actual value of the desired range. Figure 7.3 shows the pattern. As an example the sender is sending the values 2, 3, or a randomly chosen value. The receiver is using the select feature of Uppaal 3.6 to find the right value. Notice that this is expensive for the model-checker if the range is large and will degrade performance. Two-way value passing can be modeled similarly to the previous pattern with the shared variable removed. Conditional value passing works for one-way only. 
send[3-MIN]! 
send[2-MIN]! 
send[random-MIN]! 


‚‚‚‚‚ 

i:int[MIN,MAX] 
send[i-MIN]? 
value=i random:int[MIN,MAX] 
sent received 
(a) Sender. (b) Receiver. 
Fig. 24. Value passing using an array of channels. 
7.4 Multicast 
Intent 
To encode multicast to at least N receivers (or similarly exactly N ). 
Motivation 
Uppaal provides pair-wise synchronisation via regular channels (chan) and broadcast synchronisation via broadcast channels (broadcast chan). In some models it is useful to ensure there are at least N receivers available and have the multicast behaviour, typically for communication protocols. 
Structure 
Use a shared variable (e.g. ready) that is incremented on the edges leading to a 
32 
location where it is possible to receive and decrement this variable on the edges that leave this location. In addition, add the constraint in the sender process on the required number of receiver (e.g. r eady > = N ). Figure 7.4 illustrates the patter. 

doSomething 
ready++ 
waitN 
waiting 
ready >= 3 
sentN 

received 
multisend? 
multisend! 
‚‚‚‚‚
ready-
(a) Sender. (b) Receiver. 
Fig. 25. Multicast from one sender to at least N receivers (3 in this example). 
7.5 Atomicity 
Intent 
To reduce the size of the state space by reducing interleaving using committed locations, thus speeding up the verification. 
Motivation 
Uppaal uses an asynchronous execution model, i.e., edges from di erent automata can interleave, and Uppaal will explore all possible interleavings. Partial order reduction is an automatic technique for eliminating unnecessary interleavings, but Uppaal does not support partial order reduction. In many situations, unnecessary interleavings can be identified and eliminated by making part of the model execute in atomic steps. 
Structure 
Committed locations are the key to achieving atomicity. When any of the processes is in a committed location, then time cannot pass and at least one of these processes must take part in the next transition. Notice that this does not rule out interleaving when several processes are in a committed location. On the other hand, if only one process is in a committed location, then that process must take part in the next transition. Therefore, several edges can be executed atomically by marking intermediate locations as committed and avoiding synchronisations with other processes in the part that must be executed atomically, thus guaranteeing that the process is the only one in a committed location. 
Sample 
The pattern is used in the Queue process of the train gate example, see Fig. 26. 
33 
list[len]:=e, add? len++notempty! 
len>0 
empty! len==0 
rem! len>=1 len--, 
i := 0 

i < len list[i]:=list[i+1], i++ 
Fig. 26. When removing the front element from the queue, all other elements must be shifted down. This is done in the loop in the Shiftdown location. To avoid unnecessary interleavings, the location is marked committed. Notice that the edge entering Shiftdown synchronises over the rem channel. It is important that target locations of edges synchronising over rem in other processes are not marked committed. 
Known Uses 
Encoding of control structure A very common use is when encoding control structures (like the encoding of a for-loop used in the IntQueue process of the train-gate example): In these cases the interleaving semantics is often undesirable. 
Multi-casting Another common use is for complex synchronisation patterns. The standard synchronisation mechanism in Uppaal only supports binary or broadcast synchronisation, but by using committed locations it is possible to atomically synchronise with several processes. One example of this is in the train-gate example: Here the Gate process acts as a mediator between the trains and the queue, first synchronising with one and then the other – using an intermediate committed location to ensure atomicity. 
7.6 Urgent Edges Intent 
To guarantee that an edge is taken without delay as soon as it becomes enabled. 
Motivation 
Uppaal provides urgent locations as a means of saying that a location must be left without delay. Uppaal provides urgent channels as a means of saying that a synchronisation must be executed as soon as the guards of the edges involved are enabled. There is no way of directly expressing that an edge without synchronisation should be taken without delay. This pattern provides a way of encoding this behaviour. 
34 
Structure 

The encoding of urgent edges introduces an extra process with a single location and a self loop (see Fig. 27 left). The self loop synchronises on the urgent channel go. An edge can now be made urgent by performing the complimentary action (see Fig. 27 right). The edge can have discrete guards and arbitrary updates, 
but no guards over clocks. 
go!


‚‚‚‚‚ 

go? 
Fig. 27. Encoding of urgent edges. The go channel is declared urgent. 
Sample 

This pattern is used in a model of a box sorting plant (see http://www.cs.auc. dk/∼behrmann/esv03/exercises/index.html#sorter): Boxes are moved on a belt, registered at a sensor station and then sorted by a sorting station (a piston that can kick some of the boxes of the belt). Since it takes some time to move the boxes from the sensor station to the sorting station, a timer process is used to delay the sorting action. Figure 28 shows the timer (this is obviously not the only encoding of a timer – this particular encoding happens to match the one used in the control program of the plant). The timer is activated by setting a shared variable active to true. The timer should then move urgently from the passive location to the wait location. This is achieved by synchronising over the urgent channel go. 
x==ctime eject! active:=false 

x<=ctime 
active==true go? 
Fig. 28. Sample of a timer using an urgent edge during activation. 
35 
7.7 Timers 
Intent 
To emulate a timer where, in principle, time decreases until it reaches zero, at which point the timer is said to time-out. 
Motivation 
Although clocks are powerful enough to model timing mechanisms, some systems are more naturally modelled using timers, in particular event based models. In such models, a timer is started, may be restarted, and counts down until a time-out event is generated. 
Structure 
The pattern gives an equivalent of a timer object mapped on a process in Uppaal. We define the following operations for a timer object t: 
– 
void set(TO): this function starts or restarts the timer with a time-out value of TO. The timer will count down for TO time units. TO is an integer. 

– 
bool expired(): this function returns true if the timer has expired, false otherwise. When the timer has not been started yet, it is said to have expired. This function may be called at any time to test the timer. 


We map the above defined timer as a process in Uppaal. When a timer t is to be used in the model, its functions are mapped as follows: 
– 
t.set(v) where v is an integer variable is mapped to the synchronisation set! and the assignment value := v, where the channel set and the integer value are the parameters of the timer template. 

– 
t.expired() is mapped to the guard value == 0, where value is a parameter of the timer template. 


As a variant of this basic timer model, it is possible to generate a time-out synchronisation, urgent or not depending on the needs, by using the pattern to encode urgent edges shown in Fig. 27. If the time-out value is a constant, we can optimise the coding to: 
– 
t.set() (no argument since the time-out is a constant) is mapped to set!. 

– 
t.expired() is mapped to active == false where active is a parameter of the template. 


The templates are shown in Fig. 29. The two states correspond to the timer having expired (timer inactive) and waiting to time-out (timer active). The template 
(a) makes use of a feature of Uppaal to mix integers and clocks in clock constraints. The constraint is dynamic and depends on the value of the integer. When returning to the state Expired, the timer resets its value, which has the e ect to (1) use variable reduction (see pattern 7.1) and (2) to provide a simple way to test for a time-out. The template (b) is simpler in the sense that a constant is used in the clock constraints. Testing for the time-out is equivalent to test on the boolean variable active. 
36 
set? set? 
x:=0 Waiting 
x:=0, active:=true Waiting Expired x<=value Expired x<=TO 
set? set? x:=0 x:=0 
x==value x==TO value:=0 active:=false 
(a) Timer with variable time-out. (b) Timer with constant time-out. 
Fig. 29. Template of the timer pattern. Template (a) has int value; chan set as parameters and template (b) has bool active; chan set; const TO as parameters. Both templates have the local declaration clock x. 
Known Uses 
A variation of the timer pattern is used in the box sorting machine of the previous pattern (for educational purposes reconstructed in Lego): A timer is activated when a coloured brick passes a light sensor. When the timer times out a piston kicks the brick from the transport belt. 
7.8 Bounded Liveness Checking 
Intent 
To check bounded liveness properties, i.e., properties that are guaranteed not only to hold eventually but within some specified upper time-bound. Time-bounded liveness properties are essentially safety properties and hence often computationally easier to verify. Thus moving from (unconditional) liveness properties to a time-bounded versions will not only provide additional information — i.e., if one can provide a valid bound — but will also lead to more eÿcient verification. 
Motivation 
For real-time systems general liveness properties are often not suÿciently expressive to ensure correctness: the fact that a particular property is guaranteed to hold eventually is inadequate in case hard real-time deadlines must be observed. What is really needed is to establish that the property in question will hold within a certain upper time-limit. 
Structure 
We consider two variations of the pattern for a time-bounded leads-to operator ϕ ;≤t ψ expressing that whenever the state property ϕ holds then the state property ψ must hold within at most t time-units thereafter. 
In the first version of the pattern we use a simple reduction for unbounded leads-to. First the model under investigation is extended with an additional clock z which is reset whenever ϕ starts to hold. The time-bounded leads-to property ϕ ;≤t ψ is now simply obtained by verifying ϕ ; (ψ ∧ z ≤ t). 
In the second — and more eÿcient version — of the pattern we use the method proposed in [54] in which time-bounded leads-to properties are reduced 
37 
to simple safety properties. First the model under investigation is extended with a boolean variable b and an additional clock z . The boolean variable b must be initialised to false. Whenever ϕ starts to hold b is set to true and the clock z is reset. When ψ commences to hold b is set to false. Thus the truth-value of b indicates whether there is an obligation of ψ to hold in the future and z measures the accumulated time since this unfulfilled obligation started. The time-bounded leads-to property ϕ ;≤t ψ is simply obtained by verifying the safety property A2(b =⇒ z ≤ t). 
A third method not reported is based on augmenting the model under investigation with a so-called test-automata, see [2,1]. 
We have deliberately been somewhat vague about the exact nature of the required augmentation of the model. The most simple case is when the (state) 
′
properties ϕ and ψ are simple locations l and l of component automata. In this simple case the settings of z and b are to be added as assignments of the edges 
′
entering l and l . 
Sample 
In the train gate example presented earlier in this tutorial a natural requirement is that a train is granted access to the crossing within a certain upper time-bound (say 100) after having signalled that it is approaching. In fact, not only is the gate responsible for avoiding collisions on the crossing but also for ensuring a fair and timely handling of requests. In Fig. 30 the Train template has been augmented with a local boolean b and a local clock z. b (to be initialised to 0) is set to 1 on the transition to location Appr and set to 0 on the two transitions to Cross. The clock z is reset on the transition to Appr. On the augmented model we now check the safety property A[](Train1.b==1 imply Train1.z<=100) which establishes that the bounded liveness property holds for Train1. In fact — due to obvious symmetries in the model — it suÿces to establish the property for one train, Train1 say. In this case it would have been advantageous for Train1 to be singleton template in order to avoid augmenting all trains. In particular, the state-space will be substantially smaller in this way. 
Known Uses 
Almost any real-time system will have a number of liveness properties where information as to the time-bounds is vital for the correctness of the systems. The Gearbox Controller of [54] o ers an excellent example where a long list of time-bounded liveness properties are directly obtained from requirements specified by the company Mecel AB. 
7.9 Abstraction and Simulation 
Intent 
The goal of abstraction is to replace the problem of verifying a very large, infeasible concrete system with a smaller, and hopefully feasible abstract system. In particular, the method could be applied in a compositional manner to subsystems, i.e., various concrete subsystems are replaced by suitable abstractions, 
38 
e:=id, x:=0 x>=3
Safe 
Cross x<=5 
appr! 
x:=0, b:=0e:=id, 
x:=0, 
z:=0, 
x>=7 b:=1 
Appr Start
 x<=20 x<= 15 
x<=10, x:=0e==id 
go?
stop? 
e==id x:=0 
Stop 
Fig. 30. The Train-Gate augmented to enable time-bounded liveness checking. 
and the verification e ort is conducted on the composition of these abstract subsystems. 
Motivation 
Despite enormous improvement in the verification capabilities of Uppaal over the past years — and undoubtedly also for the years to come — state-space explosion is an ever existing problem that will be solved by algorithmic advances.9 However, in verifying specific properties of a systems it is often only part of the behaviour of the various components which is relevant. Often the designer will have a good intuition about what these relevant parts are, in which case (s)he is able to provide abstractions for the various components, which are still concrete enough that the given property holds, yet are abstract (and small) enough that the verification e ort becomes feasible. To give a sound methodology two requirements should be satisfied. Firstly, the notion of abstraction applied should preserve the properties of interest, i.e., once a property has been shown to hold for the abstraction it should be guaranteed to also hold for the concrete system. Secondly, the abstraction relation should be preserved under composition of systems. In [46,45] we have put forward the notion of (ready) timed simulation preserving safety properties while being a pre-congruence w.r.t. composition. Moreover, for (suggested) abstractions being deterministic and with no internal transitions, timed simulation may be established using simple reachability checking (and hence by using Uppaal). 
Structure 
Let A be a timed automaton suggested as an abstraction for some (sub)system 
9 unless we succeed in showing P=PSPACE 
39 
S (possibly a network of timed automata). We assume that A is deterministic (i.e., no location with outgoing edges having overlapping guards) and without any internal transitions. For simplicity we shall assume all channels to be non-urgent and no shared variables exist between S and the remaining system. The extension of the technique to allow for urgency and shared variables can be found in [46]. To show that A is indeed an abstraction of S in the sense that A (ready) timed simulates S a test-automata TA is constructed in the following manner: TA has A as a skeleton but with the direction of actions (input/output) reversed. A distinguished new location bad is added and from all locations l and all actions a an a -labelled edge from l to bad is inserted with guard ¬(g1 ∨ ... ∨ gn) where g1 ... gn is the full set of guards of a -labelled edges out of l in the skeleton. Now S is (ready) timed simulated by A — and hence A is a valid abstraction of S 
— precisely if the location bad is unreachable in the composite system S TA. Essentially, TA observes that all behaviour of S is matchable by A. 
Sample 
Consider the Uppaal model in Fig. 31 consisting of a Sender a Receiver and four pipelining processes Pi. Each pipeline process Pi has the obligation of reacting to a stimulus from its predecessor on channel ai and pass it on to its successor on channel ai+1. A local clock is used to model that each pipeline process adds a minimum delay of 2. After having completed the passing on, the pipeline process engages in some internal computation (the small cycle S2, S3, S4). Now assume that we want to verify that the Receiver will have received its stimulus no sooner than after 8 time-units, or in general 2n in a system with n pipeline processes. Obviously, the system we are looking at is subject to an enormous state-space explosion when we increase the number of pipeline elements. However, for establishing the property in question we need only little information about the various subsystems. For P1P2 we essentially only need to know that the time from reacting to the initial stimulus from the Sender to passing this stimulus on to P3 is at least 4. We do not need to worry about the internal computation nor the precise moment in time when the stimulus was passed from P1 to P2. In particular we should be able to replace P1P2 with the much simpler automaton P1P2. To show that this is a valid substitution we simply show that the BAD location is unreachable for the system P1P2TestP1P2, where TestP1P2 is the test automaton for P1P2. A similar abstraction P3P4 may obviously be given for the subsystem P3P4 and the desired property may now be established for the “much” simpler system P1P2P3P4, rather than the original system. 
Known Uses 
The described technique can be found in full details in the Ph.D. thesis of Jensen [45]. In [46] the technique has been successfully applied to the verification of a protocol for controlling the switching between power on/o states in audio/video components described in [48]. 
40 
Sender P1 P2 P3 P4 Receiver 
S0 S0S0 S0 

x>=2 

x>=2 

x>=2 

x>=2 
S1 

S1 
S4 
S4 
S4 
S4
S3 
S3 
S3 
S3 
a1? 
a2? 
a3? 
a4? 
S0 
S0
x:=0 
x:=0 
x:=0 
x:=0
S1 
S1 
S1 
S1 

‚‚‚‚‚ 
‚‚‚‚‚ ‚‚‚‚‚ ‚‚‚‚‚ ‚‚‚‚‚ 
a1! 
a5? 
a2! a3! a4! a5!
S2 S2 S2 S2 
S0 

Fig. 32. A suggested abstraction and its test automaton. 
8 Conclusion 
Uppaal is a research tool available for free at http://www.uppaal.com/ that features an intuitive graphical interface. It has been ported to di erent platforms and it is in constant development. There are di erent development branches and tools that make use of Uppaal: 
Cost–UPPAAL supports cost annotations of the model and can do minimal cost reachability analysis [51]. This version also has features for guiding the search. This version can be downloaded from http://www.cs.auc.dk/ ∼behrmann/ guiding/. 
Distributed–UPPAAL runs on multi-processors and clusters using the combined memory and CPU capacity of the system [17,9]. T–UPPAAL test case generator for black-box conformance testing, see http: //www.cs.auc.dk/∼marius/tuppaal/. Times is a tool set for modelling, schedulability analysis, and synthesis of (optimal) schedules and executable code. The verification uses Uppaal [6]. 
On-going work on the model-checker includes support for hierarchical timed automata, symmetry reduction, U-Code (Uppaal code, large subset of C), im
41 

proved memory management, etc. The tool has been successfully applied to case studies ranging from communication protocols to multimedia applications: 
Bang & Olufsen audio/video protocol. An error trace with more than 2000 
transition steps was found [35]. TDMA Protocol Start-Up Mechanism was verified in [55]. Bounded retransmission protocol over a lossy channels was verified in [24]. Lip synchronisation algorithm was verified in [23]. Power-down controller in an audio/video component was designed and ver
ified in collaboration with Bang & Olufsen in [34]. 
Guided synthesis of control programs for a steel production plant was done in [43]. The final control programs were compiled to run on a Lego model of the real plant. 
Gearbox controller was formally designed and analysed in [54]. Lego Mindstorm programs written in “Not Quite C” have been verified in [44]. Field bus protocol was modelled and analysed in [30]. Bi-phase Mark Protocol was modelled and analysed in [59] with Uppaal 
and PVS. Controller for a wafer scanner was designed with the aid of Uppaal in [37]. Car supervision system was formally modelled and analysed in [33]. IEEE1394a root contention protocol was modelled and verified in [58]. 
Uppaal is also used in a number of courses on real-time systems and formal verification: 
– http://user.it.uu.se/∼paupet/#teaching 
Real-time and formal method courses at Uppsala University. 
– http://csd.informatik.uni-oldenburg.de/teaching/fp 
realzeitsys 
ws0001/ result/eindex.html 
Practical course “Real-Time Systems” at the University of Oldenburg. 
– http://fmt.cs.utwente.nl/courses/systemvalidation/ 
System Validation (using Model Checking) at the University of Twente. 
– http://www.cs.auc.dk/∼behrmann/esv03/ 
Embedded Systems Validation at Aalborg University. 
– http://www.cs.auc.dk/∼kgl/TOV04/Plan.html 
Test and Verification at Aalborg University. 
– http://www.seas.upenn.edu/∼pappasg/EE601/F03/ 
Hybrid Systems at the University of Pennsylvania. 
– http://www.it.uu.se/edu/course/homepage/proalgebra 
Process Algebra at Uppsala University. 
– http://www.cs.auc.dk/∼luca/SV/ 
Semantics and Verification. 
– http://www.cs.depaul.edu/programs/courses.asp?subject=SE&courseid=533 
Software Validation and Verification at DePaul University. 
– http://www.cs.bham.ac.uk/∼mzk/courses/SafetyCrit/ 
Safety Critical Systems and Software Reliability at the University of Birmingham. 
42 
– http://fmt.cs.utwente.nl/courses/sysontomg/ 
Systeem-ontwikkelomgevingen at the University of Twente. 
– http://www.niii.ru.nl/F.Vaandrager/PV/ 
Protocol Validation at the Radboud University of Nijmegen. 
Finally the following books have parts devoted to Uppaal: 
– 
Concepts, Algorithms and Tools for Model-Checking [47]: Lecture notes in its current form. It treats both Spin and Uppaal. 

– 
Systems and Software Verification: Model-checking Techniques and Tools [22]: This book identifies 6 important tools and has a chapter on Uppaal. 


References 
1. 
Luca Aceto, Patricia Bouyer, Augusto Burgue˜no, and Kim Guldstrand Larsen. The power of reachability testing for timed automata. Theoretical Computer Science, 1–3(300):411–475, 2003. 

2. 
Luca Aceto, Augusto Burgue˜no, and Kim G. Larsen. Model checking via reachability testing for timed automata. In Bernhard Ste en, editor, Tools and Algorithms for Construction and Analysis of Systems, 4th International Conference, TACAS ’98, volume 1384 of Lecture Notes in Computer Science, pages 263–280. Springer– Verlag, April 1998. 

3. 
Rajeev Alur, Costas Courcoubetis, and David L. Dill. Model-checking for real-time systems. In 5th Symposium on Logic in Computer Science (LICS’90), pages 414–425, 1990. 

4. 
Rajeev Alur and David L. Dill. Automata for modeling real-time systems. In Proc. of Int. Colloquium on Algorithms, Languages, and Programming, volume 443 of LNCS, pages 322–335, 1990. 

5. 
Tobias Amnell, Gerd Behrmann, Johan Bengtsson, Pedro R. D’Argenio, Alexandre David, Ansgar Fehnker, Thomas Hune, Bertrand Jeannet, Kim G. Larsen, 


M. Oliver M¨oller, Paul Pettersson, Carsten Weise, and Wang Yi. Uppaal -Now, Next, and Future. In F. Cassez, C. Jard, B. Rozoy, and M. Ryan, editors, Modelling and Verification of Parallel Processes, number 2067 in Lecture Notes in Computer Science Tutorial, pages 100–125. Springer–Verlag, 2001. 
6. 
Tobias Amnell, Elena Fersman, Leonid Mokrushin, Paul Pettersson, and Wang Yi. Times – a tool for modelling and implementation of embedded systems. In TACAS 2002, volume 2280 of Lecture Notes in Computer Science, pages 460–464. Springer–Verlag, April 2002. 

7. 
Felice Balarin. Approximate reachability analysis of timed automata. In 17th IEEE Real-Time Systems Symposium. IEEE Computer Society Press, 1996. 

8. 
Gerd Behrmann. Data Structures and Algorithms for the Analysis of Real Time Systems. PhD thesis, Aalborg University, 2003. 

9. 
Gerd Behrmann. Distributed reachability analysis in timed automata. Software Tool For Technology Transfer (STTT), 2004. Currently available in the Online First edition of STTT. 

10. 
Gerd Behrmann, Johan Bengtsson, Alexandre David, Kim G. Larsen, Paul Petters-son, and Wang Yi. Uppaal implementation secrets. In Proc. of 7th International Symposium on Formal Techniques in Real-Time and Fault Tolerant Systems, 2002. 

11. 
Gerd Behrmann, Patricia Bouyer, Kim G. Larsen, and Radek Pel¡E1¿nek. Lower and upper bounds in zone-based abstractions of timed automata. International Journal on Software Tools for Technology Transfer, September 2005. 

12. 
Gerd Behrmann, Alexandre David, Kim G. Larsen, John H°akansson, Paul Pettersson, Wang Yi, and Martijn Hendriks. UPPAAL 4.0. In Proceedings of the 3rd International Conference on the Quantitative Evaluation of SysTems (QEST) 2006, IEEE Computer Society, pages 125–126, 2006. 

13. 
Gerd Behrmann, Alexandre David, Kim G. Larsen, M. Oliver M¨oller, Paul Petters-son, and Wang Yi. Uppaal -present and future. In Proc. of 40th IEEE Conference on Decision and Control. IEEE Computer Society Press, 2001. 

14. 
Gerd Behrmann, Alexandre David, Kim G. Larsen, and Wang Yi. Unification & sharing in timed automata verification. In SPIN Workshop 03, volume 2648 of LNCS, pages 225–229, 2003. 

15. 
Gerd Behrmann, Ansgar Fehnker, Thomas Hune, Kim G. Larsen, Paul Petters-son, and Judi Romijn. Eÿcient guiding towards cost-optimality in uppaal. In 


43 
T. Margaria and W. Yi, editors, Proceedings of the 7th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, number 2031 in Lecture Notes in Computer Science, pages 174–188. Springer–Verlag, 2001. 
16. 
Gerd Behrmann, Ansgar Fehnker, Thomas Hune, Kim G. Larsen, Paul Pettersson, Judi Romijn, and Frits Vaandrager. Minimum-cost reachability for priced timed automata. In Maria Domenica Di Benedetto and Alberto Sangiovanni-Vincentelli, editors, Proceedings of the 4th International Workshop on Hybrid Systems: Computation and Control, number 2034 in Lecture Notes in Computer Sciences, pages 147–161. Springer–Verlag, 2001. 

17. 
Gerd Behrmann, Thomas Hune, and Frits Vaandrager. Distributed timed model checking -How the search order matters. In Proc. of 12th International Conference on Computer Aided Verification, Lecture Notes in Computer Science, Chicago, Juli 2000. Springer–Verlag. 

18. 
Gerd Behrmann, Kim G. Larsen, Justin Pearson, Carsten Weise, and Wang Yi. Eÿcient timed reachability analysis using clock di erence diagrams. In Proceedings of the 12th Int. Conf. on Computer Aided Verification, volume 1633 of Lecture Notes in Computer Science. Springer–Verlag, 1999. 

19. 
Johan Bengtsson. Clocks, DBMs and States in Timed Systems. PhD thesis, Uppsala University, 2002. 

20. 
Johan Bengtsson, Bengt Jonsson, Johan Lilius, and Wang Yi. Partial order reductions for timed systems. In Proceedings of the 9th International Conference on Concurrency Theory, September 1998. 

21. 
Johan Bengtsson, Kim G. Larsen, Fredrik Larsson, Paul Pettersson, Yi Wang, and Carsten Weise. New generation of uppaal. In Int. Workshop on Software Tools for Technology Transfer, June 1998. 

22. 
Beatrice Berard, Michel Bidoit, Alain Finkel, Francois Laroussinie, Antoine Petit, Laure Petrucci, Philippe Schnoebelen, and Pierre McKenzie. Systems and Software Verification: Model-Checking Techniques and Tools. Springer–Verlag, 2001. 

23. 
Howard Bowman, Giorgio P. Faconti, Joost-Pieter Katoen, Diego Latella, and Mieke Massink. Automatic verification of a lip synchronisation algorithm using uppaal. In Bas Luttik Jan Friso Groote and Jos van Wamel, editors, In Proceedings of the 3rd International Workshop on Formal Methods for Industrial Critical Systems. Amsterdam , The Netherlands, 1998. 

24. 
Pedro .R. D’Argenio, Joost-Pieter. Katoen, Theo C. Ruys, and Jan Tretmans. The bounded retransmission protocol must be on time! In In Proceedings of the 


44 
3rd International Workshop on Tools and Algorithms for the Construction and Analysis of Systems, volume 1217 of LNCS, pages 416–431. Springer–Verlag, April 1997. 
25. 
Alexandre David. Hierarchical Modeling and Analysis of Timed Systems. PhD thesis, Uppsala University, November 2003. 

26. 
Alexandre David, Gerd Behrmann, Kim G. Larsen, and Wang Yi. New uppaal architecture. In Paul Pettersson and Wang Yi, editors, Workshop on Real-Time Tools, Uppsala University Technical Report Series, 2002. 

27. 
Alexandre David, Gerd Behrmann, Kim G. Larsen, and Wang Yi. A tool architecture for the next generation of uppaal. In 10th Anniversary Colloquium. Formal Methods at the Cross Roads: From Panacea to Foundational Support, LNCS, 2003. 

28. 
Alexandre David, John H°akansson, Kim G. Larsen, and Paul Pettersson. Model checking timed automata with priorities using dbm subtraction. In Proceedings of the 4th International Conference on Formal Modelling and Analysis of Timed Systems (FORMATS’06), volume 4202 of LNCS, pages 128–142, 2006. 

29. 
Alexandre David, M. Oliver M¨oller, and Wang Yi. Formal verification of UML statecharts with real-time extensions. In Ralf-Detlef Kutsche and Herbert Weber, editors, Fundamental Approaches to Software Engineering, 5th International Conference, FASE 2002, volume 2306 of LNCS, pages 218–232. Springer–Verlag, 2002. 

30. 
Alexandre David and Wang Yi. Modelling and analysis of a commercial field bus protocol. In Proceedings of the 12th Euromicro Conference on Real Time Systems, pages 165–172. IEEE Computer Society, 2000. 

31. 
Ansgar Fehnker. Citius, Vilius, Melius: Guiding and Cost-Optimality in Model Checking of Timed and Hybrid Systems. PhD thesis, University of Nijmegen, April 2002. 

32. 
Elena Fersman. A Generic Approach to Schedulability Analysis of Real-Time Systems. PhD thesis, Uppsala University, November 2003. 

33. 
B. Gebremichael, T. Krilavicius, and Y.S. Usenko. A formal analysis of a car periphery supervision system. Technical Report NIII-R0418, Radboud University of Nijmegen, 2004. 

34. 
Klaus Havelund, Kim G. Larsen, and Arne Skou. Formal verification of a power controller using the real-time model checker uppaal. 5th International AMAST Workshop on Real-Time and Probabilistic Systems, available at http://www.uppaal.co m, 1999. 

35. 
Klaus Havelund, Arne Skou, Kim G. Larsen, and Kristian Lund. Formal modelling and analysis of an audio/video protocol: An industrial case study using uppaal. In Proceedings of the 18th IEEE Real-Time Systems Symposium, pages 2–13, December 1997. 

36. 
M. Hendriks, G. Behrmann, K.G. Larsen, P. Niebert, and F.W. Vaandrager. Adding symmetry reduction to uppaal. In Proceedings First International Workshop on Formal Modeling and Analysis of Timed Systems (FORMATS 2003), volume 2791 of Lecture Notes in Computer Science, 2003. 

37. 
M. Hendriks, N.J.M. van den Nieuwelaar, and F.W. Vaandrager. Model checker aided design of a controller for a wafer scanner. Technical Report NIII-R0430, Radboud University of Nijmegen, 2004. 

38. 
Martijn Hendriks and Kim G. Larsen. Exact acceleration of real-time model checking. In E. Asarin, O. Maler, and S. Yovine, editors, Electronic Notes in Theoretical Computer Science, volume 65. Elsevier Science Publishers, April 2002. 

39. 
Thomas A. Henzinger. Symbolic model checking for real-time systems. Information and Computation, 111:193–244, 1994. 

40. 
Gerard J. Holzmann. Design and Validation of Computer Protocols. Prentice-Hall, 1991. 

41. 
Gerard J. Holzmann. An analysis of bitstate hashing. Formal Methods in System Design, 13:289–307, 1998. 

42. 
John E. Hopcroft and Je rey D. Ullman. Introduction of Automata Theory, Languages, and Computation. Addison Wesley, 2001. 

43. 
Thomas Hune, Kim G. Larsen, and Paul Pettersson. Guided synthesis of control programs using uppaal. In Ten H. Lai, editor, Proc. of the IEEE ICDCS International Workshop on Distributed Systems Verification and Validation, pages E15–E22. IEEE Computer Society Press, April 2000. 

44. 
Torsten K. Iversen, K°are J. Kristo ersen, Kim G. Larsen, Morten Laursen, Rune G. Madsen, Ste en K. Mortensen, Paul Pettersson, and Chris B. Thomasen. Model-checking real-time control programs — Verifying LEGO mindstorms systems using uppaal. In Proc. of 12th Euromicro Conference on Real-Time Systems, pages 147– 


45 
155. IEEE Computer Society Press, June 2000. 
45. 
Henrik Ejersbo Jensen. Abstraction-Based Verification of Distributed Systems. PhD thesis, Aalborg University, June 1999. 

46. 
Henrik Ejersbo Jensen, Kim Guldstrand Larsen, and Arne Skou. Scaling up uppaal automatic verification of real-time systems using compositionality and abstraction. In Mathai Joseph, editor, Formal Techniques in Real-Time and Fault-Tolerant Systems, 6th International Symposium, FTRTFT 2000, volume 1926 of Lecture Notes in Computer Science, pages 19–20. Springer–Verlag, 2000. 

47. 
Joost-Pieter Katoen. Concepts, Algorithms, and Tools for Model Checking. http://www.it-c.dk/people/hra/mcpa/katoen.ps, 1999. 

48. 
Arne Skou Klaus Havelund, Kim Guldstrand Larsen. Formal verification of a power controller using the real-time model checker Uppaal. In 5th Int. AMAST Workshop on Real-Time and Probabilistic Systems, volume 1601 of Lecture Notes in Computer Science, pages 277–298. Springer–Verlag, 1999. 

49. 
L.M. Kristensen and T. Mailund. A Generalised Sweep-Line Method for Safety Properties. In Proc. of FME’02, volume 2391 of LNCS, pages 549–567. Springer-Verlag, 2002. 

50. 
K°are J. Kristo ersen. Compositional Verification of Concurrent Systems. PhD thesis, Aalborg University, August 1998. http://www.itu.dk/people/kjk/publications.html. 

51. 
Kim G. Larsen, Gerd Behrmann, Ed Brinksma, Ansgar Fehnker, Thomas Hune, Paul Pettersson, and Judi Romijn. As cheap as possible: Eÿcient cost-optimal reachability for priced timed automata. In G. Berry, H. Comon, and A. Finkel, editors, Proceedings of CAV 2001, number 2102 in Lecture Notes in Computer Science, pages 493–505. Springer–Verlag, 2001. 

52. 
Kim G. Larsen, Paul Pettersson, and Wang Yi. Uppaal in a nutshell. Int. Journal on Software Tools for Technology Transfer, 1(1–2):134–152, October 1997. 

53. 
Fredrik Larsson, Kim G. Larsen, Paul Pettersson, and Wang Yi. Eÿcient verification of real-time systems: Compact data structures and state-space reduction. In Proc. of the 18th IEEE Real-Time Systems Symposium, pages 14–24. IEEE Computer Society Press, December 1997. 

54. 
Magnus Lindahl, Paul Pettersson, and Wang Yi. Formal design and analysis of a gearbox controller. Springer International Journal of Software Tools for Technology Transfer (STTT), 3(3):353–368, 2001. 

55. 
Henrik L¨onn and Paul Pettersson. Formal verification of a TDMA protocol startup mechanism. In Proc. of the Pacific Rim Int. Symp. on Fault-Tolerant Systems, pages 235–242, December 1997. 

56. 
Brian Nielsen. Specification and Test of Real-Time Systems. PhD thesis, Aalborg University, 2000. 

57. 
Paul Pettersson. Modelling and Verification of Real-time Systems Using Timed Automata: Theory and Practice. PhD thesis, Uppsala University, 1999. 

58. 
D.P.L. Simons and M.I.A. Stoelinga. Mechanical verification of the IEEE 1394a root contention protocol using Uppaal2k. Springer International Journal of Software Tools for Technology Transfer, pages 469–485, 2001. 

59. 
F.W. Vaandrager and A.L. de Groot. Analysis of a biphase mark protocol with Uppaal and PVS. Technical Report NIII-R0445, Radboud University of Nijmegen, 2004. 

60. 
Wang Yi, Paul Petterson, and Mats Daniels. Automatic verification of real-time communicating systems by constraint-solving. In Seventh International Conference on Formal Description Techniques, pages 223–238, 1994. 


46 
Appendix 
Expression ! ID | NAT 
| Expression ’[’ Expression ’]’ 
| ’(’ Expression ’)’ 
| Expression ’++’ | ’++’ Expression 
| Expression ’--’ | ’--’ Expression 
| Expression AssignOp Expression 
| UnaryOp Expression 
| Expression BinaryOp Expression 
| Expression ’?’ Expression ’:’ Expression 
| Expression ’.’ ID 
UnaryOp ! ’-’ | ’!’ | ’not’ 
BinaryOp ! ’<’ | ’<=’ | ’==’ | ’!=’ | ’>=’ | ’>’ 
| ’+’ | ’-’ | ’*’ | ’/’ | ’%’ | ’&’ 
| ’|’ | ’^’ | ’<<’ | ’>>’ | ’&&’ | ’||’ 
| ’<?’ | ’>?’ | ’and’ | ’or’ | ’imply’ 
AssignOp ! ’:=’ | ’+=’ | ’-=’ | ’*=’ | ’/=’ | ’%=’ 
| ’|=’ | ’&=’ | ’^=’ | ’<<=’ | ’>>=’ 
Fig. 33. Syntax of expressions in BNF. 
47 
Table 3. Options of verifyta and the corresponding options in the GUI. Defaults of verifyta are shown in boldface. 
State Space Representation 
-C DBM Use DBMs rather than a minimal constrain graph [53] in the state representation used to store reachable states. This increases the memory usage (more so in models with many clocks), but is often faster. 
-A Over approximation Use convex hull over-approximation [7]. For timed systems, this can drastically increase verification speed. For untimed systems, this has no e ect. 
-Z Under approximation Use bit-state hashing under-approximation. This reduces memory consumption to a more of less fixed amount. The precision of the approximation is controlled by changing the hash table size. Known as super-trace in [40,41]. 
-T Reuse Speed up verification by reusing the generated state-space when possible. For some combinations of properties this option can possibly lead to a larger state-space representation, thus nullifying the speedup. 
-U When representing states with minimal constraint graphs, this option changes how states are compared. It reduces the memory consumption at the expense of a more time consuming comparison operator. The reduced memory usage might cancel out the overhead. In the GUI, this is always on. 
-H Change the size of hash tables used during verification. Can give a speedup for large systems. 
State Space Reduction 
-S0 None Store all reachable states. Uses most memory, but avoids that any state is explored more than once. 
-S1 Conservative 
Store all non-committed states. Less memory when committed locations are used, and for most models states are only explored once. 
-S2 Aggressive Try hard to reduce the number of states stored. Uses much less memory, but might take much more time. Do not combine this option with depth first search, as the running time increases drastically. 
Search Order 
-b Breadth First 
Search the state space using a breadth first strategy. -d Depth First Search the state space using a depth first strategy. 
Trace Options 
-t0 Some Trace Generate some diagnostic trace. -t1 Shortest Trace Generate the shortest (in number of steps) trace. -t2 Fastest Trace 
Generate the fastest (smallest time delay) trace. -f Write traces to XTR trace files (which can be read by the GUI). -y By default concrete traces (showing both delay and control transitions) are 
produced. This option produces symbolic traces like those shown in the GUI. 
48 


1 



Introduction: The World of Real-Time Systems 

1.1 WHAT ARE REAL-TIME SYSTEMS? 
Real-time systems ,u-e computer systems that monitor, respond to, or control au external environment. This environment is connected to tl1e (,'Ofllputer system through senson;, actuators. and other input-output interfaces. It may wnsisl of' physk,11 or biological objects of any fonn and structure. Often, humans are par1 of the connected extenial world, hut a wide range of other natural and artit1cial ohjcct~. as wcU as ,mimals, are also possible. 
The computer system must meet various timing and other constraints that are i,nposed on it by the real-time behavior of the external world tu which it is interfaced. Hence comes the name real time. Another name for many of thes€' systems is reactice systems, because their primary purpose is to respond to or react to signals from th cir em~ronment. A real-time computer system may be a component of a larger system in which ii is embedded; reasonably. such a computer component is called an <'mbedded system. 
Applications and examples of real-time systems are ubi4u.itous ,md proliferating, appearing as part of our G-ommerdal, goveni, nent, military, medical, educational, and cultural infrastructures. Included <1re: 
• 
vehicle systems for automobiles, s11bways, aircraft. railways. and ships 

• 
traffic control for highways, air.;pace, railway tracks, and shipping lanes 

• 
process control for power plants, chemical plants, and mnsumer products such as soft drinks and beer 

• 
medical systems fur radiation tberapy, patient monitoring, anrl defib,illation 

• 
military uses such as flring weapons, tracking, and command and t'untrol 

• 
manufactuling systems "~th robots 


Copyrighted Material 

2 ► Chapter 1. Introduction: The World of Real-Time Systems 
• 
telephone, rndio, and satellite communications 

• 
computer games 

• 
multimedia systems that provide text. graphic, audio, and video interfaces 

• 
household systems for monitoring and controlling appliances 

• 
building ,nanagers that control such entities a~ heat, lights, doors, and elevators 


A simple example of a reactive system is a digital watch that responds to button presses for displaying and setting various times, stop"atchcs, and alarms. This is also obviously a real-time system because it must r<·spond to clock signals predictably and rapidly enough to display the time accurately. An automobile c-rnise control system is a good example of an embedded system. It regulates car ~-peed hy sensing the clrivf' axle rotations, speedometer. cruise control switch, and th•ottlc to control tlw bmke and throttle; it clearly has timing and otl1er constraints related to pcrfonnancc and safe!). 

1.1.1 Real-Timeversus Conventional Software 
Computer hardware for real-time applications typically consists of a number of fairly standard component~ such as proci>ssors, memory units, buses, and peripherals, connected to some real-time input and output devices such as sensors and actuators. Our concern is mainly ,vith the software or programs running on this hardware. Real-tiine software differs significantly from conventional software in a number of ways. 
First is the dominant role of liming co11stroi11ts.A program ,nust not only produce the correct answer or ontput, but it must also compute the answer "on time." In other words, a program must be both logically and l!lmporallyC'Orred. More generally, realtime software must also satisfy timing assertions that involve relations over relative ,md absolute times. Tbc most common and simplest such assertion is a deadline-a limit 011 tl1e absolute or relative time whc>n a computation must complete. In a robot control system. for example, there may be a deadline or limit betwee11 the lime that a ,noving robot senses an obstruction in its path and the time that an actuator, such as a wheel controller, is activated to move the robot in a safer direction. 
A c111alitative distinction can be made between hare/and ~oft real-time ~ysterns. 
Hard real-time systems are those that, ,vithout exception, must meet l11eir ti1niJ1g con
staints-if a constraint is violated, the system fails. At the other extreme are soft real
tjme systems which can still be considered successful, that is, perform their mission, 
despite missing some constraints. There is a continuum between the extrernes of"hard
ness" and "sofh1ess," and most systems flt somewbere io between. 
For example. a very hard system might be one that controls the vertical motion of 
an elevator; missing a particular timiog constraint <:<midmean that tlw elevator stops 
between two noors, requiring emergency procedures to rescue the occupants. A very 
soft subsystem might beone that counts the number of vehicles per un.il of time enter
ing a highway, and does this when l11e system has nol11ing else to do; by defl11ilioo, il 
can fail to complete a count. A communication system that OCC'asionallv loses messages 
(but informs the sender) !lts in the middle of the hard/soft spectrnm. Another example 
of a softer application is a telephone system that someti111es fails to make a eonnectiun; 
the sender just dials again. 
1.1What Are Real-Time Systems? I 3 
Most timing e<ln~iraints arP deterministic. that is, nonstatisticaL in nat11re. Deadlines and other assertions involving time are expressed in terms of exact or fixed values, rather than aggregate mea~ures such as averages. The reason. of course. is that failures to meet deterministic guamntPes often mean mission failures, especially for harder real-time systems. For example, a railway crossing gate on a road must always be dosed by the time a train reaches the crossing, not dosed ·'most of the time" or on tl1e average. These kinds of deterministic constraints can he contrasted with standard software performance and other timing measures which are usually treated a~ governed by some stochastic process. 
A seeond distinguishing feature of real-time systems is co11r111re11cy.Computer systems use (.'()ncurrency to improve performance. for example. by employing severnl processors nmning in parallel. Many systems also use <.,'<>ncurrency as a model to represent logically parallel activities, even though they may he implemented by interleaving the activities on a single processor. In addition to these reasons, real-time systems must also deal ,vith the inl1erent physical concurrency that i:, part of the external world to which they are connected. Signals from the environment can arrive simultaneously; physically disjoint and parallel activitiPS may be 111onitorecland controlled by a single computer system; it is often ne<.-essa,y to know the real time at which signals are received: and output signals may need to be emitted at approximat1·ly tlw same time due to timing constrai11ts. 
Systems clesign becomes especially <lifftcult when one combines the problems of concurrency ,vith tl1ose related to time. Tnan illuminating article on real-time programming. [Wi,th77] defined an informal hif'rarchy of program <.,'Omplexity:The first or lowest level of software complexity-the least <.-omplex-are sequential programs; next in complexity are multiprograms which create an illusion of parallelism by factoring out time (eliminating interrupts at the higher level). implementing logical parallelism typically via coroutines, and providing for synchronizatiou and resomce management; the higbest and most complex level are real-time programs whit'h include thP parallel features of multiprograms but are also execution-time clcrwndent. 
A third major characteristiC' of real-time systems is the emphasis 011 and signi6cance of t-eliabllitrJand fault tolerance. RC:'liahility is a measure of how often a syst<·m will fail. Altematively, to paraphrase [Levesonl;l.'5, p.172J, it is the probability that a system "~II perform C.'Orrcctlyover a given period of time. However, virhially no system is perfectly rehablc ancl failures must be expected. Fault tolerance is concerned with the recognition and handling of' failures. Errors anti failures can be ver)' costly. causing, for example, money losses, property damage. mlssion failnres, or loss of'human life. Conse<1nently, it is very importru1t to avoid failures if possible, through techniques for reliability, and to respond appropriately, gracefully, and with as little c,-ost as possible to failures that do occur (fault toleranc.-e). 
Systems or parts of systems can hP classified according to tl1eir criticality,which is a measure of the failure cost-the higher the c,-ost of failure, tl1e more critical the system. A very critical system ,vith high failure cost might control an aircraft or a nuclear power plant. Note tl1at criticality is a different dimension than hardness/softness. even tl1ough hardness and criticality often go together. as in the last examples. A computer game might still be a l1ard systerrr, even tl10ugh it is not a c·rilical one; if a c.-onstraint is not met, the game migbt fail but the failnre may be benign to the participiuit(s). 

4 I Chapter 1. Introduction: The World of Real-Time Systems 
Most conventional computer systems are general purposP. They nm several applications at the same time, and the applications are often nn known to the system designers. Real-time systems, on the other hand. are often a7>plicn(um-specif)cand stand-alone. That i.s, all of the software, including the operating system,is tailor-made or adapted f'or the partknlar applir•atinn. 
While there are examples of completely automatic real-time systems, thP more common conflgurations and applications have one or more hu111m1swho interactively control and monitor the system behavior. The lumum-nu,chine i11teiface.\ueed to be designed cspedallycarefully in order to prevent human enors and confusion. 
A final difference between real-time and conventional programs relates to testingand certificntio11.Because of the high costs associated with failures, it is usually not feasible to test and debug systems with their actual complete environments. Jnste,1d, one must rely upon simulations, testing of subsystems, careful specifications, comprehensive ,malysis of designs, and extensive nm-time proccdmes for fault detection and handling. 

1.1.2 A Comprehensive Example:Air Traffic Control 
Air traffic control systems (ATC)1 provide particularly good examples for a number of reasons. First, they are certainly ro1 important, widely known, and difficnlt application [Perry97], and there are many of thmn throughout the world. They also contain instan<.-esof all of the distinguishing features of real-time ~ysterns presented in the previous sc<.:tion.Finally, parts of them elln be ubstructcd to illustrate vm;ous technic·o.l idet1S. 
We <.-onsider the ATC network that monitors aircraft flying in the United States airspace. Figure 1.1 shows the basic control points in the U.S. air traffic control environment. The airspace is divided into volumes called secton1. If a plane is flying in a controlled airspace, there is an air trall1c controller, a person, responsible for that aircraft. As aircraft pass from one sector to auother, control of that aircraft passes from one c.-ontroller to another. Tlw sectors near airports are called Termi11al Radar Appmach Control (TRACON) sectors; here, the air trafl1c controller direC'ts traffic to the tower for landi.ng. and away from the tower to Eu Route sectors after takeoff. 
The main goals of tJ,ese systems are safety, efficiency, and perfonna.n<.-e. We want to prevent eolJL5io11sall(] the occurrenc.-e of other hawrds. For thL5 purpose, air traffic controllers need to assure that adequate aircraft separation distances arc maintained; and that weather hazards, natural obstacles, mid restricted airspaces are avoided. Efficiency and performance goals include maximizing airspace capacity and airp01t throughput, minimizing aircraft delays, and minimizillg foel <.-onsumptio,1. 
At each iJ1dividual center, there may hE> a variety of computer workstations and servers. There are also many forms of communications .unong c.-omponents and between centers, Proposed changes in ATC include the ability for controllers to send flight plans directly from ground ATC to !light management systems on-board an aircraft. Radar ,vill be augmented by aircraft that can repo1t their position-detem1ined through communication with global positioning systems (GPS)-directly to ground control. 
1\Ve usethe ;1bbr('via.tio11 unJmr1ruffkconlrolsys
ATC to m<'an ail' tl'affic control, air trafl:k· control ~)>stem. 
tems, relying on the con:f'xl to distinguish among the three possibilities. 
1.1 What Are Real-Time Systems? • 5 

~CO'.'/  
~  
~  ~  -;:,  
On•g1-oundcontn,1 -- -- On-ground-- 
I&I Control tower  ---- ctRadars  --Co1tt1ol to,'-'C'r11 
C:on1puters  Cc)1llp11h:rs  

Figure 1.1 Air tramc control systPms: Components and control points. 
A Simplil1ed ATC 
Consider the followiug simplified version of' an ATC fScallon&Nast87] as a more r.etailed exa,nple. The p11rpose of the system is to keep trnck of all aircraft ill a given three-dimensional airspace and to ensure that the aircraft maintain a minim11rn separation distanc,-e at all ti mes. Figtu-e l.2 shows the computer system and its external 
cn,~ronment. 
A rnclar tracks the position of each aircraft in the space. When an aircraft enters the space, its presenc~ is announced through a digital c-ommunications subsystem: on lef.ving the space, the computer system broadcasts a notit-e of its depatturc to neighhotirtg sites. The communications subsystem can also beused to co,nmw1icate directly with .u1 aircraft. A c,•cmsole with keyboard and graphics display interfaces to a human operator: it displays the track of each aircraft an<l responds to oper.,tor <.-ommands. Operator commands include ones to interrogate the status and descriptive data for an aircraft and to transmit messages to aircraft, for example. to change direction in order to avoid a collision. 
The radar can scan any portion of the airspace, given sp,K-e <.'OOrt~nates. If the radar detects an object at the c-ommanded position, it returns a ''hit." An aircraft is considered losl if the radar fails to produce a hit; in this case, the operator must hP notified and c-orrectivc action taken. The radar is also used to scan the space for unknO\vn objects and lost aircraft. 

6 ► Chapter1.Introduction:The World of Real-nme Systems 


Depa1tures 
C".ommands Depart11res 
Computer
Ra.ta, 
Comm1mic.atlons 
system 
Ohs•~rvat1ons 
Arrivals 
Coinman<.L5 
i =r 
Figure 12 SimplifiedATC example. 
Some rea~onable timing constraints for handling the various <levic-es a,1d the emironment are: 
1. 
The radar should track each plane in the space at a rate or at least ont' ohservation every 10 second~ per plane. 

2. 
The current position and track or each phne should be updated and displayed at least once every three seconds. 

3. 
A response must be provided to an operator command within two seconds. 


Where do these constraints come from? The objectives are to give the oper.1tnrs suHlcienl time to understand the state or the airspace, to control the position of aircraft hy sending messages to them, and to respond qukkly to unusual or emergency situations, involvir,g, for example, potential collisions or overload~. The informally defined global objectives are translated into the above more detailed and precise constraints. 
Note also the inherent parallelism in the environment monitored by the computer. Radar observations, new arrival~. and operator commands can arrive independently and simultmieously. Similarly, the output sign,11s, radar. display. and departure$. ar<> lo~cally concurrent. 
• An ;1utmnatic teller machine that dispenses c-ash lo

► EXERCISES1.1 
credit card and hank customers. 

1. \•\~Jich of the follo\\ong computer systems are real• An elevator system that responds to patmn request~ 
time ,ystems? Justify your answer in terms of the characinside and outside an elevator, t'Ontrollini; the elevator teristics described in the text. and door operations. 
Int J Softw Tools Technol Transfer DOI 10.1007/s10009-014-0361-y 
SMC 

Uppaal SMC tutorial 
Alexandre David · Kim G. Larsen · Axel Legay · Marius Mikucionis · Danny Bøgsted Poulsen 
© Springer-Verlag Berlin Heidelberg 2015 
Abstract This tutorial paper surveys the main features of Uppaal SMC, a model checking approach in Uppaal family that allows us to reason on networks of complex real-timed systems with a stochastic semantic. We demonstrate the modeling features of the tool, new verification algorithms and ways of applying them to potentially complex case studies. 
Keywords Uppaal · Timed automata · Model-checking · Statistical model-checking · Stochastic · Hybrid · Dynamical · Probabilistic 
1 Introduction 

Computer systems play a central role in modern societies and their errors can have dramatic consequences. Proving the correctness of computer systems is therefore a highly relevant activity, on which both industry and academics invest a considerable amount of effort. Among such techniques, one finds (1) testing [14], the traditional approach that detects bugs by exercising the real system with test cases, and (2) formal methods, e.g., model checking [17], that is a more mathematical approach that can guarantee the absence of bugs in the system design. Both approaches have been largely deployed on complex case studies. 
Originally, formal verification was devoted to software and hardware systems by considering their discrete behav-
A. David · K. G. Larsen · M. Mikucionis · D. B. Poulsen Department of Computer Science, Aalborg University, Aalborg, Denmark 
A. Legay (B) INRIA/IRISA Rennes, Rennes, France e-mail: axel.legay@inria.fr 
iors. However, the past years shown that real-time aspects play central roles in systems, and that this feature should be taken into account in the verification process. Developing formal techniques for such systems has thus been the subject of intensive studies. One of the prominent results on the topic was the introduction of model checking techniques for timed automata [1], a natural model to capture real-time systems whose behaviors depends on clocks that can be reset. Among all the tools that have been developed to implement the timed automata theory, one finds Uppaal, which has now become the leader in the area. 
Uppaal is a toolbox for verification of real-time systems represented by (a network of) timed automata extended with integer variables, structured data types, and channel synchronization. The tool is jointly developed by Uppsala University and Aalborg University. It has been applied successfully in case studies ranging from communication protocols to multimedia applications (see [4] and [5] for concrete examples). The first version of Uppaal was released in 1995 [37]. Since then it has been in constant development. In the same spirit as any other professional model checker such as SPIN, Uppaal proposes efficient data structures [36], a distributed version of Uppaal [10,13], guided and minimal cost reachability [11,12,35], work on UML Statecharts [25], acceleration techniques [29], and new data structures and memory reductions [9,15]. 
Unfortunately, timed automata is not a panacea. In fact, albeit powerful, the model is not expressive enough to capture behaviors of complex cyber-physical systems. Indeed, the continuous time behaviors of those systems often rely on rich and complex dynamics as well as on stochastic behaviors. The model checking problem for such systems is undecidable, and approximating those behaviors with timed automata [28] was originally the best one could originally do in Uppaal. 


123 
A. David et al. 

In this paper, we introduce Uppaal SMC that proposes an alternative to the above-mentioned problem. This new branch of Uppaal proposes to represent systems via networks of automata whose behaviors may depend on both stochastic and non-linear dynamical features. Concretely, in Uppaal SMC, each component of the system is described with an automaton whose clocks can evolve with various rates. Such rates can be specified with, e.g., ordinary differential equations. 
To allow for the efficient analysis of probabilistic performance properties, Uppaal SMC proposes to work with statistical model checking (SMC) [38,41], an approach that has been proposed as an alternative to avoid an exhaustive exploration of the state-space of the model. The core idea of SMC is to monitor some simulations of the system, and then use results from the statistics area (including sequential hypothesis testing or Monte Carlo simulation) to decide whether the system satisfies the property with some degree of confidence. By nature, SMC is a compromise between testing and classical model checking techniques. Simulation-based methods are known to be far less memory and time intensive than exhaustive ones, more expressive and are oftentimes the only option. SMC has been implemented in a series of tools that have been applied to a wide range of case studies. Unlike more “academic” exhaustive techniques, SMC gets widely accepted in various research areas such as systems biology [16,20,32–34], energy-centric systems [21], automotive/avionics, or software engineering, in particular for industrial applications. There are several reasons for this success. First, it is very simple to implement, understand and use (especially by industry, software engineers, and generally all people that are not pure researchers but customers of our results and tools) [3,4,8]. Second, it does not require extra modeling or specification effort, but simply an operational model of the system that can be simulated and checked against state-based properties. Third, it allows to model check properties that cannot be expressed in classical temporal logics. Aside from this, the flexibility of SMC allows it to be used in other areas than verification, including planning and robotics. 
In this paper, SMC is presented as a technique for fully stochastic models thus it validates performance properties of a given deterministic (or stochastic) controller in a given stochastic environment. However, we note that SMC is applicable to systems exhibiting non-determinism (transitions with undefined probability distributions): for instance the SMC tool Cosmos has been used to find optimal schedulers for Markov decision processes [26] and in a more recent work 
[22] an experimental version of Uppaal SMC was used for synthesizing controllers for priced timed Markov decision processes. 
This paper is a complete tutorial on Uppaal SMC for hybrid and fully stochastic systems. We illustrate most of the modeling features of the tool, the usage of the graphical interface and of the simulation framework. We discuss the SMC algorithms that are available, and introduce some techniques to deal with dynamical systems. Finally, we present some modeling features and tricks. 
2 Modeling formalism 
The modeling formalism of Uppaal SMC is based on a stochastic interpretation and extension of the timed automata (TA) formalism [1] used in the classical model checking version of Uppaal [4]. For individual TA components the stochastic interpretation replaces the non-deterministic choices between multiple enabled transitions by probabilistic choices (that may or may not be user-defined). Similarly, the nondeterministic choices of time delays are refined by probability distributions, which at the component level are given either uniform distributions in cases with time-bounded delays or exponential distributions (with user-defined rates) in cases of unbounded delays. 
Consider the three TAs A1, A2 and A3 from Fig. 1. Ignoring (initially) the weight annotations on locations and edges, the END locations in the three automata are easily seen to be reachable within the time intervals [6, 12], [4, 12] and [0, +∞). The stochastic interpretation of the three TAs provides probability distributions over the reachability time. For A1, the delay of the three transitions will all be (automatically) resolved by independent, uniform distributions over [2, 4]. Thus the overall reachability time is given as the sum of three uniform distributions as illustrated in Fig. 2a. For A2, the delay distributions determined by the upper and lower 

(a) A1. 

(b) A2. 

(c) A3. 
Fig. 1 Three stochastic timed automata 
123 
Uppaal SMC tutorial 
(a) 


(b) 


(c) 


Fig. 2 Distributions of reachability time, a A1 arrival to END, b A2 arrival to END, c A3 arrival to END 
path to the END location are similarly given by sums of uniform distributions. Subsequently, the combination ( 16 to 5)
6 

of these as illustrated in distribution of the overall delay is obtained by a weighted Fig. 2b. Finally, in A3—in the absence of invariants—delays are chosen according to exponential distributions with user-supplied rates (here 21, 2 and 1). In 
4 

addition, after the initial delay a discrete probabilistic choice 
3

(14 versus 4) is made. The resulting distribution of the overall reachability time is given in Fig. 2c. 
Importantly, the distributions provided by the stochastic semantics are in agreement with the delay intervals determined by the standard semantics of the underlying timed automata. Thus, the distributions for A1 and A2 have finite support by the intervals [ 6, 12] and [ 4, 12] , respectively. Moreover, as indicated by A3, the notion of stochastic timed automata encompasses both discrete and continuous time Markov chains. In particular, the class of reachability time distributions obtained from the stochastic timed automata (STA) of Uppaal SMC includes that of phase-type distributions. 
Networks As in Uppaal, a model in Uppaal SMC consists of a network of interacting component STAs. Here, it 
probability 
C’==2 
A0B0 
T0 
x<=1 y<=2 C’==4 a? 
T1 
a! 
b! 
b? 




T3 
AB T 
Fig. 3 An NSTA, (A| B| T ) 
0.72 
0.60 
0.48 
0.36 

Cost Time
0.24 
0.12 
0 0 1.2 2.4 3.6 4.8 6.0 
Time/Cost 
Fig. 4 Cumulative probabilities for time and Cost-bounded reachability of T3 
is assumed that these components are input-enabled, deterministic (with a probability measure defined on the sets of successors), and non-Zeno. The component STAs communicate via broadcast channels and shared variables to generate Networks of Stochastic Timed Automata (NSTA). The communication is restricted to broadcast synchronizations to keep a clean semantics of only non-blocked components which are racing against each other with their corresponding local distributions. 
Figure 3 shows an NSTA with three parallel components A, B, and T as specified using the Uppaal GUI. One can easily see that the composite system (A| B| T ) has a transition sequence: 
1 a! 
((A0, B0, T0), [ x = 0, y = 0, C = 0] ) −→−→ 1 b! 
((A1, B0, T1), [ x = 1, y = 1, C = 4] ) −→−→ 
((A1, B1, T2), [ x = 2, y = 2, C = 6] ), 
demonstrating that the final location T3 of T is reachable. In fact, location T3 is reachable within cost 0 to 6 and within total time 0 and 2 in (A| B| T ) depending on when (and in which order) A and B choose to perform the output actions a! and b! . Given that the choice of these time delays is governed by probability distributions, a measure on sets of runs of NSTAs is induced, according to which quantitative properties such as “the probability of T3 being reached within a total cost-bound of 4.3” become well defined (Fig. 4). 
For components, as stated in the previous section, Uppaal SMC applies uniform distributions for bounded delays and exponential distributions where a component STA 
123 

A. David et al. 

can remain indefinitely in the same location. In a network of STAs, the components repeatedly race against each other, i.e., they independently and stochastically decide on their own how much to delay before outputting, with the “winner” being the component that chooses the minimum delay. For instance, in the NSTA of Fig. 3, A wins the initial race over B with probability 0.75. 
As observed in [23], though the stochastic semantic of each individual STA in Uppaal SMC is rather simple (but quite realistic), arbitrarily complex stochastic behavior can be obtained by their composition when mixing individual distributions through message passing. The beauty of our model is that these distributions are naturally and automatically defined by the network of STAs. Train crossing example Uppaal SMC takes as input NSTAs as described above. Additionally, there is support for all other features of the Uppaal model checker’s input language such as integer variables, data structures and user-defined functions, which greatly ease modeling. Uppaal SMC allows the user to specify an arbitrary (integer) rate for the clocks on any location. In addition, the automata support branching edges where weights can be added to give a distribution on discrete transitions. It is important to note that rates and weights may be general expressions that depend on the states and not just simple constants. 
To illustrate the extended input language, we consider a train-gate example adapted from [42]. The example model is distributed together with Uppaal SMC tool. A number of trains are approaching a bridge on which there is only one track. To avoid collisions, a controller stops the trains. It restarts them when possible to make sure that trains will eventually cross the bridge. There are timing constraints for stopping the trains modeling the fact that it is not possible to stop trains instantly. The interesting point w.r.t. SMC is to define the arrival rates of these trains. Figure 5ashows the template for a train. The location Safe has no invariant and defines the rate of the exponential distribution for delays. Trains delay according to this distribution and then approach by synchronizing on appr[i] with the gate controller. Here, we define the rational 1+id where id is the
N 2 

identifier of the train and N is the number of trains. Rates are given by expressions that can depend on the current states. Trains with higher id arrive faster. Taking transitions from locations with invariants is given by a uniform distribution over the time interval defined by the invariant. This happens in locations Appr, Cross, and Start, e.g., it takes some time picked uniformly between 3 and 5 time units to cross the bridge. Figure 5b shows the gate controller that keeps track of the trains with an internal queue data structure (not shown here). It uses functions to queue trains (when a train approaches and the bridge is occupied in Occ)or dequeue them (when some train leaves and the bridge is free). 
(a) 

(b)  Free  
e : id_t  
e == front()  
leave[e]?  
dequeue()  

 Occ  
e : id_t  
appr[e]?  stop[tail()]!  
enqueue(e)  


Stopping 
Fig. 5 Templates for the train-gate example, a train, b gate controller 
3 Query language 
In addition to the standard model checking queries—i.e., reachability, invariance, inevitability and leads-to, which are still available—Uppaal SMC provides a number of new queries related to the stochastic interpretation of timed automata. Uppaal SMC allows the user to visualize the values of expressions (evaluating to integers or clocks) along simulated runs. This gives insight to the user on the behavior of the system so that more interesting properties can be asked to the model checker. The concrete syntax applied in Uppaal SMC is as follows: 
simulate N [< =bound]{E1, .., Ek} 
where N is a natural number indicating the number of simulations to be performed, boundis the time bound on the simulations, and E1, .., Ek are the k (state-based) expressions that are to be monitored and visualized. To demonstrate this on our previous train-gate example, we can monitor when Train(0) and Train(5) are crossing as well as the length of the queue. The query is 
123 
Uppaal SMC tutorial 
value 

Simulations 
6.0 
4.5 


Train[0].Cross 
Train[5].Cross 
1.5 
3.0 
Gate.len 

0 0 50 100 150 200 250 300 time 
Fig. 6 Visualizing the gate length and when Train(0) and Train(5) cross on one random run 
simulate1[<=300] {Train(0).Cross, Train(5).Cross, Gate.len} 
This gives us the plot of Fig. 6. Interestingly, Train(5) crosses more often (since it has a higher arrival rate). Secondly, it seems unlikely that the gate length drops below 3 after some time (say 20), which is not an obvious property from the model. We can confirm this by asking Pr[<=300](<> Gate.len < 3 and t > 20) and adding a clock t. The probability is in [0.102, 0.123]. 
For specifying properties over NSTAs, we use a weighted extension of the temporal logic MITL [2] expressing properties over runs [6], defined by the grammar: 
ϕ::=ap |¬ϕ|ϕ1 ∧ϕ2 |Oϕ|ϕ1Ux 
≤d ϕ2 

where ap is a conjunction of predicates over the state of a NSTA, d is a natural number and x is a clock. Here, the logical operators are interpreted as usual, and O is a next state operator. A weighted MITL formula ϕ1U≤ xd ϕ2 is satisfied by arun if ϕ1 is satisfied on the run until ϕ2 is satisfied, and this will happen before the value of the clock x exceeds d. As usual ¬(ϕ1 ∧ϕ2) =¬ϕ1 ∨¬ϕ2 and we use standard MITL abbreviations tt = ϕ ∨¬ϕ, ♦x≤d ϕ = ttU≤ xd ϕ and x≤d ϕ =¬♦x≤d ¬ϕ. 
For an NSTA M, we define PM (ϕ) to be the probability that a random run of M satisfies ϕ. The problem of checking PM (ϕ) ≥ p (p ∈[0, 1]) is undecidable in general.1 For the sub-logic of cost-bounded reachability problems PM (♦x≤C ap) ≥p, where x is a clock and C is a bound, Uppaal SMC approximates the answer using simulation-based algorithms known under the name of statistical model checking [41] algorithms (SMC). We briefly recap statistical algorithms permitting to answer the following three types of questions: 
1. Probability estimation What is the probability PM (♦x≤C ap) for a given NSTA M? 
1 Exceptions being stochastic TAs with 0 or 1 clocks and with p being 0or1. 
1 
P 
0 
Fig. 7 True probability P and confidence intervals 
2. 
Hypothesis testing Is the probability PM (♦x≤C ap) for a given NSTA M greater or equal to a certain threshold p ∈[0, 1]? 

3. 
Probability comparison Is the probability PM (♦x≤C ap1) greater than the probability PM (♦y≤Dap2)? 


From a conceptual point of view solving the above questions using SMC is simple. First, each run of the system is encoded as a Bernoulli random variable that is true if the run satisfies the property and false otherwise. Then a statistical algorithm groups the observations to answer the three questions. For the quantitative question (1), we will use an estimation algorithm that resemble the classical Monte Carlo simulation, while for the qualitative questions (2 and 3) we shall use sequential hypothesis testing. The two solutions are detailed hereafter. 
Probability estimation The probability estimation algorithm [30] computes the number of runs needed to produce an approximation interval [p −ε, p +ε]for p = Pr(ψ) with a confidence 1 −α. A frequentist interpretation of this result tells us that if we repeat the interval estimation N times, then the estimated confidence interval p ±ε contains the true probability at least (1−α)N times in the long run (N →∞). Figure 7 shows the relation between the estimated probability confidence intervals and the true (unknown) probability P. 
The original algorithm for interval estimation decides the number of runs apriori based on the values of ε and α using Chernoff–Hoeffding inequality [18,31], however for practical purposes this inequality is too conservative. Moreover, the result can be even more improved when the probability is further from 12. Uppaal SMC implements a sequential method where a probability confidence interval (for given α) is derived with each new simulation measurement and the simulation generation is stopped when the confidence interval width is less than 2ε. The confidence interval is derived using Clopper–Pearson “exact” method [19] using the fact that the measurements are always binary (the property is either satisfied or not) and thus the result follows binomial distribution. The confidence level is also adjusted for one-

123 
A. David et al. 


Fig. 8 The Verifier of Uppaal SMC 
sided intervals, where the measured property is always true or always false. 
In Uppaal SMC, the probability confidence interval can be estimated by the following query: 
Pr[bound] (ap) 

Example 1 Recall the Train Crossing example of the previous section. The following queries estimates the probabilities that Train(0) and Train(5) will be in the crossing before 100 time units: 
Pr[<= 100](<> Train(0).Cross) Pr[<= 100](<> Train(5).Cross) (1) 
Figure 8 shows how these (and other) queries are entered in the “Query” field of the Verifier tab of Uppaal SMC. In the “Overview” field the answers are provided: [0.502421, 0.602316] and [0.902606, 1] are the two 95 % confidence intervals obtained from 383 and 36 runs, respectively. This shows—as we would expect—that the more eager Train(5) has a higher probability of reaching the crossing than Train(0) within the given time limit. Right clicking on the answers provide easy access to more detailed information in terms of (cumulative, confidence interval, frequency histogram) probability distribution of the time-bounded reachability property, e.g., Fig. 9. 
Hypothesis testing This approach reduces the qualitative question to e test the null-hypothesis: 
H: p = PM (ψ) ≥ θ 

against the alternative hypothesis: 
K :p = PM (ψ) < θ 

To bound the probability of making errors, we use strength parameters α and β and we test the hypothesis H0: p ≥ p0 

Fig. 9 The cumulative probability distribution of 
Pr[<=T ](<> Train(5).Cross) 
and H1: p ≤ p1 with p0 = θ + δ0 and p1 = θ − δ1.The interval p0 − p1 defines an indifference region, and p0 and p1 are used as thresholds in the algorithm. The parameter α is the probability of accepting H0 when H1 holds (false positives) and the parameter β is the probability of accepting H1 when H0 holds (false negatives). The above test can be solved by using Wald’s sequential hypothesis testing [40]. This test computes a proportion r among those runs that satisfy the property. With probability 1, the value of the proportion will eventually cross log(β/(1 − α) or log((1 − β)/α) and one of the two hypothesis will be selected. In Uppaal SMC, we use the following query: 
Pr[bound] (ψ) >= p0 
where bound defines how to bound the runs. The three ways to bound them are (1) implicitly by time by specifying <=M (where M is a positive integer), (2) explicitly by cost with x<=M where x is a specific clock, or (3) by number of discrete steps with # <=M. In the case of hypothesis testing p0 is the probability to test for. The formula ψ is either <>q or []q where q is a state predicate. 
Remark 1 Bounding runs for a number of discrete steps guarantees termination of the simulation. Bounding over time may however result in non-termination if the model is not time diverging. Similarly, bounding over a non-diverging clock can result in non-termination. 
Uppaal SMC cannot detect if a clock (or time) is diverging in a model thus the modeler needs to ensure this. 
Example 2 Returning to the Train Crossing example, we may not be directly interested in the actual probability of Train(0) crossing within 100 time units, but merely whether this unknown probability is above 0.2, as reflected by the following query (see also Fig. 8): 
Pr[<= 100](<> Train(0).Cross)>= 0.2 
Within a number of runs significantly smaller than that of estimating the same probability (383 runs), this property may be 
123 
Uppaal SMC tutorial 

confirmed. The number of runs needed by Wald’s sequential hypothesis testing method varies, e.g., posing the above query 5 times, the property was confirming within 66, 62, 65, 67, and 49 runs, respectively, with 5 % level of significance. 
Probability comparison This algorithm, which is detailed in [23], exploits an extended Wald testing. In Uppaal SMC, we use the following query: 
Pr[bound1](ϕ1)>= Pr[bound2](ϕ2). 
Example 3 In the train-gate example, it might be sufficient to confirm that the probability that Train(5) reaches the crossing within 100 time units is larger than that of Train(0). Posing the query: 
Pr[<= 100](<> Train(5).Cross) >= Pr[<= 100](<> Train(0).Cross) 
confirms this belief within 120 (132, 144, 108, 174) runs with 5 % level of significance. 
In addition to those three classical tests, Uppaal SMC also supports the evaluation of expected values of min or max of an expression that evaluates to a clock or an integer value. The syntax is as follows: 
E[bound; N ](min:expr) 
or 

E[bound; N](max:expr) 
where bound is as explained in this section, N gives the number of runs explicitly, and expr is the expression to evaluate. Also for these properties a confidence interval is given using the fact that measurements follow Student’s t-distribution (approaching Normal distribution when N →∞). 
Example 4 As an interesting property of the Train Crossing example, we want to know the average of the maximum number of trains that are stopped within the first 20 time units: 
E[ <=20; 20000] (max: sum(i : id_t) Train(i) .Stop) 
Using the explicitly required 20.000 runs, this average is estimated to be in the confidence interval 3.64775 ± 0.0126354. Right clicking gives easy access to more detailed views, e.g., the frequency histogram in Fig. 10. 
Full weighted MITL Regarding the implementation, we note that both the above statistical algorithms are trivially implementable. To support the full logic of weighted MITL is slightly more complex as our simulation engine needs to rely on monitors for such logic. In [7], we proposed an extension of Uppaal SMC that can handle arbitrary formulas of weighted MITL. Given a property ϕ, our implementation first constructs deterministic under-and over-approximation monitoring PTAs for ϕ. Then, it puts these monitors in parallel with a given model M, and applies SMC-based algorithms to bound the probability that ϕ is satisfied on M.More recently [6], the exact evaluation of whether the generated run satisfies a given weighted MITL formula is done online by constantly rewriting the formula during generation of the run. 

The probability of satisfying an MITL property ψ is estimated by Uppaal SMC using the query Prψ, where 
ψ:: = BExpr 
|(ψ && ψ)| (ψ || ψ) 
|(ψ U[a, b] ψ)| (ψ R[a, b] ψ) 
|(<>[a, b] ψ)| ([][a, b] ψ) 
a, b ∈ N, a ≤ b and BExpr is a Boolean expression over clocks, variables and locations. 
Example 5 The following query: 
Pr( <>[10,100] ([ ][0,5] Train(0) .Stop) ) 
asks for the probability that Train(0) will stopped for at least 5 consecutive time units somewhere in the time interval [10, 100]. Within 738 runs [0.880894, 0.980894] is returned as a 95 % confidence interval indicating that this happens with a very high probability. 
4 Extension to hybrid systems 
Uppaal SMC allows for statistical model checking of stochastic hybrid systems, i.e., extensions of (stochastic) timed automata, where the rate of clocks may be given by general expressions involving clocks, thus effectively using ODEs. 
To illustrate the various aspects of the (extended) modeling formalism supported by Uppaal SMC, we consider the case of two independent rooms that can be heated by a single heater shared by the two rooms, i.e., at most one room can be heated at a time. Figure 11a shows the automaton for the heater. It turns itself on with a uniform distribution over time 
123 
A. David et al. 

(a) (b) 

(c) 









Fig. 12 Evolution of the temperatures of the two rooms (color figure online) 
in-between [0, 4]time units. With probability 1/4 room 0 is chosen and with probability 3/4 room 1. The heater stays on for some time given by an exponential distribution (rate 2 for room 0, rate 1 for the room 1). In summary, one may say that the controller is more eager to initiate the heating of room 1 than room 0, as well as less eager to stop heating room 1. The rooms are similar and are modeled by the same template instantiated twice as shown in Fig. 11b, c. The room is initialized to its initial temperature and then depending on whether the heater is turned on or not, the evolution of the temperature is given by Ti =−Ti /10 + 0,1 Ai, j (Tj −Ti ) or
j= Ti = K −Ti /10 + 0,1 Ai, j (Tj −Ti ) where i, j =0, 1
j= 

are room identifiers. The sum expression corresponds to an energy flow between rooms and matrix A encodes the energy transfer coefficient between adjacent rooms. Furthermore, when the heater is turned on, its heating is not exact and is picked with a uniform distribution of K ∈[9, 12], realized by the update K=9+random(3). 
This example illustrates the support for stochastic hybrid systems in Uppaal SMC with extended arithmetic on clocks and generalized clock rates. 
Uppaal SMC takes as input networks of stochastic hybrid automata as described above. In addition, the automata support branching edges where weights can be added to give a distribution on discrete transitions. It is important to note that rates and weights may be general expressions that depend on the states and not just simple constants. 
Remark 2 The ODE solver implemented within Uppaal SMC is fixed time step Euler’s integration method thus the results may be sensitive to the discretization step size. 
Euler’s method is known to be unstable for stiffs systems thus care must taken when deciding on the discretization step size controlled in the settings of statistical parameters. 
4.1 Floating-point support 
The syntax has been extended to support a double precision floating-point type (double). This type can be used mixed with clocks for computing or storing arithmetic expressions. Its rate cannot be changed. When using floating-point types or operations in a model, the model is marked as being hybrid. For such models, model checking is disabled, unless the clocks are declared to be hybrid clock and these clocks nor the floating-point variables affect the control of the automata, i.e., such variables are inactive and used as costs. 
4.2 Example 
All the new queries of Uppaal SMC described in Sect. 3 are available for stochastic hybrid systems. We illustrate this by a number of queries related to the two-room example from the previous section. 
We can simulate and plot the temperatures of the two rooms with the query 
simulate 1 [<=600]{T[0], T[1]} 
The query request the checker to provide one simulate run over 600 time units and plot the temperatures of Room(0) and Room(1). The heater in this example is purely stochastic and is not intended to enforce any particular property. Yet, the simulation obtained from this query in Fig. 12 shows that the heater is able to maintain the temperatures within (mostly) distinct intervals. 
We can evaluate on a shorter time scale the probability for the temperature of Room(0) to stay below 30 and the temperature of Room(1) to stay above 5 with the queries 
Pr[<=100] ([ ] Room(0).Init || T[0] <= 20) Pr[<=100] ([ ] Room(1).Init || T[1] >=7) 
The results are, respectively, in [0.45, 0.55] and [0.65, 0.75]. The precision and confidence of confidence intervals are user-defined (see later) and influence the number of runs 
123 
Uppaal SMC tutorial 

needed to compute the probability. In this example, for having the precision to be ±0.05 and a confidence of 95 %, we needed 738 runs. In fact, if we are only interested in knowing if the second probability is above a threshold it may be more efficient to test the hypothesis 
Pr[<=100] ([ ] Room(1).Init || T[1] >=7) >= 0.69 
which is accepted in our case with 902 runs for a level of significance of 95 %. To obtain an answer at comparable level of precision with probability evaluation, we would need to use a precision of ±0.005, which would require 73778 runs instead. 
We can test the hypothesis that the heater is better at keeping the temperature of Room(1) above 8 than keeping the temperature of Room(0) below 20 by the following comparison query: 
Pr[<=100] ([ ] Room(1).Init || T[1] >=7) >= Pr[<=100] ([ ] Room(0).Init || T[0] <= 20) 
which is accepted in this case with 95 % level of significance with just 258 runs. 
Remark 3 As it can be observed, the MITL specifications allowed in Uppaal SMC are bounded properties. That is specifications only depend on a run up to a given time-bound, step-bound or bound on some other quantity defined in the model. Thus, specifications only express properties of transient behavior of systems, and may or may not be indicative of safety of a deployed system in steady operational state, depending on how long the system takes to settle. However, given knowledge of the size of the model, estimation of probability of unbounded properties may be obtained from the observation of finite runs as shown in [39]. 
5 Extension to dynamic creation of processes 
An underlying assumption of networks of timed automata is that computer systems are statically encoded. This is however not reality. Instead, systems are composed of a number of threads/processes that interact and capable of spawning other processes/threads. Modeling such dynamic systems in standard Uppaal requires the modeler to model an underlying resource manager. In addition, the model would consist of a large number of components in an inactive state available for the resource manager to “start” whenever a spawn request was made in the model. A necessary assumption for modeling this resource manager is thus that the maximum number of spawned threads during any execution is known in advance (or can be safely over-approximated). This does not only make modeling tedious but also affects analysis time. Uppaal SMC supports instantiating dynamic processes out 
(a) (b) 


(c) 




Fig. 14 Plot of the number of waiting clients and total number of clients. The plot was obtained with the query simulate 1[<= 100]{numOf(Client), sum (c : Client)(c.Wait)} (color figure online) 
of the box. Any automata in the system can spawn instances of templates of the model that has been declared to be spawn-able. Dynamically created instances act within the system as the static instances with the exception that they at any time may terminate, and thus remove themselves from the system. 
In Fig. 13 is a high-level model of a client–server architecture. The model consists of a number of servers (10), shown in Fig. 13a, that listens on all possible input channels req. When a request arrives all the servers will “race” to acknowledge the connection over the channel ack[c]. The winner will proceed to communicate with the client (we abstract from this part), while the others return to their listening state. When a client has finished communication with the server it will terminate the connection by synchronizing on term[c]. Afterwards, the server returns to its listening state. 
In Fig. 13b, we show the client side of the model. A client is given an id when spawned which tells it what channel to connect on (req[id]). A client is first attempting to get a connection, then it awaits an acknowledgment from a server and then do some work taking less than ten time units. Finally, 
123 
A. David et al. 


it disconnects from the server by synchronizing on term[id] and at the same time tears itself down using the exit() construction. 
Clients are spawned by the template in Fig. 13cusing the spawn Client(next++) update. This instantiates a client and passes the value of next as a parameter to the client which binds that value to its own local variable id. 
Remark 4 We realize that the template in Fig. 13c may create an unbounded number of clients, whereas the number of communication channels are bounded. For our particular use this is not a problem as we know the number of spawned clients will not exceed the number of communication channels within the time limit we work with in our queries. 
5.1 Syntax in Uppaal SMC 
A template that will be dynamically spawned must be declared as a dynamic template. This is done in the global declaration of the Uppaal model using the dynamic keyword. The declaration for the Client template would for instance be dynamic Client (int id). The template takes one parameter id. Parameters to spawnable templates are restricted to be pass-by-value parameters or a reference to a broadcast channel. The reasoning behind this restriction is that templates may cease to exist—invalidating any references to its local variables that it could have passed on to spawned templates. 
The actual behavior of a spawnable template is defined as usual in the editor. Note, however, that there must be a correspondence between the parameters defined in the dynamic declaration and the definition. In the Client example this means that the parameters both in the dynamic declaration and the definition must be int id. 
Spawnable templates may be spawned by any template during a transition using the spawn keyword. For instance, adding spawn Client (2) to the update expression of an edge will spawn an instance of the template Client with parameter 
2. Obviously, there must be parameter compatibility between the actual and the formal parameters. 
A spawnable template can tear itself down during a transition. This is expressed by adding the exit() expression to the update of an edge. 
5.2 Extensions for queries 
Having extended the modeling language of Uppaal SMC to allow dynamically spawning templates, we also need an extended specification formalism. 
For the statically defined components specifications are made as described in Sect. 3. For the dynamically created components of the system three additional constructions are available: forall (i : T)(q), exists (i : T)(q)and sum (i : T)(a), 
that may be used anywhere in a specification. 
The predicate forall(i:T) (q) asserts that q is true for all the dynamically created instances of T. The name i may be used anywhere in q to refer to the variables of the instances of T, i.e., the name i is temporally bound to the instances of T while evaluating q. The construct exists (i:T) (q) is the dual of forall. 
Example 6 Returning to the server example from before, we may consider the probability that a client is not served for 5 time units, i.e., that it is working in the Wait location for 5 time units. In the extended specification formalism this can be checked using the query: 
Pr(<>[0,20] (exists (c : Client) (([ ][0,5]c.Wait)))) 
The expression sum (i : T)(a) can be used in arithmetic expressions and simply evaluates a for all the instances of T. In the Server example, we can for instance count the number of clients that are waiting for a connection with the expression sum (c : Client)(c.Wait). The sum construction can also be used to count the number of active clients sum (c : Client)(1). An optimized version of this is available as numOf(Client).InFig. 14, we show one simulation, 100 time units long, where we observe these two expressions. 
The sum operator is useful for computing aggregate data about all components of a given type but cannot give the exact value of each component. For instance, sum cannot be used to plot the location of each client. If this is wanted Uppaal SMC supports the query: 
simulate1[<=100] {foreach (c : Client) (3*C.id+c.Wait+2*c.Work)} 
The foreach statement is here used to tell the plotting facility of Uppaal SMC to plot the expression 
123 
Uppaal SMC tutorial 


(3*c.id+c.Wait+2*c.Work) for each of the dynamically instances of Client. The actual expression is just a smart way to obtain a “Gantt-like” chart of each client. The result of the query is shown in Fig. 15 where each colored line correspond to a client. 
6 Graphical interface 
We focus in this section on the main features of the interface related to SMC. For a more complete overview of the interface the reader is referred to [4]. Overview The graphical interface of Uppaal is divided into an editor, two simulators, and a verifier. The editor serves the purpose to define the automata and declaration of variables and functions. The verifier is used to specify and check different queries, and to get the results. Then there are two simulators, one is the well-known symbolic simulator that has been available in Uppaal since the birth of this interface. The second simulator is a concrete simulator that was originally used in Uppaal-tiga. This simulator allows the user to simulate a system with concrete values of clocks, which is more intuitive than with the symbolic simulator. This simulator is shown in Fig. 16. The choice of transition is situated in the upper-left corner. The user chooses with one click a transition (vertical choice) and a delay (horizontal choice). The simulator shows the automata and a message sequence chart on the right. On the lower left corner is the trace corresponding to the current simulation. The central view shows the variables and the user can show and hide variables in different scopes. In the example, only the clocks of Train(2) and Train(4) are shown. 
The concrete simulator also supports Gantt chart visualization of the interactive concrete trace. Figure 17 shows a sample use case of Gantt chart for the train-gate example. The chart is defined in system declarations (Fig. 17a), where each chart line is defined by a statement separated by a semicolon. Each statement consists of a line label (e.g., gate and train) and a comma-separated list of predicates implying color numbers. For example, a line gate is painted in color #0 (red) whenever Gate.Occ is true and in color #1 (green) whenever Gate.Free. The colors are mixed when the corresponding predicates are true at the same time. It is also possible to define a chart line for a whole range of discrete values at once, like the parameterized definition of train(i:id_t), where the temporary variable i has a range of type id_t.For example, the first 32 colors can be rendered by the following definition: gantt { C(i:int[0,31]): true -> i; }. 
123 
A. David et al. 
(a) 


(b) 


SMC options Under the menu Options the user can choose Statistical parameters. This opens the window shown in Fig. 18. 
– 
−δ and +δ: When testing for hypothesis of the form Pr(ϕ) ≥ θ , the algorithm behind tests for two hypothesis. They are 1) H0 : Pr(ϕ) ≥ θ + δ+ and 2) H1 : Pr(ϕ) ≤ θ − δ−. These parameters define the region of indifference. 

– 
α and β: α and β are used for hypothesis testing. The probability of accepting H1 instead of H0 is α and conversely for β. In the case of probability evaluation, α is also used and it is then the probability to be outside the result interval of probability. For probability comparison, the use of α and β is the same as for hypothesis testing. 

– 
ε is the uncertainty for probability evaluations. The tool evaluate some probability μ and outputs the result [μ − ε, μ + ε]. 

– 
u0 and u1 are the lower and upper bounds used in probability comparison. Similarly to hypothesis testing, the 


Pr(ϕ1)

algorithm tests two hypotheses: H0 :≥ u1 and
Pr(ϕ2) 
Pr(ϕ1)

H1 :≤ u0. These parameters define the region of 
Pr(ϕ2) 

indifference for comparing probabilities. 
– Histogram parameters: If the bucket width is set to a positive value, its value determines the width of the bars in the histogram and the number of bars depends on the range of the obtained results. Otherwise if the bucket count is positive then the number of bars is set to this value and the width of the bars depends on the range of the obtained result. Otherwise if both parameters are set to zero (default), the number of bars in the histogram is set to the square root of the number of runs used to obtain the graph. 


– 
Trace resolution: When computing a simulation using the simulate query, the tool filters out the data on-the-fly and retains points that are distinguishable w.r.t. a certain resolution when plotted on a screen. This parameter controls the maximum width of the plot in pixels. 

– 
Discretization step: This is used for integration when ODEs are used in the model. We note that defining rates as constants does not qualify as ODE, but having x’==y does. 


Plotting and composing Most of SMC queries also provide quick result visualization in a form of data plots accessible in the Verifier by right clicking on a selected property and choosing one of the available plots from a pop-up menu. Simulation queries display all the requested trajectories in one plot with different colors assigned to various expressions. Statistical queries result in a number of different histograms showing the data scattered along time, cost or discrete transitions horizontal axis. The displayed plot elements (like title, legend, transparency, comments and logarithmic scale) can be customized by right clicking on the plot and choosing appropriate items from a pop-up menu. The plotted data can be exported as either a picture or a text file using the same plot pop-up menu. The size of the exported plot can be customized by resizing the plot window. Note that larger window will result in smaller fonts when rescaled for inclusion into a document, so smaller window will result in fewer details but clearer picture with larger fonts. The dark-colored areas are printer-friendlier when the plot is brightened by choosing Areas/Bright in the plot pop-up menu. 
123 
Uppaal SMC tutorial 

Different data can also be contrasted and compared in one plot using the Plot Composer from the Tools menu. Figure 19 shows a sample Plot Composer window with data from several verifications already loaded. The bottom panel on the right shows the resulting plot and the data is organized in the tree on the left. Each verification data is appended to the tree to its corresponding query. For example, simulate query has been checked four times and each result contains one plot with two datasets. The data can be added to the composite plot by ticking its checkbox and its drawing properties can be customized in the top-right panel when it is selected in the tree. For example E2 and E4 are ticked in Fig. 19 and E2 is selected and drawing properties can be changed. The main plot attributes like the title and the labels of both axis can be changed by selecting the root node and changing its properties in the upper panel on the right. It is also possible to edit several composite plots at the same time by invoking Plot Composer several times from the Tools menu. 
7 Modeling tricks 

7.1 How to convert channel synchronizations into broadcast synchronizations 
Problem It is common that a user wants to analyze performance of a given model previously model checked with Uppaal. This model may contain ordinary channel synchronizations that work by hand shake. The problem is that the SMC extension does not support them as explained in Sect. 2. Here, we present a translation to convert these models so that they can be analyzed by Uppaal SMC. Translation We distinguish three cases: the basic simple oneto-one synchronization, the one-to-any synchronization, and a problematic case. 
The common simple case is of one process synchronizing with exactly one other process on a channel as shown in Fig. 20. The sender in state A may have an invariant or not. The receiver in state Loc2 does not have an invariant. The synchronization may be guarded by, resp. g1() and g2(),for resp. the sender and the receiver. To convert this model, the user should redeclare the channel a as broadcast, move the guard of the receiver to the sender,2 and make the actual location visible from the sender using a simple encoding with the extra integer variable recvLoc. Other encodings may be used, e.g., with booleans, but the integer presents the advantage to keep the translation of several synchronizations simple. The integer allows the user to map each location to a unique value that is used by the sender to allow the synchronization only in the right state. The example illustrates the update of this 
2 This may require moving local variables to the global scope to make the state visible. 

⇓ 


variable for some other peripheral locations Loc0, Loc1, and Loc4. 
The second more general case is of one process synchronizing with one process out of several ones. There is a choice of one-to-any synchronization shown in Fig. 21. Here as well, the receiver is in a location without invariants. In this case, the same principle as the simple case is used with in addition a renaming of the channel. The initial transition in the sender has a copy with a unique channel name for each possible synchronization that is possible in the original model. Each copy uses the right associated guard and looks up the state of the right process. In the example, we illustrate with the use of an array a generic encoding where there would be several instances of the same template for the receiver. If the guards g2() and g3() are generic or depend on some id used to instantiate the receivers, the select construct can be used, in which case the original transition is not copied and the channel a is renamed as a[id] with an array. 
The last case is the problematic one where a receiver has an invariant as shown in Fig. 22. Any translation of this model will violate the independent progress condition because here a receiver would force another sender process to synchronize. Not synchronizing would result in a deadlock. We note that if there is an output from that location, i.e., some b! synchronization, then there is no problem. 
The last technical detail to take care of is to add exponential rates to the locations without invariants and that have output synchronizations (or tau transitions). This is the rate of the exponential distribution used for picking delays. 
123 
A. David et al. 


⇓ 




Fig. 22 Problematic case where the translation to broadcast channel is not possible 



7.2 How to encode custom distributions 
tributions available in Uppaal SMC are not enough. The user needs a simple way to encode any distribution into the model to generalize the ones illustrated in Fig. 2. 
Encoding The pattern for encoding general distributions is given in Fig. 23. The principle is that upon entry of a given location Wait where the actual custom delay is to take place, the actual delay is computed and stored into a clock delay. The function f() that computes this delay returns a floating-point value of type double. The automaton will then delay for this amount and take the transition. The location Wait has its invariant set to x <= delay and delay’==0. The clock delay is used here only for storage. This technique is similar to the one used for computing stochastic simulations in Modest [27]. 
Implementation of f() The function that computes the delay may use the random(n) function with n being a floating-point value. The function returns a number in [0, n[ with a uni-
Fig. 23 Result from modeling a Gaussian distribution 

Fig. 24 Pattern for custom delay distributions 
form distribution. This can then be transformed to return a delay with another distribution. We note that the function may keep a state as well, by storing what it wants into global variables (also of type double), which allows the encoding of virtually any distribution. For example, to generate random numbers according to a normal distribution using the Box-Müller method, we can use the following function: 
The distribution obtained is shown in Fig. 24 together with the parameters used. 
Remark The reader may wonder why the pattern proposes to use a clock for the variable delay instead of a variable of type double. In fact, it is possible to use double, which saves the trouble of setting its rate to 0. However, the performance of the model checker may drop. In its current implementation, Uppaal SMC uses a fined-grained discretization if guards or invariants contain a “general” floating-point expression. The syntax analyzer will not recognize that the discretization is not needed in this case. Using clocks alleviates the problem. 
7.3 How to model physics 
Problem The formalism of Uppaal SMC is stochastic hybrid automata so modeling physics is a simple matter of writing 
123 
Uppaal SMC tutorial 

the ODEs in the model. However, only first-degree derivatives are allowed. 
Modeling To model an n-degree derivative, the user should use a clock variable for every intermediate derivative. This is standard renaming technique used in other tools, e.g., Matlab. For example, instead of modeling y’’==-9.81 for a falling object, the user should declare y’==v and v’==-9.81. Using different clocks or arithmetic expressions mixing double typed variables is also supported. 
7.4 How to model biochemistry 
Problem Cyber-physical systems may involve chemical and even biological processes and hence there is a need to evaluate the performance of control systems in such a context. Suppose the reaction involves a mixed solution of materials A and B and produce C and D with reaction speed of γ : 
γ

A + 2B −→ C + 3D 
Here, we show how this reaction can be modeled as either probabilistic or dynamical system. The containment of reactions and other interactions can be modeled by adding additional locations, edges and channel synchronizations. 
Stochastic model Figure 25 shows a stochastic model of the reaction and its behavior. The discrete quantities (molecules) of the materials involved are counted by the corresponding integers A, B, C and D. The reaction rate is represented by the double precision floating-point variable gamma.The automaton in Fig. 25b captures the interaction between chemicals A and B in the following way: 
– 
The automaton takes a discrete transition when the reaction happens. 

– 
The reaction requires at least one molecule of A and at least two molecules of B, hence the edge is guarded by an expression A > 0&&B > 1. 

– 
Each reaction consumes A and 2B and produces C and 3D, hence the edge has the update A--, B-=2, C++, D+=3. 

– 
In a well-mixed (homogeneous) compound the probability of a reaction is proportional to its speed γ and the probability of meeting the required three molecules (A, B and another B) in one place. The probability of reaction remains the same as long as the conditions (quantities and temperature) do not change, hence the reaction is a Poisson process and the delay until the next reaction follows an exponential distribution with the rate gamma∗ A∗ B∗ B. 


If there are more reactions, then they have to be modeled by another parallel process. The trajectory of the quantities can be inspected by the following query: simulate 1[ <= 5]{ A, B, C, D} . The resulting plot is shown 

(a) 

(b) (c) 
Fig. 25 Stochastic model and its behavior, a declarations, b automaton, c simulation (color figure online) 
(a) 

(c) 

in Fig. 25c: A and B are slowly decaying, replaced by C and D. We notice that the trajectory is jittery and can be slightly different with every new simulation due to probabilistic nature of the stochastic process and relatively small amounts of molecules. The trajectories are smoother when quantities are much larger and approach the limit of the continuous dynamics. Scaling Usually, chemical reactions involve huge numbers of molecules with different orders of magnitude and thus some scaling of dimensions may be desired. Note that if the quantities are scaled by 1,000, then the exponential rate gamma∗ A∗ B∗ B has to be scaled by 106 (while the dynamical coefficients are scaled by 109) and thus it is very easy to overflow the default range of int. Figure 26 shows the same model but with molecule quantities scaled by 1,000. The simulated trajectories are divided by s back down to a comparable scale as in previous and next example. The simulated behavior is smoother and closer to the dynamical model (shown next). 
123 
A. David et al. 

The default integer range is rather small (±216), thus one may need to broaden it by defining a custom range. Uppaal supports integer ranges up to 32 bits, hence the type declaration typedef int[−(1 << 31), (1 << 31) −1]int32_t;corresponds to a range of signed 32 bit integer. The range can be expanded further to a double precision floating point, but note that its precision is limited to 52 bits (≈4.5×1012) and hence beyond that point minor increments (like +1) will not affect the variable value anymore. Dynamical model The same reaction can be rewritten using a set of differential equations describing the rate of change of the quantities: 
⎧ d[A] =−γ ·[A]·[B]2 

dt ⎪ d[B]

⎨ =−γ ·[A]·[B]2 ·2 
dt d[C] 

= γ ·[A]·[B]2 
dt ⎪ d[D]

⎩ = γ ·[A]·[B]2 ·3 
dt The idea here is that the rate of change in quantities is proportional to the speed of reaction and concentration of materials. The contribution to various materials is then scaled by coefficients from the original reaction. We have one equation per each material mentioned. If there are more reactions then their contributions can be added up to the same system of differential equations either as separate extra terms or a separate equation for each new chemical. Figure 27 shows the dynamical model and its behavior. The quantities are captured by dynamical clock variables A, B, C and D and the same reaction coefficient gamma. The differential equations are then typeset as a single invariant of derivative expressions in Lagrange’s prime notation (Fig. 27b). We also added an escape transition if/when the quantity of A reaches zero, i.e., the reaction stops. The trajectories can be inspected by the same simulation query as previously and the result is shown in Fig. 27c. Notice that the trajectory is smoother, very close to the scaled-up stochastic simulation, and is the same every time (deterministic), because ordinary differential equations have one fixed solution for the same initial conditions. Some ODE systems might require tuning the discrete integration step in the Statistical parameters from the Options menu: the smaller the step the more precise simulation is, but it is also computationally more expensive. Stiff systems may require smaller integration steps. A more complicated biochemical model can be found in a study of a circadian rhythm genetic oscillator [20,24]. 
7.5 How to obtain distributions over costs 
When the user checks queries to evaluate probabilities, e.g., Pr[<=100](<> Proc.Goal), Uppaal SMC keeps track of 
(a) (c) 


(a) (b) 

(c) 

Fig. 28 Cost estimation in terms of energy, a model, b trajectories of energy and power, c estimated energy probability distribution (color figure online) 
when the runs satisfy the specified goal state and uses this information to build a frequency histogram. Specifically, what is counted is the number of runs that were satisfied at a given “time” as defined by the bound of the run. When no explicit variable is used, e.g., <=100, the plot is the count of satisfied runs as a function of time, discretized in the histogram bars (so in fact in function of time intervals). When a clock variable is used, the plot is in function of this variable. Alternatively, the runs can be bound by number of discrete steps of the form # <=100. 
Now suppose that we want to estimate a cost expressed as some energy consumption. To illustrate this, let us consider the example in Fig. 28a. In this model, a random power level is chosen stochastically and the corresponding energy consumption is integrated by Uppaal SMC. The evolution of the energy is naturally expressed by the equation E’==P. 
123 
Uppaal SMC tutorial 

Figure 28b shows one stochastic simulation bounded by two time units obtained with the query simulate 1[<= 2]{E, P}. Every run will have its own energy consumption. The question is to know the mean of the energy consumption and its distribution over runs bounded by two time units. To obtain this we check the query Pr[E <= 10](<> t == 2). The trick is that first we bound the actual energy by a high enough bound that covers the reachable range for all runs. It could be E <= 1000 if the user is unsure. Second, the goal state is the time bound that will be reached since time progresses.3 The result probability is one but this is not the point. The point is the distribution generated by this query. Uppaal SMC will record “when” (in function of the bound) the runs reach the goal, here t==2. We obtain now a distribution of energy consumption on runs bounded by two time units as shown in Fig. 28c. 
Remarks If the suggested query is checked with the default settings the obtained histogram will have poor precision because Uppaal SMC does not need many runs to conclude that the result probability is one. The user should increase the precision by changing the SMC options as described in Sect. 6. Specifically, Fig. 28c was obtained from 7598 runs using α = 0.001 and ε = 0.0005. 
It is also possible to estimate discrete costs even though the tool does not support integers as bounds. Users can use clocks for this purpose by maintaining their rates to zero and updating them manually. For example, if c is a counter, then it is declared as a clock. Then the user adds one process with one location and no transition with the invariant c’==0. Finally, the increment c=c+1 is used wherever necessary and the bound c <= 100 can now be used. 
7.6 How to model custom discretizations 
Problem Sometimes users want to use a custom integration method or want to change the integration granularity at the level of locations. Uppaal SMC uses a global time step when it detects that some integration is needed. It may be better for performance or precision to change this step depending on the locations and the type of equation to integrate. 
Modeling The modeling trick consists of using a “high” exponential rate on the locations where the manual discretization is needed. The tool will then take small delay steps, albeit random according to an exponential distribution with high rate, which allows for custom discretization. Figure 29 shows an example of the temperature of a room that can have a heater turned on or off.4 The value of RATE controls the precision. The functions for cooling and heating are depicted in Listing 
3 

Uppaal SMC detects Zeno runs and rejects models producing them. 4 The actual controller is not important for this example and is not given here. 

(a) 

(b) (c) 
Fig. 29 The temperature of a heated room with a manual discretization using a high exponential rate RATE, a variable and function declarations, b the model, c temperature trajectories 
29a. The value of the clock dt is the time elapsed and is used for the integration. KHEAT and KCOOL are constants used in the model. The result of a simulation is shown in Fig. 29. This manual encoding replaces, resp., T’==-T/KCOOL and T’==KHEAT-T/KCOOL for, resp., cooling and heating. The example also illustrates a recent new feature of the language, namely initializers for clocks with the declaration T = T0[i], where T0 is declared as const double T0={70.0,60.0}. 
8 Conclusion 
This paper presented Uppaal SMC as an efficient tool for evaluating performance properties of stochastic hybrid systems. The modeling language has been extended to handle dynamical behaviors, discrete probabilities, a stochastic interpretation for timed delays and even dynamic process creation—far beyond analytically tools reach. Most importantly the old Uppaal models require only small changes to benefit also from Uppaal SMC features, thus it is straightforward to gain also performance measures in addition to firm results. The paper also includes tricks for handling more problematic corner cases to satisfy Uppaal SMC assumptions and in particular how to transform handshake synchronization to broadcast synchronization. The query language has been expanded to request simulation trajectories, compute probabilistic aspects and evaluate weighted MITL formulas. 
In the future, we intend to include better ODE solvers to improve dynamical simulations and improve the interactive concrete run simulator including a Gantt chart visualization of a run. 
123 
A. David et al. 

Acknowledgments The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007–2013) under grant agreements No. 318490 (SENSATION) and No. 601148 (CASSTING). Also the research has received funding from the Sino-Danish Basic Research Center IDEA4CPS funded by the Danish National Research Foundation and the National Science Foundation China. EU ARTEMIS grant agreement No. 269335 (MBAT). 
References 

1. 
Alur, R., Dill, D.L.: A theory of timed automata. Theor. Comput. Sci. 126(2), 183–235 (1994) 

2. 
Alur, R., Feder, T., Henzinger, T.A.: The benefits of relaxing punctuality. J. ACM 43(1), 116–146 (1996) 

3. 
Boyer, B., Corre, K., Legay, A., Sedwards, S.: Plasma-lab: a flexible, distributable statistical model checking library. In: QEST, pp. 160–164 (2013) 

4. 
Behrmann, G., David, A., Larsen, K.G.: A tutorial on Uppaal. Lecture Notes in Computer Science. pp. 200–236 (2004) 

5. 
Behrmann, G., David, A., Larsen, K.G., Pettersson, P., Yi, W.: Developing uppaal over 15 years. Softw. Pract. Exp. 41(2), 133– 142 (2011) 

6. 
Bulychev, P., David, A., Larsen, K.G., Legay, A., Li, G., Poulsen, D.B.: Rewrite-based statistical model checking of wmtl. In: Runtime Verification, vol. 7687 of LNCS, pp. 260–275 (2012) 

7. 
Bulychev, P., David, A., Larsen, K.G., Legay, A., Li, G., Poulsen, D.B., Stainer, A.: Monitor-based statistical model checking for weighted metric temporal logic. In: Nikolaj, B., Voronkov, A. (eds.) 18th International Conference on Logic for Programming, Artificial Intelligence, and Reasoning, vol. 7180 of LNCS, pp. 168–182. Springer (2012) 

8. 
Bulychev, P.E., David, A., Larsen, K.G., Legay, A., Mikucionis, M., Poulsen, D.B.: Checking and distributing statistical model checking. In: NASA Formal Methods, vol. 7226 of Lecture Notes in Computer Science, pp. 449–463. Springer (2012) 

9. 
Behrmann, G., David, A., Larsen, K.G., Yi, W.: Unification & sharing in timed automata verification. In: SPIN Workshop 03, vol. 2648 of LNCS, pp. 225–229 (2003) 

10. 
Behrmann, G.: Distributed reachability analysis in timed automata. STTT 7(1), 19–30 (2005) 

11. 
Behrmann, G., Fehnker, A., Hune, T., Larsen, K.G., Pettersson, P., Romijn, J.: Efficient guiding towards cost-optimality in uppaal. In: Margaria, T., Yi, W. (eds.) Proceedings of the 7th International Conference on Tools and Algorithms for the construction and analysis of systems, number 2031 in Lecture Notes in Computer Science, pp. 174–188. Springer (2001) 

12. 
Behrmann, G., Fehnker, A., Hune, T., Larsen, K.G., Petters-son, P., Romijn, J., Vaandrager, F.: Minimum-cost reachability for priced timed automata. In: Di Benedetto, M.D., Sangiovanni-Vincentelli, A. (eds.) Proceedings of the 4th International Workshop on Hybris Systems: Computation and Control, number 2034 in Lecture Notes in Computer Sciences, pp. 147–161 Springer-Verlag (2001) 

13. 
Behrmann, G., Hune, T., Vaandrager, F.: Distributed timed model checking: How the search order matters. In: Proceedings of 12th International Conference on Computer Aided Verification, Lecture Notes in Computer Science, Chicago, Springer, Jul (2000) 

14. 
Broy, M., Jonsson, B., Katoen, J-P., Leucker, M., Pretschner, A. (eds.): Model-based testing of reactive systems, advanced lectures the volume is the outcome of a research seminar that was held in Schloss Dagstuhl in January 2004, vol. 3472 of Lecture Notes in Computer Science. Springer (2005) 

15. 
Behrmann, G., Larsen, K.G., Pearson, J., Weise, C., Yi, W.: Efficient timed reachability analysis using clock difference d iagrams. 


In: Proceedings of the 12th Int. Conf. on Computer Aided Verificat ion, vol. 1633 of Lecture Notes in Computer Science. Springer (1999) 
16. 
Clarke, E.M., Faeder, J.R., Langmead, C.J., Harris, L.A., Jha, S.K., Legay, A.: Statistical model checking in biolab: applications to the automated analysis of t-cell receptor signaling pathway. In: CMSB, LNCS, pp. 231–250 (2008) 

17. 
Clarke, E., Grumberg, O., Peled, D.: Model Checking. MIT Press, Cambridge (1999) 

18. 
Chernoff, H.: A measure of asymptotic efficiency for tests of a hypothesis based on the sum of observations. Ann. Math. Stat. 23(4), 493–507 (1952) 

19. 
Clopper, C.J., Pearson, E.S.: The use of confidence or fiducial limits illustrated in the case of the binomial. Biometrika 26(4), 404–413 (1934) 

20. 
David, A., Du, D., Larsen, K.G., Legay, A., Mikucionis, M., Poulsen, D.B., Sedwards, S.: Statistical model checking for stochastic hybrid systems. In: Bartocci, E., Bortolussi, L. (eds.) HSB, vol. 92 of EPTCS, pp. 122–136 (2012) 

21. 
David, A., Du, D., Larsen, K.G., Legay, A., Mikucionis, M.: Optimizing control strategy using statistical model checking. In: NASA formal methods, vol. 7871 of Lecture Notes in Computer Science, pp. 352–367. Springer (2013) 

22. 
David, A., Jensen, P.G., Larsen, K.G., Legay, A., Lime, D., Søresensen, M.G., Taankvist, J.H.: On time with miniam expected cost 

23. 
David, A., Larsen, K.G., Legay, A., Mikucionis, M., Poulsen, D.B., Vliet, J.V., Wang, Z.: Statistical model checking for networks of priced timed automata. In: FORMATS, LNCS, pp. 80–96. Springer (2011) 

24. 
David, A., Larsen, K.G., Legay, A., Mikucionis, M., Poulsen, D.B., Sedwards, S.: Runtime verification of biological systems. In: Margaria, T., Steffen, B. (eds.), ISoLA (1), vol. 7609 of Lecture Notes in Computer Science, pp. 388–404. Springer (2012) 

25. 
David, A., Möller, M.O., Yi, W.: Formal verification of UML statecharts with real-time extensions. In: Kutsche, R.-D., Weber, H. (eds.) Fundamental Approaches to Software Engineering, 5th International Conference, FASE 2002, vol. 2306 of LNCS, pp. 218–232. Springer (2002) 

26. 
Henriques, D., Martins, J.G., Zuliani, P., Platzer, A., Clarke, E.M.: Statistical model checking for markov decision processes. In: Ninth International Conference on Quantitative Evaluation of Systems, QEST 2012, London, United Kingdom, Sept 17–20, 2012, pp. 84– 

93. IEEE Computer Society (2012) 

27. 
Hartmanns, A.: Model-checking and simulation for stochastic timed systems. In: Bernhard, K.A., De Boer, F.S., Marcello M.B. (eds.) FMCO, vol. 6957 of Lecture Notes in Computer Science, pp. 372–391. Springer (2010) 

28. 
Henzinger, T.A., Ho, P.-H.: Algorithmic analysis of nonlinear hybrid systems. In: Wolper, P. (ed.) Computer Aided Verification, 7th International Conference, Liège, Belgium, July, 3–5, 1995, Proceedings, vol. 939 of Lecture Notes in Computer Science, pp. 225– 238. Springer (1995) 

29. 
Hendriks, M., Larsen, K.G.: Exact acceleration of real-time model checking. In: Asarin, E., Maler, O., Yovine, S. (eds.) Electronic Notes in Theoretical Computer Science, vol. 65. Elsevier Science Publishers (2002) 

30. 
Hérault, T., Lassaigne, R., Magniette, F., Peyronnet, S.: Approximate probabilistic model checking. In: Steffen, B., Levi, G. (eds.) Verification, Model Checking, and Abstract Interpretation, vol. 2937 of Lecture Notes in Computer Science, pp. 73–84. Springer, Berlin, Heidelberg (2004) 

31. 
Hoeffding, W.: Probability inequalities for sums of bounded random variables. J. Am. Stat. Assoc. 58(301), 13–30 (1963) 

32. 
Jha, S.K., Clarke, E.M., Langmead, C.J., Legay, A., Platzer, A., Zuliani, P.: A bayesian approach to model checking biological systems. In: CMSB, vol. 5688 of LNCS, pp. 218–234. Springer (2009) 


123 
Uppaal SMC tutorial 

33. 
Jégourel, C., Legay, A., Sedwards, S.: Importance splitting for statistical model checking rare properties. In: CAV, vol. 8044 of Lecture Notes in Computer Science, pp. 576–591. Springer (2013) 

34. 
Kwiatkowska, M.Z., Norman, G., Parker, D.: Prism 2.0: A tool for probabilistic model checking. In: Proc. of 1th Int. Conference on the Quantitative Evaluation of Systems (QEST), pp. 322–323. IEEE (2004) 

35. 
Larsen, K.G., Behrmann, G., Brinksma, E., Fehnker, A., Hune, T., Pettersson, P., Romijn, J.: As cheap as possible: efficient cost-optimal reachability for priced timed automata. In: Berry, G., Comon, H., Finkel, A. (eds.) Proceedings of CAV 2001, number 2102 in Lecture Notes in Computer Science, pp. 493–505. Springer (2001) 

36. 
Larsson, F., Larsen, K.G.,Pettersson, P., Yi, W.: Efficient verification of real-time systems: Compact data structures and state-space reduction. In: Proc. of the 18th IEEE Real-Time Systems Symposium, pp. 14–24. IEEE Computer Society Press (1997) 

37. 
Larsen, K.G., Pettersson, P., Yi, W.: Uppaal in a Nutshell. Int. J. Softw. Tools Technol. Transf. 1(1–2), 134–152 (1997) 


38. 
Sen, K., Viswanathan, M., Agha, G.: Statistical model checking of black-box probabilistic systems. In: CAV, LNCS 3114, pp. 202– 215. Springer (2004) 

39. 
Theelen, B.D.: Performance modelling for system-level design. Ph.D. thesis, Eindhoven University of Technology, (2004) ISBN 90-386-1633-3 

40. 
Wald, A.: Sequential tests of statistical hypotheses. Ann. Math. Stat. 16(2), 117–186 (1945) 

41. 
Younes, H.L.S.: Verification and planning for stochastic processes with asynchronous events. Ph.D. thesis, Carnegie Mellon (2005) 

42. 
Yi, W., Pettersson, P., Daniels, M.: Automatic verification of real-time communicating systems by constraint-solving. In: Proceedings of the 7th IFIP WG6.1 International Conference on Formal Description Techniques VII, pp. 243–258, London, UK, UK, Chapman & Hall Ltd (1995) 


123