Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen
2529
3
Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo
Doron A. Peled Moshe Y. Vardi (Eds.)
Formal Techniques for Networked and Distributed Sytems – FORTE 2002 22nd IFIP WG 6.1 International Conference Houston, Texas, USA, November 11-14, 2002 Proceedings
13
Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Doron A. Peled University of Warwick, Department of Computer Science Coventry, CV4 7AL, United Kingdom E-mail:
[email protected] Moshe Y. Vardi Rice University, Department of Computer Science 6100 S. Main St., Houston, TX 77005, USA E-mail:
[email protected] Cataloging-in-Publication Data applied for Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliographie; detailed bibliographic data is available in the Internet at .
CR Subject Classification (1998): C.2.4, D.2.2, C.2, D.2.4, D.2.5, D.2, F.3.1, D.4 ISSN 0302-9743 ISBN 3-540-00141-7 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de ©2002 IFIP International Federation for Information Processing, Hofstrasse 3, A-2361 Laxenburg, Austria Printed in Germany Typesetting: Camera-ready by author, data conversion by PTP-Berlin, Stefan Sossna e.K. Printed on acid-free paper SPIN: 10873162 06/3142 543210
Preface
The IFIP TC6 WG 6.1 Joint International Conference on Formal Techniques for Networked and Distributed Systems, FORTE 2002, was held this year at Rice University, Houston, Texas, on November 11–14. This annual conference provides a forum for researchers and practitioners from universities and industry to meet and advance technologies in areas of specification, testing, and verification of distributed systems and communication protocols. The main topics are: – – – – – – – – – – – – –
FDT-based system and protocol engineering. Semantical foundations. Extensions of FDTs. Formal approaches to concurrent/distributed object-oriented systems. Real-time and probability aspects. Performance modeling and analysis. Quality of service modeling and analysis. Verification and validation. Relations between informal and formal specification. FDT-based protocol implementation. Software tools and support environments. FDT application to distributed systems. Protocol testing, including conformance testing, interoperability testing, and performance testing. – Test generation, selection, and coverage. – Practical experience and case studies. – Corporate strategic and financial consequences of using formal methods. A total of 61 papers were submitted to FORTE 2002, and reviewed by members of the program committee and additional reviewers. The program committee selected 22 regular papers, two tool papers, and two posters for presentation at the conference. The program also included three tutorials and five invited talks. FORTE 2002 would like to gratefully acknowledge the financial support received from HP, OFFIS, Microsoft Research, and Verisity. FORTE 2002 could not take place without the effort of the PC members, reviewers, and people participating in the local organization. The editors wish to thank all of them. Doron A. Peled Moshe Y. Vardi
Organization
FORTE 2002 was organized by the Department of Computer Science, Rice University, Houston, Texas.
Executive Committee Program Chairs: Doron A. Peled (University of Warwick, UK) and Moshe Y. Vardi (Rice University) Program Committee: R. Alur D. Bjorner G. v. Bochmann T. Bolognesi E. Brinksma A. Cavalli S.T. Chanson P. Dembinski H. Garavel S. Gnesi G.J. Holzmann A. Hu C. Jard G. Leduc D. Lee I. Lee S. Leue L. Logrippo S. Mauw K. McMillan M. Morley A. Muscholl E. Najm D. Peled A. Petrenko S. Smolka R. Tenney K.J. Turner S.T. Vuong M.Y. Vardi M. Yannakakis
Univ. Pennsylvania, USA Tech. Univ. Denmark Univ. of Ottawa, Canada IEI, Italy Univ. of Twente, The Netherlands INT, France Hong Kong Univ. IPI-PAN Inria, France CNR–IEI, Italy Bell Labs, USA UBC Canada IRISA–CNRS, France Univ. of Liege, Belgium Bell Labs, China Univ. Pennsylvania, USA Univ. of Freiburg, Germany Univ. of Ottawa, Canada Eindhoven, The Netherlands Cadence Verisity Univ. Paris 7, France ENST, France Univ. of Warwick, UK CRIM, Canada Stony Brook, USA Univ. of Massachusetts, USA Univ. of Stirling, UK Univ. of British Columbia, Canada Rice University, USA Avaya Labs
VIII
Organization
Steering Committee: G. v. Bochmann E. Brinksma S. Budkowski G. Leduc E. Najm R. Tenney K.J. Turner
Univ. of Ottawa Univ. of Twente INT, France Univ. of Liege ENST, France Univ. of Massachusetts Univ. of Stirling
Table of Contents
Encoding PAMR into (Timed) EFSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manuel N´ un ˜ez, Ismael Rodr´ıguez
1
Submodule Construction for Specifications with Input Assumptions and Output Guarantees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Gregor v. Bochmann Congruent Weak Conformance, a Partial Order among Processes . . . . . . . . . 34 Ronald W. Brower, Kenneth S. Stevens Symmetric Symbolic Safety-Analysis of Concurrent Software with Pointer Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Farn Wang, Karsten Schmidt A Nested Depth First Search Algorithm for Model Checking with Symmetry Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Dragan Boˇsnaˇcki Protocol Techniques for Testing Radiotherapy Accelerators . . . . . . . . . . . . . . 81 Kenneth J. Turner, Qian Bing System Test Synthesis from UML Models of Distributed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Simon Pickin, Claude Jard, Yves Le Traon, Thierry J´eron, Jean-Marc J´ez´equel, Alain Le Guennec Formal Test Purposes and the Validity of Test Cases . . . . . . . . . . . . . . . . . . . 114 Peter H. Deussen, Stephan Tobies Use of Logic to Describe Enhanced Communications Services . . . . . . . . . . . . 130 Stephan Reiff-Marganiec, Kenneth J. Turner A Formal Venture into Reliable Multicast Territory . . . . . . . . . . . . . . . . . . . . 146 Carolos Livadas, Nancy A. Lynch Modelling SIP Services Using Cress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Kenneth J. Turner Verifying Reliable Data Transmission over UMTS Radio Interface with High Level Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Teemu Tynj¨ al¨ a, Sari Lepp¨ anen, Vesa Luukkala Verifying Randomized Byzantine Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Marta Kwiatkowska, Gethin Norman
X
Table of Contents
Automatic SAT-Compilation of Protocol Insecurity Problems via Reduction to Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Alessandro Armando, Luca Compagna Visual Specifications for Modular Reasoning about Asynchronous Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Nina Amla, E. Allen Emerson, Kedar S. Namjoshi, Richard J. Trefler Bounded Model Checking for Timed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 243 G. Audemard, A. Cimatti, A. Kornilowicz, R. Sebastiani C Wolf – A Toolset for Extracting Models from C Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Daniel C. DuVarney, S. Purushothaman Iyer NTIF: A General Symbolic Model for Communicating Sequential Processes with Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Hubert Garavel, Fr´ed´eric Lang Building Tools for LOTOS Symbolic Semantics in Maude . . . . . . . . . . . . . . . 292 Alberto Verdejo From States to Transitions: Improving Translation of LTL Formulae to B¨ uchi Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Dimitra Giannakopoulou, Flavio Lerda A Compositional Sweep-Line State Space Exploration Method . . . . . . . . . . . 327 Lars Michael Kristensen, Thomas Mailund On Combining the Persistent Sets Method with the Covering Steps Graph Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Pierre-Olivier Ribet, Fran¸cois Vernadat, Bernard Berthomieu Innovative Verification Techniques Used in the Implementation of a Third-Generation 1.1GHz 64b Microprocessor . . . . . . . . . . . . . . . . . . . . . 360 Victor Melamed, Harry Stuimer, David Wilkins, Lawrence Chang, Kevin Normoyle, Sutikshan Bhutani Mechanical Translation of I/O Automaton Specifications into First-Order Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Andrej Bogdanov, Stephen J. Garland, Nancy A. Lynch Verification of Event-Based Synchronization of SpecC Description Using Difference Decision Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Thanyapat Sakunkonchak, Masahiro Fujita
Table of Contents
XI
A Distributed Partial Order Reduction Algorithm . . . . . . . . . . . . . . . . . . . . . . 370 Robert Palmer, Ganesh Gopalakrishnan
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Encoding PAMR into (Timed) EFSMs Manuel N´ un ˜ez and Ismael Rodr´ıguez Dept. Sistemas Inform´ aticos y Programaci´ on Universidad Complutense de Madrid, E-28040 Madrid. Spain. {mn,isrodrig}@sip.ucm.es
Abstract. In this paper we show how the formal framework introduced in PAMR (Process Algebra for the Management of Resources) can be included into a notion of Extended Finite State Machines (in short EFSM). First, we give the definition of process. Following the lines of PAMR, a process consists not only of information about its behavior but also of information about the preference for resources. This information will be encoded into a model based on EFSMs. In contrast with the original definition of PAMR, a notion of time is included in our processes, that is, transitions take time to be performed. Systems are defined as the composition of several processes. We present different implementation relations, depending on the interpretation of time, and we relate them. Finally, we study how tests cases are defined and applied to implementations.
1
Introduction
There exists a growing interest in including microeconomic concepts into different areas of computer science. For example, several systems related to ecommerce use a notion of preference or, equivalently, utility function (see e.g. [23,3,8]). These notions have been also considered in the field of networks to define algorithms dealing with resource allocation (e.g. [17,27,12]). However, most of these works are restricted to solve a concrete problem, that is, they do not provide a general framework to be applied to different fields. PAMR [19] is a formal language very suitable to specify systems which depend on the resources that they own. Sometimes, in order to formally describe a system, it is useful to specify information about the available resources for the different components of the system. Let us introduce the following simple running example. Consider a system consisting in the parallel execution of n subsystems (P1 . . . Pn ) and m different kinds of resources that they may use (let us suppose that the total quantity of the resource i is equal to xi ). The performance of these subsystems depends on these resources (for example, the portion of memory used by each subsystem, time quantum of CPU, time quantum of access to the bus, etc). Each subsystem Pj has an initial distribution of resources xj1 . . . xjm , that
Research supported in part by the CICYT project TIC 2000-0701-C02-01. This research was carried out while the first author was visiting the GET-INT. He would like to thank Ana Cavalli for helpful discussions on testing and for her financial support under the Platonis project.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 1–16, 2002. c Springer-Verlag Berlin Heidelberg 2002
2
M. N´ un ˜ez and I. Rodr´ıguez
is, in the beginning Pj owns xji units of the resource i. Given the fact that the quantity of resources that subsystems own cannot be bigger j than the total amount, we work under the constraint: ∀ 1 ≤ i ≤ m : j xi ≤ xi . Finally, subsystems have a preference on how they like resources. For example, suppose that Pj1 runs at the same speed if we replace one unit of the resource i1 by four units of the resource i2 , while Pj2 runs at the same speed if one unit of the resource i1 is replaced by two units of the resource i2 . In particular, Pj1 will perform better if we replace three of its units of i2 by one additional unit of i1 . In PAMR a process does not only take into account its activity (that is, which actions can be performed at a given point of time) but it also considers which resources can be used during its execution. Besides, processes may exchange resources with other processes. For instance, in our running example, if Pj1 gives to Pj2 three units of i2 and receives from Pj2 one unit of i1 , then both subsystems run faster. So, PAMR provides mechanisms to, starting with an initial distribution of resources, accomplish a better performance of the system. Processes are able to exchange resources but harmful exchanges are forbidden. For instance, it is not allowed that Pj2 exchanges three units of i2 by one unit of i1 with Pj1 because both subsystems get worse, and thus the whole system deteriorates. The formal language PAMR has been already applied to very different frameworks: A variant of e-commerce [15], the management of software projects [20], and the definition of (part of) the behavior of agents in a cooperative learning environment [16]. However, the current formulation of PAMR lacks two characteristics that could strongly increase its application to the specification and analysis of communication protocols. First, there is no notion of input/output actions. Second, no notion of time appears in the language. In this paper we deal with these two limitations by considering a model where PAMR fits. We will consider the well-known formalism of Extended Finite States Machines [13] (in short EFSM). Our aim is to show how the concepts underlying the conception of PAMR can be encoded into a kind of EFSM. In order to include time aspects, we consider that some actions take time to be performed. This time will mainly depend on the available resources, that is, in order to perform an action the bigger amount of suitable resources a process may use the faster this action will be performed. In PAMR (and in the mechanism presented in this paper) processes have a necessity function. Given an action, this function returns a positive real value if the process has enough resources to perform this action; otherwise, the value ∞ is returned. We will consider that this value denotes the time that it takes to perform the corresponding action (with respect to the available resources). In addition to the presentation of our formalism we study conformance testing relations in our framework. Conformance is the term used by system analyzers to describe the situation in which an implementation is adequate with respect to a given specification. In order to properly define this notion, and thus to have the formal basis for the process of testing, there has been a considerable effort, that in particular has been the seed for the joint ISO/ITU–T working group on “Formal Methods in Conformance Testing” (in [6] a summary of the work carried out by the group is presented). In order to formalize the notion of conformance
Encoding PAMR into (Timed) EFSMs
3
two are the most extended methods: by means of an implementation relation or by requirements. We will concentrate on the first approach. An implementation relation relates implementations from a given set Imp with specifications from another set Spec. Our study considers relations based on conf [5] and more precisely on the update of this relation to deal with inputs and outputs: ioco [25, 26]. In order to cope with time, we will not take into account only that a system may perform a given action, but we will also record the amount of time that the system needs to do so (according to the resources that it owns). Unfortunately, conformance testing relations for timed systems have not been yet extensively studied. We propose three conformance relations according to the interpretation of good implementation for a given specification. Regarding our relations, time aspects add some extra complexity. For example, even though an implementation I had the same traces as an specification S, we should not consider that I conforms to S if the implementation is always slower than the specification. Moreover, it can be the case that a system performs a sequence of actions for different times. These facts motivate the definition of several conformance relations. For example, it can be said that an implementation conforms to a specification if the implementation is always faster, or if the implementation is at least as fast as the worst case of the specification. We think that the relations that we introduce in this paper can be useful for the study of conformance for other models of timed systems. For example, the definitions can be easily adapted to timed automata [1]. Other definitions of timed I/O automata (e.g. [10,24]) are restricted to deterministic (regarding actions) behavior. In this case, some of our relations will be equivalent among them (i.e. they will relate the same automaton). In terms of related work, there are models to specify systems sharing resources (e.g. [4]), but in this case resources are just accessed, not traded; this access induces some delays in the behavior of processes. Our proposal is somehow related to the ODP trading function [11]. Nevertheless, in our case a process only uses (and nobody else can use them until they are exchanged) the resources that it owns. Finally, management of resources appears in fields like operating systems or concurrent programming. Resources are usually owned by a mediator which allows processes to use them. Regarding conformance testing for timed systems, some proposals have already appeared in the literature (e.g. [18,7,10, 24]). Our proposal differs from these ones in several points, mainly because the treatment of time is different. We do not have a notion of clock(s) together with time constraints; we associate time to the execution of actions (the time that it takes for a system to perform and action). The rest of the paper is organized as follows. In Section 2 we define our language in terms of processes and systems. In Section 3 we study implementation relations for our framework where we make an interpretation of the behavior with respect to time. We relate these implementation relations. We also introduce a new relation that classifies policies for exchanging resources with respect to a specification. In Section 4 we show how test cases are defined and describe how to apply them to implementations. Finally, in Section 5 we present our conclusions and some directions for further research.
4
2
M. N´ un ˜ez and I. Rodr´ıguez
PAMR Processes as (Timed) EFSMs
In this section we show how the concepts behind the definition of PAMR can be encoded into an extended notion of EFSM. The main differences with respect to usual EFSMs consist in the addition of time and the existence of symbolic transitions denoting exchanges of resources. Next we introduce the definition of Timed EFSM. We suppose that the number of different variables is equal to m. Definition 1. A Timed Extended Finite State Machine, in the following TEFSM, is a tuple M = (S, I, O, T r, sin , y¯) where S is a finite set of states, I is the set of input actions, O is the set of output actions, T r is the set of transitions, sin is the initial state, and y¯ ∈ IRm + is a tuple of variables. Each transition t ∈ T r is a tuple t = (s, s , i, o, Q, Z, C) where s, s ∈ S are the initial and final states of the transition, i ∈ I and o ∈ O are the input and output actions, respectively, associated with the transition, Q : IRm + −→ Bool m is a predicate on the set of variables, Z : IRm −→ I R is a transformation over + + the current variables, and C : IRm −→ I R ∪ {∞} is the time that the transition + + needs to be completed according to the available resources. A configuration in M is a pair (s, x ¯) where s ∈ S is the current state and x ¯ is the current tuple of variable values. We say that tr = (s, s , (i1 /o1 , . . . , ir /or ), Q, Z, C) is a (timed) trace of M if there exist transitions t1 , . . . , tr ∈ T r such that t1 = (s, s1 , i1 , o1 , Q1 , Z1 , C1 ),. . ., tr = (sr−1 , s , ir , or , Qr , Zr , Cr ), the predicate Q is defined such that it holds Q(¯ x) = (Q1 (¯ x) ∧ Q2 (Z1 (¯ x)) ∧ . . . ∧ Qr (Zr−1 (. . . (Z1 (¯ x)) . . .))), the transformation Z is defined as Z(¯ x) = Zr (Zr−1 (. . . (Z1 (¯ x)) . . .)), and C is defined as C(¯ x) = C1 (¯ x) + C2 (Z1 (¯ x)) + · · · + Cr (Zr−1 (. . . (Z1 (¯ x)) . . .)). Let I ⊆ I. The first occurrence of I in the trace tr, denoted by First(tr, I ), is defined as the first input ij ∈ I , with 1 ≤ j ≤ r, appearing in the trace.
Intuitively, for a configuration (s, x ¯), a transition t = (s, s , i, o, Q, Z, C) indicates that if the machine is in state s, receives the input i, and the predicate Q holds for x ¯, then after C(¯ x) units of time (assuming C(¯ x) = ∞) the machine emits the output o and the values of the variables are transformed according to Z. Traces are defined as a sequence of transitions. In this case, the predicate, the transformation function, and the time associated with the trace are computed from the corresponding to each transition belonging to the sequence. We suppose that addition in real numbers is extended in the following way: ∞ + r = ∞. Finally, the notion of first occurrence will be used when deleting internal actions from the composition of machines. Example 1. In Figure 1 we present two TEFSMs. For example, let us suppose that the initial value of variables is x ¯ = (2, 0, 0, 2) and that the initial state of M1 is the state labelled by 1. Then, the transition t12 can be performed, it will take time 12 , and after that, the value of the variables will be given by (3, 0, 0, 1). As we said in the introduction, we separate between the behavior of the process and the management of resources. We introduce three functions that are
Encoding PAMR into (Timed) EFSMs
M1
M2
1
a4 /b4
2
a1 /b1
b1 /a4 a2 /b2
a3 /b3
t1 = (s1 , s1 , b1 , a4 , Q1 , Z1 , C1 ) t2 = (s1 , s1 , b2 , a3 , Q2 , Z2 , C2 )
3
Zi (¯ x) = x ¯+
I = {a1 , a2 , a3 , a4 }, O = {b1 , b2 , b3 , b4 } = = = = =
(s1 , s2 , a1 , b1 , Q1 , Z1 , C1 ) (s1 , s3 , a2 , b2 , Q2 , Z2 , C2 ) (s2 , s3 , a3 , b3 , Q3 , Z3 , C3 ) (s2 , s1 , a4 , b4 , Q4 , Z4 , C4 ) (s2 , s2 , a1 , b1 , Q5 , Z5 , C5 )
Zi (¯ x) = x ¯+
(1, 0, 0, −1) if i ∈ {1, 2, 5}
(1, 1, −1, −1) if i = 1 (1, 0, 0, 0)
Qi (¯ x) ≡ Zi (¯ x) ≥ ¯ 0 ∧
if i = 2 x1 > 0 ∧ x2 > 0 if i = 1
x3 > 0 if i = 2 1 if i = 1 ∧ x1 = 0 ∧ x2 = 0 xi ·x2 1 Ci (¯ x) = if i = 2 x 3 ∞ otherwise
(0, 1, −1, 0) if i ∈ {3, 4}
Qi (¯ x) ≡ Zi (¯ x) 1 xi 1 Ci (¯ x) = x1 ∞
b2 /a3
1
I = {b1 , b2 }, O = {a3 , a4 }
a1 /b1
t12 t13 t32 t21 t22
5
≥ ¯ 0 ∧
xi > 0 if i ∈ {1, 2, 3, 4} x1 > 0 if i = 5
if i ∈ {1, 2, 3, 4} ∧ xi = 0 if i = 5 ∧ x1 = 0 otherwise
We suppose that x ¯ ∈ IR4+ . We denote by xi the i-th component of x ¯. Fig. 1. Examples of TEFSM.
responsible for controlling all the details related to the resources that a machine may use at a given state. Consider M = (S, I, O, T r, sin , y¯). + 1 – Utility functions. A function u : S × IRm + −→ IR such that u is monotonic and non-decreasing in the second argument. A utility function makes, for each state, a classification of the different basket of resources. For instance, u(s, x ¯1 ) < u(s, x ¯2 ) means that if the corresponding machine is currently in the state s then it prefers to have the basket of resources x ¯2 to the basket x ¯1 . Note that this function depends on the state as preferences are not the same in all the states of the machine (they are usually strongly influenced by the actions that can be performed). + – Necessity functions. A function n : O × IRm + −→ IR ∪ {∞} such that n is monotonic and non-increasing in the second argument. The purpose of this function is to decide whether the machine owns enough resources to perform the corresponding output action (i.e., it returns a value different from ∞). We consider that only output actions need resources to be performed because input actions are passive entities in the sense that they are performed once a suitable signal is received. In this case, the machine performing the corresponding output action will use resources to perform the communication. Time will be introduced into our processes by means of this function. m – Consumption functions. A function c : O × IRm + → IR+ . They indicate how resources are created/consumed after performing an action. For example, 1
In the following we consider that IRm + is ordered by the relation (x1 , . . . , xm ) ≤ (y1 , . . . , ym ) iff xi ≤ yi , for any 1 ≤ i ≤ m.
6
M. N´ un ˜ez and I. Rodr´ıguez
c(o, x ¯) = y¯ means that if the machine currently owns the basket of resources x ¯ then the amount of resources owned after performing o is given by y¯. A process is a TEFSM where transitions adequately reflect the corresponding associated functions. Intuitively, predicates in transitions will indicate that the machine has enough resources to perform the corresponding action and that after creating/consuming resources no debts are generated; transformation functions will record the new basket of resources after the transition is performed; finally, the time associated with transitions is given by the necessity function. Definition 2. Let M = (S, I, O, T r, sin , y¯) be a TEFSM and u, n, c be utility, necessity and consumption functions, respectively. We say that P = (M, u, n, c) is a process if for each t = (s, s , i, o, Q, Z, C) ∈ T r the predicate Q, and the functions Z and C fulfill Q(¯ x) ≡ (n(o, x ¯) < ∞ ∧ Z(¯ x) ≥ ¯0), Z(¯ x) = c(o, x ¯), and C(¯ x) = n(o, x ¯).
Example 2. Consider the machine M1 presented in Example 1. Let n and c be two functions defined, respectively, as n(bj , x ¯) =
1 xj
if xj > 0 ∞ otherwise
c(bj , x ¯) = x ¯+
(1, 0, 0, −1) if j ∈ {1, 2} (0, 1, −1, 0) if j ∈ {3, 4}
If u1 is a utility function for M1 then we have that (M1 , u1 , n, c) is a process. Accordingly, if we extend n and c in the following way 1 x1 ·x2 if j = 4 ∧ x1 > 0 ∧ x2 > 0 1 if j = 3 ∧ x3 > 0 n(aj , x ¯) = x3 ∞ otherwise
c(aj , x ¯) = x ¯+
(1, 1, −1, −1) if j = 4 (1, 0, 0, 0) if j = 3
and u2 is a utility function for M2 then (M2 , u2 , n, c) is also a process.
In this paper we do not consider usual variables. That is, variables are always associated with resources.2 Let us remark that, for each transition, Z, Q, and C will be applied to the current amount of resources (they will be indicated by the current configuration). Let us also note that even though the utility function does not explicitly appear in the definition of transitions, it will be taken into account when processes exchange resources. We will define systems by composing several processes. Processes will communicate among them in two ways. First, they will jointly perform actions by sending an output action from one process that will be received (as an input) by another one. Besides, in order to improve their performance, processes will exchange resources. These exchanges will be guided by a policy. We consider the 2
In order to cope with this restriction it is enough to consider that the whole set of variables ranges over A×IRm + , being A the type of the variables keeping track of data. Note that A may possibly be a cartesian product of different sorts. Predicates and functions associated with transitions should be adapted accordingly. For example, for a transition t = (s, s , i, o, Q, Z, C) we would have Q = Q1 ∧ Q2 where Q1 is a predicate over A while Q2 is a predicate over IRm +.
Encoding PAMR into (Timed) EFSMs
7
two policies already introduced in [19].3 Under a preserving utility policy exchange of resources are allowed only if, after the exchange, at least one process improves and no process gets worse. Intuitively, processes are the owners of the resources and they will not give up them if they do not receive a compensation. Under a maximizing utility policy exchanges are allowed only if the whole system improves (even if some of the components deteriorate). In order to measure when a process/system improves we take into account the corresponding utiln×n ity functions. Exchanges are denoted by a matrix E ∈ (IRm . An element +) Ei1 i2 = (x1 , . . . , xi , . . . , xm ) indicates that the process i1 gives to the process i2 a total of xi units of the i-th resource. So, the total tuple of resources given by the process i1 to the rest of processes is k Ei1 k while it receives from other processes the tuple k Eki1 . Definition 3. Let P1 , . . . , Pn be processes such that Pi = (Mi , ui , n, c), for some utility functions ui , and some necessity and consumption functions n and c, respectively. For each i, let ci = (si , x ¯i ) be configurations over Pi . An exchange matrix (usually denoted by E, E , . . .) is an n × n matrix where the components belong to IRm +. We say that the exchange indicated by E is allowed under the preserving policy (resp. maximizing policy) for the configurations c1 , . . . , cn , denoted by allowedpres (c1 , . . . , cn , E) (resp. allowedmax (c1 , . . . , cn , E)), if we have that ∀1≤i≤n:x ¯i − k Eik ≥ ¯0 and the following conditions hold: – Preserving policy: • ∃ 1 ≤ r ≤ n : ur (sr , x ¯r + k Ekr − k Erk ) > ur (sr , x ¯r ), and • ∀ 1 ≤ i ≤ n : ui (si , x ¯i + k Eki − k Eik ) ≥ ui (si , x ¯i ) – Maximizing policy: • u (s , ¯i ) < i ui (si , x ¯i + k Eki − k Eik ) i i i x
The three conditions defining the preserving policy indicate, respectively, that no process gives resources that it does not own, that (at least) one process improves after the exchange, and that no one deteriorates. The second condition of the maximizing policy expresses that the total utility of the processes (measured as the addition of the corresponding utilities) increases after the exchange. We compose processes to define systems. Some of the actions of the processes will be hidden indicating that they are not visible, that is, they can be neither controlled nor observed. In order to facilitate the understanding, we have not defined a compressed version of systems where internal communications are omitted. So, we generate the whole graph (including both internal and external actions) and then we delete internal communications (getting what we call a simplified system). In addition to the usual input/output transitions, systems have a kind of symbolic transitions indicating exchange of resources. These transitions are parameterized by the allowed exchange matrixes for the current configuration. In this case, transition will be labelled with special input and output 3
The choice of a good policy is not a trivial task, as this problem is related with the social welfare aggregator problem. Arrow’s impossibility theorem [2] shows that there does not exist such an aggregator fulfilling a certain set of desirable properties.
8
M. N´ un ˜ez and I. Rodr´ıguez
symbols (the symbol ∗ and the corresponding exchange matrix, respectively). A system will be able to perform a transition labelled by an external input only when no more exchanges are allowed. That is, processes exchange resources until they reach a good distribution. In this case, transitions take into account the current configurations of the processes. Definition 4. Let P1 , . . . , Pn be processes, where Pi = (Mi , ui , n, c), for some utility functions ui , and some necessity and consumption functions n and c, respectively; each M is given by M = (S , I , O , T r , s , y ¯ ). Let I ⊆ i i i i i i in i i i Ii and O ⊆ i Oi , such that I ∩ O = ∅. The system created by the composition of P1 , . . . , Pn under the exchange policy P ol with respect to the actions sets I and O, denoted in short by Sys(P1 , . . . , Pn , I, O, P ol), is defined as the TEFSM n×n (S, I ∪ {∗}, O ∪ (IRm , T r, sin , y¯) where: +) – The initial state sin is defined as sin = (sin1 , . . . , sinn ). – The initial tuple of (tuples of) variable values is y¯ = (¯ y1 , . . . , y¯n ). – S = S1 × · · · × Sn . Actually, it is enough to consider those states reachable from sin by sequences of transitions belonging to T r. – Let s ∈ S with s = (s1 , . . . , sn ). We have (s, s, ∗, E, Q, Z, C) ∈ T r, where Q and Z are defined as Q(¯ x1 , . . . , x ¯n ) ≡ allowedP ol ((s1 , x ¯1 ), . . . , (sn , x ¯n ), E) and Z(¯ x1 , . . . , x ¯n ) = (¯ x1 + z¯1 , . . . , x ¯n + z¯n ), where z¯i = k Eki − k Eik . Besides, the time function C is defined as C(¯ x1 , . . . , x ¯n ) = 0. – Let s = (s1 , . . . , sj , . . . , sn ) and s = (s1 , . . . , sj , . . . , sn ) be two states. We have (sj , sj , i, o, Qj , Zj , Cj ) ∈ T rj implies (s, s , i, o, Q, Z, C) ∈ T r, where Q(¯ x1 , . . . , x ¯n ) ≡ Qj (¯ xj ) ∧ (i ∈ I ⇒ (s, s, ∗, E, Q , Z , C ) ∈ T r : Q (¯ x1 , . . . , x ¯n )), Z(¯ x1 , . . . , x ¯n ) = (¯ x1 , . . . , Zj (¯ xj ), . . . , x ¯n ), and C(¯ x1 , . . . , x ¯n ) = Cj (¯ xj ). Let tr = (s, s , (i1 /o1 , . . . , ir /or ), Q, Z, C) be a trace for the previous TEFSM. We say that tr is a chained trace if or ∈ O and there exists 1 ≤ k ≤ r such that n×n ik ∈ I, for any 1 ≤ j ≤ k − 1 we have ij = ∗ and oj ∈ (IRm , and for any +) k + 1 ≤ l ≤ r we have il ∈ / I ∪ O and il = ol−1 .
Let us note that actions not belonging to I ∪ O are considered as internal. For the sake of simplicity, we consider that exchanges do not consume time.4 A chained trace consists of a sequence of exchanges, an external input action, a consecutive sequence of paired output/input actions, and finally an external output action. Let us remind that the predicate Q and the functions Z and C associated with chained traces take into account the exchanges performed before the first visible input appears in the trace (see Definition 1). In order to abstract internal computations, systems are transformed into simplified systems. The idea is that transitions of a simplified systems are those chained traces belonging to the original system. 4
Time can be associated with exchanges of resources by replacing the assignment C(¯ x) = 0 in the fourth clause of the previous definition by C(¯ x) = e(¯ x), where e is a function computing time with respect to the amount of exchanged resources.
Encoding PAMR into (Timed) EFSMs
9
b1 /a4
S1 a4 /b4
(1, 1)
a2 /b2
a1 /b4
a2 /b3
a1 /b4
a2 /b3
b1 /a4 (2, 1)
a1 /b1
S3 a1 /b4
(1, 1)
b2 /a3 a1 /b1
b1 /a4
S2 a1 /b4
(1, 1)
a3 /b3 b2 /a3
(3, 1)
(2, 1)
a2 /b4
(2, 1)
b2 /a3
Fig. 2. Examples of Systems and Simplified Systems.
Example 3. In Figure 2 (left) we present the composition of the processes defined in Example 2. We have omitted transitions related to exchanges. Let us consider that their utility functions are respectively defined as: x1 + x2 if j = 1 u1 (sj , x ¯) = x1 + x4 if j = 2 x3 if j = 3
u2 (s1 , x ¯) = x1 · x2 + x3
Suppose that the initial distributions are x ¯1 = (1, 1, 2, 1) and x ¯2 = (5, 1, 0, 0), respectively, and that we are in the initial state (state (1, 1) of the composition). A possible exchange under the maximizing policy would transform these distributions into x ¯1 = (0, 0, 0, 1) and x ¯2 = (6, 2, 2, 0). Note that this exchange is not allowed under a preserving policy. In the latter case we could have, for example, an exchange leading to x ¯1 = (3, 0, 0, 1) and x ¯2 = (3, 2, 2, 0). We suppose that the sets of actions I and O are respectively defined as I = {a1 , a2 } and O = {b3 , b4 }. These sets are more relevant when defining the associated simplified system. In Figure 2 (center) we present the simplified system corresponding to the previous system.
n×n Definition 5. Let Comp = (S, I ∪ {∗}, O ∪ (IRm , T r, sin , y¯) be a system. +) We say that M = (S , I, O, T r , sin , y¯) is the simplified system associated with Comp, denoted by Simp(Comp), if S and T r fulfill the recursive definition:
– sin ∈ S , and – If s ∈ S and tr = (s, s , (i1 /o1 , . . . , ir /or ), Q, Z, C) is a chained trace of Comp then s ∈ S and (s, s , First(tr, I), or , Q, Z, C) ∈ T r . We say that i1 /o1 , . . . , ir /or is a non-timed evolution, or simply evolution, of M if there exists a trace (sin , s , (i1 /o1 , . . . , ir /or ), Q, Z, C) of M such that Q(¯ y ) holds. Given a simplified system Scomp, we denote by NTEvol(Scomp) the set of non-timed evolutions of Scomp. We say that the pair ((i1 /o1 , . . . , ir /or ), t) is a timed evolution of M if there exists a trace (sin , s , (i1 /o1 , . . . , ir /or ), Q, Z, C) of M such that Q(¯ y ) holds and t = C(¯ y ). Given a simplified system Scomp, we denote by TEvol(Scomp) the set of timed evolutions of Scomp.
10
M. N´ un ˜ez and I. Rodr´ıguez
Let us remind that First(tr, I) denotes the first (an unique) occurrence of an external input in the chained trace tr. As we said before, a chained trace is converted into a single transition. Then, an evolution is a trace from the initial state of the simplified system. Let us note that all the actions appearing in evolutions are visible (as both internal actions and exchanges are removed by considering transitions formed from chained traces). We distinguish between timed and non-timed evolutions (where we simply forget the associated time) because it simplifies the forthcoming definitions of implementation relations.
3
(Timed) Implementation Relations
In this section we introduce our implementation relations. All of them follow the same pattern: An implementation I conforms to a specification S if for any possible evolution of S the outputs that the implementation I may perform after a given input are a subset of those for the specification. This pattern is borrowed from ioco [25,26] but we do not consider quiescent states (that is, states where no external outputs are available). In addition to the non-timed conformance of the implementation, we require some time conditions to be hold (this is a major difference with respect to ioco where time is not considered). For example, we may ask an implementation to be always faster than the time constraints imposed by the specification. The different considerations of time produce that there is not a unique way to define an implementation relation. Next, we formally define the sets of specifications and implementations: Spec and Imp. A specification is the composition of a set of processes, that is a system, or equivalently its associated simplified system. Regarding implementations, we have to determine what is visible. We consider that exchanges of resources are autonomous as they only concern internal planning of the corresponding processes. Even in this case, these exchanges strongly influence the behavior of implementations as they may allow/disallow some actions to be performed. Let us remind that a necessary condition for an action to be performed is that the corresponding process owns enough resources. Another approach could be to consider that exchanges can be either observed or controlled (by adding adequate points of control and/or observation into the implementation). However, we think that such framework could be more appropriate for a kind of testing in context (see e.g. [21,14]) where we desire to test one component of a system (in this case a process) assuming that the rest of the system is correct. We will comment on this approach in the conclusions of this paper. Besides, we assume that all the input actions are always enabled in any state of the implementation (a similar assumption is taken in [26]). So, we can assume that for any input i and any state of the implementation s there always exists a transition (s, is a special (empty) output s, i, null, Q, Z, C) where null symbol, Q(¯ x) ≡ ¬ {Q (¯ x) | ∃ a transition (s, s , i, o, Q , Z , C )}, Z(¯ x) = x ¯, and C(¯ x) = 0. Other solutions consist in adding a transition leading to an error state or generating a transition to the initial state. Finally, we consider that implementations may not present non-observable non-deterministic behavior (see [22]
Encoding PAMR into (Timed) EFSMs
11
for a framework for deterministic implementations and non-deterministic specifications). For example, an implementation cannot have simultaneously two transitions as (s, s1 , i, o, Q1 , Z1 , C1 ) and (s, s2 , i, o, Q2 , Z2 , C2 ). Note that we do not restrict observable non-determinism, that is, we may have both the transition (s, s1 , i, o1 , Q1 , Z1 , C1 ) and (s, s2 , i, o2 , Q2 , Z2 , C2 ), with o1 = o2 . First, we introduce an implementation relation where time is not considered. Definition 6. Let S and I be two simplified systems. We say that I nontimely conforms to S, denoted by I confnt S, if for each non-timed evolution e = (i1 /o1 , . . . , ir−1 /or−1 , ir /or ) ∈ NTEvol(S), with r ≥ 1, we have that e = (i1 /o1 , . . . , ir−1 /or−1 , ir /or ) ∈ NTEvol(I) implies e ∈ NTEvol(S).
Example 4. Consider the simplified systems S2 and S3 depicted in Figure 2 (center and right). Suppose that we have an initial distribution such that all the transitions can be performed. We have S3 confnt S2 . Note that the non-timed evolutions from S3 having as prefix the sequence a2 /b3 , a2 /b4 are not checked because S2 (playing the role of specification) cannot perform those evolutions. Let us now consider that the system S2 is extended with the (implicit) transition ((2, 1), (2, 1), a2 , null, true, Z, C) where Z(¯ x) = x ¯ and C(¯ x) = 0, so that it fulfills the conditions required for implementations (input enabling). Then, S2 does not conform to S3 . For example, S3 may perform the non-timed evolution e = a2 /b3 , a2 /b4 , S2 has the non-timed evolution e = a2 /b3 , a2 /null, but e does not belong to the set of non-timed evolutions of S3 . Note that e and e have the same prefix a2 /b3 , a2 .
Next, we introduce our timed implementation relations. In the following, we call an instance of an evolution e = (i1 /o1 , . . . , ir /or ) to a pair (e, t). In the confa relation (conforms always) we consider that for any timed evolution (e, t) of the implementation we have that if e is a non-timed evolution of the specification then (e, t) is also a timed evolution of the specification. In the confw relation (conforms in the worst case) the implementation is forced, for each timed evolution fulfilling the previous conditions, to be faster than the slowest instance of the same evolution in the specification. The confb relation (conforms in the best case) is similar but considering the fastest instance. Let us remind that different instances of the same evolution may appear in a specification as result of the different configurations produced by exchanges of resources. Definition 7. Let S and I be two simplified systems. We define the following implementation relations: – I confa S iff I confnt S and for any timed evolution (e, t) ∈ TEvol(I) we have e ∈ NTEvol(S) =⇒ (e, t) ∈ TEvol(S). – I confw S iff I confnt S and for any timed evolution (e, t) ∈ TEvol(I) we have e ∈ NTEvol(S) =⇒ (∃ t : (e, t ) ∈ TEvol(S) ∧ t ≤ t ). – I confb S iff I confnt S and for any timed evolution (e, t) ∈ TEvol(I) we have e ∈ NTEvol(S) =⇒ (∀ t : ((e, t ) ∈ TEvol(S) =⇒ t ≤ t )).
12
M. N´ un ˜ez and I. Rodr´ıguez
Theorem 1. The relations given in Definition 7 are related as follows: I confa S ⇒ I confw S ⇐ I confb S Proof Sketch: We only need to consider the evolutions of I belonging also to S (for the rest of evolutions, the premises of the corresponding conformance relation do not hold). First, note that the condition about the non-timed conformance is the same in all the definitions. So, we only need to take into account the conditions on time appearing in the second clause of the corresponding relations. If I confa S then we have that each timed evolution in I fulfilling the conditions given in the definition of confa does also appear in S, so we have I confw S. If I confb S then each timed evolution of I fulfilling the conditions given in the definition of confb is faster than the fastest instance of the same evolution for S. Therefore, it is also faster than the slowest one for S, and so I confw S. It is interesting to note that if specifications are restricted to take always the same time for each given evolution (independently from the possible derivation taken for such evolution) then the relations confb and confw would coincide, but they would be still different from the confa relation. Lemma 1. Let M = (S, I, O, T r, sin , y¯) be a simplified system. Let us suppose that there do not exist ((i1 /o1 , . . . , ir /or ), t), ((i1 /o1 , . . . , ir /or ), t ) ∈ TEvol(M ) with t = t . For any simplified system I we have I confb M iff I confw M .
We also introduce a new implementation relation parameterized by the chosen policy for the exchange of resources. In this case, we suppose that the tester can indicate to the implementation under test which policy should be followed to perform exchanges. So, given a set of possible policies, we provide a mechanism to decide which one is more suitable for a given specification. First, we rephrase the definition of systems and simplified systems. We consider them as functions depending on one parameter (the corresponding policy). Definition 8. Let us consider the set π of all the policies. Let Systems be the set of systems. The parameterized system created by the composition of the processes P1 , . . . , Pn with respect to the sets I and O is defined as the function PS : π → Systems such that PS(P ol) = Sys(P1 , . . . , Pn , I, O, P ol). Let SimpSystems be the set of simplified systems. The parameterized simplified system created by the parameterized system PS is defined as the function SPS : π → SimpSystems such that SPS(P ol) = Simp(PS(P ol)). Let P ol1 , P ol2 be two policies and SPS be a simplified parameterized system. Let us consider I1 = SPS(P ol1 ) and I2 = SPS(P ol2 ). Let S be a simplified system. We say that the policy P ol1 is preferred to the policy P ol2 for SPS to conform to S, denoted by P ol2 SPS,S P ol1 , if we have that for any conformance relation confy such that I2 confy S there exists another conformance relation confx such that I1 confx S and confx ⇒ confy .
Encoding PAMR into (Timed) EFSMs
b3 f ail
T1
T2
T3
T4
a1
a1
a1
a1
b4
null
b3
b4
null
b3 f ail
a2 f ail
f ail
a2 f ail
b3
null
b4
b3
f ail
a1 f ail
f ail
b4
b3
b4
pass
f ail
b4 pass
null
b3
f ail
f ail
b4
13
null
a2 f ail
null
b4
f ail
f ail
a2 f ail
null
b4
b3
f ail
pass
pass
b3
f ail
null
null f ail
Fig. 3. Examples of Test Cases.
4
Definition and Application of Test Cases
A test represents a sequence of inputs applied to the implementation. Once an output is received, we check whether it is the expected one or not. In the latter case, a fail signal is produced. In the former case, either a pass signal is emitted (indicating successful termination) or the testing process continues by applying another input. If we are testing an implementation with input and output sets I and O, respectively, tests are deterministic acyclic I/O labelled transition systems (i.e. trees) with a strict alternation between an input action and the set of output actions. After an output action we may find either a leaf or another input action. Leaves can be labelled either by pass or by fail. In the first case we add a time stamp. This time will be contrasted with the one that the implementation took to arrive to that point. Definition 9. A test case is a tuple T = (S, I, O, T r, s0 , SI , SO , SF , SP , C) where S is the set of states, I and O are disjoint sets of input and output actions, respectively, T r ⊆ S × I ∪ O × S is the transition relation, s0 ∈ S is the initial state, and the sets SI , SO , SF , SP ⊆ S are a partition of S. The transition relation and the sets of states fulfill the following conditions: – SI is the set of input states. We have that s0 ∈ SI . For any input state s ∈ SI there exists a unique outgoing transition (s, a, s ) ∈ T r. For this transition we have that a ∈ I and s ∈ SO . – SO is the set of output states. For any output state s ∈ SO we have that for any o ∈ O there exists a unique state s such that (s, o, s ) ∈ T r. In this case, s ∈ / SO . Moreover, there do not exist i ∈ I, s ∈ S such that (s, i, s ) ∈ T r. – SF and SP are the sets of fail and pass states, respectively. We say that these states are terminal. Besides, for any state s ∈ SF ∪ SP we have that there do not exist a ∈ I ∪ O and s ∈ S such that (s, a, s ) ∈ T r. Finally, C : SP −→ IR+ is a function associating time stamps with passing states.
14
M. N´ un ˜ez and I. Rodr´ıguez σ
Let σ = i1 /o1 , . . . , ir /or . We write T =⇒ s, if s ∈ SF ∪ SP and there exist states s12 , s21 , s22 , . . . sr1 , sr2 ∈ S such that {(s0 , i1 , s12 ), (sr2 , or , s)} ⊆ T r, for any 2 ≤ j ≤ r we have (sj1 , ij , sj2 ) ∈ T r, and for any 1 ≤ j ≤ r − 1 we have (sj2 , oj , s(j+1)1 ) ∈ T r. We say that a test case T is an instance of the test case T if they only differ in the associated function C assigning times to passing states. We say that a test case T is valid if the graph induced by T is a tree with root at the initial state s0 .
In Figure 3 we present some examples of test cases (time stamps are omitted). Next we define the application of a tests suite (i.e. a set of tests) to an implementation. We say that the tests suite T is passed if for any test the terminal states reached by the composition of implementation and test belong to the set of passing states. Besides, we give timing conditions according to the different implementation relations. Definition 10. Let I be a simplified system and T be a valid test. We write σ σ I T =⇒t sT if T =⇒ sT and (σ, t) ∈ TEvol(I). We say that I passes the set of tests T , denoted by pass(I, T ), iff for any test T = (S, I, O, T r, s, SI , SO , SF , SP , C) ∈ T and σ ∈ NTEvol(I) there do not σ exist sT and t such that I T =⇒t sT and sT ∈ SF . We say that I passes the set of tests T for any time iff pass(I, T ) and σ for any (σ, t) ∈ TEvol(I) such that T =⇒ sT for some T ∈ T , there exists σ T = (S, I, O, T r, s, SI , SO , SF , SP , C) ∈ T such that I T =⇒t sT with sT ∈ SP T and t = C(s ). We say that I passes the set of tests T in the worst time iff pass(I, T ) and σ for any (σ, t) ∈ TEvol(I) such that T =⇒ sT for some T ∈ T , there exists σ T = (S, I, O, T r, s, SI , SO , SF , SP , C) ∈ T such that I T =⇒t sT with sT ∈ SP T and t ≤ C(s ). We say that I passes the set of tests T in the best time iff pass(I, T ) and σ for any (σ, t) ∈ TEvol(I) such that T =⇒ sT for some T ∈ T , we have that σ for any T = (S, I, O, T r, s, SI , SO , SF , SP , C) ∈ T such that I T =⇒t sT with T T s ∈ SP it holds that t ≤ C(s ).
Due to space limitations we cannot include a test derivation algorithm. The algorithm is based on that given for ioco [26] but taking into account the time associated with transitions. These times will be used to define the function assigning time to successful states. For instance, the first three tests in Figure 3 are derived for the system S2 appearing in Figure 2. Moreover, the last test in the same figure can be used to determine that S2 does not conform to S3 . Given a specification S, if we call tests(S) to the set of tests returned by the derivation algorithm, and we replace T in the previous definition by tests(S), we obtain alternative characterizations for the conformance relations presented in Definition 7.
Encoding PAMR into (Timed) EFSMs
5
15
Conclusions and Future Work
In this paper we have shown how the concepts underlying PAMR can be added in a natural way to the formalism of EFSMs. We have defined different implementation relations by taking into account timing relations between specifications and implementations. We consider that this paper represents only the basis of our study, so some points should be extended or improved. A line for future work consists in considering that exchanges can be controlled and/or observed. In this case, we would be able to control the exchanges that a process (that is, a part of a system) can do. Therefore, the definition of simplified systems should be modified to consider that exchanges may appear in the corresponding traces. This extension can be also used to perform a better study of the role played by policies in systems. Finally, we are also studying how the testing equivalence presented in [9], where the transitive closure of conf is studied as a testing equivalence, can be adapted to deal with our new implementation relations. Acknowledgments. We would like to thank Alex Petrenko for useful discussions on conformance testing relations and in the application of these relations to PAMR. We would also like to thank Natalia L´ opez for her help while preparing this paper. Finally, we thank the anonymous referees for their helpful remarks.
References 1. R. Alur and D. Dill. A theory of timed automata. Theoretical Computer Science, 126:183–235, 1994. 2. K.J. Arrow. Social Choice and Individual Values. Wiley, 2nd edition, 1963. 3. M. Barbuceanu and W.K. Lo. Multi-attribute utility theoretic negotiation for electronic commerce. In AMEC 2000, LNAI 2003, pages 15–30. Springer, 2001. 4. P. Br´emond-Gr´egoire and I. Lee. A process algebra of communicating shared resources with dense time and priorities. Theoretical Computer Science, 189(12):179–219, 1997. 5. E. Brinksma, G. Scollo, and C. Steenbergen. LOTOS specifications, their implementations and their tests. In Protocol Specification, Testing and Verification VI, pages 349–360. North Holland, 1986. 6. A. Cavalli, J.P. Favreau, and M. Phalippou. Standardization of formal methods in conformance testing of communication protocols. Computer Networks and ISDN Systems, 29:3–14, 1996. 7. D. Clarke and I. Lee. Automatic generation of tests for timing constraints from requirements. In 3rd Workshop on Object-Oriented Real-Time Dependable Systems, 1997. 8. M. Dastani, N. Jacobs, C.M. Jonker, and J. Treur. Modelling user preferences and mediating agents in electronic commerce. In Agent Mediated Electronic Commerce, LNAI 1991, pages 163–193. Springer, 2001. 9. D. de Frutos-Escrig, L.F. Llana-D´ıaz, and M. N´ un ˜ez. Friendly testing as a conformance relation. In Formal Description Techniques for Distributed Systems and Communication Protocols (X), and Protocol Specification, Testing, and Verification (XVII), pages 283–298. Chapman & Hall, 1997.
16
M. N´ un ˜ez and I. Rodr´ıguez
10. T. Higashino, A. Nakata, K. Taniguchi, and A. Cavalli. Generating test cases for a timed I/O automaton model. In 12th Workshop on Testing of Communicating Systems, pages 197–214. Kluwer Academic Publishers, 1999. 11. ISO/IEC. ODP Trading Function. Draft International Standard 13235, ISO Information Processing Systems, 1995. 12. S. Kalyanasundaram, E.K.P. Chong, and N.B. Shroff. Optimal resource allocation in multi-class networks with user-specified utility functions. Computer Networks, 38:613–630, 2002. 13. D. Lee and M. Yannakakis. Principles and methods of testing finite state machines: A survey. Proceedings of the IEEE, 84(8):1090–1123, 1996. 14. L.P. Lima and A. Cavalli. A pragmatic approach to generating tests sequences for embedded systems. In 10th Workshop on Testing of Communicating Systems, pages 288–307. Chapman & Hall, 1997. 15. N. L´ opez, M. N´ un ˜ez, I. Rodr´ıguez, and F. Rubio. A formal framework for ebarter based on microeconomic theory and process algebras. In Innovative Internet Computer Systems, LNCS 2346, pages 217–228. Springer, 2002. 16. N. L´ opez, M. N´ un ˜ez, I. Rodr´ıguez, and F. Rubio. Including malicious agents into a collaborative learning environment. In 8th Intelligent Tutoring Systems, LNCS 2363, pages 51–60. Springer, 2002. 17. S.H. Low and D.E. Lapsley. Optimization flow control I: Basic algorithm and convergence. IEEE/ACM Transactions on Networking, 7(6):861–875, 1999. 18. D. Mandrioli, S. Morasca, and A. Morzenti. Generating test cases for real time systems from logic specifications. ACM Trans. on Computer Systems, 13(4):356– 398, 1995. 19. M. N´ un ˜ez and I. Rodr´ıguez. PAMR: A process algebra for the management of resources in concurrent systems. In FORTE 2001, pages 169–185. Kluwer Academic Publishers, 2001. An extended version of this paper is available at: http://dalila.sip.ucm.es/˜manolo/papers/pamr.ps. 20. M. N´ un ˜ez and I. Rodr´ıguez. Applying PAMR to the management of software projects: Humans as resources, 2002. Submitted for publication. 21. A. Petrenko, N. Yevtushenko, and G. von Bochmann. Fault models for testing in context. In Formal Description Techniques for Distributed Systems and Communication Protocols (IX), and Protocol Specification, Testing, and Verification (XVI), pages 163–178. Chapman & Hall, 1996. 22. A. Petrenko, N. Yevtushenko, and G. von Bochmann. Testing deterministic implementations from their nondeterministic specifications. In 9th Workshop on Testing of Communicating Systems, pages 125–140. Chapman & Hall, 1996. 23. L. Rasmusson and S. Janson. Agents, self-interest and electronic markets. Knowledge Engineering Review, 14(2):143–150, 1999. 24. J. Springintveld, F. Vaandrager, and P.R. D’Argenio. Testing timed automata. Theoretical Computer Science, 254(1-2):225–257, 2001. 25. J. Tretmans. Test generation with inputs, outputs and repetitive quiescence. Software – Concepts and Tools, 17(3):103–120, 1996. 26. J. Tretmans. Testing concurrent systems: A formal approach. In CONCUR’99, LNCS 1664, pages 46–65. Springer, 1999. 27. H. Yaiche, R.R. Mazumdar, and C. Rosenberg. A game theoretic framework for bandwith allocation and pricing in broadband networks. IEEE/ACM Transactions on Networking, 8(5):667–678, 2000.
Submodule Construction for Specifications with Input Assumptions and Output Guarantees * Gregor v. Bochmann School of Information Technology and Engineering (SITE), University of Ottawa, Canada
[email protected] Abstract. We consider the following problem: For a system consisting of two submodules, the behavior of one submodule is known as well as the desired behavior S of the global system. What should be the behavior of the second submodule such that the behavior of the composition of the two submodules conforms to S? – Solutions to this problem have been described in the context of various specification formalisms and various conformance relations. Here we present a generalization of this problem and its solution in the context of relational databases, and show that this general solution can be used to derive several of the known algorithms that solve the problem in the context of regular behavior specifications based on finite state automata with synchronous communication or interleaving semantics. The paper also provides a new solution formula for the case that the module behaviors are specified in a hypothesisguarantee paradigm distinguishing between input and output. A new submodule construction algorithm for synchronous, partially defined input/output automata is also given.
1 Introduction In automata theory, the notion of constructing a product machine S from two given finite state machines S1 and S2, written S = S1 x S2, is a well-known concept. This notion is very important in practice since complex systems are usually constructed as a composition of smaller subsystems, and the behavior of the overall system is in many cases equal to the composition obtained by calculating the product of the behaviors of the two subsystems. Here we consider the inverse operation, also called equation solving: Given the composed system S and one of the components S1, what should be the behavior S2 of the second component such that the composition of these two components will exhibit a behavior equal to S. That is, we are looking for the value of X which is the solution to the equation S1 x X = S. In fact, we are looking for the most general machine X which composed with S1 satisfies some conformance relation in respect to S. In the simplest case, this conformance relation is trace inclusion. A first paper of 1980 [Boch 80d] (see also [Merl 83]) gives a solution to this problem for the case where the machine behavior is described in terms of labeled transi*
This work was partly supported by a research grant from the Natural Sciences and Engineering Research Council of Canada. This paper was written when the author was a visiting professor at Osaka University, Japan.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 17–33, 2002. © Springer-Verlag Berlin Heidelberg 2002
18
G. v. Bochmann
tion systems (LTS) which communicate with one another by synchronous interactions (see also [Hagh 99] for a more formal treatment). This work was later extended to the cases where the behavior of the machines is described in CCS or CSP (with behavioral equivalence as conformance relation) [Parr 89], by finite state machines (FSM) communicating through message queues [Petr 98, Yevt 01a], by input/output automata [Dris 99a] ([Qin 91] considers bisimulation as conformance relation), and by synchronous finite state machines [Kim 97]. A restricted version of this problem is considered in an earlier paper [Kim 72] which considers series composition of FSMs where each message goes from the originating FSM to its neighbor on the right (no feedback). The specification of the rightmost FSM is derived from the behavior of the other FSMs and the desired behavior of the composition. For a discussion of the applications of this equation-solving method in communication protocol design and control theory, we refer the reader to [Boch 02a]. In this paper we show that the above equation solving problem in the different contexts of LTS, synchronous and asynchronous FSMs and IOA are all special cases of a more general problem which can be formulated in the context of relational database theory which is generalized to allow for non-finite relations (i.e. relations representing infinite sets). We give the solution of this general problem and give a proof of its correctness. We also show how the different specialized version of this problem – and the corresponding solutions – can be derived from the general database version. After a review of basic notions of relational databases, we present in Section 3 the problem of equation solving in the database context and provide solution formulas and their proofs. In Section 4, we discuss how the database model can be adapted to model the dynamic behavior of systems and their components based on trace semantics, that is, when the behavior of a system component is characterized by the set of possible traces of interactions in which it could participate. We consider the cases of synchronous rendezvous communication and interleaving semantics. We also explain how the solution formula for databases can be used to derive solution algorithms for systems with regular behavior (i.e. described by finite state transition systems). In Section 5 we introduce the distinction of input and output which allows the specification of a component behavior using the hypothesis-guarantee paradigm. We state appropriate conformance relations which can be used to define the submodule construction problem. We present a general solution formula which leads to several submodule construction algorithms that can be applied to different variants of regular behavior specifications, including a variant allowing for nondeterministic output and partially defined behaviors.
2
Review of Some Notions from the Theory of Relational Databases
The following concepts are defined in the context of the theory of relational databases [Maie 83]. Informally, a relational database is a collection of relations where each relation is usually represented as a table with a certain number of columns. Each column corresponds to an attribute of the relation and each row of the table is called a tuplet. Each tuplet defines a value for each attribute of the relation. Such a tuplet represents usually an “object”, for instance, if the attributes of the employee relation are
Submodule Construction for Specifications with Input Assumptions
19
name, city, age, then the tuplet represents the employee “Alice” from “Ottawa” who is 25 years old. The same attribute may be part of several relations. Therefore we start out with the definition of all attributes that are of relevance to the system we want to describe. Definition (attributes and their values): The set A = {a1, a2, …, am} is the set of attributes. To each attribute ai is associated a (possibly infinite) set Di of possible values that this attribute may take. Di is called the domain of the attribute ai. We define D = U Di to be the discriminate union of the Di . Definition (relation): Given a subset Ar of A, a relation R over Ar, written R[Ar], is a (possibly infinite) set of mappings T: Ar --> D with T(ai) e Di. An integrity constraint is a predicate on such mappings. If the relation R has an integrity constraint C, this means that for each T e R, C(T) is true. Note: In the informal model where a relation is represented by a table, a mapping T corresponds to a tuplet in the table. Here we consider relations that may include an infinite number of different mappings. Definition (projection): Given R[Ar] and Ax ² Ar , the projection of R[Ar] onto Ax, written projAx (R), is a relation over Ax with T e projAx (R) iff there exists T’ e R such that for all ai e Ax , T(ai) = T’(ai) We note that T is the restriction of T’ to the subdomain Ax. We also write T = projAx (T’). Definition (natural join): Given R1[A1] and R2[A2], we define the (natural) join of the relations R1 and R2 to be a relation over A1 U A2 , written R1 join R2 , with T e (R1 join R2) iff projA1 (T) e R1 and projA2 (T) e R2 Definition (chaos): Given Ar ² A, we call chaos over Ar , written Ch[Ar] , the relation which includes all elements T of Ar --> D with T(ai) e Di , that is, the union of all relations over Ar. Note: We note that Ch[Ar] is isomorphic to the Cartesian product of the domains of all the attributes in Ar . The notion of “chaos” is not common in database theory. It was introduced by Hoare [Hoar 85] to denote the most general possible behavior of a module. It was also used in several papers on submodule construction [Petr 98, Dris 99a]. It is important to note that we consider here infinite attribute value domains and relations that contain an infinite number of mappings (tuplets). In the context of traditional database theory, these sets are usually finite (although some results on infinite databases can be found in [Abit 95]). This does not change the form of our definitions, however. If one wants to define algorithms for solving equations involving such infinite relations, one has to worry about the question of what kind of finite representations should be adopted to represent these relations. The choice of such representations will determine the available algorithms and at the same time introduce restrictions on the generality of these algorithms. Some of these representation choices are considered in Sections 4 and 5.
20
G. v. Bochmann
3 Equation Solving in the Context of Relational Databases We consider here a very simple configuration with three attributes a1, a2, and a3, and three relations R1[{a2, a3}], R2[{a1, a3}], and R3[{a2, a1}] as shown in the figure below. A more general architecture has been considered in [Boch 02a].
Fig. 3.1. Configuration of 3 relations sharing 3 attributes
We consider the following equation (which is in fact an inclusion relation) proj {a2, a1} (R1 join R2 ) ² R3
(Equ. 1)
If the relations R1 and R3 are given, we can ask the question: for what relation R2 will the above equation be true. Clearly, the empty relation, R2 = • (empty set), satisfies this equation. However, this case is not very interesting. However, we note that there is always a single maximal solution. This solution is the set Sol = {T e Ch[{a1, a3}] | proj {a2, a1} (R1 join {T} ) ² R3 } (2)
(Equ. 2)
This is true because the operators of set union and intersection obey the distributive law in respect to the join operation, that is, Ri join (Rj union Rk) = ( Ri join Rj) union ( Ri join Rk); and similarly for intersection. While the above characterization of the solution is trivial, the following formula is useful for deriving algorithms that obtain the solution in the context of the specific representations discussed in Sections 4 and 5. Theorem: A solution for R2 that satisfies Equation (1), given R1 and R3 , is given by the following formula (where “/” denotes set substraction): (3)
Sol = Ch[{a1, a3}] / proj{a1, a3} ( R1 join ( Ch[{a1, a2}] / R3 ) )
(Equ. 3)
This is the largest solution and all other solutions of Equ. (1) are included in this one. Informally, Equation (3) means that the largest solution consists of all tuplets over {a1, a3} that cannot be obtained from a projection of a tuplet T [{a1, a2, a3}] that can be obtained by a join from an element of R1 and a tuplet from Ch[{a1, a2}] that is not in R3. We note that the smaller solution (3*)
Sol
= proj{a1, a3}( R1 join R3) / proj{a1, a3} (R1 join ( Ch[{a1, a2}] / R3 ) ) (Equ. 3*) (3)
is also an interesting one, because it contains exactly those tuplets of Sol that can be joint with some tuplet of R1 to result in a tuplet whose projection on {a1, a2} is in R3. (3) (3*) Therefore (R1 join Sol ) and (R1 join Sol ) are the same set of tuplets; that means the same subset of R3 is obtained by these two solutions. In this sense, these solutions are
Submodule Construction for Specifications with Input Assumptions
21
equivalent. We note that the solution formula given in [Merl 83] corresponds to the (3*) solution Sol . (3) Proof of the theorem: First we note that (T2 e Sol ) is equivalent to the statement that there exist no T e Ch [{a1, a2, a3}] such that proj{a1, a3}(T) = T2 and proj{a2, a3}(T) e R1 and proj{a1, a2}(T) ¬e R3 We call this (Equivalence 4). (3) (2) (3) (2) We have to prove that Sol = Sol . In order to show that Sol ² Sol , we show that (3) proj {a2, a1} (R1 join Sol ) ² R3 (Equ. 5) Taking any T’ e (R1 join Sol ), we have proj{a2, a3}(T’) e R1 and proj{a1, a3}(T’) e Sol . (3) Since proj{a1, a3}(T’) e Sol , there is, according to Equivalence (4), no T e Ch [{a1, a2, a3}] such that proj{a1, a3}(T) = proj{a1, a3}(T’) and proj{a2, a3}(T) e R1 and proj{a1, a2}(T) ¬e R3 . Since T’ satisfies the first two of these three conditions, we conclude that the last condition must be false for T’. Therefore we have that proj{a1, a2}(T’) e R3 which implies Equation (5). (3) (2) In order to prove that Sol ¯ Sol , we assume that this is not true and that there (2) (3) exist a tuplet T’ that is in Sol , but not in Sol . However, the latter implies, according to Equivalence (4), that there exists a T e Ch [{a1, a2, a3}] such that (3)
(3)
proj{a1, a3}(T) = T’ and T1 = proj{a2, a3}(T) e R1 and proj{a1, a2}(T) ¬e R3 (Equ. 6) def
Considering the definition of the join operation, we conclude that {T} = {T’} join {T1} since the join of two singleton relations contains at most one tuplet. But now we (2) have a contradiction because ( T’ e Sol ) implies proj{a1, a2} ({T’} join {T1}) ² R3 while Equation (6) states proj{a1, a2} ({T’} join {T1}) ¬e R3 . Therefore our assumption must be false. Q.E.D.
4
Equation Solving in the Context of Composition of Sequential Machines or Reactive Software Components
4.1 Modeling System Components and Behavior Using Traces Sequential machines and reactive software components are often represented as black boxes with ports. The ports are the places where the interactions between the component in question and the components in its environment take place. For allowing the different modules to communicate with one another, their ports must be interconnected. Such interconnection points are usually called interfaces. An example of a composition of three modules (sequential machines or reactive software components) is shown in Figure 4.1. Their ports are pair-wise interconnected at three interfaces a1, a2, and a3.
22
G. v. Bochmann
Fig. 4.1. Configuration of 3 components interconnected through 3 interfaces
The dynamic behavior of a module (sequential machine or a reactive software component) is usually described in terms of traces, that is, sequences of interactions that take place at the interfaces to which the module is connected. Given an interconnection structure of several modules and interfaces, we define for each interface i the set of possible interactions Ii that may occur at that interface. For each (finite) system execution trace, the sequence of interactions observed at the interface ai is therefore an element of Ii * ( a finite sequence of elements in Ii ). For communication between several modules, we consider in this paper rendezvous interactions. This means that, for an interaction to occur at an interface, it is necessary that all modules connected to that interface must make a state transition compatible with that interaction at that interface. In our basic communication model we assume that the interactions between the different modules within the system are synchronized by a clock, and that there must be an interaction at each interface during each clock period. We call this “synchronous operation”. 4.2 Correspondence with the Relational Database Model We note that the above model of communicating system components can be described in the formalism of (infinite) relational databases as follows: 1. A port corresponds to an attribute and a module to a relation. For instance, the interconnection structure of Figure 4.1 corresponds to the relationship shown in Figure 3.1. The interfaces a1, a2, and a3 in Figure 4.1 correspond to the three attributes a1, a2, and a3 in Figure 3.1, and the three modules correspond to the three relations. 2. If a given port (or interface) corresponds to a particular attribute ai, then the possible execution sequences Ii* occurring at that port correspond to the possible values of that interface, i.e. Di = Ii* . 3. The behavior of a module Mx is given by the tuplets Tx contained in the corresponding relation Rx [Ax], where Ax corresponds to the set of ports of Mx. That is, a trace tx of the module X corresponds to a tuplet Tx which assigns to each interface ai the sequence of interactions sxi observed at that interface during the execution of @t this trace. We write sxi to denote the t-th element of sxi Since we assume “synchronous operation” (as defined in Section 4.1), all tuplets in a relation describing the behavior of a module must satisfy the following constraint: Synchrony constraint: The length of all attribute values are equal. (This is the length of the trace described by this tuplet.)
Submodule Construction for Specifications with Input Assumptions
23
4.3 The Case of Synchronous Finite State Machines If we restrict ourselves to the case of regular behavior specifications, where the (infinite) set of traces of a module can be described by a finite state transition model, we can use Equation (3) or Equation (3*) to derive an algorithm for equation solving. In this case, the behavior specification for a module is given in the form of a finite state automaton (similar to labeled transition systems) where each transition is labeled by a set of interactions, one for each port of the module. We note that the synchronous composition considered here is different than the synchronous composition of Mealy or Moore machines, as considered in [Kim 97] since the latter distinguish between input and output, as discussed in Section 5. (It appears that the complete version of [Yevt 01a] also deals with this synchronous case). The algorithm for equation solving is obtained from Equation (3) or Equation (3*) by replacing the relational database operators projection, join and substraction by the corresponding operations on finite state automata. The database projection corresponds to eliminating those interaction labels from all transitions of the automaton which correspond to attributes that are not included in the set of ports onto which the projection is done. This operation, in general, introduces nondeterminism in the resulting automaton. The substraction operation is of linear complexity if its two arguments are deterministic finite state automata. Since the projection operator introduces nondeterminism, one has to include a step to transform the nondeterministic automata obtained from the projection into its equivalent deterministic form. This step is in general of exponential complexity. However, our experience with some examples involving the interleaved semantics described below [Dris 99a] indicates that reasonably complex systems can be handled in many cases. The well-known algorithm for performing this step consists of building a deterministic automata which has as its states the possible subsets of states (of the original automaton) that are reachable after a given trace of interactions. In fact, the substraction operations involved in Equation (3) are of a special form; they represent the construction of the complement. This is a simple operation for a deterministic automaton. In a first step, the automaton is completed, that is, an additional (non-accepting) state, called fail state, is introduced, and from each state of the automaton additional transitions are created from the state to the fail state for all those interaction labels for which the original automaton has no transition from that state. There is also a self-loop on the fail state for all possible interaction labels. This first step does not change the traces of interactions accepted by the automaton. The second step performs the complement by exchanging the accepting and non-accepting states. The join operation corresponds to the composition operator of automata which is of polynomial complexity. In the case of the synchronous operation considered here, the composition is defined as follows. Synchronous composition: Given two automata R1 [a1, a3] and R2 [a2, a3] with sets of states S1 and S2, respectively, and transitions written si – x, y --> si’ with si and si’ e Si, for i = 1, 2, and where x and y are interactions at the two ports of the automaton in question. The synchronous composition of these two automaton is an automaton R [a1, a2, a3] which is defined as follows: The states of R are of the form (s1, s2) where s1 e S1 and s2 e S2; the initial state is the pair of the initial states of the R1 and R2, and a state (s1, s2) is accepting if s1and s2 are accepting in their respective automata.
24
G. v. Bochmann
R3 includes a transition (s1, s2) – x, y, z --> (s1’, s2’) iff the transitions s1 – x, z --> s1’ and s2 – y, z --> s2’ exist in their respective automata. The composition of two automata can be easily constructed by starting from the initial state and constructing all states of the composition that are reachable. Figure 4.2 shows a simple example. R3 and R1 are given. The note “Notation (x1,x2)” for R3 means that the transition labels of R3 first contain the interaction at interface a1 and then at a2. The submodule construction algorithm proceeds as follows: First R3 is completed with the introduction of a fail state, then the product with R1 is constructed. When the interations at the interface a2 are projected out, there is nondeterminism in state (2,2) for the label (n,n,d). This leads to a determinized automaton. From this automaton, all traces leading to a state containing fail should be eliminated. This leads to the elimination of the transition (n,n) from state ((4,3), (5,3)), but then also the transition leading to this state is eliminated since this state represents a deadlock. (Deadlock elimination is not further considered here).
Fig. 4.2. Example of submodule construction for synchronous automata
4.4 The Case of Interleaving Rendezvous Communication In this subsection, we consider non-synchronous rendezvous communication also called interleaving semantics, were at each instant in time at most one interaction takes place within all interconnected system components. This communication paradigm is used, for instance, with labeled transition systems (LTS), CSP and LOTOS.
Submodule Construction for Specifications with Input Assumptions
25
One way to model the behavior of such systems is to consider a global execution trace which is the sequence of interactions in the order in which they take place at the different interfaces (one interface at a time). Each element of such an execution sequence defines the interface ai at which the interaction occurs and the interaction vi which occurs at that interface. Another way to represent the behavior of such systems is to reduce it to the case of synchronous communication as follows. This is the approach which we adopt in this paper because it shows how the interleaving rendezvous communication can be based on our relational database model. In order to model the interleaving semantics, we postulate that all sets Ii include a dummy interaction, called null. It represents the fact that no interaction takes place at the interface. We then postulate that each tuplet T of a relation R[A] satisfies the following constraint: Interleaving constraint: For all time instants t (t > 0) we have that T(ai)[t] • null implies T(aj)[t] = null for all aj e A (j • i) We note that tuplets that are equal to one another except for the insertion of time periods during which all interfaces have the null interaction are equivalent as far as the sequence of non-null interactions is concerned. Note that this equivalence is sometimes called stuttering equivalence. In the following we are only interested in equivalent classes in respect to this stuttering equivalence. Such a class may be represented by the interaction sequence in the class that has no time instance with null interactions at all interfaces. We say that such an interaction sequence is of “normal form”. We also assume that each relation contains, with each sequence of interactions, also all other sequences that are stuttering equivalent to it. We call this the stuttering completeness assumption. The relational database operators projection and substraction apply under the interleaving constraint in the normal way. However, the result obtained by the joining of two relations satisfying the interleaving constraint may include tuplets that do not satisfy this constraint, because the joint interaction sequences may have non-null interactions at the same time at different interfaces. We assume that such sequences not satisfying the interleaving constraint will be eliminated from the original result of the join. However, because of the stuttering completeness assumption, there will also be an interaction sequence in the original join results which contains the conflicting interactions at different time instants. Therefore the result of a join will include all the interleavings of the non-null interactions as far as they are conform with each of the joint relations. We can therefore conclude that the interleaving semantics defined here corresponds exactly to the well-known interleaving semantics of labeled transition systems. 4.5 The Case of Finite Labeled Transition Systems To simplify the notation, we assume that the sets of interactions at different interfaces are disjoint (i.e. Ii intersection Ij = empty for ai • aj), and we introduce the overall set of interactions I = U(ai e A) Ii. Then a class of stuttering equivalent interleaving traces (as described in Section 4.4) corresponds one-to-one to a sequence of interactions in I. If we restrict ourselves to the case where the possible traces of a module are described by a finite LTS, the resulting set of possible execution sequences are regular
26
G. v. Bochmann
sets. In fact, a finite LTS is a finite state automaton with only accepting states. Therefore the operations projection, and substraction over interleaving traces can be represented by finite operations over the corresponding automata representations, as in the case of synchronous operation discussed in Section 4.4. Again, the projection may introduce nondeterminism (in the form of spontaneous transitions, sometimes written with label i) and a determination step is required before the substraction operation. Finally, the join operation represents the composition of LTSs and is defined as follows: Interleaved composition: Given two automata R1 [a1, a3] and R2 [a2, a3] with sets of states S1 and S2, respectively, and transitions written si – x --> si’ with si and si’ e Si, for i = 1, 2, and where x is an interaction at one of the two ports of the automaton in question. The interleaved composition of these two automaton is an automaton R [a1, a2, a3] which is defined as follows: The states of R are of the form (s1, s2) as for synchronous composition. R3 includes a transition (s1, s2) – x --> (s1’, s2’) iff one of the following conditions is satisfied: - x e I1 and s1 – x --> s1’ and s2 = s2’ - x e I2 and s2 – x --> s2’ and s1 = s1’ - x e I3 and s1 – x --> s1’ and s2 – x --> s2’ The submodule construction algorithm defined by Equation (3*) based on the operations on automata described above is equal to the construction algorithm that we described earlier [Boch 80d, Merl 83]. The proof of correctness of Equation (3) given in Section 3 also provides a proof of this algorithm. The example of Figure 4.2 may be considered as an example for interleaving semantics. In fact, the specification has the particular form that, if we consider the interaction written “n” as the null interaction, then all the specifications in the figure satisfy the interleaving constraint.
5 Distinction of Input and Output 5.1 Module Specification Based on Hypothesis and Guarantees The rendezvous communication paradigm considered in Section 4 has a drawback when it comes to its use for requirements specification. Usually, the requirements for a system module has two parts: (a) the hypothesis that the module may make about the behavior of the other modules within its environment and general operating assumptions such as temperature ranges etc., and (b) the guarantees that the module must provide concerning the behavior it will exhibit during execution. The distinction between these two aspects cannot be made clearly with the rendezvous communication paradigm because for any interaction to occur, it is necessary that all participating modules are ready for it. There is no notion that one of the modules is particularly responsible for initiating the interaction. We consider in the following a communication paradigm where, for each interaction taking place at some interface, there is one participating module for which the interaction is output, and it is input for all other modules that are connected to that
Submodule Construction for Specifications with Input Assumptions
27
interface. Whether the interaction will take place or not, and what its parameters will be, will solely be determined by the outputting module (the interaction must satisfy the guarantees provided by this module). The other participating modules for which the interaction is input do not influence the occurrence of the interaction and the values of its parameters. However, they may make the hypothesis that the outputting modules will satisfy the guarantees defined by their respective specifications, thus limiting the range of possibilities for receiving the interaction in question. This paradigm is the basis for the semantics of (input-output) finite state machines, Input/Output Automata (IOA) [Lync 89], as well as many software specification formalisms, such as [Adab 95, Misr 81]. It seems that this paradigm also subsumes the paradigm of controllable and uncontrollable interactions as considered for discrete event control design [Rama 89]. We note that in the case of finite state machines and IOA, we consider partially defined machines; the hypothesis is made that only those inputs will occur for which a transition is defined. We can introduce the distinction between input and output in our general relational database formalism as follows: Each attribute of a relation is marked as either input or output. An attribute of a relation resulting from a join operation is marked input if the same attribute is marked as input in the two operands of the join operation, otherwise it is marked output. A join operation is said to have output conflict if there is an attribute that is marked output for both operands. We consider in the following only join operations without output conflict. We now introduce the following notations. Given a relation R[AR] and a tuplet T e |t R, we write T for the tuplet which has as values for an attribute ai e AR the prefix (of length t) of the value which T has for this attribute. For example, if T = |2 @t then T = . And we write T for the tuplet which has as value for an attribute ai e AR the t-th element of the sequence which is the value of T for this attribute.For @1 @3 the example of T above, we have T = and T = . Similarly, we write @t T (ai) to denote the t-th element of T(ai). In order to clearly distinguish between the input and output attributes of a relation I O I O R, we write R[AR | AR ] where ai e AR are the input attributes of R and ai e AR the attributes marked output. 5.2 Conformance Relations In trace semantics without the distinction of input and output, as discussed in Section 4, the conformance relations are very simple and can be summarized by the following definitions: 1. Valid trace: A tuplet (trace) T is valid in respect to a relation (specification) R if T e R. 2. Trace inclusion: A specification R’ conforms to a specification R iff all the traces of R’ are also valid in respect to R. In order to define meaningful relations in the context of synchronous operation, we assume that a specification satisfies the constraint that the output allowed at time t by the specification does not depend on the input received at time t (but only on previous inputs and outputs). This implies that a delay of at least one time unit exists between a
28
G. v. Bochmann
received input and the output which is caused by this input. The importance of this assumption is discussed in [Abad 95, Broy 95]. In addition, we assume that the hypothesis made by a specification about the validity of the received input at a given time instance does not depend on the output selected by the module at the same time instance. We call these two assumptions together the unit-delay constraint (UDC), which can be formally defined as follows: 1. Given a trace specifications R[AR] and a tuplet T e R, we write next(T, R) for the relation that describes the possible interactions at the next time instant, formally: T’ e next(T, R) iff the tuplet T’ is of length one and T.T’ e R, where “.” denotes the pairwise concatenation of corresponding attribute values. I O 2. A trace specification (relation) R[AR | AR ] satisfies the UDC iff for any T e R the following holds: next(T, R) = proj A (next(T, R)) join proj A (next(T, R)) I
R
O
R
For characterizing conformance relations, it is important to distinguish different cases of invalid traces. If a given trace (tuplet) T is not valid in respect to a given trace I O specification (relation) R[AR | AR ] (i.e. not T e R), we may consider the longest |t-1 @t valid prefix of T; there must exist a time instant t > 0 such that T e R and T ¬e |t-1 next(T , R) (we use the notation where ¬e means "not included in"). We now can distinguish whether the invalidity of the trace is caused by a wrong input or a wrong output at time instant t as follows: WO(t) |t- Wrong output: We say that T has wrong output at time t, written T e R , iff T 1 @t |t-1 e R and proj A T ¬e proj A next(T , R). WI(t) - Wrong input: We say that T has wrong input at time t, written T e R , iff |t-1 @t |t-1 T e R and proj A T ¬ e proj A next(T , R). O
O
R
R
I
R
I
R
Clearly, it could also happen that T has wrong input and wrong output at time t. Based on the above definitions, we can now formally define the meaning of a I O component specification R[AR | AR ] (similar to [Abad 94]) as follows: I O 1. A trace T over the alphabet A = AR U AR satisfies the guarantees of R, written T |t-1 WO(t) satG R, iff for all t > 0 the following holds: T e R implies T ¬ e R . 2. A trace T over A satisfies the hypotheses of R, written T satH R, iff for all t > 0 |t-1 WI(t) the following holds: T e R implies T ¬ e R . 3. A trace T over A satisfies the specification R, written T sat R, iff (T satH R) implies (T satG R) I O 4. A trace T over an arbitrary (larger) alphabet satisfies the specification R[AR | AR ] I O iff the projection of T onto A = AR U AR satisfies R. 5. Given an interconnection structure containing several components with their respective behavior specifications Rk (i = 1, 2, …, n), we say that a trace T satisfies the interconnection structure iff it satisfies the specifications of all component specifications Rk . I O I O 6. Another specification R’[AR | AR ] conforms to R[AR | AR ] iff for all traces T we have (T sat R’) implies (T sat R).
Submodule Construction for Specifications with Input Assumptions
29
5.3 Equation Solving for Specifications with Hypothesis and Guarantees Taking into account the difference between input and output as discussed above, the problem of equation solving must be formulated in a form different from Equation (1) in Section 3. Now we want to find the most general specification for R2 such that all traces that satisfy the interconnection structure of the modules R1 and R2 (see Figure 5.1), and that also satisfy the hypothesis of R3, have the following two properties: (a) the guarantees of R3 are satisfied, and (b) the hypotheses of R1 are satisfied.
Fig. 5.1. Composition of components R1 and X with input/output interactions
This can be formalized as follows. We first note that we consider the alphabet A = O I O I O I A31 U A31 U A32 U A32 U A12 U A12 , as shown in the figure. We introduce the following abbreviations for the alphabets of the modules R1, X and R3, respectively: O I O I A1 = A31 U A31 U A12 U A12 , O I O I A2 = A32 U A32 U A12 U A12 , O I O I A3 = A31 U A31 U A32 U A32 . O O We also note that the elements of (A31 U A12 ) are the outputs of R1, the other O I elements of A1 are its inputs, A32 U A12 are the outputs of X, the other elements of O O A2 are its inputs, and A31 U A32 are the outputs of R3, the other elements of A3 are its inputs. Given two relations R1 and R3 , the equation solving problem, now, consists of IO finding a set of traces X[A2] which satisfies Equation (1 ) below: IO
projA3 (R1 join X) conforms to R3 Theorem: The set of traces Sol IO fying Equation (1 ):
(IO)
IO
defined by Equation (3 ) is the largest set satis-
(IO)
Sol
(Equ. 1 )
IO
= Ch[A2] / projA2 Ut>0 ( (Equ. 3 ) T WO(t) T WO(t) T WO(t) WO(t) (R1 join R3 ) U ( ( R1 ) join R3 ) U ( ( R1 ) join R3 ) ) T
where the notation R denotes the relation R with the input/output markings of the ports interchanged. T
WO(t)
We note that the traces in ( R1 ) are the same (if one ignores the input/output WI(t) assignment) as the traces in R1 , that is, these are the traces that do not satisfy the
30
G. v. Bochmann
hypothesis that R1 makes about the input interactions. The proof of the above theorem is given in [Boch 01b]. 5.4 The Case of Completely Defined and Deterministic Finite State Machines Submodule construction for deterministic, completely defined finite state machines is discussed in detail in Chapter 6 of [Kim 97]. Our above assumption of the unit-delay constraint corresponds to the assumption of Moore machines for which the output is a function of the current state. [Kim 97] mainly considers deterministic machines (for which the output is a function of the present state and the input) which are completely defined, that is, in each state and each input there is a specified next state and output; IO therefore there is no wrong input. Under these assumptions, Equation (3 ) becomes (IO)
Sol WO
T
WO(t)
= Ch[A2] / projA2 Ut>0 (R1 join R3 T WO = Ch[A2] / projA2 (R1 join R3 )
)
WO(t)
where R3 = Ut>0 R3 . This formula is quite similar to Equation (3) in which (Ch[{a1, a2}] / R3 ) represents all non-allowed traces, while here these traces are repreWO sented by R3 . Correspondingly, the only difference in the submodule construction algorithm for the completely defined FSMs that we are interested here and the algorithm described in Section 4.3 is the way the R3 is completed with the introduction of a fail state. Here we introduce transitions to the fail state from each normal state of the FSM and each input for all output values that are different from the original definition of the FSM. The resulting submodule construction algorithm is essentially identical to the algorithm described in Chapter 6.3.1 of [Kim 97]. However, in our approach we allow for incompletely defined solutions if the behavior for certain states and inputs needs not be defined because such inputs will never happen. We therefore do not introduce explicitly the “{}” state used in [Kim 97]. As an example, we consider the specifications given in Figure 6.5 in [Kim 97] (space limitations do not allow us to give details here). The inputs and outputs labeled x, v, u, z in [Kim 97] correspond to the ports I I O O O A31 , A12 , A12 , and A31 , respectively, in Figure 5.1. The interactions at the ports A32 , I and A32 do not exist. The completion of the automaton M leads to the following transitions to the fail state: from state A under “1/0” and “0/1”; from state B under “0/0” and “1/0”. Applying the algorithm described above leads to the same automaton as the one shown in Figure 6.6 in [Kim 97], except for the “{}” state. Since Kim’s example does not satisfy the unit-delay constraint, we note that the algorithm described above worksin this case, even though the unit-delay constraint is not satisfied. It is not clear how far the unit-delay assumption may be weakened. 5.5 The Case of Interleaving Semantics In the case of interleaving semantics, there is at each time instant only a real interaction at one of the interfaces, while the other interfaces have the null interaction. In this context, the situation of wrong input is often called "unspecified reception" [Zafi 80]. In this case, there can never be a time instant with wrong input for R1 and wrong T WO(t) WO(t) IO output for R3. Therefore the term ( R1 ) join R3 ) in Equation (3 ) of the theo-
Submodule Construction for Specifications with Input Assumptions
31
rem in Section 5.3 is empty and can be dropped. Therefore the equation can be simplied, similarly as in the subsection above, to the form (IO)
Sol
T
= Ch[A2] / projA2 Ut>0 ( (R1 join R3 T
= Ch[A2] / projA2 ( (R1 join R3
WO
WO(t)
T WO(t)
) U ( ( R1 ) T WO
) U ( ( R1 )
join R3 )
)
join R3 ) )
If we now consider the case of regular behaviors specified in terms of finite state automata, we come to consider IO-Automata [Lync 89] as finite representation of the regular behaviors. The submodule construction algorithm derived from the above equation is similar to the one for labeled transition systems considered in Section 4.4, except that we have now two classes of non-allowed traces, those giving rise to wrong behavior in respect to R3 and those giving rise to non-expected input to R1 . We therefore introduce a fail state not only in R3 but also in R1 , and all traces in the deterT minized projected product of R1 and R3 that lead to one of these fail states must be eliminated. We note this algorithm is essentially identical to the algorithm described in Section 5 of [Dris 99a]. 5.6 Algorithm for the General Synchronous Case If we consider regular specifications in the general case of synchronous communicaIO tion described in Section 5.3, Equation (3 ) gives rise to a submodule construction algorithm very similar to the one described in Section 5.5. The main difference is that the synchronous composition operation is used. Again, we have to introduce fail states for R3 and R1. After forming the product, the projection and the determinization, we have to eliminate all transitions that lead to a state of the determinized specification that contains the fail state of either R3 or R1, and transitions that lead to a state that contains both. Note that the text in italics takes care of the last term T WO(t) WO(t) IO “((R1 ) join R3 )” in Equation (3 ).
6 Conclusions The problem of submodule construction (or equation solving for module composition) has some important applications for the real-time control systems, communication gateway design, and component re-use for system design in general. Several algorithms for solving this problem have been developed based on particular formalisms that were used for defining the dynamic behavior of the desired system and the existing submodule. In this paper, we have shown that this problem and its solution can also be formulated in the context of relational databases. The main result of this paper is to show that many submodule construction algorithms that have been proposed for different specification paradigms based on finite automata can be derived from this solution of the submodule construction problem within the context of relational databases. In fact, a set-theoretical formulation of this problem has been given in this context and solution formulas have been provided for two cases: (a) when there is no notion of input-output and trace inclusion is taken as conformance relation, and (b) when partial specifications with distinction of input –
32
G. v. Bochmann
output and more complex conformance relations are considered. In both cases, synchronous communication as well as interleaving semantics may be considered. The solution formula for the case of input-output distinction is new and the corresponding submodule construction algorithm for the corresponding case of general synchronous automata is also new. In this paper we only consider trace semantics. The considerations of deadlocks and finer conformance relations based on progress or liveness are not considered here. Some references to work in that area are given in [Boch 02a]. Acknowledgements. I would like to thank the late Philip Merlin with whom I started to work in the area of submodule construction. I would also like to thank Nina Yevtushenko (Tomsk University, Russia) for many discussions about submodule construction algorithms and the idea that a generalization of the concept could be found for different behavior specification formalisms. I would also like to thank my former colleague Cory Butz for giving a very clear presentation on Bayesian databases which inspired me the database generalization described in Section 3 in this paper. Finally, I would like to thank my former PhD students Z.P. Tao and Jawad Drissi whose work contributed to my understanding of this problem.
References [Abad 95] M. Abadi and L. Lamport, Conjoining specifications, ACM Transactions on Programming Languages & Systems, vol.17, no.3, May 1995, pp. 507–34. [Abit 95] S. Abiteboul, R. Hull and V. Vianu, Foundations of Databases, Add.-Wesley, 1995. [Boch 80d] G. v. Bochmann and P. M. Merlin, On the construction of communication protocols, ICCC, 1980, pp.371-378, reprinted in "Communication Protocol Modeling", edited by C. Sunshine, Artech House Publ., 1981; russian translation: Problems of Intern. Center for Science and Techn. Information, Moscow, 1981, no. 2, pp. 146–155. [Boch 01b] G. v. Bochmann, Submodule construction - the inverse of composition, Technical Report, Sept. 2001, University of Ottawa. [Boch 02a] G. v. Bochmann, Submodule construction and supervisory control: a generalization, to appear in Proc. of Int. Conf. on Implementation and Applications of Automata (invited paper), August 2001, Pretoria, South Africa, to be published as Springer Lecture Notes. [Broy 95] M. Broy, Advanced component interface specification, Proc. TPPP'94, Lecture Notes in CS 907, 1995, pp. 369–392. [Dris 99a] J. Drissi and G. v. Bochmann, Submodule construction tool, in Proc. Int. Conf. on Computational Intelligence for Modelling, Control and Automation, Vienne, Febr. 1999, (M. Mohammadian, Ed.), IOS Press, pp. 319–324. [Dris 00] J. Drissi and G. v. Bochmann, Submodule construction for systems of timed I/O automata, submitted for publication, see also J. Drissi, PhD thesis, Univ. of Montreal, March 2000 (in French). [Hagh 99] E. Haghverdi and H. Ural, Submodule construction from concurrent system specifications, Information and Software Technology, Vo. 41 (1999), pp. 499–506. [Hoar 85] C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall, 1985. [Kele 94] S. G. H. Kelekar, Synthesis of protocols and protocol converters using the submodule construction approach, Proc. PSTV, XIII, A. Danthine et al (Eds), 1994.
Submodule Construction for Specifications with Input Assumptions
33
[Kim 72] J.Kim, and M.M.Newborn, The simplification of sequential machines with input restrictions, IRE Trans. on Electronic Computers. December, 1972, pp. 1440–1443. [Kim 97] T.Kim, T.Villa, R.Brayton, A.Sangiovanni-Vincentelli. Synthesis of FSMs: functional optimization. Kluwer Academic Publishers, 1997. [Lync 89] N. A. Lynch and M. R. Tuttle, An introduction to input/output automata, CWI Quarterly, 2(3), 1989, pp. 219–246. [Maie 83] D. Maier, The Theory of Relational Databases, Computer Science Press, Rockville, Maryland, 1983. [Merl 83] P. Merlin and G. v. Bochmann, On the Construction of Submodule Specifications and Communication Protocols, ACM Trans. on Programming Languages and Systems, Vol. 5, No. 1 (Jan. 1983), pp. 1–25. [Misr 81] J. Misra and K. M. Chandy, Proofs of networks of processes, IEEE Tr. on SE, Vol. SE-7 (July 1991), pp. 417–426. [Parr 89] J. Parrow, Submodule Construction as Equation Solving in CCS, Theoretical Computer Science, Vol. 68, 1989. [Petr 96a] A. Petrenko, N. Yevtushenko, G. v. Bochmann and R. Dssouli, Testing in context: framework and test derivation, Computer Communications Journal, Special issue on Protocol engineering, Vol. 19, 1996, pp.1236–1249. [Petr 98] A. Petrenko and N. Yevtushenko, Solving asynchronous equations, in Proc. of IFIP FORTE/PSTV'98 Conf., Paris, Chapman-Hall, 1998. [Qin 91] H. Qin and P. Lewis, Factorisation of finite state machines under strong and observational equivalences, J. of Formal Aspects of Computing, Vol. 3, pp. 284–307, 1991. [Rama 89] P. J. G. Ramadge and W. M. Wonham, The control of discrete event systems, in Proceedings of the IEEE, Vo. 77, No. 1 (Jan. 1989). [Yevt 01a] N.Yevtushenko, T.Villa, R.Brayon, A.Petrenko, A.Sangiovanni-Vincentelli. Synthesis by language equation solving (exended abstract), in Proc.of Annual Intern.workshop on Logic Synthesis, 2000, 11–14; complete paper to be published in ICCAD’2001; see also Solving Equations in Logic Synthesis, Technical Report, Tomsk State University•• •,•1999, 27 p. (in Russian). [Zafi 80] P. Zafiropulo, C. H. West, H. Rudin and D. D. Cowan, Towards analyzing and synthesizing protocols, IEEE Tr. Comm. COM-28, 4 (April 1980), pp. 651–660.
%QPITWGPV 9GCM %QPHQTOCPEG, C 2CTVKCN 1TFGT COQPI 2TQEGUUGU 4QPCNF 9. $TQYGT 1 and -GPPGVJ 5. 5VGXGPU 2 1
#KT (QTEG 4GUGCTEJ LCDQTCVQT[, ©ODGFFGF +PHQTOCVKQP 5[UVGOU ©PIKPGGTKPI $TCPEJ 9TKIJV CVVGTUQP #KT (QTEG $CUG, ýJKQ üûü33ÿ733ü, ú5#
[email protected] 2 +PVGN %QTRQTCVKQP, 5VTCVGIKE %#& LCDU þQTVNCPF, ýTGIQP, ú5#
[email protected] #DUVTCEV. 6JKU RCRGT RTGUGPVU C PGY RTQRGTV[ DGVYGGP RTQEGUUGU CTKUKPI HTQO C UGV QH TGNCVKQPU ECNNGF YGCM EQPHQTOCVKQPU. 6JG NCTIGUV, ECNNGF YGCM EQPHQTÿ OCPEG, KU CPCNQIQWU VQ /KNPGT•U QDUGTXCVKQPCN GSWKXCNGPEG. úPNKMG QDUGTXCÿ VKQPCN GSWKXCNGPEG, JQYGXGT, YGCM EQPHQTOCPEG KU PQV CP GSWKXCNGPEG DWV TCVJGT C RTGQTFGT DGVYGGP RTQEGUUGU. LKMG VJG RTGXKQWU RTQRGTV[ QH NQIKE EQPÿ HQTOCPEG, YGCM EQPHQTOCPEG CNNQYU DGJCXKQTU KP VJG KORNGOGPVCVKQP VJCV CTG WPTGCEJCDNG KP VJG URGEKHKECVKQP. úPNKMG NQIKE EQPHQTOCPEG, JQYGXGT, YGCM EQPHQTOCPEG GZRNQKVU QWVRWV EQPEWTTGPEKGU CPF CNNQYU KPVGTNGCXKPI QH GZVTCPGÿ QWU QWVRWV CEVKQPU KP VJG KORNGOGPVCVKQP. (KPCNN[, TGCUQPCDNG TGUVTKEVKQPU KP %%5 U[PVCZ UVTGPIVJGP YGCM EQPHQTOCPEG VQ C RTGEQPITWGPEG. 6JG TGUWNVKPI RTQRGTV[, EQPITWGPV YGCM EQPHQTOCPEG, HQTOU C RCTVKCN QTFGTKPI COQPI RTQEÿ GUUGU. #U C RTGEQPITWGPEG, KV OQFGNU UCHG UWDUVKVWVKQP QH JCTFYCTG.
ÿ +PVTQFWEVKQP 9JGP OQFGNKPI VJG EQORNKCPEG QH CP KORNGOGPVCVKQP VQ C URGEKHKECVKQP, VJG U[OOGÿ VT[ KPJGTGPV KP CP GSWKXCNGPEG KU GZEGUUKXGÑC HCEV YGNN MPQYP VQ NQIKUVKEKCPU YJQ CVVGORV VQ TGRNCEG FKUEQPVKPWGF RCTVU. (KTUV QH CNN, +ùý RKPU KP GZEGUU QH VJQUG URGEKÿ HKGF CTG EGTVCKPN[ VQNGTCDNG KP VJG KORNGOGPVCVKQP. 5GEQPFN[, WPURGEKHKGF DGJCXKQTU KP VJG KORNGOGPVCVKQP CTG CNUQ VQNGTCDNG YJGP VJG[ TGUKFG KP VJG WPTGCEJCDNG UVCVG URCEG. (WTVJGTOQTG, VJG URGEKHKECVKQP OC[ RTQXKFG CP output concurrency YJGTG OWNVKRNG QWVRWV GXGPVU CTG RTQFWEGF YKVJQWV KPVGTNGCXKPI KPRWV, CPF VJG QTFGT QH GXGPVU KU WPÿ KORQTVCPV. 5WEJ EQPEWTTGPE[ KU EJCTCEVGTK\GF D[ DTCPEJKPI DGJCXKQT VJCV EQPXGTIGU YJGP CNN QWVRWVU JCXG QEEWTTGF. 6JG KORNGOGPVCVKQP KU HTGG VQ TGCNK\G jWUV QPG RCVJ VJTQWIJ CP QWVRWV EQPEWTTGPE[. ©ZRNQKVKPI UWEJ QWVRWV QRVKQPU NGCFU VQ OQTG GHHKÿ EKGPV FGUKIPU. 6JG UCOG KU PQV VTWG HQT KPRWV EQPEWTTGPEKGU, YJGTG VJG KORNGOGPVCÿ VKQP OWUV TGOCKP RQKUGF VQ CEEGRV CNN KPRWV KPVGTNGCXKPIU FGHKPGF D[ VJG URGEKHKECVKQP. ©ZCORNGU QH JCTFYCTG GSWKXCNGPEGU CDQWPF =ü, û, 8, 10, 12, 13, 1øÿ23, 2÷?. *QYÿ GXGT, TCVJGT VJCP C U[OOGVTKE GSWKXCNGPEG TGNCVKQP, CP CU[OOGVTKE RTGQTFGTKPI COQPI RTQEGUUGU KU UWIIGUVGF HQT OQFGNKPI EQORNKCPEG.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 34-49, 2002. Springer-Verlag Berlin Heidelberg 2002
Congruent Weak Conformance
35
©ZCORNGU QH RTGQTFGT TGNCVKQPU CNUQ CRRGCT KP VJG NKVGTCVWTG. 6JG efficiency CPF divergence RTGQTFGTU ETGCVG CP QTFGTKPI DCUGF QP VJG COQWPV QH KPVGTPCN EQORWVCVKQP VJCV RTQEGUUGU RGTHQTO =2, 3, 1û?. 6JG faster-than RTGQTFGT CUUQEKCVGU YQTUGÿECUG GZGEWVKQP VKOGU YKVJ CEVKQPU, CPF VJGP QTFGTU RTQEGUUGU DCUGF QP URGGF =17?. #NN VJTGG RTGQTFGTU ETGCVG CP QTFGTKPI COQPI QDUGTXCVKQPCNN[ GSWKXCNGPV RTQEGUUGU, DWV VJG[ CTG WPFGHKPGF FGHKPGF DGVYGGP < ENCUUGU. ýVJGT TGUGCTEJGTU PQVG VJCV C RTQEGUU•U VTCPUKVKQP ITCRJ ETGCVGU CP QTFGTKPI COQPI s KVU FGTKXCVKXGU =1, ÷, 7, ø?. +H C VTCPUKVKQP P b Q GZKUVU VJGP P > Q. 6JGUG causal QT derivational RTGQTFGTU [KGNF CP QTFGTÿQHÿQEEWTTGPEG, DWV FQ PQV ECRVWTG VJG FGUKTGF KORNGOGPVCVKQPÿVQÿURGEKHKECVKQP TGNCVKQPUJKR, VJCV UJQWNF CRRN[ CV KPUVCPVU QH VKOG. 6JG quiescent RTGQTFGT EQORCTGU QPN[ SWKGUEGPV UVCVGUÑVJQUG VJCV QPN[ CEEGRV KPÿ RWVU =2ü?. 6JKU RTGQTFGT KU WPFGHKPGF QXGT VJG OCP[ KPVGTOGFKCVG UVCVGU ECRCDNG QH QWVRWV QT KPVGTPCN CEVKQP. #NN TGSWKTGF QWVRWVU OWUV DG É[KGNFGFÌ D[ VJG KORNGOGPVCÿ VKQP, UQ VJG SWKGUEGPV RTGQTFGT FQGU PQV GZRNQKV QWVRWV EQPEWTTGPE[. 6JG may CPF must RTGQTFGTU CTG DCUGF QP testing UGOCPVKEU ö11:%JCRVGT 2), CPF CTG FGHKPGF D[ UGV EQPVCKPOGPV. P "OC[ Q KH CNN VJG VGUVU P OC[ RCUU CTG EQPVCKPGF KP VJQUG Q OC[ RCUU öCPF UKOKNCTN[ HQT "OWUV). *QYGXGT, VJG VGUVKPI UGOCPVKEU FKUEKRNKPG KU YGCMGT VJCP DKUKOWNCVKQP =2÷? CPF VJGTGHQTG WPFGUKTCDNG CU C EQPHQTOCPEG RTGQTFGT. 6JKU RCRGT KPVTQFWEGU C PGY RTGQTFGT, congruent weak conformance, VJCV ECRVWTGU KPVWKVKXG KFGCU IQXGTPKPI VJG KORNGOGPVCVKQPÿVQÿURGEKHKECVKQP TGNCVKQPUJKR. %QPITWGPV YGCM EQPHQTOCPEG KU DGKPI WUGF KP TGUGCTEJ VQ NKPM UKOWNCVKQPÿDCUGF JCTFYCTG FGÿ UETKRVKQP NCPIWCIGU UWEJ CU õ*&L =1÷? VQ RTQEGUU CNIGDTCU UWEJ CU VJG %CNEWNWU QH %QOOWPKECVKQP 5[UVGOU ö%%5) =1ø?. 5WEJ C NKPM YKNN CNNQY UVTKEVGT XGTKHKECVKQPU QH õ*&L OQFGNU DCUGF QP VJG DKUKOWNCVKQP UGOCPVKEU QH %%5. 6JG FGXGNQROGPV QH EQPITWGPV YGCM EQPHQTOCPEG TGUGODNGU /KNPGT•U FGXGNQRÿ OGPV QH observational congruence =1ø:%JCRVGTU û CPF 7?. +P VJKU CPCNQI[, weak bisimulations CTG TGRNCEGF YKVJ C UGV QH weak conformations. 9JGTGCU VJG NCTIGUV YGCM DKUKOWNCVKQP KU observational equivalence VarId . sort DataExp . subsort VarId < DataExp . *** A LOTOS variable is a data expression. subsort Bool < DataExp . *** Booleans are a predefined data type. endfm fmod LOTOS-SYNTAX is protecting DATAEXP-SYNTAX . sorts SortId GateId ProcId . op S : Qid -> SortId . op G : Qid -> GateId . op P : Qid -> ProcId . sort BehExp . op stop : -> BehExp . op exit(_) : ExitParam -> BehExp . op _;_ : Action BehExp -> BehExp [prec 35] . op _[]_ : BehExp BehExp -> BehExp [prec 40] . op _|[_]|_ : BehExp GateIdList BehExp -> BehExp . op hide_in_ : GateIdList BehExp -> BehExp [prec 40] . [. . .] endfm
2.2
LOTOS Symbolic Semantics
First, we define Contexts, which are used to keep the definitions of processes introduced in a LOTOS specification. In order to execute a process instantiation, the process definition has to be looked for in the context. The actual context is built when the LOTOS specification is entered to the tool (we will see how it is done in Section 4.1). In the semantics, a constant context is assumed, and it represents the collection of process definitions. We could say that the semantics is parameterized over this constant, that will be instantiated when a concrete specification is used. fmod CONTEXT is protecting LOTOS-SYNTAX . sort Context . op context : -> Context . [. . .] endfm
Now, we can implement the LOTOS symbolic semantics. First we show some operations used in the semantics definition that present problems when implementing them, and how we have solved these problems in Maude. In the semantics, a set new-var of fresh variable names is assumed. As said in [3], strictly speaking, any reference to this set requires a context, i.e. the variable names occurring so far. Instead of messing up the implementation
Building Tools for LOTOS Symbolic Semantics in Maude
297
with this other context, we have preferred to use a predefined Maude utility imported from module ORACLE, where a constant NEWQ is defined. Each time NEWQ is rewritten, it is rewritten to a different quoted identifier. With the following definition, we have the set of fresh variable names. op new-var : -> VarId . eq new-var = V(NEWQ) .
A (data) substitution is written as [z/x] where z is substituted for x. It seems to be easy to implement equationally, and we present below some equations showing how the substitution operation distributes over the syntax of behaviour expressions. However, if we want to allow user-definable data expressions by means of an ACT ONE specification, we cannot completely define this operation now, because we do not know at this point the syntax of data expressions. We will describe in Section 3.1 how the module containing the new syntax is automatically extended to define this operation on new data expressions. op _[_/_] : op _[_/_] : eq stop [E’ eq g ! E1 ; eq P1 [] P2 [. . .]
BehExp DataExp VarId -> BehExp . DataExp DataExp VarId -> DataExp . / E] = stop . P [E’ / E] = g ! (E1[E’ / E]) ; (P[E’ / E]) . [E’ / E] = (P1[E’ / E]) [] (P2[E’ / E]) .
Also a function vars is used to obtain the variables occurring in a behaviour expression. And we have the same problem, that is, we cannot define it completely at this level since data expressions syntax is user-definable. We will see in Section 3.1 how it is defined automatically for new data expressions. op vars : BehExp -> VarSet . op vars : DataExp -> VarSet . eq vars(stop) = mt . eq vars(g ? x : S ; P) = x U vars(P) . eq vars(P1 [] P2) = vars(P1) U vars(P2) . eq vars(x) = x . [. . .]
Now we can define the symbolic transitions. As said above, a transition b α T −− −−−→ T , where T and T are behaviour expressions, b is a transition condition, and α is an event, will be represented as a rewrite T −→ {b}{α}T , where the righthand side term is of sort TCondEventBehExp. sort TCondEventBehExp . op {_}{_}_ : TransCond Event BehExp -> TCondEventBehExp .
We present some LOTOS symbolic semantics rules and their representation as rewrite rules in Table 1 (the complete set of rules can be found in [23]). We also show the inference rules to ease the comparison between the mathematical and Maude representations. The inference rules are not exactly the ones presented
298
A. Verdejo Table 1. Some semantics rules, and their implementation in Maude.
prefix axioms tt a a; P −− −−− →P tt
gE ...En
1 g d1 . . . dn ; P − −−−−−−− −−−−→ P
SP
gE ...En
g d1 . . . dn [SP ]; P − −−−−−−−1−−−−→ P
where Ei =
Ei if di = !Ei xi if di = ?xi : Si
rl A ; P => {true}{A}P . rl g O ; P => {true}{g eOff(O)}P . rl g O [SP] ; P => {SP}{g eOff(O)}P . op eq eq eq
eOff : eOff(! eOff(? eOff(O
Offer -> EOffer . E) = E . x : S) = x . O’) = eOff(O) eOff(O’) .
choice range rules b α P [gi /g] −− −−− → P b α choice g in [g1 , . . . , gn ] [ ] P −− −−− → P
for each gi ∈ {g1 , . . . , gn } crl choice g in [GIL][] P => {b}{a}P’ if select(GIL) => gi /\ P[gi / g] => {b}{a}P’ . sort GateId? . subsort GateId < GateId? . op select : GateIdList -> GateId? . rl select(g) => g . rl select(g, GIL) => g . rl select(g, GIL) => select(GIL) . hide rules b α P −− −−− → P name(α) ∈ {g1 , . . . , gn } b i hide g1 , . . . , gn in P −−−−−→ hide g1 , . . . , gn in P b α P −− −−− → P name(α) ∈ g{1 , . . . , gn } b α hide g1 , . . . , gn in P −−−−−→ hide g1 , . . . , gn in P
crl if crl if
hide P => hide P =>
GIL in P => {b}{i}hide GIL in P’ {b}{a}P’ /\ (name(a) in GIL) . GIL in P => {b}{a}hide GIL in P’ {b}{a}P’ /\ not(name(a) in GIL) .
general parallelism rules (not synchronising) b α P1 −− −−− → P1 name(α) ∈ g{1 , . . . , gn , δ} bσ ασ P1 | [g1 , . . . , gn ] | P2 −−−−−−−→ P1 σ| [g1 , . . . , gn ] | P2
whereα = gE1 . . . En , σ = σ1 . . . σn , dom(σi ) are disjoint, and [zi /xi ] if Ei = xi , xi ∈ vars(P2 ) and zi ∈ new-var. σi = [] otherwise crl P1 |[GIL]| P2 => {b sp(a,vars(P2))}{a sp(a,vars(P2))} ((P’ sp(a,vars(P2))) |[GIL]| P2) if P1 => {b}{a}P’ /\ not(name(a) in (GIL, delta)) .
Building Tools for LOTOS Symbolic Semantics in Maude
299
in [3] because we have generalized them to allow multiple event offers at an action. The rules for the prefix operator show how axioms are represented as rewrite rules without conditions. The choice range rule shows how nondeterministic elections can be made by using rewrite rules. The hide rules show how side conditions in the inference rules are added as conditions in the rewrite rules. Finally, the general parallelism rule shows how external definitions can be used, as the one defining the substitution (not shown in figure). After having implemented all the semantics rules for behaviour expressions, we have the following conservativity result: Given a LOTOS behaviour expression P , there are a transition condition b, an event a, and a behaviour expression P such that b a P −− −−−→ P if and only if P can be rewritten into {b}{a}P’ using the presented rules. In [3], it is also defined the concept of a term, which consists of an STS, T , paired with a substitution, σ, and written as Tσ . Transitions between terms are also defined. We have implemented these transitions as we have done for behaviour expressions (see [23]). 2.3
Execution Example
By using the search Maude command, that looks for all the rewrites of a given term that match a given pattern, we can find all the possible transitions of a behaviour expression. Maude> search G(’g) ; G(’h) ; stop |[ G(’g) ]| (G(’a) ; stop [] G(’g) ; stop) => X:TCondEventBehExp . Solution 1 (state 1) X:TCondEventBehExp --> {true}{G(’a)}G(’g) ; G(’h) ; stop |[G(’g)]| stop Solution 2 (state 2) X:TCondEventBehExp --> {true}{G(’g)}G(’h) ; stop |[G(’g)]| stop No more solutions. Maude> search G(’h) ; stop |[G(’g)]| stop => X:TCondEventBehExp . Solution 1 (state 1) X:TCondEventBehExp --> {true}{G(’h)}stop |[G(’g)]| stop No more solutions.
But we cannot use data expressions, apart from the predefined Booleans, because we have not introduced any ACT ONE specification, and we have to write identifiers using the abstract syntax. But these specifications are part of a Full LOTOS specification, and therefore, user-definable. We will see in the following sections how we give semantics to ACT ONE specifications and how they can be integrated with the previous LOTOS semantics implementation.
300
3
A. Verdejo
ACT ONE Modules Translation
We want to be able to introduce into our tool ACT ONE specifications, which will be then translated internally to Maude functional modules. Thus, we have to define ACT ONE syntax first. In Maude, the syntax definition for a language L is accomplished by defining a data type GrammarL , which can be done with very flexible user-definable mixfix syntax, that can mirror the concrete syntax of L. Particularities at the lexical level of L can be accommodated by user-definable bubble sorts, that tailor the adequate notions of token and identifier to the language in question. Bubbles correspond to pieces of a module in a language that can only be parsed once the grammar introduced by the signature of the module is available [5]. This is specially important when L has user-definable syntax, as it is our case with ACT ONE. The grammar of ACT ONE can be found in [23]. After having defined the module with ACT ONE syntax, we can use function metaParse from META-LEVEL, which receives as arguments the representation of a module M and the representation of a list of tokens and it returns the metarepresentation of the parsed term (a parse tree that may have bubbles) of that list of tokens for the signature of M . The next step consists in defining an operation translate that receives the parsed term and returns a functional module with the same semantics as the introduced ACT ONE specification. metaParse
QidList −−−−−−−→ GrammarACT
ONE
translate
−−−−−−−→ FModule
Notice that we start with a QidList (a list of quoted identifiers). It is obtained from the user input (see Section 4.2). With our translation we achieve the following result: Given an ACT ONE specification SP , and terms t and t in SP , we have SP |= t ≡ t ⇐⇒ M |= tM ≡ tM where M = translate(metaParse(ACTONE-GRAMMAR,SP )), and tM and tM are the representations of t and t in M . We do not show here the implementation of the translation (it can be found in [23]), but we show an example in Figure 1. Notice that when an ACT ONE sort declaration for sort T is found, it is not only translated into a Maude sort declaration for sort T , but we also have to declare type T as a subsort of sort DataExp (since values of the declared type could be used in a behaviour expression to be communicated) and the sort of LOTOS variables VarId has to be declared as a subsort of type T (since LOTOS variables could be used to build data expressions of this type). This is done in this way because we want to integrate ACT ONE modules with LOTOS specifications, but the translation is useful by itself, since it provides us with a tool in Maude where ACT ONE specifications can be entered and executed.
Building Tools for LOTOS Symbolic Semantics in Maude type Naturals is sorts Nat opns 0 : -> Nat s : Nat -> Nat _+_ : Nat, Nat -> Nat eqns forall x, y : Nat ofsort Nat 0 + x = x ; s(x) + y = s(x + y) ; endtype
301
fmod Naturals is including DATAEXP-SYNTAX . sorts Nat . subsort VarId < Nat . subsort Nat < DataExp . op 0 : -> Nat . op s : Nat -> Nat . op _+_ : Nat Nat -> Nat . eq 0 + x:Nat = x:Nat . eq s(x:Nat) + y:Nat = s(x:Nat + y:Nat) . endfm
Fig. 1. The ACT ONE specification on the left is translated into the functional module on the right.
3.1
Module Extensions
In Section 2.2 we saw that the operation that performs the syntactic substitution and the operation that extracts the variables occurring in a behaviour expression were not completely defined. The reason why we cannot define them completely when defining the semantics is the same in both cases: the presence of data expressions with user-definable syntax. Now that we know the ACT ONE specification and we have translated it to a functional module, we can define these operations on data expressions using the new syntax. Due to the metaprogramming features of Maude, we can do it automatically. We have defined operations that take a module M and return the same module M but where equations defining the substitution and extraction of variables over expressions built using the signature in M have been added. For example, if the operation addOperVars is applied to the module Naturals above, it adds the following equations:2 eq vars(0) = mt . eq vars(s(v1:Nat)) = vars(v1:Nat) . eq vars(v1:Nat + v2:Nat) = vars(v1:Nat) U vars(v2:Nat) .
4
Building the User Interface for LOTOS
We want to implement a formal tool where complete LOTOS specifications (with an ACT ONE data types specification, a main behaviour expression, and process definitions) are entered and executed. In order to execute or simulate the specification, we want to be able to traverse the symbolic transition system generated for the main behaviour expression by using the symbolic semantics instantiated 2
In Maude 2.0 a variable is an identifier composed of a name, followed by a colon, followed by a sort name. In this way, variables do not have to be declared in variable declarations, although they are still allowed for convenience.
302
A. Verdejo
with the data types given in ACT ONE and the given process definitions. We present here only the main ideas used in our implementation; full details can be found in [23]. The following module defines the commands of our tool. fmod LOTOS-TOOL-SIGN is protecting LOTOS-SIGN . sort LotosCommand . op show process . : -> LotosCommand . op show transitions . : -> LotosCommand . op show transitions of_. : BehExp -> LotosCommand . op cont_. : MachineInt -> LotosCommand . op cont . : -> LotosCommand . op show state . : -> LotosCommand . endfm
The first command is used to show the current process, that is, the behaviour expression used if we omit it in the rest of commands. The second and third commands are used to show the possible transitions (defined by the symbolic semantics) of the current or explicitly given process, that is, they start the execution of a process. The fourth command is used to continue the execution with one of the possible transitions, the one indicated in the argument of the command. Command cont is a shorthand for cont 1. The sixth command is used to show the current state of execution, that is, the current condition, trace and possible next transitions. 4.1
Tool State Handling
In our tool, the persistent state of the system is given by a single object which maintains the tool state. This object has the following attributes: – semantics, to keep the actual module where behaviour expressions can be executed, that is, the module LOTOS-SEMANTICS in Section 2.2 extended with the syntax and semantics for new data expressions; – lotosProcess, to keep the behaviour expression that labels the node in the symbolic transition system that has been reached during the execution; – transitions, to keep the set of possible transitions from lotosProcess; – trace, to keep the sequence of events performed in the path from the root of the STS to the current node; – condition, to keep the conjuntion of transition conditions in that path; and – input and output, to handle the communication with the user. We declare the following class by using the notation for classes in objectoriented modules [6]: class ToolState | semantics : Module, lotosProcess : Term, transitions : TermSeq, trace : Term, condition : Term, input : QidList, output : QidList .
Building Tools for LOTOS Symbolic Semantics in Maude
303
Then we describe by means of rewrite rules the behaviour of the tool when a LOTOS specification or the different commands are entered into the system. For example, there is a rule which processes a LOTOS specification entered to the system. We allow LOTOS specifications with four arguments: the name of the specification, an ACT ONE specification defining the data types to be used, the main behaviour expression, and a list of process definitions (either the ACT ONE specification or the list of processes can be empty). No local declarations are allowed. When a specification is entered, the semantics attribute is set to a new module built as follows: first, the ACT ONE part of the specification is translated to a functional module; then, equations defining the extraction of variables and substitution are added (as explained in Section 3.1); the resulting module is joined with the metarepresentation of module LOTOS-SEMANTICS; and, finally, an equation defining the constant context (Section 2.2) with the definitions of processes given in the specification is added. The lotosProcess attribute is also updated to the behaviour expression in the introduced specification (after having converted it to a term of sort BehExp), and the rest of attributes are initialized. Tool commands are handled by rules as well. For example, there is a rule that handles the show transitions command. It modifies the transitions attribute by using an operation which receives a module with the semantics implementation (extended with the syntax and semantics of data expressions) and a term t representing a behaviour expression, and returns the sequence of terms representing the possible transitions of t. It uses the operation metaSearch that represents at the metalevel the search command used in Section 2.3. 4.2
The LOTOS Tool Environment
Input/output of specifications and of commands is accomplished by the predefined module LOOP-MODE [6], that provides a generic read-eval-print loop. This module has an operator [_,_,_] that can be seen as a persistent object with an input and output channel (the first and third arguments, respectively), and a state (given by its second argument). We have complete flexibility for defining this state. In our tool we use an object of the ToolState class. When something is written in the Maude prompt enclosed in parentheses it is placed in the first slot of the loop object, as a list of quoted identifiers. Then it is parsed by using the adequate grammar, and the parsed term is put in the input attribute of the tool state object. Finally, the rules describing the tool state handling process it. The output is handled in the reverse way, that is, the list of quoted identifiers placed in the third slot of the loop is printed on the terminal. 4.3
Execution Example
This is an example of an interaction with the LOTOS tool. Although we use here a very simple example, we have used the tool to execute larger examples [23], including the Alternating Bit Protocol and the Sliding Window Protocol (with more than 550 lines of code) [21]. Our tool has proved itselt quite practical, giving the answer to the entered commands in few milliseconds.
304
A. Verdejo
Maude> (specification SPEC type Naturals is [as shown above] endtype behaviour h ! 0 ; stop [] ( g ! (s(0)) ; stop |[ g ]| g ? x : Nat ; h ! (x + s(0)) ; stop ) endspec) Maude> (show transitions .) Trace : nil Condition : true TRANSITIONS : 1. {true}{h 0}stop 2. {x = s(0)}{g s(0)}stop |[g]| h ! s(s(0)); stop Maude> (cont 2 .) Trace : g s(0) Condition : x = s(0) TRANSITIONS : 1. {true}{h s(s(0))}stop |[g]| stop Maude> (cont .) Trace :(g s(0))(h s(s(0))) Condition : x = s(0) No more transitions .
5
Comparison with Other Tools
As we said in the introduction of Section 2, we have implemented a similar tool by using a different approach, where transitions are represented as terms [22]. The main differences (besides the semantics representation, which is quite different) are found in the things that are done in the object level (level of the semantics representation) and the metalevel (by using reflection). In [22], a search operation defined at the metalevel is used to check if a transition is possible. It traverses a tree with all the possible rewrites of a term, moving continuously between the object level and the metalevel. In the implementation described in this paper, the search occurs completely at the object level, which makes it quite faster (and simpler). The fact of moving continuosly between the two levels allows us in [22] to define more things at the metalevel, like the substitution operation and extraction of variables, defined used the syntax of Terms at the metalevel. Here we follow a different approach as explained in Section 3.1, which we think is much more elegant and more general. The Concurrency Workbench of the New Century (CWB-NC) [8] is an automatic verification tool where systems in several specification languages can be executed and analyzed. Regarding LOTOS, CWB-NC accepts Basic LOTOS,
Building Tools for LOTOS Symbolic Semantics in Maude
305
because it does not support value-passing process algebras. The design of the system exploits the language-independence of its analysis routines by localizing language-specific procedures, which enables users to change the system description language by using the Process Algebra Compiler, that translates the operational semantics definitions into SML code. We have followed a similar approach, although we have tried to maintain the semantics representation at as high level as possible, although being executable. We have also implemented the semantics of the Hennessy-Milner modal logic for CCS and the subset of FULL [2] corresponding to this logic for LOTOS. Both implementations follow the same idea, using an operation to calculate the one-step successors of a process which in its turn uses the operational semantics definitions. Thus, the implementation of the analyzing algorithm, that is, the representation in Maude of the modal logic semantics, is the same in both cases, obtaining similar achievements than in the CWB-NC on keeping separated the language-specific features from the general ones. The Caesar/Aldebaran Development Package (CADP) [16] is a toolbox for protocol engineering, with several functionalities, from interactive simulation (as we do in our tool) to formal verification. In order to support different specification languages, CADP uses low-level intermediate representations, which forces the implementer of a new semantics to write compilers that generate these representations. CADP has already been used to implement FULL [1], although with the severe restrictions to finite types and to the standard semantics of LOTOS instead of the symbolic one.
6
Conclusions and Future WORK
We have presented a new example of how rewriting logic and Maude can be used as a semantic framework and metalanguage, where entire environments and tools for the execution of formal specification languages can be built. In this process, reflection plays a decisive role. We have implemented the LOTOS symbolic semantics in Maude by representing transitions as rewrites and by representing the semantics rules as conditional rewrite rules where the transitions in the premises become the conditions. This approach is different from the one used in [22,24], and presents several advantages as explained in Sections 2 and 5. In addition, we have implemented a translation from ACT ONE specifications to Maude functional modules, which allows as to execute these specifications in Maude by using its high-performance reduction engine. These functional modules are integrated with the semantics, obtaining an implementation of the LOTOS symbolic semantics with user-definable data types. Finally, we have implemented in Maude a user interface for our tool that allows the user not to use Maude directly, but instead a tool built on Maude whose input is a LOTOS specification and where the specification can be executed by means of commands that traverse the corresponding labelled transtition system.
306
A. Verdejo
Based on the symbolic semantics used in this paper, a symbolic bisimulation [3] and a modal logic FULL [2] have been defined. We plan to extend our tool so that we can check if two processes are bisimilar, or if a process satisfies a given modal logic formula. We have already implemented a subset of FULL without data values, and we have integrated it with our tool. The part of the logic with data values deserves more study, and we think that some kind of theorem proving will be needed. Rewriting logic and Maude have been proved highly valuable also for these subjects [4]. Acknowledgements. I would like to thank Carron Shankland for her helpful answers about LOTOS symbolic semantics. I am also very grateful to Narciso Mart´ı-Oliet for his useful comments and suggestions on earlier versions of this paper.
References 1. J. Bryans and C. Shankland. Implementing a modal logic over data and processes using XTL. In Kim et al. [17], pages 201–218. 2. M. Calder, S. Maharaj, and C. Shankland. An adequate logic for Full LOTOS. In J. Oliveira and P. Zave, editors, FME 2001: Formal Methods for Increasing Software Productivity, volume 2021 of Lecture Notes in Computer Science, pages 384–395. Springer-Verlag, 2001. 3. M. Calder and C. Shankland. A symbolic semantics and bisimulation for Full LOTOS. In Kim et al. [17], pages 184–200. 4. M. Clavel. Reflection in Rewriting Logic: Metalogical Foundations and Metaprogramming Applications. CSLI Publications, 2000. 5. M. Clavel, F. Dur´ an, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer, and J. Quesada. Maude as a metalanguage. In C. Kirchner and H. Kirchner, editors, Proceedings Second International Workshop on Rewriting Logic and its Applications, WRLA’98, Pont-` a-Mousson, France, September 1–4, 1998, volume 15 of Electronic Notes in Theoretical Computer Science. Elsevier, 1998. http://www.elsevier.nl/locate/entcs/volume15.html. 6. M. Clavel, F. Dur´ an, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer, and J. Quesada. Maude: Specification and Programming in Rewriting Logic. Computer Science Laboratory, SRI International, Jan. 1999. http://maude.csl.sri.com/manual. 7. M. Clavel, F. Dur´ an, S. Eker, P. Lincoln, N. Mart´ı-Oliet, J. Meseguer, and J. F. Quesada. Towards Maude 2.0. In K. Futatsugi, editor, Proceedings Third International Workshop on Rewriting Logic and its Applications, WRLA 2000, Kanazawa, Japan, September 18–20, 2000, volume 36 of Electronic Notes in Theoretical Computer Science, pages 297–318. Elsevier, 2000. http://www.elsevier.nl/locate/entcs/volume36.html. 8. R. Cleaveland and S. T. Sims. Generic tools for verifying concurrent systems. Science of Computer Programming, 42(1):39–47, Jan. 2002. 9. C. de O. Braga, E. H. Haeusler, J. Meseguer, and P. D. Mosses. Maude action tool: Using reflection to map action semantics to rewriting logic. In T. Rus, editor, AMAST: 8th International Conference on Algebraic Methodology and Software Technology, volume 1816 of Lecture Notes in Computer Science, pages 407–421. Springer-Verlag, 2000.
Building Tools for LOTOS Symbolic Semantics in Maude
307
10. H. Eertink. Executing LOTOS specifications: the SMILE tool. In T. Bolognesi, J. Lagemaat, and C. Vissers, editors, LotoSphere: Software Development with LOTOS. Kluwer Academic Publishers, 1995. 11. H. Ehrig and B. Mahr. Fundamentals of Algebraic Specification 1: Equations and Initial Semantics. EATCS Monographs on Theoretical Computer Science. Springer-Verlag, 1985. 12. B. Ghribi and L. Logrippo. A validation environment for LOTOS. In A. Danthine and G. Leduc, editors, Protocol Specification, Testing, and Verification XIII, pages 93–108. Norht-Holland, 1993. 13. R. Guillemot, M. Haj-Hussein, and L. Logrippo. Executing large LOTOS specifications. In S. Aggarwal and K. Sabnani, editors, Protocol Specification, Testing, and Verification VIII, pages 399–410. North-Hollland, 1988. 14. M. Hennessy and H. Lin. Symbolic Bisimulations. Theoretical Computer Science, 138:353–389, 1995. 15. ISO/IEC. LOTOS—A formal description technique based on the temporal ordering of observational behaviour. International Standard 8807, International Organization for standardization — Information Processing Systems — Open Systems Interconnection, Geneva, Sept. 1989. 16. J. -C. Fernandez, H. Garavel, A. Kerbrat, L. Mounier, R. Mateescu, and M. Sighireanu. CADP: a protocol validation and verification toolbox. In R. Alur and T. A. Henzinger, editors, Proceedings of the Eighth International Conference on Computer Aided Verification CAV, volume 1102 of Lecture Notes in Computer Science, pages 437–440. Springer-Verlag, 1996. 17. M. Kim, B. Chin, S. Kang, and D. Lee, editors. Proceedings of FORTE 2001, 21st International Conference on Formal Techniques for Networked and Distributed Systems. Kluwer Academic Publishers, 2001. 18. N. Mart´ı-Oliet and J. Meseguer. Rewriting logic as a logical and semantic framework. Technical Report SRI-CSL-93-05, SRI International, Computer Science Laboratory, Aug. 1993. To appear in D. Gabbay, ed., Handbook of Philosophical Logic, Second Edition, Volume 9. Kluwer Academic Publishers, 2002. http://maude.csl.sri.com/papers. 19. J. Meseguer. Conditional rewriting logic as a unified model of concurrency. Theoretical Computer Science, 96(1):73–155, 1992. 20. J. Meseguer. Research directions in rewriting logic. In U. Berger and H. Schwichtenberg, editors, Computational Logic, NATO Advanced Study Institute, Marktoberdorf, Germany, July 29 – August 6, 1997, NATO ASI Series F: Computer and Systems Sciences 165, pages 347–398. Springer-Verlag, 1998. 21. K. Turner. Using Formal Description Techniques – An Introduction to Estelle, LOTOS and SDL. John Wiley and Sons Ltd., 1992. 22. A. Verdejo. LOTOS symbolic semantics in Maude. Technical Report 122-02, Dpto. Sistemas Inform´ aticos y Programaci´ on, Universidad Complutense de Madrid, Jan. 2002. 23. A. Verdejo. A tool for Full LOTOS in Maude. Technical Report 123-02, Dpto. Sistemas Inform´ aticos y Programaci´ on, Universidad Complutense de Madrid, Apr. 2002. http://dalila.sip.ucm.es/˜{}alberto. 24. A. Verdejo and N. Mart´ı-Oliet. Implementing CCS in Maude. In T. Bolognesi and D. Latella, editors, Formal Methods For Distributed System Development. FORTE/PSTV 2000, pages 351–366. Kluwer Academic Publishers, 2000.
From States to Transitions: Improving Translation of LTL Formulae to Büchi Automata Dimitra Giannakopoulou1 and Flavio Lerda2 1
RIACS/USRA, NASA Ames Research Center, Moffett Field, CA 94035-1000, USA
[email protected] 2 School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, USA
[email protected] Abstract. Model checking is an automated technique for checking that a system satisfies a set of required properties. With explicit-state model checkers, properties are typically defined in linear-time temporal logic (LTL), and are translated into Büchi automata in order to be checked. This paper describes how, by labeling automata transitions rather than states, we significantly reduce the size of automata generated by existing tableau-based translation algorithms. Our optimizations apply to the core of the translation process, where generalized Büchi automata are constructed. These automata are subsequently transformed in a single efficient step into Büchi automata as used by model checkers. The tool that implements the work described here is released as part of the Java PathFinder software (JPF), an explicit state model checker of Java programs under development at the NASA Ames Research Center.
1
Introduction
The use of LTL-based specifications in model checking is widespread. Many tools, including Java PathFinder, developed at the NASA Ames Research Center [1], and SPIN, from Bell Labs [2], after translating LTL formulae into Büchi automata, perform the verification using algorithms based on the one presented in [3]. These algorithms are linear in the size of the Büchi automata; however the Büchi automaton corresponding to an LTL formula may, in the worst case, be exponential in the size of the formula, making the model checking effort exponential in the size of the original formula. This worst-case complexity does not tend to occur for formulae of practical interest. Despite this fact, it is important for automata used for verification to be as small as possible, because memory is a major concern in model checking. Since finding the optimal sized Büchi automaton is a PSPACE-hard problem [4], the translation process becomes crucial in determining the size of the automata used for verification. The translation of an LTL formula into a Büchi automaton that can be used for verification proceeds typically in three phases [4, 5]: 1) formula rewriting; 2) translaD.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 308–326, 2002. © Springer-Verlag Berlin Heidelberg 2002
From States to Transitions: Improving Translation of LTL Formulae
309
tion of the LTL formula into a generalized Büchi automaton – we refer to this as the “core” of the translation process; 3) conversion of the generalized Büchi automaton into a Büchi automaton, which can be used for model checking (we refer to this process as degeneralization). This paper focuses on phase 2, the core of the translation process. The existing algorithms proposed for this phase fall in two categories: those that are tableau-based ([6],[7]), and more recently an algorithm based on the construction of Alternating Automata [8], which claims better results for specific types of properties. The approach we take reduces the size of automata generated by the stateof-the-art in tableau-based algorithms [7]. Moreover, early comparisons of our translator against the one given in [8] on formulae that constitute the strength of their approach indicate that we perform equally well. a
true
a
0 b{0}
b{0}
a
1
true{0}
b{0} 2
true{0}
true{0}
3
Fig. 1. Moving information from states to transitions. A label {0} denotes that a state or transition belongs to accepting set 0 of the automaton a 0
a
true{0} b{0}
2
0
true b
2
Fig. 2. TGBAs are translated to BA with accepting states (represented with a double circle)
Our improvement is based on the fact that our core algorithm generates transitionbased generalized Büchi automata (TGBA), as opposed to state-based generalized Büchi automata (GBA). The algorithm of Gastin and Oddoux [8] also translates Alternating Automata into TGBAs. However, they attribute the improvements that their approach achieves to the use of Alternating Automata and to optimizations performed during intermediate stages of the translation. The use of TGBAs is not explicitly discussed as a factor in their results. TGBAs carry labels on their transitions, whereas the GBAs generated by existing tableau-based algorithms carry labels on their states. Moreover, the accepting sets of TGBAs contain transitions rather than states (see Section 2 for exact definitions). Although TGBAs and GBAs are equally expressive, TGBAs allow us to obtain coarser partitions of equivalent states. For example, the first automaton in Fig. 1 is the automaton generated by [7] for formula aUb (U is the strong until operator). Note that states labeled with different propositions cannot be merged. By moving information to the transitions of the automaton, we obtain the second automaton of the figure. From this TGBA, one can see that states 0 and 2 are bisimilar with states 1 and 3, respectively. By merging these states, we obtain the first automaton in Fig. 2. This is the more compact automaton that our algorithm generates directly.
310
D. Giannakopoulou and F. Lerda
During the degeneralization phase, we efficiently translate in a single step the TGBA obtained from phase 2 into a non-generalized Büchi automaton with labeled transitions but accepting states, as used by model checking (see the second automaton of Fig. 2). This allows us to limit the growth of the number of states from the generalized to the non-generalized automaton. The remainder of the paper is organized as follows. First, we provide background information in Section 2. A description of our algorithm for the core (phase 2) of the translation process is presented in Section 3, where the emphasis is on its differences from tableau-based algorithms. The degeneralization approach that we take is described in Section 4. Section 5 discusses the implementation of our tool, and Section 6 presents the results of our experiments comparing our approach to the state-of-the-art. Finally, Section 7 closes the paper with conclusions and future work.
2
Background
2.1
Linear Temporal Logic (LTL)
In this work, LTL is used to express temporal properties of a system for model checking. Given a set of atomic propositions ¨, a well-formed LTL formula is defined inductively using the standard Boolean operators, and the temporal operators X (next) and U (strong until) as follows:
each member of ¨ is a formula, if j DQG DUH formulae, then so are ½ j, j ¿ y, j ¾ y, Xj, j U y. ℘
An interpretation for an LTL formula is an infinite word w = x0x1x2… over 2 . In other words, an interpretation maps to each instant of time a set of propositions that hold at that instant. We write wi for the suffix of w starting at xi. LTL semantics is then defined inductively as follows ([6],[7]):
w |= p iff p ³ x0, for p ³ ¨ w |= j ¿ y iff ( w |= j ) or ( w |= y ) w |= j U y iff $ i 0, such that: wi |= y and " 0 j < i , wj |= j
w |= ½ j iff not w |= j w |= j ¾ y iff ( w |= j ) and ( w |= y ) w |= X j iff w1 |= j
We introduce the abbreviations “true j ¿ ½j” and “false ½true”. Temporal operators F (eventually) and G (always) typically used in LTL formulae are defined in terms of the main operators as follows: Fj true U j and Gj ½F½ j. As usual ([6],[7]), our algorithm works with formulae in negation normal form, that is, the ½ operator is pushed inwards until it occurs only before propositions. To avoid an exponential blow up in the size of the translated formula, we define operator V, as follows: j V y ½(½j U ½y). We refer to propositions and negated propositions as literals.
From States to Transitions: Improving Translation of LTL Formulae
2.2
311
Büchi Automata
There are several variants of Büchi automata. The variant typically used in model checking is Büchi automata with labels on transitions and simple accepting conditions defined in terms of states (see Fig. 2, on the right). We will refer to these as Büchi Automata. However, for simplicity, translators first generate generalized Büchi automata (GBA), which have multiple accepting conditions. The core translation algorithms of most existing approaches ([6],[7]) produce labeled GBAs. These automata have labeled states and multiple accepting conditions defined in terms of states (see Fig. 1, left). Our approach and the approach presented in [8] produce transition-based GBAs. These have labeled transitions and multiple accepting conditions defined in terms of transitions (see Fig. 2, left). In what follows, we provide formal definitions for all three of these variants. Definition 1 − A Büchi automaton (BA) is a 5-tuple B = 〈 S, A, ∆, q0, F 〉, where S is a finite set of states, A is a finite set of labels, ∆ ⊆ S A S is a labeled transition relation, q0 ³ S is the initial state, and F ² S is a set of accepting states. An execution of the automaton B on an infinite word w = a0 a1 a2… over alphabet A is an infinite word σ = s0 s1 s2… over alphabet S, such that: s0 = q0 and ((si, ai , si+1)³ ∆, ∀ i ³ N ). An infinite word w over alphabet A is accepted by the automaton B, if there exists an execution of B on w where some element of F occurs infinitely often. Definition 2 − A labeled generalized Büchi automaton (GBA) is a 6-tuple GB = 〈 S, A, L, ∆, q0, F 〉, where S is a finite set of states, A is a finite set of labels, L: S A
2 is a state labeling function, ∆ ² S S is a transition relation, q0 ³ S is an initial S state, and F ² 2 is a set of sets of accepting states. An execution of the automaton GB on an infinite word w = a0 a1 a2… over alphabet A is an infinite word σ = s0 s1 s2… over alphabet S, such that: s0 = q0 and " i³N, ((si , si+1) ³ ∆ and ai ³ L(si+1 ) ). An infinite word w over the alphabet A is accepted by the automaton GB, if there exists an execution of GB on w where some element from each set in F occurs infinitely often. For simplicity, in the rest of this paper, we will refer to labeled generalized Büchi automata as generalized Büchi automata. Definition 3 − A transition-based generalized Büchi automaton (TGBA) is a 5-tuple TGB = 〈 S, A, ∆, q0, F 〉, where S is a finite set of states, A is a finite set of labels, ∆ ² ∆
S A S is a labeled transition relation, q0 ³ S is an initial state, and F ² 2 is a set of sets of accepting transitions. An execution of the automaton TGB on an infinite word w = a0 a1 a2… over alphabet A is an infinite word σ = (source0, label0, target0) (source1, label1, target1)… over ∆, such that: (source0 = q0) and∀ i ³ N ((labeli = ai) and (targeti = sourcei+1)). An infinite word w over the alphabet A is accepted by a transition-based generalized Büchi automaton TGB, if there exists an execution of TGB on w where some element from each set in F occurs infinitely often.
312
3
D. Giannakopoulou and F. Lerda
Translation Algorithm
In this section, we describe the core algorithm of the translation process. We postpone efficiency issues until Section 3.5. to facilitate a presentation of our algorithm (LTL2BUCHI) and that presented in [7] (LTL2AUT) within a common framework. As discussed in the introduction, the main feature of our algorithm is that it records information on transitions rather than states, which allows it to merge states that other approaches cannot. Note that we only include the basic temporal operators in our presentation; derived operators are transformed appropriately during parsing of the input formulae. For readers that are familiar with previous literature on the subject, we make our presentation follow the style of [6]. The translation algorithm is a tableau-like procedure, which builds a graph that defines the states and transitions of the automaton. Nodes in the graph are partitioned based on equivalence classes, where each equivalence class corresponds to a state. The nodes are labeled by sets of formulae, separated in formulae that need to be true immediately, and formulae that need to be true from the next state on. The algorithm processes formulae by expanding temporal operators based on the following fundamental identity: j U y y ¿ (j ¾ X (j U y)). ADDINWe start by introducing the data structure used by our algorithm. 3.1
Data Structure
The basic data structure that the automaton construction algorithm manipulates is the Node, which contains the following fields: NodeId: A unique node id. Id 0 is reserved for the initial state. Incoming: The incoming edges to the node, represented by the ids of the nodes with an outgoing edge leading to the current node. ToBeDone: A set of formulae that must hold at the current node and have not been processed yet. Old: A set of already processed literals that must hold at the current node. Next: The set of formulae that must hold in all immediate successors of this node. Eventualities: The set of promised and fulfilled eventuality obligations by the node. A promised obligation is a U-formula that has been processed in the current node, and a fulfilled obligation is a formula processed in the current node that is the righthand side argument of some U-formula processed in the current node. Accepting: The accepting sets to which the node belongs. EquivClass: The id of the equivalence class to which the node belongs. We keep a list of nodes, nodes_set whose construction has been completed, each having the same fields as described above. We denote the field ToBeDone of the node q by “q.ToBeDone”, and similarly for other fields.
From States to Transitions: Improving Translation of LTL Formulae 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
313
// expand is a method of class Node ListofNodes expand (ListofNodes nodes_set) { if This.ToBeDone is empty { // node has been fully processed compute_accepting(This); if ∃ ND ∈ nodes_set s.t. equivalent(This, ND) { // this node is equivalent to a node that has already been computed merge(ND, This, nodes_set); return nodes_set; } // end if else { // processed node to be added to nodes_set This.EquivClass = new_class_id(); nodes_set = nodes_set ∪ {This}; create NewNode with: {NodeId = new_node_id(), Old=Next=Accepting = {}, Incoming = This.NodeId, ToBeDone = This.Next}; return NewNode.expand(nodes_set); } } else { // ToBeDone is not empty, so keep processing let next_formula ∈ This.ToBeDone; This.ToBeDone = This.ToBeDone \ {next_formula}; update_fulfilled_obligations(This, next_formula); if (contradicts(next_formula, This)) return nodes_set; // node gets discarded if (isRedundant(next_formula, This)) // formula is redundant return This.expand(nodes_set); // no need to process it if (next_formula is a U formula) update_promised_obligations(This, next_formula); // no contradictions, and formula is not redundant, so we process it if (next_formula is not a literal) { if (next_formula is a ‘U’, ‘V’ or ‘∨’ formula) { Node2 = This.Split(next_Formula); // split in 2 nodes return Node2.expand(This.expand(nodes_set)); } if (next_formula is a ‘ϕ ∧ ψ’ formula) { ToBeDone = ToBeDone ∪ ({ϕ,ψ} \ Old); return This.expand(nodes_set); } if (next_formula is a ‘X ϕ’ formula) { Next = Next ∪ (ϕ}; return This.expand(nodes_set); } } else { // next formula is a literal Old = Old ∪ {next_formula}; return This.expand(nodes_set); } } // end of “else ToBeDone not empty” } Fig. 3. Node expansion algorithm
314
3.2
D. Giannakopoulou and F. Lerda
Generic Algorithm
The core of algorithms LTL2BUCHI and LTL2AUT is method expand, which is illustrated in Fig. 3. The two algorithms differ in the way they implement the following methods: compute_accepting, equivalent, merge, update_fulfilled_obligations, and update_promised_obligations. The algorithm for translating a formula j starts by creating an initial node INIT with NodeId = EquivClass = 0, with Next = {j}, and with all other fields empty. The list of nodes nodes_set is initially empty. The translation of j is performed by calling INIT.expand(nodes_set) to expand node INIT. Let us at this stage describe how the expansion method works. The line numbers in the following description refer to the algorithm that appears in Fig. 3. With the current node, the algorithm first checks if there are unprocessed obligations left in ToBeDone. We examine two cases: 1) there are none 2) there are some obligations left in ToBeDone. Case 1 – there are no obligations left in ToBeDone (lines 3-17). The fact that ToBeDone is empty shows that the current node is fully processed, and ready to be added to nodes_set. It also contains enough information for us to compute the accepting sets to which it belongs (line 4). If this node is equivalent to an existing node in nodes_set, then the two nodes are merged (line 7), meaning that the information they hold is combined appropriately. If it is not equivalent to any existing node (lines 10-17), it defines a new state of the automaton generated. A new equivalence class Id is assigned to the node’s EquivClass field, and the node is added to nodes_set. Moreover, a new node NewNode is created as the immediate successor of the current node (the one that has just been processed). The Incoming field of NewNode is the NodeId of the current one, and its obligations in ToBeDone are the obligations that the current node holds in its Next field. In other words, after a node is processed, its future obligations are delegated to its immediate successors. Case 2 – there are obligations left in ToBeDone (lines 18-48). If the current node contains obligations in ToBeDone, a formula next_formula is removed from this set. Method update_fulfilled_obligations is called, to record potential eventualities that the formula that is being processed fulfills. We then check whether this formula contradicts any information contained in the node. If a contradiction occurs, it means that the node must be discarded. If no contradiction occurs, then we check whether the formula is redundant (i.e. covered by some information contained in this node), in which case we simply do not need to process it. If the formula is not redundant, and is a U-formula, it promises to fulfill some obligation in the future (since U is a strong until), which is recorded by method update_promised_obligations. If the formula is not redundant and it does not contradict existing node information, then it gets processed as follows. When next_formula is a literal, then the formula is simply added to field Old of the node (lines 44-47). When next_formula is not a literal (lines 31-43), the current node is either split in 2 nodes or not split, and new formulae may be added to the fields ToBeDone and Next. (Note that when we split a node, for efficiency reasons, we do not create two new nodes, but modify the current one, and
From States to Transitions: Improving Translation of LTL Formulae
315
create an additional node.) The exact actions performed depend on the form of next_formula and are the following:
next_formula = j ¾ y. Then j and y are added to ToBeDone because they both need to be true for the formula to hold.
next_formula = Xj. Then j is added to field Next.
next_formula is in either of the forms: j ¿ y, j U y, j V y. There are two alternative ways of making these formulae true. So the node is split into two nodes, each representing one way of making the formula true. For j ¿ y, j is added to ToBeDone of one node, and y to that of the other. For j U y, j is added to ToBeDone and j U y to Next of one node, and y is added to ToBeDone of the other. This splitting can be explained by observing that j U y is equivalent to y ¿ (j ¾ X (j U y)). For j V y, y is added to ToBeDone of both nodes, j is added to ToBeDone of one node, and jVy to Next of the other. This splitting can be explained by observing that j V y is equivalent to y ¾ (j ¿ X (j V y)).
The splitting algorithm is illustrated in Fig. 4. Table 1 illustrates, for the types of formulae that cause a node to split, the formulae added to fields of the resulting nodes (although ¾ formulae are not split, we include an entry in the table, because the fields in this table are also used for the definition of syntactic implication used in the computation of redundancies and contradictions). For example, the formulae in New1 and New2 are added to the ToBeDone field of the first and second resulting node, respectively. Moreover, Next1 is added to the Next field of the first resulting node. Table 1. Definition of New and Next functions for non-literals form
New1(form)
Next1(form)
New2(form)
jUy jVy j¿y j¾y
{j} {y} {j} «
{j U y} {j V y} « «
{y} {j, y} {y} {j, y}
//split is a method of class Node. It splits a node into two, using information in Table 1 Node split (Formula form) { create Node2 with new Id but otherwise identical to This; Node2.ToBeDone = This.ToBeDone ∪ (New2(form) \ Old); // modify This (current node) as follows This.ToBeDone = This.ToBeDone ∪ (New1(form) \ Old); This.Next = Next ∪ Next1(form); return Node2; } Fig. 4. The splitting algorithm
The copies are processed in DFS order, i.e., when expansion of the current node and its successors are finished, the expansion of the second copy and its successors is
316
D. Giannakopoulou and F. Lerda
started. Note that a formula is only added to ToBeDone if it does not exist in Old – hence the fact that we take (New(form) \ Old) (see Fig. 4). This is purely for efficiency, that is, to avoid processing a formula that has already been processed. Also, the fields Incoming, ToBeDone, Old, and Next of each node are sets, and therefore contain no duplicates. Testing for contradictions and redundancies. As described by [7], the checks for contradiction and redundancy areADDIN based on deriving the set of formulae SI(A, B) that are syntactically implied from sets of formulae A and B, where B represents formulae that have to hold at the next state. We use the following inductive definition: 1. TRUE ³ SI(A, B), 2. m ³ SI(A, B), if m ³ A, 3. m ³ SI(A, B), if m is not a literal and either of the following hold: (New1(m) ² SI(A, B) ) and (Next1(m) ² B) New2(m) ² SI (A, B) (see Table 1 for definitions of New and Next) A IRUPXOD FRQWUDGLFWV a node nd, if ½ ³ SI(nd.Old, nd.Next). In other words, contradicts nd) returns true if ½ ³ SI(nd.Old, nd.Next). A IRUPXOD LV redundant for a node nd, LI ³ SI(nd.Old, nd.Next), and additionally, if is m U n (that is is a U-formula), then n ³ SI(nd.Old, nd.Next). As mentioned in [7], the special attention to the right-hand side arguments of U-formulae is to avoid discarding information required to define accepting conditions. So to summarize, isRedundant nd) returns WUXHLI ³ SI(nd.Old, nd.Next) ) and (HLWKHU LV not a U-formula, or ¶V right hand argument n ³ SI(nd.Old, nd.Next) ). 3.3
Obtaining the Automaton
The nodes_set returned by the expand algorithm is used to construct a TGBA that corresponds to the formula translated. There are as many states in the automaton as there are different EquivClass ids in the corresponding field of nodes in nodes_set. A state with id i represents all nodes nd in nodes_set such that nd.EquivClass =i. A transition trans exists between state i and state j iff: {$ nodes ndi, ndj such that ndi.EquivClass = i and ndj.EquivClass = j , and ndi ³ ndj.Incoming}. The propositions that label trans are ndj.Old, which means that the transition is triggered iff all literals in ndj.Old hold. Finally, the accepting sets to which trans belongs are defined by ndj.Accepting. We thus obtain a transition-based generalized Büchi automaton, which is subsequently degeneralized as described in Section 4. 3.4
Tuning for LTL2AUT or LTL2BUCHI
Our description of the algorithm so far applies both to LTL2AUT and LTL2BUCHI. In this section, we show how implementations of the remaining functions can be tuned to obtain each of the two algorithms.
From States to Transitions: Improving Translation of LTL Formulae
317
LTL2AUT.
Two nodes are equivalent if their Old and Next fields are equal, i.e., equivalent(Node nd1, Node nd2) returns true if (nd1.Old equals nd2.Old) and (nd1.Next equals nd2.Next). Merging two nodes updates the Incoming field of the first node to the union of their respective Incoming fields, i.e. merge(Node nd1, Node nd2, ListOfNodes nodes_set) performs { nd1.Incoming = nd1.Incoming nd2.Incoming}. LTL2AUT does not use the Eventualities field. Rather, it computes the accepting conditions that a node fulfills in terms of fields Old and Next. As a result, methods update_fulfilled_obligations and update_promised_obligations have empty bodies. Method compute_accepting(Node nd) adds the accepting set defined by a formula U to nd.Accepting if the following condition holds: ( U ³ SI(nd.Old, nd.Next) ) ( ³ SI(nd.Old, nd.Next) ). LTL2BUCHI.
Two nodes are equivalent if their Next fields are equal, i.e., equivalent(Node nd1, Node nd2) returns true if (nd1.Next equals nd2.Next). Merging two nodes first checks if fields Old and Accepting of the nodes are equal. If they are, then the Incoming field of the first node gets updated to the union of their respective Incoming fields. Otherwise, the EquivClass field of the second node is updated to that of the first node, and the second node is added to the nodes_set: merge(Node nd1, Node nd2, ListOfNodes nodes_set) { if ((nd1.Old equals nd2.Old) and (nd1.Accepting equals nd2.Accepting)) then {nd1.Incoming = nd1.Incoming ∪ nd2.Incoming); else { nd2.EquivClass = nd1.EquivClass; nodes_set = nodes_set ∪ {nd2}; } }
So merging in the context of LTL2BUCHI consists of recording the fact that two nodes are equivalent, and adding the information that the new node provides to the nodes_set. The reason why we cannot always merge nodes in the same way as LTL2AUT is that the Old and Accepting fields of the two nodes may differ, meaning that the state in the final automaton that corresponds to this equivalence class can be obtained by different transitions. By recording the information of both nodes, we are able, at the end of the construction, to label these transitions appropriately. As soon as a formula is processed in a node, if this formula is the right-hand side argument of a U-formula (U-formulae define accepting sets in the automaton generated), then this formula must be added to field Eventualities of the node. So method update_fulfilled_obligations(Node nd, Formula form) performs { if (form is right-hand side argument of a U-formula) nd.Eventualities = nd.Eventualities {form} }. If a Uformula is processed, unless it is redundant, the node promises to fulfill its obligations, so update_promised_obligations(Node nd, Formula form) performs {nd.Eventualities = nd.Eventualities {form}}.
318
D. Giannakopoulou and F. Lerda
Finally, compute_accepting(Node nd) computes nd.Accepting as follows: the accepting set corresponding to a formula U belongs to nd.Accepting iff {( U ³ nd.Eventualities) ( ³ nd.Eventualities)}. 3.5
Optimizations
The above presentation of our algorithm focused on simplifying its comparison with that presented in [7]. In this section, we discuss how LTL2BUCHI has been implemented for efficiency. Implementation details can be found in [10]. Let j be the formula to be translated. Each accepting set for j is assigned a unique integer in the range 0..(#accepting_sets – 1). The set of accepting sets to which a node nd belongs is then represented as a bitmap B of size #{accepting_sets}. If location i of B is set, then nd belongs to accepting set i. An abstract syntax graph is initially generated for formula j. This graph is similar to an abstract syntax tree, but is a directed acyclic graph (dag) where equal formulae appear only once, i.e., they are represented by a single node in the graph. That allows for fast comparison of formulae in the subsequent phases of the algorithm, based on equality of their references. Each node of the graph represents a sub-formula of j (with the root referencing j itself). For each (sub)-formula form, the following information is recorded. If form is a Uformula, we record the index (untils_index) of the accepting set that form defines. This index is obtained by calling form.get_untils_index(). If form is the right-hand side argument of one or more U-formulae mi, we record for form in a bitmap RightofWhichUntils the indices of all mi formulae. In other words, if bit i is set in the RightofWhichUntils field of formula form, it means that form is the right-hand side arguth ment of the U-formula that defines the i accepting set. This bitmap is obtained by calling form.get_rightOfWhichUntils(). Field Eventualities of a node nd does not record formulae explicitly. Rather, it is made up of two bitmaps, one for the promised obligations, and one for the fulfilled obligations. Whenever a U-formula is processed in a node, the bit whose index corresponds to this formula must be set in Eventualities.promised. Whenever a formula that is the right-hand side argument of some U-formulae is processed, then the bits corresponding to these U-formulae must be set in Eventualities.fulfilled. Updating this information on the node is therefore performed as follows: update_fulfilled_obligations(Node nd, Formula form) { nd.Eventualities.fulfilled = (nd.Eventualities.fulfilled bitwise_or form.get_rightOfWhichUntils()); } update_promised_obligations(Node nd, Formula set bit form.get_untils_index() in nd.Eventualities.promised; }
form) {
Finally, the Accepting field of a node is computed as follows: compute_accepting(Node nd) { nd.Accepting = (bitwise_not (nd.Eventualities.promised)) bitwise_or nd.Eventualities.fulfilled; }
From States to Transitions: Improving Translation of LTL Formulae
319
Therefore, we avoid computing the accepting conditions of a node in terms of syntactic implications, as is done by [7], since this information is obtained during the actual expansion. We also avoid storing explicitly all relevant formulae that are processed, as performed in [6], but rather store them in terms of bitmaps, which also allow us a very efficient way of obtaining the accepting conditions in the end. In addition to the above, during the translation of a formula, we represent a partition of equivalent nodes in a more compact form, as described in [10]. Fully processed nodes are stored in a data structure, which we call a state. Each state represents an actual state of the final automaton, i.e. an equivalence class of nodes. In field Transitions, a state stores information about the set of transitions that lead to that state, and in Next, it stores the formulae that need to hold for its immediate successors. Each transition holds information about its source states, its labels, and the accepting sets to which it belongs. 3.6
Correctness Argument
We argue for the correctness of our approach by comparing it to other approaches proven correct. In essence, the core of our algorithm consists of applying the algorithm of [7] to generate transition-based generalized Büchi automata. There is therefore a direct correspondence between the automata we generate and those generated by the [7] algorithm. One could move between equivalent automata of each type by just applying simple transformations, if one assumes that the information about the Next fields of nodes is maintained in states of these automata. All that our algorithm does is that, by moving labels to transitions, it can always merge states that have the same future (same Next fields). Our computation of the accepting sets to which states/transitions belong is based on [6]. The idea there is to determine, for each U formula that has been processed in a Node, whether its right-hand side argument has also been processed. In other words, whether the eventualities promised are fulfilled. However, similarly to [7], we do not process some redundant formulae. We therefore need to decide how to treat redundant formulae that are U-formulae or right-hand side arguments of U-formulae. From the definitions of Section 3.2, for a U-formula to be redundant, its right-hand side argument must be syntactically implied by the current Node. According to [7], this Node is then accepting with respect to the set that the U-formula defines. For this reason, when a U-formula is redundant, we do not set its bit in the promised bitmap. On the other hand, it is possible for the right-hand side of a U-formula to be redundant, but for its corresponding U-formula to have been processed in the Node that is being expanded. To cover for this possibility, we always update the fulfilled bitmap when the righthand side of a U-formula is encountered. Our scheme for computing accepting transitions thus avoids re-computing syntactic implications in order to establish accepting states/transitions as is performed in [7], but also avoids storing explicitly all relevant formulae that are processed, as performed in [6].
320
4
D. Giannakopoulou and F. Lerda
Degeneralization
The TGBAs generated as described in Section 3 must be translated to a Büchi automaton. We perform this by using Büchi automata that we call degeneralizers. Degeneralization algorithms are well known in the literature but for completeness, we include here the way (inspired by [8]) in which we generate and use degeneralizers in our tool. else
else 0 1
0 else
0 0 0
else
else
0∧1
1
lowest priority
1
0
2
highest priority
0∧1
Fig. 5. On the left/right, we illustrate the degeneralizer used for a generalized automaton with one/two accepting sets, respectively a
a, {0}
0
1,0
Fig. 6. Degeneralization of the TGBA for “Ga”, using the automaton on the left of Fig. 5
A degeneralizer for a TGBA is a deterministic Büchi automaton. Degeneralizers have a fixed number of states for a fixed number of accepting sets in their targeted TGBAs. They express the fact that a path in the TGBA is accepting if it contains infinitely often at least one accepting transition from each one of the accepting sets. The transitions of a degeneralizer DG are therefore labeled with predicates that relate to accepting sets. A BA is obtained by a TGBA by computing its synchronous product with the appropriate degeneralizer. That is, a joint transition (t1, t2) of a DG with a TGBA is enabled if t2 belongs to the accepting set that the predicate on t1 requires. The accepting states of the product are the ones where the degeneralizer is in an accepting state. Fig. 6 illustrates the result of degeneralizing the GBA generated for formula Ga with the degeneralizer depicted on the left of Fig. 5, where state “1” is the initial state. Fig. 5 illustrates degeneralizers for automata with one and two accepting sets. These degeneralizers are deterministic; transitions are explored based on their priority – lower priority transitions are only explored if higher priority ones cannot fire. Else transitions are taken when no other outgoing transitions from a state are eligible (they have the lowest priority). A degeneralizer for n accepting sets is generated with the algorithm of Fig. 7. This algorithm generates labels in the order in which they should
From States to Transitions: Improving Translation of LTL Formulae
321
be explored, i.e. it generates higher priority transitions first. Note that transitions that have more requirements have higher priority, with “else” transitions having the lowest. From Fig. 5, it is clear that degeneralizers only accept infinite words that satisfy infinitely often the predicates related to each accepting set. However, such automata impose an order on the way these accepting sets should be satisfied. This order allows us to have deterministic degeneralizers, but the size of the Büchi automata generated is sensitive to this order. We are interested in coming up with heuristics that determine what degeneralizer would be better for a TGBA. Currently, our tool performs the degeneralization using a degeneralizer with the initial state being state 0 or the accepting state, and returns the smaller of the two results. Although very simple, this approach allows us to avoid unnecessary growth of the TGBA during degeneralization, especially for TGBAs with a small number of accepting sets. Büchi generate (int acc_sets) { nnodes = acc_sets + 1; // number of automaton nodes last = acc_sets; // last automaton node for (int i=0; i < nnodes; i++) create automaton state Si; for (int i=0; i i; j--) { create transition “trans” from Si to Sj; for (int k=i; k<j; k++) add label k to trans; } create looping transition for Si labeled with else; } // now dealing with last node create looping transition trans for Slast; for (int i=0; i=0; i--) { if (i == 0) then create transition from Slast to Si labeled else; else { create transition trans from Slast to Si; for (int j=0; j2, we generate a random operator from the set {½, X, ¿, ¾, U, V}, with a probability equal to P/2 to generate either U and V, and (1-P)/4 for the other operators. If the chosen operator is unary, it is applied to a random formula of size L-1; if it is binary, it is applied to a random formula of size S and one of size L-S-1, where S is randomly chosen between 1 and L-2 inclusive, and with a uniform distribution. 6.2
Results
We have performed tests for values of N equal to 3 and 5. In the first set of tests, the probability P is set to 1/3, that is, all operators have an equal probability of being generated. We then increase the probability of generating temporal operators, by setting P to 1/2. We plot the results as a function of the length L of the formulae, where L ranges from 5 to 30, in increments of 5. We compare the size of both the generalized, and the degeneralized automata generated by the two algorithms. Finally, we also perform a test with all the optimizations described in Section 5 turned on. In all cases our algorithm outperforms LTL2AUT with respect to both the number of states and the number of transitions, for the generalized as well as for the final Büchi automata. It can also be noted that the improvement in number of states is approximately the same as that obtained for the number of transitions. Except for the case where optimizations are used, the improvement on the generalized Büchi automata is conserved almost unaltered after degeneralization. The first row of Fig. 8 shows the ratio between the results obtained with our algorithm and the LTL2AUT algorithm, without applying any optimizations (we compare the “core” of the translation): for each data point it depicts the average number of states and transitions, before and after degeneralization. As the length of the formulae increases the improvement obtained over the LTL2AUT algorithm becomes more significant, and so does it for a larger number N of propositional variables. This can be
D. Giannakopoulou and F. Lerda
324
attributed to the fact that the complexity of a formula increases with its length and the number of propositional variables it contains, leaving more room for improvement in the tramlation. On the left side of the second row, we analyzed the behavior for random formulae generated assigning a higher probability to temporal operators. As it can be seen, the improvement again becomes more pronounced showing that the algorithm still performs better in the presence of more temporal operators.
07 06 05 04 03 02 01
tBA Transtlons
0 5
10
15
20
25
30
Length o f t h e f o r m u l a ( L )
L e n g t h o f t h e form "la (L)
F 1 0 0 N=5 P10.5
1
I
..... 07
05 04 03
.......GBA States
I
...m... BA States tBA Transtons
0 5
10
15
20
25
Length o f t h e f o r m u l a (L)
30
5
10
15
20
25
30
Length o f t h e formula (L)
Fig. 8. Ratio of states and transitiom generated by the LTL~BUCHI algorithm over the ones generated by the L T L ~ A U T algorithm, for the generalized and final Buch automata. The first row displays results for F = 100, P=1/3, N=3 (left) and N=5 (right). The second row displays results for F=100 andN=5, but for increased probabilityP=1/2 of generating temporal operators (left), and for the case where all optimizations are turned on (right).
The right side of the second row illustrates the results obtained when all optimizations are enabled: these include rewriting before the formula is translated and optimi-
From States to Transitions: Improving Translation of LTL Formulae
325
zations of the generated automaton. By comparing the results to those on the right of the first row in terms of the generalized Büchi automata, it is clear that rewriting has the same effect on both algorithms. On the other hand, optimizations of the generated automata reduce the overall improvement significantly. This is as expected, because our tools implement quite strong optimizations (including bisimulation, and fair simulation [4]). However even such strong optimizations do not completely compensate for the improvements that LTL2BUCHI achieves over LTL2AUT. Moreover, it is obvious that reducing the size of the automata early on makes the application of the optimization algorithms less expensive, both in terms of space, and time.
7 Conclusions
We have presented an algorithm that significantly improves the state-of-the-art in tableau-based translations of LTL formulae into Büchi automata, by computing transition-based, rather than state-based automata. The possibility of moving information to transitions has also been pointed out by Wolper in his tutorial paper [11], although no algorithm is provided. Transition-based automata are also used in [8], although in the context of using Alternating Automata in the translation process. An advantage of our optimization is that it is based on very simple modifications to the “core” of the tableau-based translation process, and could therefore be easily implemented by existing tableau-based translators. We have demonstrated the improvements achieved by our algorithm through extensive testing. In the future, we intend to perform more systematic testing and comparison of our tool with existing ones. We have already performed preliminary experiments with formulae that are typically used in verification and with formulae that are used to stress test such translators. For example, in testing it against “fairness formulae”, on which [8] report that their translation performs better than existing approaches, our tool generates automata with the same number of states (with optimizations turned on for both tools). As compared to SPIN [2] and to the tool by Etessami [4], our translator generates more compact automata. Finally, we are investigating ways of further improving our translation algorithms. For example, we wish to perform more efficient comparisons between the Next fields of the nodes during expansion, to allow further reductions. We also intend to update our tools with other optimizations defined in the literature.
Acknowledgements. We wish to thank Howard Barringer for his feedback on earlier versions of this paper and Cindy Kong for implementing the fair simulation algorithm.
326
D. Giannakopoulou and F. Lerda
References [1]
Visser, W., Havelund, K., Brat, G., and Park, S. "Model Checking Programs", in Proc. of the 15th IEEE International Conference on Automated Software Engineering (ASE’2000). 11-15 September 2000, Grenoble, France. IEEE Computer Society, pp. 3–11. Y. Ledru, P. Alexander, and P. Flener, Eds. [2] Holzmann, G.J., The Model Checker SPIN. IEEE Transactions on Software Engineering, Vol. 23(5), May 1997: pp. 279–295. [3] Courcoubetis, C., Vardi, M., Wolper, P., and Yannakakis, M., Memory-Efficient Algorithms for the Verification of Temporal Properties. Formal Methods in System Design, Vol. 1, 1992: pp. 275–288. [4] Etessami, K. and Holzmann, G. "Optimizing Buechi automata", in Proc. of the 11th International Conference on Concurrency Theory (CONCUR’2000). August 2000, Pennsylvania, USA. Springer, LNCS 1877. [5] Somenzi, F. and Bloem, R. "Efficient Buechi automata from LTL Formulae", in Proc. of the 12th International Conference on Computer Aided Verification (CAV 2000). July 2000, Chicago, USA. Springer, LNCS 1855. E.A. Emerson and A.P. Sistla, Eds. [6] Gerth, R., Peled, D., Vardi, M.Y., and Wolper, P. "Simple On-the-fly Automatic Verification of Linear Temporal Logic", in Proc. of the 15th IFIP/WG6.1 Symposium on Protocol Specification, Testing and Verification (PSTV’95). June 1995, Warsaw, Poland. [7] Daniele, M., Giunchiglia, F., and Vardi, M.Y. "Improved Automata Generation for Linear Temporal Logic", in Proc. of the 11th International Conference on Computer Aided Verification (CAV 1999). July 1999, Trento, Italy. Springer, LNCS 1633. [8] Gastin, P. and Oddoux, D. "Fast LTL to Buechi Automata Translation", in Proc. of the 13th International Conference on Computer Aided Verification (CAV 2001). July 2001, Paris, France. Springer, LNCS 2102, pp. 53–65. G. Berry, H. Comon, and A. Finkel, Eds. [9] Clarke, E.M., Grumberg, O., and Peled, D.A., Model Checking: The MIT press, 1999. [10] Giannakopoulou, D. and Lerda, F., “Efficient translation of LTL formulae into Büchi automata”, RIACS, Technical Report, 01.29, June 2001. [11] Wolper, P. “Constructing Automata from Temporal Logic Formulas: A Tutorial”, in Proc. of the FMPA 2000 summer school. July 2000, Nijmegen, the Netherlands.
A Compositional Sweep-Line State Space Exploration Method Lars Michael Kristensen1,2 and Thomas Mailund2 1
School of Electrical and Information Engineering, University of South Australia, Mawson Lakes Campus, Mawson Lakes, SA 5095, AUSTRALIA
[email protected] 2 Department of Computer Science, University of Aarhus IT-parken, Aabogade 34, DK-8200 Aarhus N, DENMARK, {lmkristensen,mailund}@daimi.au.dk
Abstract. State space exploration is a main approach to verification of finite-state systems. The sweep-line method exploits a certain kind of progress present in many systems to reduce peak memory usage during state space exploration. We present a new sweep-line algorithm for a compositional setting where systems are composed of subsystems. The compositional setting makes it possible to divide subsystem progress measures into monotone and non-monotone progress measures to further reduce peak memory usage. We show that in a compositional setting, it is possible to automatically obtain a progress measure for the system by combining the progress measure for each subsystem to a progress measure for the full system.
1
Introduction
A main method for verification of distributed and concurrent systems is state space exploration. The basic idea is to generate all the reachable states and state changes of the system under consideration, and represent these as a directed graph called the state space. The nodes in the state space represent the reachable states of the system, and the edges represent transitions between the reachable states. Because of the state explosion problem, the limiting factor in verification based on state spaces is, in most cases, the available computer memory. This has lead to the development of a wide range of state space reduction methods capable of reducing the memory required to conduct state space exploration. Partial-order methods [16,14,19] explore a subset of the state space, whereas the symmetry method [2] and symbolic methods based on Binary Decision Diagrams (BDDs) [12] provide a compact representation of the state space. Another main paradigm is that of compositional state space verification [17]. In this paradigm, systems are specified as a parallel composition of subcomponents, and the state space of the full system is computed from the state spaces
Supported by an Australian Research Council (ARC) Discovery Grant (DP02105). Supported by the Danish Natural Science Research Council.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 327–343, 2002. c Springer-Verlag Berlin Heidelberg 2002
328
L.M. Kristensen and T. Mailund
of the subcomponents. Moreover, the state spaces of subcomponents can be replaced by smaller and behaviourally equivalent state spaces before constructing the state space of the full system. Process algebras [5,13] are examples of formal description techniques that naturally fit the compositional paradigm. The basic idea of the sweep-line method [1, 9] is to exploit a certain kind of progress exhibited by many systems. Exploiting progress makes it possible to explore all the reachable states of a system, while only storing small fragments of the state space in memory at a time. The key concept of the sweep-line method is the notion of a progress measure which is used to capture the progress in the system. A progress measure associates a progress value to each state of the system, and it is the progress values of states that are used to determine which states can be deleted during the sweep through the state space. The sweep-line method is aimed at on-the-fly verification of safety properties, e.g., determining whether a reachable state exists satisfying a given state predicate. The sweep-line method was used in [4] for verification of transactions in the Wireless Application Protocol (WAP) with a reduction in peak memory usage to 20%. The sweep-line method is similar in spirit to the state space caching method [7,3] in that they are both based on the paradigm of deleting states encountered during the state space exploration. The criteria for deletion of states is, however, fundamentally different. In the state space caching method, states not on the depth-first stack can be deleted. With the sweep-line method, deletion is based on progress values. The sweep-line method and state space caching both guarantee complete coverage of the state space, i.e., exploration of all reachable states. For the monotone progress measures of [1], the sweep-line method explores each state exactly once, whereas state space caching may explore states multiple times. For the generalised sweep-line method [9] the main difference is in the search order. State space caching relies on depth-first exploration, whereas the sweepline method visits the reachable states in a least-progress-first order. A disadvantage of the sweep-line method is that it requires additional information from the user in the form of a progress measure. It is therefore desirable to automatically compute progress measures for systems. One contribution of this paper is to show that in a compositional setting where state spaces of the subcomponents are explicitly represented, a progress measures for each subcomponent can be obtained algorithmically and combined to a progress measure for the full system. This makes the sweep-line method fully automatic in such a setting. Furthermore, we present a new sweep-line state space exploration algorithm which exploits a division of subcomponent progress measures into monotone and non-monotone progress measures to further reduce peak memory usage. The paper is organised as follows. Section 2 gives the necessary background on the sweep-line method. Sections 3 and 4 show how to obtain a global progress measure from progress measures for the subcomponents of the system, and presents the sweep-line algorithm for compositional progress measures. Section 5 presents two algorithms for computing progress measure for subcomponents. Section 6 presents some experimental results and compares the use of the compositional sweep-line method with the use of the state space caching method. Finally
A Compositional Sweep-Line State Space Exploration Method
329
in Sect. 7, we sum up the conclusions. The reader is assumed to be familiar with the basic ideas of state space exploration.
2
The Sweep-Line Method
This section contains the necessary background information on the sweep-line method [1, 9]. To make our presentation independent of the concrete modelling language used for specification of the system, we present our results in the framework of labelled transition systems. Definition 1. A labelled transition system (LTS) is a tuple L = (S, Σ, ∆, ι), where S is a finite set of states, Σ is a finite set of transition labels, ∆ ⊆ S × Σ × S is the transition relation, and ι ∈ S is the initial state. a
We will write s → s ∈ ∆ if (s, a, s ) ∈ ∆. A state sn is reachable from a state s1 iff there exists states s2 , s3 , . . . , sn−1 and transition labels a1 , a2 , . . . an−1 such ai that si −→ si+1 ∈ ∆ for 1 ≤ i ≤ n − 1. If a state s is reachable from a state s in the LTS L, we write s →∗L s . We will refer to →∗L as the reachability relation. For a state s, reachL (s) = { s ∈ S | s →∗L s } denotes the set of states reachable from s. The set of reachable states of an LTS L is then reachL (ι). The transition labels of the LTSs are not important for the sweep-line method, and hence we omit them in the figures. An LTS can be viewed as representing the state space of a system, and we therefore use the terms state space and LTS interchangeably. A common way of constructing systems is through composition, and several parallel composition operators have been defined in the literature. In this paper we do not consider a particular parallel composition operator. Our only requirement to the parallel composition is captured in the definition below. This requirement is satisfied by most parallel composition operators used in practice. Definition 2. Let (S, Σ, ∆, ι) = L1 · · · Ln be the parallel composition of n LTSs, where Li = (Si , Σi , ∆i , ιi ) for 1 ≤ i ≤ n, and S = S1 × · · · × Sn . The operator respects local reachability if and only if the following holds: – ι = (ι1 , . . . , ιn ). – (s1 , . . . , sn ) →∗L (s1 , . . . , sn ) ⇒ si →∗Li si for 1 ≤ i ≤ n.
The sweep-line method is based on the concept of a progress measure. A progress measure specifies a partial order (O, ) (i.e., a reflexsive, antisymmetric, and transitive relation) on progress values O of the system, and a progress mapping ψ assigning a progress value ψ(s) ∈ O to each state s. Definition 3. A progress measure on an LTS L = (S, Σ, ∆, ι) is a tuple P = (O, , ψ) such that (O, ) is a partial order and ψ : S → O is a progress mapping from states into O. A monotone progress measure is a progress measure satisfying: ∀s, s ∈ reachL (ι) : s →∗L s ⇒ ψ(s) ψ(s ).
330
L.M. Kristensen and T . Mailund
Fig. 1.Snapshots of the sweep-line method. The states are ordered left to right according to their progress value. Initially (a), only the initial state i is stored and marked as unprocessed, and the sweep-line (the dashed vertical line), is to the left of the state space. Successors of i are calculated and marked as unprocessed. After i has been processed, s~ has a minimal progress value among the unprocessed states (SI,s ~ and , s ~ ) and is selected for processing. After sl has been processed, all states with the initial progress value (i.e., i and sl) have been processed (b), and the sweep-line can move to the right. As it does this, the states i and si with progress value strictly less than the minimal progress value among the unprocessed states (i.e., s2, s3, and s4) are deleted (c). Either s z or s s can now be selected for processing and the exploration continues.
Monotone progress measures preserve the reachability relation +>of the LTS. This means that a monotone progress measure 'P provides a conservative estimate of the reachability relation. In conventional state space exploration, the set of explored states is kept in memory to recognise already visited states. For a system with a monotone progress measure, the states with a progress value strictly less than the progress values of unprocessed states1 cannot be reached from the set of unprocessed states. It is therefore safe to delete such states from memory as they are not required to determine whether a newly generated state has already been visited. Saving memory by deleting such states is the basic idea underlying the sweep-line method. Figure 1 [9] illustrates the sweep-line method for monotone progress measures. The progress measure orders the states of the LTS, and the states are processed in this order. New states to be processed are chosen with minimal progress value, and whenever the minimal progress value increases, all states with a strictly smaller progress value are deleted. Intuitively, a sweep-line is dragged through the LTS, while new states are calculated in front of the sweep-line and processed states are deleted behind the sweep-line. For non-monotone progress measures it is not safe to delete states with a progress value less than the minimal progress values among the unprocessed states. The reason is that a state with a low progress value could be reachable from a state with a high progress value. State space exploration with nonmonotone progress measure can be done by conducting multiple sweeps. Each sweep is done in a similar way to the monotone case, with one exception: to A state is said to be unprocessed if all its successors have not yet been calculated.
A Compositional Sweep-Line State Space Exploration Method
331
1: Roots ← {ι} ; Nodes ← {ι} ; Persistent ← ∅ 2: while Roots = ∅ do 3: Unprocessed ← Roots // mark all root states for this sweep unprocessed. 4: Roots ← ∅ 5: while Unprocessed = ∅ do 6: // select s minimal wrt. ψ and in Unprocessed 7: select s ∈ Unprocessed such that ∀s ∈ Unprocessed : ψ(s ) ψ(s) 8: Unprocessed ← Unprocessed − {s} a 9: for all (a, s ) such that s − → s do 10: if s ∈Nodes then 11: Nodes ← Nodes ∪ {s } 12: if ψ(s) ψ(s ) then 13: Persistent ← Persistent ∪ {s } 14: Roots ← Roots ∪ {s } // make s root for the next sweep. 15: else 16: Unprocessed ← Unprocessed ∪ {s } 17: end if 18: end if 19: end for 20: // delete unreachable non-persistent states from Nodes 21: Nodes ← {s ∈ Nodes | ∃s ∈ Unprocessed : ψ(s ) ψ(s)} ∪ Persistent 22: end while 23: end while Fig. 2. The sweep-line algorithm. The algorithm performs a number of sweeps (lines 223). In each sweep regress-edges are identified (line 12), and the destination states of regress-edges are marked as persistent and are used as root states (lines 13-14) for the next sweep. Once a node has been marked as persistent, it is not deleted in line 21.
ensure that the state space exploration terminates and that all states have been visited at least once, regress-edges are recognised during the state space exploa ration. A regress-edge is an edge s − → s of the LTS such that ψ(s) ψ(s ). When a regress-edge is discovered, the destination state of the regress-edge is marked as persistent preventing it from being deleted. Newly discovered persistent states are used as roots in the subsequent sweep. The algorithm, derived from the standard algorithm for explicit state enumeration, is listed in Fig. 2. Correctness of the algorithm was established in [9]. Theorem 1 (Thm. 1 in [9]). The sweep-line algorithm terminates after having explored at most (|B| + 1) · |reachL (ι)| states, where B denotes the set of destination states of regress-edges. Upon termination, all states reachable from the initial state have been explored at least once.
3
Compositional Sweep-Line Exploration
The construction of a progress measure for the parallel composition of LTSs is based on the observation that given n partial norders (Oi , i ) for 1 ≤ i ≤ n, we can construct the product partial order ( i=1 Oi , ) where (o1 , . . . , on ) (o1 , . . . , on ) iff for all 1 ≤ i ≤ n : oi i oi . Based on this we define the product of n progress measures.
332
L.M. Kristensen and T. Mailund
Definition 4. The product of progress measures Pi = (Oi , i , ψi ) for 1 ≤ i ≤ n is defined as P = (O, , ψ) where (O, ) is the product partial order of (Oi , i ) for 1 ≤ i ≤ n as defined above, and ψ(s1 , . . . , sn ) = (ψ1 (s1 ), . . . , ψn (sn )). The fact that the product of progress measures can be used as a progress measure in conjunction with parallel composition is established by the following proposition. The proof of the proposition is rather straightforward and has been omitted here. It can be found in [8]. Proposition 1. Let Li for 1 ≤ i ≤ n be LTSs with progress measures Pi = (Oi , i , ψi ), respectively. The product P = (O, , ψ) of the Pi ’s as defined in Def. 4 is a progress measure on L = L1 · · · Ln . If Pi is a monotone progress measure on Li for 1 ≤ i ≤ n, then P is a monotone progress measure on L. Since by Prop. 1, the product progress measure is a progress measure on the parallel composition, we can immediately apply the algorithm from Fig. 2. However, we present a more elaborate algorithm which exploits that the progress measure on some components might be monotone. This makes it possible to delete persistent states when the monotone progress of a component ensures that they are no longer reachable from the unprocessed states. Persistent states cannot be deleted with the algorithm from Fig. 2. To explain how the improved algorithm operates, we first revisit the algorithm from Fig. 2. The progress mapping for the parallel composition L = L1 · · · Ln is a vector: ψ = (ψ1 , . . . , ψn ). This n-dimensional progress mapping makes a disjoint partitioning of the states of L, and positions the states into an n-dimensional grid. Figure 3 illustrates this for n = 2 and progress measures based on total orders. The square with coordinates (x, y) contains all states with progress value (x, y). For example, the states s1 , s2 , and s3 are the states with progress value (1, 2). The progress measure P1 , corresponding to the x-axis in Fig. 3, is monotone, whereas P2 , corresponding to the y-axis, is non-monotone. That P1 is monotone can be seen from the fact that all edges where the first coordinate changes points to the right. That P2 is non-monotone can be seen from, e.g., the regress-edge from s5 to s6 where the value of the y-coordinate decreases. As it can be seen, the non-monotone progress measures cause multiple sweeps. In this case, it caused all states reachable from s6 to be re-explored in the next sweep. Revisiting all states reachable from s6 can be avoided by exploring the states columnwise according to P1 (the monotone progress measure) and by conducting multiple sweeps only within each column. Figure 4 depicts a scenario in which the states are explored according to the columns determined by the monotone progress measure P1 . To formulate the sweep-line algorithm for n-dimensions we introduce two partial orderings derived from the partial order on the product progress values. The role of the two orderings is to distinguish between progress originating from monotone and non-monotone progress measures. Definition 5. Let Pi = (Oi , i , ψi ) for 1 ≤ i ≤ n be progress measures, and let P = (O, , ψ) be the product progress measure. Let m = {i | Pi is monotone },
A Compositional Sweep-Line State Space Exploration Method
333
Fig. 3. Snapshots of state exploration. The sweep-line (indicated with thick lines) separates the squares (1, I ) , (1,2), (1,3), and (2, 1) containing t h e explored (and now deleted) states ( 6 , sl, s2, s3, ss) from the squares containing some unprocessed states The squares (2,2) and (4, 1) are the next squares that can be examined in the leastprogress-first order. If ( 4 , l ) is chosen to be examined, the fragment of the sweep-line corresponding to y = 1 can move to ( 4 , l ) as shown in Fig. 3(b). If (2,2) is chosen to be examined, the fragment of the sweep-line corresponding to z = 2 can move t o (2,2). Eventually, this sweep will terminate, giving the situation depicted in Fig. 3(c). During the sweep, the states ss and sr will have been marked as persistent states because of the regress-edges from s4 to sr and s~ to ss, and they will be used as roots in the next sweep. The exploration of the state s p x e will finish after this next sweep.
and
m = { j 1 j $ m).
The partial orders ( 0 , E m ) and ( 0 , EK) are defined by:
(01,. . . ,on) Em (o:, . . . ,o&)u Y i t m : oi
Ei oj (01,. . . ,on) EK (o:, . . . ,o&)u Y i t m : oi Ei oj
In Fig. 3, the ordering on the monotone component determines the ordering on the columns, whereas the ordering on the non-monotone component determines the ordering within the columns. Figure 5 lists the compositional sweep-line algorithm. The algorithm consists of two procedures: COLUMNSWEEP and SWEEP. The procedure COLUMNSWEEP specifies the local sweep according to the nonmonotone progress measures, i.e., the sweeps in the columns of Fig. 4. SWEEP specifies the global sweep based on the monotone progress measures.
4
Correctness
We now turn to the correctness of the compositional sweep-line algorithm, i.e., that the algorithm in Fig. 5 terminates for any LTS C = C 1 . . . C , and upon termination all reachable states of C have been visited at least once (full coverage). To do this, we first introduce some new notation: The monotone compc. nents of the product progress measure on C partitions the set of reachable states into equivalence classes (columns in terms of Fig. 4), where two states s and s'
A Compositional Sweep-Line State Space Exploration Method
335
Global sets: 1: GlobalUnprocessed ← {ι}; Nodes ← {ι}; Persistent ← ∅ procedure ColumnSweep () 1: while Roots = ∅ do 2: Unprocessed ← Roots // mark all roots for this columnsweep unprocessed. 3: Roots ← ∅ 4: while Unprocessed = ∅ do 5: // select s minimal wrt. ψ and m in Unprocessed 6: select s such that ∀s ∈ Unprocessed : ψ(s ) m ψ(s) 7: Unprocessed ← Unprocessed − {s} a 8: for all (a, s ) such that s − → s do 9: if s ∈Nodes then 10: Nodes ← Nodes ∪ {s } 11: if ψ(s) m ψ(s ) then 12: // s is in a subsequent column. 13: GlobalUnprocessed ← GlobalUnprocessed ∪ {s} 14: else if ψ(s) m ψ(s ) then 15: Persistent ← Persistent ∪ {s } 16: Roots ← Roots ∪ {s } 17: else 18: Unprocessed ← Unprocessed ∪ {s } 19: end if 20: end if 21: end for 22: // delete unreachable non-persistent states in this column from Nodes 23: Nodes ← {s ∈ Nodes | ∃s ∈ Unprocessed : ψ(s ) m ψ(s)} 24: Nodes ← Nodes ∪ Persistent ∪ GlobalUnprocessed 25: end while 26: end while procedure Sweep () 1: while GlobalUnprocessed = ∅ do 2: Roots ← R where R ⊆ GlobalUnprocessed satisfy: ∀s, s ∈ R : ψ(s) = ψ(s ) and ∀s ∈ R, s ∈ GlobalUnprocessed − R : ψ(s ) m ψ(s) 3: GlobalUnprocessed ← GlobalUnprocessed − Roots 4: ColumnSweep() // sweep the next column. 5: Nodes ← Nodes − Persistent 6: Persistent ← ∅ 7: end while Fig. 5. The compositional sweep-line algorithm. Procedure ColumnSweep is identical to the algorithm in Fig. 2 except for lines 11-14 where it is checked whether s is higher in the monotone order. If this is the case, its investigation should be postponed to a later invocation of the procedure as it belongs to a subsequent column. The state is therefore inserted into the set GlobalUnprocessed which is shared between the two procedures. The procedure Sweep conducts a sweep according to the monotone progress measures where for each fixed progress value of the monotone components, a non-monotone sweep is conducted by invoking the ColumnSweep procedure. After each invocation of ColumnSweep, the persistent states are deleted from the set Nodes in line 6 of Sweep.
336
L.M. Kristensen and T. Mailund
alence class. We say that a state is being explored whenever its successor states are being calculated. Lemma 1. Let C ∈ CL and let R ⊆ C be a set of states. If in(C) ⊆ R, then invoking ColumnSweep on R explores all states in C, adds out(C) to GlobalUnprocessed, and explores at most (|B(C)| + 1) · |C| states. Proof. The lemma follows by a straightforward generalisation of the proof of Thm. 1 given in [9], and the observation that all states in C are reachable from in(C) using only intermediate states in C. Definition 7. Let X ⊆ CL . The notation for out and over in Def. 6 is extended to sets of equivalence classes by: – out(X) = {ι} if X = ∅, and out(X) = C∈X out(C) − C∈X C otherwise. – over(X) = CL if X = ∅, and C∈X over(C) − X otherwise. For a non-empty set X ⊆ CL we will say that C ∈ X is minimal in X if there exists no C ∈ X such that C m C. Similarly, we will say that s ∈ C for some C ∈ CL is minimal in C if there exists no s ∈ C such that ψ(s ) m ψ(s). The correctness of the compositional sweep-line algorithm in Fig. 5 follows from Thm. 2 below which uses the following proposition. Its proof can be found in [8]. Proposition 2. Let C ∈ CL and let X ⊆ CL be downwards closed. Then: 1. If C is minimal in over(X), then X ∪ {C} is downwards closed. 2. If s ∈ C is minimal in out(X), then C is minimal in over(X). 3. If C is minimal in over(X), then in(C) ⊆ out(X).
Theorem 2. The sweep-line algorithm in Fig. 5 terminates after having explored at most C∈CL (|B(C)|+1)·|C| states. Upon termination all states reachable from the initial state have been explored at least once. Proof. Let E(i) denote the equivalence classes completely explored after i iterations of the loop in lines 1-7 of Sweep. The following loop invariant holds: E(i) is downwards closed, GlobalUnprocessed = out(E(i)), and |E(i)| = i. Before the first iterations (i = 0), E(0) = ∅ and hence is trivially downwards closed, out(E(0)) = {ι} by the definition of out, and |E(0)| = 0. Assume that the invariant is valid before the i+1’th iteration, and let R be the set of states chosen by at line 2. By the definition, R ⊆ C for some equivalence class C, and the states in R are minimal with respect to m in GlobalUnprocessed. By Prop. 2(23) (with X = E(i)), in(C) ⊆ out(E(i)) = GlobalUnprocessed. Since line 2 of Sweep ensures that R contains all states in GlobalUnprocessed which are in C, in(C) = R. Hence by Lemma 1 the call to ColumnSweep in line 4 explores all of C. Since C is now explored, E(i + 1) = E(i) ∪ {C}. Since C is minimal in over(E(i)) by Prop. 2(2), E(i + 1) is downwards closed by Prop. 2(1). Since C ∈ over(E(i)), we have C ∈E(i). Hence |E(i + 1)| = |E(i)| + 1 =
A Compositional Sweep-Line State Space Exploration Method
337
i+1. Since R is removed from GlobalUnprocessed, and ColumnSweep adds out(C) to GlobalUnprocessed by Lemma 1, we have GlobalUnprocessed = out(E(i)) − R ∪ out(C). The monotonicity of m and C ∈E(i) ensures that C ∈E(i) C ∩ out(C) = ∅, and hence that out(E(i)) − R ∪ out(C) = out(E(i + 1)). The number of equivalence classes are finite, and since the size of E(i) grows by one in each iteration of the loop in lines 1-7 of Sweep we eventually have: E(i) = CL . In this case GlobalUnprocessed = out(E(i)) = ∅ by the definition of out, and the loop will eventually terminate with all equivalence classes having been explored. Each iteration of the loop explores a new equivalence C using ColumnSweep. The number of states explored when exploring the equivalence class C is bounded by (|B(C)| + 1) · |C| by Lemma 1. The total number of states explored by Sweep is hence bounded by C∈CL (|B(C)| + 1) · |C|.
5
Computing Component Progress Measures
This section presents our initial approaches for automatically computing progress measures for the components LTSs. We present two algorithms: one for obtaining a monotone progress measure based on strongly connected components, and one for obtaining a non-monotone progress measure based on spanning trees. Both algorithms have a time and space complexity which is linear in the size of the component LTS for which the progress measure is being computed. Strongly Connected Components. A monotone progress measure for a component LTS can be obtained by viewing the LTS as a directed graph and computing the strongly connected component (SCC) graph using e.g, Tarjan’s algorithm [15]. The associated progress mapping ψscc maps each state s into the SCC scc(s) to which it belongs. The partial order scc on progress values is determined by the reachability relation on the SCC graph, i.e., ψscc (s) scc ψscc (s ) if and only if s ∈ reachL (s). The relation scc is a partial order since the SCC graph is a directed acyclic graph. The progress measure is monotone since ψscc preserves reachability. The progress measure obtained using SCCs is optimal for monotone progress measures in the sense that all states in the same SCC must have the same progress value as a consequence of the definition of monotone progress measures. Hence, the progress measures based on SCC give the finest partitioning of the states of all monotone progress measures. However, the SCC based progress measure gives only the trivial progress measure if the component LTS itself is strongly connected, i.e., all its states belong to the same SCC. Spanning Tree. The SCC based algorithm for monotone progress measure above is highly dependent on the component LTSs having many small SCCs. If too large SCCs exist, a non-monotone progress measure might give a better reduction of peak memory usage. A non-monotone progress measure can be obtained by computing a spanning tree for the component LTS using e.g., a depth-first search.
338
L.M. Kristensen and T. Mailund
The reachability relation on the spanning tree determines the partial ordering in a similar way as for the SCC algorithm. A topological ordering of the nodes in the spanning tree gives the non-monotone progress measure consistent with the reachability relation on the spanning tree. Each edge not in the spanning tree will be treated as a regress-edge.
6
Experimental Results
A prototype [11] has been developed to conduct some initial experiments with the compositional sweep-line algorithm. This prototype consists of three programs. A program pslc for compiling process specifications into labelled transitions systems, a program progress implementing the two algorithms in Sect. 5 for computing progress measures for subcomponents, and a program sweepcheck implementing the algorithm in Fig. 5. The sweepcheck program implements the CSP [5] parallel composition operator. The deletion of states is handled by keeping track of which column each state belongs to. When the next unprocessed state selected has a progress value which is larger (wrt. to the non-monotone components) than the previous unprocessed state selected, all non-persistent states in the current column are deleted. We present experimental results obtained with this prototype on three smaller examples, and we compare the use of the sweep-line method with the use of ordinary full state space exploration, and with the use of the state space caching method [7]. The three examples are available from [11]. The experiments were conducted on a 1 Ghz Linux PC with 1 Gb of RAM. Master/Slave System. This example consists of a master process and a number of slave processes. The master process initially manages a set of jobs that it assigns to the slaves. Since the master process progresses with each job assigned, the SCC algorithm has been used to compute a monotone progress measure for the master. The slaves are all reactive, i.e., they return to their idle state after having completed a job. Hence they only have a single SCC, and the spanning tree algorithm was used to compute a non-monotone progress measure. The performance of full state space exploration of the master/slave system is shown to the left in Table 1 for different number of jobs processed by 12 slaves. The reduction obtained with the sweep-line method is shown to the right in the table. The Total column shows the number of states processed by the sweep-line method relative to the total number of reachable states. The Peak column shows relative memory usage of the sweep-line method compared to the full state space, i.e., the peak number of states stored divided by the total number of states in the full exploration. As seen from the Time columns, the reduction comes at a minor runtime penalty. This is due to the larger number of states processed and the overhead in deletion of states. Two-Phase Commit Protocol. The two-phase commit protocol consists of a single initiator process and a number of voter processes. The initiator process initiates an election on whether to commit or abort a transaction. The voters then decides
A Compositional Sweep-Line State Space Exploration Method
339
Table 1. The master/slave system with 12 slaves. Config. 20 jobs 24 jobs 28 jobs 34 jobs 40 jobs
Full State Space States Time 126,976 00:00:14 159,744 00:00:18 192,512 00:00:23 241,664 00:00:29 290,816 00:00:36
Sweep-Line Total Peak Time 200% 6.45% 00:00:24 200% 5.13% 00:00:30 200% 4.26% 00:00:36 200% 3.39% 00:00:46 200% 2.82% 00:00:55
locally whether to vote for commit or abort, and the initiator collects the votes. In this example, both the initiator and the voters have non-trivial SCCs. The SCC based algorithm has therefore been used on all subcomponents to compute the progress measures. Table 2 compares full state spaces exploration to the sweep-line method for different configurations. The independence of voters, together with the broadcast nature of the communication from initiator to voters, causes the state space to grow in width more than in depth as the number of voters increases. Consequently, the relative reduction obtained with the sweep-line method becomes smaller as the number of voters grows. Table 2. The two-phase commit protocol. Full State Space Config. States Time 6 slaves 18,478 00:00:01 7 slaves 87,475 00:00:08 8 slaves 420,988 00:01:08 9 slaves 2,051,029 00:15:46
Total 100% 100% 100% 100%
Sweep-Line Peak Time 21.16% 00:00:02 22.33% 00:00:10 23.19% 00:01:20 23.81% 00:20:46
Stop-and-Wait Protocol. This example is a stop-and-wait data-link protocol, where a sender process sends packets attached with sequence numbers over an unreliable network to a receiver process. All processes in this system are cyclic, and the spanning tree algorithm was used to obtain non-monotone progress measures. Table 3 compares of the sweep-line method with full state space exploration for different values of the maximal sequence number. State Space Caching. The state space caching method resembles the sweep-line method in that it deletes states on-the-fly in order to reduce peak memory usage. State space caching conducts a depth-first exploration of the state space, and allows states not on the depth-first stack to be deleted. To compare the two methods, we have implemented the state space caching method in our prototype tool, and tried it on the three examples above for different cache sizes. The time/space trade-off for different systems, configurations, and different choices
340
L.M. Kristensen and T. Mailund Table 3. The stop-and-wait protocol. Config. 20 30 40 50
Full State Space States Time 3,640 00:00:01 5,460 00:00:01 7,280 00:00:02 9,100 00:00:04
Sweep-Line Total Peak Time 103.84% 61.73% 00:00:01 103.84% 61.48% 00:00:01 103.84% 61.36% 00:00:02 103.84% 61.29% 00:00:04
of cache size is plotted in Fig. 6. For all three examples, the state space caching methods runs in time comparable to ordinary full state space exploration for large cache sizes. Its performance, however, quickly degenerates, when the size of the state cache is reduced. The performance degradation of state space caching has been observed before, and partial-order reduction has been used to alleviate this problem [3]. We have not added partial-order reduction to our prototype. Both the sweep-line method and state space caching will, however, benefit from the use of partialorder methods. We leave it for future work to investigate the relative impact of partial-order methods on the sweep-line method and the state space caching method. Compared to pure state space caching, the sweep-line method appears to provide a better time/space trade-off.
7
Conclusion and Future Work
We have presented a sweep-line algorithm applicable in a compositional framework where the components of the system are represented as labelled transition systems (LTSs). The key idea was to automatically compute progress measures for the component LTSs and compose these to obtain a progress measure for the full system. In addition, the developed sweep-line algorithm exploits that some components have monotone progress measures and some components have non-monotone progress measures. We have given algorithms based on strongly connected components and spanning trees for computing monotone and nonmonotone progress measures for the component LTSs. Better progress measures can possibly be obtained by combining the two using spanning trees to split large strongly connected components. We have assumed that the system considered was a parallel composition of components represented as LTSs. It is, however, only the computation of progress measures for the components of the system which relies on the representation of the components in the form of LTSs. The compositional sweep-line algorithm itself can be applied independently of the origin of the progress measure for the components. This means that the algorithm is applicable for any system S = S1 · · · Sn which is a parallel composition of subsystems Si , and where the states of the full system S is a vector of states with an entry for each subsystem. This means that our results are applicable to many modelling and specification languages for concurrent systems, such as for instance Promela used in the
A Compositional Sweep-Line State Space Exploration Method
341
I 50
100
150 PeaK no itifei (x1000)
200
250
300
(a) MasterISlave system.
PeaK no itifei (x1000)
(b) Tw-phase commit protocol
(c) Stop-and-wait protocol.
Fig. 6. Timelspace trad-off for state space caching and the sweep-line methods. The graphs shows, for different systems and configurations, the time and space usage of the sweep-line method and the state space caching method for different cache sizes. With smaller cache sizes the peak memory usage is smaller than for larger cache sizes, but at a significant runtime penalty. The sweep-line method reduces memory usage at a much lower runtime penalty.
342
L.M. Kristensen and T. Mailund
SPIN tool [6]. Processes (subsystems) in Promela are specified in a C like language. In this case it seems possible to compute progress measures based on, e.g., the control flow in the individual processes. In other formalisms such as timed automata networks as used in, e.g., the UPPAAL tool [10], a progress measure for the individual timed automata could possibly be computed based on the locations of the automata. Details of computing progress measure for processes in various modelling formalisms are left for future work. The sweep-line algorithm as presented is aimed at checking reachability properties as it explores all reachable states of the system at least once. It can however be observed that if all progress measures of the components are monotone progress measure, then all states of a cycle in the state space will have the same progress value, and hence all states in a cycle will reside in memory simultaneously at some point. This can be exploited for conducting Linear Temporal Logic (LTL) model checking, which can formulated as searching for cycles in the composition of two B¨ uchi automata [18]. This means that the compositional approach presented in this paper can be used to develop an LTL model checking algorithm capable of exploiting the graph structure of the B¨ uchi automata expressing the LTL property to be checked. Details of this is left for future work. Future work also involves techniques for generation of error traces with the sweep-line method. A trace leading from, e.g., the initial state to a state satisfying a given predicate cannot immediately be obtained with the current version of the sweep-line method due to the deletion of states. Acknowledgements. The authors would like to thank Michael Westergaard for assisting in the implementation of the prototype. Jens Bæk Jørgensen, Lisa Wells, and the anonymous reviewers for constructive comments on this paper.
References 1. S. Christensen, L.M. Kristensen, and T. Mailund. A Sweep-Line Method for State Space Exploration. In Proc. of TACAS’01, volume 2031 of LNCS, pages 450–464. Springer-Verlag, 2001. 2. E. M. Clarke, T. Filkorn, and S. Jha. Exploiting Symmetries in Temporal Logic Model Checking. In Proc. of CAV’93, pages 450–462. Springer-Verlag, 1993. 3. P. Godefroid, G.J. Holzman, and D. Pirottin. State Space Caching Revisited. In Proc. of CAV’92, volume 663 of LNCS, pages 178–191. Springer-Verlag, 1992. 4. S. Gordon, L.M. Kristensen, and J. Billington. Verification of a Revised WAP Wireless Transaction Protocol. In Proc. of ICATPN’02, volume 2360 of LNCS, pages 182–202. Springer-Verlag, 2002. 5. C.A.R Hoare. Communicating Sequential Processes. Prentice-Hall, 1985. 6. G.J. Holzmann. Design and Validation of Computer Protocols. Prentice-Hall International Editions, 1991. 7. C. Jard and T. Jeron. Bounded-memory Algorithms for Verification On-the-fly. In Proc. of CAV’91, volume 575 of LNCS, pages 192–202. Springer-Verlag, 1991. 8. L.M. Kristensen and T. Mailund. A Compositional Sweep-Line State Space Exploration Method. Technical report, Department of Computer Science, University of Aarhus, 2002. Available via: www.daimi.au.dk/˜mailund/ps/lmktm_compo.ps.
A Compositional Sweep-Line State Space Exploration Method
343
9. L.M. Kristensen and T. Mailund. A Generalised Sweep-Line Method for Safety Properties. In Proc. of FME’02, volume 2391 of LNCS, pages 549–567. SpringerVerlag, 2002. 10. K.G. Larsen, P. Pettersson, and W. Yi. Uppaal in a Nutshell. International Journal on Software Tools for Technology Transfer, 1(1+2):134–152, October 1997. 11. T. Mailund. SweepChecker. http://sweepchecker.sourceforge.net. 12. K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993. 13. R. Milner. Communication and Concurrency. Prentice-Hall International Series in Computer Science. Prentice-Hall, 1989. 14. D. Peled. All from One, One for All: On Model Checking Using Representatives. In Proc. of CAV’93, volume 697 of LNCS, pages 409–423. Springer-Verlag, 1993. 15. R. Tarjan. Depth-First Search and Linear Graph Algorithms. SIAM Journal of Computing, 1(2):146–160, 1972. 16. A. Valmari. Stubborn Sets for Reduced State Space Generation. In Advances in Petri Nets ’90, volume 483 of LNCS, pages 491–515. Springer-Verlag, 1990. 17. A. Valmari. Compositionality in State Space Verification Methods. In Proc. of ICATPN’96, volume 1091 of LNCS, pages 29–56. Springer-Verlag, 1996. 18. M. Vardi and P. Wolper. An Automata-Theoretic Approach to Automatic Program Verification. In Proc. of IEEE Symposium on Logic in Computer Science, pages 322–331, 1986. 19. P. Wolper and P. Godefroid. Partial Order Methods for Temporal Verification. In Proc. of CONCUR’93, volume 715 of LNCS, pages 233–246. Springer-Verlag, 1993.
On Combining the Persistent Sets Method with the Covering Steps Graph Method Pierre-Olivier Ribet, Fran¸cois Vernadat, and Bernard Berthomieu LAAS-CNRS 7 avenue du Colonel Roche F-31077 Toulouse cedex – France {ribet,vernadat,berthomieu}@laas.fr
Abstract. Concurrent systems are commonly verified after computing a state graph describing all possible behaviors. Unfortunately, this state graph is often too large to be effectively built. Partial-order techniques have been developed to avoid combinatorial explosion while preserving the properties of interest. This paper investigates the combination of two such approaches, persistent sets and covering steps, and proposes partial enumeration algorithms that cumulate their respective benefits. Keywords: Concurrent systems, state space exploration, partial-order, persistent sets, covering steps graph, verification methods
1
Introduction
State space derivation constitutes the preliminary step of many verification methods for concurrent systems. The state space is then analyzed by available efficient and automatic verification techniques, such as bisimulation and model-checking. The combinatorial explosion is the main limitation of these approaches. The partial order techniques (see [GW93,Pel98] for a survey) are the framework of the approach developed in this paper. Their basic principle is to consider a single specific path among all the sequences which possess the same Mazurkiewicz trace [Maz86]. In the case of persistent sets [WG93], only a subset of enabled transitions is examined, the derived graph is then a subgraph of the whole graph. In the case of covering steps [VAM96], all the transitions are considered, but independent events are put together to build a single transition step, the firing of this transition step is then atomic. This paper investigates how these two methods can be used together, and compares their combined use with that of the persistent sets or covering steps alone. This paper focuses on deadlock detection. The main contribution of this paper is a partial order method combining the respective advantages of the persistent set and covering step graph methods. A general algorithm combining persistent set and transition steps is proposed, that, for deadlock detection, improves available persistent sets and covering steps based techniques. A specific instance of this algorithm is given and studied on different examples. Section 2 recalls the necessary basic notions and the persistent sets and covering steps graph constructions. A general algorithm combining persistent sets D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 344–359, 2002. c Springer-Verlag Berlin Heidelberg 2002
On Combining the Persistent Sets Method
345
and steps is described in Section 3, together with the proof that it preserves deadlocks. Section 4 presents some computing experiments.
2
Partial Order Methods
2.1
Basic Notions
Definition 1. A Labeled Transition Systems (LTS) is a quadruple Σ =< S, so , T, →> where: S is a set of states, s0 a distinguished state in S , T is a set of transition labels, → is a set of labeled transitions (→⊂ S × T × S). t
The following notations will be used: s−− → s iff (s, t, s ) ∈→. We say that t is t
t
enabled in s (noted s −− →) iff ∃s ∈ S : s −− → s . Conversely t is not enabled t
t
(noted s− − →) iff ¬(s−− →). The set of all enabled transitions in a state s is noted t1
w
t2
Enabled(s). ∀w ∈ T ∗ , w = t1 t2 . . . tn : s0 −− → sn iff s0 −− → s1 ∧ s1 −− → s2 ∧ . . . ∧ tn
sn−1−− → sn Definition 2. Independence Relation [GW93]: is an independence relation t1
t2
over T iff ∀s, s1 , s2 ∈ S, ∀t1 , t2 ∈ T : (t1 = t2 ∧ s−− → s1 ∧ s−− → s2 ∧ t1 t2 ) ⇒ t2
t1
(s1−− → s ∧ s2−− → s ) If t1 t2 and both t1 and t2 are enabled in s then they can be fired in any order from s, and both sequences t1 t2 and t2 t1 lead from s to the same state s . This property is called the forward diamond property: independent transitions commute. The independence relation is extended from transition labels to sets of transition labels by ∀E1 , E2 ⊆ T, E1 E2 iff ∀(t1 , t2 ) ∈ (E1×E2 ) : t1 t2 . For sequences of transition labels, we note: ∀w1 , w2 ∈ T ∗ , w1 w2 iff ||w1 || ||w2 || where ||w|| is the set of transition labels occurring in sequence w. In the sequel, we will simply talk of transitions, instead of transition labels, when no ambiguity arises. The complement of relation is the conflict or dependence relation, denoted #. Its transitive closure [#] is the weak conflict relation, it is an equivaC lence relation. The complement [#] of relation [#] is the strong independence C relation. We have # ⊂ [#] and [#] ⊂ . The function [#](t) = {t |t [#]t} is the set of all transitions conflicting with t. Transition t is conflict free iff [#](t) = {t}. Definition 3. Two sequences of transitions are equivalent if they can be obtained from each other by successive permutations of adjacent independent transitions. Equivalent sequences are called (Mazurkiewicz) traces [Maz86]. The trace containing sequence w is denoted [w]. w1
w2
Proposition 1. If s0−− → s1 , s0−− → s2 , and [w1 ] = [w2 ], then s1 = s2
346
P.-O. Ribet, F. Vernadat, and B. Berthomieu
This property is used in most partial order methods. Intuitively it implies that, to check some property, it is generally not necessary to explore the entire state graph when some transitions are independent. Exhaustive
Persistent set 1 path / Trace
Step 1 set / Trace
e1 e3 e1 e2
e3
e2 e2
e3
e3
e2
e1
e1
{e1 , e2 , e3 }
e2
e3
e1 2n states n×2 transitions
n + 1 states n transitions
n−1
2 states 1 transition
Fig. 1. State graphs obtained for 3 independent transitions
As a simple example, consider a system made of three independent transitions. Its state space is the cube shown in Figure 1. Proposition 1 implies that there is only one terminal state. The persistent sets method will explore only one path from the initial to the final state. With the covering steps method, all three transitions will be fired simultaneously to reach that state in a single step.
p4 p2
t2
t1 t6
p9 p3
p11
t0 p0
t5
p1
p10 t3 p5
t4 p6
p7
p8
Fig. 2. Example Petri net
Structural independence relations: Availability of some independence relation is a prerequisite to apply partial order techniques. Computing the weakest such relation is in general impossible, however. Instead, one generally relies on stronger independence relation deduced from structural properties of the system
On Combining the Persistent Sets Method
347
[GP93]. A structural approximation of the independence relation for Petri nets is the following: t1 s t2 iff • t1 ∩ • t2 = ∅ [Rei85]. The Petri net represented in Figure 2 will be used to illustrate the exploration algorithms proposed in this paper. It exhibits parallelism with t3 and t4 , conflict with t0 #t1 and t5 #t6 , and confusion [Rei85] with t0 and t1 . 2.2
State Space Derivation
Table 1 gives a state space derivation algorithm. It is similar to a breadth-first standard exploration algorithm. Queue is a stack allowing to store the states to be explored. G represents the set of labeled transitions and H is the set of explored states (respectively named → and S in definition 1). Applying this algorithm to the Petri net of Figure 2 builds an exhaustive graph, which admits 60 states and 160 transitions, and includes 4 deadlocks. The function develop Exhaustive() (state exploration) described on Table 1, consists of firing all enabled transitions in a state, and adding all new states to the graph. In the sequel, each partial exploration algorithm is obtained by defining a new function develop name() to replace function develop Exhaustive(). Table 1. State space derivation Queue ← s0 H ← {s0 } G ← ∅ /* computed graph */ while N otEmpty(Queue) do s ← dequeue(Queue) if Enabled(s) = ∅ then print “Deadlock else develop exhaustive(Enabled(s))
2.3
develop exhaustive(E): for each t in E do s ← f ire(s, t) G ← G ∪ {< s, t, s >} if s ∈H then H ← H ∪ {s } enqueue(Queue, s )
Persistent Sets
Persistent sets are particular stubborn sets [Val88a] in which all transitions are enabled. Standard persistent sets exploration preserves deadlocks; numerous extensions have been proposed to preserve richer properties [Val90,GW93,Pel93]. Definition 4. Persistent sets [WG93]: A set P of transitions is persistent in a state s iff all transitions not in P that are enabled in s or in states reachable from s by firing transitions not in P , are independent of all transitions in P , that is iff: t
∗
w
∀t ∈ P : s−− → and ∀w ∈ P : s−− → s ⇒ ||w|| P .
348
P.-O. Ribet, F. Vernadat, and B. Berthomieu
A persistent set contains at least all transitions that have to be explored in a specific state in order to discover all potential deadlocks. If P is a persistent set in s, then no transition of P can be disabled by any sequence of firings of transitions not in P . Note that the set Enabled(s) is always persistent in s. Persistent set Graph algorithm (algorithm P G) : A generic exploration algorithm taking advantage of persistent sets is shown in Table 2, where the new function develop P G() substitutes develop exhaustive() in Table 1. It is similar to a standard state exploration except that the set of transitions to be fired from state s is determined from some function A(E). Function A(E) returns a persistent set in s. Table 2. Generic persistent set graph algorithm (P G) develop PG(E): P ← A(E) develop exhaustive(P )
Proposition 2. P G exploration preserves deadlock states[Val88a] Computation of persistent sets: A common approach consists of choosing the persistent set as small as possible. In the general case, we don’t know how to compute the minimal persistent set, but different approximations to choose this persistent set have been proposed [God90,Ove81,Val89]. As pointed out by [Val88b], minimising branching is a local optimisation; in some cases, the choice of a larger set may result in a smaller final graph, that’s why the choice of a minimal persistent set is only a heuristic. This instance of the P G will be referred to as the Pmin G algorithm in the sequel. Applying Pmin G to our example net of Figure 2 produces the graph given in Figure 3. In state s0 , transitions t0 , t1 , t2 , t3 , t4 , t5 and t6 are enabled. Because [#](t2 ) ⊆ Enabled(s0 ), this set is persistent, and only transitions in this set [#](t2 ) = {t2 } need to be fire.
t4 s4
t4 s3
s0
s8
s9
t5
t5 t3
t3
t2
t6
t6
s6
s11 t1 s5
s2
t0 s1
s7
s10
Fig. 3. Pmin G: P G computed with minimal branching strategy
On Combining the Persistent Sets Method
349
It is important to notice that a set of enabled transitions generally admits several distinct persistent sets, possibly of different cardinality. In state s0 other persistent sets could be chosen for example: {t3 }, {t4 }, {t0 , t1 }, {t5 , t6 } or any union of these sets. Hence, for computing the smallest one has to examine all subsets of enabled transitions as possible candidates for persistent sets [Val89]. Further, if several persistent sets are minimal, the choice of one becomes arbitrary. 2.4
Covering Step Graph
Covering step graphs were introduced in [VAM96]. In a covering step graph, all transitions are visited, but independent events are grouped to constitute a single transition step, the firing of this step is then atomic. Covering step graphs preserve global reachability properties such as liveness (in the Petri net sense [Rei85]) or presence of deadlock [VAM96]. The method can be specialised for checking specific properties such as weak bisimulation [VAM96] or testing equivalence [VM97]. Definition 5. A transition set π defines a transition step wrt iff ∀t1 , t2 ∈ π : t1 t2 . Step(T, ) denotes the set of transition steps derived from T wrt . The reachability relation → is extended to transition steps by: ∅
π
e
π \ {e}
s∼>s, and ∀s, s ∈ S, π ∈ Step(T, ) : s∼>s iff ∀e ∈ π : s−− → se ∧se ∼∼∼∼>s The diamond property (definition 2) can be generalised to transition sequences and steps [VAM96]. Definition 6. Covering step graph : Let Σ =< S, so , T, →> be a LTS, an independence relation over Σ, and # = C . ΣR =< SR , so , TR , ∼>R > is a covering step graph wrt , iff (1) SR ⊆ S (2) TR ⊂ Step(T, )
π
π
(3) ∀s, s ∈ SR , ∀π ∈ TR : s∼∼>R s implies s∼∼>s (4) ∀s ∈ SR , ∀s ∈ S, ∀w ∈ T ∗ : ∃s” ∈ SR , ∃w ∈ T ∗ , ∃πw.w ∈ TR∗ : w s−− → s implies w πw.w s−− → s”, s∼∼∼∼>R s” and [w.w ](T,#) = [πw.w ](T,#) Condition (1) means that each state of the step graph is a state of the standard LTS. Condition (2) defines CSG transitions as steps. Condition (3) means that each step in the CSG corresponds to a firing sequence in the standard LTS. Finally, condition (4) expresses a “covering condition” between firing sequences of the standard LTS and step sequences of the CSG: Every sequence in the LTS
350
P.-O. Ribet, F. Vernadat, and B. Berthomieu
can be extended so that it is covered by a step sequence in the CSG. Note that all linearisation sequences of a step have the same Mazurkiewicz trace, and so [π] is trivially defined. Any LTS may be seen as a CSG by taking = ∅. Another way to approach covering step graph, is to consider trace automata introduced in [God90,God96]. A trace automaton can be obtained easily from a CSG. Each step has to be replaced by states and sequence of transitions, corresponding to a possible linearisation of this step. Trace automaton can be seen as an “unfolding” of a covering step graph. Covering step graph derivation : An algorithm for computing the CSG is given in Table 3. The algorithm is implicitly parameterised by an independence relation . The enabled transitions are split into two subsets by means of functions TU and TM . Tu holds the transitions to be explored in the standard way, and Tm holds those whose exploration will be conducted within a step, referred to as the “mergeable” transitions in the sequel. ΠTm is the set of transition steps, built by function Π. Table 3. Generic covering step graph algorithm develop CSG(E): Tu ← TU (E, ) Tm ← TM (E, ) develop exhaustive(Tu ) ΠTm ← Π(Tm , ) develop by step(ΠTm )
develop by step(Π): for each π in Π do s ← step f ire(s, π) G ← G ∪ {< s, π, s >} if s ∈H then H ← H ∪ {s } enqueue(Queue, s )
Requirements for TU , TM and Π are expressed in proposition 3. Table 4 provides a specific definition for these functions. Function develop by step(Π), defined in Table 3, is similar to function develop exhaustive(E) (Table 1), except that intermediate states are not stored. All transitions of the step are fired by the function step f ire(). Proposition 3 (Conditions for Tu , Tm and ΠTm ). Under the following conditions, the algorithm in Table 3 produces a covering step graph [VAM96]. (CA1 ) Tm ∪ Tu = Enabled(s) and Tm ∩ Tu = ∅ (CA2 ) if t ∈ Tm then t [#]t ⇒ t ∈ Enabled(s) ∀s ∈ S: C (CB1 ) ∀π ∈ ΠTm : π ∈ Step(Enabled(s), [#] ) C (CB2 ) ∀P ∈ Step(Enabled(s), [#] ), ∃π ∈ ΠTm : P ⊆ π Step graph of crossed conflicts: Functions TU , TM and Π are defined on Table 4 [VAM96]. Function Π is defined using orthoproduct [PF90]. The orthoproduct of IE = {E1 , E2 , . . . En } is the set ΠC (IE) = {{e1 , e2 , . . . en } | (e1 , e2 , . . . en ) ∈ E1 × E2 . . . × En }. Applied on our example Fig. 2 this algorithm produces the CSG of Fig. 4. In the initial state s0 , the transition t0 can’t be merged in a step, because this
On Combining the Persistent Sets Method
351
Table 4. Function definitions for CSG using crossed conflicts TM (E, ) = {t ∈ E|t [#]t ⇒ t ∈ E} TU (E, ) = E \ TM (E, ) Π(E) = ΠC (E/[#])
transition is in conflict with a transition not enabled (t1 ) (this is the confusion case). Tu = {t0 }, Tm = {t2 , t3 , t4 , t5 , t6 }, Tm /[#] = {{t2 }, {t3 }, {t4 }, {t5 , t6 }}, ΠC (Tm /[#]) = {{t2 , t3 , t4 , t5 }, {t2 , t3 , t4 , t6 }}.
t2 t3 t4 t6 s4
t2 t3 t4 t5 s0
s6 t1
t1 t0 t0
s2
s5
t2 t3 t4 t6
s7
s1
t2 t3 t4 t5
t0
s3
Fig. 4. CSG using crossed conflicts
3
Persistent Steps, Combining P G and CSG
Persistent sets and covering steps contribute to the reduction of the state space by addressing different aspects. We propose in the sequel an exploration method taking advantage of both these techniques. Its correctness is proved, then its benefits in terms of state space reduction are discussed. 3.1
P SG Algorithm
A simple way to combine persistent sets and steps is to compute persistent sets as in the P G algorithm, and then to compute steps from them. Persistent sets are subsets of transitions whose exploration is sufficient to detect potential deadlocks, steps are used to fire all these transitions “together” when possible. The algorithm skeleton is shown in Table 5, referred to as the P SG (Persistent Step Graph) algorithm in the sequel. Its layout is similar to that of algorithm CSG in Table 3. They differ by the following: – P SG uses a persistent set computation function A(), as did P G (cf. Table 2); – Treatment of “unmergeable” transitions TU : Tm is empty when Enabled(s) admits no proper persistent subsets. In that case, an exhaustive exploration is performed, otherwise the transitions in TU are not explored;
352
P.-O. Ribet, F. Vernadat, and B. Berthomieu
– Treatment of “mergeable” transitions TM : In CSG, all transitions of TM were explored, only a subset of them, obtained by function A(), are explored in P SG. Table 5. Generic persistent step graph algorithm develop PSG(E): Tu ← TU (E, ) Tm ← TM (E, ) If Tm = ∅ Then develop exhaustive(Tu ) Else P ← A(Tm ) ΠP ← Π(P, ) develop by step(ΠP )
To use this algorithm we have to choose an instance, like for P G and CSG, for parameter functions A() and Π(). That is why from this generic algorithm a lot of exploration algorithm instances can be proposed. Some instances are studied in section 3.3 (Pmin SG), 3.4 (P Smax G) and 3.6 (HP SG). But first we prove that any instance of P SG preserves deadlocks. 3.2
Preservation of Deadlocks
The proof that the P SG preserves deadlocks of the state graph is similar to the one given for the CSG in [VAM96], it follows from a normalisation lemma. Normalisation operator N : Operator N extracts from all sequence w of enabled transitions in a state s, a maximal step or a maximal prefix of a such step. N : S × Step(T ) × T ∗ × T ∗ →Step(T ) × T ∗ is defined as follows: (E, w1 ) if w2 = ) if E ∈ Π(A(Tm )) (E, w1 .w2 ) N (s, E, w1 , w2 ) = N (s, E ∪ {t}, w1 , w ) if t w1 , E ∪ {t} ∈ Step(A(Tm ), [#]C ), and t ∈ / E with w2 = t.w N (s, E, w1 .t, w ) otherwise, with w2 = t.w w
Lemma 1 (Normalisation lemma). Let s ∈ S, w, w1 ∈ T ∗ such that s−− → s , N (s, ∅, ), w) = (E, w1 ) and F ∈ Π(A(TM )). Then E ⊂ F ⇒ (F \ E) w1 . w
Proof. Let s ∈ S, w, w1 ∈ T ∗ such that s −− → s , N (s, ∅, ), w) = (E, w1 ) and F ∈ ΠA(TM ) with E ⊂ F . We prove by contradiction that F \ E w1 : Let R = F \ E. Assume there exists t ∈ ||w1 || such that ∃tr ∈ R with t[#]tr , w1 = w .t.w , tr w .
On Combining the Persistent Sets Method
353
Then we have t w and t ∈ A(TM ). t w because tr w , t[#]tr , and [#] is transitive. t ∈ A(TM ) follows from the definition of persistent sets because tr ∈ A(TM ) and t[#]tr . There are two possible reasons why transition t was not added in E by the normalisation function N : Either t ∈ E therefore t ∈ F and then tr ∈ F , which leads to a contradiction because tr [#]t. Or ∃ tconf lict ∈ E such that tconf lict [#]t. C Then tr [#]tconf lict and {tr , tconf lict } ∈ Step(A(TM ), [#] , s) which also leads to a contradiction. Proposition 4. P SG exploration detects deadlocks Proof. Let Σ =< S, so , T, →>, be a LTS and an independence relation over Σ and # its complement. Let ΣR =< SR , so , TR , ∼>R > be a P SG obtained by the algorithm in Table 5. Assume there exists a deadlock state D. Let s be a state such that s ∈ SR w
with s−− → D (the initial state s0 is always a such state). That D ∈ SR is proved by induction on |w|: the property is obvious if |w| = 0. Assuming it holds for sequences of length k, let us prove it for any w of length k + 1. w
E
w1
Let (E, w1 ) = N (s, A(TM ), ∅, ), w) and so s−− → D and s∼>s−− →D 1. If E ∈ Π(A(TM )) then s ∈ SR : the induction hypothesis is then applied on w1
w1 with |w1 | ≤ k and s−− →D 2. Else, by construction of N , E ∈ Step(A(Tm ), ) therefore ∃F ∈ Π(A(TM )) (condition CB2 ) such that E ⊂ F and (F \ E) w1 (normalisation lemma 1). R
w1
Let R = F \E, then s ∼> and s−− → D with Rw1 . Diamond property implies R
D∼> which leads to a contradiction since D is a deadlock. 3.3
Comparison of P G and P SG
Proposition 4 establishes correctness of the P SG algorithm, independently of function A() for computing persistent sets. The following shows that, for each such function A(), the graph built by P SG is at most as large at that built by P G. Proposition 5. P SG generalises P G Proof. Any P G can be seen as an P SG: Taking Π(P, ) = {{t} | t ∈ P } in the P SG algorithm shown in Table 5, the graph generated is exactly that generated by the P G algorithm in Table 2, assuming both use the same function A(). So, clearly, the P SG may produce graphs whose size is smaller than those produced by P G. But not every P SG is the contraction of some P G. We investigate now a particular instance:
354
P.-O. Ribet, F. Vernadat, and B. Berthomieu
The minimising persistent set P SG algorithm, or Pmin SG for short, uses the same heuristic as Pmin G for persistent set exploration, that is it minimises local branching. Function A() is defined as follows: A(s) = if FE = ∅ then FE else [#](tmin ), where – FE is the largest subset of transitions of Enabled(s) which are conflict free. – tmin chosen in Enabled(s) so that minimises Card([#](t)) Note that, as Pmin G, Pmin SG is not deterministic (the choice between several minimal persistent set is arbitrary). Applying Pmin SG to our example produces the graph of Figure 5.
s6 t1
s7
s0
s3
t0
s4 t1
t0
t2 t3 t4 t5 s5
t6 s1
s2
Fig. 5. Pmin SG: P SG minimising persistent set
In the state s0 , transitions t2 , t3 , t4 are conflict free, and so A(s0 ) = FE = {t2 , t3 , t4 }, and on this set only one step is build. In states s2 or s5 we obtain FE = ∅ and chose A(s2 ) = A(s5 ) = [#](t0 ) = [#](t1 ) = {t0 , t1 }. Proposition 6. Every Pmin SG is the contraction of some Pmin G . Proof Sketch. We show how to build a Pmin G from a Pmin SG. For this we use the persistent set computation function defined for the Pmin SG to define a new function to build the Pmin G . When the set used in Pmin SG contains only conflict free transitions, any subset of it is persistent, and we can take persistent sets with one transition in each intermediate state. The proof that this set is minimal in each state is trivial, and the resulting graph is obviously larger. 3.4
Comparison of CSG and P SG
Conversely to P G exploration, P SG does not generalise CSG exploration. The possibility to avoid the exploration of “unmergeable transitions” (Tu ) allows to build smaller graphs than those obtained by CSG, however the covering property is lost. Let us introduce another instance of the P SG, maximising steps. The maximising steps P SG algorithm, or P Smax G for short, maximises steps, so more intermediate states are skipped. It uses A(s) = Enabled(s), as Tm must be as large as possible. The result of applying P Smax G to our example net is shown Figure 6.
On Combining the Persistent Sets Method
s2
355
s5 t1
t1 t2 t3 t4 t6 s1
t2 t3 t4 t5 s0
s4
t0
t0
s3
s6
Fig. 6. P Smax G: P SG maximising steps
Proposition 7. Any P Smax G graph is always smaller than CSG Proof Sketch. Since Tm is persistent, P Smax G does not fire the transitions in Tu . The graph obtained is then clearly a proper subgraph of the CSG.
3.5
Theoretical/Practical Point of View
In sections 3.3 and 3.4, we have proved that the P SG technique is more general and more efficient than P G and CSG techniques. From a theoretical point of view, these results could be satisfactory. Nevertheless, from a practical point of view, like for P G, we have to consider a specific instance of P SG. We have proposed the Pmin SG instance to generalise Pmin G (and generally how to generalise a P G instance), and the P Smax G instance to improve CSG. But ideally we would like an instance of the P SG better than P G and CSG. Is it possible to find a P SG instance which is deterministic and uses steps systematically, improving all possible persistent set and covering step explorations? Unfortunately the answer is negative. We consider the Petri net of Figure 7, made up of unconnected components Loop, N0 , N1 , ... Nn , to illustrate that such a P SG is impossible.
... P0
name Loop
0 P0 1 P0 n
P0
0
0 T0
P1
1
1 P1
T0 n
T0
N0
0
Pk0
0 Tk0
. . .. . .
1
T k1 . . .. . .. . . n
P1
N1
1 P k1 n
T kn
Nn n
P kn
Fig. 7. Comparison of Pmin SG and Pmin G
The optimal Pmin G explorations begins with component Loop, it has 1 state and 1 transition. The worst case is obtained when exploration terminates by
356
P.-O. Ribet, F. Vernadat, and B. Berthomieu
i=n Loop, the Pmin G graph admits then Σi=0 ki + 1 states. In an implementation, this non determinism would be typically resolved by choosing some ordering on transitions, the graph size would depend on the ordering choosen. On the following example (Figure 7), if steps are build, then the transition ”name” will be merged in a step, and so we can’t be as good as the best case of Pmin G. In that case, the benefit of the “ignoring problem” [God96] is lost because of steps.
3.6
A Hybrid P SG
Algorithms Pmin SG and P Smax G only differ by their persistent set computation functions, that returns a minimal set in the former algorithm, and the full set of enabled transitions in the second. There is a full range of P SG algorithms between these. The heuristic proposed in the HP SG below has the advantage of being deterministic in the sense that the graph size does not follow from an arbitrary choice of the persistent set. The Hybrid P SG algorithm, or HP SG for short, uses the following: A(s) = if FE = ∅ then FE else Enabled(s) where FE is the largest subset of transitions of Enabled(s) which are conflict free. The resulting graph for our example net is shown in Figure 8. Like for Pmin SG in Figure 5, all conflict free transitions are fired in first state s0 . Then in state s1 , A(s1 ) = Enabled(s) = {t0 , t1 , t5 , t6 } and ΠC ({{t0 , t1 }, {t5 , t6 }}) = {{t0 , t5 }, {t0 , t6 }, {t1 , t5 }, {t1 , t6 }}.
s5
s0
s2 t6 t1
t5 t0 t2 t3 t4 s3
t6 t0
s1
t5 t1
s4
Fig. 8. HP SG: Hybrid P SG
4
Summary of Experiments
Evaluation of the different exploration algorithms on our example are summarised in the following table. Note that all P SG strategies improve or equal both Pmin G and CSG methods. States T ransitions
Exhaustive Pmin G 60 12 160 11
CSG Pmin SG 8 8 9 7
P Smax G 7 6
HP SG 6 5
On Combining the Persistent Sets Method
357
These algorithms have been applied to models of significant size and practical interest. The first model is a version of Milner’s scheduler with 300 sites [Mil89], the second is a model of the dining philosophers problem with 8 philosophers. The third is the Data base system presented in [Jen86] and used in [Val89]. The fourth example is a token ring with 10 stations [Cor96]. The fifth model is NaimiTrehel distributed mutual exclusion model with 5 sites [NT87], where neither persistent or covering step tackles the explosion. The sixth model is defined in [ZDD93,CX97] to represent a Manufacturing system. The seventh example, describes Asynchronous Buffer[Pel93]. The results are summarised in Table 6. Pmin G provides a smaller graph than CSG for Philosopher, Naimi-Trehel and Manufacturing system examples while CSG is better for the other examples (Milner’s scheduler, Data Base, Token Ring and Asynchronous Buffer). For all these examples, HP SG builds a smaller graph than both Pmin G and CSG. Table 6. Algorithm comparison. Legend: states number 1 2 3 4 5 6 7
M odel Exhaustive Pmin G CSG HP SG Scheduler 300 2n ∗ n ≈ 6.1092 1 394 301 301 P hilosopher 8 103 681 233 31 231 227 Data base 10 196 831 191 31 31 T oken Ring 10 35 840 99 52 51 N aimi − T rehel 5 202 500 40 006 52 681 40 001 2 034 455 979 360 M anuf acturing system Asynchronous Buf f er 7 972 37 12 12
The last example is the Swimming Pool model used in [BF99]. This model is parametrised by an integer K representing both the number of available cabins and baskets. Table 7 gives the size of the explored graphs and their computation time. Table 7. Evaluation on the Swimming Pool example. Legend:states number h:min:sec K Exhaustive Pmin G CSG HP SG 10 7 006 0 : 00 : 01 857 0 : 00 : 00 367 0 : 00 : 00 87 0 : 00 : 00 235 X − 4 602 707 9 : 47 : 00 219 742 0 : 01 : 32 2 112 0 : 00 : 01 240 X − X − 229 217 0 : 01 : 42 2 157 0 : 00 : 01 500 X − X − 997 517 0 : 31 : 08 4 497 0 : 00 : 02 600 X − X − X − 5 397 0 : 00 : 02 − X − X − 134 997 0 : 00 : 16 15 000 X 150 000 X − X − X − 1 349 997 0 : 13 : 30 200 000 X − X − X − 1 799 997 0 : 24 : 11
On this example the HP SG algorithm really improves both the Pmin G and CSG. The exhaustive computation fails from K = 50 while partial explorations
358
P.-O. Ribet, F. Vernadat, and B. Berthomieu
succeed, Pmin G fails from K = 240 while CSG fails from K = 600. The size of the graph built by HP SG algorithm seems linear wrt K and HP SG succeeds until at least K = 200 000. For experiment purposes, these exploration algorithms have been implemented in a tool providing many other exploration algorithms for Petri nets or Time Petri nets. The tool is available for download at http://www.laas.fr/tina. Specific experiments not described here have shown that the run time overhead of HP SG is lower than that of the CSG, itself slightly greater than that of the P G.
5
Conclusion
This paper presents a partial order technique (persistent steps graphs) based on the well known persistent set and covering step methods. This technique is a generalisation of these methods. Persistent steps graph can ”simulate” and improve persistent set and covering step methods. However there is no persistent steps instance using steps, which is better in all cases than persistent sets, because persistent sets are non deterministic, and the ignoring phenomena benefit may be lost with steps. Nevertheless a deterministic instance gives interesting results on concrete examples: in practice the graph obtained is always smaller than the graph obtained with persistent sets and covering steps. The run time overhead is close to the that of persistent sets method. This paper concentrates on the problem of detecting reachable terminal states. Partial exploration methods have to be compared again for preservation of other classes of properties. For example the ignoring problem is an advantage for deadlock detection, but must be avoid for more general safety properties[God96]. Prospective work concerns the preservation of specific properties (safety and liveness) including a study of ample set [Pel98] and a comparison of trace automata obtained by persistent set and CSG.
References [BF99] [Cor96] [CX97] [God90]
B. B´erard and L. Fribourg. Reachability analysis of (timed) petri nets using real arithmetic. In Proceedings of CONCUR’99, pages 178–193. Springer Verlag, LNCS 1664, 1999. J. C. Corbett. Evaluating deadlock detection methods for concurrent software. IEEE Transactions on software engineering, VOL. 22(NO. 3), March 1996. F. Chu and X.Xie. Deadlock analysis of petri nets using siphons and mathematical programming. In IEEE Trans. on Robotics and Automation, volume 13, pages 793–804, 1997. P. Godefroid. Using partial orders to improve automatic verification methods. In Proceedings of CAV’90, pages 321–340. ACM, DIMACS volume 3, 1990.
On Combining the Persistent Sets Method [God96]
359
P. Godefroid. Partial-Order Methods for the Verification of Concurrent Systems. Springer Verlag, LNCS 1032, 1996. [GP93] P. Godefroid and D. Pirottin. Refining dependencies improves partial-order verification methods. In Proceedings of CAV’93. Springer Verlag, LNCS 697, 1993. [GW93] P. Godefroid and P. Wolper. Using partial orders for the efficient verification of deadlock freedom and safety properties. Formal Methods in System Design, 2(2):149–164, 1993. [Jen86] K. Jensen. Couloured petri nets. In Petri Nets : Central Model and Their Properties, pages 248–299. Springer-Verlag, LNCS 254, 1986. [Maz86] A. Mazurkiewicz. Trace theory. In Petri Nets: Applications and Relationships to Other Model of Concurrency, Advances in Petri nets 1986, Part II; Proceedings of an advanced Course, pages 279–324. Springer Verlag, LNCS 255, 1986. [Mil89] R. Milner. Communication and Concurrency. Prentice Hall, 1989. [NT87] M. Naimi and M. Trehel. An improvement of the log N distributed algorithm for mutual exclusion. In Proceedings of ICDCS’87, pages 371–377, Washington, D.C., USA, September 1987. IEEE Computer Society Press. [Ove81] W. T. Overman. Verification of concurrent systems: function and timing. PhD thesis, University of California, 1981. [Pel93] D. Peled. All from one, one for all: On model checking using representatives. In Proceedings of CAV’93, pages 409–423. Springer Verlag, LNCS 697, 1993. [Pel98] Doron Peled. Ten years of partial order reduction. In Proceedings of CAV’98, pages 17–28. Springer Verlag, LNCS 1427, 1998. [PF90] D. H. Pitt and D. Freestone. The derivation of conformance tests from lotos specifications. IEEE Transactions on Software Engineering, 1990. [Rei85] W. Reisig. Petri Nets : an Introduction. Springer-Verlag,EATCS, 1985. [Val88a] A. Valmari. Error detection by reduced reachability graph generation. In Proceedings of ATPN’88. Springer Verlag, LNCS 424, 1988. [Val88b] A. Valmari. State Space Generation: Efficiency and Practicality. PhD thesis, Tampere University of Technology, 1988. [Val89] A. Valmari. Stubborn sets for reduced state space generation. In Proceedings of ATPN’89. Springer Verlag, LNCS 483, 1989. [Val90] A. Valmari. A stubborn attack on state explosion. In Proceedings of CAV’90, pages 25–42. ACM, DIMACS volume 3, 1990. [VAM96] F. Vernadat, P. Az´ema, and F. Michel. Covering step graph. In Proceedings of ATPN’96. Springer Verlag, LNCS 1091, 1996. [VM97] F. Vernadat and F. Michel. Covering step graph preserving failure semantics. In Proceedings of ATPN’97. Springer Verlag, LNCS 1248, 1997. [WG93] P. Wolper and P. Godefroid. Partial-order methods for temporal verification. In Proceedings of CONCUR’93. Springer Verlag, LNCS 575, 1993. [ZDD93] M.C. Zhou, F. Dicesare, and A.A. Desrochers. A hybrid methodology for synthesis of petri net models for manufacturing systems. In IEEE Trans. on Robotics and Automation 8:3, pages 350–361, 1993.
Innovative Verification Techniques Used in the Implementation of a Third-Generation 1.1GHz 64b Microprocessor Victor Melamed, Harry Stuimer, David Wilkins, Lawrence Chang, Kevin Normoyle, and Sutikshan Bhutani Sun Microsystems Inc., 901 San Antonio Road Palo Alto, CA, 94303-4900, USA. Mail Stop: SUN03-315, {victor.melamed,harry.stuimer, david.wilkins, lawrence.chang, fred.lowe,kevin.normoyle, sutikshan.bhutani}@sun.com
Abstract. This paper presents an innovative tool used during the verification of the UltraSPARC #IIIi (TM) processor. UltraSparc #IIIi operates in a multi-processor environment. Verifying the robustness of the cache coherency maintaining parts of the design was one of the main challenges facing the functional verification team. The team adopted a combination of standard, “classic” techniques and methodologies, as well as some new innovative approaches. This mixture of old and new led to a well-balanced, robust verification flow which enabled finding the majority of the design problems (bugs) early in the pre-silicon stage of the project. This paper discusses an internal tool (Sniper) (patent pending) which increases the processor bus activity in a way which would uncover subtle coherency problems.
1
Architecture Overview
The UltraSPARC #IIIi processor is a third generation 64b 4-instruction issue SPARC(TM) RISC processor which supports high-end desktop workstations and workgroup servers with focus on higher system integration and cost reduction. The chip operates at 1.1GHz to 1.4GHz. The processor core uses a 14-stage pipeline described in [1,2,3] that supports the concurrent launch of up to six instructions which can consist of 2 integer operations, 2 floating point operations, 1 memory operation and 1 control transfer instruction.[5] On-chip, level 1 caches include 64KB 4-way data cache, a 32KB 4-way instruction cache, a 2KB 4way data prefetch cache, and a 2KB 4-way write cache. The instruction and data caches have data parity protection. The design includes a 1MB on-chip, (64B line size) level 2 cache that is used for both instruction and data caching. It implements a pseudo-random cache line replacement algorithm. The level 2 cache is a writeback, write-allocate cache, supporting the MOESI coherency protocol. [5] The proprietary 200MHz, 128 bit system interface (JBUS) enables processors and other bus agents to communicate via the shared address and data bus with 3.2GB/s maximum bandwidth.[5] The on-chip memory controller D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 360–363, 2002. c Springer-Verlag Berlin Heidelberg 2002
Innovative Verification Techniques
361
supports 133MHz double data rate (DDR1) SDRAM and provides 4.2GB/s per processor off- chip memory bandwidth. A JBUS to PCI bridge was designed simultaneously with the processor and provides access to IO devices which reside on a PCI bus.
2
Functional Verification Strategy
The team adopted a combination of standard, “classic” techniques and methodologies, as well as some new innovative techniques. This combination led to a well-balanced, robust verification flow which enabled catching the majority of the design problems (bugs) in the pre-silicon stage and increased the productivity of the verification team. The UltraSPARC #IIIi processor is binary compatible with previous SPARC processors, so the first natural step in the verification process was to port a significant set of existing Sparc assembly tests which were used to verify previous processors. Many new test cases were written manually but there was an emphasis on the usage of random test generators. Monitors were written to check the correctness of the internal and external interface protocols, as well as to detect internal conditions which were considered errors. This paper will focus on a tool (Sniper) used in the verification process to increase the processor bus activity in a way which would uncover subtle coherency problems. It is important to note that Sniper would not be effective without the strong foundation provided by the overall verification environment.
3
Sniper
Early on in the project the team realized the need for a programmable, high level bus functional model of UltraSparc #IIIi (TM) that could be instanced in our simulation environment (in place of multiple instances of the verilog model of the CPU) to generate system bus traffic. This high-level model, written in C++, was called a Simulated JBUS Master (SJM), and models a JBUS compliant processor with a MOESI coherent cache. A simple command language controls the SJM’s behavior to provide a very flexible stimulus generator for our verification environment. Sniper is a tool which was built on top of SJM. The tool works by keeping a history table of the transactions on the processor bus (JBUS) and occasionally issuing transactions to increase the stress on the bus. The transactions issued by Sniper use addresses which are closely correlated to the addresses which appeared on the JBUS previously. They are also non-destructive, meaning that the Sniper generated transactions never modify the data that they access. Sniper can be tuned through configuration files. The main configuration parameters are: frequency of transaction injection, length of history table, types of transactions that Sniper is allowed to issue and address generation algorithms based on the address history. Typically, Sniper chooses an address from the address history table (either randomly or the N-th oldest address) and then “shoots” in one of two ways. In
362
V. Melamed et al.
a “surrounding” mode Sniper randomly generates an address which is close to the chosen one and can be bigger, equal or smaller. In a “prefetching” mode the address can only be equal or bigger. In both cases the maximum distance between the chosen address and the sniper address can be configured. Sniper knows which JBUS agents generate the addresses that appear on the bus. It does not enqueue the addresses that it generated itself in the address history table. Enqueueing Sniper’s own addresses would create a positive feedback loop and would decrease the efficiency of the tool. Sniper is essentially a bus noise generator where the noise can be tuned to have a high correlation with the signal. The typical behavior of Sniper will result in lines being “snooped away” from their normal place of residence. Thus, typical Sniper-generated bus activity will include one Sniper-generated transaction to “steal” the line into the cache of a Simulated JBUS Model and then one more transaction where the user of the line requests the line (back). Obviously this increases the traffic on the processor bus and stresses the processor’s internal queues and FIFOs, but more importantly, the same line is going back and forth between processors, thus testing logic which may be stalling or bypassing information based on an address match. Almost any test case which passes without Sniper enabled should pass with Sniper in use since it does not modify any data. Only the tests which perform diagnostic reads from the cache and expect a cache line to be in a particular state are an exception and cannot run with Sniper, and test cases such as these are rare. The concept was extended to the PCI bus (the system’s IO bus) in our environment with only slight modifications. The PCI bus does not support cache coherency, but the idea of generating transactions based on the history of the bus is still valid. The next extension of Sniper is interesting for bus-to-bus bridges which are historically very difficult to verify. In a configuration where a bridge chip connects bus A and B, Sniper may monitor bus A and issue transactions on bus B, and vice versa. This idea has not yet been implemented. Sniper does not have to be limited to monitoring bus interfaces. It can also be extended to monitor internal chip signals and interfaces. This would add a predictor property to Sniper since it would know in advance what transactions the processor is about to present to the bus. A last idea for further Sniper development would be to generate an address as a function of several entries in the history table. Some linear regression curve functions are the obvious first choice here.
4
Some Results, Conclusions
A typical bug caught by Sniper can be described with the following statement: “This is a corner case of a corner case. The test is aligning two transactions next to each other, now comes Sniper and adds a third one”. The first family of bugs that Sniper targeted well were corner cases where transactions with related
Innovative Verification Techniques
363
addresses have to appear almost simultaneously. Other tools scored poorly in identifying those types of bugs. A “typical” bug is often found by many tests and tools independently. The bugs found by Sniper however, were extremely hard to duplicate without it, even after the bug was already known and another test or tool was tweaked to attempt to address it. The other family of bugs that Sniper uncovered were related to overflowing internal processor queues. Since the tool generates a fair number of transactions on the bus, it helped fill up the bus-related queues in the design and thus tested the conditions where these queues are full or almost full. Other tools also scored well locating this type of bugs. Only 2–3% of all logic bugs found on UltraSparc #IIIi could be credited to Sniper. One reason for this is that the tool was deployed when the design was already in a fairly mature state. However, most of these bugs were very subtle and thus would have been very difficult to find without Sniper.
References 1. Heald R. et al “A 3rd generation Sparc V9 64-b Microprocessor” IEEE JSSC, pp. 1526–1538, Nov. 2000 2. Lauterbach G. et al “UltraSPARC-III: a 3rd generation 64b SPARC Microprocessor”, ISSCC Digest of Technical Papers, pp 410–411, Feb. 2000. 3. Heald R et al, “Implementation of a 3rd Generation SPARC V9 64b Microprocessor”, ISSCC Digest of Technical Papers, pp 412–413, Feb. 2000 4. Normoyle K. “Introducing the UltraSPARC(TM)-IIIi Microprocessor”, Microprocessor Forum, Oct. 2001 5. George Konstadinidis et al, “Implementation of a Third generation 1.1 64b Microprocessor”, ISSCC2002.
Sun, Sun Microsystems, the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
Mechanical Translation of I/O Automaton Specifications into First-Order Logic Andrej Bogdanov1 , Stephen J. Garland2 , and Nancy A. Lynch2 1
UC Berkeley, EECS – Computer Science Division, Berkeley, CA 94720 2 MIT Laboratory for Computer Science, Cambridge, MA 02139
Abstract. We describe a tool that improves the process of verifying relations between descriptions of a distributed algorithm at different levels of abstraction using interactive proof assistants. The tool automatically translates algorithms, written in the IOA language, into first-order logic, expressed in the Larch Shared Language, in a style that facilitates reasoning with a theorem prover. The translation uses a unified strategy to handle the various forms of nondeterminism that appear in abstract system descriptions. Applications of the tool to verify safety properties of three data management algorithms, including a substantial example based on Lamport’s logical time algorithm, suggest that the tool can be used to validate complicated, practical designs.
1
Introduction
High-level descriptions of distributed algorithms differ from their low-level counterparts not only in level of detail, but also in style and syntax. The choice of style and syntax is closely related to a description’s intended use. High-level descriptions generally serve to specify a range of allowable abstract behaviors. For this purpose, a declarative, nondeterministic style enhances clarity and generality. On the other hand, low-level descriptions generally serve as input to code generators (e.g., compilers). For this purpose, an imperative, deterministic style works best. Program analysis tools, such as model checkers and theorem provers, tolerate nondeterminism better than code generators. In practice, however, nondeterminism can result in search space explosion for model checkers, and it can increase the need for user interaction with theorem provers. For these reasons, designers generally produce different descriptions of an algorithm for different tools—a dangerous practice, given the discrepancies that all too easily appear in multiple descriptions of the same algorithm. IOA [3], a high-level language based on the I/O automaton formalism [9], intends to bridge the gap between the stages in the design of distributed algorithms through a versatile syntax for describing algorithms, their properties, and their interrelations. The language supports expressing designs at different levels of abstraction, starting with a high-level abstract specification of desired system behavior, appropriate for formal reasoning, and ending with a low-level version which is translatable into real distributed code. D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, pp. 364–368, 2002. c Springer-Verlag Berlin Heidelberg 2002
Mechanical Translation of I/O Automaton Specifications
365
The advantage of IOA is that it enables one to establish a formal connection, within a single language, between specifications written at different levels of abstraction. The mathematical tool used for this purpose is the simulation relation [10]. Since simulation proofs tend to be very stylized, they are amenable to the application of computer-assisted proof tools. Generally, it is harder to write and check formal proofs with mechanized proof assistants than to write unchecked intuitive arguments. However, complicated distributed algorithms, such as data management algorithms with strong coherence guarantees, or fault-tolerant distributed algorithms that are used in practice, can benefit greatly from the careful reasoning style of formal proofs. Our goal is to combine the flexibility of informal arguments with the credibility of formally checked proofs. We describe ioa2lsl, a tool that translates IOA specifications into the Larch Shared Language (LSL), a logical language for describing first-order theories. LSL interfaces with the Larch Prover (LP), an interactive theorem proving assistant for multisorted first-order logic. We have used this tool to verify the correctness of three distributed data management algorithms, Dijkstra’s mutual exclusion algorithm and a distributed spanning tree algorithm [7]. A significant feature of our translation procedure is its treatment of nondeterminism. Even though theorem provers are better equipped for handling nondeterminism than other tools, such as model checkers and code generators, the use of nondeterminism still incurs a number of technical difficulties. Generally, these difficulties stem from the representation of nondeterministic choices by existential quantifiers, which require explicit instantiation in a proof session. Our tool uses a simple extension to the mathematical I/O automaton model that captures the essence of nondeterminism and reduces the need for explicit instantiation in proofs.
2
Features of the Translation
Our tool is aimed at producing a translation that appears natural to the user of the theorem proving tool. If the translation is cumbersome and unreadable, interaction with the tool can become extremely difficult. A good translation must preserve the illusion that what appears obvious to the user is also obvious to the mechanized proof assistant. This becomes an especially important issue in the translation of transition effects because the semantics of imperative code may be quite complicated. For example, the proof assistant ought to establish that a state variable was not modified by a transition automatically, without user intervention. In an IOA program, the conditions under which two states are related by a labeled transition are specified by transition definitions. Transition definitions consist of a precondition predicate specifying the enabling condition for the transition and an effect specifying the relation between the initial and final states, usually written as an imperative-style program. The specification may depend on both explicit transition parameters and nondeterministically selected hidden parameters.
366
A. Bogdanov, S.J. Garland, and N.A. Lynch
In many formalisms, the precondition and effect of a transition are lumped into a single predicate describing the condition under which a labeled transition is allowed between two states. Our translation produces, for each transition definition, a separate enabled clause containing the enabling condition and an effect clause specifying the change in the state variable. This allows us to represent effect as a function, rather than a predicate, that maps an initial state and a transition label into a final state. This functional representation is useful in the theorem proving session, where effect clauses turn into rewrite rules expressing post-state variables in terms of pre-state variables. The utility of these rewrite rules in inductive proofs, including proofs of invariants and simulation relations, is our principal motivation for this design decision. A fundamental feature of the IOA language is its support for nondeterministic choices. There are two sources of nondeterminism in IOA programs: (1) at a given state, more than one action may be enabled, and (2) a transition definition may contain explicit nondeterministic choices, indicated by choose statements. Nondeterminism of the first kind causes no difficulty for theorem proving (although code generators must provide some way to schedule actions when more than one is enabled). Nondeterminism of the second kind can complicate theorem proving, particularly because standard techniques for translating choose statements (cf. [5], page 312) introduce explicit universal or existential quantifiers. We avoid the introduction of additional quantifiers by transforming explicit nondeterministic choices into transition parameters. For example, consider the following transition of an automaton with a single state variable x of type Int: input chooseroot eff x := choose t: Int where t * t = 1
This transition definition is nondeterministic because it specifies two possible post-states: x = −1 and x = 1. We can interpret this nondeterministic choice using a transition parameter t by rewriting the transition definition in the following form: input chooseroot(t: Int) pre t * t = 1 eff x := t
The two specifications are almost the same: the only difference is that we have replaced the action chooseroot with a family of actions chooseroot(t), where t ranges over the sort Int. We note that our translation scheme avoids the use of quantifiers to specify either bounded or unbounded nondeterministic choices, as in earlier approaches [5,2,4]. This translation benefits theorem proving, since establishing statements involving existential quantifiers often requires explicit user instantiation.
3
Applications of the Tool
We have used our translation tool to verify three distributed data management algorithms of successively increasing complexity: a simple caching algorithm, a
Mechanical Translation of I/O Automaton Specifications
367
majority voting algorithm, and a replicated storage algorithm based on Lamport’s logical time transformation. In each case, we verified that the implementations of read/write operations were atomic. In the spirit of successive refinement, we wrote an abstract specification for an atomic variable and showed that each of the algorithms implements the atomic variable. The proofs use forward simulation relations. In the majority voting algorithm (cf. [8], page 573), each concurrent process employs a local copy of the data, and the algorithm preserves the invariant that the most recent value is always present in a majority of the processes. To verify this invariant, it is necessary to argue that any majority of processes intersects the set of processes containing the most recent value. Establishing set theoretic properties such as this requires a number of lemmas, which constitute the bulk of our simulation proof script. The sections of the proof owing to our choice of representation for automata and their properties were straightforward, with one exception: the prover required a great deal of assistance to establish intuitively clear properties of a for loop used to store values at a majority of processes during the write operation. Our most challenging example was the replicated storage algorithm. The atomicity assumptions in this algorithm are much less strict, and closer to actual practice, than in the other two. In particular, no action involving more than one process is required to be atomic. The algorithm ensures consistency with the help of Lamport’s logical time algorithm [6]. Originally, the correctness of this algorithm was established by demonstrating indistinguishability with respect to certain orderings of events [6], an approach quite different from the techniques supported by our tool. We developed a new correctness proof based on successive refinement and forward simulation relations. Our proof introduces an auxiliary data management model that preserves the data replication features of the replicated storage algorithm, but pretends that the interactions are synchronous. We first establish that this auxiliary model implements an atomic variable. The mathematics of the proof are quite intricate, and this is reflected in the proof script ([1], Appendix B), which is 800 lines in length. As in the proof of the majority voting algorithm, most of the proof script is concerned with establishing lemmas about data structures; relatively little work is required because of our translation process. Another proof, dealing with synchronization properties, establishes that the replicated storage algorithm implements the auxiliary algorithm. This proof is complicated mathematically, and we have not yet attempted to verify it mechanically.
References 1. Andrej Bogdanov. Formal verification of simulations between I/O automata. Master of engineering thesis, Massachusetts Institute of Technology, 2001. http://theory.lcs.mit.edu/˜adib/thesis. 2. Marco Devillers. Translating I/O automata to PVS. Preliminary report, Computing Science Institute, University of Nijmengen, 1999.
368
A. Bogdanov, S.J. Garland, and N.A. Lynch
3. Stephen J. Garland and Nancy A. Lynch. Using I/O automata for developing distributed systems. In Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, pages 285–312. Cambridge University Press, 2000. 4. Stephen J. Garland, Nancy A. Lynch, and Mandana Vaziri. IOA: a language for specifying, programming, and validating distributed systems. MIT Laboratory for Computer Science, 1997 (revised January, 2001). 5. David Gries. The Science of Programming. Springer-Verlag, 1981. 6. Leslie A. Lamport. Time, clocks and the ordering of events in a distributed system. Communications of the ACM, 21(7):558–565, July 1978. 7. Chris Luhrs. Distributed spanning tree algorithms coded in IOA: Challenge problems for software analysis and synthesis methods. Technical Note, 2001. 8. Nancy A. Lynch. Distributed Algorithms. Morgan Kaufman Pubishers Inc., 1996. 9. Nancy A. Lynch and Mark Tuttle. Hierarchical correctness proofs for distributed algorithms. Technical Report MIT/LCS/TR-387, MIT Laboratory for Computer Science, 1987. 10. Nancy A. Lynch and Frits Vaandrager. Forward and backward simulations – part I: Untimed systems. Information and Computation, 121(2):214–233, September 1995.
Verification of Event-Based Synchronization of SpecC Description Using Difference Decision Diagrams Thanyapat Sakunkonchak and Masahiro Fujita Department of Electronic Engineering, University of Tokyo 7-3-1, Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan
[email protected],
[email protected] We introduce an on-going work that tries to develop a technique for the verification of synchronization issues in SpecC language, a C-based system level description language. It is summarized as followed. – Based on the concept of the boolean program, the SpecC source description is translated into boolean SpecC. We concern only with the synchronizationrelated statements, hence, statements like conditional branching statements (if/else) and synchronization semantics containing statements (notify/wait) will be sustained. The other statements will be abstracted away. – From the boolean SpecC, we translate it again into the C++ language where the relationship among the statements in the boolean SpecC is expressed in terms of inequalities, e.g. stmnt1 < stmnt2 < . . . , and proportional logic on conditional variables introduced when translating from SpecC to boolean SpecC. This will be incorporating with the DDD package (able to handle the inequalities expression and proportional variables) for verifying the synchronization of the original SpecC. The verification result must be one of these: Satisfied or Unsatisfied. When the result is Satisfied, the verification process terminates with the satisfied result. Otherwise, we have to further verify the result whether the synchronization is really unsatisfied or unable to determine because of the limitation of our verification tools. – We are verifying the result from the previous stage. Some other tools like SVC or Program Slicing will be used in order to help checking and tracing to the Unsatisfied verification result. The causes of the Unsatisfied result are either the synchronization of the original source is wrong or there is too much abstraction when translating from SpecC to boolean SpecC. This stage is under implementation. Let us note that the verification process should be completely automatic. As a final remark, the proposed technique clearly defines synchronization semantics of SpecC descriptions, which is one of most important issues for system level description languages.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, p. 369, 2002. c Springer-Verlag Berlin Heidelberg 2002
A Distributed Partial Order Reduction Algorithm Robert Palmer and Ganesh Gopalakrishnan University of Utah, School of Computing {rpalmer,ganesh}@cs.utah.edu
A distributed version of the PV model checker [5] is being developed at the University of Utah [7]. Other distributed model checkers have also been implemented [1, 2, 6], however these have limited, or do not use partial order reduction. The distributed version of PV uses a variant on the original Twophase partial order reduction algorithm [4] and a simple heuristic that may reduce the number of states saved in a distributed verification. The graph search has been changed to make the distributed version of PV perform a breadth first based search. The distributed Twophase algorithm uses an alternation between a reduction step and a classical breadth first search step. The reduction step executes every commuting [3, 4] enabled transition of each process in the model as in the sequential version. The resultant search frontier consists of non-commuting states. Distributed breadth first search requires sending and receiving of states. The owner of a state is determined when a new state has been returned by Phase-1. States received from other processes are enqueued as though they were generated by the classical breadth first search. States are passed as messages along with information to reconstruct an error trail. A process is assigned a section of the search space using a uniform hash function. Communication only takes place after Phase-1. The distributed version of PV uses a variant on the “Twophase” algorithm that may reduce the amount of unnecessary communication in a distributed verification.
References 1. Jiri Barnat, Lubos Brim, and Jitka Stribrna. Distributed ltl model-checking in spin. In Proceedings of the 7th International SPIN Workshop, pages 200–216, 2001. LNCS 2057. 2. Hubert Garavel, Radu Mateescu, and Irina Smarandache. Parallel state space construction for model-checking. In Proceedings of the 7th International SPIN Workshop, pages 217–234, 2001. LNCS 2057. 3. Richard J. Lipton. Reduction: A method of proving properties of parallel programs. Communications of the ACM, 18(12), December 1975. 4. Ratan Nalumasu and Ganesh Gopalakrishnan. An efficent partial order reduction algorithm with an alternative proviso implementation. Formal Methods in System Design, 20(3):231– 247, May 2002. 5. Robert Palmer and Ganesh Gopalakrishnan. Partial order reduction assisted parallel modelchecking (full version). Technical report, University of Utah, August 2002. 6. Ulrich Stern and David Dill. Parallelizing the Murφ verifier. Formal Methods in System Design, 18(2):117–129, 2001. (Journal version of their CAV 1997 paper). 7. The Utah Verifier group website. http://www.cs.utah.edu/formal verification.
Supported by NSF Grants CCR-9987516 and CCR-0081406, and a gift from the Intel Corporation.
D.A. Peled and M.Y. Vardi (Eds.): FORTE 2002, LNCS 2529, p. 370, 2002. c Springer-Verlag Berlin Heidelberg 2002
Author Index
Amla, Nina 226 Armando, Alessandro Audemard, G. 243
210
Berthomieu, Bernard 344 Bhutani, Sutikshan 360 Bing, Qian 81 Bochmann, Gregor v. 17 Bogdanov, Andrej 364 Boˇsnaˇcki, Dragan 65 Brower, Ronald W. 34 Chang, Lawrence 360 Cimatti, A. 243 Compagna, Luca 210 Deussen, Peter H. 114 DuVarney, Daniel C. 260 Emerson, E. Allen Fujita, Masahiro
226 369
Garavel, Hubert 276 Garland, Stephen J. 364 Giannakopoulou, Dimitra 308 Gopalakrishnan, Ganesh 370 Iyer, S. Purushothaman Jard, Claude 97 J´eron, Thierry 97 J´ez´equel, Jean-Marc
260
97
Kornilowicz, A. 243 Kristensen, Lars Michael 327 Kwiatkowska, Marta 194
Lang, Fr´ed´eric 276 Lepp¨ anen, Sari 178 Le Guennec, Alain 97 Lerda, Flavio 308 Livadas, Carolos 146 Luukkala, Vesa 178 Lynch, Nancy A. 146, 364 Mailund, Thomas 327 Melamed, Victor 360 Namjoshi, Kedar S. 226 Norman, Gethin 194 Normoyle, Kevin 360 N´ un ˜ez, Manuel 1 Palmer, Robert 370 Pickin, Simon 97 Reiff-Marganiec, Stephan 130 Ribet, Pierre-Olivier 344 Rodr´ıguez, Ismael 1 Sakunkonchak, Thanyapat Schmidt, Karsten 50 Sebastiani, R. 243 Stevens, Kenneth S. 34 Stuimer, Harry 360
369
Tobies, Stephan 114 Traon, Yves Le 97 Trefler, Richard J. 226 Turner, Kenneth J. 81, 130, 162 Tynj¨ al¨ a, Teemu 178 Verdejo, Alberto 292 Vernadat, Fran¸cois 344 Wang, Farn 50 Wilkins, David 360