Engineering Methods and Tools for Software Safety and Security - Volume 22 NATO Science for Peace and Security Series - D: Information and Communication Security

ENGINEERING METHODS AND TOOLS FOR SOFTWARE SAFETY AND SECURITY NATO Science for Peace and Security Series This Series...

Author: M. Broy | W. Sitou and T. Hoare

26 downloads 618 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

ENGINEERING METHODS AND TOOLS FOR SOFTWARE SAFETY AND SECURITY

NATO Science for Peace and Security Series This Series presents the results of scientific meetings supported under the NATO Programme: Science for Peace and Security (SPS). The NATO SPS Programme supports meetings in the following Key Priority areas: (1) Defence Against Terrorism; (2) Countering other Threats to Security and (3) NATO, Partner and Mediterranean Dialogue Country Priorities. The types of meeting supported are generally “Advanced Study Institutes” and “Advanced Research Workshops”. The NATO SPS Series collects together the results of these meetings. The meetings are co-organized by scientists from NATO countries and scientists from NATO’s “Partner” or “Mediterranean Dialogue” countries. The observations and recommendations made at the meetings, as well as the contents of the volumes in the Series, reflect those of participants and contributors only; they should not necessarily be regarded as reflecting NATO views or policy. Advanced Study Institutes (ASI) are high-level tutorial courses to convey the latest developments in a subject to an advanced-level audience. Advanced Research Workshops (ARW) are expert meetings where an intense but informal exchange of views at the frontiers of a subject aims at identifying directions for future action. Following a transformation of the programme in 2006 the Series has been re-named and reorganised. Recent volumes on topics not related to security, which result from meetings supported under the programme earlier, may be found in the NATO Science Series. The Series is published by IOS Press, Amsterdam, and Springer Science and Business Media, Dordrecht, in conjunction with the NATO Public Diplomacy Division. Sub-Series A. B. C. D. E.

Chemistry and Biology Physics and Biophysics Environmental Security Information and Communication Security Human and Societal Dynamics

Springer Science and Business Media Springer Science and Business Media Springer Science and Business Media IOS Press IOS Press

http://www.nato.int/science http://www.springer.com http://www.iospress.nl

Sub-Series D: Information and Communication Security – Vol. 22

ISSN 1874-6268

Engineering Methods and Tools for Software Safety and Security

Edited by

Manfred Broy Technische Universität München, Germany

Wassiou Sitou Technische Universität München, Germany

and

Tony Hoare Microsoft Research, UK

Amsterdam • Berlin • Tokyo • Washington, DC Published in cooperation with NATO Public Diplomacy Division

Proceedings of the NATO Advanced Study Institute on Engineering Methods and Tools for Software Safety and Security Marktoberdorf, Germany 5–17 August 2008

© 2009 IOS Press. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 978-1-58603-976-9 Library of Congress Control Number: 2008944241 Publisher IOS Press BV Nieuwe Hemweg 6B 1013 BG Amsterdam Netherlands fax: +31 20 687 0019 e-mail: [email protected] Distributor in the UK and Ireland Gazelle Books Services Ltd. White Cross Mills Hightown Lancaster LA1 4XS United Kingdom fax: +44 1524 63232 e-mail: [email protected]

Distributor in the USA and Canada IOS Press, Inc. 4502 Rachael Manor Drive Fairfax, VA 22032 USA fax: +1 703 323 3668 e-mail: [email protected]

LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS

Engineering Methods and Tools for Software Safety and Security M. Broy et al. (Eds.) IOS Press, 2009 © 2009 IOS Press. All rights reserved.

v

Preface As a consequence of the wide distribution of software and software infrastructure, information security and safety depend on the quality and excellent understanding of its functioning. Only if this functionality is guaranteed as safe, customer and information are protected against adversarial attacks and malfunction. A vast proportion of information exchange is dominated by computer systems. Due to the fact that technical systems are more or less interfaced with software systems most information exchange is closely related to software and computer systems. Information safety and security of software systems depend on the quality and excellent understanding of its functioning. The last few years have shown a renewed interest in formally specifying and verifying software and its role in engineering methods. Within the last decade, interactive program verifiers have been applied to control software and other critical applications, software model checking has made strides into industrial applications, and a number of research tools for bug detection have been built using automatic program-verification technology. Such solutions are high level programming methods and provide strategies to ensure information security in complex software systems by automatically verified correctness. Based on the specific needs in applications of software technology, models and formal methods must serve the needs and the quality of advanced software engineering methods. The objective of our Summer School 2008 Engineering Methods and Tools for Software Safety and Security was an in-depth presentation of state-of-the-art topics on how to meet such challenges covering both theoretical foundations and industrial practice. With Methods and Tools for System and Software Construction J EAN -R AYMOND A BRIAL’s contribution gives an introduction to the construction of complex systems using a formalism called Event-B and a tool called the Rodin Platform. The intent of his contribution is to explain all this in great details by means of various practical examples and tool demonstrations. The contribution is not made of examples and demonstrations only: the theory behind Event-B and the tool are also exposed in details. G ERARD B ERRY presents with Synchronous Techniques for Software and Hardware Embedded Systems the synchronous programming approach to embedded systems design, based on specific languages and programming and verification environments. The synchronous approach is based on zero-delay deterministic information transmission between concurrent processes. It is now widely used for the design and verification of embedded systems in two main application areas: safety-critical embedded software (avionics, railways, heavy industry, and automotive applications), and high-level synthesis of Systems-on-Chips components. The synchronous tools are fully integrated in industrial development flows, ranging from specification-level design to formal verification. For digital interactive distributed systems the timing of their events and the causality between their events are key issues. With his contribution on Relating Time and Causality in Interactive Distributed Systems M ANFRED B ROY demonstrates the relationship between causality and the timing of input and output events, as well as its relationship

vi

to the granularity of time. He deals, in particular, with the problem of time abstraction and the precise timing of events. How causality and time forms the basis of inductive reasoning, specially in the case of dependencies in communication cycles (“feedback”), is also presented as well as how it is able to work with time in models of distributed systems with a flexible choice of local clocks and local timing. Following the results of Jean-Raymond’s topic, M ICHAEL B UTLER shows in his contribution on Incremental Design of Distributed Systems how Event-B can be used to model and reason about distributed systems from a high-level global view down to a detailed distributed architectural view. It is shown how refinement and decomposition could be used to introduce distribution of state and control and to introduce message passing between components. Performing refinement in incremental steps means that the abstraction gap between refinement levels is not too great. This means that the proof effort can be factored out into many relatively simple steps. Simple proof steps allow for a high degree of automation in proof. Proving Program Termination and Liveness is the contribution of B YRON C OOK. Byron introduces available automatic methods for proving that programs eventually do something good (e.g. that programs don’t hang, that programs don’t forget to release locks, etc.). Introduced topics include rank-function synthesis, variance analysis and refinement, fair termination, concurrency, and the support for programs with dynamically allocated data structures. T ONY H OARE’s contribution on Separation Logic and Trace Semantics is concerned with developing a family of simple models of the separating conjunction of separation logic. He illustrates their utility in formalisation of many modern programming language features, including concurrency, sharing of memory, communication, dynamic allocation and disposal of resources, and the transfer of their ownership. He avoids the particularities of any existing or proposed new programming language, but instead attempts to clarify general principles of programming, those that govern the execution of programs expressed in any procedural programming language that includes given feature. The principles are expressed as sanity conditions on timed traces of program execution, and on the predicates describing them. The contribution of K IM G. L ARSEN on Verification, Performance Analysis and Controller Synthesis for Real-Time Systems provides a thorough tutorial of the tool UPPAAL and its application to modelling, verification, optimal scheduling and synthesis of real-time and embedded systems. The theory underlying UPPAAL is focussed, including: timed automata, priced automata and game automata together. Efficient algorithms and data structures for the analysis of these models were thoroughly covered as well as applications of the tool. In his contribution on Specification and Verification of Object-Oriented Software RUSTAN L EINO presents an object-based language, Dafny, whose specifications use the style of dynamic frames. He shows how to write and specify programs in Dafny, and demonstrates how to build a first-order automatic program verifier for Dafny programs, generating the verification conditions as input to an automatic satisfiability-modulotheories solver. J. S TROTHER M OORE presents Mechanized Operational Semantics. He explains how to formalize an “operational” or semantics of a von Neumann programming language in a functional programming language. Such semantics permit both simulation and code proofs. Moore formalizes a simple programming language related to the Java Vir-

vii

tual Machine and shows how it could be elaborated. He focuses on how to prove properties of programs and concluded with a proof of the correctness of the Boyer-Moore fast string searching algorithm. J OHN R EYNOLDS explains in his contribution on Separation Logic – A Logic for Shared Data and Local Reasoning that separation logic is an extension of Hoare logic originally intended for reasoning about programs that use shared mutable data structures. It is based on the concept of separating conjunction, which permits the concise expression of aliasing constraints. He shows that the logic also includes a “frame rule”, which enables local reasoning that is the key to the scalability of proofs. Examples of nontrivial proofs include the Schorr-Waite marking algorithm and the Cheney relocating garbage collector. John Reynolds describes that more recently the logic has been extended to encompass information hiding, shared-variable concurrency, and numerical permissions. J IM W OODCOCK demonstrated The Verified Software Repository. His contribution describes experiments in mechanically verifying several different kinds of systems as part of building a Verified Software Repository. He starts by proposing a series of open challenges and finishes by drawing some conclusions about the current state of the art in modelling and verification, and the need for inter-operability of notations and tools. The contributions in this volume have emerged from the lectures of the 29th International Summer School helt at Marktoberdorf from August 5 to August 17, 2008. 109 participants from 34 countries attended—including students, lecturers and staff. The Summer School provided two weeks of learning, discussion and development of new ideas, and was a fruitful event, at both the professional and social level. We would like to thank all lecturers, staff, and hosts in Marktoberdorf. In particular special thanks goes to Dr. Katharina Spies, Silke Müller, and Katjana Stark for their great and gentle support. The Marktoberdorf Summer School was arranged as an Advanced Study Institute of the NATO Science for Peace and Security Programme with support from the Deutscher Akademischer Austausch Dienst (DAAD), the Microsoft Research Ltd. under the Inspire Programme and the town and county of Marktoberdorf. We thank all authorities involved. T HE E DITORS

viii

ix

Contents Preface

v

A Mechanical Press Controller Development J.R. Abrial

1

Synchronous Techniques for Software and Hardware Embedded Systems Gérard Berry

43

Relating Time and Causality in Interactive Distributed Systems Manfred Broy

75

Incremental Design of Distributed Systems with Event-B Michael Butler Principles of Program Termination – Notes for the Marktoberdorf Summer School Byron Cook Graphical Models of Separation Logic C.A.R. Hoare, Ian Wehrman and Peter W. O’Hearn Verification, Performance Analysis and Controller Synthesis for Real-Time Systems Uli Fahrenberg, Kim G. Larsen and Claus R. Thrane Specification and Verification of Object-Oriented Software K. Rustan M. Leino A Mechanically Checked Proof of the Correctness of the Boyer-Moore Fast String Searching Algorithm J. Strother Moore and Matt Martinez

131

161 177

203 231

267

An Introduction to Separation Logic John C. Reynolds

285

Unifying Theories of Undefinedness Jim Woodcock, Mark Saaltink and Leo Freitas

311

Subject Index

331

Author Index

333

This page intentionally left blank

Engineering Methods and Tools for Software Safety and Security M. Broy et al. (Eds.) IOS Press, 2009 © 2009 IOS Press. All rights reserved. doi:10.3233/978-1-58603-976-9-1

1

A Mechanical Press Controller Development J.R. ABRIAL ETHZ e-mail: [email protected] Abstract. In this text, we present a complete development with Event-B [1] [2] [3]: a mechanical press. The intention is to show how this can be done in a systematic fashion in order to obtain correct final code. In section 1, we present an informal description of this system. In section 2, we develop two general patterns [4] that we shall subsequently use. The development of these patterns will be made by using the proofs as a mean of discovering the invariants and the guards of the events. In section 3, we define the requirement document in a more precise fashion by using the terminology developed in the definition of the patterns. The main development of the mechanical press will take place in further sections where more design patterns will be presented.

1. Informal Description 1.1. Basic Equipments A mechanical press is essentially made of the following pieces of equipment: • a vertical slide which is either stopped or moving up and down very rapidly. • an electrical rotating motor which can be stopped or working, • a connecting rod which transmits the movement of the electrical motor to that of the slide, • a clutch which allows to engage or disengage the motor on the connecting rod. This is illustrated in Fig. 1. 1.2. Basic Commands and Buttons The following commands can be performed by means of buttons named respectively B1, B2, B3, and B4. • • • •

Command 1: start motor (this is performed by depressing button B1), Command 2: stop motor (this is performed by depressing button B2), Command 3: engage clutch (this is performed by depressing button B3), Command 4: disengage clutch (this is performed by depressing button B4).

1.3. Basic User Action The following actions can be performed by the user (it is clearly better to do so when the vertical slide is stopped!).

2

J.R. Abrial / A Mechanical Press Controller Development

MOTOR

ROD

SLIDE

TOOL PART BUTTONS B1

B2

B3

B4

Figure 1. Schematic View of the Press

• Action 1: change the tool at the lower extremity of the vertical slide, • Action 2: put a part to be treated by the press at a specific place under the slide, • Action 3: remove the part that has been treated by the press. The very first schematic structure of the system could be thought of as being the one shown on Fig. 2.

Commands

Equipment

Figure 2. First Schematic View of the System

1.4. User Session A typical user session is the following (we suppose that, initially, the motor is stopped and the clutch is disengaged): • • • • • • • • •

1: start motor (Command 1), 2: change tool (Action 1), 3: put a part (Action 2), 4: engage the clutch (Command 3): the press now works, 5: disengage the clutch (Command 4): the press is stopped, 6: remove the part (Action 3), 7: repeat zero or more times items 3 to 6, 8: repeat zero or more times items 2 to 7, 9: stop motor (Command 2).

As can be seen, the philosophy of this mechanical press is that it can work without stopping the motor.


3

1.5. Danger: Necessity of a Controller Clearly, Action 1 (change the tool), Action 2 (put a part), and Action 3 (remove a part) are dangerous because the user has to manipulate objects (tools, parts) in places which are just situated below the vertical slide. Normally, this slide should not move while doing such actions because the clutch must have been disengaged. However, the user could have forgotten to do so or a malfunction could have caused it not to happen. As a consequence, a controller is placed between the commands and the equipment in order to make sure that things are working properly. In order to prevent malfunctions, the equipment is also reporting its own status to the controller. All this results in the second, more precise, system structure shown on Fig. 3.

Commands

Controller

Equipment

Figure 3. Second Schematic View of the System

1.6. The Door Placing a controller between the commands and the equipment is certainly not sufficient: one has also to make these commands more sophisticated in order to protect the user. In fact, the key is clearly the two commands for engaging and disengaging the clutch. For this, a door is put in front of the press.This is illustrated on Fig. 4. Initially, the door is open. When the user depresses button B3 to engage the clutch, then the door is first closed before engaging the clutch, and when the user depresses button B4 to disengage the clutch, then the door is opened after disengaging the clutch. 2. Design Patterns In this example, there are many cases where a user can depress a button, which is eventually followed by a certain reaction of the system. For example buttons B1 and B2 have an eventual action on the motor. This is not a direct action however. In other words, there is no direct connection between these buttons and the motor. Direct actions on the motor are initiated by the controller which sends commands after receiving some information coming from buttons B1 or B2. For example, when the motor does not work the effect of depressing button B1 is to eventually have the motor working. Likewise, when the motor is working, the effect of depressing button B2 is that the motor will eventually stop. Note that when the user depresses such a button, say button B1, and releases it very quickly, it might be the case that nothing happen simply because the controller has not got enough time to figure out that this button was depressed. Another interesting case is the one where the user depresses button B1 and keep on depressing it by not removing his finger. Once the motor starts working, the user depresses

4


open

closed Figure 4. The door

button B2 with another finger. This results in having the motor being eventually stopped. But the fact that now button B1 is still depressed must not have any effect, the motor must not restart: this is due to the fact that any button must be first released in order to be taken into account once again.

B1

B2

1

4

2 Controller

3

Motor

Figure 5. Race Conditions Between 3 and 4

A more complicated case corresponds to the following sequence of actions as indicated in figure 5: • (1) the user depresses button B1 (starting motor) and, not too quickly releases it, • (2) the controller treats this depressing of button B1 by sending the start command to the motor, • (3) the motor sends back to the controller an information telling that it has started working, • (4) the user depresses button B2 (stopping motor) and, not too quickly, releases it.


5

The difficulty is that action (3) and (4) are done in parallel by the motor and by the user. Both these actions have to be taken into account by the controller. If action (3) (feedback from the motor) wins, then action (4) (depressing the stop button) is followed by a controller reaction whose purpose is to send to the motor the stop command. But if action (4) wins then the reaction of the controller cannot be performed as the controller does not know yet whether the motor is working since it has not received the corresponding information from the motor. In that case, the depressing on button B2 is not taken into account. What we would like to do in this section is to have a formal general study of such cases. This will allow us to have a very systematic approach to the construction of our mechanical press reactive system in further sections. 2.1. Action and Reaction The general paradigm in what we mentioned in the previous section is that of actions and reactions. Action and reactions can be illustrated by a diagram as shown in Fig. 6. We have an action, named a and represented by the plain line, followed by a reaction, named r and represented by the dashed line. Action and reaction can take two values: 0 or 1. We note that r, the reaction, always takes place after a, the action. In other words, r goes up (1) after a has gone up (1). Likewise, r goes down (0) after a has gone down (0).

1 a

r

0 Figure 6. Action and Reaction

2.2. First case: a Simple Action and Reaction Pattern Without Retro-action 2.2.1. Introduction. This first case corresponds to two possible scenarios. In the first one, it is possible that a goes up and down several times while r is not able to react so quickly: it stays down all the time. This is indicated in the diagram of Fig. 7. As a second similar scenario, it is possible that once r has gone up then a goes down and then up again very quickly, so that r comes only down after a has done this several times. This is indicated in the diagram of Fig. 8. When the behavior of an action-reaction system corresponds to what we have just described, it is said that we have a weak synchronization between the action and the reaction.

Figure 7. Action and Weak Reaction (case 1)

6


Figure 8. Action and Weak Reaction (case 2)

2.2.2. Modeling. These two cases will be handled by the same model. Besides variables a and r denoting the state of the action and reaction (invariant pat0_1 and pat0_2 below), we introduce two counters: the first one is named ca and is associated with a and the second one is named cr and is associated with r (invariant pat0_3 and pat0_4 below). These counters denote the number of times each action and reaction respectively has gone up. The role of these counters is precisely to formalize the concept of a weak reaction: this is done in the main invariant, pat0_5, which says that cr is never greater than ca. Note that these counters will not be present in our final definition of the patterns: they are there just to make precise the constraint of the pattern. For that reason, variables ca and cr will not be allowed in the guards of events, they will be present in event actions only.

variables:

a r ca cr

pat0_1:

a ∈ {0, 1}

pat0_2:

r ∈ {0, 1}

pat0_3:

ca ∈ N

pat0_4:

cr ∈ N

pat0_5:

cr ≤ ca

Initially, no action and reaction have taken place (event init below). Events a_on and a_off correspond to the action a. As can be seen, these events are not constrained by the reaction. init a := 0 r := 0 ca := 0 cr := 0

a_on when a=0 then a := 1 ca := ca + 1 end

a_off when a=1 then a := 0 end

This is not the case for r_on and r_off corresponding to the reaction r. These events are synchronized with some occurrences of events a_on and a_off. This is due to the presence of the guards a = 1 and a = 0 in the guards of events r_on and r_off.


r_on when r=0 a=1 then r := 1 cr := cr + 1 end

7

r_off when r=1 a=0 then r := 0 end

The weak synchronization of action and reaction is illustrated in the diagram of Fig 9. In this figure, the arrows simply express that the occurrence of an event relies on the previous occurrences of some others. For example, the occurrence of event r_on depends on that of event a_on and on that of event r_off. Note that these arrows have to be understood informally only.

a_on

a_off

r_on

r_off

Figure 9. Weak Synschronisation of the Events

2.2.3. Proofs. The proofs of invariant preservation are straightforward. Unfortunately, one of them fails. This is the proof of the preservation of invariant pat0_5 by event r_on, that is r_on/pat0_5/INV. r_on when r=0 a=1 then r := 1 cr := cr + 1 end

One has to prove the following (after some simplifications):

8


cr ≤ ca r=0 a=1 cr + 1 ≤ ca

Invariant pat0_5 Guards of event r_on Modified invariant pat0_5

We could solve difficulty by adding the predicate cr < ca in the guard of event r_on: this is certainly the most economical solution as it does not affect the rest of the model. But, as was pointed out earlier, we do not want to incorporate counter variables in event guards. This suggests the following implicative invariant: a = 1 ⇒ cr < ca which is clearly preserved by event a_on which simultaneously sets a to 1 and increments ca, also trivially by events a_off (setting a to 0 and keeping cr and ca untouched) and r_off (keeping a, cr, and ca untouched). But unfortunately, this invariant is not preserved, again by event r_on. In this case, we have to prove the following: a = 1 ⇒ cr < ca r=0 a=1 a = 1 ⇒ cr + 1 < ca

New proposed invariant Guards of event r_on Modified proposed invariant This can be simplified to the following: cr < ca r=0 a=1 cr + 1 < ca

This shows that our first proposed invariant, a = 1 ⇒ cr < ca was not strong enough. The reader could also convince himself that the invariant r = 0 ⇒ cr < ca, would not be sufficient either. Thus, we have to also suppose that r = 0 holds. This leads to the following new invariant: pat0_6:

a = 1 ∧ r = 0 ⇒ cr < ca

The preservation of this invariant by event r_on leads to the following Invariant pat0_6 Guards of event r_on Modified invariant pat0_6

a = 1 ∧ r = 0 ⇒ cr < ca r=0 a=1 a = 1 ∧ 1 = 0 ⇒ cr + 1 < ca

This simplifies to the following which holds trivially since there is a false assumption, namely 1 = 0:


9

cr < ca r=0 a=1 1=0 cr + 1 < ca 2.3. Second Case: a Simple Action Pattern with a Retro-acting Reaction 2.3.1. Introduction. In this section, we refine the previous model by imposing now that the diagrams shown in figures Fig. 8 and Fig. 7 are not possible. We now have a strong synchronization between the action and the reaction. The only well synchronized possibilities are those indicated in Fig. 10.

1 a

r

0 Figure 10. Action and Strong Reaction

2.3.2. Modeling. We have exactly the same variables as in previous case, with an additional invariant stipulating that ca cannot exceed cr by more than one. In other words, either ca and cr are equal or ca is equal to cr + 1. This yields the following: pat1_1:

ca ≤ cr + 1

2.3.3. Proofs. To begin with, since we do not know how to modify the events, we do not modify them at all. The idea again is that the failure of some proofs will give us some clues on how to improve the situation. In fact, all proofs succeed except one. Event a_on cannot maintain the new invariant pat1_1. a_on when a=0 then a := 1 ca := ca + 1 end

After some simplifications, we have to prove:

10


Invariant pat0_5 Invariant pat1_1 Guard of a_on Modified invariant pat1_1

cr ≤ ca ca ≤ cr + 1 a=0 ca + 1 ≤ cr + 1

That is: cr ≤ ca ca ≤ cr + 1 a=0 ca ≤ cr The impossibility to prove this statement suggests the following invariant since ca cannot be strictly smaller than cr because of invariant pat0_5 (cr ≤ ca): pat1_2:

a = 0 ⇒ ca = cr

Unfortunately, this time event a_off cannot preserve this invariant. a_off when a=1 then a := 0 end

After some simplification, we are left to prove the following: Guards of a_off Modified invariant pat1_2

a=1 0 = 0 ⇒ ca = cr

Note that we already have the following (this is pat0_6): a = 1 ∧ r = 0 ⇒ cr < ca This suggests trying the following invariant pat1_3:

a = 1 ∧ r = 1 ⇒ ca = cr

But unfortunately we have no guarantee that r is equal to 1 when we are using event a_off, unless, of course, we add r = 1 as a new guard for event a_off . We thus try to refine a_off by strengthening its guard as follows:


11

a_off when a=1 r=1 then a := 0 end

Unfortunately, this time we have a problem with a_on. a_on when a=0 then a := 1 ca := ca + 1 end

The preservation of the proposed invariant pat1_3 leads to the following to prove: a = 0 ⇒ ca = cr a=0 1 = 1 ∧ r = 1 ⇒ ca + 1 = cr

Invariant pat1_2 Guards of a_on Modified invariant pat1_3 This can be simplified to the following:

ca = cr a=0 r=1 ca + 1 = cr The only possibility to prove this is to have an additional guard in a_on in order to obtain a contradiction. The one that comes naturally is thus r = 0 (it will contradict r = 1). We thus refine a_on by strengthening its guard as follows: a_on when a=0 r=0 then a := 1 ca := ca + 1 end

And now we discover that all invariant preservation proofs succeed. Notice that we can put the two invariants pat1_2 and pat1_3 together:

12


pat1_2:

a = 0 ⇒ ca = cr

pat1_3:

a = 1 ∧ r = 1 ⇒ ca = cr

This leads to the following invariant which can thus replace the two previous ones: pat1_4:

a = 0 ∨ r = 1 ⇒ ca = cr

It is very instructive to put invariant pat0_6 next to this one: pat0_6:

a = 1 ∧ r = 0 ⇒ cr < ca

As can be seen, the antecedent of pat0_6 is the negation of that of pat1_4. And now we can see in the diagram of Fig. 11 the places where these invariants hold.

a=1

a=1

r=1

r=1 a=0

r=0

pat1_4

r=0 pat0_6

a=0

r=0

pat1_4

Figure 11. Showing where the Invariants Hold

To summarize, here are the events for this strong synchronization case. We have removed the counters which were present just to formalize the relationship between the events: a_on when a=0 r=0 then a := 1 end

a_off when a=1 r=1 then a := 0 end r_off when r=1 a=0 then r := 0 end

r_on when r=0 a=1 then r := 1 end

13


The strong synchronization is illustrated on the diagram of Fig. 12.

a_on

a_off

r_on

r_off Figure 12. Strong Synchronization

3. Requirements of the Mechanical Press In view of what we have seen in previous section, we now can clearly present the requirements of our Mechanical Press. We first have three requirements defining what the equipment are: The system has got the following pieces of equipment: a Motor, a Clutch, and a Door

EQP_1

Four Buttons are used to start and stop the motor, and engage and disengage the clutch

EQP_2

A Controller is supposed to manage these equipment

EQP_3

Then we present the ways these equipment are connected to the controller: Buttons and Controller are weakly synchronized

Controller and Equipment are strongly synchronized

FUN_1

FUN_2

Next are the two main safety requirements of the system: When the clutch is engaged, the motor must work

SAF_1

14


When the clutch is engaged, the door must be closed

SAF_2

Finally, more constraints are put in place between the clutch and the door: When the clutch is disengaged, the door cannot be closed several times, ONLY ONCE

When the door is closed, the clutch cannot be disengaged several times, ONLY ONCE

FUN_3

FUN_4

Opening and closing the door is not independent. It must be synchronized with disengaging and engaging the clutch

FUN_5

The overall structure of the system is presented in the diagram of Fig. 13

Motor Buttons

Clutch Buttons

Start Stop

Start Stop

Weak

Weak

clutch_actuator CLUTCH

motor_actuator

Strong

Strong

CONTROLLER

motor_sensor

clutch_sensor

door_actuator

Strong

door_sensor

DOOR

Figure 13. The Press Controller

MOTOR

15


4. Refinement Strategy In the following sections we are going to develop the design of the mechanical press according to the following strategy: • • • • • • • •

Initial model: Connecting the controller to the motor, 1st refinement: Connecting the motor button to the controller, 2nd refinement: Connecting the controller to the clutch, 3rd refinement: Constraining the clutch and the motor, 4th refinement: Connecting the controller to the door, 5th refinement: Constraining the clutch and the door, 6th refinement: More constraints between the clutch and the door, 7th refinement: Connecting the clutch button to the controller.

In each case, we are going to do so by instantiating some design patterns. 5. Initial Model: Connecting the Controller to the Motor 5.1. Introduction. This initial model formalizes the connection of the controller to the motor as illustrated in Fig. 14

Strong Reaction Controller Motor Figure 14. Connecting the Controller to the Motor

We take partially into account requirement FUN_2: Controller are Equipment are strongly synchronized

FUN_2

5.2. Modeling. We first define a context with the set ST AT U S defining the two different status of the motor: stopped or working:

set: ST AT U S

constants: stopped working

axm0_1: ST AT U S = {stopped, working} axm0_2: stopped = working

16


Then we define two variables corresponding to the connection of the motor to the controller: motor_actuator and motor_sensor. Variable motor_actuator formalizes the connection of the controller to the motor. It corresponds to the command sent by the controller, either to start or to stop the motor. Variable motor_sensor formalizes the connection of the motor to the controller. It corresponds to the feedback sent by the motor concerning its physical status. variables:

motor_actuator motor_sensor

inv0_1: motor_sensor ∈ ST AT U S inv0_2: motor_actuator ∈ ST AT U S In this connection, the controller acts as an action whereas the motor acts as a reaction. As we know, the reaction of the motor is strongly synchronized to the action of the controller. The idea then is to use the corresponding pattern (section 2.3) by instantiating it to the problem at hand. More precisely, we are going to instantiate the strong pattern as follows: a r 0 1 a_on a_off r_on r_off

; ; ; ; ; ; ; ;

motor_actuator motor_sensor stopped working treat_start_motor treat_stop_motor Motor_start Motor_stop

This leads first to the following events, which are supposed to represent the action of the controller: a_on when a=0 r=0 then a := 1 end

treat_start_motor when motor_actuator = stopped motor_sensor = stopped then motor_actuator := working end


treat_stop_motor when motor_actuator = working motor_sensor = working then motor_actuator := stopped end

In this section and in the rest of this chapter, we shall follow the convention that the names of the events pertaining the controller all start with the prefix "treat-". A contrario,

17


events whose names do not start with the prefix "treat-" are physical events occurring in the environment. The following events are supposed to represent the physical reaction of the motor: r_on when r=0 a=1 then r := 1 end

Motor_start when motor_sensor = stopped motor_actuator = working then motor_sensor := working end


Motor_stop when motor_sensor = working motor_actuator = stopped then motor_sensor := stopped end

5.3. Summary of the Events - Environment - motor_start - motor_stop - Controller - treat_start_motor - treat_stop_motor

6. First Refinement: Connecting the Motor Buttons to the Controller 6.1. Introduction. We extend now the connection introduced in the previous section by connecting the motor buttons B1 (start motor) and B2 (stop motor) to the controller. This corresponds to the diagram of Fig. 15 We take partially into account requirement FUN_1: Buttons and Controller are weakly synchronized

FUN_1

6.2. Modeling We define two boolean variables corresponding to the connection of the motor buttons B1 and B2 to the controller: start_motor_button and stop_motor_button. These physical variables denote the status of buttons B1 and B2 respectively: when equal to TRUE, it

18


B1

B2

Weak Reaction Strong Reaction Controller Motor Figure 15. Connecting the Motor Buttons to the Controller

means that the corresponding button is physically depressed, when equal to FALSE, it means that it is physically released. We define two more boolean variables, this time controller variables : start_motor_impulse and stop_motor_impulse. These variables denotes the knowledge by the controller of the physical status of the buttons. They are clearly distinct from the two previous variables as the change of the physical status of a button occurs before the controller can be aware of it. variables:

inv1_1: inv1_2: inv1_3: inv1_4:

... start_motor_button stop_motor_button start_motor_impulse stop_motor_impulse

stop_motor_button ∈ BOOL start_motor_button ∈ BOOL stop_motor_impulse ∈ BOOL start_motor_impulse ∈ BOOL

As we know, the controller weakly reacts to the buttons: it means that the buttons can be sometimes quickly depressed and released without the controller reacting to it: the behavior is clearly an instantiation of the weak reaction pattern we studied in section 2.2. Thus, we are going to instantiate the weak pattern as follows: a_on a_off r_on r_off a r 0 1

; ; ; ; ; ; ; ;

Here are the first two events:

push_start_motor_button release_start_motor_button treat_start_motor treat_release_start_motor_button start_motor_button start_motor_impulse FALSE TRUE


a_on when a=0 then a := 1 end

push_start_motor_button when start_motor_button = FALSE then start_motor_button := TRUE end


release_start_motor_button when start_motor_button = TRUE then start_motor_button := FALSE end

19

Here are the two other events. As can be seen, the event treat_start_motor, which used to be the instantiation of an action in the initial model, is now the instantiation of a reaction. It is renamed below treat_push_start_motor_button: r_on

end

treat_push_start_motor_button refines treat_start_motor when start_motor_impulse = FALSE start_motor_button = TRUE motor_actuator = stopped motor_sensor = stopped then start_motor_impulse := TRUE motor_actuator := working end


treat_release_start_motor_button when start_motor_impulse = TRUE start_motor_button = FALSE then start_motor_impulse := FALSE end

when r=0 a=1 then r := 1

In order to understand what is happening here, let us show again the abstract event treat_start_motor. treat_start_motor when motor_actuator = stopped motor_sensor = stopped then motor_actuator := working end

20


We can see how the new pattern is superposed to the previous one: treat_push_start_motor_button refines treat_start_motor when start_motor_impulse = FALSE start_motor_button = TRUE motor_actuator = stopped motor_sensor = stopped then start_motor_impulse := TRUE motor_actuator := working end

The guard of the concrete version of event treat_push_start_motor_button is made stronger and the action is enlarged: the new version of this event is indeed a refinement of the previous one. But, at the same time, the new version of this event is also a refinement of the pattern (up to renaming). We now instantiate the weak pattern as follows: a_on a_off r_on r_off a r 0 1

; ; ; ; ; ; ; ;

push_stop_motor_button release_stop_motor_button treat_stop_motor treat_release_stop_motor_button stop_motor_button stop_motor_impulse FALSE TRUE

Once again, we can see that the event treat_stop_motor which used to be the instantiation of an action in the initial model is now the instantiation of a reaction. It is renamed treat_push_stop_motor_button. a_on when a=0 then a := 1 end

push_stop_motor_button when stop_motor_button = FALSE then stop_motor_button := TRUE end


release_stop_motor_button when stop_motor_button = TRUE then stop_motor_button := FALSE end


r_on

21

treat_push_stop_motor_button refines treat_stop_motor when stop_motor_impulse = FALSE stop_motor_button = TRUE motor_sensor = working motor_actuator = working then stop_motor_impulse := TRUE motor_actuator := stopped end

when r=0 a=1 then r := 1 end r_off when r=1 a=0 then r := 0 end

treat_release_stop_motor_button when stop_motor_impulse = TRUE stop_motor_button = FALSE then stop_motor_impulse := FALSE end

In the diagram of Fig. 16, you can see a combined synchronization of the various events.

push_start_motor_button

treat_push_start_motor_button

release_start_motor_button

treat_release_start_motor_button

Motor_start

Motor_stop

treat_release_stop_motor_button

release_stop_motor_button

treat_push_stop_motor_button

push_stop_motor_button

Figure 16. Combined Synchronizations

22


6.3. Adding "false" events The problem we tackle in this section has to do with the superposition of a pattern on an existing event. A typical example is the following event: treat_push_start_motor_button refines treat_start_motor when start_motor_impulse = FALSE start_motor_button = TRUE motor_actuator = stopped motor_sensor = stopped then start_motor_impulse := TRUE motor_actuator := working end In case the following condition is false motor_actuator = stopped ∧ motor_sensor = stopped while the following condition is true: start_motor_impulse = FALSE ∧ start_motor_button = TRUE then the event cannot be "executed" but nevertheless the button has been depressed so that the assignment start_motor_impulse := TRUE must be "executed". As a consequence, it is necessary to define the following additional event: treat_push_start_motor_button_false when start_motor_impulse = FALSE start_motor_button = TRUE ¬ (motor_actuator = stopped ∧ motor_sensor = stopped) then start_motor_impulse := TRUE end In the sequel, we shall encounter similar cases for all buttons. 6.4. Summary of the Events - Environment - motor_start - motor_stop - push_start_motor_button

23


- release_start_motor_button - push_stop_motor_button - release_stop_motor_button - Controller - treat_push_start_motor_button - treat_push_start_motor_button_false - treat_push_stop_motor_button - treat_push_stop_motor_button_false - treat_release_start_motor_button - treat_release_stop_motor_button

7. Second Refinement: Connecting the Controller to the Clutch We now connect the controller to the clutch. As it follows exactly the same approach as the one we have already used for the connection of the controller to the motor in section 6, we simply copy (after renaming "motor" to "clutch") what has been done in the initial model. 7.1. Summary of the Events - Environment - motor_start - motor_stop - clutch_start - clutch_stop - push_start_motor_button - release_start_motor_button - push_stop_motor_button - release_stop_motor_button - Controller - treat_push_start_motor_button - treat_push_start_motor_button_false - treat_push_stop_motor_button - treat_push_stop_motor_button_false - treat_release_start_motor_button - treat_release_stop_motor_button - treat_start_clutch - treat_stop_clutch

8. Another Design Pattern: Weak Synchronization of Two Strong Reactions Our next step in designing the Mechanical Press is to take account of the following additional safety constraint: When the clutch is engaged, the motor must work

SAF_1

24


It means that engaging the clutch is not independent of the starting of the motor as was the case in the previous refinement, where we had two completely independent strongly synchronized connections: that of the motor and that of the clutch. For studying this in general, we now consider another design pattern. 8.1. Introduction. In this design pattern, we have two strongly synchronized patterns as indicated in Fig. 17, where in each case the arrows indicate the strong synchronization at work. Note that the first action and reaction are called a and r as before, whereas the second ones are called b and s.

a r

b s Figure 17. Two Strongly Synchronized Action-reactions

We would like now to synchronize these actions and reactions so that the second reaction, s, only occurs when the first one, r, is enabled. In other words, we would like to ensure the following: s = 1 ⇒ r = 1. r=1

s=1 => r=1 s=1

Figure 18. Synchronizing two Strongly Synchronized Action-reactions

This is illustrated in Fig. 18, where the dashed arrows indicate this new synchronization. But this synchronization between the two is supposed to be weak only. For example, in our case, it is possible that the motor is started and stopped several time before the clutch is indeed engaged. Likewise, it is possible that the clutch is disengaged and re-engaged several times before the motor is stopped. All this is illustrated in Fig. 19.


25

Motor can be started and stopped several times Clutch is disengaged

Motor is working Clutch can be disengaged and re−engaged several times

Figure 19. Weak Synchronization of the Motor and the Clutch

In the diagrams of Fig. 19, the new relationship between the various events is illustrated by the dashed arrows. The reason why these arrows are dashed is that we have an additional constraint stating that we do not want to modify the reacting events s_on and r_off. This is illustrated in Fig. 20. More precisely, we want to act at the level of the actions which have enabled these events. This is what we shall formalise in the next section. a_on

a_off

r_on

r_off

b_on

b_off

s_on

s_off

Figure 20. Weak Synchronization of two Strongly Synchronized Action-reactions

26


8.2. Modeling. Next is a blind copy of the two strongly synchronized patterns:

dbl0_1: dbl0_2: dbl0_3: dbl0_4: dbl0_5: dbl0_6:

a ∈ {0, 1} r ∈ {0, 1} ca ∈ N cr ∈ N a = 1 ∧ r = 0 ⇒ ca = cr + 1 a = 0 ∨ r = 1 ⇒ ca = cr

dbl0_7: dbl0_8: dbl0_9: dbl0_10: dbl0_11: dbl0_12:

b ∈ {0, 1} s ∈ {0, 1} cb ∈ N cs ∈ N b = 1 ∧ s = 0 ⇒ cb = cs + 1 b = 0 ∨ s = 1 ⇒ cb = cs

a_on when a=0 r=0 then a, ca := 1, ca + 1 end

b_on when b=0 s=0 then b, cb := 1, cb + 1 end


b_off when b=1 s=1 then b := 0 end

r_on when r=0 a=1 then r, cr := 1, cr + 1 end

s_on when s=0 b=1 then s, cs := 1, cs + 1 end


s_off when s=1 b=0 then s := 0 end

We now refine these patterns by introducing our new requirement

dbl1_1: s = 1 ⇒ r = 1

The only events which might cause any problem in proving this invariant are event s_on (setting s to 1) and r_off (setting r to 0). In order to solve this problem, it seems sufficient to add the guards r = 1 and s = 0 to events s_on and r_off respectively:


s_on when s=0 b=1 r=1 then s, cs := 1, cs + 1 end

27

r_off when r=1 a=0 s=0 then r := 0 end

But, as indicated above, we do not want to touch these reacting events. In order to obtain the same effect, it is sufficient to add the following invariants: dbl1_2: b = 1 ⇒ r = 1 dbl1_3: a = 0 ⇒ s = 0 In order to maintain invariant dbl1_2, we have to modify event b_on by adding the guard r = 1 to it since it sets b to 1: b_on when b=0 s=0 then b := 1 cb := cb + 1 end

;

b_on when b=0 s=0 r=1 then b := 1 cb := cb + 1 end

To maintain invariant dbl1_2 we have also to add the guard b = 0 to event r_off since it sets r to 0: r_off when r=1 a=0 then r := 0 end

;

r_off when r=1 a=0 b=0 then r := 0 end

But, again, we do not want to touch this reacting event so that we introduce the following invariant: dbl1_4: a = 0 ⇒ b = 0 In order to maintain invariant dbl1_3, that is:

28


dbl1_3: a = 0 ⇒ s = 0 we have to refine event a_off as follows (guard strengthening): a_off when a=1 r=1 then a := 0 end

;

a_off when a=1 r=1 s=0 then a := 0 end

We have also to refine event s_on as follows (guard strengthening) s_on when s=0 b=1 then s := 1 cs := cs + 1 end

;

s_on when s=0 b=1 a=1 then s := 1 cs := cs + 1 end

But, again, we do not want to touch this event, so that we have to introduce the following invariant: b=1 ⇒ a=1 Fortunately, this is exactly dbl1_4 contraposed dbl1_4: a = 0 ⇒ b = 0 In order to maintain invariant dbl1_4, we have to refine a_off again a_off when a=1 r=1 s=0 then a := 0 end

;

a_off when a=1 r=1 s=0 b=0 then a := 0 end


29

And also event b_on again: b_on when b=0 s=0 r=1 then b := 1 cb := cb + 1 end

;

b_on when b=0 s=0 r=1 a=1 then b := 1 cb := cb + 1 end

Now we have obtained the desired effect, namely that of weakly synchronizing the reactions r and s by acting on their respective actions a and b. This is indicated in the diagram of Fig. 21.

a_on

a_off

r_on

r_off

b_on

b_off

s_on

s_off

Figure 21. Weak Synchronizing two Strongly Synchronized Action-reactions

Here is a summary of the introduced invariants: dbl1_1: s = 1 ⇒ r = 1

dbl1_3: a = 0 ⇒ s = 0

dbl1_2: b = 1 ⇒ r = 1

dbl1_4: a = 0 ⇒ b = 0

Here is also a summary of the modified events a_off and b_on (where we have removed the incrementation of counter cb):

30



b_on when b=0 s=0 r=1 a=1 then b := 1 end

Note that the four previous invariants can be equivalently reduced to the following unique one, which can be "read" now on the diagram of Fig. 22. dbl1_5: b = 1 ∨ s = 1 ⇒ a = 1 ∧ r = 1

a r b s

a=0 or r=0

a=0 or r=0

Figure 22.

a=0 or r=0

b=1 or s=1

b=1 or s=1

b=1 ∨ s=1 ⇒ a=1 ∧ r=1

9. Third Refinement: Constraining the Clutch and the Motor Coming back to our development, we incorporate now the following requirement: When the clutch is engaged, the motor must work

SAF_1

This can be formalized by means of the following new invariant inv3_1:

clutch_sensor = engaged ⇒ motor_sensor = working

This is an instance of the design pattern developed in section 8, which we instantiate as follows:


31

a r 0 1

; ; ; ;

motor_actuator motor_sensor stopped working

a_on a_off r_on r_off

; ; ; ;

treat_push_start_motor_button treat_push_stop_motor_button Motor_start Motor_stop

b s 0 1

; ; ; ;

clutch_actuator clutch_sensor disengaged engaged

b_on b_off s_on s_off

; ; ; ;

treat_start_clutch treat_stop_clutch Clutch_start Clutch_stop

The invariant are as follows:

s=1 dbl1_1: ⇒ r=1

inv3_1:

clutch_sensor = engaged ⇒ motor_sensor = working

b=1 dbl1_2: ⇒ r=1

inv3_2:

clutch_actuator = engaged ⇒ motor_sensor = working

dbl1_3:

a=0 ⇒ s=0

inv3_3:

motor_actuator = stopped ⇒ clutch_sensor = disengaged

dbl1_4:

a=0 ⇒ b=0

inv3_4:

motor_actuator = stopped ⇒ clutch_actuator = disengaged

The two modified events are as follows:

b_on when b=0 s=0 r=1 a=1 then b := 1 end

treat_start_clutch when clutch_actuator = disengaged clutch_sensor = disengaged motor_sensor = working motor_actuator = working then clutch_actuator := engaged end

32



treat_stop_motor when stop_motor_impulse = FALSE stop_motor_button = TRUE motor_actuator = working motor_sensor = working clutch_sensor = disengaged clutch_actuator = disengaged then motor_actuator := stopped stop_motor_impulse := TRUE end

10. Fourth Refinement: Connecting the Controller to the Door 10.1. Copying We copy (after renaming "motor" to "door") what has been done in the initial model (section 6) 10.2. Summary of the Events - Environment - motor_start - motor_stop - clutch_start - clutch_stop - door_close - door_open - push_start_motor_button - release_start_motor_button - push_stop_motor_button - release_stop_motor_button - Controller - treat_push_start_motor_button - treat_push_start_motor_button_false - treat_push_stop_motor_button - treat_push_stop_motor_button_false - treat_release_start_motor_button - treat_release_stop_motor_button - treat_start_clutch - treat_stop_clutch - treat_close_door - treat_open_door

11. Fifth Refinement: Constraining the Clutch and the Door We now incorporate the following additional safety constraint:

33



SAF_2

This is done by copying (after renaming "motor" to "door") what has been done in the third model (section 9). At this point, we figure out that we have forgotten something concerning the door: clearly it must be open when the motor is stopped so that the user can replace the part or change the tool. This can be stated by adding the following requirement: When the motor is stopped, the door must be open

SAF_3

It is interesting to present this requirement under its equivalent contraposed form SAF_3’: When the door is closed, the motor must work

SAF_3’

We can take care of this requirement by copying (after renaming "clutch" to "door") what has been done in the third model (section 9). It is interesting to put now the two previous requirements SAF_1 and SAF_2 next to SAF_3’: When the clutch is engaged, the motor must work


SAF_1

SAF_2

This shows that SAF_1 is redundant as it can be obtained by combining SAF_2 and SAF_3’! The moral of the story is that the third refinement (section 9) can be removed completely, and thus our refinement strategy (section 4) could have been simplified as follows: • • • • •

Initial model: Connecting the controller to the motor, 1st refinement: Connecting the motor button to the controller, 2nd refinement: Connecting the controller to the clutch, 3rd (4th) refinement: Connecting the controller to the door, 4th (5th) refinement: Constraining the clutch and the door and the motor and the door, • 5th (6th) refinement: More constraints between the clutch and the door, • 6th (7th) refinement: Connecting the clutch button to the controller. 12. Another Design Pattern: Strong Synchronization of Two Strong Reactions 12.1. Introduction. We consider now the following requirements FUN_3 and FUN_4 concerning the relationship between the clutch and the door:

34


When the clutch is disengaged, the door cannot be closed several times When the door is closed, the clutch cannot be disengaged several times This is also a case of synchronization between two strong reactions. This time however the weak synchronization is not sufficient any more: we need a strong synchronization. This is indicated in the diagram of Fig. 23.The full picture is indicated on Fig. 24.

Door CANNOT be closed and re−opened several times Clutch is disengaged

Door is closed Clutch CANNOT be disengaged and re−engaged several times

Figure 23. Strong Synchronization between the Clutch and the Door

12.2. Modeling The modeling of this new constraints will be presented as a refinement of the "weakstrong" model of section 8. In order to formalize this new kinds of synchronization, we have to consider again the counters ca, cr, cb, and cs as indicated in Fig. 25. What we want to achieve is expressed in the following properties: ca = cb ∨ ca = cb + 1 cr = cs ∨ cr = cs + 1 Let us first treat the case of counters ca and cb as illustrated in Fig 26. It seems that the condition ca = cb + 1 is implied by the condition a = 1 ∧ b = 0 as indicated in


35

door is closed

door is open

clutch is engaged

clutch is disengaged

Figure 24. The Full Picture of Strong Synchronization

counter ca counter cr

counter cb

counter cs

Figure 25. The Counters

fig 27. However, this guess is wrong as illustrated on Fig 28. The solution consists in introducing a new variable m as indicated in Fig. 29. dbl2_1: m ∈ {0, 1} variables:

... m

dbl2_2: m = 1 ⇒ ca = cb + 1 dbl2_3: m = 0 ⇒ ca = cb

Let us now treat the case of counters cr and cs as indicated on Fig. 30. It seems that the condition cr = cs + 1 is implied by the condition r = 1 ∧ s = 0 as indicated in fig 31. But again this guess is wrong as illustrated on Fig 32. The solution is shown on Fig. 33. This lead to the following additional invariants dbl2_4 and dbl2_5:

36


ca=cb+1

ca=cb

Figure 26. Counters ca and cb

a=1

ca=cb+1

ca=cb

a=1 and b=0

b=0

Figure 27. A Guess

dbl2_1: m ∈ {0, 1} dbl2_2: m = 1 ⇒ ca = cb + 1 dbl2_3: m = 0 ⇒ ca = cb dbl2_4: r = 1 ∧ s = 0 ∧ (m = 1 ∨ b = 1) ⇒ cr = cs + 1 dbl2_5: r = 0 ∨ s = 1 ∨ (m = 0 ∧ b = 0) ⇒ cr = cs

Let us now turn our attention to the modified events. This is indicated on Fig. 34. As can be seen the concerned events are a_on, b_on, and a_off. Here are the proposals for these events:

37


a=1

a=1

ca=cb+1

ca=cb

a=1 and b=0

a=1 and b=0

b=0

b=0

Figure 28. The Guess is Wrong

ca=cb+1

ca=cb

m=1

m=0

m=0

Figure 29. Introducing a New Variable m

a_on when a=0 r=0 then a := 1 ca := ca + 1 m := 1 end

b_on when r=1 a=1 b=0 s=0 m=1 then b := 1 cb := cb + 1 m := 0 end

a_off when a=1 r=1 b=0 s=0 m=0 then a := 0 end

It remains now for us to do the proofs. Similar techniques as the ones used in sections 2 and 8 lead us to define the following additional invariants dbl2_6 and dbl2_7:

38


dbl2_1: m ∈ {0, 1} dbl2_2: m = 1 ⇒ ca = cb + 1 dbl2_3: m = 0 ⇒ ca = cb dbl2_4: r = 1 ∧ s = 0 ∧ (m = 1 ∨ b = 1) ⇒ cr = cs + 1 dbl2_5: r = 0 ∨ s = 1 ∨ (m = 0 ∧ b = 0) ⇒ cr = cs dbl2_6: m = 0 ⇒ a = 0 ∨ r = 1 dbl2_7: m = 1 ⇒ b = 0 ∧ s = 0 ∧ a = 1 After this last invariant extension, the proofs are done easily.

cr=cs+1

cr=cs

cr=cs

m=1

m=0

m=0

Figure 30. Counters cr and cs

13. Sixth Refinement: More Constraints between Clutch and Door It remains now for us to instantiate the "strong-strong" pattern of previous section. It is done as follows: a r 0 1

; ; ; ;

door_actuator b ; clutch_actuator door_sensor s ; clutch_sensor open 0 ; disengaged closed 1 ; engaged a_on ; treat_close_door a_off ; treat_open_door b_on ; treat_start_clutch

This leads to the following event instantiations:


r=1 cr=cs+1

cr=cs

cr=cs

r=1 and s=0

m=1

s=0

m=0

m=0

s=0

Figure 31. A Guess

r=1

r=1

cr=cs+1

cr=cs

cr=cs

r=1 and s=0

r=1 and s=0 m=1

s=0

m=0

s=0

m=0

s=0

Figure 32. The Guess is Wrong

a_on when a=0 r=0 then a := 1 m := 1 end

treat_close_door when door_actuator = open door_sensor = open motor_actuator = working motor_sensor = working then door_actuator := closed m := 1 end

39

40


r=1

r=1

cr=cs+1

cr=cs

cr=cs

r=1 and s=0 m=1

b=1 r=1 and s=0

m=1

s=0

m=0

b=0 m = 0

s=0

Figure 33. The Solution

a_on

a_off

m=1 b_on m=0

m=0

Figure 34. The Events

b_on when b=0 s=0 r=1 a=1 m=1 then b := 1 m := 0 end

treat_start_clutch when motor_actuator = working motor_sensor = working clutch_actuator = disengaged clutch_sensor = disengaged door_sensor = closed door_actuator = closed m=1 then clutch_actuator := engaged m := 0 end

41


a_off when a=1 r=1 s=0 b=0 m=0 then a := 0 end

treat_open_door when door_actuator = closed door_sensor = closed clutch_sensor = disengaged clutch_actuator = disengaged m=0 then door_actuator := open end

The final synchronization of the door and the clutch is shown on Fig. 35. In this figure, the underlined events are environment events. treat_open_door

door_open

push_start_clutch_button (B3)

treat_close_door

push_stop_clutch_button (B4)

treat_stop_clutch door_close treat_start_clutch

clutch_start

clutch_stop

Figure 35. The Final Synchronization of the Door and the Clutch

14. Seventh Refinement: Connecting the Controller to the Clutch Buttons 14.1. Copying We simply connect button B3 to the event treat_close_door and button B4 to the events treat_stop_clutch. 14.2. Summary of Events - Environment - motor_start - motor_stop - clutch_start - clutch_stop - door_close - door_open

42


- push_start_motor_button - release_start_motor_button - push_stop_motor_button - release_stop_motor_button - push_start_clutch_button - release_start_clutch_button - push_stop_clutch_button - release_stop_clutch_button - Controller - treat_push_start_motor_button - treat_push_start_motor_button_false - treat_push_stop_motor_button - treat_push_stop_motor_button_false - treat_release_start_motor_button - treat_release_stop_motor_button - treat_start_clutch - treat_stop_clutch - treat_close_door - treat_open_door - treat_close_door_false

References J.R. Abrial. The B-book: Assigning Programs to Meanings. CUP 1996 J.R. Abrial. Modeling in Event-B: System and Software Engineering. To be published by CUP 2009 J.R. Abrial and S. Hallerstede. Refinement, Decomposition,and Instantiation of Discrete Models: Application to Event-B. Fundam. Inform. 2007 [4] J.R. Abrial and Thai Son Wang. Using design Pattern in Formal methods: An EWvent-B Approach. ICTAC 2008 [1] [2] [3]


43

Synchronous Techniques for Software and Hardware Embedded Systems Gérard BERRY a a Chief Scientist, Esterel Technologies 679 av Dr. J. Lefebvre 06270Villeneuve-Loubet, France Abstract. We survey the synchronous approach to embedded hardware and software systems, its scientific content, and its use in industry. We discuss the concurrency and determinism constraints of embedded applications, and the way in which they are reconciled by the synchronous concurrency model. We present the main synchronous languages, their semantics, and the industrial tools and flows that support them. Keywords. Synchronous programming, embedded system, safety-critical systems, synchronous circuits, systems on chips, formal semantics, formal verification, automatic code generation.

Introduction We present the synchronous programming approach to embedded systems design, which is based on specific languages and programming and verification environments. Born in research in the early 80’s and first industrialized in the 90’s, the synchronous approach is now widely used for the design and verification of embedded systems in two main application areas: on one hand, safety-critical embedded software in avionics, railways, heavy industry, and automotive applications; on the other hand, high-level synthesis of Systems-on-Chips hardware components. Although the involved industries are vastly different in their development flows and application constraints, they deal with the same basic objects: control-theory or signal-processing data-flow networks, and finite state machines. Synchronous languages are dedicated to these two major design components and to their integration in a common hierarchical and concurrent framework. Section 1 describes the specific problems posed by embedded system design and verification. Section 2 presents the synchronous cycle-based approach to embedded systems design. The key is synchronous parallelism, which scales up to real-size applications with a large number of parallel components, while remaining deterministic by construction, unlike for classical asynchronous parallelism. Section 4 briefly presents the various styles of synchronous primitives and languages, including the industrial languages Esterel v7 for hardware and Scade 6 for safety-critical software, used in the SCADE tool (Safety Critical Application Development Environment). The section also briefly describes the mathematical semantics of the languages, the way they are compiled, and the way program properties are formally verified. Section 5 discusses integration of syn-

44

G. Berry / Synchronous Techniques for Software and Hardware Embedded Systems

Figure 1. The concrete car.

chronous techniques in industrial flows and actual applications. It shows how SCADE makes it possible to formally and efficiently develop safety-critical software certified according to the DO-178B avionics norm, the most stringent safety norm in computer applications. We conclude in Section 6. Basic references for synchronous languages are [44,15,42,41,6]. See also [35] for the inscription of synchronous languages in a more general embedded systems programming landscape.

1. Embedded Systems Design Issues Embedded hardware and software systems drive objects of all kinds: airplanes, trains, cars, cameras, TV sets, music players, telephones, robots, medical sensors, pacemakers, etc. Examples of embedded systems in a modern electronified car are shown in Figure 1. 1.1. Embedded Systems Safety Constraints Embedded computerized systems obey particular constraints depending on their usage. • They are safety-critical when human life is at stake. Such systems are found in avionics, trains, plants, or medical applications. Avionics examples are flight control, engine control (FADEC), braking and steering control, landing gear control, etc. They bear stringent safety constraints: bugs can simply not be tolerated. They are often required to be certified by external authorities (for instance, the Federal Aviation Agency for commercial airplanes).


45

• They are often called mission-critical when their safety impacts a whole application without directly endangering humans. Such systems are found in rockets, satellites, etc. Automotive manufacturers still seem to think that automotive software lies in this category, which is not obvious for the rest of us. • They are called market-critical if their failure can either impact time-to-market in a product development, or lead to costly product recall after deployment. Examples are cameras, telephones, TV sets, etc. In all cases, bugs are much more problematic than for standard computer-based systems, since fixing a bug cannot simply be done by new release download. In the worst case, for certified avionics, any design change requires a re-certification. 1.2. Embedded Systems Design Constraints Two intrinsic constraints are essential for most embedded systems. • Parallelism. The systems are almost invariably composed of components that act in parallel and must be controlled in parallel. For instance, an airplane has two wings, two or four engines, three wheel sets, two pilots, lots of displays, etc. • Determinism. Most often, it is required that the system’s response shall always be the same if the past and present environments are the same. A car driver clearly expects his car to be deterministic in this sense. Beware: the determinism we mention is internal determinism, which should be carefully distinguished from external non-determinism due to the environment in which the system evolves. The environment remains of course unpredictable and cannot be deterministically controlled by the system. External non-determinism and internal determinism are both the rule. Internal determinism can sometimes be relaxed, but should never be let go wild. 1.3. Embedded Systems Design Styles Embedded applications involve four styles of components. • Continuous control components, or CC-components for short. These are the subject of control and signal processing theories. For instance, an airplane autopilot is mostly a CC-component. • Finite state machines components, or FSM-components for short. They are found in user interfaces, in communication protocols, in mode logic for switching between CC algorithms, etc. For instance, a USB connection protocol or the control of a display system are large FSMs; on the opposite the user control of an autopilot is generally a simple FSM coupled with complex CC logic. • Calculation components. They are found in engine control, GPS localization, etc. • Web-like components. They are found in non-critical human-machine interfaces, games, entertainment systems, etc. It is fundamental to understand the relative weight of these four component kinds. If one performs an abstraction of the concrete car of Figure 1 according to the above taxonomy, one obtains the “abstract car” displayed in Figure 2. It is clear that the CC+FSM association is predominant. Therefore, dealing with the CC+FSM couple in the best possible

46


Figure 2. The abstract car.

way is a key concern. Furthermore, CC and FSM components can be very big, and it is fundamental to design them in a hierarchical style to scale to real application style. Here, we mean behavior hierarchy, not just structure hierarchy. 1.4. The Limits of Classical Design Techniques At specification level, CC+FSM designs are often modeled using control-theory based mathematical tools and libraries (Matlab, SciLab, etc.). Such design environments make it possible to couple a model of the design with a model of its environment, usually represented by continuous differential equations. However, while they are appropriate to develop CC algorithms controlled by small FSMs, these tools are far from rigorous enough to be able to generate safe enough embedded code. A manual or automatic insertion into coding techniques that respect the strongest safety rules of hardware or software engineering is required. In traditional software engineering, coding is done using conventional or concurrent programming languages (C, ADA etc.) augmented with parallelism primitives (tasking or threading for C, tasking and rendezvous for ADA). However, these languages are born from classical computing and not up to the job. Programming CC and FSM applications with them is unnatural and stylistically far from the specifications provided by the architects. Most importantly, classical languages exhibit a misfit between determinism and parallelism, because they are based on non-deterministic interleaving of activities. Indeed, they are often call concurrent languages, to stress the fact that activities concurrently compete for resources, each concurrent process seeing the other ones as a nondeterministic competitor. This view is fine to build Internet surfing tools, but it is the exact opposite of what is needed to deterministically control the behavior of an airplane. In traditional hardware design using Verilog and VHDL register transfer level (RTL) languages, parallelism and determinism fit well together: all gates in a circuit act in par-


47

allel, and the clocking mechanism makes the behavior internally deterministic (see Section 2.3). Hierarchical design of CC systems is also feasible since the languages support structural hierarchy, which is enough for CC. However, sequencing behaviors becomes difficult, and there is no support for hierarchical design of FSMs, which is not as simple as for CC, and, more generally, of hierarchical description of behavior and not just structure.

2. Rethinking Concurrency : the Synchronous Approach To make progress towards better embedded systems design techniques, we need to better understand what parallelism really means. Let us first get out of the classical view that parallelism is synonymous with concurrency, asynchrony, and competition. 2.1. The Three Kinds of Compositional Parallelism For design techniques to scale, it is fundamental that any model of concurrency respects the compositionality principle, which states that any set of parallel connected activities may be seen as a single activity at a higher abstraction level. An immediate consequence is that a chain of communications between concurrent components should be fully homogeneous to a single communication between the ends of the chain. For instance, this is why Internet routing is far superior to older manual or pre-calculated routing. Since time adds up when communications are chained, this means that t + t should be homogeneous to t, where t is any sensible notion of communication time. To solve this “homogeneity equation”, there are only three possibilities: • t arbitrary, which is called asynchrony; • t = 0, which is called synchrony; • t predictable, which we call vibration. This characterization is equally meaningful in computer science and in physics, as we now demonstrate by individually detailing the three solutions. 2.1.1. Asynchrony Asynchrony, i.e., communication with arbitrary delay, may be viewed as the base of chemistry: two distant ions H + and Cl− floating in a chemical soup and wanting to marry into an HCl molecule may meet thanks to Brownian motion, but only after an unpredictable amount of time. Asynchrony is also the base of the Internet: routers implement a kind of Brownian motion for packets, and routing optimization is similar to the use of catalysts in chemistry to help ions meet. Asynchronous computing is usually non-deterministic and formalized using concurrent calculi [1] or abstract machines such as the Chemical Abstract Machine or CHAM [2]. The Erathostenes-Darwin CHAM sieve due to Banâtre and Le Métayer [3] is pictured in Figure 3, where each fish is allowed to eat its multiples. Only prime-numbers bearing fishes remain alive. Notice the highly parallel character of the sieve: 4 may eat 28 before 7, and before being itself eaten by 2. Furthermore, one may use several fishes for each number, as for the many 7 sharks in Figure 3.

48


Figure 3. The Eratosthenes-Darwin asynchronous sieve.

Figure 4. Sun, Earth, and Moon, a synchronous system.

Not all asynchonous computational models are behaviorally non-deterministic. The Kahn networks model [47,48] has non-deterministic execution but deterministic input / output function. We will study it in Section 4.3, since it is a precursor to synchronous programming. 2.1.2. Synchrony Synchrony is information propagation and communication in zero time. In physics, a good example is Newtonian mechanics, see Figure 4. Planets in the sky may be viewed as parallel objects constantly broadcasting their position and mass, and constantly computing where to go from the information received from others. Even with a very large number of parallel components (say stars), the system is fully deterministic, and the model makes it possible to perform very precise computations of behaviors. For embedded systems design, synchrony is an excellent paradigm: it is deterministic, based on cooperation instead of competition, and scales well. Thus, it will serve us


49

Figure 5. A synchronous circuit.

as the basic framework for the design and semantics of synchronous languages and applications. However, synchrony is not directly implementable in computers. This is why we need the third model below. 2.1.3. Vibration Vibration is propagation of information in predictable time. In physics, it corresponds to the propagation of light, sound, waves, electricity, etc. In computer science, it corresponds to propagation of electricity in circuit wires, or of the program counter in a program. The behavior of a vibration system can be fully deterministic as for waves or light (in classical optics). It can also involve some amount of non-determinism as for electricity propagation in a circuit under varying temperature, or propagation of program counter in modern microprocessors with caches and speculation. What shall really matter for us is the availability of upper bounds of propagation times, which do exist and are computable in all cases of interest. 2.2. Why Synchrony and Vibration Fit Together Consider a person speaking in a room. Since sound propagates at finite speed, say 340 m/s, it takes some time for the speech to reach a given spectator. Since light travels much faster than sound, there is a constant shift between the vision of the lips and the reception of the sound they emit. However, in a normal room, nobody cares, since the shift is small enough not to be perceivable. In other words, spectators neglect the speed of sound and the speed of light and safely think that vision and sound reach them in zero time. This kind of synchrony is simply an abstraction of vibration that makes life simpler. The same does not hold when observing an airplane that travels above sound speed: one views the plane much before one hears it, because the “room size” is too big for the approximation to hold. Therefore, the match between synchrony and vibration depends on the size of the room. The design of synchronous systems is based on the same abstraction. If response to external events is fast enough, actual response time can be neglected and set to 0. Figure 5 shows the times models in this case. Logical time is represented by vertical lines

50


Figure 6. A synchronous circuit.

with no time shift. Physical time is represented by fat horizontal time lines. If there is no overlap between fat lines, there is no interference between instants, and the models are viewed as agreeing. Fortunately, comparatively small rooms are very frequent in embedded systems. With the synchronous abstraction, designing programs and reasoning about them becomes much simpler than with a more exact vibration-based model. In computing as in physics, it is essential to remember that a conceptual model should not be perfectly exact, but as simple as possible and just exact enough to match the phenomena of interest. One uses Newtonian mechanics to control cars, rockets, and satellites, not general relativity. However, for clock synchronization in the GPS systems, this is a much more specific problem, general relativity is actually needed. Most engineering problems are nicely solved by simple models. 2.3. Synchronous Circuits The synchronous model is standard in circuit design, where it is called the RTL (Register Transfer Level) model. A synchronous circuit is pictured in Figure 6. It is composed of combinational and, or, and not gates, and of sequential registers, pictured as square boxes. The behavior is cyclic and driven by a clock connected to the registers. The electrical vibration behavior is as follows. Wire voltages may switch from 0 to 1 (Volt) and conversely. Registers have a constant 0/1 output during each clock cycle. At the beginning of the clock cycle, one sets each inputs to either 0 or 1, and one keeps inputs fixed for the whole cycle. Then, the gate output wires switch according to the gates inputs in a way that depends on the gate and wire delays. Since inputs are constant and the combinational gates form an acyclic circuit, all wires reach a stable state in a bounded amount of time. The bound can be precisely computed from the gates and wire characteristics. When the clock edge occurs, it triggers the registers that make their current input become their stable output for the next cycle. This makes the circuit ready to process new data in the next cycle. The “size of the room” requirement is that the clock period should be longer than the maximum stabilization time; the correponding complex technical calculation process is called timing closure. The logical synchronous behavior is as follows. The circuit is equivalently represented by the system of equations pictured below the circuit graph in Figure 6. At each


51

Figure 7. Cycle-based software.

Figure 8. Cycle fusion.

logical cycle, given the input values and register states, the system of equations has exactly one solution because of acyclicity of variable dependencies. The behavior is this solution, assumed to be computed in zero time. Solving Boolean equations is obviously simpler and much more flexible than computing complex propagation times. If the room is small enough, that is, if the clock is slow enough, the electrical vibration behavior is identical to the synchronous logical behavior. As for Newtonian mechanics, the physical or logical gates work in parallel but with fully deterministic behavior. Because of this wonderful physical property, circuit design is divided into two relatively distinct steps. For functional design and verification, one reasons in zero delay, which is much simpler than reasoning with propagation delays. Then, one uses sophisticated backend tools to optimized the logic and implement it in a given electronic technology, accurately computing the corresponding maximal clock speed. This separation of concerns makes design scalability and verifiability much better. Of course, not meeting timing constraints may require redesign of the logic, for instance by adding pipelining. This is the art of micro-architecture. The synchronous Esterel circuit design flow we have developed for circuits will be studied further in Section 5.2.2. Controlled asynchrony may be added to basic synchrony by using multiple clocks, which are available for Esterel but will not be detailed here. 2.4. Cycle-based Synchronous Software The synchronous model is also an informal Folk model in industrial systems design, where it is often spontaneously used by engineers to program micro-controllers or PLCs (Programmable Logic Controllers). The idea is to rely on cyclic computations, where each cycle consists in three successive phases pictured in Figure 7: reading the inputs,

52


computing the outputs and next state, producing the outputs. The cycle can be driven by timers or by external events. For instance, in a flight control or automotive breaking application, a typical cycle frequency is 100 Hz. In a human-machine interface, the cycle may be driven by button depressing or by the elapse of timers. Two computations are viewed as synchronous if they occur in the same cycle. The size of the room is determined by the worst-case computation time (WCET) of a cycle, which can be estimated by tests, or, preferably, upper-approximated by appropriate tools as for circuits [2,20]. Concurrency may be also supported, using cycle fusion pictured in Figure 8. Two cycles are pictured on the top of the figure. The left cycle inputs X from the environment and outputs T to the environment; it also outputs Y to the right cycle and inputs Z from it. The right cycle inputs Y from the left cycle and outputs back Z. Running the cycles in lockstep parallel amounts to running the single bottom cycle, in which the statements of the right cycle have been incorporated at the right place into the statements of the left cycle. In this way, the code achieves conceptual parallelism by remaining strictly sequential. The algorithm needed to perform cycle fusion is essentially topological sorting over variable dependencies. The cycle-based approach is popular among control engineers because it ensures behavioral determinism in a very simple way. The strict alternation of input/output and calculation activities avoids the main pitfall of communicating task based systems, namely the interference between them that generates unwanted non-determinism. It also avoids the high run-time overhead of context switching, since programs are single-threaded.

3. A Short History of Synchrony Synchronous languages were born in 1983 with Esterel [18], originally developed for robotic applications. Soon after, the Lustre [42] and Signal [41] data-flow languages were born. These three languages were developed by teams gathering computer scientists and control theorists, and they shared the same basic idea and semantics framework. The languages mathematical semantics were developed together with the languages [11], and research compilers based on these semantics readily followed. These compilers evolved with the progress in semantics definitions [14,9]. At about the same time, D. Harel developed Statecharts [45], a breakthrough visual formalism for hierarchical state machine design, similar in intent and applications, but with somewhat different semantics. Application started in the mid-80’s. Synchronous languages were experimented in a number of different fields in research or industry: telecommunication protocols [13,53, 46], networking [29,28], avionics [16], robotics [37,33], graphical user interface [30], automotive, etc. In the beginning of the 90’s, several commercial tools were developed for Esterel, Lustre, and Signal: AGEL for Esterel by Cisi Ingéniérie and ILOG, SAGA [7] based on a graphical version of Lustre by Merlin Gerin (later Schneider Electric) for nuclear plant safety systems, and Sildex based on Signal by TNI for control applications such as airplane engine control or power distribution control. At the end of the 90’s, SIMULOG developed the Esterel Studio tool, which incorporated the SyncCharts [3] synchronous variant of Statecharts by C. André, itself an improvement over Maraninchi’s ARGOS [51] synchronous visual formalism. Esterel Studio was taken over by Esterel Technologies in 2000.


53

In the early 90’s, Esterel was adapted to generate hardware in addition to C programs [8], and new hardware sequential optimization techniques were developed for it [65,59,60]. In 1999, in cooperation with Intel, the Esterel language was extended to support full data path design [17,10], with powerful features such as automatic data path sizing. Multiclock support was added in 2005. The new Esterel v7 language is currently submitted to IEEE standardization. Together with its SSM hierarchical state machines (see 4.2), it is now supported by the Esterel Studio tool and used in production for complex control circuits. Hardware generation also made it possible to translate Esterel programs into input languages for the nascent BDD-based verification systems [34]. Formal verification of non-trivial properties of large FSM-based avionics systems was performed throughout the 90’s at Dassault Aviation [16] and elsewhere. Esterel Studio verification was later enhanced by using the Prover SL SAT-based sequential verification engine (http://www.prover.com/products/prover_plugin/). Formal verification technology was also developed for Lustre [43] and Signal [52]. In the late 90’s, SCADE was chosen by Airbus to develop flight control and other critical software for new airplanes. The A380 superjumbo is mostly flying SCADE code (for flight control, engine control, braking and steering control, and many other critical applications), with several millions lines of code automatically generated from formal descriptions. Esterel Technologies acquired SCADE in 2003. SCADE and Esterel Studio were coupled in 2004, until being both replaced for embedded software by the new Scade 6 language and development environment [31]. Scade 6 took benefit of the definition of mode automata by Maraninchi and Rémond [50]; it is further detailed in Section 4.5.2. SCADE is now widely used in avionics and other safety critical applications: railways, heavy industry, automotive, etc. In the mean time, other researchers developed alternative synchronous languages and compilers to software or hardware. See for instance Boussinot [21], Boussinot and de Simone [22], Edwards [36], Saraswat [55], Closse, Pulou and Weil [66], Caspi and Pouzet [26], Schneider [56,57,23], etc. Esterel and Lustre have also been used at UC Berkeley for the Ptolemy system [25] and the Polis codesign system [5]. Research has also focused on aspects which will be only briefly studied here, such as causality [61,24,1], mixed hardware / software execution of Esterel programs [38], distribution of synchronous programs on distributed architectures [40,19], and, more generally, linking synchrony and asynchrony [27].

4. Synchronous Languages This section surveys the Esterel and Scade languages and graphical formalisms. The associated tools and flows will be presented in Section 5. 4.1. A Look At Esterel We explain how Esterel helps programming complex control by a simple example. We will not explain the Esterel v7 data path constructs here, see the language documentation for details (available at www.esterel-eda.com).

54


4.1.1. The Runner The most typical and useful Esterel program is the following runner controller: module Runner : input Morning, Meter, Step, Second, Lap; every Morning do abort loop abort run Slowly when 100 Meter; abort every Step do run Jump || run Breathe end every when 15 Second; run FullSpeed each Lap when 4 Lap end every end module

It is assumed that the program execution is driven by an external cycle trigger, which can be a hardware clock, a timer, an event loop, or any other device. The Morning, Meter, Step, Lap, and Second identifiers denote input signals that are either true or false at each cycle. The run keyword starts a submodule that runs until own termination or abortion. Here, the submodules are Slowly, Jump, Breathe, and FullSpeed, which have non-terminating behavior; they are assumed to be written in Esterel and will not be detailed. Semicolon ‘;’ is used for sequencing behaviors, parallelism ’||’ for executing behaviors in parallel. The program does exactly what it says. It is executed every morning, and consists of four identical laps. Each lap normally consists in running slowly for exactly 100 meters, then jumping and breathing in parallel for exactly 15 seconds, then running full speed exactly until the end of the lap. The key behavior control statements are the abortion statements abort, every, and loop-each. These statements immediately abort their body when their guards elapse; abort-when then passes control in sequence, while every and loop-each immediately restart their body afresh.The difference between the every and loop-each loops is that every initially waits for the guard to be true to start its body, while loop-each starts it immediately. Abortion statements are very strict: if the lap is shorter than 100 meters, one only runs slowly. If the lap is shorter than 100 meters plus 15 seconds, one never runs full speed, but restarts running slowly again. For all statements, control passing and guard evaluation is immediate. The semantics is as simple as it can be, and administration is infinitely fast, a consumer’s dream! 4.1.2. The Older Runner Since the author is getting older every year, he now needs to watch his heart during the most strenuous part of the day, the jumping phase. Here is the modified program:


55

signal HeartAttack in // new weak abort // when HeartAttack, new every Morning do abort loop abort run Slowly when 100 Meter; abort every Step do run Jump || run Breathe || run CheckHeart // new, may emit HeartAttack end every when 15 Second; run FullSpeed each Lap when 4 Lap end every when HeartAttack do // new run RushToHospital // new end abort end signal

We add a call to a CheckHeart module that outputs a signal HeartAttack if a heart problem is diagnosed. Emitting this signal provokes instantaneous self-abortion of the external weak abort statement. In turn, this implies instantaneous abortion of the whole “every Morning” behavior, including the concurrent Jump and Breathe modules, and immediate execution of the RushToHospital module. Notice that such instantaneous mandatory abortion of concurrent modules could not be programmed with asynchronous signalling techniques. Nested abortion structure are also very hard to program in conventional sequential languages, where the scheduling of all activities must be done by hand. 4.1.3. Causality Loops In the older runner code, we wrote weak abort instead of abort for abortion by HeartAttack. We now explain the difference between these two abortion statements. In “abort p when g”, the body statement p is not executed when g becomes true, i.e., at abortion time. On the contrary, in “weak abort p when g”, the body statement p is executed for a last cycle when g becomes true. In our example, weak abort is needed to deal with HeartAttack, since this signal is emitted by the body itself (here, the CheckHeart submodule). Using abort would provoke a self-contradiction called a causality loop: HeartAttack true would provoke non-execution of the body, hence of the very statement that emits HeartAttack. Such causality loops are unsound and are rejected by the semantics and compiler, unlike asynchronous deadlocks, which manifest themselves only at run time. 4.1.4. Esterel Semantics and Compiling The Esterel semantics is given in Plotkin’s Structural Operational Semantics (SOS) style, i.e., in the form of recursive logical rules that define the behavior of statements in given contexts [9,15]. There are several levels of semantics:

56


• The logical semantics defines the zero-delay synchronous behavior in the most direct way, ignoring causality loops. The original version of [14,9] has been later improved by Potop [54] and Tardieu [62,63]. • The state semantics [9] improves over the logical semantics by making the notion of state more explicit and proving that Esterel programs are finite-state for control. • The constructive semantics [9] yields a precise study of signal and control dependencies and of causality issues. • The operational semantics [54] yields a detailed analysis of program execution. • Finally, the circuit semantics [9] expresses how to translate Esterel programs into synchronous circuits. All these semantics present different point of views on the very same object, for different needs: specification, software implementation, hardware implementation, etc. But they are all consistent: the behavior of a program is the same in all of them, except for causality issues; some semantics may reject programs as non-causal, while these programs are accepted by other semantics that use more tolerant correctness criteria. For instance, the constructive circuit semantics may accept electrically correct but combinationally cyclic circuits that cannot be processed by circuit synthesis backend tools, and, therefore, cannot be used in production. Practical circuit generation must use topological graph acyclicity constraints instead of finer logical constructiveness constraints (see [9,61,58]). Another point where semantics may slightly differ is the handling of program schizophrenia due to multiple executions of the same instruction in the same instant. This problem is too technical to be exposed here but easier to practically solve than causality, see [9,54,64] for details. Here again, when a program is accepted by two semantics, it has exactly the same behavior in both. Many different compiling techniques for Esterel have been developed, each directly based on one of the mathematical semantics, see [54]. They may compile an Esterel program into either a synchronous circuit (in Verilog or VHDL) or a software program (in C, C++, SystemC, etc.), with exactly the same behavior, but with various efficiency tradeoffs. Each compilation technique is better adapted to a particular form of hardware or software execution. Esterel-specific research hardware processors have also been developed [38]. 4.2. A Quick Look at SyncCharts and SSMs SyncCharts [3] are an hybrid between Statecharts [45] and Esterel: restricting over the graphical constructs of Statecharts make them fully synchronous in the sense of Esterel. Safe State Machines (SSMs) are the version of SyncCharts used by the SCADE Suite and Esterel Studio tools, see Sections 5.1 and 5.2. Their key elements are Esterellike sequencing, concurrency, and strong and weak abortion transitions, coupled with Statecharts-like nested states hierarchy. We present a SSM classic example called ABRO. There are three inputs, A, B, and R, and one output O. Inputs may be simultaneous. The output O should be immediately emitted once when the last of A and B occurs, and the behavior should be (strongly) reset when R occurs. Reset by R should occur at any time, irrespective of A and B signals received so far, and A and B should be ignored if R is true.


57

Figure 9. The ABRO flat state machine.

Instances of the ABRO example are very frequent in actual designs: for instance, think of A as address, B as data, O as memory write, and R as new write command with abortion of the previous one if not yet completed. The usual way of coding ABRO is by the flat state machine pictured in Figure 9. There are obvious drawbacks: each signal appears several times, and priority specification remains loose. While priority may be easily specified by numbering the transitions out of each state, the first drawback is fundamental: flat state machine coding is essentially transition cut-and-paste; any change in the specification will provoke a number of changes in the code, with a high risk of forgetting some. Adding a C input signal to A and B will lead to a cube instead of a square, and, more generally, dealing with n inputs will lead to a state machine with 2n states, which is unacceptable. Esterel and SSMs provide the user with a much simpler solution, based on behavior factoring. The ABRO SSM is pictured in Figure 10. It consists in a toplevel state with a R-labelled arrow to perform reset. Inside this toplevel state, one finds two states: the WaitLast_A_B state waits for the last of A and B and terminates, while the Wait state waits forever until being aborted by some outer transition. The WaitLast_A_B state is itself recursively decomposed into two parallel SSMs, repectively waiting for A and B; synchronous parallelism is indicated by the vertical dotted line separating these two machines. The double-circled states in each of the A and B machines indicate local termination, and the triangle on the arrow out of the machine pair indicates that the transition trigger is the parallel termination of the enclosing parallel state. As for Esterel, a pair of concurrent machines terminates exactly at the time the last of them terminates. The detailed behavior is as follows: • At start time, the initial transitions are recursively taken at each level, which places the state machine in the WaitA wait state on the left and in the WaitB wait state on the right. Call WaitAB this compound global state. (Note that WaitAB is different from WaitLast_A_B, which is a state container and not a run-time state by itself. Only leaf states with no internal structure such as WaitA and WaitB contribute to run-time states.) • At next instant, if R is true, the external R arrow is taken without executing the inner state machine and the state is reset to WaitAB. The little circle at start of

58


Figure 10. The ABRO SSM.

the R arrow tells that abortion by R is strong, hence that the inner state machine should not be executed; thus R takes priority over A and B as requested, these signals being simply ignored if true. • If, instead, R is false, there are four subcases: ∗ If A and B are both false, no transition is taken and the machine stays in compound state WaitAB. ∗ If A and B are both true, both internal state machines take their transition and simultaneously reach termination. Their synchronous parallel product immediately terminates, the parallel termination transition that emits O is taken, and its target Wait state is entered and becomes the global run-time state. At subsequent instants, nothing will happen until R is true, which will put the global machine back in compound state WaitAB; in particular, A and B will be ignored while waiting for R. ∗ If only A is true, the left machine terminates and the global machines ends in the WaitB state. From then on, an R will reset the global machine to WaitAB, while a B without R will provoke emission of O and entering of the Wait state as before. ∗ If only B is true, the behavior is symmetrical. Thus, the behavior is exactly the same as that of the flat machine. The key difference between the flat and hierarchical state machines is linear vs. exponential growth: in the SSM, each signal appears only once. Adding another input C simply consists in adding a third parallel component for C in the inner concurrent state, which keeps the design linear in size. The same behavior is equivalently defined by the following Esterel textual program:


59

module ABRO : input A, B, R; output O; loop { await A || await B }; emit O each R end module

where “await A ” waits for A and terminates. The Esterel Studio tool actually translates the graphical ABRO SSM into this textual program. Consider now a variant of ABRO where R does not take priority over A and B; in that case, O should be emitted if the machine receives A, B, and R in state WaitAB, with new state WaitAB instead of Wait because of R, and the same should hold when the main machine is in the WaitA or WaitB global states. Updating the flat machine involves changing the label on three arrows. Updating the Esterel program simply amounts to changing abort into weak abort, and updating the SSM simply amounts to removing the little circle at the start of the transition to make it weak, as pictured in Figure 11. 4.3. Data-Flow Kahn Networks Data flow networks were introduced in the early 1970’s, and were among the first truly cooperative parallel computation models. Kahn networks [47,48] are of particular importance, since they were the first concurrency model to receive a beautiful mathematical semantics. A Kahn network is pictured in Figure 12. It is composed of nodes linked

Figure 11. The weak ABRO SSM

60


Figure 12. A Kahn network.

by communication channels. Each node is a deterministic sequential program (later extended into the more general notion of a sequential algorithm, see [12]). A node repeatedly reads input data items from input channels and write output data items to output channels, where each channel is an unbounded fifo queue. Read is blocking and write is non-blocking: each node waits for all the input items it needs to perform its computation, and writes output items at will; being unbounded, an output channel is never full. All nodes can be executed in parallel and asynchronously when enabled by their inputs. The mathematical semantics consists in associating an infinite sequence of values or flow with each channel. A network then becomes a system of flow equations, and the main theorem is that any network has a unique solution given the input flows. Thus, Kahn networks are both asynchronous and deterministic. Kahn networks are widely used in computer applications, in particular for audio and video streaming. Of course, there is a practical problem: one cannot really implement unbounded fifos. Unfortunately, the model is not very resistant to change. For example, allowing the nodes to test input fifo emptiness breaks determinism. Fortunately, there are good restrictions that make Kahn networks synchronous. One of them is balance equations used for synchronous dataflow in the Ptolemy systems [25,49]. The other one is used in the Lustre synchronous language described in Section 4.4 below. See also [32] for the recent N-synchronous Kahn networks. 4.4. A Quick Look at Lustre Lustre [42] is a particularly simple and elegant functional synchronous language. It is based on the same nodes and flows idea as Kahn networks, but with a set of primitives that guarantees synchrony [26]. 4.4.1. Flow Equations Consider a cycle counter that increments its output integer value at each cycle and resets the count to 0 each time an input R is present. The mathematical definition is as follows, using indices to number cycles: Count0 = 0 0 if R Countn+1 = Countn + 1 otherwise This definition is fine for a mathematician, but not quite for a software engineer: the rules of what is allowed for indices are implicit, if not fuzzy. Lustre makes the writing precise by removing indices and viewing a variable as denoting the infinite flow of values it takes over time, as for Kahn networks. The main change compared to Kahn networks is to use memory-free synchronous communication between nodes instead of unbounded buffers.


61

Specifications are written using simple temporal primitives acting on flows. The Lustre code for the counter is as follows: node Counter (R : bool) returns (Count: int) let Count = 0 -> if R then 0 else pre(Count)+1; tel;

Here are the definitions of the involved operators. Let X = X0 , X1 , . . . , Xn , . . . and Y = Y0 , Y1 , . . . , Yn , . . . be two flows. • The 0 constant is extended to the 0, 0, . . . , 0, . . . infinite flow. • The X->Y operator performs initialization by X and continuation by Y , i.e., returns the flow X0 , Y1 , . . . , Yn , . . . • The pre operator shifts a flow by one cycle, i.e. returns at each instant the previous value of its argument: pre(X)= nil, X0 , X1 , . . . , Xn , where nil is the undefined value. • Addition of two flows operates pointwise: (X + Y )n = Xn + Yn . • The if-then-else operator also operates pointwise, selecting the n-th value of X or Y according to the n-th value of C. Then, the value of Count is defined as the unique flow that satisfies its definition equation. We leave it to the reader to see that this solution is unique and is indeed the intended flow. More generally, one can define several flows by a system of possibly recursive equations; then, their value is given by the unique solution of the system of equations. Existence and uniqueness are guaranteed by the classical additional condition that any dependency cycle from a variable to itself is cut by a pre delay operator. Finer causality characterizations could be made available as for Esterel, but they have never been used for Lustre. The beauty of Lustre is that ‘=’ really means equal, which is unfortunately uncommon in programming languages. This makes it possible to substitute any variable by its definition at any place. 4.4.2. Hierarchical Lustre nodes One can build hierarchical networks of nodes, using a node as a function in any expression. For example, if one wants to perform the same count with reset when R1 or R2, one simply writes the following: node CounterWithTwoResets (R1 : bool, R2 : bool) returns (Count : int) let Z = Counter (R1 or R2) tel;

Lustre node call is much more than a usual function call since the called Counter node has an internal memory.

62


Figure 13. Clocks in Lustre.

Figure 14. The Scade cycle counter.

4.4.3. Lustre Clocks Lustre can deal with sub-cycles of the main cycle to undersample events and perform variable-rate computations, which is mandatory for efficient CC computations. A clock is a Boolean signal; the undersampling “X when C ” of a flow X by a clock C is the sequence of values taken by X when C is true. The Lustre clock calculus checks that operations are performed only when flows have the same clock. See Figure 13 for the impact of clocks on flow values.


63

Figure 15. The Scade 5 cruise control.

4.5. A Quick Look at the Scade languages 4.5.1. Scade as Graphical Lustre The original Scade graphical formalism was created as a graphical version of Lustre, using block diagram drawings more familiar to control engineers than textual specifications. The Scade specification of the tick counter is pictured in Figure 14. It uses a fby operator, where fby(X,n,Y) is Y0 , Y1 , . . . , Yn−1 , X0 , X1 , . . . , Xn , . . .. Before being replaced by Scade 6, the later Scade 5 generation used two kinds of diagrams: data-flow diagrams, already described with Lustre, and SSM diagrams, already described in Section 4.2. A Scade 5 cruise control example is pictured in Figure 15. Two diagrams appear in two windows. The data-flow diagram defines the continuous control (CC) algorithms; it is itself recursive, but its sub-diagrams are not shown here. The SSMs describes the cruise control modes. The CC and SSM diagrams communicate by exchanging Boolean signals. The Esterel compiler is used to translate SSMs into Scade. Thus, Scade 5 can be considered as a superposition of a language and a tool for CC and another language and another tool for FSM. The superposition was smooth because Esterel and Lustre share the very same synchronous approach. 4.5.2. The Scade 6 CC+FSM Unification The new Scade 6 generation completely unifies CC and FSM styles, by allowing the two kinds of diagrams to coexist. The Scade 6 cruise control is pictured in Figure 16. States

64


Figure 16. The Scade 6 unified cruise control.

Figure 17. A Scade 6 display controller.

of SSMs can now contain either other SSMs or data-flow diagrams, and conversely. To avoid flow definition constructs that are accepted by Esterel but would not fit certification constraints, Scade 6 imposes simple restrictions on SSMs to ensure that a flow is never computed by more than one state at a time. In the example of Figure 16, the SSMs are relatively simple. They control the different cruise control modes, which correspond to states containing different CC diagrams. In other examples such as display control, SSMs can be very large with comparatively little CC components. Figure 17 shows a display controller with more SSM than CC; the display graphics are themselves programmed with the SCADE Display tool.


65

Scade 6 also improves over Scade 5 by supporting functional arrays and static code replication directives, which greatly simplify the design of complex CC or FSM components without sacrificing semantics clarity. In addition to SSMs, Scade 6 also supports activation conditions to control the activation of CC components; they correspond to Lustre clocks but are easier to use. Finally, the Scade 6 cruise control uses initial states instead of initial transitions, a technical detail. See [31] and the Scade 6 documentation for these more technical aspects. 4.5.3. The KCG Certified Code Generator The KCG code generator translates Scade designs into C programs. It is written in CAML, and has itself been shown certifiable by avionics authorities according to the highest level A of the DO-178B avionics norm. This has major impact on industrial development flows, as will be explained in Section 5.1.2. (The SCADE Display graphics compiler is also certifiable at level A.) KCG works by a succession of formal transformations: parsing the design into an abstract syntax tree, typing and polymorphism resolution, translation from SSMs states and transitions to dataflow equations, static analysis for absence of access to undefined values, allocation of variables, optimization, C generation. In addition, KCG checks that all flows are used and that there is no dead code, which is essential for certified applications. The code generator generates very simple C code: the code is purely sequential, memory allocation is static, there is no pointer arithmetic, etc. These properties greatly facilitate static analysis, such as worst-case execution time analysis or verification of the absence of arithmetic faults.

5. Industrial Flows Industrial development of systems is about dealing with large and complex development flows, not just a series of point tools. The flows range from specification to embedded hardware and software, with extensive verification of all steps. Any tool that is not properly integrated in the flow is useless. We discuss two synchronous flows, the SCADE DO-178B flow for certified software development and the Esterel-based System on Chips flow for electronic circuits design. 5.1. The SCADE Embedded Software Flow 5.1.1. DO-178B Constraints The DO-178B embedded software design flow for software avionics is pictured in Figure 18. This flow is mandatory for airborne commercial software; it is becoming mandatory for many defense programs as well. A key point is that certification is performed by external authorities, not just internally by the manufacturer. Similar flows are now put in place for railway and heavy industry software development. The software flow lies between the systems requirement flow and the integration flow. Certification involves extensive specification, code, and test reviews. There are four levels of safety, A, B, C, and D, with A the highest. We consider level A here. The flow must obey the following constraints:

66


Figure 18. The DO-178B software flow.

• Extensive code reviews. • Full documentation of all steps and codes. • Full traceability: all code elements and tests should be linked to specificationlevel requirements, and why the code satisfy the requirements should be explained in the documentation. • Full verifiability: tests should realize complete coverage of the code and requirements. At level A, one requires verification of Multiple Condition Decision Coverage (MCDC) for the code, which means thorough and systematic analysis of Boolean condition tests. The completeness of the verification process should be itself verified, by an essential activity called verification of verification. The norm does not enforce any particular method to achieve these goals. In particular, it does not yet mention modern software engineering techniques such as model-based design, component-based design, worst-case timing analysis, or formal verification. These shall be included in the new norm DO-178C to appear in the next few years. 5.1.2. The SCADE Ecosystem The SCADE ecosystem that drives the SCADE flow is pictured in Figure 19. The three middle columns present the three major activities of SCADE design: • Design capture, using the SCADE editor for behavior definition using the Scade 6 language and graphics, and the SCADE Display editor for the design of complex displays. • Design verification, using a variety of integrated tools: an interactive simulator, to visualize program execution; a Model Test Checker (MTC), to compute advanced


67

Figure 19. The SCADE ecosystem.

Scade coverage measurements; a formal verifier (model-checker), to prove properties of Scade programs; several other tools to perform additional model and generated code verification, including a worst-case execution time (WCET) analyzer by AbsInt [2]. • Target code generation, using the KCG certifiable code generator, linked with wrappers to efficiently and safely embed the generated code within Real-Time Operating Systems (RTOS). The link with system-level specification is on the left of Figure 19. Systems may be specified by textual documents, by prototypes developed within mathematical simulation systems, or by architectural specification formalized in UML or SysML. Several gateways make it possible to import such specifications in SCADE, and several links with requirement traceability tools make it possible to trace the Scade code back to system specifications and requirements. The link with system integration and test is on the right of Figure 19. The KCG compiler generates code in ANSI C, and ADA generation will be made available. Target code is not the only generated object. It is accompanied with automatically generated documentation and with a qualification kit, meant for the user to demonstrate the quality of the design to the certification authorities. An additional Compiler Verification Kit (CVK) is used to test that the target C compiler correctly compiles the code patterns generated by KCG. Finally, the bottom part of Figure 19 details the management and traceability tools involved throughout the process. Version and configuration management is of course indispensable for safety-critical designs. It is performed by external tools using a generic interface. The same holds for requirement traceability management.

68


Figure 20. The System on Chips flow.

The key differentiator of the SCADE flow is that the KCG compiler has been itself certified at level A of the DO-178B norm. There is a very important consequence for the user: since the compiler is itself certified, the certification authorities accept that there is no need to verify and unit-test the generated C code. This has a major positive impact on the whole software initial and incremental certification, since all technical justifications may be given at Scade source level, i.e., at a level that is very close to that of the original mathematical specification. Furthermore, integration tests are made easier by the simplicity of the generated C code. 5.2. The Esterel SoC Flow Esterel is particularly well-adapted to control-complex hardware designs, such as protocols (USB, SATA, etc.), on-chip networks, memory access and management systems, caches, etc. We present the standard circuit design flow and how Esterel modifies and shortens this flow. 5.2.1. The Standard SoC Flow The standard SoC hardware development flow is pictured in Figure 20. It has four main levels: • Architecture. The flow starts by the definition of the overall SoC architecture from the circuit marketing specifications. Architects are special cooks who work with


69

ingredients such as processors, DSPs, accelerators, etc, make pictures on blackboards and drawing systems, compute information throughputs and latencies using spreadsheet tools, etc. Then, they give hand to micro-architects, who design pipelines, bus and memory systems, protocols, generic and specific processors, etc. • Design and Verification. Architectural and micro-architectural specifications are passed to designers, who code the design using hardware description languages such as Verilog or VHDL. Coding is mostly done in the RTL style (see 2.3), possibly using several clock zones for power efficiency. The designs are checked by simulation using manually written or random-directed tests, or by formal verification for critical safety properties. • Backend. Testability logic is inserted to ensure that fabrication faults will be detected with a very high probability. The RTL design is synthesized into gates using a logic synthesizer (the nickname of a compiler in the hardware community). Then, the gates are placed and routed and clock trees are built. Finally, the fabrication masks plans are built. These phases are mostly automatic and use very sophisticated and expensive tools, as well as a lot of CPU time. Nowadays, many of the backend steps are formally verified using sophisticated formal verification tools. • Fabrication. The masks and test suites are sent to the fab (nickname of a circuit factory). Once built, the circuits are functionally tested one by one, and the faulty units are put to garbage. The whole process is very heavy and expensive. The cost of bugs grows dramatically when the level gets down from architecture to fabrication and distribution. A bug found when the circuit is on the market may incur an enormous cost. Therefore, it is very important to find and correct all the bugs as soon as possible. A particularly difficult transition is the one between design and backend, because masks cost millions of dollars. There is one special day called the RTL signoff day. From then on, it is considered impossible to reprocess the whole design. The only possible changes are called ECOs, for Engineering Change Orders. They consist in patching the circuit, putting additional gates in spare room intentionally left for that, and performing minimal rewiring. The correctness of such patches should be guaranteed at the highest possible level, since an ECO cycle is long and expensive. In addition to this circuit-production oriented flow, it becomes necessary to deliver software models of the SoCs, in order for the software team to be able to write the application software before the circuit actually exists. Conformance between the actual circuit and the software model is a key problem; it is almost impossible to guarantee when manually developing a circuit on one hand and the software model on the other hand, often in different design groups. 5.2.2. The Esterel Studio Flow The Esterel Studio flow is presented in Figure 21. Its goal is threefold: • Raise the level of abstraction for complex control description. Esterel v7 and Esterel Studio provide the user with many design goodies such as direct behavioral programming using sequencing, concurrency, abortion, and hierarchical state ma-

70


Figure 21. The Esterel Studio ecosystem.

chines, automatic data path sizing, etc. Esterel Studio also makes it possible to define structural architectures in a graphical way. • Raise the level of verification, using simulation with behavioral animation of the source code, and performing formal verification of design very early in the flow. Local design bugs should not reach later integration verification. • Generate automatically consistent and efficient hardware and software models from a single source code, to avoid the aforementioned inconsistency pitfall. On top of Figure 21, we find design activities: structural architecture capture using either textual Esterel v7 specifications or graphical structure diagrams; behavior capture using textual Esterel v7 or hierarchical state machines; verification requirements capture using assertions or property observers, themselves specified in Esterel (which can also be viewed as a temporal logic for safety properties). On the right, we find debugging activities, including simulation with source code animation and Esterel-level formal verification. In the bottom part, we find RTL and software generation, which make the link with the circuit backend flow and with the application software development flow. On the left, we find automatic documentation activities. These are less elaborate than for SCADE since there is no certification process involved (there is a certification norm called DO-254 for airborne circuits, but Esterel Studio has not yet been used for such designs). Finally, Esterel Studio supports full traceability from source code to target code by a special browsing mode, which is indispensable to perform ECOs (late changes after RTL signoff) even on heavily optimized circuits [4].


71

5.2.3. Esterel Studio in the ESL Flow Circuit specifications are becoming so complex that architects cannot fully master them any more without early simulation, early what-if analysis, and early formal verification. Furthermore, software is also becoming so complex that software teams need to develop the software before the circuit that will run it actually exists. This is why a new approach called Electronic System Level design (ESL) is now put in place in industry. ESL tools operate in two main fields: fast simulation of large circuits using higher levels of abstraction, such as Transaction-Level Modeling (TLM) in SystemC [39], and synthesis of circuits from higher level specifications written in non-RTL languages such as C, Esterel, or Bluespec. ESL is bound to replace RTL in the middle term, just as RTL has replaced manual gate specification. It reduces the distance between architects and designers, speeds up design time, and makes it possible to exercise designs and catch bugs very early in the process. By generating automatically consistent hardware and software, Esterel is able to enter the two fields of ESL at the same time. By its ability to handle complex control paths, it is an ideal complement to C-based data path generation, which is very efficient for heavy computation but not for heavy control, in particular because C lacks explicit synchronous concurrency. For instance, in a typical video application, the video filters should be coded in C, and the memory and cache access logic should be coded in Esterel. This new kind of flow is currently being put in place in production by Esterel Studio customers.

6. Conclusion We have surveyed the synchronous design model for hardware and software embedded systems, the associated textual and graphical languages, and the synchronous industrial flows that are now in place for major applications. Synchronous languages and tools greatly simplify the design of systems, in particular by allowing control engineers to use formalisms that look familiar to them. Synchrony assumes that “the room is small enough”. This hypothesis will not hold forever. Research is now oriented towards dealing with “castles” instead of rooms. The challenge is to keep the nice properties of synchrony whenever possible, especially determinism, and to add asynchrony whenever mandatory. Multiclock hardware systems and GALS (Globally Asynchronous Locally Synchronous) systems are going this way. Our opinion is that one should deal with synchronous islands as long as possible, and carefully control asynchrony when several islands need to communicate. The ultimate goal is to build designs that are humanly understandable, practically efficient, and formally verifiable.

72


References [1] Joaquin Aguado and Michael Mendler. Constructive semantics for instantaneous reactions. In Proc. GALOP 2005, ETAPS, Edinburgh, pages 16–31, 2005. [2] M. Alt, C. Ferdinand, F. Martin, and R. Wilhelm. Cache behavior prediction by abstract interpretation. In Proc. SAS’96, Static Analysis Symposium, LNCS 1145, pages 52–66. Springer, 1996. [3] C. André. Representation and analysis of reactive behaviors: a synchronous approach. In Proc CESA’96, IEEE-SMC, Lille, France, 1996. [4] L. Arditi, G. Berry, and M. Kishinevsky. Late design changes (ECOs) for sequentially optimized esterel designs. In Proc. FMCAD’04, pages 128–143, 2004. [5] F. Balarin, M. Chiodo, P. Giusto, H. Hsieh, Jurecska A, L. Lavagno, C. Passerone, A. SangiovanniVincentelli, E. Sentovich, K. Suzuki, and B. Tabbara. Hardware-Software Co-Design of Embedded Systems: The Polis Approach. Kluwer Academic Press, 1997. [6] Albert Benveniste, Paul Caspi, Stephen A. Edwards, Nicolas Halbwachs, Paul Le Guernic, and Robert de Simone. The synchronous languages 12 years later. Proceedings of the IEEE, 91(1):64–83, January 2003. [7] J.L. Bergerand and E. Pilaud. Saga: a software development environment for dependability in automatic control. In Proc. Safecomp’88. Pergamon Press, 1988. [8] G. Berry. Esterel on hardware. Philosophical Transactions Royal Society of London A, 339:87–104, 1992. [9] G. Berry. The constructive semantics of Pure Esterel. Available at http://www.estereleda.com/downloads/papers.html/, 2000. [10] G. Berry. Circuit design and verication with esterel v7 and esterel studio. In High Level Design Validation and Test Workshop HLDVT’07, IEEE International, pages 133–136, 2007. [11] G. Berry and L. Cosserat. The synchronous programming languages Esterel and its mathematical semantics. In S. Brookes and G. Winskel, editors, Seminar on Concurrency, pages 389–448. Springer Verlag Lecture Notes in Computer Science 197, 1984. [12] G. Berry and P-L. Curien. Theory and practice of sequential algorithms: the kernel of the programming language CDS. In Algebraic Methods in Semantics, Cambridge University Press, pages 35–88, 1985. [13] G. Berry and G. Gonthier. Incremental development of an HDLC entity in Esterel. Comp. Networks and ISDN Systems, 22:35–49, 1991. [14] G. Berry and G. Gonthier. The Esterel synchronous programming language: Design, semantics, implementation. Science Of Computer Programming, 19(2):87–152, 1992. [15] Gérard Berry. The foundations of Esterel. In Proof, Language and Interaction: Essays in Honour of Robin Milner. MIT Press, 2000. [16] Gérard Berry, Amar Bouali, Xavier Fornari, Emmanuel Ledinot, Eric Nassor, and Robert de Simone. Esterel: a formal method applied to avionic software development. Science of Computer Programming, 36:5–25, 2000. [17] Gérard Berry, Michael Kishinevsky, and Satnam Singh. System level design and verification using a synchronous language. In Proc. ICCAD 2003, pages 433–440, 2003. [18] Gérard Berry, Sabine Moisan, and Jean-Paul Rigault. Esterel: Towards a synchronous and semantically sound high-level language for real-time applications. In Proc. IEEE Real-Time Systems Symposium, Arlington, Virginia, IEEE Catalog 83CH1941-4, pages 30–40, 1983. [19] Darek Biernacki, Jean-Louis Colaco, Grégoire Hamon, and Marc Pouzet. Clock-directed Modular Code Generation of Synchronous Data-flow Languages. In ACM International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES), Tucson, Arizona, June 2008. [20] Marian Boldt, Claus Traulsen, and Reinhard von Hanxleden. Worst case reaction time analysis of concurrent reactive programs. Electron. Notes Theor. Comput. Sci., 203(4):65–79, 2008. [21] F. Boussinot. Reactive C: An extension of C to program reactive systems. Software Practice and Experience, 21(4):401–428, 1991. [22] F. Boussinot and R. de Simone. The SL synchronous language. Research Report 2510, INRIA, 1995. [23] J. Brandt and K. Schneider. Advances in Design and Specification Languages for Embedded Systems, chapter Different Kinds of System Descriptions as Synchronous Programs. S.A. Huss ed., Springer, 2007. [24] J. Brandt and K. Schneider. Formal reasoning about causality analysis. In S. Tahar and C. Munoz, editors, Theorem Proving in Higher Order Logic (TPHOL), LNCS, Montreal, Canada, 2008. Springer.


73

[25] Joseph Buck, Soonhoi Ha, Edward A. Lee, and David G. Messerschmitt. Ptolemy: a framework for simulating and prototyping heterogeneous systems, pages 527–543. Kluwer Academic Publishers, Norwell, MA, USA, 2002. [26] P. Caspi and M. Pouzet. Synchronous Kahn networks. In Proceedings of the first ACM SIGPLAN international conference on Functional programming, Philadelphia, USA, pages 226–238, 1996. [27] P. Caspi, N. Scaife, Ch. Sofronis, and S. Tripakis. Semantics-preserving multitask implementation of synchronous programs. ACM Transactions on Embedded Computing Systems, 7(2), 2008. [28] C. Castelluccia and W. Dabbous. Automatic protocol code optimizations. Journal of Electrical and Electronic Engineering Australia - Special Issue on Networking, 1996. [29] C. Castelluccia and P. Hoschka. A compiler-based approach to protocol optimization. In Proceedings of the Third IEEE Worshop on the Architecture and Implementation of High Performance Communication Subsystem, Mistic, Connecticut, U.S.A, 1995. [30] Dominique Clément and Janet Incerpi. Programming the behavior of graphical objects using Esterel. In Proc. TAPSOFT’89, Lecture Notes in Computer Science 352, Springer -Verlag, 1989. [31] J-L. Colaço, B. Pagano, and M. Pouzet. A conservative extension of synchronous data-flow with state machines. In Proc. Emsoft’05, New Jersey, USA, 2005. [32] A. Cohen. N-synchronous kahn networks: A domain-specific program generation perspective. In Proc. IFIP WG 2.11, Wadern, Germany, 2006. [33] Eve Coste-Maniere and B. Faverjon. Programming and simulation tool for robotics workcells. In Proc. International Conference on Automation, Robotics, and Computer Vision, Singapore, 1990. [34] O. Coudert, C. Berthet, and J. C. Madre. Verification of Sequential Machines Based on Symbolic Execution. In Proceedings of the Workshop on Automatic Verification Methods for Finite State Systems, Grenoble, France, 1989. [35] S. Edwards. Languages for Digital Embedded Systems. Kluwer, Boston, Mass., 2000. [36] S. Edwards. An Esterel compiler for large control-dominated systems. IEEE Transactions on ComputerAided Design of Integrated Circuits and Systems, 21(2), 2002. [37] Bernard Espiau and Eve Coste-Maniere. A synchronous approach for control sequencing in robotics applications. In Proc. IEEE International Workshop on Intelligent Motion, Istambul, Turkey, pages 503–508, 1990. [38] Sascha Gädtke, Claus Traulsen, and Reinhard von Hanxleden. Hw/sw co-design for Esterel processing. In CODES+ISSS ’07: Proceedings of the 5th IEEE/ACM international conference on Hardware/software codesign and system synthesis, pages 99–104, New York, NY, USA, 2007. ACM. [39] F. Ghenassia. Transaction Level Modeling with SystemC. Springer, 2008. [40] A. Girault. A survey of automatic distribution method for synchronous programs. In F. Maraninchi, M. Pouzet, and V. Roy, editors, International Workshop on Synchronous Languages, Applications and Programs, SLAP’05, ENTCS, Edinburgh, UK, April 2005. Elsevier Science. [41] P. Le Guernic, M. Le Borgne, T. Gauthier, and C. Le Maire. Programming real time applications with Signal. Another Look at Real Time Programming, Proceedings of the IEEE, Special Issue, Sept. 1991. [42] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous dataflow programming language Lustre. In Proceedings of the IEEE, volume 79(9), pages 1305–1320, 1991. [43] N. Halbwachs, F. Lagnier, and C. Ratel. Programming and verifying critical systems by means of the synchronous data-flow language Lustre. IEEE Transactions on Software Engineering, Special Issue on the Specification and Analysis of Real-Time Systems, 1992. [44] Nicolas Halbwachs. Synchronous Programming of Reactive Systems. Kluwer academic Publishers, 1993. [45] D. Harel. Statecharts: a visual approach to complex systems. Science of Computer Programming, 8:231–274, 1987. [46] L. Jategaonkar Jagadeesan, C. Puchol, and J. E. Von Olnhausen. A formal approach to reactive systems software: a telecommunications application in Esterel. Formal Methods in Systems Design, 8(2), 1996. [47] G. Kahn. The semantics of simple parallel languages. In Proc. IFIP Conference, 1974. [48] G. Kahn and D. McQueen. Coroutines and networks of parallel processes. In Proc. IFIP Conference, 1977. [49] Edward A. Lee and David G. Messerschmitt. Static scheduling of synchronous data flow programs for digital signal processing. IEEE Transactions on Computers, C-36(1), 1987. [50] F. Maraninchi and Y. Rémond. Mode automata: a new domain-specific construct for the development of safe critical systems. Science of Computer Programming, pages 219–254, 2003.

74


[51] Florence Maraninchi. The Argos language: Graphical representation of automata and description of reactive systems. In Proc. IEEE Conf. on Visual Languages, Kobe, Japan, 1991. [52] H. Marchand, E. Rutten, M. Le Borgne, and M. Samaan. Formal verification of programs specified with Signal : Application to a power transformer station controller. Science of Computer Programming, 41(1):85–104, 2001. [53] G. Murakami and Ravi Sethi. Terminal call processing in Esterel. In Proc. IFIP 92 World Computer Congress, Madrid, Spain, 1992. [54] D. Potop-Butucaru, S. Edwards, and G. Berry. Compiling Esterel. Springer, 2007. [55] V. A. Saraswat, R. Jagadeesan, and V. Gupta. Default timed concurrent constraint programming. In Proc. POPL’95, San Francisco, USA, pages 272–285, 1995. [56] K. Schneider. Embedding imperative synchronous languages in interactive theorem provers. In Conference on Application of Concurrency to System Design (ACSD), pages 143–156, Newcastle upon Tyne, UK, 2001. IEEE Computer Society. [57] K. Schneider, J. Brandt, and E. VecchiÃl’. Efficient code generation from synchronous programs. In 165174, editor, Formal Methods and Models for Codesign (MEMOCODE), pages 165–174, Napa Valley, California, 2006. IEEE Computer Society. [58] Klaus Schneider. Embedding imperative synchronous languages in interactive theorem provers. In Proc. ACSD’01, IEEE Computer Society, 2001. [59] E. Sentovich, H. Toma, and G. Berry. Latch optimization in circuits generated from high-level descriptions. In Proc. International Conf. on Computer-Aided Design (ICCAD), 1996. [60] E. Sentovich, H. Toma, and G. Berry. Efficient latch optimization using exclusive sets. In Proc. Digital Automation Conference (DAC), 1997. [61] T. Shiple and G. Berry. Constructive analysis of cyclic circuits. In Proc. International Design and Test Conference ITDC 96, Paris, France, 1996. [62] Olivier Tardieu. A deterministic logical semantics for Esterel. In Proc. SOS Workshop’04, Electronic Notes in Theoretical Computer Science, Elsevier, 2004. [63] Olivier Tardieu. Loops in Esterel - from operational semantics to formally specified compilers. Technical report, PhD thesis, Ecole des Mines de Paris, 2004. [64] Olivier Tardieu and Robert de Simone. Curing schizophrenia by program rewriting in Esterel. In Proc. MEMOCODE’04, IEEE Press, 2004. [65] H. Touati and G. Berry. Optimized controller synthesis using Esterel. In Proc. International Workshop on Logic Synthesis IWLS’93, Lake Tahoe, 1993. [66] D. Weil, V. Bertin, E. Closse, M. Poise, P. Vernier, and J. Pulou. Efficient compilation of esterel for real-time embedded systems. In Proceedings of the 2000 international conference on Compilers, architecture, and synthesis for embedded systems, San Jose, CA, 2000.


75

Relating Time and Causality in Interactive Distributed Systems Manfred BROY Technische Universität München e-mail: [email protected] Abstract. For digital interactive distributed systems the timing of their events and the causality between their events are key issues. In real time applications of embedded software systems timing properties are essential such as response times of reactions depending on the precise timing of the input events. In a highly abstract view, a digital system can be represented by a set of events annotated by their timing. Sets of timed events labeled by actions represent the observations about systems. An essential property that helps to understand distributed interactive systems and a way to reason about their event flow is causality. Causality addresses the questions under which conditions certain events must, may or must not happen. Causality addresses the logical dependencies between the events in systems. Strictly speaking, causality reflects the logical essence in the event and action flow of systems. Causality is closely related to time. In particular, we study in the following the relationship between causality and the timing of input and output events, as well as its relationship to the granularity of time. We deal, in particular, with the problem of time abstraction and the precise timing of events. We show how causality and time form the basis of inductive reasoning, in particular, in the case of dependencies in communication cycles (“feedback”) and how we can work with time in models of distributed systems with a flexible choice of local clocks and local timing. Keywords. Interactive systems, causality, input/output behavior

1. Time and Causality We study the information flow in relation to the time flow in a system of events and components in the following. Information flow evolves through events in physical or technical systems within a global time frame. There are many ways to model and represent time, events, and information and the way in which they evolve in physical or technical systems. Even more, there are many ways to interpret certain phenomena related to events carrying or disseminating information inside a system or over the system boundaries between a system and its environment. Since we consider models of systems that are the result of abstractions we better are very critical not to confuse observations in models with observations about real world systems. Only if the abstractions are chosen carefully the models reflect properties of real world systems faithfully.

76

M. Broy / Relating Time and Causality in Interactive Distributed Systems

In this paper, we study issues of timing and causality of discrete event systems and how they are related. Behavior of systems is modeled by sets of events. Causality addresses the logical dependencies between the events of systems and thus the relationship between their cause and their effect. It refers in philosophy to the principle that nothing can happen without causes. In distributed systems, it addresses the logical dependencies between events, related actions and messages generated by the different parts (often called “components”) of systems. For realistic models of distributed interactive systems in terms of their flow of events, data or signals as found in interactive distributed systems we assume that there is a source and a cause for each (communication) event and its transmitted information. A reasonable way to model such systems are sets of communication events with a causality relation and a timing relation where each event consists in sending or receiving a message by one of the components of the system. This approach models the behavior of systems in terms of their communication and event flows. We are interested in this paper basically in a number of fundamental questions of system modeling and design such as: • • • • •

How can the principle of causality be formalized? Are there universal laws of causality and what are they? How do causality and time relate? How does causality help to reason about systems? How does time help to reason about systems and their causality?

We first discuss notions of time and causality independently and then study their relationship. 1.1. Discrete Event Systems In physics, system behaviors are often modeled by continuous functions depending on time. There, the dynamics of a system is captured by a set of variables that change their values continuously over time. Dependencies between these variables are captured by continuous functionals and expressed by formulas of differential calculus and integration theory, where time is represented by real numbers. The values of the continuous functions represent the states of the system at the corresponding points in time. Digital event systems provide a more abstract logical model of technical or economical systems than continuous functions do. Discrete steps of the systems modeled by events capture the dynamics of digital systems and discrete state changes. A discrete event is a quite general notion. An event may represent the execution of a certain statement, and thus a state change such as the change of the value of some system state attribute, a certain system predicate becoming true, the arrival or the sending of a certain message, or reaching a certain time bound. A digital system shows a behavior that can be modeled by a set of digital processes. A digital process is a finite or even an infinite set of discrete events. These events are causally dependent and take place within a time frame. The time model may be continuous or discrete. In the following we introduce a formal model taking these considerations into account.


77

1.2. Time Timing properties of systems can be classified into quantitative and qualitative aspects. The quantitative aspects aim at measuring time and talk about time distances between discrete events leading to questions such as: • How much time does it take until event A happens? • How much time does it take until event B happens after event A had happened? If we are not interested in measures of time distances between events as in hard real time applications there remain questions addressing the qualitative nature of timing properties, expressed by the after/before relation. Given such relations we can ask questions such as: • Does event A happen after event B? • Do events A and B happen simultaneously? • Does event A always happen only after event B? Qualitative timing relates events in a partial or even linear order while quantitative time refers to measures and distances between events in terms of time. In this section we introduce an abstract model of time. For our purpose a simple model of time is sufficient. Time is represented by a set called TIME with a linear order ≤. For each process formed by a set of events E their timing is a mapping time: E → TIME If such a mapping is defined for the events of a process we call the process a timed process. In timed processes we can relate events by their timing. In our approach each event happens at a certain point in time. In other words, we assume that an event represents a point in time and thus has no time duration. If we want to model system activities with some time duration we can do that by referring to two events associated with the activity, the beginning of the activity and its termination. For two events e1 and e2 in a timed process we say e1 takes place before e2 if time(e1) < time(e2) holds and then we write e1 < e2 and we say that the events e1 and e2 are simultaneous, if time(e1) = time(e2). This gives already a simple but quite useful notion for the timing of events. We carefully distinguish between the timing of events, which gives us “absolute” values in a time frame, and values measuring the duration of time. Given two events e1 and e2 we can ask about the duration of time between the occurrence of event e1 and event e2. The time duration is not a member of the set TIME but of another set called DURATION, which is an additive semi-group with a zero element. For the set DURATION we assume an additive structure (which does not make sense for time points). More precisely we assume an operation + : DURATION × DURATION → DURATION as well as a mapping dur: TIME × TIME → DURATION

78


This function maps two time points t1, t2 ∈ TIME with t1 ≤ t2 onto a duration dur(t1, t2) ∈ DURATION which represents the time period that it takes until the second time point is reached from the first time point. We can also introduce negative time durations by considering dur(e2, e1) where e1 < e2. We, moreover, assume that there is a null element 0 ∈ DURATION and that dur(t, t) = 0 for all time points t ∈ TIME and 0+d=d+0=d for all durations d. The operation dur can easily be extended to events e1, e2 given a timing: dur(e1, e2) = dur(time(e1), time(e2)) This function introduces a relationship between the events and the duration of time between them. For all simultaneous events their time is identical and thus the duration of time between the two events is zero. Also on durations we assume a linear ordering ≤ which faithfully reflects the timing, such that the following law holds: e1 ≤ e2 ≤ e3 ⇒ dur(e1, e2) ≤ dur(e1,e3) The ordering on the set of durations is assumed to be consistent with the addition operator. In particular, we assume that the operator + is monotonic d1 ≤ d1’ ∧ d2 ≤ d2’ ⇒ d1 + d2 ≤ d1’ + d2’ So far and in the following, we assume that time is linear (one-dimensional). This seems to be obvious. However, when selecting the model of time, it is worthwhile to shortly consider the difference between a linear (one-dimensional) space of time and time spaces where time might have several dimensions. We consider only “one-dimensional”, linear time in the following. A one dimension linear space of time is characterized by the law time(e1) ≤ time(e2) ≤ time(e3) ⇒ dur(e1, e3) = dur(e1, e2) + dur(e2, e3) or expressed in terms of time points t1, t2, t3 ∈ TIME: t1 ≤ t2 ≤ t3 ⇒ dur(t1, t3) = dur(t1, t2) + dur(t2, t3) Duration allows us to refer to the relative timing of different time points. So we can ask for time points t1, t2, t3 ∈ TIME with t1 ≤ t2 ≤ t3 whether dur(t1, t2) < dur(t2, t3)


79

A further question concerns the model of time. Basically there are two essentially different classes of models of time, discrete (digital) time and continuous, dense (analog) time. For each set of time points we assume the existence of a least upper bound (lub) and a greatest lower bound (glb). Examples of time domains are IN ∪ {∞} the natural numbers IN including ∞ for infinity as well as the non-negative real numbers including infinity IR+ ∪ {∞} where IR+ = {r ∈ IR: 0 ≤ r}. In a discrete model we find time points t1, t2∈ TIME with t1 < t2 which are “direct neighbors” (that cannot be strictly separated by a third time point that lies in between both points) such that for all t3 ∈ TIME: t1 ≤ t3 ≤ t2 ⇒ t1 = t3 ∨ t2 = t3 Thus each time point (except the maximal one, if it exists) has a unique successor. This property of discreteness does not hold for dense time. In dense time we always can find a time point separating two given different time points. This density of time results in Zenon’s problem, where there is an infinite sequence of time points that step by step increase in time but do not reach or go beyond a particular point in a finite number of steps. For an extensive discussion on ways to represent digital and analog time see [16]. 1.3. Discrete Timed Processes Based on the idea of timed events the concept of a timed process is quite straightforward. Let E be a set of timed events; then each subset P ⊆ E defines a discrete timed process. If the set of events is finite then P is called a finite process; otherwise it is called infinite. A timed process P has a start time specified by the time value glb {time(e): e ∈ P} As its termination time we define lub {time(e): e ∈ P} that may be infinite. A process has also a duration lub {dur(e, e’): e, e’ ∈ P} and a structure in terms of a partial order according to the relation e ≤ e’ for events e, e’ ∈ P provided time(e) < time(e’) or e = e’ hold. By TPROCESS we denote the set of all timed processes. 1.4. Selecting Models of Time As a first critical question for system models we address the nature of time and its models: • For which engineering tasks and when is it necessary or at least more convenient to work with continuous, dense time and when is a model of discrete time good enough or even more appropriate?

80


We work with discrete time in the following! Discrete time is typical for digital systems that are pulse driven and proceed in discrete time steps. We want to demonstrate in the following that also discrete time allows for time models that are as flexible as continuous time. We work with the following idea of observations that we can make about a system. We assume that at each time t we observe a finite family of events. In each run of the system we make a sequence of observations, one at each time point. The timing introduces a structure on the events of a process. For each time t ∈ TIME we define the sub-process (the partial process) {e ∈ P: time(e) ≤ t} that consists of all events that take place till time t. This process is denoted by P↓t. A logical property of a timed process is represented by a predicate Q: TPROCESS → IB A property Q that holds at time t is a predicate on (finite) processes applied to the set P↓t of events. Each predicate Q of that type applied to a process P↓t is called an observation about a system or about a process till time t. We write also Qt (P) for Q(P↓t). We get a kind of temporal logic if we define (for a given process P) ♦ Q ≡ ∃t ∈ TIME: Qt (P) ❑ Q ≡ ∀t ∈ TIME: Qt (P) By these formulas we can introduce the temporal operators in a rather straightforward manner. An observation (a predicate) Q is called stable, if the following proposition Qt (P) ∧ t < t’ ⇒ Qt (P) holds for all processes P and all times t, t’. 1.5. System Behaviors A discrete system may show a set of behaviors represented by processes. In the literature a discrete system is often described by a state transition machine, for instance, or by a set of concurrent cooperating state machines, or by a Petri-Net. When executing such a state machine, actions are carried out that correspond to state transitions. Each instance of an action is an event. Thus we associate for an interpreted process P (generated by the system) an action with each of its events. Let Ep be the set of events forming a process P. The concept of a discrete interpreted process is defined by a mapping act: Ep → Action where Action is the set of actions of the system. Each action defines a state change, a timing action or a communication action. This leads to a slightly more sophisticated notion of a system behavior represented by a set of processes where each event is timed and corresponds to an action.


81

1.6. Causality Causality is a notion that is more sophisticated than that of time. Time is used to capture straightforward observations about systems. Referring to causality we speak about the rules (“the logics”) for the occurrence of events and actions in the executions (processes) of systems. Timing is an observation about a single process representing a run of a system. Causality speaks about the properties and rules that hold for all processes of a system and therefore deals with the logical properties of the system. Causality addresses the rules and thus the logics of systems. But what is causality precisely and how is it related to the observations with respect to time? Causality addresses the logical dependencies between the events and actions in the digital processes of a concurrent interactive system S. Causality actually deals both with liveness and safety in observations: • Liveness: Which observation A about the system S guarantees another observation B to follow later eventually: we say “in system S observation A leads_to observation B”. • Safety: Which observation B for the system S occurs only if another observation A was observed before: we may write “in system S observation B ⇒ observation A”; however, this expression using implication does not properly express the relation between the two observations stating that B follows only after A, since the causal relationship is expressed rather implicitly this way. For the concept of causality the notion of the flow of actions and events in each process of the system is decisive which reflects implicitly or explicitly a qualitative notion of time - more precisely an ordering of the events according to time. Example: Airbag Let us look at a simple example. An airbag in a car is activated only if the crash sensor indicated a crash and whenever the crash sensor indicates a crash it is activated. Both observations are stable. Therefore if we do not consider time flow the two propositions: “crash sensor indicates crash” (csic) and “airbag is activated” (aia) are logical equivalent for completed processes. The asymmetry of these two events with respect to the event flow of a system gets only modeled if we take the time flow into account. This can be done by studying subprocesses of the processes P representing the behaviors of cars. Then we require that ∀t: csic(P↓t) ⇐ aia(P↓t) ∀t: csic(P↓t) ⇒ ∃ t’: t ≤ t’ ∧ aia(P↓t’) Here csic(P↓t) stands for ”crash sensor indicates crash“ as one of the actions of an event in P↓t and aia stands for “airbag is activated” as one of the actions of an event in P↓t. These are examples of properties addressed by the notion of causality. ❑ This example leads to a delicate question that addresses the difference between causality and logical implication. If we talk about the processes of a system and their sets of events without timing or causality information, we easily may write implications.

82


Example: Air Bag (continued) For instance, in the case of an airbag we may write (*) crash_sensor_indicates_crash ⇒ airbag_is_activated This system property expresses that for each (complete) process of the airbag system this implication is valid. This seems fine. We are even tempted to read (*) as follows: if crash_sensor_indicates_crash, this leads to airbag_is_activated. This is an assertion that can be appropriately formalized in temporal logic, but as a translation into the statement (*) above it is misleading, however, since it is an overinterpretation of implication. What we have written in (*) is simply logical implication. For the airbag we also assume the validity of the formula: airbag_is_activated ⇒ crash_sensor_indicates_crash This is an implication as the one before. But now the “leads-to” interpretation is no longer appropriate. A more accurate interpretation is: “If the air bag is activated then the crash sensor has indicated a crash before.” ❑ In fact, one way to look at causality is to see it as a principle that can be observed in any form of information processing systems independently of their technical or physical representation. Causality addresses the logical dependencies between the events (and in turn the actions) of a system. Causality is a way to “understand” a system. Certain events and actions may take place or not (such as input). Other events and actions can be caused by these events and actions (such as output). If a system has no rules of causality it is chaotic. Then all actions and events may occur at all times in a completely unrelated random manner. Causality addresses both safety and liveness properties of systems. An event A may guarantee an event B to happen later. This relationship is what is called a liveness property. An event B may only happen if event A has happened before. This relationship is what is called a safety property. There are basically two aspects of causality between two events (or actions) A and B. If A is causal for B, we may assume that • A enforces (leads_to) B: this means that whenever event A occurs event B eventually occurs (later), • B requires A: this means that event B does not occur if event A did not take place before. Of course, there are many generalizations of the notion of causality beyond these two basic principles. Example: AirBag (continued) For the airbag we obviously get the rules crash_sensor_indicates_crash enforces airbag_is_activated


83

as well as airbag_is_acivated requires crash_sensor_indicates_crash. Here we have a typical example of a strong relation of causality.

❑

Causality can be discussed not only in terms of events but also in terms of system properties. A property Q is called causal for a property Q’ if for each system run whenever we observe Q at some time t at some time later t’ > t we observe Q’. Moreover, whenever we observe Q’ at some time t’ there exists some time with t < t’ such that Q holds. We say “observation A is causal for observation B in system S” if for each process P ∈ S we have (for all times t ∈ TIME) A(P↓t) ⇒ ∃ t’ ∈ TIME: t ≤ t’ ∧ B(P↓t’) B(P↓t) ⇒ ∃ t’ ∈ TIME: t’ ≤ t ∧ A(P↓t’) The first formula is capturing what is called the “leads-to”-property in temporal logic. It can be expressed by temporal logic as follows: ❑(A ⇒ B) If both formulas shown above hold we speak of causality and write A >≈> B From the definition of causality we easily prove the transitivity of the causality relation: A >≈> B ∧ B >≈> C ⇒ A >≈> C An observation is called stable for a process P, if t ≤ t’ ∧ A(P↓t) ⇒ A(P↓t’) or in terms of temporal logic ❑(A ⇒ ❑A) In other words, if A holds at time t it remains valid from thereon. For stable observations causality is very close to logical equivalence. If A is causal for B and if A and B are stable then for each complete process P system causality boils down to implication: A(P) ⇒ B(P) and B(P) ⇒ A(P) Here logically there is no asymmetry between A and B, which indicates that by simple implication the causal relationship between A and B are not modelled appropriately. Causality is reduced to logical equivalence when abstracting from timing. If we include timing the asymmetry between A and B becomes observable. There exist times t such that A(P↓t) holds but not B(P↓t). We get for all times t (recall that we assume that A and B are stable) B(P↓t) ⇒ A(P↓t)

84


and A(P↓t) ⇒ ∃ t’: t ≤ t’ ∧ B(P↓t). This shows that if A is causal for B we get B implies A which sounds counterintuitive since sometimes “implies” may be confused with “leads to”. A sophisticated question asks about the very nature of causality. If we assume in systems that there are mechanisms (“algorithms”) that enforce that certain actions are executed by some control flow, this gives us a very concrete (“operational”) idea of causality. On the other hand we may develop some idea about causality only by observing systems and their generated actions and try to conclude causality relations from that. Actually there are along these lines two ways to look at the causality of a system: • in an intentional approach (“glass box view”) we study the internal structure and mechanisms of a system to recognize that certain events A are causal for certain events B due to the technical mechanisms (the “algorithmics”) that control the behavior and the flow of actions and events of the system. • in an extensional approach (“black box view”) to causality we study only observations about a system in terms of its events and actions and their temporal relationships without any knowledge of the internal structure and mechanisms of the system. In the set of all observations we may recognize certain regularities that we then call causal dependencies. In the first case we can speak about the causality within a single process or a single instance. In the second case we speak about the causality within the system considering all its processes. Both approaches lead to concepts and notions of causality. Extensional causality can be seen as an abstraction of intentional causality. By this abstraction some intentional causality may get hidden. We get a universal notion of extensional (“observable”) causality for a system S modeled by its set of timed processes. A simple example that illustrates this distinction between intentional and extensional is a nondeterministic process, where we have one run which first shows the action d that leads due to its underlying mechanism causally to the action b, and a behavior where the system can nondeterministically choose between the actions d or b. Then intentionally in the first run there is a causal relationship between d and b while extensionally for the system this does not hold. Observationally, the intentional causality is hidden by the nondeterminism of the system. An extensional causality is only valid if it is intentionally valid for all executions of the system. If we can only observe runs of a system with the events and their timing we get processes that are sets of events with their timing. From the set of all observations we cannot derive the intentional causality, in general. Intentional causality allows us to talk about the causality within a single execution represented by a process, while extensional causality considers a system as a whole with all its processes. In spite of the example above, causality and nondeterminism are independent notions. We do not even have to have a notion of nondeterminism to introduce the concept of causality and vice versa.


85

2. Causality and Time Of course, we can also model causality for event structures that model systems by concurrent traces. There causality is a logical relationship between the events of a system. We work with a universal notion of extensional causality for a system S consisting of a set of timed processes. Time or at least a time-based ordering of the events are an indispensable instrument to capture and measure causality. If event A is causal for event B then it certainly holds that B happens after A. The reverse does not hold. If in an observation an event A is before an event B this does not mean necessarily that they are causally related. However, if A occurs in all processes (all observations) before B (whenever A occurs) then we may assume a causal relationship between the events A and B. Note that there are many possibilities how causality is realized operationally. Even time can be a mechanism to establish causality between events. Assume that a system starts a clock under certain conditions such that after some time A happens and after some later time B happens: then A is observably causal for B. Time is definitely a way to observe causality since time is one way to observe the “happens before” relation. But the ability to observe this relationship requires that the time granularity is fine enough. We call a system model strongly causal if all events that are intentionally causal to each other are strictly separated by their timing; more precisely the time scale is fine enough that whenever an event e1 is causal for an event e2 then we have time(e1) < time(e2) Of course, in any case, we assume for causal events time(e1) ≤ time(e2) We speak of weak causality if at least this property holds for a system model. Weak causality is what we at least expect for any faithful model of real world system. Only if we would include “incorrect” observations then the “law of weak causality” does not hold any longer. 2.1. What is a Nondeterministic System In the literature there is a careful distinction between deterministic and nondeterministic systems. When looking at concrete system models, this distinction seems obvious, at a first sight. But, in fact, often it is not so clear how to give a definition what it means that a system is deterministic or nondeterministic. Often abstractions turn deterministic system models into nondeterministic ones and vice versa. The notion of nondeterminism is inherently related to the notion of input to a system. If we consider systems without input from the outside, either the system has only one behavior (one run or one process) or it has to be considered as being nondeterministic. Input to a system comes from its environment and cannot be controlled by the system itself. Systems with a variety of choices for input are not considered nondeterministic if

86


several processes depending on different input exist. Only if the system shows at least two different processes for the same input events we call it nondeterministic. We take here a very fundamental point of view. For us a system is nondeterministic, if its behavior includes choices that cannot be controlled by input from the outside but do influence its visible observable behavior. 2.2. Causality between Input and Output For a system there are events that are only internal and others that affect or are affected by the environment. Typical events of the second class are input and output. If we are aiming at an interface view onto systems then we study the events at the border of a system, being events that carry input or output across the system borders. Of course, we may study models of systems where certain events carry both input and output, however, in the following we deal with systems only that show a clear separation between events providing input and those providing output in their externally visible events. Note that there exist system models (specific instances of so-called “process algebras”) like CSP or CCS (see [29] and [36]) with the concept of synchronous communication where certain events are “shared” between systems and their environments and thus may carry both input and output. Then there is no straightforward clear notion of causality between input and output. We study a specific form of causality for systems in the following, namely the causality between their input and output events. We work under following hypothesis: • there is a canonical notion of extensional causality between input and output. This idea of causality captures the essential relationship between input and output. For a system we assume that we have a clear notion of input, which means input events can be chosen arbitrarily by the environment (and must be accepted by the system). The input events form a sub-process called the input process. The system may or must react to such input by output. This manifests the fundamental principle of causality between input and output. Of course, in addition, there may be a causal relationship between the output events observable, which manifests some additional logics of the system. In a deterministic system for each input process exactly one output process is generated. Therefore there is a fixed causality between the output events given some input process. In a nondeterministic system, several output processes may be possible for given input. Extensional causality is observed by studying all possible system processes or traces to find out whether an event is always present and guaranteed only after another event. This applies also for the causality between input and output. Such observations about the flow of events and their relationships are closely related to a model of time. We work in the following with the simplifying assumption that we do not know anything about or at least do not take advantage of any causality in the input history. We are mainly interested in studying causality between input and output and the causality in the output history. This in turn leads also to a notion of causality in the output. 2.3. Information Flow and Causality Whenever two subsystems of a system interact and this way mutually influence each other’s behavior within the context of the larger system this requires a form of informa-


87

tion exchange between the subsystems. In general, the information flows in both directions. This leads to a fundamental question: • Can we model information exchange always as a directed activity (information flow) with an explicit sender and one or several receivers (modeling mutual information exchange as two steps of directed information exchange)? The events of information exchange are then output of one system and input to the other. The basic principle of causality in information flow of components with input and output is as simple as the following axiom (here we assume that a system cannot predict its future input and thus there is no “anticipating logical gate” – no logical gate that can predict its future input and thus produce corresponding output before the input actually arrived; therefore, in real life systems, output depending on such future input can be produced only after that input had been received): • Information can only be evaluated, processed and forwarded as soon as/after it has been received. This hypothesis leads to essential questions about the relationship between time, granularity, and causality. If the time granularity is fine enough there is always a delta, the “reaction time”, between the timing of the input and the output caused by it. If the time granularity is not fine enough, this does not hold, in general. In this case, input and output might occur in the same time interval and thus have the same time stamp. 2.4. Time Granularity and Causality In this section we study changes and transformations of the time granularity of a system and its consequences. We are, in particular, interested in time abstractions that make the time scale coarser. Given a timed process P with the event set E and the timing function time: E → TIME we can change (“transform”) the timing of the process P by a function trans: TIME → TIME’ where we assume the following monotonicity property for all times t1, t2 ∈ TIME: t1 ≤ t2 ⇒ trans(t1) ≤ trans(t2) Given a time transformation function we get a new timing for process P by the function time’: E → TIME’ specified by the formula (for all events e ∈ E) time’(e) = trans(time(e)) As a result of a time transformation, the new timing may be coarser. Events e1 and e2 with the timing property time(e1) < time(e2) may become simultaneous events under time’. In other words, we may get time’(e1) = time’(e2). We speak of a time coarsening in this case.

88


We discuss in the remainder of this paper the notion of strong and that of weak causality. Given strong causality, the time model strictly separates all events that are causal for other events from those for which they are causal. If we coarsen the timing of a process we may map a strongly causal process onto a process that is no longer strongly but only weakly causal. We are interested to study in the following the effects of the time granularity and its coarsening onto the notion of causality. We study systems and their models under several time granularities. Basically, for systems and their models we assume the following principles: • For the time granularity we find: ∗ If the time scale of the input events is chosen fine enough then there is no nondeterminism/underspecification left in the system model that is due to missing information about the timing of the input. ∗ If the time scale is finer than the minimal delay of reactions to events, then causal events are separated by time and the behavior is strongly causal. ∗ Every system behavior is weakly causal in appropriately constructed system models. Strong causality, however, may be abstracted away due to time models that are too coarse and hence do not separate some events that are in the causality relation. • Every system behavior is “physically” strongly causal. This means that even for a given weakly causal model of a real world system there exists a strongly causal behavior model such that the given weakly causal system behavior model is a time coarsening of this strongly causal model. If we choose the time granularity not fine enough then we get a system behavior that is only weakly causal although implicitly strongly causal since it is an abstraction of a strongly causal system.

3. Streams and Stream Processing Systems In this section we briefly introduce a simple, but very fundamental model of systems called F OCUS (see [23]). It is based on streams representing interaction histories. 3.1. Streams A stream is a finite or infinite sequence of elements. In interactive systems streams are built over sets of messages, signals, or actions. Streams are used that way to represent communication histories for sequential communication devices such as channels or for sequential histories of activities. Let M be a given set of messages. A stream over the set M is a finite or an infinite sequence of elements from M. We use the following notation: M∗ M∞

denotes the set of finite sequences over M including the empty sequence , denotes the set of infinite sequences over M (that are represented by the total mappings IN\{0} → M).


89

A stream is a member of the set Mω that is defined by the equation Mω = M∗ ∪ M∞ We introduce the prefix ordering on streams which is a partial order specified for streams x, y ∈ Mω by the formula x y ≡ ∃ z ∈ Mω : x^z = y Here x^z denotes the well-known concatenation of sequences; by concatenation the stream z is appended to the stream x. To extend the concatenation to infinite streams we define: if x is infinite then x^z = x. Throughout this paper we do not work with this simple concept of a stream as introduced above. Since we want to deal with the timing of systems we find it more appropriate to use so-called timed streams. An infinite timed stream represents an infinite history of communications over a channel or an infinite history of activities that are carried out sequentially in a discrete time frame. The discrete time frame represents time as an infinite chain of time intervals of equal finite duration. In each time interval a finite number of messages can be communicated or a finite number of actions can be executed. Since we do not assume anything about the speed of communication the sequence of messages communicated within a time interval can be arbitrarily long but it is always finite. Therefore we represent a communication history over a sequential communication medium in a system model executed in a discrete time frame by an infinite sequence (a “stream”) of finite sequences of messages or actions. By (M∗ )∞ we denote the set of timed streams. Note that the elements of (M∗ )∞ are infinite streams of finite sequences. The idea of a timed stream reflects directly the concept of an observation in a discrete time scale. For every time t ∈ IN and every stream s ∈ (M∗ )∞ the prefix of s of length t (which is a sequence of length t of finite sequences from M∗ ) reflects the observation till time t. For a function f we often write f.z for function applications instead of f(z) to avoid unnecessary brackets. Throughout this paper we work with a couple of simple basic operators and notations for streams and timed streams respectively that are summarized below: m x.t #x x^z x↓t c Sx

empty sequence or empty stream, one-element sequence containing m as its only element, t-th element of the stream x, which is a sequence in the case of a timed stream length of the stream x, concatenation of the sequence x to the sequence or stream z, prefix of length t of the stream x (which is a sequence with t elements, in the case of a timed stream a sequence with t sequences as elements), provided x has at least t elements (otherwise x↓t = x), stream obtained from x by deleting all its messages that are not elements of the set S.

90


For a timed stream we denote by x

the finite or infinite stream that is the result of concatenating all sequences in the timed stream x. Note that x is finite if x carries only a finite number of nonempty sequences.

A timed stream x ∈ (M∗ )∞ carries the information at which times which messages are transmitted. As long as the timing is not relevant for a system it does not matter if a message is transmitted somewhat later (scheduling messages earlier may make a difference with respect to causality – see later). To take care of this we introduce the concept of a delay closure. For a timed stream x ∈ (M∗ )∞ we define the delay closure of x by the set x↑ of timed streams that carry the same stream of messages but perhaps with some additional time delays as follows: x↑ = {x’ ∈ (M∗ )∞ : ∀ t ∈ IN: x ↓ t x ↓ t ∧ x = x } Obviously, we have x ∈ x↑ and for each x’ ∈ x↑ we have x’↑ ⊆ x↑ as well as x = x . The set s↑ is called the delay closure for the stream s. The delay closure is easily extended from streams to sets of streams by pointwise application (let S ⊆ (M∗ )∞ ) S↑ =

s↑

s∈S

Throughout this paper, we use streams exclusively to model the communication histories of sequential communication media that we call channels. In general, in a system many communication streams occur. Therefore we work with channels to name the individual communication streams. Accordingly, in F OCUS a channel is simply an identifier in a system that identifies a communication line and in every execution of the system it evaluates to a stream of messages communicated over that line. 3.2. Components: Syntactic and Semantic Interfaces In this section we introduce a mathematical notion of components and their interfaces. Components interact with their environment via channels. A channel is a communication link and uniquely identified by a channel identifier. 3.2.1. I/O-Behaviors Types (or sorts) are useful concepts to describe interfaces. We work with a simple notion of types where each type represents a set of data elements. These data elements are used as messages or as values of state attributes. Let a set S of types of messages be given. By M where


M=

91

s

s∈S

we denote the set (the “universe”) of all data messages. In Focus a typed channel is an identifier for a sequential directed communication link for transmitting messages of that type. By C we denote a typed channel set. We assume that a type assignment for the channels in the set C is given by the mapping: type: C → S → − Given a set C of typed channels, a channel valuation is an element of the set C defined as follows: − → C = {x: C → (M∗ )∞ : ∀ c ∈ C: x.c ∈ (type(c)∗ )∞ } → − A channel valuation x ∈ C associates a stream of elements of type type(c) with each channel c ∈ C. This way the channel valuation x defines a communication history for each of the channels in the set C. The operators on streams induce operators on channel valuations and furthermore on sets of streams as well as sets of channel valuations by pointwise application. This way all our operators introduced on streams generalize to channel valuations. Given a set of typed input channels I and a set of typed output channels O we introduce the notion of a syntactic interface of a component: (I, O) syntactic interface, I set of typed input channels and, O set of typed output channels. A graphical representation of a component and its interface as a data flow node is shown in Fig. 1. We do not require that the channel sets I and O are disjoint. If a channel c occurs both in I and O it denotes two different channels: one channel in the set of input channels and one channel the set of input channels.

I ... F ... O Figure 1. Graphical Representation of a Component F with the Set of Input Channels I and the Set of Output Channels O

For a component-oriented approach to system development in addition to the syntactic interface a concept for describing the behavior of a component is needed. We work

92


with a simple and straightforward notion of a behavior. Relations between input histories and output histories represent behaviors of systems. Input histories are represented by valuations of the input channels and output histories are represented by the valuations of the output channels. In Focus we represent the black box or interface behavior of systems by set-valued functions (we also speak of the semantic or behavioral interface of the component): → − → − F: I → ℘( O ) As it is well known, such a set-valued function is isomorphic to a relation which is a → − − → subset of I × O . We prefer set-valued functions in the case of system behaviors to emphasize the different roles of input and output. We call the function F an I/O-behavior. → − Given an input history x ∈ I , F.x denotes the set of all output histories each of which a system with behavior F may exhibit in reaction to the input x. → − An I/O-behavior F is called deterministic, if F.x is a one-element set for each x ∈ I . → − − → A deterministic I/O-behavior represents simply a function I → O . It is well known that a naive modeling of the behavior of systems by relations on streams leads into the so-called merge anomaly (also called Brock-Ackermann anomaly, see [11]). In Focus this anomaly is avoided by the notion of strong causality (see later). 3.3. Specification of I/O-Behaviors An I/O-behavior represents a model of the behavior of a system. Using logical means, an I/O-behavior F can be described by a logical formula, called specifying assertion relating the streams on the input channels to the streams on the output channels. In such a formula channel identifiers occur syntactically as identifiers (variables) for streams of the respective type. The specifying formulas are interpreted in the standard way of typed higher order predicate logic (see [4]). An abstract specification of a system provides the following information: • its syntactic interface, describing the input and output channels by which the system interacts with its environment, • its behavior by a specifying formula Φ relating input and output channel valuations. This leads to a specification technique for systems (see [23] for lots of examples). In F OCUS we specify a system by a scheme of the following form: ‹name› in ‹input channels› out ‹output channels› ‹specifying formula› The shape of the scheme is inspired by well-known specification approaches like Z (see [42]). Example: Transmission, Merge and Fork As simple but quite fundamental examples of systems we specify a merge component MRG, a transmission component TMC, and a fork component FRK. In the examples let


93

T1, T2, and T3 be types (recall that in our case types are simply sets) where T1 and T2 are assumed to be disjoint and T3 is the union of the sets of elements of type T1 and T2. The specification of the merge component MRG (actually the specification relies on the fact that T1 and T2 are disjoint which should be made explicit in the specification in a more sophisticated specification approach) reads as follows: MRG in x: T1, y: T2 out z: T3 c z ∧ y = T2 c z x = T1 In this specification we do not specify the quantitative timing (since the output does not refer to nor depend on the timing of the input of the output streams) and therefore refer only to the time abstractions of the involved streams. The causality of the time and message flow is considered in detail in the following subsection. We specify the proposition x ∼ y for timed streams x and y of arbitrary type T; x ∼ y is true if the messages in x are a permutation of the messages in y. Formally we define this operator by the following logical equivalence relation: c y) c x = {m} x ∼ y ≡ (∀ m ∈ T:{m} Based on this definition we specify the component TMC below. Often it is helpful to use some channel identifiers both for input channels and for output channels. These are then actually two different channels, which, of course, may have different types. To distinguish these channels in the specifying formulas, we use a well-known notational convention. In a specification, it is sometime convenient to use the same channel name for an input as well as for an output channel. Since these are different channels with identical names we have to distinguish them in the body of a specification. Hence, in the body of a specification, we write for a channel c that occurs both as input and as output channel simply c to denote the stream on the input channel c and c’ to denote the stream on the output channel c. Thus in the following specification z is the outside name of the output channel z and z’ is its local name used in the specifying formula. TMC in z: T3 out z: T3 z ∼ z’ This simple specification says that for component TMC every input message occurs eventually also as output message, and vice versa. Nothing is specified about the timing of the messages. In particular, messages may be arbitrarily delayed and overtake each other. Output messages may even be produced earlier than they are received. This paradox is excluded by causality in the following section. The following component FRK is just the ”inversion” of the component MRG.

94


FRK in z: T3 out x: T1, y: T2 c z x = T1 c z y = T2 Note that the merge component MRG as well as the TMC component and the fork component FRK as they are specified here are “fair”. Every input is eventually processed and reproduced as output. ❑ Based on the specifying formula given in a specification of an I/O-behavior F we may prove properties about the function F in classical (higher order) predicate logic. 3.4. Causality and Timing in I/O-Behaviors For input/output information processing devices the notion of causality is crucial. Certain output depends causally on certain input. Causality indicates dependencies between the input and output actions of information exchange of a system. So far I/O-behaviors are nothing but relations represented by set-valued functions. In the following we introduce and discuss the notion of causality for I/O-behaviors. I/O-behaviors generate their output and consume their input in a global time frame. This time frame is useful to characterize causality between input and output. Output that depends causally on certain input cannot be generated before this input has actually been received. Let an I/O-behavior → − → − F: I → ℘( O ) be given. In the following we define a couple of fundamental notions to characterize specific properties of F that relate to causality and the timing of the input and output messages. Definition: Weak Causality for Component Behavior An I/O-behaviorF is called weakly causal (properly timed), if for all times t ∈ IN the following formula is valid x↓t = z↓t ⇒ (F.x)↓t = (F.z)↓t ❑ F is properly timed if the output in the t-th time interval does not depend on input that is received after time t. This ensures that there is a proper time flow for the component modeled by the behavior function F. This is a property that manifests the essential asymmetry between input and output. If F is not weakly causal then there exists a time t and input histories x and x’ such that x↓t = x’↓t but (F.x)↓t = (F.x’)↓t. A difference between the input histories x and x’ occurs only after time t but at time t the reactions of F in terms of its output messages till time t are already different.


95

Nevertheless, proper timing in terms of weak causality does not exclude instantaneous reaction (see [8]): the output at time t may depend on the input at time t. This may, however, lead into problems with causality if we consider, in addition, delay free feedback loops (such problems also occur in Esterel, see [8]). To avoid these problems we better strengthen the concept of proper time flow to the notion of strong causality. Definition: Strong Causality for Component Behavior An I/O-behavior F is called strongly causal (or time guarded), if for all times t ∈ IN (and all input histories x and z) we have x↓t = z↓t ⇒ (F.x)↓t+1 = (F.z)↓t+1 ❑ If F is time guarded then the output in the t-th time interval does not depend on input that is received after the (t-1)-th time interval. Then F is certainly properly timed and in addition reacts to input received in the (t-1)-th time interval not before the t-th time interval. This way causality between input and output is guaranteed and explicitly visible according to the sufficiently fine time granularity. Definition: Delay by n Time Units We write delay(F, n), if F is a behavior with a delay by (at least) n time units. More precisely we define: delay(F, n) ≡ [∀ x, z, t: x↓t = z↓t ⇒ (F.x)↓t+n = (F.z)↓t+n] In other words, F is (weakly) causal if delay(F, 0) holds and strongly causal if delay(F, 1) holds. ❑ Obviously we have for all n, m ∈ IN (the proof is straightforward): n ≤ m ∧ delay(F, m) ⇒ delay(F, n) If delay (F, ∞) holds then the output does not depend on the input at all. For a weakly causal component there is always a maximal number n ∈ IN ∪ {∞} such that delay(F, n) holds. This number is called the guaranteed delay. Our concept of delay is easily extended to individual output channels. Of course, there may be different delays and different guaranteed delays valid for the different output channels of an I/O-behavior. We will come back to this. → − → − A function f: I → O is called weakly or strongly causal respectively if the de→ − → − → − terministic I/O-behavior F: I → ℘( O ) specified by F.x = {f.x} for all x ∈ I has the required properties. → − → − By [F] we denote the set of time guarded total functions f: I → O , with f.x ∈ F.x → − for all input histories x ∈ I . A nondeterministic specification F defines the set [F] of total deterministic behaviors. A specification is only meaningful (“consistent”) if the set [F] is not empty. This idea leads to the following definition.

96


Definition: Realizability An I/O-behavior F is called realizable, if [F] = ∅; this means that there exists a time → − − → guarded total function f: I → O such that → − ∀ x ∈ I : f.x ∈ F.x. → − → − Given an input x ∈ I an output y ∈ O is called realizable for F with input x, if there is a function f ∈ [F] such that y = f.x. ❑ → − → − A time guarded function f: I → O provides a deterministic strategy to calculate for every input history x a particular output history y which is correct for F, i.e. such that y ∈ F.x holds. Every input x↓t till time point t fixes the output till time point t+1 and in particular the output at time t+1. Actually the function f essentially defines a deterministic automaton with input and output. If an I/O-behavior F is not realizable there does not exist a state machine that implements it, not even a state machine that implements a refinement of F (for a proof, see [18]). There are sophisticated examples of behaviors that are strongly causal, but not real→ − → − izable. Consider for instance the following example of a behavior F: I → ℘( I ) that is not realizable (here the proof of this fact is left to the reader, a proof is found in [23]): → − F.x = {x’ ∈ I : x = x’} Note that this behavior F is strongly causal but not realizable. Definition: Full Realizability An I/O-behavior F is called fully realizable, if it is realizable and if for all input histories → − x∈ I: F.x = {f.x: f ∈ [F]} holds.

❑

Full realizability guarantees that for all output histories there is a strategy (a deterministic state machine implementation) that computes this output history. For fully realizable behavior there is a close relationship between F and the set [F]. Both define the behavior of a system. In fact, nondeterministic state machines with input and output are not more powerful or more expressive than sets of deterministic state machines with input and output. An extensive definition of realizability and its relation to computability is found in [18]. 3.5. Property Refinement of Interfaces Property refinement allows us to replace an interface behavior by one having additional properties. This way interface behaviors are replaced by a more restricted ones. An interface


97

→ − → − F: I → ℘( O ) is refined by a behavior → − → − Fˆ : I → ℘( O ) if → ˆ − ∀ x ∈ I : F(x) ⊆ F(x) We write then Fˆ ⊆ F Obviously, property refinement is a partial order and therefore reflexive, asymmetric, and transitive. Note that the paradoxical system, with empty sets of output histories for each of its input histories, is logically a refinement for every system with the same syntactic interface. A property refinement is a basic refinement step adding requirements as it is done step by step in requirements engineering. 3.6. Computations Our model describes a behavior in terms of the relationship between input and output histories. In this section we show how to associate computations with behaviors. The key idea is that we calculate the output in each time interval step by step from the input given in the previous time interval according to the progress of time. We show how to calculate stepwise inductively an output history for a given strongly → − causal realizable behavior F and an input history x ∈ I that is only provided step→ − wise. We construct the output histories y ∈ O defining y↓t iteratively from input x↓t for t = 0, 1, 2, . . . The key idea is that we can select the output y.t+1 given x↓t without considering x.t+1. We define a computation for a realizable behavior F for a given input history inductively as follows: we choose a deterministic behavior f ∈ [F]. We start with t = 0; by definition x↓0 and y↓0 are both empty histories. Given x↓t and y↓t ∈ (F.x)↓t we construct from x↓t and y↓t the sequence y.t+1 as follows: We construct a chain of partial output histories yt ∈ (F.x)↓t such that yt ∈ {(f.x’)↓t: x’↓t = x↓t} The construction works as follows: we start the iteration with the empty history: y0 .c =

∀c∈O

Given yt we construct yt+1 by the following rules: (1) choose some y’ ∈ {f.x’: x’↓t = x↓t} (2) define yt+1 = yt ^y’.t+1

98


Note that by strong causality yt = y’↓t and thus yt+1 = y’↓t+1. This shows that our construction essentially relies on the strong causality of f. If the behaviour is not strongly causal, then our construction does not work, in general. Given some input x↓t we may select some output y↓t ∈ {y’↓t: ∃ x’: y’ ∈ F.x’ ∧ x’↓t = x↓t} such that y↓t ∈ (F.x)↓t The partial output y↓t therefore cannot be necessarily completed into a complete infinite output history (for details, see [18]). The same applies if the output y is not realizable. Then a function f ∈ [F] does not exist with y = f.x. If we would choose in step (1) the formula y’ ∈ {F.x’: x’↓t = x↓t} then it is not guaranteed that y ∈ F.t holds with this construction. For a behavior function → − → − → − → − F: I → ℘( O ) there may exist a history y ∈ O such that for some input history x ∈ I we have y↓t ∈ (F.x)↓t for all t but y ∈ F.x (for details see [18]). 3.7. Fixpoints To compose two or more components into a system architecture these components are connected by their channels. Some of these connecting channels typically form feedback loops, in general. Feedback corresponds to recursive definitions of the streams in the channel valuations. Recursion on streams is treated, as usual, in terms of fixpoints. As well-known, deterministic strongly causal functions always have fixpoints. Strongly causal function are guarded and thus the fixpoints can be “inductively” defined. The existence proof basically is given by an inductive construction of the fixpoint along the lines of the definition of the concept of a computation as shown above. Thus realizable strongly causal behaviors always have fixpoints that reflect feasible computations of the system. Recall, that every strongly causal function → − → − f: I → O has a unique fixpoint x = f(x). The proof is quite straightforward by an inductive construction of the fixpoint as in the previous section on computations. Therefore every realizable function → − → − F: I → ℘( O ) has a fixpoint1 x ∈ F(x). Moreover, for a fully realizable behavior every fixpoint x ∈ F(x) is a fixpoint of a function f ∈ [F]. Using weakly causal functions we run into difficulties, here, however, to separate fixpoints x ∈ F(x) that correspond to actual computations from those that do not. In the case of strongly causal, realizable functions, every fixpoint corresponds to a proper computation. For a weakly causal function 1 For

a function F that maps histories onto sets of histories x is called a fixpoint if x ∈ F(x).


99

→ − → − f: I → O we do not even have a guarantee that fixpoints actually exist. Example: Fixpoints for weakly and strongly causal functions Consider as an example the following specification: Succ in a: IN out b: IN ∀ t: b.t = if a.t = then 1 else succ*(a.t) fi where ∀ n ∈ IN, s ∈ IN*: succ*() = ∧ succ*(n^s) = n+1^succ*(s) Succ is obviously weakly causal but not strongly causal since the output at time t depends exclusively on the input at time t. However, Succ does not have a fixpoint x ∈ Succ.x; this is proved by contradiction as follows; there does not exist a history x and y with y ∈ Succ.x x.a = y.b since this would immediately result in a contradiction because then for all times t ∈ IN we would get (with a.t = b.t): b.t = if b.t = then 1 else succ*(b.t) fi which is an equation impossible to fulfill since if b.t = then b.t = 1 would follow as well as b.t = and b.t = succ*(b.t) cannot hold. If we slightly change the definition by writing b.t+1 = . . . instead of b.t = . . . then the specified behavior is obviously strongly causal and fixpoints do exist. One fixpoint (in fact the only one) is then given by the timed stream on channel b: b.0 = , b.1 = 1, b.2 = 2, . . . ❑ This example demonstrates the complications when working with only weakly causal in contrast to strongly causal functions and behaviors. Such problems are also encountered in approaches called “perfect synchrony” as found in Esterel (see [8]) leading to the wellknown problem of certain Esterel programs that are without proper computations called causal loops. 4. Composition Operators In this section we introduce an operator for the composition of components. We prefer to introduce only one general powerful composition operator and later show how to define a number of other operators as special cases.

100


F1

F2 F1

F2

...

...

Figure 2. Parallel Composition with Feedback

4.1. Composing Components Given I/O-behaviors → − → − F1 : I 1 → ℘( O 1 ),

− → → − F2 : I 2 → ℘( O 2 )

where the sets of output channels are disjoint O1 ∩ O2 = ∅ we define the parallel composition with feedback as it is illustrated in Fig. 2 by the I/Obehavior → − → − F1 ⊗ F2 : I → ℘( O ) with a syntactic interface as specified by the equations: I = (I1 ∪ I2 )\(O1 ∪ O2 ), O = (O1 ∪ O2 ). → − The resulting function is specified by the following equation (here we assume z ∈ C where the set of all channels C is given by C = I1 ∪ I2 ∪ O1 ∪ O2 ): (F1 ⊗ F2 ).x = {z|O: z|I = x|I ∧ z|O1 ∈ F1 (z|I1 ) ∧ z|O2 ∈ F2 (z|I2 ) } → − Here for a channel set C’ ⊆ C we denote for z ∈ C by z|C’ the restriction of y to the channels in C’. The equation defining composition includes a fixpoint construction for all channels in Z = (I1 ∪ I2 ) ∩ (O1 ∪ O2 ). → − For these channels for given input history x ∈ I we get by the notation above some → − y|Z ∈ Z which is a fixpoint of the function λz. [(F1 ⊗F2 ).(x⊕z)]|Z → − → − where for x1 ∈ I 1 , x2 ∈ I 2 where (I1 ∩ I2 ) = ∅


101

−−−→ x1 ⊕x2 ∈ I1 ∪I2 is defined as follows: (x1 ⊕x2 )|I1 = x1 ∧ (x1 ⊕x2 )|I2 = x2 As long as F1 and F2 have disjoint sets of input and output channels the composition is → − − → simple. Given x1 ∈ I 1 and x2 ∈ I 2 we get the equation (F1 ⊗ F2 ).(x1 ⊕ x2 ) = {y1 ⊕ y2 : y1 ∈ F1 .x1 ∧ y2 ∈ F2 .x2 } Now assume I1 = O1 and I2 = O2 = ∅ Note F2 is then the component without input and output. We write then μ.F1 for F1 ⊗ F2 . We get I = ∅ (μ.F1 has no input channels) and μ.F1 = {y: y ∈ F1 .y} This somewhat special construction shows once more that composition with feedback loops corresponds to a kind of fixpoint equation. We call y ∈ F1 .y a fixpoint of F1 . Note → − → − in the case of a deterministic function f1 : O 1 → O 1 we get y = f1 .y. The operator ⊗ is a rather general composition operator that can be easily extended from two components to a family of components. A more specific operation is sequential composition also called pipelining. It is a special case of the composition operator where O1 = I2 and the sets I1 and O2 are disjoint. In this case we define F1 ◦ F2 = F1 ⊗ F2 where the composition is illustrated by Fig. 3.

F1

F2 Figure 3. Pipelining

Pipelining is the special case of composition without feedback. It can easily be generalized to the case where the channel sets I1 and O2 are not disjoint. The definition reads as follows (F1 ◦ F2 ).x = {z ∈ F2 .y : y ∈ F1 .x } This composition is also called relational composition if F1 and F2 are represented asrelations or functional composition if F1 and F2 are deterministic and thus functions.

102


4.2. Granularity Refinement: Changing Levels of Abstraction In this section we show how to change the levels of abstractions by refinements of the interfaces, state machines and processes. Changing the granularity of interaction and thus the level of abstraction is a classical technique in software system development. Interaction refinement is the refinement notion for modeling development steps between levels of abstraction. Interaction refinement allows us to change for a component • the number and names of its input and output channels, • the types of the messages on its channels determining the granularity of the communication. An interaction refinement is described by a pair of two functions → − → − A: C ’ → ℘( C )

→ − → − R: C → ℘( C ’)

that relate the interaction on an abstract level with corresponding interaction on the more concrete level. This pair specifies a development step that is leading from one level of → − abstraction to the other one as illustrated by Fig. 4. Given an abstract history x ∈ C each y ∈ R(x) denotes a concrete history representing x. Calculating a representation for a given abstract history and then its abstraction yields the old abstract history again. Using sequential composition, this is expressed by the requirement: R ◦ A = Id Let Id denote the identity relation and “◦” the sequential composition defined as follows: (R ◦ A)(x) = {y ∈ A(z): z ∈ R(x)} A is called the abstraction and R is called the representation. R and A are called a refinement pair. For untimed systems we weaken this requirement by requiring R ◦ A to be a property refinement of the untimed identity, formally expressed by the following equation: (R◦A)(x) = { x } This defines an identity under time abstraction. abstract level

...

...

R

A

...

... concrete level

Figure 4. Communication History Refinement


103

Interaction refinement allows us to refine systems, given appropriate refinement pairs for their input and output channels. The idea of an interaction refinement is visualized in Fig. 5 for the so-called U−1 -simulation. Note that here the components (boxes) AI and AO are no longer definitional in the sense of specifications, but rather methodological, since they relate two levels of abstraction.

I1

F

...

...

AI

RO

...

abstract level

O2

concrete level

... ^

I2

O1

F

Figure 5. Interaction Refinement (U−1 -simulation)

Given refinement pairs → − → − AI : I 2 → ℘( I 1 ) → − → − AO : O 2 → ℘( O 1 )

→ − → − RI : I 1 → ℘( I 2 ) → − → − RO : O 1 → ℘( O 2 )

for the input and output channels we are able to relate abstract to concrete channels for the input and for the output. We call the interface → − → − Fˆ : I 2 → ℘( O 2 ) an interaction refinement of the I/O-behavior → − → − F : I 1 → ℘( O 1 ) if the following proposition holds: ≈> AI ◦ F ◦ RO ≈> Fˆ

U−1 -simulation

This formula essentially expresses that Fˆ is a property refinement of the system → − AI ◦ F ◦ RO . Thus for every “concrete” input history xˆ ∈ I 2 every concrete output → − yˆ ∈ O 2 can be also obtained by translating xˆ onto an abstract input history x ∈ AI · xˆ such that we can choose an abstract output history y ∈ F(x) such that yˆ ∈ RO (y).

5. Variations on Time Granularity In this section we show how to change the time granularity in system models and study the effect of those changes. We start by defining operators that change the time scale. Then we study algebraic properties of these operators.

104


5.1. Changing the Time Scale Let n ∈ IN with n > 0 and C be a set of typed channels; to make for a channel history (or a stream) → − x∈ C its time scale coarser by the factor n we introduce the coarsening function − → → − COA(n): C → C defined by (for all t ∈ IN): COA(n)(x).t+1 = x.(t*n+1)^...^x.(t*n+n) COA(n).x yields a history from history x where for each stream associated with a channel the sequences for n successive time intervals are concatenated (“abstracted”) into one. That way we forget about some of the time distribution of x. The time scale is made coarser that way. Time coarsening obviously is an instance of abstraction. We forget some information about the timing of a history. The mapping is not injective. Distinct histories may be mapped onto the same history by time scale coarsening. It is not difficult to allow even a coarsening factor n = ∞ in time coarsening. Then the infinite number of time intervals in a timed stream is mapped into one. The infinite stream of sequences is concatenated into a nontimed stream. Timed streams are abstracted into nontimed streams that way if we define: COA(∞).x = x On histories, coarsening is a function that is not injective and thus there does not exist an inverse. We generalize the coarsening of the time scale from channel histories to behaviors. We coarsen both the input and the output histories. To make a behavior → − → − F: I → ℘( O ) coarser by the factor n, we define the coarsening operator that maps F onto a function → − → − COA(F, n): I → ℘( O ) which is defined as follows COA(F, n)(x) = { COA(n).y: ∃ x’: x = COA(n).x’ ∧ y ∈ F(x’) } Coarsening maps I/O-behaviors onto I/O-behaviors. On one hand, coarsening may introduce further nondeterminism and underspecification into behaviors due to the coarser time scale of the input histories. Certain different input histories are mapped by the time coarsening onto the same coarser input histories. Then their sets of output histories are defined by the union of all their coarsened output histories. This way nondeterminism may grow.


105

On the other hand some nondeterminism and underspecification may be removed in behaviors by coarsening since some different output histories may be mapped by the time coarsening onto the same coarser output history. A special case is the coarsening COA(F, ∞), which abstracts completely away all time information. If the output of F is depending on the timing of the input, then the coarsening COA(F, ∞) introduces a lot of nondeterminism, in general. However, if the output produced by F does not depend on the timing of the input messages at all but only on their values and the order in which they arrive, COA(F, ∞) will rather be more deterministic. If F is weakly causal, the behavior COA(F, n) is obviously weakly causal, too. However, strong causality is not maintained by coarsening the time scale, in general. We will come back to more explicit laws of causality and coarsening later. Reactions to input at later time intervals may be mapped onto one time interval. We can also map a history as well as a behavior onto a finer time granularity. Let n ∈ IN; to make for a history (or a stream) → − x∈ C its time scale finer by the factor n we use the function → − → − FINE(n): C → ℘( C ) defined by the equation: → − FINE(n)(x) = { x’ ∈ C : ∀ t ∈ IN: x.t+1 = x’.(n*t+1)^...^x’.(n*t+n) } FINE(n).x yields the set of histories where for each time interval the sequences of messages in this interval are arbitrarily subdivided into n sequences that are associated with n successive time intervals. Thus the sequence on each time interval for each channel is nondeterministically divided into n sequences. The time scale is made finer that way. Making the time scale finer is a form of concretization in contrast to abstraction. Each history is mapped onto a number of histories by making its time scale finer. Each of these histories represents one version of the history with a finer time granularity. Another way to define the function FINE is demonstrated by the following formula FINE(n)(x) = {x’: COA(n).x’ = x} This equation shows more explicitly the relationship between making the time scale coarser and making the time scale finer. They are “inverse” operations (for detailed discussion, see following section). Changing the time scale represents an abstraction, if we make the time scale coarser, and a concretization, if we make it finer. The idea of making a time scale finer can be applied also to behaviors. We specify FINE(F, n)(x) = { y’ ∈ FINE(n).y: ∃ x’: x = FINE(n)(x’) ∧ y ∈ F(x’) } Due to the underspecification that is involved in the way we make the time scale finer, there is no guarantee that we get a higher number of delays in the behaviors when moving to a finer time scale.

106


Nevertheless, we can introduce an “artificial” operator DFINE that makes the time scale finer in a way that guarantees a larger delay. This operator is easily defined in a brute force way by defining DFINE as follows for t ∈ IN\{0} x.(t/n) if t mod n = 0 (DFINE(n).x).t = otherwise Then every input is delayed by the factor n. Such an operator is artificial, however, since it resolves some of the nondeterminism introduced by the operator FINE in a brute force way by making the time grain finer in a way that guarantees the largest delay. Going from a finer to a coarser time scale we generally lose some information about the timing that cannot be recovered properly when making the time scale finer again. 5.2. Rules for Time Scale Refinement Changing the time scale is an operation on histories and behaviors. In this section we study laws and rules for changing the time scale. Our first rules for changing the time scale show that the functions COA(n) and FINE(n) form refinement pairs in the sense of [23]: COA(n).FINE(n).x = {x} x ∈ FINE(n).COA(n).x In other words, coarsening is the inverse of making the time scale finer. The proof of the equation is quite straightforward by the definition of COA and FINE. We observe, in particular, the following equations (here F1 ◦ F2 denotes the pipeline → − → − → − → − composition of F1 : I 1 → ℘( O 1 ) and F2 : I 2 → ℘( I 2 ) where O1 = I2 and (F1 ◦ F2 ).x = {y: ∃z: z ∈ F1 .x ∧ y ∈ F2 .z}) COA(F, n) = FINE(n) ◦ F ◦ COA(n) FINE(F, n) = COA(n) ◦ F ◦ FINE(n) The proof is again quite straightforward. The equations show that time refinement in fact is a special case of interaction granularity refinement (see [17]). Both time granularity abstractions and refinements by factors n*m can be seen as two consecutive refinements by the factor n followed by a refinement with factor m or vice versa. Fig. 6 shows such an iterative refinement of the time scale. We get the following obvious rules: FINE(n*m) = FINE(n) ◦ FINE(m) COA(n*m) = COA(n) ◦ COA(m) We are in particular interested to analyze how time refinement relates to causality. This relationship is illustrated by the following equation (let m, n ∈ IN with m ≥ 1): delay(F, n*m) ⇒ delay(COA(F, m), n)


107

... 3 0

9 6

15 12

Figure 6. Refinement of the time scale by 6: shown as a refinement by the factor 3 followed by a refinement by the factor 2

The proof of this rule is quite straightforward and uses the fact that (COA(m).x)↓t = COA(m).(x↓(t*m)) holds. This rule is, in particular, interesting for our discussion of time, time abstraction, and causality. As long as we coarsen a behavior F for which delay(F, n) holds at most by factor n causality is still guaranteed for the resulting component. In fact, there exists a kind of monotonicity of coarsening with respect to delay properties: n < m ∧ delay(COA(F, m), k) ⇒ delay(COA(F, n), k) Again the proof is straightforward and left to the reader. If we coarsen the time scale we may lose strong causality, in general. In other words, the property of strong causality is depending on a fine enough granularity of the time scale. The following equation does not hold for the operator FINE, in general. It holds only for the version DFINE of FINE that increases the delay. delay(F, n) ⇒ delay(DFINE(F, m), m*n) To keep this formula valid we cannot replace the operator DFINE by FINE. 5.3. Fractions of Time Changes We can even change in a behavior the time by fractions m/n for m, n ∈ IN using the time change operator TCH. TCH(F, m/n) = COA(FINE(F, n), m) Note that all the rules introduced so far for COA and FINE carry obviously over to this case, since we expressed TCH in terms of COA and FINE. 5.4. Choosing the Appropriate Time Scale We have discussed how closely the time scale is related to the property of causality. It depends very much on the time scale whether a behavior is strongly causal as well as on the delay properties of the components. In a large system with many components, different

108


time scales may be appropriate for different subsystems. In the remainder of this section we study therefore an idea of flexible timing. Complex hierarchical distributed systems require a flexible time model such that its time granularity can be adapted individually to the needs of its various subsystems. This leads to the following idea: We establish and model different time scales for the subsystems of a composed system. Then we can choose the time scales in a flexible way, according to the following observations: • for each system composed of strongly causal components its time delay is greater than the length of the shortest path of channels through the system of components. • therefore we can coarsen the interface abstraction of the system by the factor k without loosing strong causality provided the shortest path is ≥ k. This leads to hierarchical system models that support local islands (“subsystems”) of finer granularity of time. A system may be composed of many subsystems with their own finer time scales. To discuss this idea in detail we have first to introduce a notion of composition. 5.5. Causal Fixpoints and Causal Loops Given a strongly causal function → − → − F: C → C each fixpoint y ∈ F.y is called causally faithful or for short causal. In a causal fixpoint each sequence of values in a time interval t is triggered by the values that occurred in the history before t. Now we consider a coarsening of the time for the function F → − → − COA(F, n): C → C We get for each fixpoint y ∈ F.y that COA(n).y is a fixpoint of COA(F, n), too. But there may be fixpoints COA(F, n) that do not correspond to fixpoints of F. A fixpoint y’ ∈ (COA(F, n)).y’ is called causal w.r.t. F if there is a fixpoint y ∈ F.y such that y’ = COA(n).y. Otherwise y’ is called a causal loop. We will show that considering COA(F, n) alone without knowing F we cannot distinguish, in general, causal fixpoints from causal loops. In other words, if we choose the time scale too coarse such that the resulting function is not strongly causal we may lose the faithful notion of causality and compositionality and cannot distinguish causal from not causal fixpoints. Let us consider a simple function → − → − IDS: C → ℘( C ) with the specification (for all channels c ∈ C)


109

(IDS.x).c = { ^(x.c) } IDS is the identity on the data streams shifted by one time interval. Now we consider the history x.c = 1∞ for all c ∈ C we get (IDS.x).c = 1∞ for all c ∈ C This shows that x is not a fixpoint of IDS. Now we consider COA(2).IDS. We get: COA(2).1∞ = { 1∞ } COA(2).1∞ = { 1∞ } This proves the fixpoint property 1∞ ∈ (COA(2).IDS).1∞ So 1∞ is a fixpoint of COA(2).IDS. However, this fixpoint is not causal, since ∞ is the only fixpoint of IDS as well as COA(IDS, 2). This shows that coarsening a behavior F leads to functions F’ with additional fixpoints that are not causal in the case that F’ is, in contrast to F, not strongly but only weakly causal. Moreover, we cannot distinguish, in general, for these functions causal from non-causal fixpoints. 5.6. Delay Calculus for System Architectures By composition of a family of components we can form a network (representing an architecture) of components with delays. This network is a directed graph with channels as arcs and components as nodes. With each path in the graph leading from an input channel to an output channel c we can associate a delay which is the sum of all delays on that path (each component on the path adds to the delays). For an output channel c the (guaranteed) delay in the system for c is the minimum over the sum of delays on each of the paths from some input channel to the output channel c. In a behavior function we can define the guaranteed delay between an input channel and an output channel. Consider → − → − F: I → ℘( O ) and an output channel c’ ∈ O and an input channel c ∈ I. We define the guaranteed delay for the output channel c’ in F by the following formula: gardelay(F, c’) = → − max {k ∈ IN ∪ ∞ }: ∀ x, x’ ∈ I , t ∈ IN : x↓t = x’↓t ⇒ ((F.x).c’)↓t+k = ((F.x’).c’)↓t+k}

110


In a composed system we define the delay length of a path from an input channel c to an output channel c’ as follows: A path is a sequence of channels p = c0 c1 . . . ck such that for each index i < k there exists a component Fi in the system such that ci is an input channel of Fi and ci+1 is an output channel of that component. c0 is called the source of p and ck is called the target of p. By Path(c, c’) we denote the set of all paths with source c and target c’. The delay length of the path is given by the formula dl(p) =

k i=1

gardelay (Fi , ci )

For each output channel c’ for the system F represented by the considered network we obtain: gardelay(F, c’) ≥ min {dl(p): p ∈ Path(c, c’)} Given lower bounds for the delays between the components we can calculate lower bounds for the delays for output channels in composed systems. 5.7. Composition and Delay Using our composition operators we can construct system architectures represented by data flow nets. In this section we study how to calculate the delay of composed systems from the delay profile of their components. For each component of the considered system, we can define a (maximal) guaranteed delay for each output channel. Given a component → − → − F: I → ℘( O ) we introduce mappings d: I → IN ∪ {∞}, e: O → IN ∪ {∞} that associate a delay with every input and output channel. To calculate the guaranteed delay of a network of components, we have to be able to determine the delay of F if for each of its input channels a delay is given. guaranteed delay on input

I

{ {

O

t

guaranteed delay on output

time

Figure 7. Relationship between input with guaranteed delay and output with guaranteed delay at time t


111

We are interested in the delay of a component that is inside a large architecture given by a data flow graph (with feedback loops). If we give input to the data flow graph till time t ∈ IN then we assume that for each channel c ∈ I the stream (x.c)↓(t+d.c) determined by that input to the network till time t. x 1: M 1 [ d . x 1 ]

y 1 : N 1 [ e . y1 ]

F x n: M n [ d . x n ]

yn : N n [ e . yn ]

Figure 8. Delay Profile in a Graphical Representation

From this delay of the input we guarantee a delay for the output channels at time t, if d.b is the guaranteed delay on input channel b ∈ I; thus the input (x.b)↓(t+d.b) is fixed at time t. We write isdelay(F, d, e) for the logical proposition that holds, if for all times t ∈ IN we have (here we assume that for a stream s the partial stream s↓j is empty if j ≤ 0) → − ∀ x, z ∈ I : [∀ b ∈ I: (x.b)↓(t-d.b) = (z.b)↓(t-d.b)] ⇒ [∀ c ∈ O: {(y.c)↓t+e.c : y ∈ F.x} = {(y.c)↓t+e.c : y ∈ F.z}] This formula expresses that the input on channel b affects the output on channel c at most after e.c time steps provided fresh input arrives on the input channels only after the times as described by d. We call then the functions d: I → IN ∪ {∞}, e: O → IN ∪ {∞} a delay profile. A delay profile can be graphically represented by an annotated data flow node as show in Fig. 8. d

1

d

1

1

F1

e

1 1

d

2

2 2

d

2 1

F2

e

1 2

e

2 2

e

2 1

Figure 9. Delay Profile for the Components in a Composition (suppressing channel identifiers)

112


Let al the definitions be as in the section on composition. For a composition we get graphical representations of the delay profiles of the components as shown in Fig. 9.

F1

F2

1

2

F3

2

3

F4

1

2

4

Figure 10. Network of Components with given Delay for each Channel)

Given d: (I1 ∪ I2 ) → IN ∪ {∞}, e: (O1 ∪ O2 ) → IN ∪ {∞} we only have to assume for dk = d|Ik and ek = e|Ok for k = 1, 2: isdelay(F1 , d1 , e1 ) as well as isdelay(F2 , d2 , e2 ) and for the feedback (by d12 = d1 |(I1 ∩ O2 ) we denote the vector of delays for the channels in (I1 ∩ O2 ), by d22 = d2 |(I2 ∩ O1 ) we denote the vector of delays for the channels in (I1 ∩ O2 ), by e22 = e2 |(I1 ∩ O2 ) we denote the vector of delays for the channels in (I1 ∩ O2 ), by e12 = e1 |(I2 ∩ O1 ) we denote the vector of delays for the channels in (I1 ∩ O2 )) d12 ≤ e22 ∧ d22 ≤ e12 to guarantee isdelay(F1 ⊗ F2, d|I, e|O). Note that the guaranteed delay of a feedback channel c ∈ (I1 ∩ O2 ) ∪ (I2 ∩ O1 ) must be greater at the output than the assumed at the input to guarantee a faithful fixpoint and strong causality. This way of asserting delays of composition can be captured in a simple proof rule.


9

0

0

F1

F2

6

3 F3

5

113

2

3

F4

6

9

4

Figure 11. Network of Components with Accumulated Delay for each Channel

5.8. Optimal Delay Profile In his section we show how to calculate optimal delay profiles for composed systems. We assume that ∀ c ∈ I1 ∩ I2 : d1 .c = d2 .c isdelay(Fi , di , ei ) for i = 1, 2 ∀ c ∈ I1 ∩ O2 : d1 .c ≤ e2 .c ∀ c ∈ I2 ∩ O1 : d2 .c ≤ e1 .c to guarantee that isdelay(F1 ⊗ F2 , d, e) holds, where I = (I1 \O2 ) ∪ (I2 \O1 ), O = (O1 ∪ O2 ) and d: I → IN ∪ {∞}, e: O → IN ∪ {∞} are functions defined by the equations: ⎧ 1 ⎪ if c ∈ I1 \I2 ⎨d .c ∀ c ∈ I : d.c = d2 .c if c ∈ I2 \I1 ⎪ ⎩ 1 2 min(d .c, d .c) if c ∈ I1 ∩ I2 ⎧ 1 ⎪ if c ∈ O1 \O2 ⎨e .c ∀ c ∈ O : e.c = e2 .c if c ∈ O2 \O1 ⎪ ⎩ 1 2 min(e .c, e .c) if c ∈ O1 ∩ O2 These rules allow us to calculate and prove delays in a modular way for composed systems given delays for their components. We construct the maximal guaranteed delay b for the feedback loops in a composition. We assume that for all i ∈ {1, 2}

114


isdelay(Fi , di , ei ) holds and that for all channels c ∈ I1 ∩ O2 d1 .c ≤ b.c and for all c ∈ I2 ∩ O1 d2 .c ≤ b.c where input delay b is defined as b: I1 ∪ I2 → IN with b.c = max {bk .c: k ∈ IN} and where we inductively calculate the delays bk : I1 ∪ I2 → IN as follows b0 .c = 0 b0 .c = di .c

if c ∈ C if c ∈ Ii \C

where C is the set of feedback channels C = (I1 ∪ I2 ) ∩ (O2 ∪ O1 ). The delays bk+1 are defined inductively by bk+1 .c = di .c for c ∈ Ii \C bk+1 .c = a.c for c ∈ C where the delay a: O1 ∪ O2 → IN is the maximal numbers such that isdelay(Fi , bk |Ii , a|Oi ) holds. Note that b is the “least fixpoint” of the delay function. The construction uses as its basis the compositionality of the calculus. 5.9. Deducing Delay Equations We consider a network N with interface behavior FN with a number of systems as data flow nodes. Let C be the set of all channels in the net N. We want to calculate a delay profile d: C → IN ∪ {∞}


115

With every system behavior F in in the networkwe may associate a function gdelF (c): IN × . . . × IN → IN for every output channel c defined by gdelF (c)(d.c1 , . . ., d.cn ) = max {k ∈ IN ∪ {∞} : ∀ x, z: ∀ b ∈ I: (x.b)↓(t-d.b) = (z.b)↓(t-d.b)] ⇒ {(y.c)↓t+k: y ∈ F.x} = {(y.c)↓t+k : y∈ F.z} This equation calculates the maximal guaranteed delay for channel c given the delays d.c1 , . . . , d.cn for the input channels of F. To calculate for every channel c in the network its delay d.c we associate with every node and every output channel c of one of the nodes F the equation d.c = gdelF (c)(d.x1 , . . ., d.xn ) For the input channels c we assume d.c = 0 We get an equation for each channel c ∈ C. It is easy to show that the functions gdelF (c) are all monotonic. Therefore there exists a least fixpoint d for the equations which is the delay profile.

6. Composition and the Choice of the Time Scale In this chapter we study the question how time abstraction and composition fit together. A compositional formula for time refinement should read as follows: COA(F1 ⊗ F2 , n) = COA(F1 , n) ⊗ COA(F2 , n) However, this formula does not hold, in general, since making a behavior coarser is an information loss that may result in the loss of strong causality and thus may introduce “causal loops”. The time abstraction is the origin of the problems with causal loops in approaches advertised under the name “perfect synchrony” such as Esterel (see [8]). Moreover, the individual timing of the subcomponents may be highly relevant for selecting the behaviors (the output histories). 6.1. Strong Causality and Compositionality of Coarsening In this section we study cases that guarantee the validity of the equation COA(F1 ⊗ F2 , n) = COA(F1 , n) ⊗ COA(F2 , n) As we will explain in section 8, coarsening is fundamental for a flexible timing of large systems architectures. That this equation does not hold, in general, can immediately be concluded from our discussion of causal and not causal fixpoints.

116


Theorem: Let F1 and F2 be behaviors that can be composed (according to consistent channel naming and typing); then the following equation holds COA(F1 ⊗ F2 , n) ⊆ COA(F1 , n) ⊗ COA(F2 , n) Proof: By definition the statement (let all definitions as in the definition of ⊗) y ∈ (F1 ⊗ F2 ).x stands for: there exists a history z for all channels in I1 , I2 , O1 , and O2 such that y = z|O and z|I = x|I ∧ z|O1 ∈ F1 (z|I1 ) ∧ z|O2 ∈ F2 (z|I2 ) Now let us assume y’ ∈ COA(F1 ⊗ F2 , n).x’; then there exists y ∈ (F1 ⊗ F2 ).x such that x’ = COA(n).x and y’ = COA(n).y and there exists z such that y = z|O and z|I = x|I ∧ z|O1 ∈ F1 (z|I1 ) ∧ z|O2 ∈ F2 (z|I2 ) From this we get with z’ = COA(n).z: z’|I = x’|I ∧ z’|O1 ∈ COA(n).F1 (z|I1 ) ∧ z’|O2 ∈ COA(n).F2 (z|I2 ) Since by definition of COA(n) we get COA(n).(F.x) ⊆ COA(F, n).(COA(n).x) we get z’|I = x’|I ∧ z’|O1 ∈ COA(F1 , n).(COA(n).(z|I1 )) ∧ z’|O2 ∈ COA(F2 , n).(COA(n).(z|I2 )) and finally z’|I = x’|I ∧ z’|O1 ∈ COA(F1 , n).(z’|I1 ) ∧ z’|O2 ∈ COA(F2 , n).(z’|I2 ) which proves that y’ ∈ (COA(F1 , n) ⊗ COA(F2 , n)).x’ and thus that COA(F1 ⊗ F2 , n) ⊆ COA(F1 , n) ⊗ COA(F2 , n)

❑


117

The theorem shows that COA(F1 ⊗ F2 , n) is a refinement of COA(F1 , n) ⊗ COA(F2 , n) The converse statement is not true, in general. It holds only if both F1 and F2 are not sensitive to the finer timing. Theorem: → − Let n > 1 hold. Assume for i = 1, 2 that we have (for all x, x’ ∈ I ) COA(n).x = COA(n).x’ ⇒ Fi .x = Fi .x’ and that delay(Fi, n) holds, then we get: COA(F1 , n) ⊗ COA(F2 , n) ⊆ COA(F1 ⊗ F2 , n) Proof: The proof that under the given assumptions the formula holds uses the stepwise construction of the history z such that z|I = x|I ∧ z|O1 ∈ F1 (z|I1 ) ∧ z|O2 ∈ F2 (z|I2 ) for any given z’ with z’|I = x’|I ∧ z’|O1 ∈ COA(F1 , n).(z’|I1 ) ∧ z’|O2 ∈ COA(F2 , n).(z’|I2 ) with z’ = COA(n).z. Note that y’ ∈ (COA(F1 , n) ⊗ COA(F2 , n)).x’ if such a history z’ exists with y’ = z’|O. From the existence of z we can conclude y’ = COA(n).z and y’ ∈ COA(F1 ⊗ F2 , n). This construction is inductive and uses the fact that the behaviors are strongly causal. Since delay(Fi , n) holds for i = 1, 2, we can conclude that COA(Fi , n) is strongly causal for i = 1, 2. By the assumption we get for any history d and b such that b ∈ COA(Fi , n).(COA(n).d) with the history a ∈ Oi → (M*)n∗k specified by a = (COA(n).b)↓(n*k) and a ∈ (Fi .d)↓(n*k)

118


that there exists a history a’ ∈ Oi → (M*)n∗(k+1) such that a’ = (COA(n).b)↓(n*(k+1)) and a’ ∈ (Fi.d)↓(n*(k+1)) Now let y’ ∈ (COA(F1 , n) ⊗ COA(F2 , n)).(COA(n).x) hold; then there exists a history z’ such that y’ = z’|O and z’|I = x’|I ∧ z’|O1 ∈ COA(F1 , n).(z’|I1 ) ∧ z’|O2 ∈ COA(F2 , n).(z’|I2 ) We construct a history z such that z’ = COA(n).z holds and z|I = x|I ∧ z|O1 ∈ F1 (z|I1 ) ∧ z|O2 ∈ F2 (z|I2 ) inductively as follows: Since delay(Fi , n) holds there exists a history z(0) ∈ C → (M*)n such that z’↓1 = COA(n).z(0) and for every z” we have (for i = 1, 2) z(0) |I = (x↓n)|I ∧ z(0) |Oi ∈ Fi .(z(0) ^z”|Ii )↓n This follows from the fact that Fi .a↓n = Fi .b↓n for all a, b since delay(Fi , n) holds and therefore COA(n).(Fi .(z(0) ^z”|Ii )↓n) = (COA(Fi , n).(z’|I2 ))↓1 Given z(k) ∈ C → (M*)n∗(k+1) where z’↓(k+1) = COA(n).z(k) and z(k) |I = (x↓(n*(k+1)))|I ∧ z(k) |Oi ∈ Fi .(z(k) ^z”|Ii )↓(n*(k+1)) there exists z(k+1) ∈ C → (M*)n∗(k+2) such that z(k+1) |I = (x↓(n*(k+2)))|I ∧ z(k+1) |Oi ∈ Fi .(z(k+1) ^z”|Ii )↓(n*(k+2)) This follows from the fact that


119

Fi (z(k) |Ii â)↓n = Fi (z(k) |Ii ^b)↓(n*k) for all a, b since delay(Fi , n) holds and therefore COA(n).(Fi .(z(k) ^z”|Ii )↓(n*k)) = (COA(Fi , n).(z’|I2 ))↓k By induction we get for all k: z’↓(k+1) = COA(n).z(k) and z(k) |I = (x↓(n*(k+1)))|I ∧ z(k) |Oi ∈ Fi .(z(k) ^z”|Ii )↓(n*(k+1)) and thus for z with z↓(n*(k+1)) = z(k) for all k z’ = COA(n).z(k) and z|I = x|I ∧ z|Oi ∈ Fi .(z|Ii ) This proves that COA(F1 , n) ⊗ COA(F2 , n) ⊆ COA(F1 ⊗ F2 , n) and thus concludes the proof.

❑

Moreover, if a component is time independent, then we have the validity of the following equation: COA(F, n).COA(n).x = COA(n).(F.x) However, in contrast to problems when coarsening behaviors the equation FINE(F1 ⊗F2 , n) = FINE(F1 , n) ⊗ FINE(F2 , n) does always hold, as long as F1 and F2 are strongly causal. 7. Pros and Cons for Strong Causality As formulated in the hypothesis above, we may assume that for each model of a physical system behavior there is a time scale that is fine enough to capture all essential time differences especially for the delay between input and output to guarantee the property of strong causality. Modeled in an appropriate time scale the behavior is always strongly causal according to the principle of strong causality. Strong causality has a number of significant advantages since it makes the reasoning about systems more concrete and simpler since reasoning about feedback loops is

120


reduced to induction. In particular, it is easy to treat feedback loops by fixpoints for strongly causal behaviors since strong causality guarantees, in particular, the existence of unique fixpoints for deterministic functions. In other words, for strongly causal, fully realizable system behaviors all fixpoints are causal and thus computationally appropriate in the sense that they faithfully reflect computations. The disadvantage of strong causality is its limited abstractness illustrated for instance by the fact that in sequential composition delays accumulate. This well known effect observed for the composition of strongly causal components can nicely be demonstrated for pipelining. Let the behaviors F1 : I1 → ℘(O1 ), F2 : O1 → ℘(O2 ) be given. We obtain delay(F1 , m) ∧ delay(F2 , n) ⇒ delay(F1 ◦ F2 , m+n) In the case of two strongly causal functions F1 and F2 we get (at least) delay(F1 ◦ F2 , 2) On one hand this observation is very satisfactory since it leads to a useful delay calculus (see above). On the other hand it shows an unfortunate inflexibility of the design calculus for timed systems. If we want to represent a function by an architecture with two functions composed by pipelining we always have to accept a delay by at least 2 if the functions are strongly causal. In fact, if we insist on a delay less than 2 then a component cannot be implemented by a system consisting of two components composed sequentially. This seems unacceptable, since it makes the design very inflexible, and seems to be a good reason to reject our approach based on a global discrete time altogether. In the remainder of this paper we deal with this issue and show how to gain the necessary flexibility. The choice of the time granularity is crucial for the behavior. As a result of strong causality composition is not as abstract as wanted and needed. A sequentially composed system with strongly causal components shows always delays larger than one. This difficulty can be avoided by lowering the constraint of strong to weak causality. But then the characterization of fixpoints being causally sound and computationally realistic is no longer guaranteed and the reasoning about fixpoints and the characterization of causally correct fixpoints gets much more involved or even impossible. Fixpoints are of major interest for systems since they are the classical technique to give meaning to feedback loops, mutual interaction, and recursive definitions of behaviors. A feedback loop introduced for a behavior F with input channel e and output channel c is specified by a fixpoint characterization x.e ∈ {y.c: y ∈ F.x} → − → − Let us consider a function F: C → ℘( C ). Feeding back all its channels corresponds to the fixpoint property x ∈ F.x. This property characterizes the computations in feedback loops correctly if F is strongly causal. Otherwise there may occur fixpoints that are computationally infeasible since they are the result of so-called causal loops. A causal loop


121

yields a fixpoint where certain output is produced under the assumption that this output is fed back within the same time interval as the corresponding input (“self fulfilling prophecy”). There exist fixpoints that are not causal in the sense that they do not reflect proper computations. We demonstrate this observation by some simple examples. For a feedback loop a fixpoint is causal, if all produced output is actually caused by some input or – more precisely – is enforced by some input that is available before the output is generated. This corresponds to the well-known concept of least fixpoints and inductive definitions that reflect in an abstract manner a concept of computation. A fixpoint is not causal, if there is output that is produced before the corresponding input arrives which then in turn is used as the corresponding input in a feedback loop to “logically justify” the output. Example: Causal loops for the identity function Let us consider as a simple example the weakly causal time independent identity function ld characterized by the equation Id.x = x In fact there are many time independent identity functions (functions that fulfill the equation above) that are only distinct with respect to their time delay and timing. In particular, there is a weakly causal identity function that fulfills the following specification Id.x = {x’: x’ = x ∧ ∀ t ∈ IN: #x ↓ t ≤ #x ↓ t } A strongly causal version of the identity shows in addition the property Id.x ↓ k + 1 x ↓ k

(*)

If we are looking for a fixpoint x ∈ Id.x we easily prove for a strongly causal version by induction from the equation (*) the expected property x = . For the most general, only weakly causal identity Id.x = x↑, however, each history is a fixpoint. For a weakly causal version of the identity function Id the proof that x ∈ Id.x ⇒ x = as shown for strong causality does not work. There are fixpoints x ∈ Id.x that are not the empty history (i.e. x = ) and do not represent causal computations, of course. An example is the history x with x.t = 1 for all t ∈ IN. Such fixpoints do not reflect feasible “causally proper” computations. They are not causal and instances of a causal loop. ❑ Weak causality is the result of selecting too coarse time scales. It leads to models that are too abstract. As a result, in these models composition may not be operationally faithfully definable since fixpoints may correspond to causal loops and – even worse – we cannot distinguish between causal and non-causal fixpoints, in general. Strong causality allows us to avoid causal loops at the cost of less abstract models. Strong causality provides a computationally faithful, more down to earth model of composition and interaction.

122


8. A Compromise We have extensively discussed so far the advantages and disadvantages of strong in contrast to weak causality. Weak causality is transparent w.r.t. composition. A weakly causal component can always be decomposed into a system of weakly causal components with feedback loops and sequential composition, which does not hold for strongly causal components. Strong causality is not abstract enough, while weak causality is too abstract in cases of feedback loops and fixpoints. The challenge is to combine the advantages of weak and strong causality. In this section we look for a methodological compromise that incorporates as much as possible of both their advantages and avoids most of their disadvantages by supporting a refinement of time. 8.1. Strongly and Weakly Causal Behaviors In this section we explore possibilities to identify causal fixpoints for weakly causal behaviors. In fact, there is a natural implicit notion of strong causality that applies even for weakly causal systems. Definition: Causality An I/O-behavior (that is weakly causal) → − → − F : I → ℘( O ) is called causal (properly timeable), if there exists a number n ∈ IN and a strongly causal function → − → − F’ : I → ℘( O ) such that F = COA(F’, n).

❑

In other words, in the definition above F is a causal function that is weakly causal and can be understood as an abstraction (by time coarsening) of some strongly causal function F’. The critical question, however, is if such a strongly causal function is unique and thus leads to a canonical construction of causal fixpoints. Every fixpoint of the strongly causal function F’ is a fixpoint of the weakly causal function F since x ∈ F’(x) ⇒ COA(n).x ∈ COA(n).F’(x) ⇒ COA(n).x ∈ COA(F, n).COA(n).x Given a weakly causal function F the existence of a strongly causal function F’ such that F is an abstraction of F’ does not really help, however, to separate faithful fixpoints from causal loops. There are cases where there are several choices of strongly causal behaviors F’, say F1 ’ and F2 ’, such that some fixpoints of F are causal for F1 ’ but not for F2 ’. This leads to the following fact: time abstractions may lose the notion of strong causality leading to models where we cannot distinguish causal from non-causal fixpoints. The information loss by time abstraction is therefore critical, in general, and does not allow any longer distinguishing causal from non-causal fixpoints.


123

We illustrate this problem by an example. First we show an example where weak causality works. Example: Identity Consider again some identity function F with F (x) = x. We can prove that fix F is the empty stream. The proof is essentially the same as the one given above. We assume that there is a strongly causal function and that every causal fixpoint of F corresponds to a fixpoint of the strongly causal function. This way we easily deduce x = for every fixpoint. ❑ This shows that the assumption of strong causality leads to proof principles for systems with feedback loops. But the assumption does not allow us to rule out non-causal fixpoints in a canonical way, in general. Only strong causality guarantees that all fixpoints are causal and that we do not have fixpoints for which we do not know whether they are causal or not. Finally to demonstrate the significance of strong causality let us look at a slightly trickier example. We consider a function F with the following characteristic behavior: x 1 1 1

F.x {, 1} {1, 1 1} {1 1}

Depending on the structure of its timing the history x with x = 1 can be a causal ∞ fixpoint or not (here denotes the infinite stream with empty sequences of messages in each time interval) depending on the actual definition of F. The following table shows a particular version of F: x ∞ 1^∞ 11^∞

F.x {∞ , 1^∞ } {∞ , 1^∞ , 11^∞ } {∞ , 1^∞ , 11^∞ }

In this case F is (more precisely, can be extended to) a strongly causal function and the stream 1^∞ is a causal fixpoint. Now consider the strongly causal function F’ with the following characteristic behavior x ∞ 1^∞ 11^∞

F’.x { , 1^∞ } ∞ { , 1^∞ , 11^∞ } {∞ , 1^∞ , 11^∞ } ∞

In this case 1^∞ is not a causally correct fixpoint of F’, although F.x and F .x do coincide. In such a case, the timing of the output is essential for determining the causality of fixpoints and therefore for determining which of the fixpoints are causal.

124


9. Causality, Time, and Composition As we have shown causality is essential for an inductive reasoning about composed systems with feedback loops. 9.1. Causality and Composition → − → − Given a set of specified components we get for each component F: I → ℘( O ) with the relational specification (“specifying assertion”) for y ∈ F.x in the form of a predicate P: P(x, y) by imposing causality the logical weakest specification Pc that fulfills the following equation Pc(x, y) ≡ P(x, y) ∧ ∀ t ∈ IN: ∃ x’ : x’↓t = x↓t ⇒ ∃ y’: Pc(x’, y’) ∧ y’↓t+1 = y↓t+1 This way we can add the requirement of strong causality to every specification to get a strongly causal specification. Note, that the specification may become inconsistent if the original specification contradicts the notion of strong causality. As well-known (and straightforward to prove) if we compose strongly causal systems we get again strongly causal systems. 9.2. Composition and Coarsening Time If we compose strongly causal systems their time delays accumulate. For instance, if each component has a time delay of at most one, then computing the time delay of a composed system is the result of calculating the minimal number of delays of components on the shortest path from an input to an output channel. This allows us to calculate delays in architectures of composed systems. But sometimes we may be interested in a more abstract view on the function computed by an architecture. If we work with a component F with delay k, we easily construct a strongly causal component of delay one by the component COA(F, k) This construction can be understood as a way to abstract from the finer time scale used inside for the sub-systems of a system to a coarser time scale outside of the system. We may speak of a macro/micro time scale. As long as we are not interested in the fine grained notion of time such an abstraction is certainly appropriate. It is the best abstraction maintaining crucial notions such as causal fixpoints and ways to reason about them. 9.3. Local Timing The flexibility of our timing calculus can be seen in the following by demonstrating how we can work with local timing and local clocks.


125

Figure 12. Hierarchical Architectures of Components with Different Time Scales

For each subsystem (subcomponent) of a network we can introduce a local time and a local time granularity. This idea is demonstrated by a simple example. Example: Architecture with local Time Granularities The following expression COA(COA(F⊗G, 10)⊗COA(H⊗K, 20)⊗L, 2) denotes a system with a subsystem F⊗G which works in a 10 times faster mode H⊗K which works in a 20 times faster mode This way we get a system with different local time scales where each time scale can be chosen fine enough for each of the components locally to guarantee strong causality of each of its subcomponents such that all local computations are captured on the right level of time granularity. The components operate locally on a higher frequency. Since delays accumulate in a system the larger components composed of many subcomponents show typically larger delays such that we can choose coarser time granularity for them without losing strong causality. ❑ Fig. 12 shows an informal example of a complex system composed of three subsystems each of which is composed of four components. For each of the subsystems we may select local proprietary time granularity. 9.4. Multiplexing of the Components of a Network on one CPU In general, we cannot expect that each dedicated node in a data flow net always runs on its own CPU. We rather expect that a complete net or sub-net of components is executed on

126


one CPU. Then the multiplexing of the components, which may be running at different speed, have to be mapped by a scheduling onto the CPU cycles. 9.5. Avoiding Causal Loops In the following we finally discuss the problem of causal loops. We show how we can add strong causality as a property to specifications to reason about feedback loops. Example: Interface specification Consider the following specification of a component that copies its input on channel x on both of its output channels y and r. Copy in x: T out y, r: T x=y∧x=r Strong causality as an assumption on the specification Copy allows us to conclude in addition to the specifying assertion the following property: ∀ t ∈ IN: ∀ m ∈ T: {m}#r ↓ t + 1 ≤ {m}#x ↓ t ∧ {m}#y ↓ t + 1 ≤ {m}#x ↓ t where M#x denotes the number of copies of messages in the set that occur in x. Another example is the specification of component Repeater, which repeats each of its inputs infinitely often. Its specification reads as follows: Repeater in r: T out x: T ∀ m ∈ T: {m}#r > 0 ⇒ {m}#x = ∞ ∧ {m}#r = 0 ⇒ {m}#x = 0 Strong causality allows us to conclude in addition to the specifying assertion the following property ∀ t ∈ IN: ∀ m ∈ T: {m}#r ↓ t = 0 ⇒ {m}#x ↓ t + 1 = 0 Now let us compose the two components into the composed system characterized by the term Repeater ⊗ Copy as shown in Fig. 13. We get a system that forms a feedback loop. If we want to reason about the composed system, we have to refer to the assumption of strong causality to reason about the system in a way where we avoid causal loops. Without strong causality arguments we get the following formula:


127

y x

Copy r x

r Repeater Figure 13. Composition Repeater ⊗ Copy

x=y∧x=r ∧ ∀ m ∈ T: {m}#r > 0 ⇒ {m}#x = ∞ ∧ {m}#r = 0 ⇒ {m}#x = 0 which simplifies to x = y ∧ x = r ∧ ∀ m ∈ T: {m}#r > 0 ⇒ {m}#r = ∞ which indicates for the output y of the network only ∀ m ∈ T: {m}#y > 0 ⇒ {m}#y = ∞ With strong causality arguments we get in addition the assertion ∀ t ∈ IN: ∀ m ∈ T: {m}#r ↓ t + 1 ≤ {m}#x ↓ t ∧ {m}#r ↓ t ≤ {m}#x ↓ t ∧ ∀ t ∈ IN: ∀ m ∈ T: {m}#r ↓ t = 0 ⇒ {m}#x ↓ t + 1 = 0 that allows us to conclude (by a simple inductive argument) the validity of the following formula y = which cannot be concluded without strong causality.

10. Conclusion: ROBUST Flexible Timing The goal of this paper was to show the relationship between causality and the choice of the time scale and granularity as well as its influence onto compositionality. The main issues here were the dependencies between the time scale and composition with feedback. If we choose the time scale fine enough the definition of faithful composition is quite straightforward. Our approach supports flexibly chosen time scales. We worked out the following idea of flexible timing:

128


• The leaves of the component hierarchy are state machines. • Each state machine runs in its own local time scale that defines the time duration of each of its steps • Each processor (CPU, controller) contains a family of state machines which run with different speed (time granularity). This defines the finest time grain steps and the set of steps (state transitions) that have to be executed (scheduled) in a time slot. This determines the workload. So we can design a static schedule at the abstract level of behavior without being forced to address low-level technical issues such as schedulers or operating systems. Moreover, by strong causality we get a very robust inductive technique for reasoning by feedback. We obtain a flexible and modular theory of timing of systems and sub-systems this way which provides the following helpful properties • • • • • • •

high level abstract and flexible modeling multiplexing and scheduling on abstract level application oriented time model close to hardware time model causality for inductive reasoning avoiding causal loops rich algebraic properties discrete model of time that provides the same flexibility as analog models of time (real time) • time abstraction by coarsening the time granularity to get rid of unwanted delays. In the end we can generate from such a time model a static scheduling for the system.

References [1] M. Abadi, L. Lamport: The Existence of Refinement Mappings. Digital Systems Research Center, SRC Report 29, August 1988 [2] M. Abadi, L. Lamport: Composing Specifications. Digital Systems Research Center, SRC Report 66, October 1990 [3] L. Aceto, M. Hennessy: Adding Action Refinement to a Finite Process Algebra. Proc. ICALP 91, Lecture Notes in Computer Science 510, 1991, 506-519 [4] P. Andrews: An Introduction to Mathematical Logic and Type Theory: To Truth Through Proof. Computer Science and Applied Mathematics. Academic Press 1986 [5] R.J.R. Back: Refinement Calculus, Part I: Sequential Nondeterministic Programs. REX Workshop. In: J. W. deBakker, W.-P. deRoever, G. Rozenberg (eds): Stepwise Refinement of Distributed Systems. Lecture Notes in Computer Science 430, 1989, 42-66 [6] R.J.R. Back: Refinement Calculus, Part II: Parallel and Reactive Programs. REX Workshop. In: J. W. de Bakker, W.-P. de Roever, G. Rozenberg (eds): Stepwise Refinement of Distributed Systems. Lecture Notes in Computer Science 430, 1989, 67-93 [7] L. Bass, P. Clements, R. Kazman: Software Architecture in Practice. Reading, MA: Addison-Wesley 1998 [8] G. Berry, G. Gonthier: The E STEREL Synchronous Programming Language: Design, Semantics, Implementation. INRIA, Research Report 842, 1988 [9] G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language for Object-Oriented Development. Version 1.0. RATIONAL Software Cooperation [10] J. Botaschanjan: Techniques for Property-Preservation in theDevelopment of Real-Time Systems. Dissertation, Technische Universität München, Fakultät für Informatik 2008 [11] J. D. Brock, W. B. Ackermann: Scenarios: A Model of Nondeterminate Computation. In: J. Diaz, I. Ramos (eds): Lecture Notes in Computer Science 107, Springer 1981, 225-259


129

[12] M. Broy: Mathematical System Models as a Basis of Software Engineering. J. van Leeuwen (ed.): Computer Science Today. Lecture Notes of Computer Science 1000, 1995, 292-306 [13] M. Broy: Algebraic Specification of Reactive Systems. M. Nivat, M. Wirsing (eds): Algebraic Methodology and Software Technology. 5th International Conference, AMAST ‘96, Lecture Notes of Computer Science 1101, Heidelberg: Springer 1996, 487-503 [14] M. Broy: The Specification of System Components by State Transition Diagrams. Technische Universität München, Institut für Informatik, TUM-I9729, May 1997 [15] M. Broy: Towards a Mathematical Concept of a Component and its Use. First Components’ User Conference, Munich 1996. Revised version in: Software-Concepts and Tools 18, 1997, 137-148 [16] M. Broy: Refinement of Time. M. Bertran, Th. Rus (eds.): Transformation-Based Reactive System Development. ARTS’97, Mallorca 1997. Lecture Notes in Computer Science 1231, 1997, 44-63, To appear in TCS [17] M. Broy: Compositional Refinement of Interactive Systems. Digital Systems Research Center, SRC Report 89, July 1992, Also in: Journal of the ACM, Volume 44, No. 6 (Nov. 1997), 850-891 [18] M. Broy: Interaction and Realizability, In: Jan van Leeuwen, Giuseppe F. Italiona, Wiebe van der Hoek, Christoph Meinel, Harald Sack, Frantisek Plasil (eds.): SOFSEM 2007: Theory and Practice of Computer Science, Lecture Notes in Computer Science 4362, Springer 2007, S. 29–50 [19] M. Broy, M. Breitling, B. Schätz, K. Spies: Summary of Case Studies in Focus - Part II. Technische Universität München, Institut für Informatik, SFB-Bericht Nr. 342/40/97A, 1997 [20] M. Broy, F. Dederichs, C. Dendorfer, M. Fuchs, T. F. Gritzner, R. Weber: The Design of Distributed Systems - An Introduction to Focus. Technische Universität München, Institut für Informatik, Sonderforschungsbereich 342: Methoden und Werkzeuge für die Nutzung paralleler Architekturen TUMI9202, January 1992 [21] M. Broy, F. Dederichs, C. Dendorfer, M. Fuchs, T. F. Gritzner, R. Weber: Summary of Case Studies in F OCUS - a Design Method for Distributed Systems. Technische Universität München, Institut für Informatik, Sonderforschungsbereich 342: Methoden und Werkzeuge für die Nutzung paralleler Architekturen TUM-I9203, January 1992 [22] M. Broy, B. Möller, P. Pepper, M. Wirsing: Algebraic Implementations Preserve Program Correctness. Science of Computer Programming 8 (1986), 1-19 [23] M. Broy, K. Stølen: Specification and Development of Interactive Systems: Focus on Streams, Interfaces, and Refinement. Springer 2001 [24] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture: A System of Patterns. New York: Wiley 1996 [25] K. M. Chandy, J. Misra: Parallel Program Design: A Foundation. Addison Wesley 1988 [26] J. Coenen, W.P. deRoever, J. Zwiers: Assertional Data Reification Proofs: Survey and Perspective. Christian-Albrechts-Universität Kiel, Institut für Informatik und praktische Mathematik, Bericht Nr. 9106, Februar 1991. [27] FlexRay Consortium. FlexRay Communication System - Protocol Specification - Version 2.0, 2004 [28] Th. A. Henzinger, B. Horowitz, and Ch. M. Kirsch. Giotto: A time-triggered language for embedded programming. Proceedings of the IEEE, 91:84–99, 2003. [29] C.A.R. Hoare: Communicating Sequential Processes. Prentice Hall, 1985 [30] F. Huber, B. Schätz, G. Einert: Consistent Graphical Specification of Distributed Systems. In: J. Fitzgerald, C. B. Jones, P. Lucas (ed.): FME’97: 4th International Symposium of Formal Methods Europe, Lecture Notes in Computer Science 1313, 1997, 122-141 [31] G. Kahn: The Semantics of a Simple Language for Parallel Processing. In: J.L. Rosenfeld(ed.): Information Processing 74. Proc. of the IFIP Congress 74, Amsterdam: North Holland 1974, 471-475. [32] G.T. Leavens, M. Sitaraman: Foundations of Component-Based Systems. Cambridge University Press 2000 [33] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, W. Mann: Specification and Analysis of System Architecture Using Rapide. IEEE Transactions on Software Engineering, Special Issue on Software Architecture, 21(4): 336-355, April 1995 [34] N. A. Lynch, E. W. Stark: A Proof of the Kahn Principle for Input/Output Automata. Information and Computation 82(1): 81-92 (1989) [35] M. Moriconi, X. Qian, R. A. Riemenschneider: Correct Architecture Refinement. IEEE Transactions on Software Engineering, Special Issue on Software Architecture, 21(4): 356-372, April 1995 [36] R. Milner: A Calculus of Communicating Systems. Lecture Notes in Computer Science 92, Springer

130


1980 [37] B. Möller: Algebraic Structures for Program Calculation. In: M. Broy, R. Steinbrüggen (eds.): Calculational System Design. Marktoberdorf Summer School 1998. Nato Science Series, Series F: Computer and System Sciences 173, IOS Press: Amsterdam 1999, 25-100. [38] B. Rumpe: Formale Methodik des Entwurfs verteilter objektorientierter Systeme. Dissertation, Technische Universität München, Fakultät für Informatik 1996. Published by Herbert Utz Verlag [39] M. Shaw, P. Clements: A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. Proceedings of the COMPSAC, Washington, D.C., August 1997 [40] M. Shaw, D. Garlan: Software Architecture: Perspectives of an Emerging Discipline. Englewood Cliffs, NJ: Prentice Hall 1996 [41] Specification and Description Language (SDL), Recommendation Z.100. Technical report, CCITT, 1988 [42] J. M. Spivey: Understanding Z - A Specification Language and Its Formal Semantics. Cambridge Tracts in Theoretical Computer Science 3, Cambridge University Press 1988 [43] Clemens Szyperski: Component Software - Beyond Object-Oriented Programming. Addison-Wesley, ACM Press 1998 [44] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whalley, G. Bernat, Ch. Ferdinand, R. Heckmann, T. Mitra, F. Mueller, I. Puaut, P. Puschner, J. Staschulat, and P. Stenström. Theworst-case execution-time problem – overview of methods and survey of tools. Trans. on Embedded Computing Sys., 7(3):1-53, 2008


131

Incremental Design of Distributed Systems with Event-B Michael Butler School of Electronics and Computer Science University of Southampton, UK [email protected] Abstract. It is shown how Event-B can be use to model and reason about distributed systems from a high-level global view down to a detailed distributed architectural view. It is shown how refinement and decomposition can be used to introduce distribution of state and control and to introduce message passing between components. Distribution is treated as a special case of concurrency. Techniques are presented for decomposing abstract atomic events into smaller atomic steps in refinement and for decomposing models into sub-models. Keywords. set theory, refinement, invariants, proof obligations, distributed systems, message-passing

1. Introduction These lectures notes make use of Event-B [1] for modelling and refinement and make use of the Rodin toolset for Event-B [2]. The notes assume some knowledge of the Event-B language, refinement in Event-B, invariants and proof obligations. It will be shown how Event-B can be use to model and reason about distributed systems from a high-level global view down to a detailed distributed architectural view and will be shown how refinement and decomposition can be used to introduce distribution of state and control and to introduce message passing between components. We treat distribution as a special case of concurrency where the only shared variables are buffers used for message-passing. This is very convenient as it allows us to reason about key properties of systems using simpler global abstractions of state and then refine these to distributed systems. We will look at how one can model concurrency in Event-B by modelling the atomic steps that take place in a concurrent system. We will also look at atomicity refinement whereby an atomic step at an abstract level is decomposed into several smaller atomic steps. This involves refining coarse-grained atomicity with more fine-grained atomicity. We will look at how a model may be decomposed into sub-models. Typically these sub-models will represent separate archtectural components. We will present a technique for syntactically partitioning an Event-B model into several sub-models. This technique has a sound semantic basis that corresponds to the synchronous parallel composition of processes as found in process algebra such as CSP [10]. An important property of the

132

M. Butler / Incremental Design of Distributed Systems with Event-B

decomposition technique is that the resulting sub-models can be refined independently of each other. Our decomposition tehnique wil be used to partition the behaviour of agents in a distributed network into separate models, including separate models of messagepassing mechanisms. Performing refinement in incremental steps means that the abstraction gap between refinement levels is not too great for feasible reasoning (formal and informal). This means that the proof effort can be factored out into many relatively simple steps. Simple proof steps allow for a high degree of automation in proof. More automated proof makes it easier to change models A completed refinement chain (or tree) is usually presented in a top-down manner. However, construction of a refinement chain is rarely top-down. There are several reasons for this. One is that requirements change. Another is that when proving refinement between two models, say M 1 and M 2, it may be more convenient to find an intermediate model M 3 lying between M 1 and M 2 in order to simplify the proof effort. A further reason is that our abstract model my turn out to be inaccurate. That is when proving that M 1 is refined by M 2, we encounter proof failure and realise that the problem is with M 1 rather than M 2. Our understanding of the system changes (improves) as we elaborate the design. A key ingredient in performing refinement proofs is the gluing invariant linking states of abstraction levels. A key role of the proof obligations generated by the Rodin tool is to verify the maintainence of gluing invariants. But the tool can also be used to help in the discovery of appropriate gluing invariants. A link between modelling in Event-B and modelling with process algebra such as CSP will be made. Typically in process algebra the behaviour of a process is defined in terms of the events in which it can engage. A similar view can be taken of Event-B models and has a bearing on the way in which interaction, composition and refinement are treated. The relationship to modelling and proof in Event-B will be outlined. In the Event-B, a system is specified as an abstract machine consisting of some state variables and some events (guarded actions) acting on that state. This is essentially the same structure as an action system [3] which describes the behaviour of a parallel reactive system in terms of the guarded actions that can take place during its execution. Techniques for refining the atomicity of operations and for composing systems in parallel have been developed for action systems and such techniques are important for the development of parallel/distributed systems. Different views as to what constitutes the observable behaviour of a system may be taken. In the state-based view, the evolution of the state during execution is observable but not the identity of the operations that cause the state transitions. In the event-based view, the execution of an operation is regarded as an event, but only the the identity of the event is observable and the state is regarded as being internal and not observable. The event-based view corresponds to the way in which system behaviour is modelled in process algebras such as CSP [10]. An exact correspondence between action systems and CSP was made by Morgan [12]. Using this correspondence, techniques for event-based refinement and parallel composition of action systems have been developed in [5,6]. In these notes, we shall use the event-based view of action systems, applying the techniques of [5,6] to Event-B machines. For a description of the state-based view of action systems see [4]. Note that in this paper we only deal with preservation of safety properties in refinement. We avoid treating preservation of liveness in the form of convergence of hidden


133

Figure 1. Simple concurrent program with atomic steps identified

events (absence of divergence) and preservation of event enabledness (absence of deadlock). Further discussion of the proof obligations needed for this may be found in [9].

2. An example of treating concurrency in Event-B In this section we outline how Event-B can be used to model a concurrent system. An Event-B machine consists of some state variables, a set of events, each with its own unique name, and an initialisation action. A machine proceeds by firstly executing the initialisation. Then, repeatedly, an enabled event is selected and executed. A system deadlocks if no event is enabled. Our approach to modelling concurrency in Event-B is straightforward. We identify the atomic steps that can take place in the system being modelled and make these events. We introduce appropriate state variables to control the order of execution of our chosen events and appropriate state to represent the purpose of the system. Figure 1 presents a very simple concurrent program written in a fairly conventional structured programming notation (note this is not Event-B). The process consists of a main process M ain and N subprocesses Inc(p) where p ranges between 1 and N . The program has a single shared variable x that is initialised to 0. Each subprocess increments x exactly once. The execution of an individual assignment x := x + 1 by a subprocess is assumed to be atomic. Once each subprocess completes its simple task, the main process outputs the value of x. Despite its simplicity, we can ask some important questions about this program: • What does this program achieve? • Why does it work? • How would we verify that it works? We will address these questions by building an Event-B model of the concurrent program. In order to do this we identify the atomic steps that can take place in the program. The callout comments in Figure 1 identify these steps. The initialisation of x is an atomic step. Each subprocess executes a single atomic step when it increments x. The

134


Context C Sets P ROC Constants N Axioms axm1 : f inite(P ROC) axm2 : N = card(P ROC) Figure 2. Context for program model.

Machine M Sees C Variables x, Inc, Out Invariants x ∈ N, Inc ⊆ P ROC, Out ∈ BOOL Initialisation x := 0, Inc := {}, Out := F ALSE Event Inc =

any p where grd1 : p ∈ P ROC \ Inc then act1 : Inc := Inc ∪ {p} end Event Out =

any v! where grd1 : Inc = P ROC grd2 : Out = F ALSE grd3 : v! = x then act1 : Out := T RU E end Figure 3. Event-B machine for the simple concurrent program.

final atomic step is to output x. So there are N + 2 atomic steps . Rather than having a separate event for each subprocess Inc(p), we will use a single event, parameterised by p, to model the atomic steps of the subprocesses. So our Event-B model will have three events: the initialisation, Inc and Out. This may be seen in the machine M in Figure 3. When modelling multiple instances of some entity (such as a subprocess) in Event-B, it is convenient to use a given type to identify instances. Figure 2 shows the contex for our model. It defines a set P ROC, to represent subprocesses instances and a constant N . The set P ROC is assumed to be finite with cardinality N . In addition to the variable x, machine M contains two variables for modelling the


135

control of execution of events. Variable Inc ⊆ P ROC represents the set of processes for which the increment event has occurred. Variable Out ∈ BOOL is true when the output event has occurred. In this case the initialiation of the program is modelled by the standard initialisation clause of the machine M so we do not need a control variable for the initialisation. The Inc event can occur for process p provided Inc has not already occurred for process p. This constraint is modelled by guard grd1 of Inc. The action act1 of the Inc event adds the value p to the set Inc which prevents the event occurring for that value of p again. The Out event can occur provided Inc has occurred for all processes (grd1) and Out has not occured (grd2). The parameter v! represents the output value produced by the Out event. Interaction and control We see in machine M two different uses of event parameters. In the Inc event, the parameter p is used to identify the process whose atomic step the event occurence is modelling. In the Out event, the parameter v! is being used to represent an output value produced by an atomic step. We treat these differently in how we interpret the model but we do not treat them differently in proof. Machine M also illustrates a convention we will adopt about variables for controlling event execution. When we want to limit the occurrence of an event we will introduce a variable with the same name as the event, e.g., Inc and Out in M . If we want a single execution of one instance of the event, we specify the control variable for that event to be of type boolean, initially set to f alse, and model the control as in the Out event of machine M . If we require multiple instances of execution of the event we specify the control variable to be a set of some type T , where T is a type used to identify instances, e.g., Inc ⊆ P ROC in M . Execution of such an event with instance value i will add the value of i to the set to indicate that the instance has occurred and to prevent it from occurring again. This is illustrated in the Inc event of machine M . Event traces of the model In the CSP process algebra, process behaviour can be given a formal semantics in terms of traces of obervable events of a process. We can do the same with our model of the simple concurrent program. Consider the case where we have two subprocesses so that P ROC = {p1, p2} and N = 2. The event traces of the model are as follows: Inc.p1, Inc.p2, Out.2

Inc.p2, Inc.p1, Out.2

Each event trace represents a record of a possible execution trace of the model. Here we are ignoring the initialisation event since it always occurs exactly once at the beginning of a trace. The parallel execution of the subprocesses is modelled by interleavings of the atomic steps of the processes. Here the two possible interleavings of Inc.p1 and Inc.p2 represented by the two events traces model their concurrent execution. The event traces provide a definition of the observable behaviour of the model using an interleaving semantics. We will treat this more precisely in Section 3.

136


Machine L Sees C Variables Out Invariants Out ∈ BOOL Initialisation Out := F ALSE Event Out =

any v! where grd1 : Out = F ALSE grd2 : v! = N then act1 : Out := T RU E end Figure 4. Abstraction of model of simple concurrent program.

Abstract model of the desired behaviour We have yet to give a precise answer to the question about what the simple concurrent program achieves. The informal answer of course is that it outputs the value N . We can specify this formally using an Event-B model that outputs the value N . This is represented by the machine L of Figure 4 which has a single event Out that simply outputs N and then disables itself. This model abstracts away from the subprocesses that contribute towards achieving the effect and does not include the variable x that is used to accumulate the value contributed by the subprocesses. It is instructive to relate the event traces of the machine L with those of machine M . L has just a single event trace that outputs N and nothing else. In the case that N = 2, the single event trace of L is Out.2 Recall that the event traces of machine M were Inc.p1, Inc.p2, Out.2

Inc.p2, Inc.p1, Out.2

If we remove the Inc events from these traces we get the trace of L: Inc.p1, Inc.p2, Out.2 \ Inc

=

Out.2

Inc.p2, Inc.p1, Out.2 \ Inc

=

Out.2

Removing events from a trace is the standard way of giving a semantics to hidden or stuttering events and is used, for example, in CSP. By treating the Inc events as a hidden, traces of M look like traces of L. This illustrates a semantics of refinement of Event-B models. Machine M is a refinement of machine L since any trace of M in which the Inc events are hidden is also a trace of L. We will treat this more precisely in Section 3.


137

Refinement proof When both machines L and M , with M declared to be a refinement of L, are given to the Rodin tool several proof obligations are generated and discharged. One proof obligation turns out not to be provable: N = card(P ROC)

// from context C

Inc = P ROC

// guard grd1 of Out in M

x=N This proof obligation is required to ensure that the output value x produced by the refined Out event is the same as the output value N produced by the abstract Out event. The proof obligation lists two hypotheses and a single goal x = N . The task is to prove the goal under the hypotheses. Unfortunately the goal is not provable under the given hypotheses since they say nothing about x. To overcome this we need to add an invariant to the model that will be available as a hypothesis in the proof and will be sufficient to prove the goal. The proof obligation gives us a clue as to what the invariant should be. A standard heuristic for constructing an invariant from a goal is to replace a constant by a variable [8]. The hypotheses above allow us to replace the constant N by card(P ROC) and then P ROC by Inc to get the invariant: x = card(Inc) The expression card(Inc) represents the number of subprocesses that have completed their task (which is to increment x) so this invariant specifies that the value of x is equal to the number of processes that have completed their task. Therefore when all N processes are have completed, x will have the value N and the correct value will be output. By correct we mean, of course, the value specified in the abstract model L. When the above invariant is added to the model, all proof obligations are discharged and we are done with proof. We now have precise answers to the quesions posed at the beginning of this section: • What does this program achieve? It outputs the value N as specified in the model L of Figure 4. • Why does it work? Because it is always the case that x = card(Inc) (the invariant). • How would we verify that it works? By discharging all proof obligations associated with showing that model M refines model L. An important observation is that the verification has helped us uncover why the program works by forcing us to discover invariants that are sufficient to discharge the proof obligations. 3. Behaviour and Refinement In this section we will be more precise about trace behaviours of machines and its connection with refinement. A trace is a sequence of event labels, where an event label is of

138


the form ev.i consisting of event name ev and parameter value i. For example, Inc.p1 is an event label with event name Inc and event parameter p1. We can view an Event-B machine M as a labelled transition system with state space S and event labels E. The event labels are as just outlined above. The states are given by the possible values of the machine variables. We view the events as defining a labelled transition relation on the state space of the following type: A ∈ E → (S ↔ S) That is for event label ev.i ∈ E, the event ev with parameters instantiated to i defines a transition relation on the state space, A(ev.i) ∈ S ↔ S. We can lift A to traces of ¯ represents the event labels giving A¯ ∈ seq(E) → (S ↔ S). For an event trace t, A(t) relational composition of the transition relations of each event label in t. This is defined inductively over traces as follows: ¯ ) = ID A( ¯ et ) = A(e); A(t) ¯ A( Here ID is the identify relation on states (skip). If I is the set of initial states of a ¯ machine M , then A(t)[I] is the set of states reachable by executing trace t. We say that t is a trace of M if the set of states reachable by executing trace t is non-empty: ¯ t ∈ traces(M ) iff A(t)[I]

= ∅ Note that traces are prefix-closed by this definition, that is, if t is a trace then any prefix of t is also a trace. In the previous section we saw how the Inc event could be treated as hidden in order to relate the traces of the refined machine with the traces of the abstract machine. Since we don’t care about the identity of an event when it is hidden, for convenience of definition we can asume that all hidden events are combined into a single unlabelled transition relation H: H ∈ S↔S The definition of the lifted transition relation on event sequences is then modified to take account of H as follows: ¯ ) = H ∗ A( ¯ ¯ et ) = H ∗ ; A(e); A(t) A( Now we give a definition to refinement in terms of trace inclusion, that is, machine M 1 is refined by M 2 when traces(M 2) ⊆ traces(M 1). That is, any possible behaviour of M 2 is a possible behaviour of M 1. New events may be introduced in Event-B refinement, that is, a refined machine may have additional events that have no corresponding events in the abstract machine. New events are required to refine skip. This ensures that they have no effect in terms of the abstract state. The new events introduced in a refinement step can be viewed as hidden events not visible to the environment of a system and are thus outside the control of the environment. In Event-B, requiring a new event to refine skip corresponds to the


139

process algebraic principle that the effect of an event is not observable. Any number of executions of an internal action may occur in between each execution of a visible action. The proof obligations defined for Event-B refinement are based on the following proof rule that makes use of a gluing invariant J: • Each M 1.A is (data) refined by M 2.A under J • Each M 2.H refines skip under J It can be shown that these are sufficient conditions for trace refinement [6]. In the simple concurrent program of Section 2 we saw how the gluing invariant x = card(Inc) was used to discharge the conditions showing that the abstract Out event is refined by the concrete Out event and that the Inc event in the refined model refines skip.

4. Decomposing Atomicity In this section we will look at how coarse-grained atomicity can be refined to more finegrained atomicity. The approach we take is to treat most of the sub-atomic events of a decomposed abstract event as hidden events which are required to refine skip. We have already seen an example of this in our Event-B teatment of the simple concurrent program in Section 2. The abstract model consists of a the single event that outputs the value N . We view the refined model as breaking the atomicity of the output event by introducing the Inc event that models the behavior of the parallel sub-processes. The decomposition of the atomicity of the simple concurrent program is modelled diagrammatically in Figure 5. This diagrammatic notation is based on JSD (Jackson Structure Diagrams) by Jackson [11]. Figure 5 is a tree structure with root Out(N ) representing the abstract output event. The diagram shows how the root is decomposed into an initialisation, the parallel composition of multiple parallel instances of Inc(p) and a refined output event Out(x). The oval with the keyword par represents a quantifier that replicates the tree below it. In this case it replicates Inc(p) by quantifying over p. An important feature of this diagrammatic notation, in common with JSD diagrams, is that the subtrees are read from left to right and indicate sequential control from left to right. This means that our diagram indicates that the abstract Out(N ) event is realised in the refinement by firstly executing the initialisation, then executing the Inc(p) events in parallel (in an interleaved fashion as discussed previously) and then executing Out(x). Another important feature of the diagrammatic notation is the solid and dashed lines linking children to their parent. The Init and Inc(p) events are linked by a dashed line which means it must be proven that they refine skip. The abstract and refined Out events are linked by a solid line which indicates a refinement relation. That is, it must be proven that Out(x) refines Out(N ). In Section 2 the proof obligations that we discharged were concerned with proving precisely these refinement conditions. We will study a further example of atomicity refinement which involves more event interleaving than the simple concurrent program. This is an event for writing a file to a disk. At the abstract level the entire contents of the file is written in one atomic step as in the following machine: Machine File1 Variables f ile, dsk

140


Figure 5. Illustration of the atomicity decomposition

Invariants

f ile ⊆ F ILE,

dsk ∈ f ile → CON T

Event Write =

any f, c where grd1 : f ∈ f ile grd2 : c ∈ CON T then act1 : dsk(f ) := c end Here the contents of the disk are represented by the variable dsk which maps files to their contents. The W rite event has 2 parameters, the identity of the file to be written f and the contents to be written c. Other events such as creating a file and reading a file are not shown. We assume that file contents is structured as a set of pages of data so that the type CON T is defined as follows: CON T = P AGE → DAT A Figure 6 illustrates the decomposition of the W rite event into sub-events to model the writing of individual pages. In the refinement, the writing of individual pages will be modelled atomically by the P ageW rite event and the writing of the entire file is no longer atomic. The writing of a file is initiated by the StartW rite event and ended by the EndW rite event. We will allow multiple file writes to be taking place simultaneously in an interleaved fashion. This is indicated by the top level parallel quantification over f (par(f )). We also assume that the pages of an individual file f can be written in parallel hence the inner parallel quantification over p (par(p)). Occurrence of event P ageW rite(f, p) models writing of page p of file f . In order to model the event sequencing implied by Figure 6, we introduce variables corresponding to the StartW rite and P ageW rite events as follows: Invariants inv1 : StartW rite ⊆ F ILE inv2 : P ageW rite ⊆ F ILE × P AGE


141

Figure 6. Decomposition of the atomiticy of file write

The types of these variables are determined by the parallel quantification in Figure 6. When the writing of a file is complete, we will allow the file to be written to again. Therefore we do not need any variable to model the occurrence of the EndW rite event for a file, since all the control information for a file will be cleared when the file write is complete in order to allow the file to be written to again later if required. Now, for example, the control behaviour of the StartW rite and P ageW rite events is as follows: Event StartWrite =

any f where grd1 : f ∈ f ile grd2 : f ∈ StartW rite then act1 : StartW rite := StartW rite ∪ {f } end Event PageWrite =

any f, p where grd1 : f ∈ StartW rite grd2 : f → p ∈ / P ageW rite then act1 : P ageW rite := P ageW rite ∪ {f → p} end This control behaviour on its own is not enough. The pages and their contents for a particular file need to be determined before we start the process of writing to a file. We introduce a variable writebuf to act as a buffer for the content to be written to disk. Rather than writing directly to the abstract variable dsk, the P ageW rite event will write the contents of an indivdual page to a shadow disk while the writing is in progress. When the writing is complete, the contents of the shadow disk is transferred to the disk at the end of the writing process. These variables are defined as follows:

142


inv3 : writebuf ∈ StartW rite → CON T inv4 : sdsk ∈ StartW rite → CON T Note that both are defined on files that are currently being written, i.e., files in the set StartW rite. Now, as well as initialising the control for the writing process, the StartW rite event sets the contents to be written to disk in the write buffer for that file (act2) and sets the shadow disk for that file to be empty (act3): Event StartWrite =

any f, c where grd1 : f ∈ f ile grd2 : f ∈ StartW rite grd3 : c ∈ CON T then act1 : StartW rite := StartW rite ∪ {f } act2 : writebuf (f ) := c act3 : sdsk(f ) := ∅ end The P ageW rite event selects a page of a file that have yet to be written (grd2) and is in the write buffer (grd3). The parameter d represents the data associated with the page being written: Event PageWrite =

any f, p, d where grd1 : f ∈ StartW rite grd2 : f → p ∈ / P ageW rite grd3 : p → d ∈ writebuf (f ) then act1 : P ageW rite := P ageW rite ∪ {f → p} act2 : sdsk(f ) := sdsk(f ) − {p → d} end The StartW rite and P ageW rite events both refine skip while the EndW rite event refines the abstract W rite event (see the dashed and solid lines in Figure 6). The EndW rite event occurs once all pages of a file have been written, a condition that is captured by grd2 below. The effect of the event is to copy the shadow disk to the disk (act1). The event also clears all the control, buffer and shadow information for the file to enable the write process to commence all over again (act2 to act5). Event EndWrite Refines Write =

any f, c where


143

grd1 : f ∈ StartW rite grd2 : P ageW rite[{f }] = dom(writebuf (f )) grd3 : c = sdsk(f ) then act1 : act2 : act3 : act4 : act5 :

dsk(f ) := sdsk(f ) StartW rite := StartW rite \ {f } P ageW rite := {f } − P ageW rite writebuf := {f } − writebuf sdsk := {f } − sdsk

end It may seem like we have not really achieved much decomposition of atomicity since the copy of the shadow disk is copied to the actual dik in one atomic step (act1 of EndW rite). However our intention is that the disk and the shadow together are both realised on the real hard disk and that the effect of act1 would be achieved by an update to the page table for the disk (in later refinements). We assume that updating the page table can reasonably be treated as atomic. Having the P ageW rite event write the individual pages to a shadow disk also allows us to model fault tolerance quite easily. We add an AbortW rite event that clears all the control and shadow information for a file write but does not update the disk: Event AbortWrite =

any f where grd1 : f ∈ StartW rite then act1 : StartW rite := StartW rite \ {f } act2 : writebuf := {f } − writebuf act3 : sdsk := {f } − sdsk act4 : P ageW rite := {f } − P ageW rite end This event refines skip since it does not modify the dsk variable that appears in the abstract model. Thus the effect of an abort, which can happen after any number of pages are writen, is to leave the disk in the state it was in before the file write process started (for the file f ). It is instructive to compare an event trace of the abstract file model with a corresponding trace of the refinement file model. The following trace represents a behaviour in which the contents c2 is written to file f 2 and then the contents c1 is written to file f 1: W riteF ile.f 2.c2, W riteF ile.f 1.c1 Each of these high-level events is realised by several new events (StartW riteF ile, W riteP age etc). The sub-events of one high-level write may interleave with those of the other high-level event. For example, the folllowing event trace of the refined model illustrates this (the events that directly refine an abstract event are highlighted in bold):

144


StartW riteF ile.f 1.c1, W riteP age.f 1.p1.c1(p1), StartW riteF ile.f 2.c2, W riteP age.f 1.p2.c1(p2), W riteP age.f 2.p1.c2(p1), W riteP age.f 2.p2.c2(p2), EndWriteFile.f2.c2, W riteP age.f 1.p3.c1(p3), EndWriteFile.f1.c1 This illustrates a scenario in which writing to file f 1 is started before writing to f 2 is started but writing of file f 2 finishes before writing of file f 1. To recap, we have decomposed the atomicity of the abstract W rite event by introducing new the events StartW rite, P ageW rite and AbortW rite and by refining the W rite event with the EndW rite event. Formally, the new events have no connection to the abstract W rite event, only the EndW rite has a fomal connection. However, the diagram of Figure 6 describes the intended purpose of the new events which is to represent the intermediate steps of the file write process that lead to a state where the EndW rite is enabled. The diagram also plays another role in that it defines the control behaviour of all the events constituting the write process and this was encoded in Event-B in a systematic way, i.e., introducing the StartW rite and P ageW rite control variables. The additional modelling elements provided, writebuf and sdsk, were required in order to model abstractly the effect of the various events and their introduction was based on modelling judgement.

5. Decomposing machines In this section, we describe a parallel composition operator for machines. The parallel composition of machines M and N is written M N . Machines M and N must not have any common state variables. Instead they interact by synchronising over shared events (i.e., events with common names). They may also pass values on synchronisation. We look first at basic parallel composition and later look at parallel composition with shared parameters. We show how the composition operator may be applied in reverse in order to decompose system models into subsystem models. Parallel Composition of Machines To achieve the synchronisation effect between machines, shared events from M and N are ‘fused’ using a parallel operator for events. Assume that m (resp. n) represents the state variables of machine M (resp. N ). Variables m and n are disjoint. The parallel operator for events is defined as follows: when G(m) then S(m) end =

when H(n) then T (n) end

when G(m) ∧ H(n) then S(m) T (n) end

any x where G(x, m) then S(x, m) end

any y where H(y, n) then T (y, n) end =

any x, y where G(x, m) ∧ H(y, n) then S(x, m) T (y, n) end


Machine V1 Variables v Invariants v ∈ N Initialisation v := N Event B =

when grd1 : v > 0 then act1 : v := v − 1 end Event A =

145

Machine W1 Variables w Invariants w ∈ N Initialisation w := 0 Event B =

when grd2 : w < M then act2 : w := w + 1 end Event C =

begin act1 : v := N end (a) Machine V 1

when grd1 : w > 0 then act1 : w := w − 1 end (b) Machine W 1

Figure 7. Machines to be composed in parallel

The parallel operator models simultaneous execution of the events actions and the composite event is enabled exactly when both component events are enabled. This models synchronisation: the composite system engages in a joint event when both systems are willing to engage in that event. The parallel composition of machines M and N is a machine constructed by fusing shared actions of M and N and leaving independent actions independent. The state variables of the composite system M N are simply the union of the variables of M and N. As an illustration of this, consider machines V 1 and W 1 of Figure 7. The machines work on independent variables v and w respectively. Both machines have an event labelled B and to compose these machines we fuse their respective B events. The composition of both machines is shown in Figure 8. The A event and C event of V W 1 come directly from V 1 and W 1 respectively as they are not joint events (i.e., independent events). The B event is a joint event and is defined as the fusion of the B-events of V 1 and W 2. The initialisations of V 1 and W 1 are also combined to form the initialisation of V W 1. The joint B event simultaneously decreases v while increasing w, provided v > 0 and w < N . Decomposition We have presented V W 1 as having been formed from the composition of V 1 and W 1. We can view the relationship between these machines in another way. Let us suppose we had started with V W 1 and decided that we wish to decompose it into subsystems.

146


Machine VW1 Variables v, w Invariants v ∈ N, w ∈ N Initialisation v := N, w := 0 Event A =

begin act1 : v := N end Event B =

when grd1 : v > 0 grd2 : w < N then act1 : v := v − 1 act2 : w := w + 1 end Event C =

when grd1 : w > 0 then act1 : w := w − 1 end Figure 8. Composition of V 1 and V 2.

The diagram in Figure 9(a) illustrates the dependencies between events and variables in the machine V W 1. For example, the line from the box indicating event A to the circle indicating variable v represents the fact that event A depends on v, i.e., it may read from and assign to v. The diagram shows that B is the only event that depends on both v and w suggesting that B needs to be a shared event if we are to partition v and w into separate subsystems. This decomposition is illustrated in Figure 9(b) where variables v and w of V W 1 are partitioned into subsystems V 1 and W 1 respectively, A is an event of subsystem V 1, C is an event of subsystem W 1 and B is an event shared by both subsystems. Event B of system V W 1 is partitioned into two parts, one of which will belong in W 1 and the other in W 1. Event B has an important characteristic that allows it to be partitioned in this way. The guards and actions depend either on v or on w but not both. So, guard grd1 and action act1 both depend on v only, while guard grd2 and action act2 both depend on w. This localisation of variable dependency allows us to easily partition the guards and actions of the B event of V W 1 into the separate B events of V 1 and W 1 respectively.

147


(a) Variable access by events in V W

(b) Split events and variables

Figure 9. Illustration of decomposition a machine

Fusion with shared event parameters

We extend the fusion operator to deal with shared event parameters. Events to be fused must depend on disjoint machine variables but they may have common parameters and these common parameters are treated as joint parameters in the fused event as follows: any x where G(x, m) then S(x, m) end

any x where H(x, n) then T (x, n) end =

any x where G(x, m) ∧ H(x, n) then S(x, m) T (x, n) end

More generally, fused events may also have additional independent parameters (y and z) besides the joint parameters: ev1 = any x, y where G(x, y, m) then S(x, y, m) end ev2 = any x, z where H(x, z, n) then T (x, z, n) end

ev1 ev2

=

any x, y, z where G(x, y, m) ∧ H(x, z, n) then S(x, y, m) T (x, z, n) end

We illustrate the use of shared parameters by extending the V W 1 machine slightly. Assume that instead of increasing v and decreasing w by 1 in the B event, we modify both v and w by a value i. To do this we give the B event a parameter i which is used to modify the variables as follows:

148


Event B =

any i where grd1 : 0 ≤ i ≤ v grd2 : w < N then act1 : v := v − i act2 : w := w + i end Now we partition the guards and events of B into those that depend on v and those that depend on w giving the following events: Event B =

any i where grd1 : 0 ≤ i ≤ v then act1 : v := v − i end

Event B =

any i where grd1 : i ∈ Z grd2 : w < N then act1 : w := w + i end

The shared parameter i means that both of these events will agree on the amount by which v and w are respectively decreased and increased. In the left hand sub-event, the guard grd1 constraints the value of the parameter based in the state variable v. In the right-hand sub-event, the value of i is not constrained other than a typing guard (i ∈ Z). This means that the left-hand sub-event can be viewed as outputting the value i while the right-hand sub-event accepts the value i as an input. Independent refinement of subsystems In Section 3, we saw how the event traces of a machine may be defined and it was pointed out that such event traces are used to define the behaviour of CSP processes as found in [10]. Parallel composition of process in CSP is defined by processes synchronising over shared events and non-shared events can occur independently in sub-processes. The semantics of parallel composition in CSP is defined in terms of an operator over traces that fuses shared events and interleaves non-shared events. Details may be found in [10]. The parallel composition of Event-B machines that we use here achieves the same effect as CSP parallel composition by synchronising shared events and leaving non-shared events independent. For example, in composing V 1 and W 1, the shared B events are synchronised by event fusion while the non-shared events, A and C, remain independent in the composition. It can be shown that this composition of machines results in the same composition of event traces as found in the CSP definition. Details may be found in [5].


149

Figure 10. Decomposition with asynchronous middleware

Significantly parallel composition of event traces is monotonic w.r.t. trace refinement [10]. Therefore a corollary of the correspondence between CSP parallel composition and our composition of Event-B machines is that our composition is also monotonic w.r.t. trace refinement. This means that when we decompose a system into parallel subsystems, the subsystems may be refined and further decomposed independently. This is a major methodological benefit, helping to modularise the design and proof effort.

6. Incremental development of a distributed file transfer In this section we present an incremental development of a simple system for copying a file from one location to another. We start with an abstract model in which the file copy occurs in one atomic step. We then refine this by a model in which the contents of the file is copied one page at a time. The refined model is then decomposed into subsystems. Instead of decomposing into two subsystems that synchronise with each other, we decompose into three subsystems as illustrated in Figure 10. In this decomposition the two agents do not synchronise directly with each other. Instead they interact indirectly through a middleware subsystem. Each agent synchronises directly and separately with the middleware and this will be used to model asynchronous communication between the agents. This form of asynchronous communication via middleware can be used to model many distributed systems that are based on message passing. In oder to be able to decompose in this way, we will need to apply refinement steps that enable the agents to be decomposed into asynchronous subsystems. 6.1. Abstract model The model makes use of the following context which introduces the types P AGE and DAT A respectively. A file is modelled as a partial function from pages to data. The constant file f 0 will be used in the initialisation of the machine. Context C1 Sets PAGE ; DATA Constants f 0 Axioms axm1 : f 0 ∈ P AGE → DAT A END

150


Figure 11. Refining atomicity of the CopyF ile event

Machine F 1 defines the abstract behaviour of the file transfer system. It contains two variables f ileA, representing the contents of the file at the sending side, and f ileB representing the value of the file at the receiving side: Machine F1 Variables fileA , fileB Invariants inv1 : f ileA ∈ P AGE → DAT A inv2 : f ileB ∈ P AGE → DAT A The variables are initialised as follows: Initialisation act1 : f ileA := f 0 act2 : f ileB := ∅ The abstract machine has one event that simply copies the contents of f ileA to f ileB on one atomic step: Event CopyFile =

begin act1 : f ileB := f ileA end 6.2. Breaking atomicity The atomicity of the CopyF ile event is decomposed in the same way in which the atomicity of the W rite event was decomposed in Section 4. This is illustrated in Figure 11. We introduce control variables based on this diagram as well as a buffer buf in which pages are written one at a time: Machine F2 Refines F1 Variables fileA , fileB , Start , CopyPage , Finish , buf Invariants inv1 : Start ∈ BOOL Control variable inv2 : CopyP age ⊆ P AGE Control variable Control variable inv3 : F inish ∈ BOOL


inv4 : buf ∈ P AGE → DAT A

151

Page buffer

The control behaviour of the Start and CopyP age events is constructed based in the control implied by the diagram in Figure 11 (in the same way that the control for the file write process was defined in Section 4). In addition the CopyP age event writes a page from f ileA to buf . We omit the definitions of these events and focus on the F inish event that refines the abstract CopyF ile event. The F inish event is enabled once all pages have been copied into buf , i.e., card(buf ) = card(f ileA). The F inish event copies buf into f ileB and sets the control variable F inish to T RU E: Event Finish =

Refines CopyFile when grd1 : Start = T RU E grd2 : F inish = F ALSE grd3 : card(buf ) = card(f ileA) then act1 : f ileB := buf act2 : F inish := T RU E end END The F inish event gives rise to an unproved proof obligation as follows: Start = T RU E, card(buf ) = card(f ileA) buf = f ileA This proof obligation embodies the need to demonstrate that the effect of the F inish event (which assigns buf to f ileB) refines the effect of the CopyF ile event (which assigns f ileA to f ileB). The requirement is to show that the value assigned to f ileA is the same in the abstract and refined events hence the goal buf = f ileA. Clearly while we are copying pages from f ileA to buf it is not always the case that buf = f ileA. But we would expect that any page-content pair that has been copied into buf is also a pair of f ileA, i.e., that buf ⊆ f ileA. Thus we add the following invariant to the model: inv5 : Start = T RU E ⇒ buf ⊆ f ileA With this invariant available as an additional hypothesis, the above proof obligation can be discharged since buf ⊆ f ileA and card(buf ) = card(f ileA) together mean that buf = f ileA.

152


Figure 12. Splitting events into sender and receiver parts

6.3. Split events to A side and B side As previously mentioned, we will decompose the file transfer system into three subsystems. We first split some events into an A-part, representing behaviour on the sending side, and a B-part, representing behaviour on the receiving side. This is illustrated by the diagram in Figure 12 which shows that the Start event is decomposed into StartA and StartB. The StartA event represents the sending side deciding to commence the transfer while the subsequent StartB event represents the receiving side recognising that the transfer has commenced. The StartA event will set a flag StartA to T RU E while the StartB event will set a flag StartB to T RU E provided StartA is true. The CopyP age event is decomposed into separate A and B parts in a similar way. We assume that the sending side will send the size of the file at the start so that the receiving side can know when all the pages have been received. This means that the sending side does not need to send a finish message so we need a F inish event on the receiving side only. We replace the buf variable from the previous level by two variables buf A and buf B representing the values of the buffers in the A and B sides respectively. We also introduce variables sizeA and sizeB representing the size of f ileA as know at sides A and B respectively. As indicated by Figure 12, the StartA event refines skip and is defined as follows: Event StartA =

when grd1 : StartA = F ALSE then act1 : StartA := T RU E act2 : buf A := ∅ act3 : sizeA := card(f ileA) end As indicated by Figure 12, the StartB event refines the Start event of the previous level. The receiving side will discover the file size when it starts the transfer so the StartB event sets the sizeB variable appropriately.


153

Event StartB =

Refines Start when grd1 : StartB = F ALSE grd2 : StartA = T RU E then act1 : StartB := T RU E act2 : buf B := ∅ act3 : sizeB := sizeA end We omit details of the CopyP ageA and CopyP ageB events. The F inishB event refines the F inish event of the previous level. It is enabled when the number of pages received reaches the number expected (grd3): Event FinishB =

Refines Finish when grd1 : F inishB = F ALSE grd2 : StartB = T RU E grd3 : card(buf B) = sizeB then act1 : f ileB := buf act2 : F inishB := T RU E end END 6.4. Introduce message variables Now consider again the StartB event just presented. Our intention is that this is an event of the receiving side so we wish to make it an event of the receiver subsystem. This means it should not refer to variables of the sending side directly since we are aiming at an asynchronous decomposition. However the StartB event does refer to variables of the sending side: grd2 refers to the StartA variable and act3 refers to the sizeA variable. To break this dependency on variables of the sending side in events of the receiving side, we introduce variables that duplicate the variables of the sending side (StartM , CopyP ageM , sizeM and buf M ). These duplicate variables will be separated into a middleware machine (Figure 10) and become abstract representations of messages in transit in the middleware. We refine the StartA event so that it initialises the duplicate variables as well as the sender variables: Event StartA =

Refines StartA

154


when grd1 : StartA = F ALSE then act1 : StartA := T RU E act2 : buf A := ∅ act3 : sizeA := card(f ileA) act4 : StartM := T RU E act5 : buf M := ∅ act6 : sizeM := card(f ileA) end Now, instead of being enabled when the StartA flag is true, the StartB event is enabled when the StartM flag is true. Also the value assigned to sizeB is based on sizeM rather than sizeA as previously: Event StartB =

Refines StartB when grd1 : StartB = F ALSE grd2 : StartM = T RU E then act1 : StartB := T RU E act2 : buf B := ∅ act4 : sizeB := sizeM end This refinement relies on the invariants StartM = StartA and sizeM = sizeA. 6.5. Separate machines The previous model is decomposed into three separate machines representing three subsystems as illustrated in Figure 10. The three machines are: • machine mA1 representing a model of the sending agent • machine mB1 representing a model of the receiving agent • machine mM 1 representing a model of the middleware through which the sender and receiver interact. The variables of the previous model are partitioned amongst the three machines. The sender interacts with the middleware through synchronisation over actions (StartA and CopyP ageA). Similarly, the receiver interacts with the middleware through synchronisation over actions (StartB and CopyP ageB). There is no direct interaction between the sender and receiver - all communication is via the middleware machine. Figure 13 provides an architectural overview of the decomposition illustrating how the variables and events are distributed amongst the subsystems. The variables allocated to each subsystem are listed in italic in the relevant box for that subsystem, e.g., the


155

Figure 13. Architectural illustration of decomposition

sender subsystem contains the variables f ileA, StartA etc. The smaller labelled boxes indicate the synchronised shared events. For example, the StartA event is shared between the sender and the middleware representing a synchronised interaction between these subsystems. Let us look at how the StartA event is split into the sender event and the middleware event. We would like guard grd1 to become a guard of the sender event. We would like actions act1..act3 to become actions of the sender event and actions act4...act6 to become actions of the middleware event. However, this is not possible since act6 refers to card(f ileA). We cannot have an event of the middleware referring to a variable of the sender. We overcome this by adding a parameter s to the event whose value is the same as card(f ileA) and use this in the action act6: Event StartA =

Refines StartA any s where grd1 : StartA = F ALSE grd2 : s = card(f ileA) then act1 : StartA := T RU E act2 : buf A := ∅ act3 : sizeA := card(f ileA) act4 : StartM := T RU E act5 : buf M := ∅ act6 : sizeM := s end The parameter s that we have just introduced will become a shared parameter when the separate sender and middleware StartA events are fused. We are now in a position to partition the StartA event into the sender event mA1 : StartA and the middleware event mM 1 : StartA. Event mA1:StartA =

156


any s where grd1 : StartA = F ALSE grd2 : s = card(f ileA) then act1 : StartA := T RU E act2 : buf A := ∅ act3 : sizeA := card(f ileA) end Event mM1:StartA =

any s where grd1 : s ∈ N then act1 : StartM := T RU E act2 : buf M := ∅ act3 : sizeM := s end 6.6. Introducing message types In this section we show how more explicit datatypes representing messages can be introduced and used in the file transfer middleware. We introduce a type representing general message structures M ESS and a type M ID representing message identifiers associated with messages. We regard elements of M ESS as structured messages, each of which has an identifier field. This identifier field is represented by a projection function idF mapping M ESS to M ID: axm1 : idF ∈ M ESS → M ID We define a subtype of M ESS called StartM ESS representing the messages that can be sent from sender to receiver to start a file transfer. Each StartM ESS has a size field sizeF which is used to indicate the size of the file to be transferred. axm2 : StartM ESS ⊆ M ESS axm3 : sizeF ∈ StartM ESS → N Since StartM ESS is a subset of M ESS, each StartM ESS will also have an idF field. We introduce another subtype of M ESS called P ageM ESS representing the message that are used to transfer pages from sender to receiver. Each P ageM ESS has a page field and a data field. axm4 : P ageM ESS ⊆ M ESS axm5 : pageF ∈ P ageM ESS → P AGE axm6 : dataF ∈ P ageM ESS → DAT A


157

We assume that the two subtypes are distinct: axm7 : StartM ESS ∩ P ageM ESS = ∅ We refine the communications medium by replacing StartM with a set of StartM ESS messages and replace buf M with a set of P ageM ESS messages. It also contains a variable mid representing the set of message identifiers already used. This allows for specification of a freshness constraint on the choice of message identifier. Machine mM2 Refines mM1 Variables StartMS , CopyPageMS , mid Invariants inv1 : StartM S ⊆ StartM ESS inv2 : CopyP ageM S ⊆ P ageM ESS inv3 : mid ⊆ M ID The relationship between the abstract sets of the previous model of the communications medium and the message sets that replace them is given by the following gluing invariants: inv4 : inv5 : inv6 : inv7 :

∀m· ∀m· ∀m· ∀m·

m ∈ StartM S ⇒ m ∈ StartM S ⇒ m ∈ CopyP ageM S m ∈ CopyP ageM S

StartM = T RU E sizeF (m) = sizeM ⇒ pageF (m) ∈ CopyP ageM ⇒ pageF (m) → dataF (m) ∈ buf M

Now the StartA event of the middleware is parameterised by a message m whose idF field is fresh. The relationship between the parameter m and the abstract parameter s is given by the witness statement which specifies that the size parameter s equals the value of the size field of m. The selected message identifier is added to the set mid indicating that it should not be used again. Event mM1:StartA =

Refines mM2:StartA any m where grd2 : m ∈ StartM ESS grd3 : idF (m) ∈ / mid witness s : s = sizeF (m) then act3 : StartM S := StartM S ∪ {m} act1 : mid := mid ∪ {idF (m)} end The previous StartB event of the middleware is enabled when StartM = T RU E. This is refined by there being a message m in initM S:

158


Event mM2:StartB =

Refines mM1:StartB any m where grd2 : m ∈ StartM S witness s : s = sizeF (m) end The CopyP ageA and CopyP ageB events are refined in a similar way. Details are omitted.

7. Concluding It was shown how Event-B can be use to model and reason about distributed systems from a high-level global view down to a detailed distributed architectural view. It was shown how refinement and decomposition can be used to introduce distribution of state and control and to introduce message passing between components. The key ideas that we covered include concurrency and atomicity in Event-B models, refining the atomicity of events in refinement and decomposing models into submodels based on synchronous interaction between subsystems. In this context we treat a distributed systems as a special case of concurrency where the only shared variables are buffers used for message-passing. This is very convenient as it allows us to reason about key properties of systems using simpler global abstractions of state and then refine these to distributed systems. This incremental style of development has been applied to many distributed systems including a replicated database [13] and an electronics funds transfer system [7].

Acknowledgements Some of the work described here is part of the EU research project ICT 214158 DEPLOY (Industrial deployment of system engineering methods providing high dependability and productivity) www.deploy-project.eu.

References J.-R. Abrial. Modelling in Event-B: System and Software Engineering. To be published by Cambridge University Press, 2008. [2] J.-R. Abrial, M. Butler, S. Hallerstede, and L. Voisin. An open extensible tool environment for Event-B. In Z. Liu and J. He, editors, ICFEM 2006 Lecture Notes in Computer Science, volume 4260, 2006. [3] R.J.R. Back and R. Kurki-Suonio. Decentralisation of process nets with centralised control. In 2nd ACM SIGACT-SIGOPS Symp. on Principles of Distributed Computing, pages 131–142, 1983. [4] R.J.R. Back and K. Sere. Stepwise refinement of parallel algorithms. Sci. Comp. Prog., 13:133–180, 1989. [5] M.J. Butler. A CSP Approach To Action Systems. D.Phil. Thesis, Programming Research Group, Oxford University, 1992. http://eprints.ecs.soton.ac.uk/974/. [1]


[6] [7] [8] [9]

[10] [11] [12] [13]

159

M.J. Butler. Stepwise refinement of communicating systems. Science of Computer Programming, 27(2):139–173, September 1996. M.J. Butler and D.S. Yadav. An incremental development of the mondex system in event-b. Formal Aspects of Computing, 20(1):61–77, January 2008. D. Gries. The Science of Programming. Springer–Velag, 1981. S. Hallerstede. On the purpose of event-b proof obligations. In Egon Börger, Michael Butler, Jonathan P. Bowen, and Paul Boca, editors, ABZ, volume 5238 of Lecture Notes in Computer Science, pages 125– 138. Springer, 2008. C.A.R. Hoare. Communicating Sequential Processes. Prentice–Hall, 1985. M.A. Jackson. System Development. Prentice–Hall, 1983. C.C. Morgan. Of wp and CSP. In W.H.J. Feijen, A.J.M. van Gasteren, D. Gries, and J. Misra, editors, Beauty is our business: a birthday salute to Edsger W. Dijkstra. Springer–Verlag, 1990. D.S. Yadav and M.J. Butler. Formal development of fault tolerant transactions for a replicated database using ordered broadcasts. In Methods, Models and Tools for Fault Tolerance (MeMoT 2007), pages 33–42, May 2007.



161

Principles of program termination Notes for the Marktoberdorf summer school Byron Cook Microsoft Research Cambridge Abstract. In this paper we introduce the basic concepts behind the problem of proving program termination, including well-founded relations, well-ordered sets, and ranking functions. We also connect the notion of termination of computer programs with that of well-founded relations. This paper introduces no original concepts, nor does it propose solutions towards the the problem of automating termination proofs. It does, however, provide a foundation from which the reader can peruse the more advanced literature on the topic.

1. Introduction The program termination problem, also known as the uniform halting problem, can be defined (using today’s terms) as follows: Using a finite amount of time: determine whether a given program will always finish running or could potentially execute forever. This problem rose to prominence before the invention of programs or computers, in the era of Hilbert’s Entscheidungsproblem1 : the challenge to formalize all of mathematics into logic and use mechanical means to determine the validity of mathematical statements. After Hilbert’s challenge, a number of logicians and mathematicians began finding instances of undecidable problems, thus showing the ideal of the Entscheidungsproblem to be impossible. Turing [18]2 , for example, proved the halting problem undecidable. Turing’s result is now perhaps the most frequently covered topic in introductory courses in the areas of logic and theoretical computer science. This popularization of Turing’s result has, unfortunately, had the side-effect of giving birth to a frequently held misconception that we are always unable to prove termination: many believe that it is impossible to prove program termination of any program; many others believe that program termination is too hard a problem to tackle. Thus, little effort was expended to automate termination proving—those who 1 In

English: “decision problem” is some controversy as to whether or not Turing proved the undecidability in [18]. Technically he did not, but termination’s undecidability is an easy consequence of the result that is proved. 2 There

162

B. Cook / Principles of Program Termination – Notes for the Marktoberdorf Summer School

suggest solutions to termination or related problems were usually derided by their peers. The true consequence of Turing’s proof, in contrast, is the much more benign fact that we are unable to always prove termination—meaning that we can potentially prove termination in most cases, but no matter how sophisticated a termination prover we build, there will always be at least one terminating program that cannot be proved terminating. The program termination problem has recently found new life [16] as our society increasingly depends more on computers, the need for practical tools that automatically prove the correctness of software (as opposed to simply finding bugs) is becoming clear [1]. Practical and powerful industrial tools are now emerging that allow us to express and automatically prove properties of computer programs. It turns out that the program termination problem is at the foundation of many of the properties that we might want to prove of software: a liveness property such as “Every call to AcquireLock is eventually followed by a call to ReleaseLock” amounts proving the termination of the code occurring between calls to AcquireLock and ReleaseLock. Several advanced prototype tools have recently emerged that attempt to automatically prove program termination. Since termination is formally undecidable, the modern challenge is to show the problem to be “effectively decidable”—i.e. to build robust termination provers that work in all practical cases, or maybe even all known cases. As of the writing of these notes, these new termination tools can automatically prove or disprove termination of many famous complex examples (e.g. Ackermann’s function, McCarthy’s 91 function), as well as moderately-sized industrial examples (e.g. Windows OS device drivers). Perhaps, as the tools improve, we will one day be able prove liveness properties of most industrial programs. Currently the techniques for automating program termination proofs are known perhaps to only a handful of people. Furthermore, there is no single good source for those interested in learning more: knowledge on how to automate termination proofs must today be synthesized from obscure research papers in tandem with voluminous foundational texts (each of which used distinct notations and required different levels of sophistication). These notes are designed to accompany lectures I will present at the Marktoberdorf summer school. My goal in giving these lectures is to provide advanced students with an understandable and uniform introduction to the foundations of the program termination problem and the modern approaches for automation. The lectures will begin with information drawn from this paper. The material in the remaining lectures will be drawn primarily from the research papers written during the development of the Terminator termination prover: [2,3,5,6,7,8,9,13].

2. Defining termination For the purpose of these notes it is convenient to think of a computer program as its possible initial configurations paired together with a relation that specifies the possible transitions that the program can make between configurations during execution. Program executions can be thought of as traversals starting from one of the program’s initial configurations through the various changes of configuration


163

allowed by the program’s transition relation. We say a program is terminating if all of its executions are finite. A program is called non-terminating if there exists at least one infinite execution. When trying to prove termination, formally we are trying to prove that the program’s transition relation is well-founded. In a sense, termination is the user’s experience, whereas well-foundedness is a mathematical property the holds of transition relations of terminating programs. Despite their differences, we shall use the two terms interchangeably throughout these notes and lectures. Before attempting to automate the search for proofs of termination (as happens in the advanced literature) we first must ground ourselves with some basic concepts and notation—e.g. states, programs, ranking functions and well-founded relations.

3. States, sets and relations Throughout these notes we will be concentrating on program configurations. We call these configurations states. States are encoded as partial finite mappings from variables to values. Let S be the set of all such mappings. We will assume that the set of variables, Var, is infinite, and formed of strings expressed in sans-serif font (e.g. x ∈ Var). The set of values, Val, will be an under-specified set of values which can include Z or other arithmetic constants. Later we will point to papers which describe termination methods supporting programs with dynamically allocated heap-based data structures. Depending on the context we will use two forms of notation interchangeably when describing relations over states: sets of pairs of states, and formulae drawn from quantifier-free first-order logic with pre- and post-variables. When using formulae, unprimed variables will represent the pre-variables and primed variables will represent the post-variables. We define the usual semantic mapping from formulae to the underlying sets of pairs of states that they represent, e.g. [[x < x ]] = {(s, t) | s(x) < t(x)}. If Q is a set of states using unprimed variables, we use the notation Q to mean a set expressed using primed variables such that Q ∼ = Q . Note that many of the definitions and results described in these notes hold over all sets and relations, not just those over states. Definition 1 (Relational application, composition, closure) Assume that R ⊆ S × T and I ⊆ S, we define the image of R on I (notationally, R(I)) as: R(I) {b | a ∈ I ∧ (a, b) ∈ R} Note that R(I) ⊆ T . If a ∈ S and R ⊆ S × T then we define R(a) ⊆ T as R(a) {b | (a, b) ∈ R} Let ; be relational composition where R; Q {(a, b) | ∃c. (a, c) ∈ R ∧ (c, b) ∈ Q}

164


We define R0 {(a, b) | a = b}. When k > 0, Rk R; Rk−1 . The non-reflexive and reflexive transitive closure of R are defined respectively: R+ R∗

{(a, b) | ∃n > 0. (a, b) ∈ Rn } {(a, b) | ∃n ≥ 0. (a, b) ∈ Rn }

We define relational inverse and projection as follows: R−1 Π1 (R) Π2 (R)

{(a, b) | (b, a) ∈ R} {a | ∃b. (a, b) ∈ R} {b | ∃a. (a, b) ∈ R}

If Q is a set of states (i.e. Q ⊆ S) then ¬Q S − Q

4. Well-ordered sets and well-founded relations In this section we describe what it means for a set to be well ordered, and a relation to be well founded. Definition 2 (Total-order) The structure (S, ≥) forms a total order iff for all a, b, c ∈ S • • • •

a ≥ a (reflexive), a ≤ b and a ≥ b then a = b (antisymmetry), If a ≥ b and b ≥ c then a ≥ c (transitivity), a ≤ b or a ≥ b (totality),

Definition 3 (Well order) (S, ≥) forms a well order iff it is a total order and every nonempty subset of S has a least element. Example 1 The natural numbers, N, are a well-ordered set, as in the worst case 0 is the least element of any subset. The integers, Z, are not well ordered because there is no least element. However, for any integer constant b ∈ Z, the set {x | x ∈ Z ∧ x ≥ b} is a well-ordered set. Example 2 The non-negative real numbers with relation ≥ are not a well-ordered set because there there is no least element in the open interval (0,1). The nonnegative real numbers can be made into a well-ordered set when paired with the alternative comparison relation ≥w , which we define x ≥w y x ≥ y + 1 ∨ x = y. Definition 4 (Sequences) We say that s is an S-sequence if s = s1 , s2 , . . . and each si ∈ S. A finite sequence will have a last index last(s). Let R ⊆ S × S. A finite sequence is said to be permitted by R iff ∀i ∈ {1, . . . last(s) − 1}. R(si , si+1 ). An infinite sequence is permitted by R iff ∀i. i > 0 ⇒ R(si , si+1 ). Let I ⊆ S. We say that s is permitted by (I, R) iff s is permitted by R and s1 ∈ I.


165

Definition 5 (Well-founded relations) A binary relation R ⊆ S ×S is well-founded iff it does not permit infinite sequences. Example 3 The relation x > x ∧ x > 0 is a well-founded relation if the variables range over the integers or natural numbers, but not if the variables range over the reals. The reason is that, if we apply the relation point-wise to any sequence of naturals or integers, we’ll see that the values along the sequence are forced to go down towards (and eventually pass) a bound. Thus no permitted sequence can be infinite. In the reals the constraint x > x does not require the value to go down enough to guarantee eventual progress to 0. The relation x ≥ x + 1 ∧ x > 0, on the other hand, is well founded in all three interpretations. Theorem 1 Assume that (S, ≥) is a total order. (S, ≥) is a well order iff the relation x > y (defined as x > y x ≥ y ∧ x = y) is well founded on S-sequences. Proof. Well-ordered set ⇒ Well-founded relation: By a contrapositive argument, assume that > is not well founded, meaning in this case that there is an infinitely descending chain of S-elements. In this case there can be no least element. Well-ordered set ⇐ Well-founded relation: Again, by a contrapositive argument. Assume that the infinite S-subset S has no least element (the fact that every finite set has a least element can be established using the fact that S is a total order). Let s1 ∈ S . Since s1 cannot be minimal we know that there exists an s2 ∈ S such that s1 > s2 , and an s3 ∈ S such that s2 > s3 , etc. Therefore, using the somewhat controversial axiom of dependent choice we can show that there exists an infinite sequence of S -elements that is permitted by > Observation 1 If Q is well founded and R ⊆ Q, then R is well founded. Proof. Assume that R is not well founded. Therefore there exists an infinite sequence s such that ∀i.(si , si+1 ) ∈ R. Because R ⊆ Q, we know that ∀i.(si , si+1 ) ∈ Q, thus contradicting the claim that Q is well founded. Corollary 1 If R is not well founded and R ⊆ Q, then Q is not well founded. Remark on Cantor’s ordinal numbers. We often see Cantor’s ordinal numbers [4] used in the literature discussing well-ordered sets. Cantor’s ordinals are a canonical representation for sets of well-ordered sets who are all related in size. (e.g. the natural numbers and any isomorphic set can be represented by the ordinal number ω). In these notes we avoid the ordinals for the reason that, although they can make a fundamental discussion more concise, they come at a great initial cost. Many distracting ideas and notation would need to be introduced.

166


5. Ranking functions and ranking relations The most popular method of proving a relation R ⊆ S × S well founded is to follow Turing’s suggestion [19] and find a map from the structure (R, S) to some known well-ordered set (≥, T ) and then prove that the map is structurepreserving (i.e. that it is a homomorphism). Since we know that the > relation (where x > y x ≥ y ∧ x = y) on T is well founded, by the properties of homomorphisms and Observation 1, we know that R too is well founded. Turing’s maps are typically called ranking functions. Definition 6 (Ranking function) A mapping f with a range to a well-ordered set is called a ranking function. In cases where f ranges over a set that would be a well-order if a bounder were given, we may chose to make the bound explicit. In this case we say that (f, b) is a ranking function. In cases where the set would be a well-order if an explicit delta d were given, then we say (f, b, d) is the ranking function. Definition 7 (Ranking relation) Let f : X → Y be a ranking function. We define f ’s ranking relation, f , to be f

We also introduce variants of f,b

= {(s, t) | f (s) > f (t)} for the case where an explicit bound is needed

= {(s, t) | f (s) > f (t) ∧ f (s) ≥ b}

and where an explicit delta is needed f,b,d

= {(s, t) | f (s) ≥ f (t) + d ∧ f (s) ≥ b}

Observation 2 For any ranking function f , f is well founded. Analogously, for any ranking function (f, b), f,b is well founded. Proof. We know that there exists some Y such that f : X → Y such that (≥ , Y ) is a well-ordered set. Thus, due to Theorem 1, we know that > is a wellfounded relation on sequences drawn from Y . By way of contradiction, assume that s1 , s2 , s3 , . . . is an infinite sequence permitted by f . This gives rise to the infinite sequence of Y -elements f (s1 ) > f (s2 ) > f (s3 ) > . . .. But this infinite sequence is not permitted, as (≥, Y ) is well ordered. Example 4 Consider the example relation R x > 0 ∧ y > 0 ∧ x = x − 1 ∧ y = y + 1 Assume that x and y range over the integers. To prove R well-founded we can use the ranking function f (s) = s(x) and bound 0 to construct f,0 :

167


let let let let let let let

n0 = Dp.constant 0 n1 = Dp.constant 1 x = Dp.var "x" y = Dp.var "y" x’ = Dp.var "x’" y’ = Dp.var "y’" R = Dp.conj [ Dp.gt x n0 ; Dp.gt y n0 ; Dp.eq x’ (Dp.sub x n1) ; Dp.eq y’ (Dp.add y n1) ] let f = x let f’ = x’ let RR = Dp.conj [ Dp.gt f f’ ; Dp.ge f n0 ] let query = Dp.implies R RR Dp.valid query |> print_bool

Figure 1. F# code which proves the condition from Example 4 f,0

{(s, t) | f (s) > f (t) ∧ f (s) ≥ 0} {(s, t) | s(x) > t(x) ∧ s(x) ≥ 0} [[x > x ∧ x ≥ 0]]

= = =

To prove that the inclusion R ⊆ f,0 holds we can construct a query for a decision procedure. See Figure 1 for an implementation expressed in F# using an interface to the Z3 decision procedure tool. When executed this program prints the result true.

6. Supporting invariants The common wisdom when proving a relation well founded is that one must find both a ranking function and a supporting invariant. The difficulty that this strategy is solving is the fact that, in practice, relations are often only well founded when restricted to the states reachable by the relation from some set of initial states. Definition 8 (Transition systems) We say that P is a transition system if P = (I, R, S), where S is the (possibly infinite) set of program states represented as finite partial functions from Vars to Vals, I ⊆ S, and R ⊆ S × S. We call I the initial states, and R the update relation. Definition 9 (Reachable states) We call R∗ (I) the reachable states of the transition system P = (I, R, S). Definition 10 (Transition relation) Let P = (I, R, S). We use the notation R denote P ’s transition relation: R

I

R ∩ (R∗ (I) × R∗ (I))

I

to

168


In contrast to transition relations, in practice update relations are usually simple disjunctions representing simple commands—usually update relations are much larger than R I , though of course it is possible to define a R such that R = R I . Definition 11 (Invariant) A set of states Q is an invariant of a relation R ⊆ S × S and initial set I ⊆ S iff Q ⊇ R∗ (I). Note that, because R I ⊆ R, if R is well founded then R I is also well founded. Clearly R∗ (I) is the strongest possible invariant, but it is not computable in theory and very difficult to compute in practice. Instead we usually look for a weaker (but easier to find) invariant Q that is strong enough to prove relations well founded. Because, by definition, Q ⊇ R∗ (I), if Q × Q ∩ R is well founded, then we know that R I is well founded. Note also that Q × Q ∩ R = Q × T ∩ R whenever Q ⊆ T . Thus it suffices to find an invariant and prove Q × S ∩ R well founded, assuming that R ⊆ S × S. Example 5 Consider the relation R x > 0 ∧ x = x + y ∧ y = y, where the variables range over the integers. R is not well founded if y ≥ 0. However, if we let the initial set of states be I y ≤ −1, then R I is well founded. To prove this we can let Q = y ≤ −1. Luckily, in this case, Q is an inductive invariant, meaning that we can show Q invariant simply via induction (i.e. I ⇒ Q and Q ∧ R ⇒ Q ) To prove that Q × Q ∩ R is well founded we can show that Q × Q ∩ R ⊆ x,0 . This query is encoded in Figure 2.

7. Proving non-termination Until now we have considered only proving termination, but not disproving—i.e. proving non-termination. Definition 12 (Recurrence sets) Assume P = (I, R, S). Q ⊆ S is a recurrence set of P if: 1. Q ⊆ Π1 (R) 2. Q ∩ I = ∅ 3. ∀x ∈ Q. ∃x . (x, x ) ∈ R ∧ x ∈ Q Theorem 2 R

I

is not well founded iff there exists a recurrence set Q for R

I

Example 6 Consider the relation over S: R x > 0 ∧ (x = x − 1 ∨ x = x) Let I S. The relation R I is not well founded. To prove it not well founded (as opposed to simply failing to prove it well founded) we define Q = {s | s(x) = 1 ∧ s ∈ S}. Π1 (R) = {s | s(x) > 0 ∧ s ∈ S}, thus Q ⊆ Π1 (R). Because Q ⊆ I and Q = ∅, Q ∩ I = ∅. Finally, R(Q) = Q, thus ∀x ∈ Q.∃x .(x, x ) ∈ R ∧ x ∈ Q.


let let let let let let

169

n0 = Dp.constant 0 x = Dp.var "x" x’ = Dp.var "x’" y = Dp.var "y" y’ = Dp.var "y’" R = Dp.conj [ Dp.gt x n0 ; Dp.eq x’ (Dp.add x y) ; Dp.eq y’ y ]

in let I = Dp.lt y n0 // The relation Q * Q is expressed via Q && Q’, where Q’ is like // Q but expressed over primed variables let Q = Dp.lt y n0 let Q’ = Dp.lt y’ n0 // Base check Dp.implies I Q |> Dp.valid |> print_bool // Inductive check Dp.implies (Dp.conj [Q;R]) Q’ |> Dp.valid |> print_bool // WF-check let RR = Dp.conj [ Dp.gt x x’ ; Dp.ge x n0 ] Dp.implies (Dp.conj [R;Q;Q’]) RR |> Dp.valid |> print_bool

Figure 2. Implementation of the check described in Example 5.

8. Composing termination arguments In many cases, constructing a ranking function for a complex relation can be a subtle art. As we have seen: once we know a ranking function, proving the necessary subset inclusion is usually not difficult—finding the ranking function argument is the hard part. This section describes a method for constructing termination arguments via the composition of small sub-arguments. As we will see later, the method makes the search for and construction of termination arguments easier, but makes checking the argument more difficult. Modern approaches to termination are based on this result. Theorem 3 (Podelski & Rybalchenko) Let be a binary relation R ⊆ S × S. Let Q1 , Q2 , . . . Qn be a finite set of binary relations Qi ⊆ S × S such that each Qi is well founded. R is well founded iff there exist a Q1 , Q2 , . . ., Qn such that R+ ⊆ Q1 ∪ Q2 ∪ . . . ∪ Qn . The proof of this theorem can be found in [14]. It is important to note that the union of well-founded relations is not necessarily well founded, thus making Theorem 3 a little surprising. Transitive closure is the key to Theorem 3’s soundness. To see why this is true consider the relations P 0 < x ∧ x < x and Q 100 > x ∧ x > x. Both P and Q are well founded,

170


let let let let let let

n0 = Dp.constant 0 x = Dp.var "x" x’ = Dp.var "x’" y = Dp.var "y" y’ = Dp.var "y’" R_star_abs = Dp.conj [ Dp.gt x n0 ; Dp.gt y n0 ; Dp.disj [ Dp.conj [Dp.gt x x’; Dp.ge y y’ ] ; Dp.conj [Dp.ge x x’; Dp.gt y y’ ] ] ] let RR_x = Dp.conj [ Dp.gt x x’ ; Dp.ge x n0 ] let RR_y = Dp.conj [ Dp.gt y y’ ; Dp.ge y n0 ] let arg = Dp.disj [ RR_x ; RR_y] Dp.implies R_star_abs arg |> Dp.valid |> print_bool

Figure 3. Implementation of the check described in Example 7.

but P ∪ Q is not. To see that P ∪ Q is not well founded consider the case where s(x) = 5. In this case (s, s) ∈ (P ∪ Q)2 , thus making {s | s(x) = 5 ∧ s ∈ S} a valid recurrence set for (P ∪ Q)2 . Example 7 Consider the relation R

∨

(x > 0 ∧ y > 0 ∧ x = x − 1 ∧ y = y) (x > 0 ∧ y > 0 ∧ x = x ∧ y = y − 1)

We can prove R well founded by showing R ⊆ x+y,0 . Alternatively we use Theorem 3 and establish termination via proof that R+ ⊆ x,0 ∪ y,0 . Note that we cannot prove the inclusion R+ ⊆ x,0 ∪ y,0 directly with any known decision procedure, as they do not support transitive closure (transitive closure for infinite-state systems is undecidable in theory, and difficult in practice). In the advanced research literature we see the use of techniques from program analysis + to be being adapted to address this class of question. For now, define Rα + (x > 0 ∧ y > 0 ∧ x ≤ x ∧ y < y) ∨ (x > 0 ∧ y > 0 ∧ x < x ∧ y ≤ y) Rα + . Thus we can use It can be proved (via methods described later) that R+ ⊆ Rα + to check the condition from Theorem 3. An encoding of this check can be Rα found in Figure 3. Note that finding x,0 and y,0 is, in a sense, easier than x+y,0 . The reason is that if we can often find the former argument by looking individually at R’s disjuncts: x,0 is motivated by looking at the first disjunct in R (i.e. x > 0 ∧ y > 0 ∧ x = x − 1 ∧ y = y), and y,0 is motivated by the second.


171

As mentioned above, we find that Theorem 3 makes the construction of termination arguments easier but—because of the use of transitive closure—the checking of the inclusion harder. For more discussion on this topic, see [8] Definition 13 (Termination arguments, validity) We say that M is a valid termination argument of R’s iff R+ ⊆ M and M is disjunctively well founded or R ⊆ M and M is well founded. We say that a valid recurrence set is a valid argument for non-termination.

9. Decomposition using program structure When we consider programs with locations and nested loops the ranking function to prove termination for even the simplest program can be surprisingly complex if we attempt to directly find a ranking function using the relation that the code denotes. The difficulty is that the program’s notation of location complicates matters. A program’s set of locations can actually work to our advantage if we use them appropriately. Following Floyd’s suggestion [10], we define a technique that allows us decompose a single termination check into a fixed number of easier checks. The decomposition makes use of our assumption that the range of pc is finite in any state in reachable state. The decomposition technique is, in fact, general and can be used with any program variable of finite range. Definition 14 Assume that Q is a set of states. We define the set Q Q

p

p

as

Q ∩ {s | p(s)}

We also define a similar restriction on relations: R

p

R ∩ {(s, t) | p(s) ∧ p(t)}

Theorem 4 Assume that v ∈ Var and that the set L is finite, where L = {x | s ∈ R∗ (I) ∧ s(v) = x} R

I

is well founded if for all l ∈ L, (R

+ I ) v=l

is well founded.

Proof. By contradiction and the pigeon-hole principle. Assume that s = s1 , s2 , s3 , . . . is an infinite sequence such that (s1 , s2 ) ∈ R I , (s2 , s3 ) ∈ R I , etc. Because L is finite and R∗ (I)(v) = L, we know that there exists a c ∈ L such that si (v) = c infinitely-often in s. Let s be the infinite sequence of these states. We know that s is in the sequences allowed by R + I ∩ {(s, t) | s(v) = t(v) = c} + ) . But (R ) is well founded. (i.e. (R + v=c v=c I I Example 8 Consider the relation R

∧

(b = 1 ∧ b = 0) ∨ (b = 0 ∧ b = 1) (b = 1 ∧ x = x − 1 ∧ x > 0) ∨ (b = 0 ∧ x = x)

172


In this case we could invent a fairly complex ranking function involving both x and b, or alternatively we can simply prove R+ b=0 ⊆ x,0 and R+ b,1 ⊆ x,0 . Note that we can do slightly better—the following lemmas will allow us to eliminate one of these conjuncts. Lemma 1 Assume that v ∈ Var and that the set L = R∗ (I)(v) is finite. Let k1 and k2 be constants from Val. Assume that, if (s, t) ∈ R and t(v) = k2 then + s(v) = k1 . (R + I ) v=l is well founded for each l ∈ L iff (R I ) v=l is well founded for each l ∈ L − {k2 }. Proof. By contradiction. Assume that there is an infinite sequence s = s1 , s2 , s3 , . . . allowed by R such that si (v) = k2 infinitely often. By assumption, if si+1 (v) = k2 then si (v) = k1 . Thus si (v) = k1 occurs infinitely often in s. But, by assumption, (R + I ) v=k1 is well founded, meaning that s cannot be infinite and thus contradicting the starting assumption. Lemma 2 Assume that v ∈ Var and that the set L = R∗ (I)(v) is finite. Let k1 and k2 be constants from Val. Assume that, if (s, t) ∈ R and s(v) = k2 then + t(v) = k1 . (R + I ) v=l is well founded for each l ∈ L iff (R I ) v=l is well founded for each l ∈ L − {k2 }. Proof. By the same argument as Lemma 1 Lemmas 1 and 2 allow us to remove one of the termination checks from Example 8. We can now simply prove R well founded by proving R+ b,0) ⊆ x,0

10. Further reading The reader interested in examining the original papers from which these notes are drawn should begin with the proof of termination’s undecidability [18,17], and the seminal papers on proving program correctness (e.g. Turing’s paper on proving programs correct [19], Gupta et al. [11] for more information on methods of proving non-termination, and Floyd’s paper on program semantics [10]. Readers interested in well-ordered sets, well-founded relations, and the ordinals should refer to a text like [4]. Readers interested in disjunctive termination proofs (i.e. Theorem 3) should read Podelski & Rybalchenko’s paper [14] together with Ramsey’s original paper [15]. The size-change principle [12] is very similar to Podelski & Rybalchenko’s result, but specialized to functional programs. For methods of automating termination based on Podelski & Rybalchenko’s result, see [2,3,5,8]. For methods of proving programs terminating that use dynamically allocated and deallocated data structures, see [3]. Note also that [13] produces arithmetic abstractions of programs that are sound for termination proving when treating programs with heap. For information on how to prove concurrent programs terminating, see [9]. To see methods on synthesizing preconditions which guarentee termination of non-terminating programs, see [7]. Finally, in the beginning of these notes we alluded to the fact that proving liveness properties can be converted into a problem of termination—for this reduction see [6]


173

11. Exercises 1. Assume that the variables in the following relations range over the integers. Which of the following relations are well founded? Which are not? Prove your answer by either finding (and proving the validity) of a ranking relation, or finding (and proving the validity) of a recurrence set. (a) 1 < 0 (b) 0 < 1 (c) x > x ∧ x < 1000 (d) x > x ∧ x > 1000 (e) x ≥ x + 1 ∧ x < 1000 (f) x ≥ x − 1 ∧ x < 1000 (g) y ≥ y + 1 ∧ z = z ∧ z < 1000 (h) y + 1 ≥ y ∧ z = z ∧ z < 1000 (i) (x = x − 1 ∨ x = x + 1) ∧ x < 1000 (j) x = x − z ∧ x > 0 (k) x = x − z ∧ x > 0 (l) x = x − 1 ∧ (x > 0 ∨ x < 200) (m) x > 0 ∧ y > 0 ∧ [(x = x − 1 ∧ y = y) ∨ (y = y − 1 ∧ x = x)] (n) x > 0 ∧ y > 0 ∧ [(x = x − 1 ∧ y = y) ∧ (y = y − 1 ∧ x = x)] (o) x > 0 ∧ y > 0 ∧ [(x = x − 1 ∧ y = y + 1) ∨ (y = y − 1 ∧ x = x)] (p) x > 0 ∧ y > 0 ∧ [(x = x − 1 ∧ y = y + 1) ∨ (y = y − 1 ∧ x = x + 1)] (q) (x > 0 ∨ y > 0) ∧ x = x − 1 ∧ y = y − 1 (r) x > 0 ∧ x = x − y ∧ y = y + 1 2. Reconsider the relations above in the case where the variables range over the real numbers? Which of the following relations are well founded? Which are not? Again, prove your answers. 3. Prove or disprove the following assertions: (a) (b) (c) (d) (e) (f) (g)

If R2 is well founded, R is well founded. If R is well founded, R2 is well founded. If R is well founded, R+ is well founded. If R+ is well founded, R is well founded. If R is well founded, R ∩ Q is well founded. If R is well founded, R ∪ Q is well founded. If R is well founded, R−1 is well founded.

4. Is the following relation well founded? x > 0 ∧ y > 0 ∧ [(x = x + 1 ∧ y = y − 1) ∨ (x = x − 1 ∧ y = y)] If so: Use Theorem 3 to prove the following relation well founded (i.e. figure out the transitive closure, find two ranking relations, etc). If not, find and prove the validity of a recurrence set. 5. Translate the following program into the representation using goto and assume statements:

174


while x > 0 do x := x − 1; y := x; while y > 0 do y := y − 1; od od exit; What is this program’s semantic meaning (in the form of a relation)? Give a valid set of cutpoints for this program. Find and prove the validity of a ranking function that proves the relation well founded. 6. Use the techniques from Section 9 to prove the following relation well founded: R ∧ ∧ ∧ ∧

x = 0 ⇒ (x = 1 ∧ y > 0 ∧ y = y) x = 1 ⇒ (x = 2 ∧ y = y) x = 2 ⇒ (x = 3 ∧ y = y − 1) x = 3 ⇒ (x = 0 ∧ y = y) (x = 3 ∨ x = 2 ∨ x = 1 ∨ x = 1 ∨ x = 0)

What is the value of R+

x=2 ?

References [1] [2]

[3] [4] [5] [6]

[7] [8] [9] [10] [11] [12] [13]

Building a better bug-trap. Economist Magazine, June 2003. J. Berdine, A. Chawdhary, B. Cook, D. Distefano, and P. O’Hearn. Variance analyses from invariance analyses. In POPL: Programming Language Design and Implementation, 2007. J. Berdine, B. Cook, D. Distefano, and P. O’Hearn. Automatic termination proofs for programs with shape-shifting heaps. In CAV: Computer Aided Verification, 2006. G. Cantor. Contributions to the Founding of the Theory of Transfinite Numbers. Dover, 1955. A. Chawdhary, B. Cook, S. Gulwani, M. Sagiv, and H. Yang. Ranking abstractions. In ESOP: European Symposium on Programming, 2008. B. Cook, A. Gotsman, A. Podelski, A. Rybalchenko, and M. Vardi. Proving that programs eventually do something good. In POPL: Programming Language Design and Implementation, 2007. B. Cook, S. Gulwani, T. Lev-Ami, A. Rybalchenko, and M. Sagiv. Proving conditional termination. In CAV: Computer Aided Verification, 2008. B. Cook, A. Podelski, and A. Rybalchenko. Termination proofs for systems code. In PLDI: Programming Language Design and Implementation, 2006. B. Cook, A. Podelski, and A. Rybalchenko. Proving thread termination. In PLDI: Programming Language Design and Implementation, 2007. R. Floyd. Symposia in applied mathematics. In Mathematical Aspects of Computer Science, 1967. A. Gupta, T. Henzinger, R. Majumdar, A. Rybalchenko, and R. Xu. Proving nontermination. In POPL: Principles of Programming Languages, 2008. C. S. Lee, N. D. Jones, and A. M. Ben-Amram. The size-change principle for program termination. In POPL: Principles of Programming Languages, 2001. S. Magill, J. Berdine, E. Clarke, and B. Cook. Arithmetic strengthening for shape analysis. In SAS: Static Analysis Symposium, 2007.


[14] [15] [16] [17] [18] [19]

175

A. Podelski and A. Rybalchenko. Transition invariants. In LICS: Logic in Computer Science, 2004. F. Ramsey. On a problem of formal logic. London Math. Soc., 30:264–286, 1930. G. Stix. Send in the Terminator. Scientific American Magazine, November 2006. C. Strachey. An impossible program. Computer Journal, 7(4):313, 1965. A. Turing. On computable numbers, with an application to the Entscheidungsproblem. London Mathematical Society, 42(2):230–265, 1936. A. Turing. Checking a large routine. In Report of a Conference on High Speed Automatic Calculating Machines, 1949.



177

Graphical Models of Separation Logic C. A. R. HOARE a , Ian WEHRMAN b,1 and Peter W. O’HEARN c a Microsoft Research, Cambridge, UK b The University of Texas at Austin, USA c Queen Mary University London, UK Abstract. Labelled graphs are used to model control and data flow among events occurring in the execution of a (possibly concurrent) program. Data flow is a unifying concept that covers both access to memory and communication along channels; it covers many variations including weakly consistent memory, re-ordered execution, and communication channels that are multiplexed, buffered, or otherwise unreliable. Nevertheless, the laws of Hoare and Jones correctness reasoning remain valid when interpreted in this general model. The key is use of the same language and logic for the specification of programs as for description of the behavior of programs. We make no attempt to lift the level of abstraction above that of the atomic events involved in program execution. Keywords. concurrency, formal semantics, separation logic

1. Introduction In this paper, we present a trace semantics based on graphs: nodes represent the events of a program’s execution, and edges represent dependencies among the events. The style is reminiscent of partially ordered models [12,16], though we do not generally require properties like transitivity or acyclicity. Concurrency and sequentiality are defined in Section 2 using variations on separating conjunctions: whereas the conjunction in the original separation logic partitions addresses in a heap [11,14], the conjunctions here partition events in a trace. We show graphical models of simple programming primitives in Section 3, and of more advanced primitives in Section 7. The model has pleasant algebraic properties, which are shown with surprisingly simple proofs. We present a number of theorems about the generic model, including the soundness of the laws of Hoare logic [4] in Section 5 and the Jones rely/guarantee calculus [6] in Section 6. The paper is liberally illustrated by diagrams.

2. Traces and Separation A directed graph is a pair of sets (EV , AR), where EV is a set of nodes and AR is a set of (directed) arrows linking the nodes. The objects of EV represent occurrences 1 Corresponding Author: The University of Texas at Austin, Department of Computer Sciences, 1 University Station, C0500, Austin, TX 78712-0233, USA; E-mail: [email protected].

178

C.A.R. Hoare et al. / Graphical Models of Separation Logic

of atomic events recorded in a trace of program execution; the objects of AR represent control or data flows that occur between events. We assume that the sets EV and AR contain all possible events in the execution of a program. A labelled graph also has a labelling function on its events and arrows. The theorems in this paper only make use of event labels, but our examples also describe labels on arrows. We write label (e) = a to mean that a is the atomic action of the programming language (e.g., x := x + 12) whose execution is recorded as e. A trace is a subset of EV that records the execution of a component of the program. We will identify each command of our programming language with the set of traces of all its possible executions, in any possible environment. An atomic command is one whose execution gives rise to only a single event, and this event has label : Definition 1. [] =def {tr | ∃r ∈ tr.tr = {r} & label (r) = }. We can define the semantics of a program as the set of its possible traces, as in the CSP traces model [15]. For example, the [] is the set of traces associated with a label (thought of as a program) . If p and q are events, we write p → q to indicate the existence of an arrow between + them. As usual, we write ← and → for the inverse and transitive closure of the → rela+ + + tion, respectively. Additionally, we write ↔ for → ∪ ← and ↔ for → ∪ ←. When we wish to restrict a relation to a particular set of events t ⊆ EV , we write, for example, + →t . For trace tq, we write p → tq when, for some event q ∈ tq, p → q; and similarly tp → tq when for some p ∈ tp and q ∈ tq, p → q.

Figure 1. A trace separated with (∗)

Let P ∗ Q be the structured command that denotes the concurrent execution of components P and Q. Obviously no event is simultaneously a part of the execution of both these commands. Furthermore, every event in the execution of P ∗ Q is in the execution of at least one of P and Q. Therefore, the most general form of a trace tr of P ∗ Q is the disjoint union of some trace tp of P with some trace tq of Q:


179

tr = tp ∗ tq ≡def tr = tp ∪ tq & tp ∩ tq = ∅. An example of a trace separated with (∗) is shown in Figure 1. The trace separator (∗) is a partial function on traces; it can be lifted to a total function on sets of traces in the usual way: Definition 2. P ∗ Q =def {tr | tr = tp ∗ tq & tp ∈ P & tq ∈ Q}. We call the (∗) function on trace sets the concurrent separator. In words, a trace is a model of P ∗ Q exactly when it can be split into two disjoint parts, one of which is a trace of P and the other a trace of Q. This definition can be implemented by running P and Q concurrently, as separate threads or processes in the same or in different computers. There is no restriction on the arrows which communicate between events of P and events of Q. The two threads may communicate freely with each other, e.g. through shared memory or channels.

Figure 2. A trace separated with (;)

A stronger notion is sequential separation. Informally, a trace tr may be split into a sequential separation tp ; tq when there is no arrow from an event of tq to an event of tp: tr = tp ; tq ≡def tr = (tp ∗ tq) & ¬(tp ← tq). An example of a trace separated with (;) is shown in Figure 2. Again, the trace separator (;) is lifted pointwise to a total function on trace sets: Definition 3. P ; Q =def {tr | tr = (tp ; tq) & tp ∈ P & tq ∈ Q}. This definition expresses an essential property of sequential composition. It allows implementations to optimise a program by interleaving events of the first trace with

180


events of the second; the events can even be executed concurrently, if they do not violate the dependency condition in the definition. We have thus defined what is sometimes called a “weak sequential composition” in concurrency theory, and it has the usual anomalous consequence.

;

tp

z:=x

tq

y:=3

*

x:=y

tr Figure 3. Backward dependency anomaly: finally z = 3

Consider the trace (tp ; tq) ∗ tr in Figure 3. In our definition, an event in tp can depend on an event of tq through a chain of dependencies in the concurrent thread tr. The events in Figure 3 are labeled with assignment statements to show how such a trace might arise. As a result of standard optimisations, this apparently paradoxical data flow—in which z may take the value 3—occurs in standard computers of the present day. Thus, our theory faithfully represents the (problematic) features of the real world. It is therefore surprising and encouraging that the model validates all the familiar proof rules of sequential and concurrent reasoning about programs [4,6], as we show in Sections 5 and 6. A yet stronger notion is parallel separation, in which distinct processes have no interdependencies among them. The definition allows (but does not compel) an implementation to run the whole of each process concurrently with the others, perhaps in its own partition of memory: tr = tp || tq ≡def tr = (tp ; tq) & tr = (tq ; tp). Again, we lift the definition of trace sets, and call the resulting operation a parallel separator: Definition 4. P || Q =def {tr | tr = (tp || tq) & tp ∈ P & tq ∈ Q}. In models based on sequential traces [15] this definition is given in terms of arbitrary interleaving. Our definition seems easier to reason with.


181

Figure 4. A trace separated with (||)

Figure 5. A trace separated with ([])

The fourth and strongest notion of separation holds between traces when at least one is empty: tr = tp [] tq ≡def tr = tp ∪ tq & (tp = ∅ ∨ tq = ∅). We can represent nondeterministic choice by lifting this operator to sets of traces. The each execution of process P [] Q behaves either as an execution of P or as an execution of Q: Definition 5. P [] Q =def {tr | tr = tp [] tq & tp ∈ P & tq ∈ Q}.

182


We shall not deal in further detail with the operators (||) and ([]). It is sufficient to note that they have the same algebraic properties as the concurrent separator (∗).

3. Graphical Models of Simple Programming Primitives This section shows graphical models of some simple primitive operations of some programming languages. Our models are presented informally with pictures of traces. Events in the traces are depicted by boxes that surround their labels. Dependencies are depicted by arrows. A plurality of arrows with identical labelling is indicated by an diagonal slash. The orientation of the arrows in the following pictures is informally meaningful: vertical arrows indicate dependencies between processes (i.e., across separators), and horizontal arrows indicate dependencies within a process (i.e., only across the sequential separator (;)). Arrows that represent data dependencies are labeled with this data and the resource across which it flows. For horizontal arrows, the resource is above and the data below; for vertical arrows, the resource is to the left and the data is to the right. We use the letters x, y, z for variables, and a, b, c for constant values (including names).

x a

b!a

b a

Figure 6. b!x: Output on channel b

The first primitive is shown in Figure 6. It shows a trace of the command b!x, an output of the value of variable x on communication channel b. The trace contains a single event, depicted as a box. The event has a single incoming arrow, which indicates the incoming flow value a of variable x, and a single outgoing arrow, which indicates the outgoing flow of value a on channel b. The value a flows in across x from within the process, and so is represented by a horizontal arrow. The value a flows on channel b outside of the process, and so is represented by a vertical arrow. Similarly, Figure 7 shows a trace of the command b?x, an input from communication channel b into variable x. The trace contains a single event, with a single input arrow that represents the input of value a from channel b. There may be many output arrows, which represent thread-local accesses of the value a via variable x. The value a flows out across x within the process, and so is represented by a horizontal arrow. Figure 8 shows a trace of a blocking input command, b?x.P (x), as in CCS. Its first action is to input a value on channel b and give it name x, which is local to the command P (x). We will use normal data flow arrows to carry the value that has been input to


183

b a

x a

b?a

Figure 7. b?x: Input from channel b

b a

b?a x a Figure 8. b?x.P (x): Blocking input from channel b

the places in P (x) where it is used. That is the function of the collection of arrows at the bottom right of Figure 8. But CCS also ensures that no action of P (x) is executed before the input. That is the function of the collection of control arrows at the top right of Figure 8.

x a

b!a

b a

b?a y a Figure 9. b!x ∗(b?y.P (y)): Communication across channel b

184


Figure 9 shows communication across channel b, as in CSP [15], by concurrent composition of an input with an output command: b!x ∗(b?y.P (y)). According to the definition of (∗), the events of this command include all and only the events of b!x and b?y.P (y). The value a from variable x is communicated across channel b, and then accessed via variable y by process P . Note that the communication between threads via channel b is represented by a vertical arrow.

b a

x d

c!d

b?a

c d

y a

Figure 10. c!x ∗(b?y.P (y)): Interleaved output and input events

Figure 10 also shows a concurrent composition of input and output commands, c!x ∗(b?y.P (y)), with c = b. Because the input and output commands employ different channels, no direct communication occurs—the data from the output commands flows to the environment, and the data from the input command flows from the environment. x a x:=a+b y b

x a+b

Figure 11. x := x + y: Variable assignment

Figure 11 shows an assignment command, x := x + y, which for the sake of example we will treat as atomic. The trace has only a single event, labeled with the variable x and the value assigned to it. There is a single input arrow for each variable in the expression on the right-hand-side of the assignment statement; in this case, one for variable x carrying value a, and one for variable y carrying value b. There are output arrows labeled with resource x and data value a + b, indicating the value of the variable after the assignment. All arrows are horizontal, indicating that variables should only be accessed locally, within a process. Finally, Figure 12 shows a program that combines that variable assignment, input, output and blocking input: x := x + y ; (c?z . (d!(x − z) ∗ d?y)) . After assigning x + y to variable x, a value for z is read from channel c (from the environment), and x − z is communicated across channel d, which then becomes locally available via variable y. Graphical models of additional, advanced commands are given in Section 7.

185


z

c

z

d!

c?

d x x:= y

x

d?

y x

Figure 12. x := x + y ; (c?z.(d!(x − z) ∗ d?y)): A combined example

4. Program algebra To facilitate comparison with (original) separation logic [11,14,10], in this section we use notations of propositional logic to represent the corresponding operations on sets. For example, P ∨ Q represents a nondeterministic choice between P and Q, and can easily be executed by executing either one of them. P ∧ Q specifies a conjunction of two desirable properties of a program; it may be false, and therefore cannot in general be executed. Nevertheless, conjunction is an essential connective for modular specification of programs. We define the special predicate false as the empty set of traces (which cannot be implemented), and skip as the set that contains only the empty trace (which is easily implemented by doing nothing). For predicate P and trace tp, we write P (tp) to indicate tp ∈ P , and say in this case that tp satisfies P . The inclusion P ⊆ Q can be interpreted as a refinement ordering: Definition 6. P |= Q ≡def P ⊆ Q. It means that every trace observed of P is also a possible trace of Q; hence we often prove P |= Q by showing, for an arbitrary trace t, that P (t) ⇒ Q(t). It follows that if P is implementable, then so is Q; and if P is incorrect, then so is Q. As result, Q can be implemented by running P instead. For example, the following theorem shows that the four separators form a chain of refinements: Theorem 1 (Refinement). P [] Q |= P || Q |= P ; Q |= P ∗ Q. We show that the (;) operator has all the familiar properties: it is associative, distributes across disjunction, and is monotonic. skip is its unit and false is a zero. The (∗) operator satisfies all these laws, as well as commutativity.

186


In the sequel, note that in reasoning about a partially defined term like tp ; tq, we adopt the convention that mention of a term implies that it is defined. As a result, all our equalities are strong equalities. Lemma 1. t = tp ;(tq ; tr) ⇔ t = (tp ; tq) ; tr Proof.

t = tp ;(tq ; tr) ⇔ {definition of (;)} t = tp ∪ (tq ; tr) & tp ∩ (tq ; tr) = ∅ & ¬(tp ← (tq ; tr)) ⇔ {definition of (;)} t = tp ∪ tq ∪ tr & tp ∩ (tq ∪ tr) = tq ∩ tr = ∅ & ¬(tp ← (tq ∪ tr)) & ¬(tq ← tr) ⇔ {set theory} t = tp ∪ tq ∪ tr & tp ∩ tq = tp ∩ tr = tq ∩ tr = ∅ & ¬(tp ← tq) & ¬(tp ← tr) & ¬(tq ← tr) ⇔ {definition of (;)} t = (tp ; tq) ∪ tr & (tp ∪ tq) ∩ tr = ∅ & ¬(tq ← tr) & ¬(tp ← tr) ⇔ {definition of (;)} t = (tp ; tq) ; tr

Theorem 2 (Associativity). P ;(Q ; R) = (P ; Q) ; R Proof.

(P ;(Q ; R))(t) ⇔ {definition of (;)} ∃tp, tq, tr : P (tp) & Q(tq) & R(tr) & t = tp ;(tq ; tr) ⇔ {Lemma 1} ∃tp, tq, tr : P (tp) & Q(tq) & R(tr) & t = (tp ; tq) ; tr ⇔ {definition of (;)} ((P ; Q) ; R)(t)

Lemma 2. t = tp ∗ tq ⇔ t = tq ∗ tp Proof.

t = tp ∗ tq ⇔ {definition of (∗)} t = tp ∪ tq & tp ∩ tq = ∅ ⇔ {set theory} t = tq ∪ tp & tq ∩ tp = ∅ ⇔ {definition of (∗)} t = tq ∗ tp

Theorem 3 (Commutativity). P ∗ Q = Q ∗ P Proof.

(P ∗ Q)(t) ⇔ {definition of (∗)} ∃tp, tq : P (tp) & Q(tq) & t = tp ∗ tq ⇔ {Lemma 2}


∃tp, tq : P (tp) & Q(tq) & t = tq ∗ tp ⇔ {definition of (∗)} (Q ∗ P )(t) Theorem 4 (Distributivity). 1. P ;(Q ∨ R) = (P ; Q) ∨ (P ; R) 2. (Q ∨ R) ; P = (Q ; P ) ∨ (R ; P ) Proof. We show the first part; the second is similar. (P ;(Q ∨ R))(t) ⇔ {definition of (;)} ∃tp, t2 : P (tp) & (Q ∨ R)(t2) & t = tp ; t2 ⇔ {definition of (∨)} ∃tp, t2 : P (tp) & (Q(t2) or R(t2)) & t = tp ; t2 ⇔ {propositional calculus} ∃tp, t2 : (P (tp) & Q(t2) & t = tp ; t2) or (P (tp) & R(t2) & t = tp ; t2) ⇔ {definition of (;)} ((P ; Q) ∨ (P ; R))(t)

Theorem 5 (Monotonicity). 1. P |= Q ⇒ (P ∗ R) |= (Q ∗ R) 2. P |= Q ⇒ (R ∗ P ) |= (R ∗ Q) Proof.

(P ∗ R)(t) {definition of (∗)} ∃tp, tr : P (tp) & R(tr) & t = tp ∗ tr ⇒ {assumption} ∃tp, tr : Q(tp) & R(tr) & t = tp ∗ tr ⇒ {definition of (∗)} (Q ∗ R)(t)

⇒

Theorem 6 (Unit, Zero). 1. (P ; skip) = (skip ; P ) = P 2. P ; false = false ; P = false Proof.

1.

(P ; skip)(t) ⇔ { definition of (;) and skip} ∃tp, tq : P (tp) & skip(tq) & t = tp ; tq ⇔ {skip(tq) implies tq = ∅} P (t)

187

188


2. = = =

P ; false {definition of (;)} {t | ∃tp ∈ P : ∃tq ∈ false : t = tp ; tq} {set theory, false = ∅} ∅ {definition of false} false

Let P 0 =def skip and P n+1 =def P n ; P , for all natural numbers n. Finite iteration of a program P , written P ∞ , is then defined as follows: Definition 7 (Iteration). P ∞ =def n P n . By Kleene’s theorem, P ∞ is the least fixpoint of the function λX.(X; P ). Trace sets are thus a model of Kleene algebra [7,5], where the additive and multiplicative operations are given respectively by disjunction and sequential composition (or, equally well, by disjunction and concurrent composition). Lemma 3. For all n ≥ 0, P ; P n = P n+1 Proof. By induction on n. If n = 0: = = =

P ;P0 {P 0 = skip} P ; skip {skip is unit, Theorem 6} skip ; P {definition of P n } P1

Otherwise: = = = =

P ; P n+1 {definition of P n } P ;(P n ; P ) {associativity of (;)} (P ; P n ) ; P {induction on n} P n+1 ; P {definition of P n } P n+2

Theorem 7 (Unfold). 1. (skip ∨ (P ∞ ; P ) |= P ∞ 2. (skip ∨ (P ; P ∞ )) |= P ∞ Proof.

1. skip |= P 0 |= P , and


189

(P ∞ ; P )(t) ⇒ {definition of (∗) and (;)} ∃n, tp , tp : P n (tp ) & P (tp) & t = tp ; tp ⇒ {definition of (∗)} ∃n : P n (t) ⇒ {definition of P ∞ } P ∞ (t) 2. From part 1) and Lemma 3.

Theorem 8 (Induction). 1. (Q ∨ (P ; R)) |= R) ⇒ (P ∞ ; Q) |= R 2. ((Q ∨ (R ; P )) |= R) ⇒ (Q ; P ∞ ) |= R Proof. We show by induction on n that, for all n, (P n ; Q) |= R. If n = 0 then: P0 ;Q |= {P 0 = skip, Theorem 6} Q |= {propositional logic} Q ∨ (P ; R) |= {assumption} R. Otherwise,

|= |= |= |= |=

P n+1 ; Q {Lemma 3} (P ; P n ) ; Q {associativity of (;)} P ;(P n ; Q) {induction on n} P ;R {propositional logic} Q ∨ (P ; R) {assumption} R.

The definitions of P ∗ Q and P ; Q are instances of general model theories of separation logic and bunched logic [13,3,2], and thus inherit all of the general properties implied by these theories. In the sequel we describe properties of the model that concern interaction between the connectives. Lemma 4. t = (tp ∗ tq) ;(tr ∗ ts) ⇒ t = (tp ; tr) ∗(tq ; ts)

190


Proof. ⇒ ⇒ ⇒ ⇒ ⇒

t = (tp ∗ tq) ;(tr ∗ ts) {definition of (;)} t = (tp ∗ tq) ∪ (tr ∗ ts) & (tp ∗ tq) ∩ (tr ∗ ts) = ∅ & ¬((tp ∗ tq) ← (tr ∗ ts)) {definition of (∗)} t = tp ∪ tq ∪ tr ∪ ts & tp, tq, tr, ts are pairwise disjoint & ¬((tp ∪ tq) ← (tr ∪ ts)) {set theory} t = tp ∪ tq ∪ tr ∪ ts & tp, tq, tr, ts are pairwise disjoint & ¬(tp ← tr) & ¬(tq ← ts) {definition of (;)} t = (tp ; tr) ∪ (tq ; ts) & tp, tq, tr, ts are pairwise disjoint {definition of (∗)} t = (tp ; tr) ∗(tq ; ts)

Theorem 9 (Exchange). (P ∗ Q) ;(P ∗ Q ) |= (P ; P ) ∗(Q ; Q ) Proof.

((P ∗ Q) ;(P ∗ Q ))(t) ⇒ {definition of (∗) and (;)} ∃tp, tq, tp , tq : P (tp) & Q(tq) & P (tp ) & Q (tq ) & t = (tp ∗ tq) ;(tp ∗ tq ) ⇒ {Lemma 4} ∃tp, tq, tp , tq : P (tp) & Q(tq) & P (tp ) & Q (tq ) & t = (tp ; tp ) ∗(tq ; tq ) ⇒ {definition of (∗) and (;)} ((P ; P ) ∗(Q ; Q ))(t)

Intuitively, the exchange law holds because the antecedent restricts dependencies of P and Q on both P and Q, whereas the consequent only restricts dependencies of Q on Q and of P on P . The laws below are easily derived from the exchange law by substituting skip for some of the operands. Corollary 1. 1. P ;(Q ∗ R) |= (P ; Q) ∗ R 2. (P ∗ Q) ; R |= P ∗(Q ; R) Proof. We show P ;(Q ∗ R) |= (P ; Q) ∗ R here; the other proof is similar. P ;(Q ∗ R) |= {skip is a unit of (∗), by Theorem 6} (P ∗ skip) ;(Q ∗ R) |= {Theorem 9, the Exchange law} (P ; Q) ∗(skip ; R) |= {skip is a unit of (;), by Theorem 6} (P ; Q) ∗ R.


191

5. Hoare Logic The familiar assertional triple P { Q } R over predicates P ,Q and R is defined as follows: Definition 8. P { Q } R ≡def (P ; Q) |= R. Note that our assertion language is the same as our programming language. Like programs, our assertions P and R describe the entire history of execution. Thus the triple defined above states that if P is a description of what has happened just before Q starts, then R describes what has happened when Q has finished. The more familiar kind of single-state assertions describe the history abstractly as the set of traces that end in a state satisfying the assertion. The usual axioms of assertional reasoning [4] are easily proved sound. Theorem 10. 1. 2. 3. 4. 5. 6. Proof.

P P P P P P

{ { { { { {

Q Q Q Q Q Q

} } } } } }

R R S R R R

& & & & & ⇒

P { Q } R ⇒ P { Q } R ∧ R P { Q } R ⇒ P ∨ P { Q } R S { Q } R ⇒ P { Q ; Q } R P { Q } R ⇒ P { Q ∨ Q } R P { Q } R ⇒ P ∗ P { Q ∗ Q } R ∗ R F ∗P { Q } F ∗R

1. We show (P ; Q) |= (R ∧ R ): P ;Q |= {assumption} R and R |= {definition of (∧)} R ∧ R

2. We show ((P ∨ P ) ; Q) |= R: (P ∨ P ) ; Q |= {Theorem 4, distributivity} (P ; Q) ∨ (P ; Q) |= {assumption} R∨R |= {propositional logic} R 3. We show (P ;(Q ; Q )) |= R: P ;(Q ; Q ) |= {definition of (;)} (P ; Q) ; Q |= {assumption, monotonicity of (;) by Theorem 5} S ; Q |= {assumption} S.

192


4. We show (P ;(Q ∨ Q )) |= R: P ;(Q ∨ Q ) |= {Theorem 4, distributivity} (P ; Q) ∨ (P ; Q ) |= {assumption} R∨R |= {propositional logic} R. 5. |= |= 6. ⇒ ⇒

(P ∗ P ) ;(Q ∗ Q ) {Theorem 9, the Exchange law} (P ; Q) ∗(P ; Q ) {assumption} R ∗ R P ; Q |= R {Theorem 5, monotonicity of (∗)} F ∗(P ; Q) |= F ∗ R {Corollary 1} (F ∗ P ) ; Q |= F ∗ R

The last two laws are reminiscent of two of the basic axioms of separation logic [10]. But the standard separation logic rule is stronger and more useful. This is because the standard definition of separating conjunction applies to assertions about the current state. The state is an abstraction of the history of events which caused it. The validity of the abstraction depends on assumptions about the consistency of memory, which in this work we have not made. We leave for future work the investigation of the logical connections between various kinds of weak memory and the validity of the relevant program proof rules. The weakest precondition of program Q and postcondition R is defined as follows: Definition 9. (Q –; R)(tr) ≡def ∀tq : Q(tq) & (tr ; tq) defined ⇒ R(tr ; tq). Informally, a trace satisfies (Q –; R) if, whenever followed by a trace of Q, the combined trace satisfies R. The following theorem states in terms of Hoare triples that (Q –; R) is a precondition of R under program Q, and that it is the weakest such condition. Theorem 11 (Galois adjoint). P { Q } R ⇔ P |= (Q –; R) Proof. In one direction: P (tp) and Q(tq) and tp ; tq defined ⇒ {definition of (;)} (P ; Q)(tp ; tq) ⇒ {assumption} R(tp ; tq). In the other direction:


193

(P ; Q)(tr) {definition of (;)} ∃tp, tq : P (tp) & Q(tq) & tr = tp ; tq ⇒ {assumption} ∃tp, tq : R(tp ; tq) & tr = tp ; tq ⇒ {predicate calculus} R(tr).

⇒

The (∗) operator has a similarly defined adjoint called the magic wand, usually written −∗. 6. The Rely/Guarantee Calculus A predicate is called acyclic when all of its traces are acyclic. Some theorems in this section require this assumption to ensure linearizeability.

tr

+ + +

e

tp

tq

Figure 13. Linearity

Theorem 12 (Linearity). Suppose e ∈ tr, and tr is acyclic. Then for some tp, tq, tr = tp ;{e} ; tq. +

Proof. Let tp = {d ∈ tr | d → e} and tq = tr \ (tp ∪ {e}), as shown in Figure 13. It + is not the case that e → tp, because then e → e, which violates acyclicity; so tp ;{e} is defined. It is not the case that tq → tp because if for some d ∈ tq such that d → tp, then + also d → e, which contradicts the definition of tq; so tp ; tq is defined. Finally, it is not the case that tq → e, because d ∈ tq such that d → e again contradicts the definition of tq. Predicate G is called an invariant when every event of a trace that satisfies G also satisfies G:

194


Definition 10. G invariant ≡def ∀tr : (G(tr) ⇔ ∀e ∈ tr : G({e})). Invariants are also satisfied by the empty trace, which informally means that an invariant can be satisfied by doing nothing. Theorem 13. For invariant G: 1. 2. 3. 4.

skip |= G G(tp ∪ tq) iff G(tp) and G(tq) G;G = G∗G = G G ∗ [] = G ; [] ; G, when G ∗ [] is acyclic.

1. ∀e ∈ ∅ : G({e}) is vacuously true, and so G(∅) by definition of invariant. G(tp ∪ tq) ⇔ {definition of invariant} ∀e ∈ (tp ∪ tq) : G({e}) ⇔ {set theory} ∀e ∈ tp : G({e}) and ∀e ∈ tq : G({e}) ⇔ {definition of invariant} G(tp) and G(tq). 3. (G ∗ G)(t) ⇔ {definition of (∗)} ∃tp, tq : t = tp ∗ tq & G(tp) & G(tq) ⇔ {G is invariant, part 2} ∃tp, tq : t = tp ∗ tq & G(tp ∗ tq) ⇔ {set theory} G(t) 4. In one direction:

Proof. 2.

(G ∗ [])(t) {definition of (∗) and []} ∃tr, e : G(tr) & t = tr ∗{e} ⇒ {Theorem 12, linearity} ∃tr1, tr2, e : G(tr1 ∗ tr2) & t = tr1 ;{e} ; tr2 ⇒ {G is invariant, part 3} ∃tr1, tr2, e : G(tr1) & G(tr2) & t = tr1 ;{e} ; tr2 ⇒ {definition of (;)} (G ; [] ; G)(t)

⇒

In the other direction: G ; [] ; G {(;) ⊆ (∗) and commutativity of (∗)} G ∗ G ∗ [] ⇒ {G is invariant, part 3} G ∗ []

⇒

The strongest invariant implied by both G and G is (G ∧ G ); the predicate G∇G defined below is the weakest invariant that implies both G and G :


195

Definition 11. G∇G (tr) ≡def ∀e ∈ tr : G({e}) ∨ G ({e}). It is easy to see that a predicate G is an invariant iff G = G∇G; other facts are collected below. Theorem 14. For invariant G: 1. Q |= G & Q |= G ⇒ (Q ∗ Q ) |= (G∇G ) 2. Q |= G & Q |= G ⇒ (Q ; Q ) |= (G∇G ) Proof. We show (Q ∗ Q ) |= (G∇G ); the other implication follows because Q ; Q |= Q ∗ Q . Let t be an arbitrary trace. (Q ∗ Q )(t) ⇒ {definition of (∗)} ∃tq, tq : Q(tq) & Q (tq ) & t = tq ∗ tq ⇒ {assumption} ∃tq, tq : G(tq) & G (tq ) & t = tq ∗ tq ⇒ {definition of (∇) and (∗)} (G∇G )(t).

As in the Jones rely/guarantee calculus, invariants are used to describe ways in which one process is permitted to interfere with another. A rely condition is an invariant that describes the assumptions a process makes about interference from its environment during execution; similarly, a guarantee condition is an invariant that describes the guarantee that a process makes regarding its own interference with the environment. Satisfaction of the invariant condition G by process Q is simply expressed by the implication Q |= G. The Jones quintuple P R { Q } G S is a partial correctness specification of program Q in the presence of interference from other threads. It allows the program Q to rely on the environment to satisfy the invariant R, and in turn guarantees the condition G. (R ∗ Q) also satisfies postcondition S on the assumption of precondition P : Definition 12. P R { Q } G S ≡def P { R ∗ Q } S & Q |= G. The base rule of the Jones calculus reduces concurrent reasoning to sequential reasoning within a single thread. Theorem 15. P R { [] } G S ⇔ P { R ; [] ; R } S & [] |= G, when R ∗ [] is acyclic. Proof.

P R { [] } G S ⇔ {definition} P { R ∗ [] } S and [] |= G ⇔ {Theorem 13, part 4} P { R ∗ [] ∗ R } S and [] |= G

Theorem 16 (Concurrency). P R { Q } G S & P R { Q } G S ⇒ (P ∧ P ) (R ∧ R ) { Q ∗ Q } (G∇G ) (S ∧ S ), when G |= R and G |= R .

196


Proof. Q ∗ Q |= G∇G follows from Theorem 14. Below we show (P ∧ P ) { (R ∧ R ) ∗(Q ∗ Q ) } S. By a similar argument it can be shown that (P ∧ P ) { (R ∧ R ) ∗(Q ∗ Q ) } S, from which the conclusion follows from Theorem 10. |= |= |= |= |= |=

(P ∧ P ) ;((R ∧ R ) ∗(Q ∗ Q )) { (;) and (∗) are monotonic } P ;(R ∗(Q ∗ Q )) { (∗) is monotonic and Q |= G } P ;(R ∗(Q ∗ G )) { (∗) is monotonic and G |= R } P ;(R ∗(Q ∗ R)) { associativity and commutativity of (∗) } P ;((R ∗ R) ∗ Q) { R is invariant, so R ∗ R = R by Theorem 13, part 3 } P ;(R ∗ Q) { P ;(R ∗ Q) |= S by assumption } S.

;

tq

q

tq

q

*

r

tr Figure 14. Weak sequentiality violates the Jones rule for sequential composition

The Jones rule for sequential composition is: P R { Q } G S & S R { Q } G S ⇒ P (R ∧ R ) { Q ; Q } (G∇G ) S . To prove soundness of this rule, we have to show Q ; Q |= G∇G and P { (R ∧ R ) ∗(Q ; Q ) } S. The first assertion follows from Theorem 14, but the second assertion is not valid in this setting. Consider the following model, where q ← r ← q :


197

P = {∅} R = {{r}, ∅} R = {{r}, ∅} Q = {{q}} Q = {{q }} S = {{r, q}, {q}} S = {{q, q }} The trace {r, q, q } is shown in Figure 14. The reader can check that the antecedents hold in this model, and also that {r, q, q } satisfies P ;((R ∧ R ) ∗(Q ; Q )), but not S . The countermodel resembles the paradoxical example in Figure 3 in that there is no direct dependency between q and q , but interference from the environment yields an indirect dependency from the second operand to the first. The Jones rule is of course valid for normal strong sequential composition, since all the events of the second operand would be forced by control dependency to be executed after those of the first operand. The anomalous dependency is then ruled out by acyclicity. But this would sacrifice all opportunity for standard optimisations. All that is necessary is to ensure that the “critical” events in the trace of P ; Q are connected by a control dependency. In practice (e.g., in a parallel ALGOL language [1]), critical events are protected by an exclusion semaphore; and the definition of the acquisition and release of semaphores requires that they be linearly ordered by a control arrow. To prove the weak sequential composition axiom in the Jones calculus, we formalize our assumptions as follows. We say an event p ∈ tp is critical with respect to tr when, for some event r ∈ tr, either p ↔ r. In established parlance, traces with critical events events would be called critical regions. We say tp is protected from tr if every pair of + events p, p ∈ tp that are critical with respect to tr are connected; i.e., p ↔tp p . (Recall + + + from Section 2 that we write ↔ to mean → ∪ ←, and in particular not to indicate the transitive closure of ↔.) Finally, P is protected from R when every tp ∈ P is protected from every tr ∈ R, and P ∗ R is acyclic. In Figure 3, the two events in the trace tp ; tq are both critical with respect to tr. To protect them, it is necessary to connect these critical events by a chain of dependencies. Then the possibility of a backward dependency is ruled out by acyclicity. The sequential composition theorem below is weakened to require that the program (Q ; Q ) be protected from the environment (R ∧ R ), which rules out the counterexample. Lemma 5. If tq ; tq is protected from tr and tr ∗(tq ; tq ) is defined, then there exists tr1, tr2 such that tr = tr1 ; tr2 and (tr1 ∗ tq) ;(tr2 ∗ tq ) is defined. +

Proof. Let tr1 = {e ∈ tr | ∃q ∈ tq : e → q} and tr2 = tr \ tr1. First, t = tr1 ; tr2 + because if there were some e1 ∈ tr1 and e2 ∈ tr2 such that e2 → e1, then also e2 → q for some q ∈ tq, which implies e2 ∈ tr1. To show that (tr1 ∗ tq) ;(tr2 ∗ tq ) is defined, we also have to show 1) that tr1 ∗ tq and tr2 ∗ tq are defined, 2) tq ; tr2 is defined, and 3) tr1 ; tq is defined. By assumption, tr is disjoint from tq and tq , which implies that tr1 ∗ tq and tr2 ∗ tq are defined. Next, tq ; tr2 holds because if there were some r ∈ tr2 and q ∈ tq such that r → q, then also + r → q, which implies r ∈ tr1, a contradiction. Finally, suppose tr1 ; tq does not hold. Then, for some q ∈ tq and r ∈ tr1, q → r. + + By definition of tr1, q → r → q, for some q in tq. Hence also q ↔(tq ; tq ) q , because

198

C.A.R. Hoare et al. / Graphical Models of Separation Logic +

tq ; tq is protected from tr. But then either tq ← tq , which violates definedness of + + tq ; tq , or q → q → q, which violates the acyclicity. Lemma 6. For invariants R, R , (R ∧ R ) ∗(Q ; Q ) |= (R ∗ Q) ;(R ∗ Q), when Q ; Q is protected from (R ∧ R ). Proof.

((R ∧ R ) ∗(Q ; Q ))(t) ⇒ {definition of (;) and (∗) for trace sets} ∃tr, tq, tq : (R ∧ R )(tr) & (Q)(tq) & (Q )(tq ) & t = tr ∗(tq ; tq ) ⇒ {Lemma 5} ∃tr1, tr2, tq, tq : (R ∧ R )(tr1 ; tr2) & (Q)(tq) & (Q )(tq ) & t = (tr1 ∗ tq) ;(tr2 ∗ tq ) ⇒ {R and R are invariant, Theorem 13, part 3} ∃tr1, tr2, tq, tq : (R)(tr1) & (R )(tr2) & (Q)(tq) & (Q )(tq ) & t = (tr1 ∗ tq) ;(tr2 ∗ tq ) ⇒ {definition of (∗) and (;) } ((R ∗ Q) ;(R ∗ Q ))(t)

Theorem 17. P R { Q } G S & S R { Q } G S ⇒ P (R ∧ R ) { Q ; Q } (G∇G ) S , when (Q ; Q ) is protected from (R ∧ R ). Proof. To show the consequent, we have two obligations: 1. (Q ; Q ) |= (G∇G ) — By assumption, Q |= G and Q |= G . The desired property follows from Theorem 14. 2. P { (R ∧ R ) ;(Q ; Q ) } S — ⇒ ⇒

P { R ; Q } S & S { R ; Q } S {sequential composition of Hoare logic} P { (R ∗ Q) ;(R ∗ Q ) } S {Lemma 6} P { (R ∧ R ) ∗(Q ; Q ) } S.

7. Graphical Models of Advanced Programming Primitives In this section, graphical models are described for more advanced programming primitives. The same notational conventions are used as in Section 3. First consider the CCS [8] program b!x | b?y.P (y). There are two possibilities for its execution: either the output from the first process is directly communicated to the second process, as previously shown in Figure 9; or the input and output commands are interleaved, as in Figure 15. In spite of the fact that the channel name b is the same for both input and output, the channel may be multiplexed in CCS, so that both output and input communicate with their common environment, instead of with each other. This models the sequential programming phenomenon of interference.

199


b a

x d

b!d

b?a

b d

y a

Figure 15. b!x | (b?y.P (y)): CCS communication

x a A[a]:=b y b

A[a] b

Figure 16. A[x] := y: Array assignment

Figure 16 shows a trace of an array assignment command, A[x] := y. The trace contains a single event indicating the assignment. There is an input arrow for the value a of variable x, and value b of variable y. There are also output arrows, all labeled with the resource A[a] and its value after the assignment, b. x a a:=b y b

a b

Figure 17. [x] := y: Indirect assignment

Figure 17 shows a trace of an indirect assignment command [x] := y, as found in an imperative programming languages with references or pointers. The trace is similar to Figure 16. There is an incoming arrow for the value (memory location) a of variable x, and the value b of variable y. Again, there are output arrows, all labeled with the memory location a and its value after the assignment, b. Here we have modeled each element of the array A as a separate resource. This is more realistic that the traditional treatment of arrays in models of Hoare logic, where an assignment to a subscripted variable is treated as assigning an array value to the complete array. An advantage of the new model is that it enables different parts of the same array to be owned and updated simultaneously by concurrent processes. Figure 6 in Section 3 showed a direct output command, in which the name of channel is fixed in advance. Another level of indirection is needed, however, if channel names are dynamic, as in the π-calculus [9]. An indirect output command y!x, as in the π-calculus,

200


y b b!a x a

b a

Figure 18. y!x: Indirect output

is shown in Figure 18. The trace is identical that of the direct output command, but for another input arrow that provides the output channel name b from variable y.

b a

y b

b?a x a

Figure 19. y?x.P (x): Indirect input

Figure 19 shows an indirect blocking input command, y?x.P (x), as found in the πcalculus. The trace is identical to the direct blocking input command, shown in Figure 7 in Section 3, but for another input arrow that provides the input channel name b from variable y.

new a

x a

Figure 20. new x.P (x): Allocation

The π-calculus can declare a new channel for use in the process P by the notation new x.P (x). Figure 20 shows a trace of the command new x.P (x) from the π-calculus. Allocation of the new channel is modelled as an event added to the events of P . The additional event has no incoming arrows. As in the case of the input command, its outgoing arrows are just the set of input arrows of P that are labelled by with resource x and value a, the name of the new channel. In contrast with the input command, there are no control arrows, so the exact timing of the new event is undetermined. The semantics of the new


201

command is embodied in two constraints on the definition of a trace: 1) for each memory location a, at most one event event labeled new a must appear; and 2) a new a event must ∗ be connected to every event e labeled with a (i.e., d → e, where label (d) = new a). x a y b

b!a

b a

new b

y b

b?a x a

Figure 21. new y.(y!x | y?x.P (x)): π-calculus communication

Consider again the program b!x | (b?y.P (y)), which transfers the value stored in variable x across the shared channel b. In the π-calculus as in CCS, communication may occur either directly between the two processes, or may be interleaved with events from the environment. By using a newly allocated channel, interleaving can be avoided because no other processes can interfere. A trace of program new y.(y!x | y?x.P (x)) is shown in Figure 21. Note that the allocation event provides the channel name to both the channel input and output events, and the only input arrow is for the value of x to be communicated.

x a

dispose a

Figure 22. dispose x: Deallocation

The trace of the new command in Figure 20 could also be a trace of a memory allocation command in a C-like language. In Figure 22, we show a trace of a dispose command, which frees a previously allocation memory location. The trace contains a single event and no output arrows. There is a single input arrow that gives the memory location to be disposed. As with the new command, the semantics of the dispose command is embodied in two constraints on the definition of a trace: 1) for each memory location a, at most one event event labeled dispose a must appear; and 2) every event e labeled with ∗ a must be connected to a dispose a event (i.e., e → d, where label (d) = dispose a).

202


Acknowledgements The authors thank the following colleagues for their comments: Josh Berdine, Ernie Cohen, Philippa Gardner, Bernhard Möller, Aleksander Nanevski, Viktor Vafeiadis, Glyn Winskel, Hongseok Yang and the members of IFIP WG 2.3.

References [1] [2]

[3] [4] [5] [6] [7] [8] [9] [10] [11]

[12]

[13] [14] [15] [16]

Stephen D. Brookes. The essence of parallel ALGOL. Inf. Comput., 179(1):118–149, 2002. Cristiano Calcagno, Philippa Gardner, and Uri Zarfaty. Context logic as modal logic: completeness and parametric inexpressivity. In Martin Hofmann and Matthias Felleisen, editors, POPL, pages 123–134. ACM, 2007. Cristiano Calcagno, Peter W. O’Hearn, and Hongseok Yang. Local action and abstract separation logic. In LICS, pages 366–378. IEEE Computer Society, 2007. C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM, 12(10):576–580, 1969. Peter Höfner and Georg Struth. Automated reasoning in Kleene algebra. In CADE’07, volume 4603 of LNAI, pages 279–294. Springer, 2007. Cliff B. Jones. Development methods for computer programs including a notion of interference. PhD thesis, Oxford University, 1981. Dexter Kozen. On Kleene algebras and closed semirings. In Proceedings, Math. Found. of Comput. Sci., volume 452 of Lecture Notes in Computer Science, pages 26–47. Springer-Verlag, 1990. Robin Milner. A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science. Springer, 1980. Robin Milner, Joachim Parrow, and David Walker. A calculus of mobile processes, i. Inf. Comput., 100(1):1–40, 1992. Peter W. O’Hearn. Resources, concurrency, and local reasoning. Theor. Comput. Sci., 375(1-3):271–307, 2007. Peter W. O’Hearn, John C. Reynolds, and Hongseok Yang. Local reasoning about programs that alter data structures. In Laurent Fribourg, editor, CSL, volume 2142 of Lecture Notes in Computer Science, pages 1–19. Springer, 2001. Vaughan R. Pratt. The pomset model of parallel processes: Unifying the temporal and the spatial. In Stephen D. Brookes, A. W. Roscoe, and Glynn Winskel, editors, Seminar on Concurrency, volume 197 of Lecture Notes in Computer Science, pages 180–196. Springer, 1984. David J. Pym, Peter W. O’Hearn, and Hongseok Yang. Possible worlds and resources: the semantics of BI. Theor. Comput. Sci., 315(1):257–305, 2004. John C. Reynolds. Separation logic: A logic for shared mutable data structures. In LICS, pages 55–74. IEEE Computer Society, 2002. A. W. Roscoe. The theory and practice of concurrency. Prentice Hall, 1998. Glynn Winskel. Event structures. In Wilfried Brauer, Wolfgang Reisig, and Grzegorz Rozenberg, editors, Advances in Petri Nets, volume 255 of Lecture Notes in Computer Science, pages 325–392. Springer, 1986.


203

Verification, Performance Analysis and Controller Synthesis for Real-Time Systems a

Uli Fahrenberg a Kim G. Larsen a,1 , and Claus R. Thrane a Department of Computer Science, Aalborg University, Denmark Abstract. This note aims at providing a concise and precise Travellers Guide, Phrase Book or Reference Manual to the timed automata modeling formalism introduced by Alur and Dill [7,8]. The note gives comprehensive definitions of timed automata, priced (or weighted) timed automata, and timed games and highlights a number of results on associated decision problems related to model checking, equivalence checking, optimal scheduling, and winning strategies. Keywords. Timed automata, regions, zones, reachability, bisimilarity; priced and weighted timed automata, optimal reachability, optimal infinite runs, conditional optimality; timed games, winning strategies.

1. Introduction The model of timed automata, introduced by Alur and Dill [7,8], has by now established itself as a classical formalism for describing the behaviour of real-time systems. A number of important properties has been shown decidable, including reachability, model checking and several behavioural equivalences and preorders. By now, real-time model checking tools such as UppAal [17,57] and Kronos [32] are based on the timed automata formalism and on the substantial body of research on this model that has been targeted towards transforming the early results into practically efficient algorithms — e.g. [14,21,13,19] — and data structures — e.g. [56,54,20,20]. The maturity of a tool like UppAal is witnessed by the numerous applications — e.g. [48,60,55,45,40,38,52,61] — to the verification of industrial case-studies spanning real-time controllers and real-time communication protocols. More recently, model-checking tools in general and UppAal in particular have been applied to solve realistic scheduling problems by a reformulation as reachability problems — e.g. [42,47,1,62]. Aiming at performance analysis allowing to formulate and solve optimal scheduling problems, a recent extension of timed automata is that of priced or 1 Corresponding Author: Kim G. Larsen, Department of Computer Science, Aalborg University, Selma Lagerløfs Vej 300, 9220 Aalborg Øst, Denmark. E-mail: [email protected]

204

U. Fahrenberg et al. / Verification, Performance Analysis and Controller Synthesis

weighted timed automata [18,9]. Surprisingly, a number of properties have been shown to be decidable for this formalism [41,58,18,9,29]. The newly emerged branch UppAal Cora provides an efficient tool for solving cost-optimal reachability problems [53] and has been applied successfully to a number of optimal scheduling problems, e.g. [15,22,44]. Most recently, substantial efforts have been made on the automatic synthesis of (correct-by-construction) controllers from timed games for given control objectives. From early decidability results [63,12] the effort has lead to efficient on-thefly algorithms [68,34] with the newest branch UppAal Tiga [16] providing an efficient tool implementation with industrial applications emerging, e.g. [50]. This note aims at providing a concise and precise Travellers Guide, Phrase Book or Reference Manual to the land and language of timed automata. The note gives comprehensive definitions of timed automata, weighted timed automata, and timed games and highlights a number of results on associated decision problems related to model checking, equivalence checking, optimal scheduling, and winning strategies. The intention is that the note should provide an easy-to-access introduction and overview of the field to anyone interested.

2. Timed automata In this section we review the notion of timed automata introduced by Alur and Dill [7,8] as a formalism for describing the behaviour of real-time systems. We review the syntax and semantics and highlight the by now classical region construction underlying the decidability of several associated problems. Here we illustrate how regions are applied in showing decidability of reachability and timed and untimed (bi)similarity. However, though indispensable for showing decidability, the notion of region does not provide the means for efficient, practical tool implementations. The verification engine of UppAal instead applies so-called zones, which are convex unions of regions. We give a brief account of zones as well as their efficient representation and manipulation using difference-bound matrices. 2.1. Syntax and semantics Definition 2.1. The set Φ(C) of clock constraints ϕ over a finite set (of clocks) C is defined by the grammar ϕ ::= x k | ϕ1 ∧ ϕ2

(x ∈ C, k ∈ , ∈ {≤, }

The set Φ+ (C) of extended clock constraints ϕ is defined by the grammar ϕ ::= x k | x − y k | ϕ1 ∧ ϕ2

(x, y ∈ C, k ∈ , ∈ {≤, }


205

press? Bright x ≤ 100

x := 0

x = 100 x := 0 x := 0 Off

press? x := 0

x := 0 x = 100

Light x ≤ 100

x≤3 press? press? x>3 x := 0

Figure 1. A light switch modelled as a timed automaton.

Remark 2.2. The clock constraints in Φ(C) above are also called diagonal-free clock constraints, and the additional ones in Φ+ (C) are called diagonal. We restrict ourselves to diagonal-free clock constraints here; see Remark 2.44 for one reason. For additional modelling power, timed automata with diagonal constraints can be used, as it is shown in [8,26] that any such can be converted to a diagonalfree one; however the conversion may lead to an exponential blow-up. Definition 2.3. A timed automaton is a tuple (L, 0 , F, C, Σ, I, E) consisting of a finite set L of locations, an initial location 0 ∈ Q, a set F ⊆ Q of final locations, a finite set C of clocks, a finite set Σ of actions, a location invariants mapping I : L → Φ(C), and a set E ⊆ L × Φ(C) × Σ × 2C × L of edges. ϕ,a,r

We shall denote an edge (, ϕ, a, r, ) ∈ E by −−−→ . Example 2.1. Figure 1 provides a timed automaton model of an “intelligent” light switch. A press of the button turns on the light, which switches itself off after 100 time units. The switching-off can be prevented by pressing the button again, and pressing the button twice, with at most three time units between the presses, triggers a special bright light. Definition 2.4. A clock valuation on a finite set C of clocks is a mapping v : C → ≥0 . The initial valuation v0 is given by v0 (x) = 0 for all x ∈ C. For a valuation v, d ∈ ≥0 , and r ⊆ C, the valuations v + d and v[r] are defined by

206


(v + d)(x) = v(x) + d 0 for x ∈ r v[r](x) = v(x) for x ∈ /r Note. We will in general write B A for the set of mappings from a set A to a set B. The set of clock valuations on C is thus C ≥0 . Definition 2.5. The zone of an extended clock constraint in Φ(C) is a set of clock valuations C → ≥0 given inductively by x k = {v : C →

≥0

| v(x) k}

x − y k = {v : C →

≥0

| v(x) − v(y) k}

ϕ1 ∧ ϕ2 = ϕ1 ∩ ϕ2 We shall write v |= ϕ instead of v ∈ ϕ. Definition 2.6. The semantics of a timed automaton A = (L, 0 , F, C, Σ, I, E) is the transition system A = (S, s0 , Σ ∪ ≥0 , T = Ts ∪ Td ) given by

S = (, v) ∈ L × C s0 = (0 , v0 ) ≥0 v |= I()

ϕ,a,r a Ts = (, v) − → ( , v ) ∃ −−−→ ∈ E : v |= ϕ, v = v[r]

d Td = (, v) − → (, v + d) ∀d ∈ [0, d] : v + d |= I() Remark 2.7. The transition system A from above is an example of what is known as a timed transition system, i.e. a transition system where the label set includes ≥0 as a subset and which satisfies certain additivity and time determinacy properties. We refer to [2] for a more in-depth treatment. Definition 2.8. A (finite) run of a timed automaton A = (L, 0 , F, C, Σ, I, E) is a finite path ρ = (0 , v0 ) − → · · · (k , vk ) in A. ρ is said to be accepting if k ∈ F . Example 2.1 (continued). The light switch model from figure 1 has as state set S = {Off} ×

≥0

∪ {Light, Bright} × [0, 100]

where we identify valuations with their values at x. A few example runs are given below; we abbreviate “press?” to “p”: p

150

100

(Off, 0) −−→ (Off, 150) − → (Light, 0) −−→ (Light, 100) − → (Off, 0) p

10

p

1

p

100

→ (Light, 0) −→ (Light, 10) − → (Light, 0) −−→ (Light, 100) − → (Off, 0) (Off, 0) − p

100

→ (Light, 0) − → (Light, 1) − → (Bright, 0) −−→ (Bright, 100) − → (Off, 0) (Off, 0) −


207

x := 0

y := 0 a

0

y≤2

b x≤2

c x≥4∧y ≤2

1 Figure 2. A timed automaton with two clocks.

Example 2.2 (cf. [2, Ex. 11.7]). Figure 2 shows a timed automaton A with two clocks and a final location 1 . In the next section we shall be concerned with a reachability problem: Is the location 1 reachable, i.e. does there exist a state (1 , v) in A for some valuation v? 2.2. Reachability We are concerned with the following problem: Given a timed automaton A = (L, 0 , F, C, Σ, I, E), is any of the locations in F reachable? We shall later define the timed language generated by a timed automaton and see that this reachability problem is equivalent to emptiness checking: Is the timed language generated by A non-empty? An immediate obstacle to reachability checking is the infinity of the state space of A: The transition system A has uncountably many states, hence straight-forward na¨ıve reachability algorithms do not work for us. Notation 2.9. The derived transition relations in a timed automaton A = (L, 0 , F, C, Σ, I, E) are defined as follows: For (, v), ( , v ) states in A, we say that δ

d

→ ( , v ) if (, v) − → ( , v ) in A for some d > 0, • (, v) − α a • (, v) − → ( , v ) if (, v) − → ( , v ) in A for some a ∈ Σ, and δ

α

→∪− →)∗ ( , v ). • (, v) ( , v ) if (, v) (− Definition 2.10. The set of reachable locations in a timed automaton A = (L, 0 , F, C, Σ, I, E) is Reach(A) = ∈ L ∃v : C →

≥0

: (0 , v0 ) (, v)

Hence we can now state the reachability problem as follows: Problem 2.1 (Reachability). Given a timed automaton A = (L, 0 , F, C, Σ, I, E), is Reach(A) ∩ F = ∅ ?

208


Definition 2.11. Let A = (L, 0 , F, C, Σ, I, E) be a timed automaton. A reflexive C relation R ⊆ L × C ≥0 × L × ≥0 is a time-abstracted simulation provided that for all (1 , v1 ) R (2 , v2 ), δ

δ

→ (1 , v1 ) there exists (2 , v2 ) R (1 , v1 ) for which (2 , v2 ) − → • for all (1 , v1 ) − (2 , v2 ), and a • for all (1 , v1 ) − → (1 , v1 ), a ∈ Σ, there exists (2 , v2 ) R (1 , v1 ) for which a (2 , v2 ) − → (2 , v2 ). R is called a time-abstracted bisimulation if it is also symmetric; it is said to be F -sensitive if additionally, (1 , v1 ) R (2 , v2 ) implies that 1 ∈ F if and only if 2 ∈ F . Note that a time-abstracted (bi)simulation on A is the same as a standard δ

(bi)simulation on the transition system derived from A with transitions − → and a − →. Likewise, the quotient introduced below is just the bisimulation quotient of that derived transition. Definition 2.12. Let A = (L, 0 , F, C, Σ, I, E) be a timed automaton and R ⊆ L × C C ≥0 × L × ≥0 a time-abstracted bisimulation. The quotient of A = (S, s0 , Σ ∪ 0 ≥0 , T ) with respect to R is the transition system AR = (SR , sR , Σ ∪ {δ}, TR ) 0 given by SR = S/R , sR = s0 R , and with transitions δ

δ

• π− → π whenever (, v) − → ( , v ) for some (, v) ∈ π, ( , v ) ∈ π , and a a • π− → π whenever (, v) − → ( , v ) for some (, v) ∈ π, ( , v ) ∈ π . The following proposition expresses that F -sensitive quotients are sound and complete with respect to reachability. Proposition 2.13 ([4]). Let A = (L, 0 , F, C, Σ, I, E) be a timed automaton, R ⊆ C L× C ≥0 × L × ≥0 an F -sensitive time-abstracted bisimulation and ∈ F . Then ∈ Reach(A) if and only if there is a reachable state π in AR and v : C → ≥0 such that (, v) ∈ π. Example 2.2 (continued). We shall now try to construct, in a na¨ıve way, a timeabstracted bisimulation R for the timed automaton A from Figure 2 which is as coarse as possible. Note first that we cannot have (0 , v) R (1 , v ) for any / F . On the other hand it is easy to v, v : C → ≥0 because 1 ∈ F and 0 ∈ see that we can let (1 , v) R (1 , v ) for all v, v : C → ≥0 , which leaves us with constructing R on the states involving 0 . α We handle switch transitions − → first: If v, v : C → ≥0 are such that v(y) ≤ 2 and v (y) > 2, the state (0 , v) has an a-transition available while the state (0 , v ) has not, hence these cannot be related in R. Similarly we have to distinguish states (0 , v) from states (0 , v ) where v(x) ≤ 2 and v (x) > 2 because of b-transitions, and states (0 , v) from states (0 , v ) where v(x) < 4 and v (x) ≥ 4 because of c-transitions. Altogether this gives the five classes depicted to the left of Figure 3, where the shading indicates to which class the boundary belongs, and we have written the set of available actions in the classes.

209


y

y {b}

∅

2

2 {a, b}

{a} 2

{a, c} 4

x

2

4

x

Figure 3. Time-abstracted bisimulation classes for the two-clock timed automaton from Example 2.2. Left: equivalence classes for switch transitions only; right: equivalence classes for switch and delay transitions. δ

When also taking delay transitions − → into account, one has to partition the state space further: From a valuation v in the class marked {a, b} in the left of the figure, a valuation in the class marked {a} can only be reached by a delay transition if v(y) < v(x); likewise, from the {a} class, the {a, c} class can only be reached if v(y) ≤ v(x) − 2. Hence these two classes need to be partitioned as shown to the right of Figure 3. It can easily be shown that no further partitioning is needed, thus we have defined the coarsest time-abstracted bisimulation relation for A, altogether with eight equivalence classes. 2.3. Regions Motivated by the construction in the example above, we now introduce a timeabstracted bisimulation with a finite quotient. To ensure finiteness, we need the maximal constants which respective clocks are compared to in the invariants and guards of a given timed automaton. These may be defined as below. Definition 2.14. For a finite set C of clocks, the maximal constant mapping cmax : C → Φ(C) is defined inductively as follows: k if y = x cmax (x)(y k) = 0 if y = x cmax (x)(ϕ1 ∧ ϕ2 ) = max c(x)(ϕ1 ), c(x)(ϕ2 ) For a timed automaton A = (L, 0 , F, C, Σ, I, E), the maximal constant mapping is cA : C → defined by

ϕ,a,r cA (x) = max cmax (x)(I()), cmax (x)(ϕ) ∈ L, −−−→ ∈ E Notation 2.15. For d ∈ ≥0 we write d and d for the integral respectively fractional part of d, so that d = d + d.

210


y

2

2

4

x

Figure 4. Clock regions for the timed automaton from Example 2.2.

Definition 2.16. For a timed automaton A = (L, 0 , F, C, Σ, I, E), valuations v, v : C → ≥0 are said to be region equivalent, denoted v ∼ = v , if • v(x) = v (x) or v(x), v (x) > cA (x), for all x ∈ C, and • v(x) = 0 iff v (x) = 0, for all x ∈ C, and • v(x) ≤ v(y) iff v (x) ≤ v (y) for all x, y ∈ C. Proposition 2.17 ([4]). For a timed automaton A = (L, 0 , F, C, Σ, I, E), the relation ∼ = v is an = defined on states of A by (, v) ∼ = ( , v ) if = and v ∼ F -sensitive time-abstracted bisimulation. The quotient A∼ = is finite. The equivalence classes of valuations of A with respect to ∼ = are called regions, is called the region automaton associated with A. and the quotient A∼ = Proposition 2.18 ([8]). The number of regions for a timed automaton A with a set C of n clocks is bounded above by n! · 2n ·

(2cA (x) + 2)

x∈C

Example 2.2 (continued). The 69 regions of the timed automaton A from Figure 2 are depicted in Figure 4. Propositions 2.13 and 2.17 together now give the decidability part of the theorem below; for PSPACE-completeness see [6,37]. Theorem 2.19. The reachability problem for timed automata is PSPACE-complete. 2.4. Behavioural refinement relations We have already introduced time-abstracted simulations and bisimulations in Definition 2.11. As a corollary of Proposition 2.17, these are decidable: Theorem 2.20. Time-abstracted simulation and bisimulation are decidable for timed automata.


211

The following provides a time-sensitive variant of (bi)simulation. Definition 2.21. Let A = (L, 0 , F, C, Σ, I, E) be a timed automaton. A reflexive C relation R ⊆ L × C ≥0 × L × ≥0 is a timed simulation provided that for all (1 , v1 ) R (2 , v2 ), d

→ (1 , v1 ), d ∈ • for all (1 , v1 ) − d

≥0 ,

there exists (2 , v2 ) R (1 , v1 ) for which

→ (2 , v2 ), and (2 , v2 ) − a • for all (1 , v1 ) − → (1 , v1 ), a ∈ Σ, there exists (2 , v2 ) R (1 , v1 ) for which a (2 , v2 ) − → (2 , v2 ). R is called a timed bisimulation if it is also symmetric. Two states (1 , v1 ), (2 , v2 ) ∈ A are said to be timed bisimilar, written (1 , v1 ) ∼ (2 , v2 ), if there exists a timed bisimulation R for which (1 , v1 ) R (2 , v2 ). Note that a timed (bi)simulation on A is the same as a standard (bi)simulation on A. A A A A A Definition 2.22. Two timed automata A = (LA , A 0 , F , C , Σ , I , E ) and B = B B B B B B B (L , 0 , F , C , Σ , I , E ) are said to be timed bisimilar, denoted A ∼ B, if B (A 0 , v0 ) ∼ (0 , v0 ) in the disjoint-union transition system A B.

Timed simulation of timed automata can be analogously defined. The following decidability result was established for parallel timed processes in [36]; below we give a version of the proof which has been adapted for timed automata. Theorem 2.23. Timed simulation and bisimulation are decidable for timed automata. Before the proof, we need a few auxiliary definitions and lemmas. The first is a product of timed transition systems which synchronizes on time, but not on actions: Definition 2.24. The independent product of the timed transition systems A = A A B B B B (S A , sA ≥0 , T ), B = (S , s0 , Σ ∪ ≥0 , T ) associated with timed 0 ,Σ ∪ A B automata A, B is A × B = (S, s0 , Σ ∪ Σ ∪ ≥0 , T ) given by B s0 = (sA S = SA × SB 0 , s0 )

a a T = (p, q) − → (p , q) a ∈ Σ, p − → p ∈ T A

b b ∪ (p, q) − → (p, q ) b ∈ Σ, q − → q ∈ T B

d d d ∪ (p, q) − → (p , q ) d ∈ ≥0 , p − → p ∈ T A , q − → q ∈ T B

We need to extend region equivalence ∼ = to the independent product. Below, ⊕ denotes vector concatenation (direct sum); note that (p1 , q1 ) ∼ = (p2 , q2 ) is not the same as p1 ∼ = q1 and p2 ∼ = q2 , as fractional orderings xA xB , for xA ∈ C A , xB ∈ C B , have to be accounted for in the former, but not in the latter. Hence (p1 , q1 ) ∼ = (p2 , q2 ) implies p1 ∼ = q1 and p2 ∼ = q2 , but not vice-versa.

212


Definition 2.25. For states pi = (pi , v pi ) in A and qi = (qi , v qi ) in B for i = 1, 2, we say that (p1 , q1 ) ∼ = (p2 , q2 ) iff p1 = p2 ∧ q1 = q2 and v p1 ⊕ v q1 ∼ = v p2 ⊕ v q2 . is finite, with an upper bound Note that the number of states in A×B ∼ = : given by Proposition 2.18. Next we define transitions in A × B ∼ = Notation 2.26. Regions in A × B ∼ will be denoted X, X . The equivalence = class of a pair (p, q) ∈ A × B is denoted [p, q]. we say that Definition 2.27. For X, X ∈ A × B ∼ = a

→ X for a ∈ Σ if for all (p, q) ∈ X there exists (p , q) ∈ X such that • X− a (p, q) − → (p , q) in A × B, b

→r X for b ∈ Σ if for all (p, q) ∈ X there exists (p, q ) ∈ X such that • X− b

(p, q) − → (p, q ) in A × B, and δ

→ X if for all (p, q) ∈ X there exists d ∈ • X − d

≥0

and (p , q ) ∈ X such

→ (p , q ). that (p, q) − Definition 2.28. A subset B ⊆ A × B ∼ is a symbolic bisimulation provided = that for all X ∈ B, a a • whenever X − → X for some X ∈ A × B ∼ , then X − →r X for some = X ∈ B, a a • whenever X − →r X for some X ∈ A × B ∼ , then X − → X for some = X ∈ B, and δ • whenever X − → X for some X ∈ A × B ∼ , then X ∈ B. =

Note that it is decidable whether A × B ∼ admits a symbolic bisimula= tion. The following proposition finishes the proof of Theorem 2.23. admits a symbolic bisimulation if Proposition 2.29. The quotient A × B ∼ = and only if A ∼ B. , the set Proof (cf. [36]): For a given symbolic bisimulation B ⊆ A × B ∼ =

RB = (p, q) [p, q] ∈ B ⊆ A × B is a timed bisimulation. For the other direction, one can construct bisimulation from a timed bisimulation a symbolic

R ⊆ A × B by BR = [p, q] (p, q) ∈ R 2.5. Language inclusion and equivalence Similarly to the untimed setting, there is also a notion of language inclusion and equivalence for timed automata. We need to introduce the notion of timed trace first. Definition 2.30. A timed trace over a finite set of actions Σ is a finite sequence ((t1 , a1 ), (t2 , a2 ), . . . , (tk , ak )), where ai ∈ Σ and ti ∈ ≥0 for i = 1, . . . , k, and ti < ti+1 for i = 1, . . . , k − 1. The set of all timed traces over Σ is denoted T Σ∗ .


213

In a pair (ti , ai ), the number ti is called the time stamp of the action ai , i.e. the time at which event ai occurs. Remark 2.31. Timed traces as defined above are also known as strongly monotonic timed traces, because of the assumption that no consecutive events occur at the same time. Weakly monotonic timed traces, i.e. with requirement ti ≤ ti+1 instead of ti < ti+1 , have also been considered, and there are some subtle differences between the two; see [65] for an important example. Definition 2.32. A timed trace ((t1 , a1 ), . . . , (tk , ak )) is accepted by a timed automaton A = (L, 0 , F, C, Σ, I, E) if there is an accepting run t

a

t −t

1 1 2 1 (0 , v0 ) −→ (0 , v0 + t1 ) −→ (1 , v1 ) −− −→ ···

ak−1

tk −tk−1

a

k (k , vk ) · · · −−−→ (k−1 , vk−1 ) −−−−−→ (k−1 , vk−1 + tk − tk−1 ) −→

in A. The timed language of A is L(A) = {τ ∈ T Σ∗ | τ accepted by A}. It is clear that L(A) = ∅ if and only if none of the locations in F is reachable, hence Theorem 2.19 provides us with the decidability result in the following theorem. Undecidability of universality was established in [8]; we give an account of the proof below. Theorem 2.33. For a timed automaton A = (L, 0 , F, C, Σ, I, E), deciding whether L(A) = ∅ is PSPACE-complete. It is undecidable whether L(A) = T Σ∗ . Proof: We may show that the universality problem for a timed automata is undecidable by reduction from the Σ11 -hard problem of of deciding whether a given 2-counter machine M has a recurring computation. Let the timed language Lu be the set of timed traces encoding recurring computations of M . Observe that Lu = ∅ if and only if M does not have such a computation. We then construct a timed automaton Au which accepts the complement of Lu , i.e. L(Au ) = T Σ∗ \ Lu . Hence the language of Au is universal if and only if M does not have a recurring computation. Recall that a 2-counter, or Minsky, machine M is a finite sequence of labeled instructions {I0 , · · · , In } and counters x1 and x2 , with Ii for 0 ≤ i ≤ n − 1 on the form if xc = 0 then goto Ij Ii : xc := xc + 1; goto Ij or Ii : else xc = xc -1; goto Ik for c ∈ 1, 2, with a special In : Halt instruction which stops the computation. The language Lu is designed such that each Ii and the counters x1 and x2 are represented by actions in Σ. A correctly encoded computation is represented by a timed trace where “instruction actions” occur at discrete intervals, while the state (values of x1 and x2 ) is encoded by occurrences of “counter actions” in-between instruction actions (e.g. if xi = 5 after instruction Ij , then action xi occurs 5 times within the succeeding interval of length 1).

214


1 Ii+1

Ii 1111

2222 1

Ii+2

11111

2222

1 time

Figure 5. Timed trace encoding a increment instruction Ii+1 of a 2-counter machine.

When counters are incremented (or decremented), one more (or less) such action occurs through the next interval, and increments and decrements are always from the right. Additionally we require corresponding counter actions to occur exactly with a time difference of 1, such that if xi occurs with time stamp a then also xi occurs with time stamp a + 1, unless xi is the rightmost xi action and Ii at time stamp a is a decrement of xi . Figure 5 shows a increment of x1 (from 4 to 5) using actions 1 and 2. We obtain Au as a disjunction of timed automata A1 , . . . , Ak where each i A violates some property of a (correctly encoded) timed trace in Lu , either by accepting traces of incorrect format or inaccurate encodings of instructions. Consider the instruction: (p): x1 := x1 +1 goto (q), incrementing x1 and jumping to q. A correct encoding would be similar to the one depicted in Figure 5 where all 1’s and 2’s are matched one time unit later, but with an additional 1 action occurring. In order to accept all traces except this encoding we must consider all possible violations, i.e. • • • • •

not incrementing the counter (no change), decrementing the counter, incrementing the counter more than once, jumping to the wrong instruction, or incrementing the wrong counter,

and construct a timed automaton having exactly such traces. Figure 6 shows the timed automaton accepting traces in which instruction p yields no change of x1 . Turning our attention to timed trace inclusion and equivalence, we note the following. Proposition 2.34. Let A and B be timed automata. If A is timed simulated by B, then L(A) ⊆ L(B). If A and B are timed bisimilar, then L(A) = L(B). By a standard argument, Theorem 2.33 implies undecidability of timed trace inclusion and equivalence, a result first shown in [7]. Theorem 2.35. Timed trace inclusion and equivalence are undecidable for timed automata. There is also a notion of untimed traces for timed automata.


Σ

2

1 z := 0

Σ

1

p

215

1 z=1

Σ \ {1}

Figure 6. Timed automaton which violates the encoding of the increment instruction.

Definition 2.36. The untiming of a set of timed traces L ⊆ T Σ∗ over a finite set of actions Σ is the set U L = w = (a1 , . . . , ak ) ∈ Σ∗ ∃t1 , . . . , tk ∈

≥0

: ((t1 , a1 ), . . . , (tk , ak )) ∈ L

Hence we have a notion of the set U L(A) of untimed language of a timed automaton A. One can also define an untime operation U for timed automata, forgetting about the timing information of a timed automaton and thus converting it to a finite automaton; note however that U L(A) ⊆ L(U A) in general. Lemma 2.37 ([8]). For A a timed automaton, U L(A) = L(A∼ = ) provided that δ-transitions in A∼ are taken as silent. = As a corollary, sets of untimed traces accepted by timed automata are regular : Theorem 2.38. For a timed automaton A = (L, 0 , F, C, Σ, I, E), the set U L(A) ⊆ Σ∗ is regular. Accordingly, whether U L(A) = ∅ is decidable, and so is whether U L(A) = Σ∗ . Also untimed trace inclusion and equivalence are decidable. 2.6. Zones and difference-bound matrices As shown in the above sections, regions provide a finite and elegant abstraction of the infinite state space of timed automata, enabling us to prove decidability of reachability, timed and untimed bisimilarity, untimed language equivalence and language emptiness. Unfortunately, the number of states obtained from the region partitioning is extremely large. In particular, by Proposition 2.18 the number of regions is exponential in the number of clocks as well as in the maximal constants of the timed automaton. Efforts have been made in developing more efficient representations of the state space [56,20,25], using the notion of zones from Definition 2.5 as a coarser and more compact representation of the state space. An extended clock constraint over a finite set C may be represented using a directed weighted graph, where the nodes correspond to the elements of C k together with an extra “zero” node x0 , and an edge xi − → xj corresponds to a constraint xi − xj ≤ k (if there is more than one upper bound on xi − xj , k is the minimum of all these constraints’ right-hand sides). The extra clock x0 is fixed at value 0, so that a constraint xi ≤ k can be represented as xi − x0 ≤ k. Lower bounds on xi − xj are represented as (possibly negative) upper bounds on

216


Z=

-4

⎧ x1 ≤ 3 ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ x1 − x2 ≤ 10 ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ x1 − x2 ≥ 4

x1

3

⎪ x1 − x3 ≤ 2 ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ x3 − x2 ≤ 2 ⎪ ⎪ ⎪ ⎪ ⎩ x3 ≥ −5

10

x2

2

2 x0

x3 5

Figure 7. Graph representation of extended clock constraint.

xj − xi , and strict bounds xi − xj < k are represented by adding a flag to the corresponding edge. The weighted graph in turn may be represented by its adjacency matrix, which is known as a difference-bound matrix or DBM. The above technique has been introduced in [39]. Example 2.3. Figure 7 gives an illustration of an extended clock constraint together with its representation as a difference-bound matrix. Note that the clock constraint contains superfluous information. Zone-based reachability analysis of a timed automaton A uses symbolic states of the type (, Z), where is a location of A and Z is a zone, instead of the region-based symbolic states of Proposition 2.17. Definition 2.39. For a finite set C, Z ⊆

C ≥0 ,

and r ⊆ C, define

• the delay of Z by Z ↑ = {v + d | v ∈ Z, d ∈ ≥0 } and • the reset of Z under r by Z[r] = {v[r] | v ∈ Z}. Lemma 2.40 ([46,69]). If Z is a zone over C and r ⊆ C, then Z ↑ and Z[r] are also zones over C. Extended clock constraints representing Z ↑ and Z[r] may be computed efficiently (i.e. in time cubic in the number of clocks in C) by representing the zone Z in a canonical form obtained by computing the shortest-path closure of the directed graph representation of Z, see [54]. Example 2.3 (continued). Figure 8 shows two canonical representations of the difference-bound matrix for the zone Z of Figure 7. The left part illustrates the shortest-path closure of Z; on the right is the shortest-path reduction [54] of Z, essentially obtained by removing redundant edges from the shortest-path closure. The latter is useful for checking zone inclusion, see below. The zone automaton associated with a timed automaton is similar to the region automaton of Proposition 2.17, but uses zones for symbolic states instead of regions:

217


-4 x1

3 3 x0

-4 x2

4

x1

x2

-1

-2 2

7

1 5

-2 2 x3

3 3

2

2

x0

x3

Figure 8. Canonical representations. Left: shortest-path closure; right: shortest-path reduction.

Definition 2.41. The zone automaton associated with a timed automaton A = (L, 0 , F, C, Σ, I, E) is the transition system AZ = (S, s0 , Σ ∪ {δ}, T ) given by

S = (, Z) ∈ L, Z ⊆ C s0 = 0 , v0 ≥0 zone δ T = (, Z) , Z ↑ ∧ I() ϕ,a,r

a ∪ (, Z) , (Z ∧ ϕ)[r] ∧ I( ) −−−→ ∈ E The analogue of Proposition 2.13 for zone automata is as follows: Proposition 2.42 ([69]). A state (, v) in a timed automaton A = (L, 0 , F, C, Σ, I, E) is reachable if and only if there is a zone Z ⊆ C ≥0 for which v ∈ Z and such that (, Z) is reachable in AZ . The zone automaton associated with a given timed automaton is infinite and hence unsuitable for reachability analysis. Finiteness can be enforced by employing normalization, using the fact that region equivalence ∼ = has finitely many equivalence classes: Definition 2.43. For a timed automaton A and a zone Z ⊆ of Z is the set {v : C → ≥0 | ∃v ∈ D : v ∼ = v }

C ≥0 ,

the normalization

The normalized zone automaton is defined in analogy to the zone automaton from above, and the analogue of Proposition 2.42 holds for the normalized zone automaton. Hence we can obtain a reachability algorithm by applying any search strategy (depth-first, breadth-first, or another) on the normalized zone automaton. Remark 2.44. For timed automata on extended clock constraints, i.e. with diagonal constraints permitted, it can be shown [27,24] that normalization as defined above does not give rise to a sound and complete characterization of reachability. Instead, one can apply a refined normalization which depends on the difference constraints used in the timed automaton, see [24]. In addition to the efficient computation of symbolic successor states according to the relation, termination of reachability analysis requires that we can

218


efficiently recognize whether the search algorithm has encountered a given symbolic state. Here it is crucial that there is an efficient way of deciding inclusion Z1 ⊆ Z2 between zones. Both the shortest-path-closure canonical form as well as the more space-economical shortest-path-reduced canonical form [54], cf. Example 2.3, allow for efficient inclusion checking. In analogy to difference-bound matrices and overcoming some of their problems, another data structure of clock difference diagram (CDD) has been proposed [56]. However, the design of efficient algorithms for delay and reset operations is a challenging open problem; generally, the design of efficient data structures for computations with (unions of) zones is a field of active research, see [3,64,11] for some examples.

3. Weighted timed automata The notion of weighted — or priced — timed automata was introduced independently, at the very same conference, by Behrmann et.al. [18] and Alur et.al. [9]. In these models both edges and locations can be decorated with weights, or prices, giving the cost of taking an action transition or the cost per time unit of delaying in a given location. The total cost of a trace is then simply the accumulated (or total) weight of its discrete and delay transitions. As a first result, the above two papers independently, and with quite different methods, showed that the problem of cost-optimal reachability is computable for weighted timed automata. Later, optimal reachability for timed automata with several weight functions was considered in [59] as well as optimal infinite runs in [41,29]. Definition 3.1. A weighted timed automaton is a tuple A = (L, 0 , F, C, Σ, I, E, R, P ), where (L, 0 , F, C, Σ, I, E) is a timed automaton, R : L → a location weight-rate mapping, and P : E → an edge weight mapping. The semantics of A is the weighted transition system A = (S, s0 , Σ ∪ ≥0 , T, w), where (S, s0 , Σ ∪ ≥0 , T ) is the semantics of the underlying timed automaton (L, 0 , F, C, Σ, I, E), and the transition weights w : T → are given as follows: d → (, v + d) = d R() w (, v) − ϕ,a,r a → ( , v ) = P −−−→ w (, v) −

with v |= ϕ, v = v[r] e

→ to illustrate an We shall denote weighted edges and transitions by symbols − w edge or a transition labeled e with weight w. 3.1. Optimal reachability The objective of optimal reachability analysis is to find runs to a final location with the lowest total weight as defined below.

219


y≤4 1

a

x := 0 P =1

R=4

x≤2∧y ≥3 2

c

P =4

R=2

x := 0

3

y≤4

b

Figure 9. A weighted timed automaton with two clocks.

Example 3.1. Figure 9 shows a simple weighted timed automaton with final location 3 . Below we give a few examples of accepting runs, where we identify valuations v : {x, y} → ≥0 with their values (v(x), v(y)). The total weights of the runs given here are 17 and 11. 3

a

c

12

1

4

(1 , 0, 0) −→ (1 , 3, 3) − → (2 , 0, 3) − → (3 , 0, 3) a

3

b

c

1

6

0

4

→ (2 , 0, 0) − → (2 , 3, 3) − → (2 , 0, 3) − → (3 , 0, 3) (1 , 0, 0) − −→ s1 −−→ · · · −−→ sk in a Definition 3.2. The total weight of a finite k run π = s0 − w1 w2 wk weighted transition system is w(π) = i=1 wk . We are now in a position to state the problem with which we are concerned here: We want to find accepting runs with minimum total weight in a weighted timed automaton A. However due to the possible use of strict clock constraints on edges and in locations of A, the minimum total weight might not be realizable, i.e. there might be no run which achieves it. For this reason, one also needs to consider (infinite) sets of runs and the infimum of their members’ total weights: Problem 3.1 (Optimal reachability). Given a weighted timed automaton A, com pute W = inf w(π) π accepting run in A and a set P of accepting runs for which inf π∈P w(π) = W . The key ingredient in the proof of the following theorem is the introduction of weighted regions in [18]. A weighted region is a region as of Definition 2.16 enriched with an affine cost function describing in a finite manner the cost of reaching any point within it. This notion allows to define the weighted region automaton associated with a weighted timed automaton, and one can then show that optimal reachability can be computed in the weighted region automaton. Theorem 3.3 ([18]). The optimal reachability problem is computable for weighted timed automata with non-negative weights. Similar to the notion of regions for timed automata, the number of weighted regions is exponential in the number of clocks as well as in the maximal constants of the timed automaton. Hence a notion of weighted zone — a zone extended with

220


1 R = (1, 4)

y := 0

a

x≤2

x≥2∧y ≥1

2 R = (2, 1)

y := 0

x≤3 y≤2

b

3

Figure 10. A doubly weighted timed automaton with two clocks.

an affine cost function — was introduced [53] together with an efficient, symbolic A∗ -algorithm for searching for cost-optimal tracing using branch-and-bound techniques. In particular, efficient means of generalizing the notion of symbolic successor to incorporate the affine cost functions were given. During the symbolic exploration, several small linear-programming problems in terms of determining the minimal value of the cost function over the given zone have to be dealt with. Given that the constraints of these problems are simple difference constraints, it turns out that substantial gain in performance may be achieved by solving the dual problem of minimum-cost flow [67]. The newly emerged branch UppAal Cora provides an efficient tool for cost-optimal reachability analysis, applying the above data structures and algorithms and allowing the user to guide and heuristically prune the search. 3.2. Multi-weighted timed automata Definition 3.4. An doubly weighted timed automaton is a tuple A = (L, 0 , F, C, Σ, I, E, R, P ) where (L, 0 , F, C, Σ, I, E) is a timed automaton, R : L → rate mapping, and P : E → 2 an edge weight mapping.

2

a location weight-

The semantics of a doubly weighted timed automaton is a doubly weighted transition system defined similarly to Definition 3.1, and the total weight of finite paths is defined accordingly as a pair; we shall refer to the total weights as w1 and w2 respectively. These definitions have natural generalizations to multi-weighted timed automata with more than two weight coordinates. The objective of conditional reachability analysis is to find runs to a final location with the lowest total weight in the first weight coordinate while satisfying a constraint on the other weight coordinate. Example 3.2. Figure 10 depicts a simple doubly weighted timed automaton with final location 3 . Under the constraint w2 ≤ 3, the optimal run of the automaton can be seen to be 1/3

5/3

a

b

(1 , 0, 0) −− −→ (1 , 1/3, 1/3) − → (2 , 1/3, 0) −− −−→ (2 , 2, 5/3) − → (3 , 2, 0) 1 4 10 5 (3,3)

with total weight

11 3

(

3

,3)

,3 .

The precise formulation of the conditional optimal reachability problem is as follows, where we again need to refer to (possibly infinite) sets of runs:

221


x=3 H R=2 x≤3

x := 0

d y≥2 a

x, y := 0

x=3 M R=5 x≤3

P =2

L R=9

d y≥2

x, y := 0

a

P =1

Figure 11. A weighted timed automaton modelling a simple production system.

Problem 3.2 (Conditional optimal reachability). Given a doubly weighted timed automaton A and M ∈ , compute W = inf w1 (π) π accepting run in A, w2 (π) ≤ M } and a set P of accepting runs such that w2 (π) ≤ M for all π ∈ P and inf π∈P w(π) = W . Theorem 3.5 ([58,59]). The conditional optimal reachability problem is computable for doubly weighted timed automata with non-negative weights and without weights on edges. The proof of the above theorem rests on a direct generalization of weighted to doubly-weighted zones. An extension can be found in [59], where it is shown that also the Pareto frontier, i.e. the set of cost vectors which cannot be improved in any cost variable, can be computed. 3.3. Optimal infinite runs In this section we shall be concerned with computing optimal infinite runs in (doubly) weighted timed automata. We shall treat both the limit ratio viewpoint discussed in [29] and the discounting approach of [41]. Example 3.3. Figure 11 shows a simple production system modelled as a weighted timed automaton. The system has three modes of production, High, Medium, and Low. The weights model the cost of production, so that the High production mode has a low cost, which is preferable to the high cost of the Low production mode. After operating in a High or Medium production mode for three time units, production automatically degrades (action d) to a lower mode. When in Medium or Low production mode, the system can be attended to (action a), which advances it to a higher mode. The objective of optimal-ratio analysis is to find an infinite run in a doubly weighted timed automaton which minimizes the ratio between the two total weights. This will be formalized below. w

w

w

z1

z2

zk

1 2 k Definition 3.6. The total ratio of a finite path π = s0 −−→ s1 −−→ · · · −−→ sk in a

doubly weighted transition system is k wk Γ(π) = i=1 k i=1 zk

222

U. Fahrenberg et al. / Verification, Performance Analysis and Controller Synthesis w

w

z1

z2

1 2 The total ratio of an infinite path π = s0 −−→ s1 −−→ · · · is

Γ(π) = lim inf Γ(s0 → · · · → sk ) k→∞

A special case of optimal-ratio analysis is given by weight-per-time models, where the interest is in minimizing total weight per accumulated time. The example provided in this section is a case of this. In the setting of optimal-ration analysis, these can be modelled as doubly weighted timed automata with R2 () = 1 and P2 (e) = 0 for all locations and edges e. Example 3.3 (continued). In the timed automaton of Figure 11, the following cyclic behaviour provides an infinite run π: 3

d

3

1

d

→ (H, 3, 3) − → (M, 0, 3) − → (M, 3, 6) − → (L, 3, 6) − → (H, 0, 0) − a

3

a

→ (M, 0, 0) − → (M, 3, 3) − → (H, 0, 0) − → ··· (L, 4, 7) − Taking the weight-per-time viewpoint, the total ratio of π is Γ(π) = 4.8. Problem 3.3 (Minimum infinite ratio). Given a doubly

weighted timed automaton A, compute W = inf Γ(π) π infinite run in A and a set P of infinite runs for which inf π∈P Γ(π) = W . The main tool in the proof of the following theorem is the introduction of the corner-point abstraction of a timed automaton in [29]. This is a finite refinement of the region automaton of Definition 2.16 in which one also keeps track of the corner points of regions. One can then show that any infinite run with minimum ratio must pass through corner points of regions, hence these can be found in the corner-point abstraction by an algorithm first proposed in [51]. The technical condition in the theorem that the second weight coordinate be strongly diverging means that any infinite run π in the closure of the timed automaton in question satisfy w2 (π) = ∞, see [29] for details. Theorem 3.7 ([29]). The minimum infinite ratio problem is computable for doubly weighted timed automata with non-negative and strongly diverging second weight coordinate. For discount-optimal analysis, the objective is to find an infinite run in a weighted timed automaton which minimizes the discounted total weight as defined below. The point of discounting is that the weight of actions is discounted with time, so that the impact of an event decreases, the further in the future it takes place. In the definition below, ε is the empty run, and (, v) → π denotes the concatenation of the transition (, v) → with the run π. Definition 3.8. The discounted total weight of finite runs in a weighted timed automaton under discounting factor λ ∈ [0, 1[ is given inductively by


223

wλ (ε) = 0 a wλ (, v) − → π = P + wλ (π)

P

d wλ (, v) − → π = R()

d

λτ dτ + λd wλ (π)

0 d

a1

1 The discounted total weight of an infinite run π = (0 , v0 ) −→ (0 , v0 + d1 ) −→ P1 (1 , v1 ) − → · · · is

ak → · · · −−→ (k , vk ) wλ (π) = lim wλ (0 , v0 ) − k→∞

Pk

provided that the limit exists. Example 3.3 (continued). The discounted total weight of the infinite run π in timed automaton of Figure 11 satisfies the following equality, where It = the t τ λ dτ = − ln1λ (1 − λt ): 0 wλ (π) = 2I3 + λ3 (5I3 + λ3 (9I1 + λ(1 + 5I3 + λ3 (2 + wλ (π))))) With a discounting factor of λ = .9 for example, the discounted total weight of π would hence be wλ (π) ≈ 40.5. Problem 3.4 (Minimum discounted weight). Given a weighted timed automaton

A and λ ∈ [0, 1[, compute W = inf wλ (π) π infinite run in A and a set P of infinite runs for which inf π∈P wλ (π) = W . The proof of the following theorem rests again on the corner-point abstraction, and on a result in [10]. The technical condition that the timed automaton be time-divergent is analogous to the condition on the second weight coordinate in Theorem 3.7. Theorem 3.9 ([41]). The minimum discounted weight problem is computable for time-divergent weighted timed automata with non-negative weights and rational λ.

4. Timed games Recently, substantial effort has been made towards the synthesis of winning strategies for timed games with respect to safety and reachability control objectives. From known region-based decidability results, efficient on-the-fly algorithms have been developed [68,34] and implemented in the newest branch UppAal Tiga. For timed games, as for untimed ones, transitions are either controllable or uncontrollable (i.e. under the control of an environment), and the problem is to synthesize a strategy for when to take which (enabled) controllable transitions in order that a given objective is guaranteed regardless of the behaviour of the environment.

224


1

x > 1 u1

x= j (length pat)) j ≥ |pat| (char pat (+ j 1)) pat[j + 1] (xmatch pat j txt i) xmatch(pat, j, txt, i) In ACL2, strings are indexed from 0. So the character at (char pat ((length pat) 1)) is the last character in pat, provided pat is non-empty. The ACL2 expression

J.S. Moore and M. Martinez / Correctness of the Boyer-Moore Fast String Searching Algorithm

271

(cond ((not (natp i)) nil) ((>= i (length txt)) nil) ((xmatch pat 0 txt i) i) (t (correct-loop pat txt (+ 1 i))))

may be read as If i is not a natural number, then nil, else if i ≥ |txt|, then nil, else if xmatch(pat, 0, txt, i), then i, else correct−loop(pat, txt, 1 + i). 1.1. A Correct Algorithm Below we define three functions, xmatch, correct-loop, and correct. The last is our “obviously correct” algorithm: (correct pat txt) returns the index in the string txt at which we find the left-most exact match of the string pat, or else nil if no such exact match exists in txt. The function “works” by checking, for each successive legal index into txt starting from 0, whether there is an exact match of pat starting at that index. (defun xmatch (pat j txt i) (declare (xargs :measure (nfix (- (length pat) j)))) (cond ((not (natp j)) nil) ((>= j (length pat)) t) ((>= i (length txt)) nil) ((equal (char pat j) (char txt i)) (xmatch pat (+ 1 j) txt (+ 1 i))) (t nil))) (defun correct-loop (pat txt i) (declare (xargs :measure (nfix (- (length txt) i)))) (cond ((not (natp i)) nil) ((>= i (length txt)) nil) ((xmatch pat 0 txt i) i) (t (correct-loop pat txt (+ 1 i))))) (defun correct (pat txt) (correct-loop pat txt 0))

The top-level function correct takes two arguments, pat and txt (which will be strings), and calls its “subroutine” correct-loop on them, initializing the local i of correct-loop to 0. Think of correct-loop as a while loop. For each legal index into txt it checks whether there is an exact match of pat (starting at index 0) with txt (starting at i). If so, it returns i. If not, it iterates (recurs), incrementing i by 1. The function xmatch checks for an exact match between the characters of pat (starting at j) with the corresponding characters of txt (starting at i). It terminates with t if pat is exhausted first and terminates with nil if txt is exhausted first or if unequal characters are found.

272


The declare forms above supply ACL2 with a measure of the arguments that ACL2 uses in the termination proofs for these recursive definitions. The tests that i and j are natural numbers are necessitated by ACL2’s requirement that functions are total (defined on all inputs). Henceforth, we will omit such details from this paper and refer the reader to the proof script. We take it as obvious that correct returns the smallest index into txt at which an exact match of pat occurs. This can be formalized: xmatch insures that corresponding characters are equal; if correct returns nil, there is no exact match; and if correct returns non-nil, there is an exact match at the indicated index and there is no earlier match. The formal statements of these properties can and have been proved. But we believe the definitions above are as clear as the formalized versions of these remarks. We use correct as the specification of the fast string searching algorithm. 1.2. The Fast Algorithm The top-level function for the fast algorithm is defined as follows. (defun fast (pat txt) (if (equal pat "") (if (equal txt "") nil 0) (fast-loop pat (- (length pat) 1) txt (- (length pat) 1))))

The initial case analysis is required because the main loop of the fast algorithm requires that pat be non-empty. That loop is formalized by fast-loop which takes pat, an index j into pat, txt, and the index i into txt. Index i corresponds to the arrows (“⇑”) in our diagrams – the place in txt at which we will read – and index j points to the corresponding place in pat. We call these the focus locations. The difference between i and j indicates the current alignment, the location in txt corresponding to the 0th character of pat. Fast enters the loop with pat aligned with the 0th character of txt and the focus on the last character of pat. (defun fast-loop (pat j txt i) (cond ((< j 0) (+ 1 i)) ((= i (len txt~)) nil) ((equal (firstn (len pat~) (nthcdr i txt~)) pat~) i)

; (*5)


281

(t (correct-loop~ pat~ txt~ (+ 1 i))))) (defthm correct-loop-trade (implies (and (stringp pat) (stringp txt)) (equal (correct-loop pat txt i) (correct-loop~ (coerce pat ’list) (coerce txt ’list) i))))

; (*6)

(defun clear (pat~ txt~ k n) (declare (xargs :measure (nfix n))) (cond ((zp n) t) ((equal (firstn (len pat~) (nthcdr k txt~)) pat~) nil) (t (clear pat~ txt~ (+ k 1) (- n 1)))))

; (*7)

(defthm clear-implies-skip (implies (and (natp k) (< k (len txt~)) (natp n) (clear pat~ txt~ k n)) (equal (correct-loop~ pat~ txt~ (+ k n)) (correct-loop~ pat~ txt~ k))) :rule-classes nil)

; (*8)

Lemma (*8), above, is not stored as a rewrite rule (note :rule-classes above) because ACL2 cannot “see” how to use it automatically. In the proof of (*4) below, we supply a hint that instantiates (*8) as required. Lemma (*9), below, is the other half of our decomposition of (*4). As noted the firstn expression yields the list representation of the discovered text dt~. Technically, it is the character just read from txt at i consed onto tail of pat starting at j+1. But that direct formulation of dt~ (a) hides its relation to txt and (b) makes it a function of j. But to prove (*9) we induct on j and the induction requires that the “dt~” in the induction hypothesis be the same “dt~” in the induction conclusion. (*9) is thus a generalization of the theorem we need because it deals with an arbitrary substring of txt of length d. This introduction of d and the separation of dt~ from pat makes (*9) not useful as a rewrite rule in the proof of (*4) and so in that proof we have to provide a hint as to how to use (*9). (defthm clear-x (implies (and (true-listp pat~) (true-listp txt~) (consp pat~) (natp i) (natp d) (

Engineering Methods and Tools for Software Safety and Security - Volume 22 NATO Science for Peace and Security Series - D: Information and Communication Security

Quantum Communication and Security (NATO Science for Peace and Security Series: Information and Communication Security) (NATO Security Through Science Series. D: Information and Com)

Combinatorial Optimization: Methods and Applications: Volume 31 NATO Science for Peace and Security Series - D: Information and Communication Security

Environmental Security and Public Safety (NATO Science for Peace and Security Series C: Environmental Security)

Information Assurance and Computer Security, Volume 6 NATO Security through Science Series: Information and Communication Security (Nato Security Through Science)

Language Engineering for Lesser-Studied Languages - Volume 21 NATO Science for Peace and Security Series - D: Information and Communication Security (Nato ... and Communications Security- Vol. 20)

Complexity and Security (Nato Science for Peace and Series) (Nato Science for Peace and Series)

Security and Embedded Systems: Volume 2 NATO Security through Science Series: Information and Communication Security (Nato Security Through Science)

Energy and Environmental Challenges to Security (NATO Science for Peace and Security Series C: Environmental Security)

Nanotechnology - Toxicological Issues and Environmental Safety (NATO Science for Peace and Security Series C: Environmental Security)

Mini-Micro Fuel Cells: Fundamentals and Applications (NATO Science for Peace and Security Series C: Environmental Security) (NATO Science for Peace and Security Series C: Environmental Security)

Nuclear Power and Energy Security (NATO Science for Peace and Security Series B: Physics and Biophysics)

Building and Using Datasets on Armed Conflicts (Nato Science for Peace and Security) (Nato Science for Peace and Security)

Energy Options Impact on Regional Security (NATO Science for Peace and Security Series C: Environmental Security)

Geographic Uncertainty in Environmental Security (NATO Science for Peace and Security Series C: Environmental Security)

Boolean Functions in Cryptology and Information Security (Nato Science for Peace and Security)

Advances and Challenges in Multisensor Data and Information Processing - Volume 8 NATO Security through Science Series: Information and Communication Security ... D: Sinformation and Communication Security)

Nanomaterials: Risks and Benefits (NATO Science for Peace and Security Series C: Environmental Security)

Virus Diseases and Crop Biosecurity (NATO Science for Peace and Security Series C: Environmental Security)

Nanomaterials: Risks and Benefits (NATO Science for Peace and Security Series C: Environmental Security)

Smart Materials for Energy Communications and Security NATO Science for Peace and Security Seri

Increasing Seismic Safety by Combining Engineering Technologies and Seismological Data (NATO Science for Peace and Security Series C: Environmental Security)

Stem Cells and Their Potential for Clinical Application (NATO Science for Peace and Security Series NATO Science for Peace and Security Series A: Chemistry and Biology)

Security and Reliability of Damaged Structures and Defective Materials (NATO Science for Peace and Security Series C: Environmental Security)

Hypermedia Seduction for Terrorist Recruiting - Volume 25 NATO Science for Peace and Security Series: Human and Societal Dynamics (Nato Science for Peace and Security)

Role Engineering for Enterprise Security Management (Information Security and Privacy)

Problems of High Altitude Medicine and Biology (NATO Science for Peace and Security Series NATO Science for Peace and Security Series A: Chemistry and Biology)

Imaging for Detection and Identification (NATO Science for Peace and Security Series B: Physics and Biophysics)

Nuclear Doctrines and Strategies (Nato Sciences for Peace and Security)

Environmental Security and Environmental Management: The Role of Risk Assessment (NATO Science for Peace and Security Series C: Environmental Security)

Wastewater Reuse - Risk Assessment, Decision-Making and Environmental Security (NATO Science for Peace and Security Series C: Environmental Security)

Engineering Methods and Tools for Software Safety and Security - Volume 22 NATO Science for Peace and Security Series - D: Information and Communication Security

Quantum Communication and Security (NATO Science for Peace and Security Series: Information and Communication Security) (NATO Security Through Science Series. D: Information and Com)

Combinatorial Optimization: Methods and Applications: Volume 31 NATO Science for Peace and Security Series - D: Information and Communication Security

Environmental Security and Public Safety (NATO Science for Peace and Security Series C: Environmental Security)

Information Assurance and Computer Security, Volume 6 NATO Security through Science Series: Information and Communication Security (Nato Security Through Science)

Language Engineering for Lesser-Studied Languages - Volume 21 NATO Science for Peace and Security Series - D: Information and Communication Security (Nato ... and Communications Security- Vol. 20)

Complexity and Security (Nato Science for Peace and Series) (Nato Science for Peace and Series)

Security and Embedded Systems: Volume 2 NATO Security through Science Series: Information and Communication Security (Nato Security Through Science)

Energy and Environmental Challenges to Security (NATO Science for Peace and Security Series C: Environmental Security)

Nanotechnology - Toxicological Issues and Environmental Safety (NATO Science for Peace and Security Series C: Environmental Security)

Mini-Micro Fuel Cells: Fundamentals and Applications (NATO Science for Peace and Security Series C: Environmental Security) (NATO Science for Peace and Security Series C: Environmental Security)

Nuclear Power and Energy Security (NATO Science for Peace and Security Series B: Physics and Biophysics)

Building and Using Datasets on Armed Conflicts (Nato Science for Peace and Security) (Nato Science for Peace and Security)

Energy Options Impact on Regional Security (NATO Science for Peace and Security Series C: Environmental Security)

Geographic Uncertainty in Environmental Security (NATO Science for Peace and Security Series C: Environmental Security)

Boolean Functions in Cryptology and Information Security (Nato Science for Peace and Security)

Advances and Challenges in Multisensor Data and Information Processing - Volume 8 NATO Security through Science Series: Information and Communication Security ... D: Sinformation and Communication Security)

Nanomaterials: Risks and Benefits (NATO Science for Peace and Security Series C: Environmental Security)

Virus Diseases and Crop Biosecurity (NATO Science for Peace and Security Series C: Environmental Security)

Nanomaterials: Risks and Benefits (NATO Science for Peace and Security Series C: Environmental Security)

Smart Materials for Energy Communications and Security NATO Science for Peace and Security Seri

Increasing Seismic Safety by Combining Engineering Technologies and Seismological Data (NATO Science for Peace and Security Series C: Environmental Security)

Stem Cells and Their Potential for Clinical Application (NATO Science for Peace and Security Series NATO Science for Peace and Security Series A: Chemistry and Biology)

Security and Reliability of Damaged Structures and Defective Materials (NATO Science for Peace and Security Series C: Environmental Security)

Hypermedia Seduction for Terrorist Recruiting - Volume 25 NATO Science for Peace and Security Series: Human and Societal Dynamics (Nato Science for Peace and Security)

Role Engineering for Enterprise Security Management (Information Security and Privacy)

Problems of High Altitude Medicine and Biology (NATO Science for Peace and Security Series NATO Science for Peace and Security Series A: Chemistry and Biology)

Imaging for Detection and Identification (NATO Science for Peace and Security Series B: Physics and Biophysics)

Nuclear Doctrines and Strategies (Nato Sciences for Peace and Security)

Environmental Security and Environmental Management: The Role of Risk Assessment (NATO Science for Peace and Security Series C: Environmental Security)

Wastewater Reuse - Risk Assessment, Decision-Making and Environmental Security (NATO Science for Peace and Security Series C: Environmental Security)

Recommend Documents