00001.tif

PDF

Download

Open document

Flip pages

Contact Us

Copy asset link

Request this asset

Transcript (if available)

Content SYMBOLIC VERIFICATION OF REAL-TIM E CONTROLLERS by M ark A. Stalzer A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (Com puter Science) December 1993 Copyright 1993 M ark A. Stalzer UMI Number: DP22876 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Dissertation Publishing UMI DP22876 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 This dissertation, written by Mark A. S t a lz e r under the direction of hXs Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillment of re quirements for the degree of DOCTOR OF PHILOSOPHY Dean of Graduate Studies Date ..Recember. 3.t,. 1993 DISSERTATION COMMITTEE Chairperson S182- 3tfs-6»4/^ f D e d ic a tio n To Ashley Marie and B rittany A nastasia A ck n o w led g em e n ts By the tim e a student begins the research leading to a Ph.D ., he or she has typ ically taken upwards of seventy classes from nearly as many instructors. Some of jthese instructors have a profound im pact on the way the student approaches the acquisition and creation of knowledge. In my case, three professors were central to my education: Diane Schwartz and Malcolm Soule, both from the California State University at N orthridge, and Leonard Adleman from USC. The things I learned from each can’t be found in a book. Throughout my college years, I have tried to be active both professionally and academically. Sometimes the pull from one would cause me to neglect the other and I ’m grateful to my supervisors—James Berger from Trace Instrum ents, and jGeorge Valley and Stephen W andzura from the Hughes Aircraft Company—for their support, understanding, and encouragement. My academic advisor, Dean Jacobs, was at the other end and he never let go. He always questioned my assumptions and helped me order my thoughts. The strengths of this presentation are largely due to his guidance. I couldn’t have done this work w ithout the support of my family. My parents always encouraged learning and th at was their single greatest gift to me. My lovely wife, Julie, was the essence th a t kept me going. The journey has ju st begun. C o n te n ts D e d ic a tio n ii A ck n o w led g em en ts iii 'List O f T ables vi •List O f F igu res vii A b stra ct viii 1 S cop e 1 1.1 Synchronous Real-Time C ontrollers............................................................. 7 1.2 Symbolic V erification........................................................................................ 10 1.3 C ontributions and P l a n ................................................................................. 14 2 M o d elin g R eal-T im e C ontrollers 16 2.1 A Model for Real-Time C o n tro lle rs............................................................. 17 2.1.1 A Formal M o d e l ................................................................................. 17 2.1.2 An Alternative R e p re s e n ta tio n ...................................................... 20 2.1.3 A Form of N for Deterministic S y s te m s ..................................... 26 2.1.4 Forms of N for Asynchronous S y ste m s......................................... 27 2.2 Synchronous Action L anguage....................................................................... 29 2.2.1 Sal Concepts and S y n ta x ................................................................ 29 2.2.2 Sal S e m a n tic s.................................................................................... 34 2.2.3 Reachable States, Race Conditions, and Erroneous Program s 40 2.2.4 The Traffic Light C o n tro ller............................................................. 42 2.3 Related L a n g u a g e s........................................................................................... 43 2.3.1 Subsumption A rch itectu re................................................................. 46 2.3.2 E Q L ......................................................................................................... 47 2.3.3 S M V ......................................................................................................... 47 3 C o m p u tin g w ith M od els 49 | iv 3.1 Ordered Binary Decision D ia g ra m s.............................................................. 49 3.1.1 D ata S tr u c tu r e ..................................................................................... 50 3.1.2 Fundam ental Operation: If-T h e n -E lse .......................................... 53 3.1.3 Complexity Limits and the Variable Ordering Problem . . . . 57 3.2 Com puting the Predecessors of a Set of S ta te s ........................ 58 3.2.1 S yn cS tep : Com puting N ~ * S for Deterministic Systems . . . 59 3.2.2 Step : Computing N -1 S with Unconstrained State Variables 63 3.3 Com parative P erfo rm a n ce ............................................................................... 64 3.3.1 A n d E x ists : The SMV Predecessor Algorithm ....................... 65 3-3.2 Results ................................................................................................... 66 4 R ea l-T im e S ym b olic M od el C hecking 68 4.1 Logics for Specifying Real-Time C o n tro lle rs ............................................. 68 4.2 RTCTL Syntax and S e m a n tic s ..................................................................... 74 4.3 RTCTL Symbolic Model C h e c k in g .............................................................. 77 4.3.1 Intuitions about I n p u t s ..................................................................... 81 4.3.2 Related W o rk ......................................................................................... 82 5 A p p lica tio n s 84 5.1 Traffic Light Controller .................................................................................. 84 5.2 Elevator C o n tro lle r............................................................................................ 91 5.2.1 RTCTL Specification........................................................................... 92 5.2.2 Sal Im p le m e n ta tio n ............................................................................ 96 5.2.3 RTSMC Results .................................................................................. 97 5.3 A Real-Time Rule-Based Diagnostic S y s te m ........................................ . 99 6 C on clu d in g R em ark s 102 A p p en d ix A Sal Im plem entation of the Elevator C o n tro lle r.......................................................105 A p p en d ix B Sal Im plem entation of CRY 063a ............................................................................ 110 R eferen ce List 114 v L ist O f T a b les 3.1 Complexity of some common function classes............................................. 57 3.2 Com parative performance of various predecessor algorithm s.................. 66 3.3 Com parative memory requirements of various predecessor algorithm s. 66 5.1 RTSMC verification timings for the traffic light controller...................... 87 5.2 RTSMC verification timings for the elevator controller............................ 98 L ist O f F ig u res 2.1 Basic model of a synchronous system with unconstrained state vari ables (inputs)........................................................................................................ 18 2.2 Sal syntax................... 32 2.3 The semantics of Sal expressions.................................................................. 37 2.4 The semantics of Sal conditions................................................................... 38 2.5 A lgorithm Reachable for computing reachable states and detecting race conditions...................................................................................................... 42 2.6 TLC Sal im plem entation: Declarations and preprocessor definitions. 44 2.7 TLC Sal im plem entation: Actions and defaults...................................... 45 3.1 BDD representation of the 3-input m ajority function............................. 51 3.2 Reduced OBDD representation of the 3-input m ajority function. . . 51 3.3 Algorithm I T E ................................................................................................... 55 3.4 Algorithm S tep ................................................................................................... 64 3.5 SMV predecessor algorithm: A n d E x ists .................................................... 65 4.1 RTCTL Model Checking R u l e s ................................................................... 79 4.2 Algorithm E U n tila for computing C heck(E [< ^U -*^])......................... 80 5.1 RTSMC timings for the TLC verification versus the num ber of reach able states as determ ined by Th...................................................................... 89 5.2 RTSMC timings for the TLC verification with assertion W 4 removed versus the num ber of reachable states as determ ined by Th................... 90 vii A b str a c t 'Presented are techniques for formally verifying the correctness of real-tim e, safety- jcritical controllers based on a synchronous model of com putation. These techniques are generalizations of symbolic model checking, as introduced by Clarke et al., and are applicable to systems th a t were intractable for other model checking m ethods due to their large num ber of states. The work has four m ajor directions: 1. generalizing symbolic model checking to Real-Time C om putational Tree Logic (Emerson et al.); 2. the development of a new algorithm for com puting the predecessors of states th at improves the perform ance of symbolic model checking; 3. applying the techniques to the verification of useful real time controllers; and, 4. the introduction of the S y n c h r o n o u s A c tio n L a n g u a g e (S a l ) for implementing real-tim e controllers. S al is based on rules which consist of an enabling condition and a set of assign m ents to the system ’s state variables. At each clock tick, all enabled actions fire simultaneously. As such, Sal is highly concurrent and can be compiled directly into program m able hardware. One problem is simultaneous assignments to the same jvariable, which is commonly known as a race condition. As p art of the S al se m antics, a technique for detecting race conditions is presented. One result is th a t the synchronous system model used by S al and the verification techniques is also applicable to asynchronous systems. All techniques presented in this work have been implemented in the Real-Time Symbolic Model Checker (RTSMC) program . Timing results are given and com- I pared w ith other approaches. C h a p te r 1 S c o p e Digital com puters are being used to control a wide variety of devices, from household appliances to nuclear power plants. In some applications, the com puter is a critical component and its failure can cause the loss of property, or even, life. An example is the X-29, an aircraft of exceptional m aneuverability th at depends on its triply redundant com puters to adjust its control surfaces forty times a second to keep from tum bling out of control[Cer89]. If the com puter system stops operating, either through mechanical failure or software “bugs,” the aircraft will quickly disintegrate. This control frequency (40Hz) and failure recovery tim e (ss Is) are beyond hum an (limits. The computerized controller is critical and, therefore, so is the correctness of its software. C om puting systems can be grouped into two broad classes: transformational and reactive. Compilers, batch-oriented mangem ent inform ation systems, and w eather prediction codes are transform ational: each takes some input, computes a m athe m atical function, and gives the result as an output. A transform ational program is correct if for any valid input, it term inates with the value of the desired function as its o u tp u t.1 During the entire com putation, the inputs are not changed. A reactive system[Pnu89] periodically reads its inputs and responds by adjusting its outputs. These systems are intended to m aintain an interaction with their environm ent and jterm ination is often undesirable. Some examples are operating system s, graphical juser interfaces, anti-lock brake controllers, and fly-by-wire aircraft. 1 System and program are used interchangeably. 1 The inputs to a reactive system are different than the inputs to a transform a tional system. For a reactive system, the inputs are expected to change while the system is computing. W ith each change of the inputs, the system m ust re-evaluate and possibly update its behavior. The correctness of these systems cannot be de term ined simply by looking at initial inputs and final outputs. The entire history of inputs and outputs m ust be considered. This is one of the features th a t makes designing reactive systems exciting and challenging. Tim ing constraints may be applied to both kinds of systems. For transform a tional system s, these are always specifications of performance. The loosest one is th a t the program term inates. Depending on the system, stronger constraints might be desirable. A batch-oriented banking system should finish its account updates be fore the bank opens for business in the morning and a weather prediction program th a t makes forecasts after the fact is of little use. The tim ing constraints th a t can be placed on a reactive system are much richer. For example, a traffic light controller m ight be program m ed to allow cars to cross a busy highway from a side road for at m ost 15 seconds. If, at any tim e during this period, the controller senses th a t there are no m ore cars on the side road, then it must set the side road light to yellow in preparation for letting the highway light go green. A reactive system w ith tim ing constraints is known as a real-time system .2 Real-tim e systems are often safety-critical[Lev86]. The X-29 com puters are an example of a safety-critical, real-time, system. It is clear th a t the software m ust be “safe,” i.e. free of defects. The system is reactive since it m ust continuously respond to the pilot’s inputs and the forces on the plane. The addition of tim ing constraints make it real-tim e. Not all real-time programs are safety-critical. It doesn’t m atter much if a video game reacts too slowly to an input and the character dies. Similarly, not all safety-critical program s are reactive. The load m anagem ent software of an airline, which instructs the crew how to arrange the cargo so th a t the plane flies properly, is a safety-critical transform ational system. However, most safety-critical system s are real-tim e and the two are sometimes mixed together in the literature. 2There is som e debate over the definition of a real-tim e system . T h e definition given here is due to B enveniste and Berry[BB91]. 2 It is often the case th a t the simplest and most innocuous systems are real-tim e and safety-critical. Take the traffic light controller as an example. If it allows the 'lights on both the highway and side road to be green or yellow at the same tim e, a Jcollision is only a m atter of time. There are many failure reports for these seemingly simple systems: an anti-lock brake controller with a control strategy th a t cancelled jout a state trooper’s m odulation of the brake pedal, resulting in no brakes at all; a itrain controller th a t put two trains on a collision course (there are m any examples of failed train controllers); and a door safety interlock to a storage area containing ■radioactive m aterials th a t allowed both the outer and inner door to be open at I 3 once. The simplicity of these systems is merely an illusion since they can be in a trem endous num ber of internal states. A state is a unique configuration of a sys tem ’s inputs and internal variables. Assuming th a t the system is im plem ented using N two-valued (binary) inputs and memory elements, it can potentially be in 2N dif ferent states. In general, each state leads to a different future behavior. Consider the traffic light controller. A small one can be constructed from an eight bit tim er, a couple of two bit output registers for the lights, an input to sense cars on the side ■road, and a few bits to remember what it’s supposed to be doing (the state register or iprogram counter), for a to tal of about sixteen bits. In general, at any given instant, the controller can be in one of 216 = 65,536 states. The actual num ber of states can be m ade smaller by initializing the controller properly (the reachable states). But the point is th a t there are simply too many states for a person to check by hand. Even constructing an exhaustive set of test cases is hard. Adding a few m ore state variables makes the problem much worse and results in the state explosion problem. A controller for a single elevator servicing just a few floors can easily have forty state variables, and due to the random nature of requests at different floors, a significant ■fraction of the 1,099,511,627,776 possible states are reachable. Even w ith extensive Resting, can we ever be sure th at the system will never do something dangerous? iW hat’s lurking out there is state space? | 3T h ese and other reports about troublesom e com puter system s, hum an-com puter mis- interactions, and privacy concerns can be found in back issues of the Risks D igest, an Internet forum m oderated by Peter Neum an (r is k s -r e q u e s t® s r i.c o m ). 3 The traditional software engineering approach is to treat this as a software relia bility issue: by proper engineering processes and a rigorous test plan, the probability of failure can be m ade arbitrarily low given enough resources. The view th a t this approach is adequate for real-time systems is challenged by D unn and Corliss in the conclusions of “Software safety: A user’s practical perspective” [DC90]: We do not believe th at life cycle practices, testing and analysis techniques will improve to the point th a t an arbitrary software package can be ultim ately m ade safe solely through their repeated application. D unn and Corliss are concerned about developing software th a t fails once every (hundred or thousand years, not once a day. There are two key problems: 1. the engineering methodologies are not autom atic, so there is room for hum an error; and 2. there are too m any states to test to try to uncover the inevitable mistakes. An alternative approach is to develop a specification of the system in some form al language, typically a logic, and to verify that the implem entation m eets the specification. The power of this approach is that a single logical formula covers all 'states. For the traffic light controller, a useful formula is one that specifies that jonly one road may have a green or yellow light at a tim e. Assuming we show this •formula is true for a given implementation, we can be assured that the lights will Lever allow cars to go at the same time. There are two objections to the verification approach: 1. developing the spec ification is at least as hard as programming the system, and 2. the correctness [proofs are harder to do than the actual programming. The first objection really ‘ has nothing to do with verification. The initial step in developing any im portant com puter system should be writing down its specification. This is the only way th a t the users and implementors can agree on how the system is supposed to behave. Certainly, there can be bugs in the specification, usually by omission of some con straint. However, here we are concerned about insuring th a t the im plem entation is ^correct, not th a t people always know what they are trying to accomplish. I t ’s not a failure in the com puter system if it properly implements a bad specification. This is a philosophical point of some contention dating back to at least Apollo ll[Cer89] Jand a com puter overload indication th a t confused m atters during the lunar landing. (Even though the com puter operated as specified, some authors argued th a t it was 4 a “bug” in the software (Ceruzzi gives an excellent sum m ary of the debate). This seems extrem e, and we’ll take the view th a t an im plem entation is correct (bug-free) if it satisfies its specification. The second objection is right on target. Performing correctness proofs by hand requires a level of m athem atical competence th a t is beyond the ability of most program m ers. Furtherm ore, it is not uncommon for the correctness proof to be longer and far more difficult to follow than the actual code for the system. Some work has been done on autom ating correctness proofs. But the process is not completely autom ated and people still have to do the hard part (finding loop invariants). P a rt of the trouble is th a t specifications are often w ritten in a form al notation th a t is as strong as first-order logic. It shouldn’t be surprising th a t i t ’s hard to find good autom ated techniques for undecidable problems. However, by making two restrictions, we can develop an efficient procedure for autom atically checking an im plem entation against its specification. The first is to insist th a t the system have a fin ite num ber of possible states. This is true of all com puter systems since nobody has invented a Turing-style infinite tape. However, m ost com puters have so much memory th a t it might as well be infinite when considering the num ber of possible states. The finite-state approach is much more appropriate for small system s, like our real-tim e controllers, th at have only a few state variables. For a finite-state system , we can construct a finite m athem atical model th a t describes the system ’s behavior. Now, the m athem atical description of the system (its model) can be checked against its specification by an exhaustive search of the state space in a process known as model checking. This leads to the second restriction: use a logic for specifying the system th a t has an efficient model checking procedure. Unfortunately, the model checking procedures of m any logics have very high tim e complexities which makes them intractable for even the smallest of systems. However, this is not the case for all logics. In particular, some temporal /o < 72c.s[Pnu77] have efficient model checking algorithm s and are well suited to specifying properties of reactive systems. Even efficient model checking procedures have a serious difficulty: they have to -enumerate all of the states. This is okay for small systems, and there have been reported successes of model checking finding problems in simple circuits[BCDM86]. [However, at around twenty to thirty state variables, the procedures also become 5 intractable. The solution, symbolic model checking, was discovered independently by groups at Carnegie Mellon University[BCM+90, CBG+91, McM92] and the Bull Research Center in France[CBM89, CMB91]. A symbolic model checking procedure does not enum erate all of the states. Instead, it reasons about sets of states th a t are encoded in an efficient representation for boolean formulas. This often leads to large speed-ups, and systems with over 1020 states (sixty four state variables) jhave been successfully verified. The technique does not always work, the boolean form ula representation can itself “blow-up” exponentially in the num ber of state jvariables. However, symbolic model checking has been used successfully to verify ■reactive systems th a t are a billion times more complex, in term s of the num ber of [states, than previously possible. In this thesis, symbolic model checking is extended to a real-tim e tem poral logic, i.e. a logic th a t is useful for specifying the properties of reactive systems and |their tim ing constraints. The logic is called Real-Time C om putational Tree Logic (RTCTL)[EMSS89] and this is the first tim e th at symbolic model checking has been 'done for the logic. Additionally, a new technique is developed th a t allows for the autom atic detection of race conditions which tend to be a m ajor source of bugs in i •highly concurrent systems. The combination of real-time symbolic model checking and the detection of race conditions is called, to coin a phrase, real-tim e symbolic verification. These techniques are implemented in a program called RTSMC and jtheir utility is dem onstrated on three sample problems: the traffic light controller, an elevator controller, and a real-time rule-based system used to diagnose faults in a Space Shuttle subsystem. The last two systems are intractable using traditional m odel checking techniques. The next section describes the im plem entation model th a t we’ll use for real tim e controllers. I t ’s followed by a section th at describes tem poral logic and sym bolic model checking in greater detail. The final section of this chapter lists the contributions of this work and gives a plan for the rem ainder of the thesis. 6 1.1 S y n ch ro n o u s R e a l-T im e C o n tro llers T he discussion so far has been primarily about real-time systems in general. In this section, we will focus on synchronous finite state machines as an im plem entation m odel for real-tim e systems. This im plem entation model is appropriate for relatively small systems having up to a hundred or so state variables and inputs. These system are frequently found in control applications. A bstractly, a synchronous finite state machine consists of a collection of states where each state corresponds to a possible configuration of the system ’s state vari ables and inputs. The machine can only be in one state at a tim e and its operation is synchronized by a clock. At each tick, the machine transitions to a new state which depends on the values of the inputs and the current state. Synchronous finite state machines are often implemented as sequential circuits jWhich consist of a set of memory elements interconnect by a com binatorial logic network all driven by a global clock[Mot72]. The memory elements hold the value jof the state variables and encode the current state. The com binatorial logic network is driven by the memory elements and inputs. During the interval between clock jticks, the network computes new values for all of the state variables. At each tick, jthe new values are latched into the memory elements. A crucial point here is th a t jthe system has no control over the inputs. The inputs are qualitatively different from the state variables. This fact is discussed below and is used later to develop a fast algorithm for symbolic model checking. There are other ways to implement the synchronous finite-state machine model, th e m ost obvious being software. In this thesis, we abstract away some of the im plem entation details by defining the SYNCHRONOUS ACTION LANGUAGE ( S a l). jSAL can be compiled directly into hardware, such as program m able gate arrays |(PGA)[Xil92], or simulated by software. Sal is a small language th a t lacks some ■modern program m ing language features such as encapsulation mechanisms and jtypes. These features can be easily added and are desirable for wider scale use. [However, they would not increase S a l’s expressive power. i S a l is based on rules which are similar to 0 P S 5 style production rules[For81]. The structure of S a l is based on sensing inputs and state variables, and then reacting through outputs. Each rule is of the form j condition — > actions iwhere condition is a function of the state variables and inputs, and actions is a list of 'assignments to some of the state variables. A S a l program consists of declarations for inputs and state variables, a list of rules, and a list of default rules. All rules th a t •have a true condition (enabled) are fired (actions perform ed) at each clock tick. This •leads to the possibility of a race condition where the same state variable is updated m ore th an once. In this thesis, a m ethod is presented th a t finds all races conditions. Previous approaches to this problem are based on either prioritizing the rules or by insuring th a t the rules do not “overlap” based on syntactic criteria. This later approach is pessimistic and sometimes finds race conditions th a t can never occur in actual system operation. Default rules are fired whenever regular rules do not provide a new value for some state variable. S al makes a distinction between state variables and inputs. To a reactive system , the “inputs” of a transform ational program are more like configuration switches— common examples are the tiny unreachable switches th at set a printer to a serial or parallel interface and the bits in a read-only memory. In Sa l , true inputs are modeled w ith random variables. At any tim e step, an input can take either boolean value. In this thesis, inputs are called unconstrained state variables. The identifi cation of these variables, in the context of symbolic model checking, is new and it allows an optim ized model checking algorithm. An alternative approach is to choose an asynchronous model for real-tim e sys tem s. Asynchronous systems cascade from state to state w ithout reference to a clock. Tim e can only be m easured externally. Asynchronous systems can be im plem ented in m any ways. Digital logic im plem entations are self-timed, i.e. the jtiming signals are generated by the logic instead of a global clock. In software, the •asynchronous model is often appropriate due to buffered communications between 8 processes or the sharing of a single processor by many processes which leads to arb itrary interleavings.4 The asynchronous model is necessary for many kinds of reactive system s, such as loosely-coupled networks like the Internet and m ulti-tasking operating system s, but it is of little utility to controllers having a synchronous im plem entation. Even so, i t ’s sometimes argued th a t synchronous systems should be modeled asynchronously to im prove concurrency. However, S a l is already fully concurrent in th a t any enabled Lction is perform ed. Furtherm ore, to specify a general asynchronous system with jtemporal logic requires a dense time structure since two events can be separated by an arbitrarily short duration. These structures tend to result in logics th a t are undecidable, as discussed in the next section. Finally, a result from Sections 2.1.4 and 2.3.3 is th a t two common forms of asynchronous systems can be em bedded in jthe synchronous model by using unconstrained state variables to give an arbitrary ordering to the firing of rules. The implications of this have not been worked out, land it is an interesting avenue for future research. There is growing support in the literature for using the synchronous, finite-state, model to im plem ent small safety-critical systems. In their conclusions, D unn and Corliss go on to say: It does seem reasonable th a t safe software can be achieved through de sign. However, this belief centers around a specialized class of software problem —the realization of deterministic real-time control system re quirem ents. This kind of problem sets up readily in finite state machine representation where— and here is one possible key to software safety assurance—global algorithmic behavior is fully visible and predictable. Further support is given by Bowen and Stavridou, from the Program m ing Research Group at Oxford, in “Safety-Critical Systems: Formal m ethods and standards” [BS92]: A particularly attractive feature of this direct im plem entation in hard ware [talking about Program m able G ate Arrays] for safety-critical sys tem s is th a t the tim ing aspects of the program can be considerably sim plified if synchronous circuits are used. For example, in [Compiling Oc cam into PGAs] all assignment statem ents take one clock and (perhaps 4 T h is definition of asynchrony is different from the com puter engineering notion o f an unclocked circuit, such as a flip-flop. 9 surprisingly) all control statem ents take no clock cycles since the control operates between clock edges. Additionally, the natural parallelism of the hardw are can be used to great advantage. Parallel program s can run truly concurrently and parallel assignments of several variables (up to the entire state of the program ) still only take one clock cycle. This looks like a very promising research area for the 1990s... 1.2 S y m b o lic V erifica tio n The form al verification of transform ational program s dates back to 1967 and Floyd’s m ethod of inductive assertions[Flo67]. Hoare followed in 1969 with his axiom atic approach and the now famous “Hoare” triples[Hoa69]: P{S}Q where if the assertion P holds in the state before statem ent S is executed, then Q will hold im m ediately after S. In the early and mid 70’s, the sequential program proof techniques were adapted to concurrent programs[Asc75, LS82]. The basic idea is give to Hoare-style proofs for each statem ent and then show th a t statem ents in different processes do not interfere by invalidating any of the assertions in the individual statem ent proofs. A completely new approach to verifying reactive systems was m ade possible by the development of tem poral logic which is a form of modal /oghc[BS79]. M odal logic deals with the tru th of propositions in possible worlds. It introduces several quantifiers, two of which, necessity and possibility, are interesting to program veri fication. A proposition P is necessary, w ritten d P , if it is true in all worlds, and it is possible, w ritten O P , if it is true in at least one world. Necessity and possibility are quantifiers over possible worlds. For example, it’s possible th a t there is a world where C anada is south of the United States, and it ’s necessary th a t tru e = tru e in all worlds. In 1977 Pnueli published a paper, “The tem poral logic of program s,” [Pnu77] th a t introduced tem poral logic where possible worlds are identified w ith possible times. Now, a necessary proposition holds for all times in a program ’s execution, and a 10 possible proposition holds for at least one tim e. The tru th of a form ula is defined w ith respect to a Kripke structure (or model)[HC77] which is a m athem atical model of the program ’s behavior. This point is crucial, in order to reason about a program iwe m ust encode it into a m athem atical model th a t is appropriate for the logic. The synchronous finite state machines discussed in the previous section can be encoded as Kripke structures. Kripke structures are discussed in Section 2.1.1. An assertion in tem poral logic generally expresses either a safety or liveness (property. A safety property is one th at m ust always hold, such as a traffic light jcontroller only allowing one light to be green or yellow at a tim e. Safety properties state th a t nothing bad ever happens. A liveness property specifies th a t something ^good m ust eventually happen—at least one traffic light m ust be green or yellow at {the intersection of the two roads. Owicki and Lam port introduced the “leads-to” quantifier[OL82]: given two (propositions P and Q, the fact th a t if P holds then Q will eventually hold is w ritten ]P '^Q . T he leads-to quantifier is a shorthand for D (P — * O Q ), i.e. it is always the case th a t if P is ever true, then Q m ust be true at th a t tim e or later. In 1982 H arter put an upper bound on this quantifier[Har82]: if P holds then Q will be true within a steps which is w ritten P Q. H arter’s work represents the beginning of the quantitative view of tem poral logic: we will not just state th a t som ething eventually happens, we’ll given an upper bound on when it happens. Several other tem poral •logics with bounded quantifiers followed[Koy87, HMS88]. Shortly thereafter, a new semantics for tem poral logic was developed th a t is based on branching time versus the linear time of Pnueli’s logic[CE81b, EH86]. The sem antics of a linear tim e tem poral logic is defined along a sequence of states. Given a sequence, the formula CUP is true iff P is true in every state on the sequence and O P is true iff P is true in at least one state on the sequence. In branching tim e, formulas are interpreted with respect to states, not sequences. For exam ple, the branching tim e form ula A G P is true in a state if P is true at all times along all jpaths leading out of the state. The two forms of logic have different expressive ipowers. j M any other logics th a t are not based on the tem poral framework have been iproposed for specifying real-tim e systems. An example is Real Tim e Logic[JM88] 11 jwhich is based on arithm etic up to addition (Presburger arithm etic)[End72] and a predicate 0 (e , i , t ) which states th a t the *-th occurrence of event e happens at tim e RTL is very expressive but the RTL satisfiability problem is undecidable (see below) which, in a sense, makes the logic too strong. There is considerable debate on the appropriate logic for reasoning about real- jtime systems. Should it be a tem poral logic? Is linear or branching tim e the best? M aybe the tem poral framework is too weak and we would be b etter off w ith a stronger logic like RTL? We will use three criteria for selecting a real-tim e logic: 'E x p re ssiv e n e ss. This is the most fundam ental: is the logic strong enough to w rite complete specifications? Ideally, we would like a logic th a t can characterize any difference in behavior between two systems. Also, a logic should have an “economy of expression”— short formulas can express complex meanings. M e c h a n iz a b ility . Given a formula and a model, is there an algorithm th a t decides if the model satisfies the formula. This is essential for autom atic verification. D e c id a b ility . Given a formula, is it satisfied by any model? If this can be answered for all formulas, then the logic is said to be decidable.5 Decidability is essential for controller synthesis, i.e. given a specification, find a model (program ) th at m eets the specification. It is not required for program verification, and its in clusion as a criteria here might be controversial. However, autom atic program verification is ju st the first step to the ultim ate goal: autom atic synthesis of program s from specifications. If autom atic verification becomes popular, based on an undecidable logic, then many of the specifications developed will be worthless for synthesis. In other words, the logic should be strong enough, but no stronger. The simplest example is sentential (boolean) logic which is mechanizable and decid able by building tru th tables. However, it is not expressive enough since there are no quantifiers and tim ing properties cannot be specified. M any real-tim e logics are 5 T h is form o f decidability is different from decidability o f a theory. A theory is th e set of all jformulas satisfied by a given m odel. For exam ple, G odel showed that th e theory o f our intuitive m odel of arithm etic is not decidable[End72]. I 12 | ; ----------------------------------------------- expressive and mechanizable but not decidable (RTL). Linear tim e tem poral logics ^are decidable, b ut are difficult to mechanize and do not appear to be strong enough jto distinguish between systems with different behaviors. The branching tim e logic ‘ RTCTL is expressive, mechanizable (C hapter 4), and decidable, and is the logic jused in this thesis. RTCTL is a real-time extension to C om putational Tree Logic j(CTL). The Carnegie Mellon symbolic model checker is based on CTL. The case for the choice of RTCTL will be argued more fully in Section 4.1. T he practicality of symbolic model checking rests on the representation of boolean form ulas. M ost representations, such as tru th tables or conjunctive norm al form, require space th a t is exponential in the num ber of state variables. For example, Jadding a single variable to a tru th table doubles its size. This defeats the en tire purpose of symbolic model checking. However, in 1986, Bryant introduced a new representation of boolean formulas called the Ordered Binary Decision Diagram J(OBDD)[Bry86, Bry92] th a t allows a small representation for many useful functions. |The com bination of symbolic model checking with B ryant’s OBDD representation lets us get around the state explosion problem for many useful reactive systems. The central algorithm in symbolic model checking is com puting the predecessors, or pre-image, of a set of states. This is due to the fact th a t the symbolic model checking rules work backwards from the atom ic formulas. In this thesis, a new pre image algorithm called Step is given th at is optimized for synchronous system s with unconstrained state variables. Step uses a “fully partitioned” representation of a system ’s model th at dram atically reduces its size. This allows larger system s to be verified th an is possible with existing pre-image algorithm s th a t use a monolithic system representation. RTSMC is a program and we should be reasonably convinced th a t its algorithm s are sound. A faulty verification tool is worse than no tool at all. RTSMC is based on two key algorithm s: I T E for OBDDs and Step. In this thesis each are proved to be correct. The proof th a t I T E is correct has not previously appeared in the literature. 13 1 .3 C o n tr ib u tio n s an d P la n The contributions of this work are in two broad areas: system modeling and system verification. The specific contributions are: S y ste m m od eling: • The Sal language for implementing real-time controllers. • An encoding of synchronous systems th at allows the detection of race condi tions, and the race condition detection algorithm. • The identification of unconstrained state variables as the sole source of non determ inism in real-tim e controllers. • The use of unconstrained variables to model asynchronous systems in a syn chronous framework. S y ste m verification : • Generalization of symbolic model checking to Real-Time C om putational Tree Logic and the first application of symbolic model checking to synchronous real-tim e systems. • D em onstrations of real-tim e symbolic model checking on three sample systems. • An efficient algorithm for com puting the predecessors of a set of states for synchronous systems with unconstrained state variables. • A form al development of the techniques with all definitions and proofs, in cluding correctness proofs for the key algorithms. The bulk of this thesis is divided into four chapters. The next chapter defines a synchronous, finite-state, real-tim e system in term s of a Kripke model and shows how models can be represented using boolean formulas (Section 2.1). N ext, S a l is introduced and its semantics is given by functions th a t m ap S a l program text into a Kripke model represented as a boolean formula (Section 2.2). As p art of 14 the S al sem antics, race conditions are defined and an m ethod for finding them is given. A complete Sal im plem entation of the traffic light controller is presented in Section 2.2.4. C hapter 2 ends with a section on related languages for program m ing controllers (Section 2.3). C hapter 3 deals with the d ata structure (OBDD) and key algorithm s th a t sup p ort real-tim e symbolic verification. In Section 3.1 the OBDD d a ta structure is introduced and its fundam ental operation, I T E , is presented and shown to be cor rect. Section 3.2 develops the main algorithmic advance of this thesis, algorithm Step. The perform ance of S tep is compared with other pre-image algorithm s in Section 3.3. C hapter 4 contains the extension of symbolic model checking to RTCTL. It begins w ith a general discussion of logics for specifying real-tim e systems. In p ar ticular, the two m ajor forms of tem poral logics, linear tim e and branching tim e, are com pared. Section 4.2 contains the formal syntax and semantics of RTCTL and, in Section 4.3, the RTCTL symbolic model checking rules are developed. The chapter ends w ith some examples and comparisons with related work. C hapter 5 contains the results of applying real-tim e model verification to three applications: 1. the traffic light controller (Section 5.1), 2. an elevator controller (Section 5.2), and 3. a rule-based system th a t performs some Space Shuttle di agnostic functions (Section 5.3). For each application, a Sal im plem entation and RTCTL specification are given followed by the tim e required for RTSMC to check th e specification for various configurations of the systems. Applications 2 and 3 are intractable by conventional model checking approaches. Finally, this thesis ends with some concluding rem arks and directions for future work. 15 C h a p te r 2 M o d e lin g R e a l-T im e C o n tro llers To understand the meaning of a system, it m ust ultim ately be expressed in term s of a m athem atical model. The semantics of program m ing languages are defined in jterms of models as are the notions of satisifiability for logics. A model of a system ■ is the ultim ate referee of the system ’s behavior and serves to connect disparate approaches to im plem enting and reasoning about the system. We will model systems using a variant of a Kripke structure which is defined in the first section of this chapter. In Section 2.1.2, an alternative representation of Kripke structures, in term s of boolean formulas, is given. The boolean form ula representation is induced by the mapping 0 , which is shown to be an isomorphism of Kripke structures into the boolean formula representation. This isom orphism is crucial since it allows us to m anipulate the boolean form ula representation of a model as if it were the actual model. For many problems, working w ith the boolean form ula representation is much faster, and this is the essence of symbolic model checking. One element of a Kripke structure is the state transition relation which m aps a state into its successors. For synchronous systems, the relation takes a special form which is discussed in Section 2.1.3. The pre-image algorithm Step takes advantage of this form. Section 2.1.4 presents a new formulation of the state transition relation ■for asynchronous systems. The basic idea is to use unconstrained state variables as a source of random ness to control the interleaving. The exciting p art is th a t Step, which is optimized for synchronous systems, is also applicable to asynchronous system s. 16 S a l is introduced in Section 2.2 with a formal definition of its syntax and opera tional sem antics. S a l is intended to be a minimal language for im plem enting small real-tim e controllers. It lacks m any m odern program m ing language features, such as encapsulation mechanisms and types. Instead, the language is focused around the concept of a rule which is key to reactive systems. Furtherm ore, S a l is highly concurrent, in th a t all enabled rules are fired in parallel. O ther languages also have this property, but they restrict the possible programs by dem anding th a t the condi tions th a t enable rules be statically disjoint. This is unnecessary in S a l since race conditions are detected autom atically which is described in Section 2.2.3. A complete Sal im plem entation for the traffic light controller is given in Sec tion 2.2.4. The chapter ends with a discussion of other languages th a t are related to Sa l . 2.1 A M o d e l for R e a l-T im e C o n tro llers O ur intuitive model for real-tim e controllers is a finite-state synchronous system. Such a system consists of inputs, outputs, registers, and a com binational logic n et work, as shown in Figure 2.1. These components are synchronized by a global clock. At each tick of the clock, the logic network computes new values for every register based on the inputs and the current register values. The new values are then latched into the registers and the cycle repeats. For our purposes, the outputs of the system are the current register values. One possible way of thinking about the clock is simply as a square wave generator w ith a fixed period. A t the rising edge of each wave, the logic network senses the current state of the inputs and the registers. Based on this state, it com putes a new set of register values. These values are then latched on the falling edge of the wave. The cycle repeats on the next rising edge. 2 .1 .1 A F o r m a l M o d e l O ur m athem atical model for controllers is a Kripke structure. Let V = v q , u j , . . . , un_j be a set of two-valued state variables. These are the bits of the controller’s registers and its inputs. Let U C V be just the inputs (unconstrained state variables). A i 17 t O U TPUTS 1 ^ > NEW VALUEsI> LOGIC NETWORK CURRENT VALUES Figure 2.1: Basic model of a synchronous system with unconstrained state variables (inputs). state is a tru th value assignment to the variables in V. The set of all states for the variables V is w ritten £ y , i.e. E y = {s|s : V {0,1}}. Let I C E y be the set of initial states. This contains all the valid initial tru th value assignm ents to the variables in V. The final p art of the model is the state transition relation N , which is a to tal binary relation on E y . For each state s € E y , N gives the states th a t can be reached from s in one tim e step. These states are known as im m ediate successors. By being to tal, the relation insures th a t each state has at least one im m ediate successor. In the absence of unconstrained state variables, every state has exactly one successor. It is the unconstrained state variables th a t can cause branching to m ore th an one state. A simple example will make this clear. Consider a two bit counter w ith an ex ternal input th a t resets the counter. The state variables are V = {reset, ci,Co} with U = {reset}. A given state represents a unique encoding of the state variables. For this exam ple the values of the state variables are given by the binary representation of the corresponding sta te ’s index. For state s&, the index in binary is 110 which corresponds to reset = l,c i = 1, and C o = 0. The state transition relation is > ^ 0 s2 ^3 s4 s5 56 s7 50 1 1 51 1 1 s2 1 1 53 1 1 (2 .1) 54 55 56 57 where a 1 represents a transition between a state 5 and a possible successor s'. In the absence of a clear, the counter counts up and “wraps around” to zero. If the clear is set, the counter goes to zero on the next tick. From every state, there is always a branching to two successors, where one successor has reset — 0 and the other has reset = 1. This is a characteristic of unconstrained state variables. Even N = 19 though states S 3 . . . 3 7 have the same successors, they are all distinct states since the counter has a different value in each. Also note the regularity of the relation. This is not atypical and is one of the reasons why symbolic model checking is more efficient th a t traditional model checking algorithms. The definition of a model is as follows. D efin itio n 2.1 A model M is a tuple {V ,U ,I ,N ) where V is a set of variables, U C V are the unconstrained state variables, I C E y is the set of initial states, and N is a total binary relation on E y that gives the successors to any state in E y . This model differs slightly from the definition of a Kripke structure given in the literature. Typically, a Kripke structure is defined as a triple (5, R , L) where S is a set of states, R is a total binary relation on S, and L is a m apping from S to sets of atom ic formulas in the logic. Given a state s, L(s) is the set of all true atom ic formulas in s. For our purposes, the atom ic formulas are the state variables V and any tru th value assignment to the variables in V is a valid state. Thus, the two kinds of models are related by S — E v , R = N , and L : E y 1 — > 2V where 2V is the powerset of V. The model of Definition 2.1 also defines the initial states, since th ey ’re required for verification, and the unconstrained state variables. It is a Kripke structure tailored for our purposes. 2 .1 .2 A n A lt e r n a t iv e R e p r e s e n ta tio n The models of Definition 2.1 are represented by sets and a binary relation. In this section, we will develop an alternative representation of models, in term s of boolean form ulas, th a t is com putationally more efficient for model checking. The representations are equivalent in the sense th a t given a model M and its boolean form ula representation M , there exists an isomorphism of M into M . Any sequence of operations on the elements of M may instead be perform ed on the elem ents of M w ith an equivalent result and at often greater speed. The m ath behind both representations is a boolean algebra. D e fin itio n 2.2 A boolean algebra is a tuple (B, + # , -jg, ->#, 0,1) where B is a set, 0,1 G B , +b ■ B 2 B , -b : B 2 i-+ B, and -1 b : B > - * ■ B , such that for all b € B: • b +b 0 = b and b -b 1 = b; 20 • b A b -iijgft = 1 and b -b — > gb — 0 ; • +B and -b are commutative, associated and distributive. An algebra is often nam ed by its set. For any nonem pty set B , (2 B , U, fl, c , 0, B ^ is a boolean algebra where c is set complementation[Dur79]. This boolean algebra is nam ed 2s . A nother example of a boolean algebra is boolean (predicate) logic. The well form ed formulas of boolean logic are constructed from boolean variables selected from some set V and the logical connectives -• (not), • (and), and + (or). The set of all well formed formulas is nam ed £®°o1. The standard semantics of boolean logic is assum ed, in particular, the connectives are free to return any form ula th a t is allowed by th e semantics. For example, “/ i ” “+ ” “/ 2” may simply return “( / i + / 2),” or, alternatively, it may return some kind of reduced, or canonical, form ula as the result. jThe actual underlying representation of boolean formulas is not im portant at this ipoint, but it does become im portant later and is discussed fully in Section 3.1. Given |a tru th value assignment (state) s to the variables in V and a form ula / € £®°o1, / | s as the value of / for the state s. As expected, ^£®°o1, 0,1^ is a boolean Llgebra. One of the goals of this section is to “connect” the boolean algebra 2Sv to the boolean algebra £®°o1. To do this we need the notion of an isomorphism. In general, .an isom orphism is a one-to-one m apping of one algebraic structure into another jalgebraic structure th a t preserves the operations. For boolean algebras, we have: 'D e fin itio n 2.3 A n isomorphism of a boolean algebra (A, + a , * A, ~'A,0a, 1 a ) into a i boolean algebra (B, + b, ‘B, ~'Bi Ob, 1b) is a one-to-one mapping 0 : A t— > ■ B such ; that for all s ,t 6 A : Q(s +A t) = ® (5) +B ® (0 0 (5 .A t ) = 0 (5) -B 0 (t) j jThe notion of an isomorphism can be generalized to any operation. For our purposes, we only need to consider boolean algebras th at are augm ented by a binary relation. I 21 D efin itio n 2.4 For all boolean algebras A ,B and binary relations R a on A and R b on B: 0 is an isomorphism of the algebraic structure (A ,R a } into the algebraic structure (B , R b ) iff o. © is an isomorphism of A into B and b. for all a £ A: Q(Rao) — i? B © (a ). For an arb itrary model M = (V, U, I , N ) , we are going to show how to build its boolean form ula representation M — ( v , U, I, . For the m om ent, boolean form ula representations are w ritten using the hat notation. The hats will be dropped once the isom orphism between the two representations is dem onstrated. To dem onstrate an isom orphism between M and M it is sufficient to define a m apping 0 : e 2pv i-* £ y oal and show th a t it is an isomorphism of ^2Sv% into ^£®ool,iV^ . Note th a t the dom ain of 0 is sets of states. This immediately gives I, since for any set of states S C E y we have S = 0 (S ). Also, N S is just those states th a t are successors to the states in S, i.e. N S = € S and (s,s') £ N }. The plan for the rem ainder of this section is to 1. define 0 , 2 . show th a t it is an isomorphism of boolean algebra 2Sv into £ y °o1, 3. define N and the operation N S , and, finally, 4. show th a t 0 is an isom orphism of the two model representations. The boolean form ula representation of a state s is a conjunction term s, one for each variable v £ V , where if v is false in s the term is otherwise the term is v. For exam ple, the boolean expression of state 56 for the resettable two-bit counter is i 6 = reset ■ ci • -ico. The only tim e this formula is true is when the system is in state 56- In general, for all s ,t £ E y ,s |( iff t = s. The m apping 0 is defined as follows. D efin itio n 2.5 For all sets of variables V and sets of states S C E y : S = e ( S ) = 2 > (2 .2 ) Note th a t given a set of states S, 5 |s is true iff s £ S and, furtherm ore, this fact implies th a t 0 is one-to-one. This boolean representation for a set of states allows ja considerable economy of expression. For example, the set of states S where some 22 variable v is tru e is ju st 5 = v. The set of all states is logical true, 1 , and the em pty set is logical false 0. T he claim is th a t 0 is an isomorphism. L e m m a 2.1 For all sets of variables V: the mapping 0 : 2S v > i — » £ y °o1 is an iso morphism of 2 Sv into £®°o1. P r o o f. We already know th a t 0 is one-to-one so it’s only necessary to show th a t the operations agree (Definition 2.3). For all 5, T 6 2E'/ : e ( s u r ) = Y . J s € S u T = £ * + £ » sgs te r = 0 ( 5 ) + 0 (T ) and similarly for 0 ( 5 fl T ). □ Note th a t 0 is not onto £ y °o 1 and, therefore, the two algebras are not isomorphic. This will be discussed below. The next step is to define N for a model M . N is w ritten in term s of variables in V and their prim ed counterparts in V'. The boolean representation of a prim ed state s' also uses prim ed variables, e.g. ig = reset' • c[ • -ic</. For a form ula F th a t depends on variables in V and V', let Fs> s> be the value of F in the states s, s'. N ote th a t this is a tru th value, not a boolean formula with some unevaluated p arts since s, s' jointly give a tru th value to all variables th a t can appear in F. Consider a single state s th a t has the successors N s = {sq, .S j ,...} . This can be expressed with a boolean form ula of the form F = s ■ (< § o + -f ...) which has the required property th a t F\StSi iff s' £ N s. This leads to the boolean representation of a state transition relation. 23 D efin itio n 2.6 For all sets o f variables V and binary relations N on 25 * = £ » • £ * ') • s€ S v \ s'tN s N ote th a t for any N , iV|S iS / iff (s,s') 6 N. The final step in developing the isomorphism between the two representations is to define w hat it means to apply a N to a set of states S. This operation, N S , m ust yield a boolean form ula in the variables V such th a t (N S )\sj is true iff s € S and {s , t) € N. The idea is to form the union of N \s for all s € S and then to substitute v € V for v' in the result. Following common notation, this substitution is w ritten [V \u]. By Lemma 2.1, a union can be replaced by a logical or, giving N S = £ i V | s [t/\i;] s£ S = £ ■ 5)1 . [ « » • (2-3) sglV This expression might look strange, but consider a state s S, then (N • 5')|s = 7^ |s • 0 = 0 which indicates there are no successors to a state not in S. Similarly, for a state s € S : (N • 5 ) |s = N \s ■ 1 = T V ^s which, as expected, is ju st the successors of s. Equation 2.3 m ust be w ritten completely in term s of boolean formulas. To do this, we’ll introduce an existential quantifier for variables in V th a t has the definition 3 (v)F = E |„=0 + F \v=1 (2.4) where -F j^o is F with v set everywhere to 0 and similarly for - F j^ i. This generalizes to m ultiple variables: 3(» e V ) F = £ F \, (2.5) j s € Z v since F is being evaluated for all tru th value assignments (states) to the variables in V. The operation N S can be defined completely in term s of boolean logic by substituting Equation 2.5 into Equation 2.3 which leads to this definition: 24 D efin itio n 2.7 For all models M = (V , U,I, N) and sets o f states S C N S = 3(t> € V ) N - S [ v '\v ] . We have the key result of this part. T h e o re m 2.1 For all models M = {V ,U ,I ,N ): 0 is an isomorphism of M into M = (V , U, I, N ) . P ro o f. It suffices to show th a t 0 is an isomorphism of the algebraic structures (oPv and ^£®°o1, JV^ . By Definition 2.4 it is necessary th a t a. 0 is an isom or phism of 2sv into £® °o 1 which was shown in Lemma 2.1, and b. N and N m ust agree. Let S C E v : N Q (S ) = N S = 5Z ^ frV] s £ S By Definition 2.7 and Equation 2.3. S&S and s*£N s Since iV|s,« ' iff {s , s ') £ N (Definition 2.6). = £ 5 seNS = Q (N S ) By Definition 2.5. □ The im portance of this theorem is th at any operations th a t can be expressed in term s of the sets and relation in M , may be performed on their boolean representations in M w ith the equivalent result. The correctness of symbolic verification is based on \this theorem. Furthermore, it is the freedom to represent models as boolean formulas that makes the technique efficient. I The two representations are not isomorphic since the isomorphism 0 is into not onto. The trouble is th a t the cardinality of the boolean algebra 2^v is finite b u t the cardinality of £® °o 1 can be countably infinite (No). It is simple to m ake the algebras isom orphic by insisting on a canonical representation for boolean formulas. Then 0 becomes onto and invertible since the cardinality of the sets are the same and i t ’s already a one-to-one m apping. Algebraic systems connected by an onto isom orphism are isomorphic. We will not do this formally since real-tim e symbolic verification doesn’t require a canonical representation and the future designers of representations tfor boolean formulas should be given the maximum am ount of leeway. We do, however, require th a t the two representations be isomorphic for the sem antics of Sal which can only be properly defined in term s of the “real” model, i.e. the one given in Definition 2.1. The trouble is th a t Sal compiles into the boolean form ula representation of the model. This is a minor technical detail th a t can be resolved by resorting to a canonical form for Sal compilation. This turns out to be irrelevant since RTSMC does use a canonical form for boolean formulas (OBDDs). 2 .1 .3 A Form o f N for D eterm in istic S y stem s The boolean representation takes a special form for synchronous system s. For a state variable v, let S v be the states th a t lead to v being true at the next tim e step: S v = {s| (s ,s r) € N and s \ v ') = true}. The function f v is the boolean formula representation of Sv, i.e. fv = Q(SV). (2.6) This function is precisely the one com puted by the com binatorial network to update the state variable v at each tim e step. I t’s called the variable transition function for 26 v. Assume for a m om ent th a t there are no unconstrained state variables (U = 0). Then, the state transition relation is n = n v' o /„. v£ V This form of the state transition relation has been recognized by m any au th o rs.1 W hat has not been previously noticed is th a t it also applies when there are uncon strained state variables since the system does not update the elements of U. This leads to the m ore general form N = I ] v ' & f v (2.7) v e v -u Note th a t this form ula m ay still depend on elements of U since they m ay appear in the individual f v. This observation allows us to develop a fast pre-im age algorithm in C hapter 3 th a t works with unconstrained state variables. As an example, the variable transition functions for the two-bit resettable are fvo = -'reset ■ -m0 f v, = preset • (n0 © vx) where ® represents exclusive-or. Note th at there is no f reaet- 2 .1 .4 F o r m s o f N f o r A s y n c h r o n o u s S y s te m s Equation 2.7 can also model asynchronous systems by using unconstrained variables as a source of random ness. There are two basis semantics for asynchronous systems: ’ A s prom ised, th e h ats have been dropped. 27 interleaving and simultaneous[McM92]. For interleaving sem antics, only one state variable m ay be changed per tim e step .2 In this case, the transition relation is N = (V < = > fv) • J J w' O w v£V _ w£V— { r> } which states th a t one variable v is updated and the rest rem ain the same. This model is useful for interleaving processes th a t share a single processor. An alternative, and equivalent approach, is to allow an external random num ber generator to select which variable to change at each step. This generator is con structed from unconstrained state variables. Assume th a t there are n state variables such th a t only one may be changed at a tim e. Introduce m = [log2 n\ new uncon strained state variables and interpret the variables as a random num ber generator R — {j'o? • • •»I'm-1} th a t gives a value, w ritten R , in the range [0 , n — 1] a t each step. This value will be used to select the variable th a t changes. A variable Vi will only change if R = i which gives the following form for the f v in Equation 2.7: fvi = ((R ± *) • vt-) + ((R = i) • gVl) (2.9) where gV i = Q (SVi). This reduces an asynchronous transition relation to a syn chronous one th a t can be m anipulated more efficiently. Similarly, for sim ultaneous asynchronous systems, the transition relation is given by N = (v* f v) + (v* < S > v). vev This allows any num ber of variables to change each time step. To model this, we add n unconstrained variables r,- such th a t V { changes only if r; is true which gives fvi = (fi ■ Vi) + (-irj -gVi) jfor Equation 2.7. 2ActuaUy, only one register, which is a collection of state variables, m ay be changed at a step. T h is will be m ade clear in the next section. (2 .8) 28 A first objection to this approach is the addition of new state variables. However, as will be seen in Section 3.2, the Step algorithm does not use the prim ed variables so it works w ith half the num ber of variables as other pre-image algorithm s. This is a dram atic savings in the OBDD representation. For the interleaving model, only log n new variables are introduced, which is a large savings. For the sim ultaneous m odel, up to n new variables may have to be introduced, which is no worse th an the n prim ed variables. In practice, only one new variable for each register is required. T he rem ainder of this thesis concentrates on synchronous real-tim e controllers w ith unconstrained state variables. However, all techniques presented are applicable to the asynchronous system forms described here. This is an interesting avenue for future work. 2 .2 S y n c h r o n o u s A c tio n L an gu age This section introduces the Synchronous A ction Language (S a l). 2.2.1 Sal C on cep ts and S yn tax Sal is based on rules of the form condition => register expression where condition and expression are a function of the state variables. If condition is true, expression will be evaluated and assigned to register at the next clock tick. T he evaluation of an expression and updating of a register is called an action. More th an one rule can apply to a register, and all rules are considered simultaneously. The S a l compiler checks to insure th at only one rule can be true at a tim e for a given register. This is known as race condition detection, and is discussed in Section 2.2.3. If no rule is tru e for a register, the default rules are considered. The default rules are ju st like regular rules except th a t there can only be one per register. This is common enough th a t it justifies a special syntax. Finally, if no rules are enabled, including the default rule (if present), for a register it retains its current value at the next tim e step. 29 Sal is a concurrent language and every rule is evaluated in parallel. In a sense, Sal is fully concurrent, in th at every register is updated on every clock tick even if th a t m eans a register ju st retains its current value.3 A Sal program consists of four sections: register declarations, input declarations, rules, and default rules. Every register and input m ust be declared, including a size in bits. If a size isn’t given, it is assumed to be one. A register can optionally be given an initial value which is used to form the set of initial states. The inputs are all unconstrained as discussed in C hapter 1 and the previous section. We’ll use a simple up/down counter with an external reset to introduce the Sal syntax. The following code: r e g i s t e r c o u n te r@ 8 := 0 ; d i r e c t i o n ; in p u t r e s e t ; d e f a u l t 1 => c o u n te r := + + co u n ter; declares an eight bit register c o u n te r, a single bit register d i r e c t i o n and a single bit input r e s e t . The counter is always initialized to zero when the system starts operation. The only rule is the default rule which is always tru e and causes the counter to be increm ented at each clock tick. The direction flag never changes, i.e. i t ’s a latch th a t keeps its initial value for all time. We can make the counter more interesting by m aking it count up or down de pending on the direction flag: r e g i s t e r c o u n te r@ 8 := 0 ; d ir e c t i o n ; in p u t r e s e t ; r u l e !d i r e c t i o n => c o u n te r := — c o u n te r; d e f a u lt 1 => c o u n te r := + + co u n ter; I T h is high level of parallelism is easiest to achieve in hardware, although it can b e sim ulated in softw are or firmware w ithout any difficulty by paying a perform ance penalty. For slow ly clocked sy stem s (and the definition o f “slow ” is becom ing very fast) w ith relaxed cost requirem ents, the [flexibility o f softw are m akes it the choice. For extrem ely high speeds, such as bus controllers, or jhigh production runs, custom logic is a reasonable choice. Program m able logic falls som ew here in betw een th e tw o and is probably the b est im plem entation technology to d ate for th e applications covered in this thesis. 30 The symbol ! means logical or bitwise negation depending on the context. A lternatively, this can be w ritten without using default rules: r e g i s t e r c o u n te r@ 8 := 0 ; d i r e c t i o n ; in p u t r e s e t ; r u l e !d i r e c t i o n => c o u n te r := — c o u n te r; d i r e c t i o n => c o u n te r := + + co u n ter; A nother useful addition is to make the counter start over at zero whenever the reset input is true: r u l e !d i r e c t i o n => c o u n te r := — c o u n te r; r e s e t => c o u n te r := 0 ; d e f a u l t 1 => c o u n te r := + + co u n ter; where the declarations are the same as before. This is a erroneous program since r e s e t and ! d i r e c t i o n can be true at the same time. The fix is simple r u l e ( ! d i r e c t i o n ) & & !r e s e t => c o u n te r := — c o u n te r; r e s e t => c o u n te r := 0 ; d e f a u lt 1 => c o u n te r := + + counter; where & & is logical and. The form al syntax of Sal is given in Figure 2.2. Symbols in the language, i.e. term inals, are given in ty p e w r ite r type. Non-term inal symbols are given in italics. Square brackets m ean zero or one instance of the enclosed symbols, curly braces m ean zero or m any instances, and vertical bar (|) means choice. The values of expressions are assigned to registers and can be used to construct conditions. Expressions are built from • registers and inputs (id); • the unary operators bitwise not (!), shift right (>>), shift left (<<), increm ent (++), and decrement ( — ); and • the binary operators bitwise and (ft) and bitwise or (I). 31 nat digit {digit} id «- letter {letter | digit | _} idjdecl <- id | id@nat[:=nat] regjdecl «- r e g is t e r idjdecl; {idjdecl;} inputjdecl <- input idjdecl; {idjdecl;} expr < — nat | id \ (expr) | \expr | » e x p r \ « e x p r | ++expr | ----expr | expr&iexpr \ expr\expr action «- id := expr cond i — expr | (cond) | !cond | condSzSzcond \ cond1 1 cond | expr=—expr \ exprl =expr \ expr<expr \ expr<=expr \ expr>expr | expr>=expr rule <- cond = > action{, action}; rules «- r u le rule; {rule;} defaults <- d e fa u lt rule; {rtt/e;} program <- [regjdecl][inputjdecl][rules][de faults] Figure 2.2: Sal syntax. 32 [There is no sign bit and all operations produce the minimum num ber of bits to exactly represent their result. This will all be m ade precise in the next section. The Jcurrent Sal im plem entation doesn’t support operator precedence so it is necessary |to use parentheses to remove ambiguities from expressions and conditions. In the absence of parenthesis, parsing is done left to right. Conditions evaluate to either true or false for a given set of register and input values. Conditions are constructed from • the unary operator not (!); • the binary operators and (&&) and or ( I I); and • the relational operators (== !=<<=> >=) applied to expressions. Again, parenthesis m ust be used to remove any ambiguities. It is common for several assignments to be enabled by a single condition. In this case, the assignm ents can all be listed, separated by commas, after the condition. This is equivalent to each assignment appearing in its own separate rule and all assignm ents happen at once. One final note about the syntax of Sal program s is th a t they are first processed by cpp, the C /C -f + language preprocessor. Here, comments are removed (denoted by / / ) and macros expanded. Macros are defined using #def in e. The m ost com m on case is the definition of a constant, such as #def in e Green 2. W henever the preprocessor sees the token Green it replaces it with 2 . Macros th a t take argum ents are used in the applications and their meaning should be clear from the context. The im portant point is th a t Sal never sees any of this, all of the com m ents are ■removed and substitutions m ade by cpp prior to Sal getting the program . The use of the preprocessor is intended to make program s easier to w rite and m ore readable. This is illustrated in the final version of the counter. / / A r e s e t t a b le up/down counter having S iz e b it s ( # d e fin e S iz e 8 # d e fin e Up 1 l#d efin e Down 0 33 # d e fin e True 1 •r e g is te r counterO Size := 0; j d ir e c tio n ; in p u t r e s e t ; •rule (d ir e c tio n == Down) & & O r e s e t) => counter := — cou n ter; r e s e t => counter := 0; d e fa u lt True => counter := ++counter; A Sal program for a more complex system, the traffic light controller, is given iin Part 2.2.4. 2.2.2 S a l S em an tics The sem antics of Sal is defined in term s of the model given in Definition 2.1. By Theorem 2.1, we are free to represent this model in term s of boolean form ulas and the m eaning of Sal program s is defined by “compilation” into boolean formulas. However, one should not lose sight of the fact th a t an operational sem antics is being built for Sal in term s of Kripke structures. This underlying m athem atical model is the connection between the language used to express controller im plem entations, Sa l, and the language use to expression controller specifications, RTCTL. It w hat follows, we will show how to build a model M = (V , U, I, N ) given a particular program . The set V contains the bits defined in the register and input sections. The set U C V contains only those bits defined in the input section. Let R be an initialized m bit register or input with bits {r0, ..., r m_ i} and initial value R inn = {no, n i , ..., n m_ i}. The boolean formula representation of the initial value for R is m— 1 in = n r * ° ni- i=0 34 T he set of initial states for the entire program , I, is the conjunction of the I r form ulas. Note th a t not all registers or inputs are initialized. In the absence of any initializations, 1 = 1 (all states are valid initial states). 4 An interm ediate form called an action triple is helpful in building the state transition relation and finding race conditions. The action triple {v , c, e) means th a t if the condition c is true, the state variable v G V — U will get the value e at the next clock tick. Both c and e are boolean formulas. Action triples result from breaking an assignm ent to a register into its individual bits. Before discussing the triples further, we need to define the meaning of the expressions and conditions th a t appear in S a l rules. The m eaning of an expression is complicated by the fact th a t registers m ay have different sizes and th a t operators may overflow or underflow. There are two issues: 1. w hat register size is used to carry out a specific operation, and 2 . are short registers “padded” with zeros (zero extension) or with the value of the highest order bit in the register (sign extension). The solution taken in S a l is simple. Given a S a l program , let M be the size in bits of the largest register declared in the program . Then, all operations are carried out mod 2M and all registers are zero extended to M bits. Only during an assignment is the result truncated back to the size of the destination register. O ther choices are possible. For example, S a l program s could be interpreted w ith a fixed m axim um register size th a t applies to all program s. This solution was rejected for two reasons: 1. the meaning of a program can change, even though the program itself is not changed, by someone deciding th a t the size is too small, and 2 . nobody can decide w hat is “big enough” for registers so it’s best not to fix a value th a t should “cover all cases.” Item 1 is very insidious, a program should only change m eaning when its text is changed. One disadvantage w ith the approach is th a t changing the size of the biggest register can affect the meaning of the program . B ut this is local to one program and it should be re-verified in any case. At first glance, a second disadvantage m ight be one of overkill: why use 32 bit operations on 2 bit quantities? Fortunately, this is 4 Initial values are perm itted for inputs, but they generally should not be used because in pu ts are beyond th e program ’s control. 35 not the case since the zero extension of smaller registers shows up in the boolean form ula representation and is simplified. The net effect is th a t operations seem to be carried out w ith ju st enough precision (mod2M). However, if sign extension was chosen, this simplification would not be available. The lack of sign extension is not an expressiveness problem , since signed arithm etic can be sim ulated w ith an unsigned semantics. The m eaning of an expression is given by the function £[] which takes an ex pression and returns an ordered list {eo,..,.. -z m - 1} where eo is the lowest order bit and so on. In general, each e,- can be an arbitrary boolean formula. The simplest expression is a register R and has the meaning £ [ - S ] = 7 * 0 ? ^ 1 > • ■ • j r m — 1 ? O m j • • • ■ > O m - 1 where 0m, .. . ,0 a /- i represents the zero extension of the m bit register to M bits. T he m eaning of an input is defined in a similar fashion. All operators work on one or two general expressions, for example, negation is defined £[\E] = { - i e 0 , ->ei,. . . , and bitwise and is 8[E&cE'] = {eo * e ' 0, e\ • e' x, . . . , • eM - i } - T he com plete semantics of Sal expressions is given in Figure 2.3. T he m eaning of a condition is defined by the function C[] which takes a condition and returns a boolean formula. The definition style is like th a t of expressions and the com plete sem antics for conditions is given in Figure 2.4. If an expression is found where a condition is expected, S a l uses the least order bit of the expression’s m eaning as the condition. A ction triples are built from a rule C =>R :=E 1 36 £[N) = {n0,ni,...,WA/-i} £[R] = {^0, ^1) " • j ^m — 1 »^m, • • — 1} £[/] = {*0j ® 1> • ■ • , * 7 J l — 1 , 0m, . . . , O jV f— 1} £[!£] = {->e0, -lei,..., £ [ « £ ] = {ei,e 2,...,eA /-i, 0} £ [ » E ] = {0, ei, e2, ..., eM- 2} £ [+ + £ ] = {-ieo, inc(E, 1),..., in c (E, M — 1)} £[— JS] = {-ieo, dec(E, 1),..., dec(E, M — 1)} £ [£ & £ '] = {eo • e^, ei • e'x, ..., ejv/-i • eM -i} £[E \E Q = {eO + eO : el + 5 • • • ) e M - \ + eM - l} where inc{E , *) = ->ei • ej + e,- • j < i and dec(E, i) = e; • + J J -lCi j < i and N is a n atural num ber, R is a register, I is an input, and E , E ' are arb itrary expressions with the meanings £[E ] = {eo,ei,... ,e ^ _ 1} and £[E’] = {eQ, ..., e ^ ^ } , respectively. Figure 2.3: The semantics of Sal expressions. 37 c m = . -i c C [C kkC ') = c c C[C\\C] = c + c C[E==E'] = (e0 o e'0 ) ' (ei •(eM-i < = » e'M- i ) C[E<E') = lt(E , E \ M - 1) C[E<=E'] = C { « E < E ) II dE == £'))] C[E>=E'] = C[dldE < £))] C[E>E/] = C[dUE <= £))] C[E\ =E'] = C[d\dE == £))] C[E] = eo where F F' _ / “,co • eo if * = 0 { -iei • ej + (e; -O e') • ^(.E, E \ i — 1) otherwise and C, C' are arbitrary conditions and E , E f are arbitrary expressions with the meanings £\E\ = {eo, e \ , . . . , ejw -i} and E[E] = {e'0, e^,. . . , re spectively. Figure 2.4: The semantics of Sal conditions. 38 as follows (recall th a t multiple assignments per rule are treated as m ultiple rules w ith the same condition). Let £[-£■] = { e 0? e\i ■ • • i eM - 1} and C[C} = c. C onstruct a triple (r,-,c,ei) for every bit, 0 < i < m in R. Recall th a t the register bits are in the set V — U. Each triple for a program P is added to the set Ap which is increm entally constructed during the compilation. Similarly, for the default rule C = > R := E form the triple (r,-,c • -1 cri,e,) where r,, c and e, are as before, with C y = (v,c,e)€ A p This condition is true if any condition pertaining to variable v in A p is true. These (default) triples are also added to A p. A fter action and default triples have been added to A p, the S a l compiler places the triple (v, -<cv, v) into Ap for every v 6 V — U. This forces a state variable to retain its current value when no rule or default rule is enabled. Finally, for every state variable v 6 V — U, the function f v (E quation 2.6) is defined as f v = J J c ^ e . (2 .10) (v,c,e)£Ap If a condition c is true, the value of the associated im plication will be e. If c is false, its im plication is true and the value of f v is determ ined by some other condition and expression. The state transition relation is then given by E quation 2.7. 39 2 .2 .3 R each ab le S ta tes, R ace C on d ition s, and E rron eou s P rogram s T he sem antics of S a l is well defined by the compilation procedure and the iso m orphism 0 except for the case of a register bit being sim ultaneously updated by m ultiple actions. This is commonly known as a race condition and can be thought of as a form of non-determ inism . The new value of a register bit th a t is subject to a race condition depends on the im plem entation technology and may even be random . Assume for a program P, Ap contains two action triples (v, ci,ei) and (v, C 2,e 2) and th a t there exists a state in which both c\ and C 2 are true. Due to the construction of f v (E quation 2.10) the model checker will assume the next value of v is given by (cj = > - ex) • (c2 = > ■ e2) which simplifies to e\ • e^. However, a hardw are im plem entation m ight try to drive bit v w ith the value of e\ and e2 simultaneously. If a “wired-or” technology is used, the im plem entation will com pute e\ + e2- A different im plem entation technology, such as software, m ight simply select the first true condition th a t it finds, say ci, and use its associated update formula, e\, to determ ine the next value of the bit. The scary p art is th a t the S a l program might satisfy its specification and the actual hardw are im plem entation might do something completely different. Thus, detecting race conditions is a crucial p art of verification because, w ithout it, we m ay be reasoning about an ill-formed system. The ability to detect race conditions is a unique feature of S a l and, along w ith model checking, guarantees the correctness of controllers. To properly detect race conditions requires com puting the set R of reachable states, i.e. states th a t can be reached from the initial states by any sequence of im m ediate successors. The reason is simple: if the only states th a t cause race conditions are unreachable, then it ’s senseless to flag an error. For exam ple, in the S a l program r e g is t e r XQ2 := 0; r u le (X ==0) II (X > 1) => X := 1; X > 0 => X :» 0; 40 th e two rules can fire simultaneously and update X w ith different values. However, the states th a t cause this, X = 2 or X = 3, are not reachable from the initial states. The set of reachable states for a given controller is often smaller th an the set of possible states, which is ju st all truth value assignments to its state variables. T he set can be defined as the union of states reachable in zero steps from the initial states, one step, two steps, and so on, thus, R = / + N I + N N I + .... (2.11) jThe upper bound on the num ber of steps is the to tal num ber of states, # £ y , since the controller can at m ost visit each state once before repeating a state. Let Rn = I + N I + ... + N . . . N I . S i . i ^ i ✓ n times The form al definition of a race condition is: D e fin itio n 2 .8 For a S a l program P, a race condition exists for v £ V — U iff there exists triples t — (v,c,e),f = (v,cf, e') £ A p, an integer i < # £ y , and a state s £ R % such that c|s = c'\a = true and e\s e'\s. I f there exists a race condition for any v, then the program is erroneous. Some m ight argue th a t this definition is too weak—th a t a race condition is trouble even if the associated expressions agree in value. There m ay be some tru th to this argum ent, but I ’m not aware of any current im plem entation technology where this 'is a problem . Certainly, i t ’s a trivial m atter to strengthen the definition if necessary. The reachable states can be com puted by iteratively forming R ° ,R 1,. .. using the boolean form ula representation until R % = i2,+ 1. This oftens happens for i much smaller th an # £ y . At each step i, we check R % against the race set G which is defined as ] T J 2 e • c’ • ->(e & e') ve-v t,t'^Ap,tjtt' where t = (v,c,e),tf = {v,cf,ef) . The algorithm for com puting the set of reachable states R and detecting race conditions is given in Figure 2.5. It is useful to check the partially form ed sets, R \ of reachables states since a race condition corrupts 41 Reachable(I, iV, G) : R = I lo o p if R • G 7^ 0 th e n fail (race condition) if R = N R th e n r e t u r n R e lse R = R + N R e n d Figure 2.5: Algorithm Reachable for com puting reachable states and detecting race conditions. the state transition relation and the final set of reachable states can be wrong. This is not absolutely necessary, since the first partial set th a t had a race condition will 'still be in the final set and this is sufficient for Sal to flag the program as erroneous. /This seems a bit sloppy however, since we should stop once we know the program ■ is erroneous. The problem of finding a state s where two formulas agree (or disagree) is equiva lent to the boolean form ula satisfiability problem (3CNFSAT) and is therefore AfV- complete. It m ay seem som ewhat strange to have a compiler solve A^P-complete problem s, but this is no harder than doing the model checking. Furtherm ore, the representation for boolean formulas often contains the com binatorial explosion. 2 .2 .4 T h e Traffic Light C ontroller This section presents a description and im plem entation of the first application, a simple traffic light controller (TLC ). P art 5.1 gives a form al specification in RTCTL and the results of applying RTSMC to the problem. Consider the intersection of a m ajor highway, such as US 101 between Los A n geles and San Francisco, and a side road. The goal is to keep the highway flowing w ithout starving the side road. There is a sensor in the side road th a t’s true if there is at least one car waiting. Normally, the highway light is green. If th ere’s a car w aiting at the side road and the highway light has been green for m ore th an Th seconds, then the highway light turns yellow. A short tim e thereafter, Ty (known only to C alTrans), the highway light turns red and the side road light turns green. 42 Once the side road light has been green for more th a t Ts seconds, or if there are no m ore cars w aiting at the side road, its light turns yellow. A couple of seconds later (Ty), it turns red and the highway light turns green. A n im plem entation of TLC consists of the following parts: 1. An input cars th a t indicates th a t a car is waiting on the side road. 2. A tim er of size flog2(Tft)] assuming th a t 2 \ = max(Th,Ty, Ts). In other words, the highway green tim e is the longest. 3. A set of multiplexed outputs th at control the highway and side road lights. Each set of outputs consists of two bits with the encoding Red = 0 , Y ellow = 1, and G reen = 2. A Sal im plem entation of TLC is given in Figures 2.6 and 2.7. There are a few notable item s. T he m acro In checks to see if the system is in a given state which reduces to a test against s t a t e . Second, the tim er normally counts up unless some other rule resets it to zero. 2 .3 R e la te d L a n g u a g es This section compares and contrasts Sal with some other languages th a t have been used for program m ing real-tim e controllers. A particular emphasis is given to the handling of race conditions. M ost controllers have traditionally been program m ed in assembly language or a high-level language like C. These languages are intended for general purpose com puters and are not well suited for handling controllers with a small num ber of state variables. A typical microprocessor has over a hundred bits in its register file and processor statu s word, not to m ention read/w rite memory. This makes verifying m ost program s th a t run on such machines intractable, even w ith symbolic model checking. However, the generality of these machines are not required for m any applications and a lower level approach is appropriate. 43 11 T r a f fic L ight C o n tro ller // / / S ta te s .•d e fin e Hwy.Green 0 j#define Hwy_Yellow 1 .•d e fin e Sid e.G reen 2 • d e fin e Side_Y ellow 3 / / L igh t co n sta n ts '•d e fin e Red 0 • d e fin e Y ellow 1 • d e fin e Green 2 / / Timer lim it s • d e fin e T .S iz e 7 • d e fin e T_Yellow 3 • d e fin e T_Green 120 • d e fin e T_Side_Lim it 15 r e g is t e r state@ 2 := Hwy.Green; / / current s t a t e timer@ T_Size := 0; / / tim er hw y_light® 2 := Green; / / highway lig h t sw itch encoded by c o n sta n ts sid e _ lig h t© 2 := Red; / / s id e road lig h t sw itch in p u t c a rs; / / 1 i f f cars a t s id e road • d e f in e In (S ta te_ V a lu e) ( s t a t e == S tate_V alue) Figure 2.6: TLC Sal im plem entation: Declarations and preprocessor definitions. I I 44 ■rule / / I f highway lig h t has been green fo r a t le a s t T.Green seconds / / and th e r e are cars at th e s id e road, th en t r a n s it io n to / / Hwy_Yellow In(Hwy_Green) & & (tim er == T_Green) ftft cars => h w y_ligh t := Y ellow , tim er := 0, s t a t e := Hwy_Yellow; / / Keep highway y ello w fo r a w h ile th en t r a n s it io n to Side_G reen In(Hwy_Yellow) & & (tim er == T .Y ellow ) => h w y .lig h t := Red, s id e _ lig h t := Green, tim er : = 0 , s t a t e := Side_G reen; / / Keep s id e road green w h ile ca rs or u n t il T_Side_Lim it In(Side_G reen) & & ((S c a rs) II (tim er == T _Sid e_L im it)) => s id e _ lig h t := Y ellow , tim er := 0 , s t a t e : = S id e.Y ello w ; / / Keep s id e road y ello w fo r a w h ile th en t r a n s it io n to Hwy_Green In (S id e_Y ellow ) & & (tim er == T .Y ellow ) => h w y_ligh t :® Green, s id e _ lig h t := Red, tim er := 0 , s t a t e := Hwy.Green; d e fa u lt / / The d e fa u lt tim er b ehavior i s to count u n t il T_Green i s reached tim er != T_Green => tim er := ++tim er; Figure 2.7: TLC S al im plem entation: Actions and defaults. 45 There are advantages to the low-level approach besides autom atic verification. For one, Sal and other related languages are highly concurrent which is impossi ble to achieve w ith single instruction stream processors. Second, Sal is suited to reactive system s as opposed to algorithmic (transform ational) approaches. Sal is based on two existing program m ing languages: B rooks’ inform al language jfor the Subsum ption Architecture[Bro86, Bro90] and M ok’s equational rule-based 'language EQL[Mok89]. Both these languages, and the input language to the CMU symbolic model checker (SM V), are discussed in the following sections. 2 .3 .1 S u b s u m p tio n A r c h ite c tu r e B rook’s subsum ption architecture is based on Augm ented Finite S tate Machines (A FM Ss). An AFSM consists of a traditional finite state machine augm ented w ith input registers, o utput ports, alarm clocks (tim ers), and a com binatorial network jthat can perform simple arithm etic and relational operations. The registers and sports all have a fixed size of, typically, eight bits. AFSMs can be interconnected us ing three connectives (direct, inhibit, and suppress) th a t are p atterned after synap- jtic junctions in neural systems. These networks are often used to control small 'autonom ous robots. The individual AFSMs are program m ed using a rule oriented language th a t has a LISP-like syntax. Each rule has a condition and then a body of operations th a t are perform ed if the condition is true. The operations m ay update registers (an AFSM m ay w rite into its own input registers), output values, and perform other simple com putations. Sal is patterned after the AFSM im plem entation language but there are dif ferences besides the syntax. F irst, Sal makes a distinction between registers and in p u ts. An AFSM input can be either, depending on if i t ’s connected to other J a FSMs or the outside world. It makes no difference in the AFSM program m ing 'language b ut i t ’s crucial to Sal. Second, AFSM rules are prioritized. If m ultiple rules are enabled, the first one listed in the text of the program is selected. This is Jan acceptable solution to the race condition problem but it can limit concurrency jwhich is discussed more in the section on the SMV input language. A final m inor difference is th a t Sal program s can have registers and inputs of varying sizes. 46 2 .3 .2 E Q L The design of Sal was also strongly influenced by EQL which is a language for developing real-tim e equational rule-based programs. An EQL program consists of declarations for state variables and a set of rules. A rule has a condition and a set of assignm ents to state variables. EQL program s are given an initial state and then begin executing. All rules th a t are enabled are fired and the variables are updated, just like Sal. This process continues until the state no longer changes. This is in contrast w ith Sal program s which are expected not to term inate. EQL is designed for a fixed set of inputs and has no concept of an unconstrained state variable. EQL program s can have race conditions. A special tool[W T W +91] has been developed for EQL program s th a t looks for sequences of rules th a t can interfere, i.e. cause race conditions. These rules sequences are known as incom patible braids. The tool is based on a static inspection of the program so th a t it will som etim es identify rules sequences th a t are not a problem. This does not happen w ith the Sal race condition detection algorithm . The advantage w ith the EQL tool is th a t it runs in polynom ial tim e for all programs. 2 .3 .3 S M V SMV is the CTL symbolic model checker developed by Ken McMillan a t Carnegie Mellon University. It accepts an input language th a t is m odular, supports m ulti ple processes, and can be used to implement both synchronous and asynchronous system s. An SMV module is similar to a Sal program . A m odule consists of sec tions for variable declarations and variable updates. Variables can be given initial values for use by the model checker. The SMV language differs from Sal in two im portant respects: 1. the treatm ent of conditional behavior, and 2. the modeling of asynchronous systems. In SMV, each variable is assigned at m ost once in a single process. The as signm ent takes the form of a case statem ent which lists pairs of conditions and expressions. SMV scans the pairs and selects the first th a t has a tru e condition and evaluates the associated expression to get the variable’s value for the next tim e 'step. This is similar to the behavior of the Subsum ption A rchitecture, where the 47 first enabled rule is fired. This results in a m ore complex transition relation since the expressions m ust be prioritized. Hardware im plem entations generally required m ore gates, and are slower, for the same reason. The advantage is th a t SMV doesn’t need to deal w ith race conditions. SMV aJlows a special kind of module called a process. All processes in an SMV system are interleaved arbitrarily. This behavior can be em ulated in Sal using the idea from Section 2.1.4 by setting up an input register th a t random ly selects the next process: r e g i s t e r . . . ; in p u t c u r_ p ro c ; r u l e / / P ro c e ss 0 r u le s (c u r_ p ro c == 0) & & f i r s t r u l e f o r p ro c e ss 0 (c u r_ p ro c == 0) & & second r u l e f o r p ro c e s s 0 / / P ro c e ss 1 r u le s (c u r .p r o c - - 1) & & f i r s t r u le f o r p ro c e ss 1 This can be extended to any num ber of processes by lengthening c u r_ p ro c . 48 C h a p te r 3 C o m p u tin g w ith M o d e ls This chapter is concerned with the d ata structure and algorithm s used to im plem ent the boolean form ula representation of models. The im plem entation m ust provide: • a d a ta structure for boolean formulas; • algorithm s for com puting the values of the boolean connectives; and • algorithm s for com puting the successors and predecessors of a set of states. iThe efficiency of the d a ta structure and algorithm s is critical to the perform ance of 'symbolic verification. T he first section discusses the d a ta structure used to represent boolean formulas: Ordered Binary Decision Diagrams[Bry86]. In Section 3.2, the Step algorithm is in troduced for com puting the predecessors of a set of states. The real-tim e symbolic ► model checking rules are implem ented entirely in term s of the predecessor algorithm (and the boolean connectives). Therefore, the algorithm ’s perform ance is crucial. The Step algorithm is far m ore efficient th a t other predecessor algorithm s and is a contribution of this thesis. Finally, in Section 3.3, the perform ance of Step is com- ipared w ith other algorithm s, including the SMV predecessor algorithm AndExists. iThis final section also discusses com puting the successors of a set of states. 3.1 O rd ered B in a r y D e c isio n D ia g ra m s M any representations (d ata structures) have been proposed for boolean formulas. The m ost fam iliar one is a tru th table. Given the tru th tables for two formulas f\ 49 and f'ii we can com pute f\ + f 2 by scanning each table and filling in a new table w ith the result of f\ + fa for each tru th value assignment. This process is simple and it takes tim e proportional to the size of the two tru th tables. U nfortunately, the tru th table representation itself increases exponentially in size as the num ber of variables increases. M any other representations for boolean form ulas, such a canonical sum of products, also have sizes th at are exponential in the num ber of variables. In 1986 B ryant introduced a new representation for boolean formulas called an O rdered B inary Decision Diagram (OBDD)[Bry86, Bry92]. The OBDD represen tatio n is based on decision trees w ith certain restrictions th a t make it a canonical ?form: every form ula th a t represents the same boolean function has the same OBDD representation. OBDDs are very compact for a variety of useful functions. How ever, there are some functions th a t cause the OBDD representation to “blow-up” exponentially (as it m ust if V ^ M V). In this section, we will discuss OBDDs in detail. The rem ainder of this section is divided into three parts. The first describes the OBDD representation and the restrictions th a t make it a canonical form . N ext, the fundam ental OBDD algorithm , I T E (f,g ,h ) , is described. This algorithm is used to com pute the values of all operations involving boolean connectives and OBDDs. A correctness proof for I T E is given and its running tim e is shown to be linear in the product of its argum ents. The final section contains some complexity bounds on the size of the representation. 3 .1 .1 D a t a S tr u c tu r e A binary decision diagram (BDD) is a binary tree where each nonterm inal node represents a choice for the value of a variable and a term inal node is either the constant 0 or 1. For a given tru th value assignment to the variables, the value of the form ula th a t the BDD represents is found by traversing the BDD from its root to a term inal node, taking the right branch at a nonterm inal if its variable is true and the left branch if the variable is false. The term inal node gives the value of the form ula. For a nonterm inal b, let Vb be its associate variable, tb be the branch to take if Vb is true, and e & be the branch taken for false. The nonterm inal b is then the triple 50 0 0 0 10 1 1 1 Figure 3.1: BDD representation of the 3-input m ajority function. f 0 1 Figure 3.2: Reduced OBDD representation of the 3-input m ajority function. (vftjtb, e&). A BDD for the three input m ajority function f(a, b,c) — a - b + a • c + b • c is given in Figure 3.1. A n ordered BDD (OBDD) places a strict ordering < e V 2 over the variables and any variable at level I in the tree is less than any variable at level V > I. The size of an OBDD for a given form ula depends on the variable ordering which is discussed 'further in Section 3.1.3. It is im portant to note th a t all formulas use the same ordering and m ost OBDD m anipulation algorithm s depend on this fact. 51 A reduced OBDD is an OBDD constrained by the following rules:1 1. Remove duplicate terminals: Select one instance of each kind of term inal (0 or 1) and redirect all arcs to the appropriate instance. Elim inate all other term inal instances. 2. Remove duplicate nonterminals: If nonterm inals b and b' are such th a t V f, = Vfj^tb = fj,/, and eb = ey then eliminate b' and redirect all arcs to b. 3. Remove redundant tests: If nonterm inal b is such th a t tt, = e& , then elim inate b and redirect all arcs to %. These rules are applied repeatedly from the bottom up to obtain the reduced form of the diagram which, in general, is a directed acyclic graph. The OBDD for the m ajority function appears in Figure 3.2 (multiple term inals are shown for clarity). B ryant showed th a t the OBDD representation is a canonical form ([Bry86] Theorem !)■ It is common practice to store all OBDDs in a single directed acyclic graph w ith entry arcs for each top-level OBDD. A subexpression th a t is common to m ore th an one OBDD is shared and only represented once. If two formulas are equivalent, they will have the sam e entry arc into the DAG. This means th a t testing for equivalence (graph isom orphism ) is a constant tim e pointer comparison. Similarly, we can test if a form ula / is satisfiable or tautological by evaluating / = 0 or / = 1, respectively. These evaluations are also ju st pointer comparisons. The RTCTL m odel checking and reachable states algorithm s implement certain fixed point calculations using iteration. This OBDD sharing scheme makes detecting fixed points cheap: the pointer to the result of the current iteration is simply com pared against the pointer to the previous iteratio n ’s result. Of course, we pay the price for this feature when [inserting new nodes into the graph. j 'T h e obvious acronym is R O B D D which is used by som e authors. However, we will follow IBryant’s convention that O B D D m eans a reduced O B D D . 52 3 .1 .2 F u n d a m e n ta l O p e r a tio n : I f-T h e n -E ls e T h e fundam ental operation of the RTSMC OBDD package is I T E ( f,g , /i)[BRB90, iKar88] which builds the OBDD th a t represents i f / th e n g e ls e h, given the OBDDs for / , g and h. This operation in term s of the two place connectives is I T E ( f ,g ,h ) = f - g + ^ f - h . (3.1) All tw o place operations and negation can be implemented in term s of I T E and th e constant symbols (OBDD term inals). For example, ->/ = I T E ( f , 0 ,1 ), / • g = I T E ( f , g , 0), and / + g = I T E ( f , l,£r). The optimized pre-image algorithm in Section 3.2 uses I T E directly. The cofactor of / w ith respect to v , w ritten v ( f ) is the form ula obtained by 'replacing v by 1 in / . Similarly, let v(f) be the form ula obtained by replacing 0 for v. Assume th a t v < v' for all v' in the representation of / . W ith this assum ption v (f) = < t f V = V f f < t)/ or / = 0 or / = 1 (3-2) undefined v > Vf and for v(f) replace tf with ey. Note th a t Equation 3.2 is undefined if v > Vf. T he I T E algorithm works in a top-down fashion to insure th a t this constraint is satisfied. The cofactor operations distribute over • and + . A recursive form ulation of I T £'[BRB90] follows from Shannon’s decom position theorem: f = v • v(f) + -iv ■ v(f). (3 .3) Using Shannon’s theorem and Equation 3.1 with v = m in (vf,vg,vh) and r = I T E ( f , g , h ) yields r = I T E ( f , g , h ) = v • v(r ) + -iv • v(r) = V • v ( f • g + - . / • h) + -IV ■ v ( f ■ g + - ./ • h) = v - ( v ( f) - v ( g ) + v(-if)-v(h)) + ^ v ( v ( f ) - v ( g ) + v ( ^ f) - v ( h ) ) (3.4) 53 = IT E (v , IT E (v (f), v(g), v(h)), IT E (v(f), v(g), v(h))) = (v, IT E (v (f) , v(g), v(h)), IT E (v (f), v(g), v(h) ) ) . jThe final step substitutes an I T E expression having the if p art v w ith the equivalent .OBDD nonterm inal since a nonterm inal b represents i f vi th e n e ls e /*,. Two ^obvious term inal cases of the recursion are IT E (0 ,g , h ) = h and I T E ( l , g , h) = g. A ithird case is I T E ( f , 1 ,0 ) = f. All other argum ent p atterns correspond to negation, one of the two-place connectives, or an I T E where none of the argum ents is a term inal. A naive I T E algorithm can be constructed directly from this recursive form u lation and the term inal cases. However, such an algorithm has three weaknesses: 1. it doesn’t return a reduced OBDD, 2. the DAG is not supported for sharing common subexpressions, and 3. its time complexity is often exponential. The I T E algorithm in Figure 3.3 addresses these weaknesses. I T E uses a cache to rem em ber the results of previous calls to IT E . The index to the cache are the algorithm ’s argum ents represented as the triple (f , g , h ) . For the general case, the value of I T E is (v,t,e). Prior to returning, the algorithm attem pts to find (v,t,e) in the DAG since calls to I T E w ith different argum ents can lead to the same result. If the triple is found, the findJnsert^D A G call returns a pointer r to the existing triple in the DAG. If it ’s not found, the newly com puted triple is inserted into the DAG and its address returned in r. This step (6) insures th a t the OBDD corresponding to every form ula is stored at m ost once and th a t there are no duplicate term inals in th e OBDD. The im pact of the cache and the DAG on the algorithm ’s perform ance is discussed below. A correctness proof for I T E has not appeared in the literature so we’ ll do it here. Assum e for a m om ent th a t I T E is correct, then only correct results are placed in the cache at step 7 and returned from the cache at step 2. Therefore, we do not need to consider the cache in the proof. T h e o re m 3.1 If f ,g and h are reduced OBDDs then (a) I T E ( f,g ,h ) = / ■g + ~'f -h and (b) I T E ( f,g , h) is a reduced OBBD. P r o o f. By structural induction on / , g, and h. I 54 I T E ( f,g , h) : 1. if / = 1 retu rn g e lse if / = 0 retu rn h e lse if g = 1 and h = 0 retu rn / 2. e lse if (f,g,h) 6 cache retu rn cache{{f,g,h)) e lse b eg in 3. v = min(vf,Vg,Vh) 4. t = IT E (v(f),v(g ),v(h )) e = IT E (v(f),v(g),v(h)) 5. if t = e retu rn t 6. r = find-insert JDAG{(v,t,e)) 7. cache({f,g,h)) = r retu rn r en d Figure 3.3: Algorithm IT E . Base cases: / = 1, / = 0, or (g = 1 and h = 0). (a) I T E ( l , g , h ) = g = 1 • g + 0 h = f • g + ->f • h. The other two bases cases can be treated in a similar fashion. (b) Im m ediate since in each case one of the argum ents is returned and, by assum p tion, each argum ent is a reduced OBDD. General case: f is a nonterminal. The inductive hypothesis is: if v ( f ), v(f), v(g),... are reduced OBDDs then t and e are the reduced OBDDs th a t represent v(f)-v(g) + -iv(f) • v(h) and v ( f ) • + _|u ( /) • v(h), respectively. (a) We want to show th a t the result of I T E ( f , g , h ) = / • g -f -if • h whenever the algorithm returns. The algorithm I T E proceeds from step 3. A t step 3, the smallest of the variables Vf,vg and Vh is chosen. Such a variable exists since at least / is nonterm inal and the ordering is strict. A fter step 4, t = v ( f ) • v(g) + -iv(f)v(h) and e = v(f) • v(g) + • v(h), which follows from the induction hypothesis and the fact th a t v is the sm allest of Vf,vg and Vh from step 3. By the recursive form ulation in Equation 3.4: I T E ( f, g, h) = (v, t, e) = / • g + - . / • h. (3.5) 55 If I T E simply returned {v , t , e) at this point, the proof of p art (i) would be complete. However, two final steps rem ain related to the reduction to canonical form. O ur goal is to show th a t the rem aining steps, 5 and 6 , do not corrupt the result. A t step 5. If t = e then t and e represent the same form ula since they are reduced OBDDs by the induction hypothesis. For t = e, the algorithm returns w ith t which can justified by setting g = h in the recursive form ulation. A fter step 6 . The result of I T E is r which is (v, t, e) or an isomorphic triple, by the operation of find-insert-DAG({v,t,e}). Finally, we m ust dem onstrate th at I T E makes progress on each call to itself for which it is sufficient to show th a t |/ | + |< 7| + |h| > |u ( /) | + |v(<7)| + !«(h)|, and similarly for the cofactors in v. A t step 3, the smallest variable v is chosen and is such th a t at least one of v = Vf, v = vg, or v = Vh is true. W ithout loss of generality, assume v = Vf. Then v ( f ) = tf by Equation 3.2 and \tf\ = |/ | — 1, hence the inequality holds. (b) We m ust show th a t (i) the ordering is m aintained and (ii) there are no duplicate term inals, redundant tests, or duplicate nonterm inals. (i) If I T E returns t at step 5 then the ordering is m aintained since t is reduced. For the result (v,t,e), it’s sufficient to show th a t v < vt and v < ve. By the operation of I T E there can be no variables in t th a t were not in n ( /) , v(g), or v(h). From step 3, v < Vf,v < vg and v < v^. Therefore, since / , h and h are reduced, v < vv(f),v < and v < vv^hy Hence v is smaller th an any variable in the cofactors and, consequently, smaller th an any variable in t or e. (ii) There can be no duplicate term inals since I T E doesn’t create te rm inals and f , g , and h are reduced. For redundant tests, note th a t at step 5, if t = e then t is returned and t is reduced by the induction hypothesis. If t 7^ e then the test for v is, by definition, not redundant. Finally, if the nonterm inal (w,t,e) is a duplicate, the original nonterm inal th a t is isomorphic to (v,t,e) is found in step 6 by fin d .insert-D AG and returned by IT E . □ Note th a t the I T E ( f , 1 ,0 ) = / base case is not required for correctness. It simply improves the algorithm ’s performance. The tim e complexity of I T E depends on the complexity of the cache and DAG operations. A common assum ption[BRB90] is th a t these operations require constant 56 Function class Best case W orst case Sym m etric Integer addition (any bit) Integer m ultiplication (middle bits) linear linear exponential linear exponential exponential Table 3.1: Complexity of some common function classes. tim e. This is justified if the cache and the DAG are implem ented using large hash tables relative to the num ber of entires since the num ber of collisions in such tables tend to be very small. Given this assum ption, the only non-constant operations in I T E are the calls to itself. Theorem 3.1 shows th a t I T E calls itself at m ost once for each nonterm inal in its argum ents. The cache is critical here since there can be more th an one p ath to a given nonterm inal. W ithout the cache, redundant calls to I T E would m ake the overall tim e complexity exponential. The use of the cache is a form of dynam ic program m ing. The complexity of I T E is then 0 ( |/ ||^ j |/ i |) where |x| is the num ber of term inals and nonterm inals in x. The use of I T E to im plem ent the two-place connectives does not increase the tim e complexity over dedicated algorithm s, such as B ry an t’s Apply, since the constant symbols (term inals) have size 1. 3 .1 .3 C o m p le x it y L im its a n d t h e V a r ia b le O r d e r in g P r o b le m The size of an OBDD for a given formula is sensitive to the variable ordering. For exam ple, B ryant showed in his survey[Bry92] th at the simple form ula f = Y l a i ' hi i requires a linear num ber of non-term inals for the ordering ao < bo < a\ < b\ < . . . but an exponential num ber of non-term inals for the ordering eto < ° i < ■ ••< bo < bi < .... Indeed, it has recently been shown th a t almost all form ulas require (3.6) 57 storage where e is an arbitrarily small positive num ber and N is the num ber of variables[LL92]. This result is independent of the variable ordering. However, m ost boolean form ulas are not interesting and our concern is how well the OBDD represen tatio n perform s for the formulas th a t arise in modeling practical real-tim e system s. B ryant has shown[Bry92] th a t many useful classes of formulas have com pact representations w ith a proper variable ordering (see Table 3.1). For exam ple, all sym m etric formulas have a quadratic worst case complexity and addition can be m odeled in linear size w ith the proper variable ordering. Further results by McMil- ilian suggest th a t there is a wide class of useful formulas for which the OBDD rep resen tatio n is efficient[McM92]. Several researchers have conjectured th a t the variable ordering problem for the OBDD representation is ATP-hardlBrySd, CMB91]. This seems plausible but I ’m unw are of a published proof. The variable ordering in RTSMC is constrained by the fact th a t the variables th a t represent unconstrained state variables m ust come first. F urther, empirical, proof of the utility of the OBDD representation is given later in this chapter and in C hapter 5. 3 .2 C o m p u tin g th e P r e d e c e sso r s o f a S e t o f S ta te s The purpose of this section is to develop an efficient algorithm for com puting the predecessors of a set of states for synchronous real-tim e controllers having uncon strained state variables. Given the state transition relation of a system , N, the pre-im age of a set of states S is given by N - ' S = 3(v' € V')S'- N (3.8) where S' denotes 5 w ith all variables v 6 V replaced by v'. C ontrast this w ith the equation in Definition 2.7 which gives the successors to a set of states. All of the symbolic model checking rules for RTCTL are expressed in term s of the boolean connectives, im plem ented with IT E , and N~*S. 58 In principle, the existential quantifications in Equation 3.8 can be evaluated using the smoothing operation [Bry92] 3 ( < 0 / = / U o + / U i . (3.9) This leads to a simple but naive im plem entation of N -1S: Simple(S) : !l. R = Sf-N 2. fo r a ll a s c e n d in g v' € V7: R = v'(R) + v'(R ) •3. r e t u r n R where v'(R ) is the cofactor of R w ith respect to v' and similarly for v'(R). A prim ed variable is distinct from its unprim ed version and m ust have its own place in the OBDD variable ordering. Simple requires the ordering v'0 < v[ < . . . < vq < V\ < . . . so th a t the cofactors are well defined. Unfortunately, Simple is inefficient since S' • N and the interm ediate com putations can become very large. To construct an efficient algorithm , we will exploit the structure of the state transition relation for our controllers and the OBDD representation. T he rem ainder of this section consists of three parts. The first discusses SyncStep, an algorithm for com puting the pre-image when there are no unconstrained state ivariables. N ext, SyncStep is extended to tre a t unconstrained state variables. This new algorithm , Step, is very efficient and is one of the contributions of this thesis. Finally, this section ends w ith a comparison of the perform ance of Simple, Step, and the SMV relational product algorithm AndExists for three test cases. The final p art also includes a discussion on com puting the successors of a set of states. 3 .2 .1 SyncStep : C o m p u tin g N~*S fo r D e t e r m in is t ic S y s t e m s Here we present a simple algorithm for efficiently evaluating N ~ l S for system s th a t have no unconstrained state variables (U = 0). For such system s, N is given in Equation 2.7 which is a conjunction of individual variable transition formulas th a t 59 retu rn the value of a single variable (V) for the next state given the current state variables. Substituting Equation 2.7 into Equation 3.8 yields N ~ 'S = 3 (i/ £ V')S' ■ n » '« • /« ■ (3.10) The actual form of the f v is not im portant except to note th a t they only depend on variables in V. In the following m ethod the f v are used as needed and S' ■ N is never explicitly com puted which was the downfall of Simple. There is a single existential quantification for each variable in V '. Factoring out th e quantification for v'Q gives Sequential(S) : 1. R = S' 2. fo r a ll a sc e n d in g v' € V : R — v \ R ) • ->/„ + v’(R ) • f v 3. r e t u r n R We can do b etter th an Sequential by observing th a t Equation 3.10 represents a sequential substitution of formulas for variables. In general, consider substituting a Note th a t only one term in the transition relation N depends on v'0 so all b ut the v'0 term can be pulled out from under the v'0 quantification: 3(v’ e v ’ - K » n -3K)<s"-K^/vo)- _vev— {u0} Now use sm oothing: {ii0} T hus, the factors in N can be treated one at a tim e which suggests the following iterative algorithm for com puting N~*S which exploits the OBDD variable ordering: 60 form ula / for a variable v' in a formula g(vf), which is denoted g(v') (vf < — / ) , where v' is not free in / . This is expressed as g(v)(v ' «- / ) = g(0) - + g(l) • f (3.11) = 3(v')g(v') ■ (vf & f ) or, in the m ultivariable case: g(V) (v’ 0 «- / 0) . . . « _ i <- fn — 1 > = 3 « _ i ) • ■ • Oo ^ /o) • • - « - i ^ / n - l ) (3.12) which is precisely the form of Equation 3.10. I t’s clear th a t Sequential simply substitutes /„ for v' in S' sequentially (iteratively). Intuitively, the reason for the prim ed variables is to keep the f v from “mixing” w ith the variables th a t have not yet been substituted. If all variables could be simultaneously substituted, then there would be no need for prim ed variables. Simultaneous substitution of a set of formulas f v for all v in 5 is denoted S (v0 <- . .,v » _ i <- /«„_!> • (3.13) T he following algorithm , SyncStep , performs this substitution: SyncStep(x) : 1. if x = 0 o r x = 1 r e t u r n x 2. if x £ cache cache(x) = I T E ( f Vx, SyncStep(tx), SyncStep(ex)) 3. r e t u r n cache(x) Consider an OBDD node x with variable vx, true branch tx, and false branch ex. This node represents i f vx then tx els e ex . The idea behind SyncStep is to work from the leaf nodes up to the root (5 ), replacing every variable vx w ith f Vx, using IT E . SyncStep was developed independently, but it is similar to a restricted version of A ndE xists called bottom-up th a t also performs sim ultaneous substitution. There are two differences. The first is th a t SyncStep uses I T E ( f,g ,h ) instead of the 61 equivalent form ulation in term s of the two place connectives, f • g + ~>f ■ h, th a t is used by bottom-up. Using I T E eliminates the need for the com plem ent of each variable transition form ula, -'fv, which makes SyncStep more efficient. T he second, and m ore im portant difference, is the im plem entation of the cache. SyncStep caches [everything it com putes. W ith norm al caches, it is sometimes necessary to replace entries due to collisions during insertion. This is unnecessary w ith the SyncStep cache because it reserves a field in every OBDD node to rem em ber the value of ]SyncStep when called w ith th a t node. The overhead is small and it results in a cache th a t never needs to do replacement. The following proof shows th a t SyncStep is correct, which is required by our (philosophy th a t all key algorithm s in a verification tool m ust be verified. Note th a t the cache does not effect the correctness of the algorithm . For an OBDD x, let {a;} be the set of variables th a t appear in x. Given a set of variables V, let Fy be the set of variable transition functions for the variables in V, namely { fVo,..., f Vn_1}. Then, the sim ultaneous substitution of Equation 3.13 can be w ritten S ^{5} F { S } ) • T h e o re m 3 .2 If S is an OBDD in the variables V then SyncStep(S) is the OBDD that represents N ~ XS. Proof. It suffices to show th a t (i) SyncStep(S) is an OBDD and (ii) SyncStep(S) = 5 < M - Fls}) . P a rt (i) is im m ediate: 5 is an OBDD and SyncStep(S) either returns S or the result of an I T E operation which, by Theorem 3.1, is also an OBDD since its argum ents are OBDDs. For p a rt (ii), the proof is by structural induction on S. Base cases. If S = c where c is a constant, then, by step 1, SyncStep(S) — c which is correct since there are no free variables in c. G eneral case. The induction hypothesis is SyncStep(tx) = tx • * — ^{<*}) and similarly for ex. Note th a t the set of variables th a t x depends on is {x} = {T x} U { tx } U {fia:} • In the general case, the result of SyncStep(x) is com puted in step 2: SyncStep(x) = I T E ( f Vx, SyncStep(tx), SyncStep(ex)) 62 — I T E ( f Vx, tx ^{tr} < 5ea;^{ex} -^{ex}^) by the induction hypothesis = I T E ( f Vx,Vx(x) (^{tx } > ^c(*) ^{ex} F{ex})) by definition of the cofactors and the fact th a t x depends on vx = I T E ( f Vx, x (vx «- 1, {tx} «- ,*(»*«- 0, {ex} «- F{exy^) by definition of the cofactors and simultaneous substitution = fvx ' x (\Vx 0* } Fytx T ~'fvs ' x vx * 0, {fix} * — FyCxy^ by definition of I T E — X (vx « fvxi ilx} L I {ea:} F{tx} U by E quation 3.11 = x * F{xy^ which is the desired result. □ 3 .2 .2 Step : C om p u tin g N ~ l S w ith U n con strain ed S ta te V ariables So far we have developed an efficient algorithm for evaluating the pre-im age for determ inistic system s. Here we will extended th a t algorithm to system s w ith un constrained state variables. The main idea is th a t the com putation of N -1 S can be separated into parts for each kind of state variable. The unconstrained variables are treated using sm oothing and SyncStep is used on the regular variables. The algorithm based on this idea is called Step and it perform s b etter th an all other algorithm s on the cases tested (see Section 3.3). The Step algorithm is the m ain contribution of this section. Let U C V be the set of underconstrained state variables. The predecessors are given by iV-1 5 = 3 (y ')S ' • N. By its construction, N does not depend on U' (Equation 2.7), therefore the existen tial quantifiers for 17' only apply to S' : N ~ l S = 3(V' - U') [1V(F' - U') • 3(t7/)5"] (3.14) 63 Step(x) : 1. if a; € cache r e t u r n cache(x) 2. y = x 3. fo r a ll a s c e n d in g v € U: y = v(y ) + v(y) 4. cache(x) = SyncStep(y) 5. r e t u r n cache(x) Figure 3.4: Algorithm Step. where N (V ' — U') indicates the fact th a t N doesn’t depend on U'. Let T ( V ’ - U') = 3(U')S' and su b stitu te into Equation 3.14, giving N - ' S = 3(V ; - U’)N (V ' - U') • T (V ' - U’). T he variables V' — U' are all regular state variables (not unconstrained) and, given the value of T (V ' — U'), N ~*S can be com puted using SyncStep which is efficient. To com pute T(V ' — Ur) it is sufficient to use sm oothing in a top down fashion which exploits the OBDD ordering. This leads to algorithm Step (Figure 3.4) which is the key algorithm in RTSMC. Its correctness follows im m ediately from the preceding derivation and Theorem 3.2. 3 .3 C o m p a r a tiv e P er fo rm a n ce The purpose of this section is to dem onstrate the efficiency of Step as com pared to the other predecessor algorithm s. To do this, we compare the run tim e and m em ory requirem ents of each algorithm for verifying the full specification of: 1. T he traffic light controller for a 15 second highway light tim e and a 15 second sideroad light tim e (TLC15). 64 A ndExists(p , q) : 1. if p = 0 or q = 0 return 0 2. else if p = 1 and q = 1 return 1 3. else if (p, q) € cache return cache((p,q}) else begin ( 4. v = min(vp,vq) 5. t = AndExists(v(p), v(q)) 6. e = AndExists(v(p),v(q)) j7. if v € V ', result = t + e 8. else if < = e, result = t J 7 9. else result = (v,t,e) 10. cache((p,q)) = result 11. return result end Figure 3.5: SMV predecessor algorithm : AndExists. 2. TLC for a 4 m inutes highway light tim e (TLC240).2 3. A reduced version (8 rules) of the space shuttle diagnostic system (CRYO) The results are given below after a discussion of SMV’s pre-image algorithm . 3 .3 .1 A n d E x is ts : T h e S M V P r e d e c e s s o r A lg o r ith m The SMV predecessor algorithm , A ndE xists , is shown in Figure 3.5 using the notation of this thesis. The algorithm computes 3{V € V)p * q where p and q are arb itrary form ulas in V and V ' . The value of N~XS is given by AndExists(S, N). jThe algorithm is general and works for any state transition relation. Its m ajor advantage over Simple is th a t it doesn’t construct the OBDD for S' • N , which can ibe quite large. The base cases are straightforw ard. The code th a t handles the general case is m uch like I T E except for the case when the smallest variable v is prim ed. In this case AndE xists returns 3(u)p • q which is just t + e. j 2T h is m odels th e Santa Barbara traffic lights on Highway 101 prior to th e im provem ents in early 9 0 ’s. 65 Algorithm TLC15 TLC240 CRYO Simple 1.5 34.5 12.3 AndExists 1.26 27.9 9.77 Step 0.3 3.15 0.03 Table 3.2: Com parative perform ance of various predecessor algorithm s. Algorithm TLC15 TLC240 CRYO Simple 19952 279380 163259 AndExists 17102 235901 44025 Step 1466 11718 122 Table 3.3: Com parative memory requirem ents of various predecessor algorithm s. Like Step, AndExists uses a cache to rem em ber previously com puted results. T h e AndE xists cache is implem ented using a hash table which m eans th a t cache entries may be replaced. The Step cache is encoded right in the OBDD represen tatio n , and once Step is called with a set of states, it remembers the result for the duration of the run. Besides the ability to work w ith arbitrary transition relations, AndE xists can be modified to com pute the successors of a set of states simply by changing the test a t step 7 to v G V. Some of the tim ing d a ta in later chapters is plotted against the num ber of reachable states. The set of reachable states is com puted in RTSMC using AndE xists since there doesn’t appear to be a way to modify Step to do the com putation. 3 .3 .2 R esu lts Table 3.2 shows the num ber of seconds required by the various predecessor algo rithm s to verify the full specifications of the three problems listed at the beginning of this section. Table 3.3 gives the num ber of OBDD nodes created by the algorithm s (during the verifications which gives an indication of the m em ory requirem ents. Note [that Sequential and SyncStep where not benchm arked since they don’t support un constrained state variables. The results show th a t Step is superior in both run-tim e and m em ory require m ents to both Simple and AndExists. The speedup ranges from 5 to over 300. The i 66 prim ary reason for Step's perform ance relative to the other algorithm s is th a t Step cloes not use the entire state transition relation. Instead, it keeps the individual jvariable transition functions separate (Section 2.1.3). This is w hat is m eant by a ifully partitioned transition relation. In contrast, both Simple and A ndE xists re quire the entire, monolithic, transition relation which can be quite large. It should be noted th a t the size of the monolithic transition relation is sensitive to the or dering of the primed variables as well as the regular variables. The OBDD doesn’t m ake a distinction between the two forms of variables. These comparisons used the ordering Vq < v[ < . . . < vq < Vx < .... A nother ordering th a t has been reported in .the literature is v'0 < vq < v[ < v\ < . . . which may result in b etter perform ance for 'Simple and AndExists. However, both algorithm s will always be at a significant Jdisadvantage since they m ust deal with twice as m any variables. Also, note the claim th a t AndE xists uses less memory than Simple is clearly apparent for the CRYO test case. 67 C h a p te r 4 R e a l-T im e S y m b o lic M o d e l C h eck in g Search along separate paths, for that is how truth comes to light. — Friedrich Von Schiller The results of the last two chapters come together here to form a m ethod for verifying th a t a real-tim e controller meets its specification. This chapter begins w ith some discussion on logics for verifying real-tim e systems and some notions about logics, such as deduction, satisfiability, and model checking. In Section 4.2, Real-Tim e C om putational Tree Logic is introduced with a form al definition of its syntax and semantics. It is shown th a t for finite models, the RTCTL quantifiers can be elim inated which forms the basis for real-tim e symbolic model checking. In the final section (4.3), the RTCTL symbolic model checking rules are developed. T he developm ent is based on the idea of com puting the m axim um num ber of states th a t satisfy a given formula. The section and chapter end w ith some examples and a discussion of related work. 4 .1 L o g ics for S p e c ify in g R e a l-T im e C o n tr o lle r s Logics are based on the formulas (strings) in a language. Formulas are w ritten ip, < f> , or (p to m ake them distinct from boolean logic formulas and sets of form ulas are w ritten I \ 68 There are two fundam ental notions in logic, derivation (or deduction) (b ) and satisfaction ((=). Derivation is concerned with the syntactic m anipulation of form u las. We can w rite r b ip if and only if the repeated application of inference rules to jthe formulas in T and already deduced formulas, yields ip. A well known inference rule is m odus ponens: if ip and ip — » < p hold, then < p m ust hold. Satisfaction is concerned with the validity or tru th of a form ula in a given model .and state (or sequence of states). We w rite s \=m V ’ to m ean th a t ip is true in the model M w ith the state (or sequence) s. If a form ula is tru e in a model and state, then the model satisfies the formula with the state. In the context of verifying reactive system s, the model is a m athem atical description of the system or program . jThese two notions, derivation and satisfaction, are connected by soundness and completeness theorem s. T he verification of reactive systems using tem poral logic has its roots in a de ductive approach. An assertion about a program is checked by deriving it from some axioms using inference rules th at are appropriate to the logic. T he axioms are statem ents about a particular program ’s execution, such as if the program is at the statem ent labeled /, it will eventually reach the statem ent labeled / + 1. These ax ioms are satisfied by the model of the program , and hence, anything derivable from jthem (by soundness), is also satisfied by the program . U nfortunately, the problem of deriving a theorem from a set of axioms has extrem ely high complexity (at best) and is often undecidable. An alternative approach is model checking which is generally only applicable to finite models. The basic problem is: given a model M , state s, and form ula j« /> , does M satisfy ip with s ? The simplest form of model checking is for boolean logic: given a form ula and a state (tru th value assignm ent), a simple evaluation of J,he form ula determ ines if it is satisfied by the state. The evaluation requires tim e linear in the size of the formula. The situation is more complex for m ore expressive logics. The downside of model checking is th a t the size of the model generally increases exponentially in the num ber of state variables. The deductive approach is not lim ited in this way since the tim e required to derive program proofs tends to depend m ostly on the size of the program , not the am ount of m em ory the program 69 accesses. Symbolic model checking attem pts to alleviate this by not enum erating all of the states in the model. A related question is the satisfiability problem. Given a form ula 0 can we find a m odel M and state s th a t satisfies 0? Satisfiability is closely related to the program synthesis problem . If 0 is the specification of a program and our models can be interpreted as program s, then the synthesis problem reduces to the satisfiability problem . The satisfiability problem for boolean logic is decidable. In fact, the algorithm , 3CNFSAT, is the quintessential ./VP-complete problem . It is sufficient to guess a tru th value assignment and see if 0 holds. This algorithm s runs in 0 ( 2 N) tim e where N is the num ber of variables appearing in the form ula. Some logics are undecidable, m eaning there is no algorithm for solving the satisfiability problem. This section has presented some of the general notions about logics. Next we jwill consider two particular forms of tem poral logic, linear tim e and branching tim e, in this context. jL inear tim e te m p o r a l logics. Tem poral logic is a m odal logic th a t gives a tim e interpretation to the necessity (□ ) and possibility (O ) quantifiers. In tem poral logic, O P means th a t P is true henceforth (now and in the future), and O P means jthat P is tru e now or a t some tim e in the future. Using these two quantifiers we can express useful properties about reactive systems. For example, let in Ci mean jthat task i is in its critical region. Given two tasks, □ (in C\ — * ->m Cfi) expresses jthe safety property th a t task 1 and task 2 are never in their critical regions at the sam e tim e. Similarly, □ ( in C\ — » O after C \ ) is a liveness property th a t says if task jl is ever in its critical region, there will be a tim e in the future th a t i t ’s out of its region. The above form ula is more commonly expressed in after C\ where P^*Q = n ( P — ► O Q). The operator is called “leads-to.” A program is expressed as a set of axioms. For example, if label I corresponds to a statem ent th a t term inates, such as an assignment, then the axiom at P a after I 70 'holds. In addition, there are inference rules th a t are specialized for the logic. One [expresses the transitivity of the leads-to operator: P ^ Q ,Q ^ R P ^ R i.e. if it can be shown th a t P ^ Q and Q ^ R , then P ^ R can be deduced. Properties !of the system can then be derived from the axioms and inference rules. This logic is an example of a linear tim e tem poral logic (the quantifiers □ and jO are generally reserved for linear tim e logics except in [Lam80]). A model of a linear tim e logic contains all possible state sequences of its corresponding program startin g from the initial states. Each sequence represents a possible behavior of the program . A form ula is satisfied with respect to a particular sequence in the model, jwhich is w ritten a \=m ip- Implicit in the semantics of linear tim e tem poral logics is a universal quantification over all execution sequences: a form ula is true if and only if it holds for all sequences. This works well for verifying pre-existing program s, since it makes sense to pick and reason about an arbitrary path. An alternative sem antics for tem poral logic, called branching tim e, is discussed below. H arter extended the work on reactive program s by placing an upper bound on jthe “leads-to” operator[Har82]: in C\ ^>° after C\ states th a t if task 1 is ever in its critical region, it will leave within 10 tim e units. This m arked the beginning |of real-tim e system verification using tem poral logic, and m any related approaches ■followed[Koy87, HMS88]. In each case however, the proof techniques were based on deduction. jC om p u tation al tr e e logic. C om putational tree logic is defined using a branch ing tim e semantics[CE81b]. The intuitive model is a forest of trees, where each tree is rooted in an initial state and represents all possible system behaviors from th a t state. If the system is determ inistic (no unconstrained state variables), each “tree” is simply a sequence of states. I t’s the addition of non-determ inism from the environm ent th a t causes the branching behavior. The quantifiers in CTL are constructed by pairing a quantifier over p aths, E (exists a p ath ) or A (all paths), with a quantifer over the states on a path: F (it’s 71 possible on the p ath ) or G (it’s necessary on the path ). The possible com binations are: • ~EiYip holds if there exists a p ath leading from the current state on which ip is eventually true; • E G -0 holds if there exists a p ath leading from the current state on which ip is always true; • A F ip holds if for all paths leading from the current state, ip eventually becomes tru e on each path; and • A G ip holds if for all paths leading from the current state, ip is always true. Notice th a t the tru th of a CTL form ula is defined with respect to a state, not a sequence of states. Only two of these quantifiers are fundam ental since YYip = -iA G -iip and A F ^ = -lE G n^i. Linear and branching tim e tem poral logics have different expressive powers(EH 8 6, Lam80]. For exam ple, consider the linear tim e formula O O-ienabled V O executed which is the fairness property stating th a t either enabled becomes forever false, or executed becomes eventually true. This cannot be expressed in CTL (Theorem 2 of [EH86]). Intuitively, there is no way to express in CTL th a t the two disjuncts apply to the same execution (p ath ), which is the goal of a fairness constraint. Conversely, the CTL form ula E F ip cannot be expressed in linear tim e logics since a formula is true, in linear tim e, only if i t ’s tru e on all execution sequences. Both kinds of logic are useful for specifying ■real-time system s. B ut, there will be some system aspects th a t can be specified in one kind of logic but not the other. A solution is to use a stronger logic, such as C TL*[EH 86], which has both linear and branching modalities. However, the model checking problem for stronger logics has a very high tim e complexity. 72 Here we will use the real-tim e varient of CTL called Real-Time C om putational Tree Logic (RTCTL)[EMSS89]. The choice of RTCTL is based on several reasons. F irst, the model checking problem for CTL is com putationally easier th an it is for 'linear tim e logics and this benefit extends to RTCTL. The best CTL model checking algorithm s require tim e th a t is linear in the size of the model and the length of the formula, i.e. 0(\M \\tp\). For linear tim e logics, the tim e complexity is linear in the size of the model and exponential in the length of the form ula, but its expressive ipower is only com parable with branching tim e logics. Second, branching tim e logics ■are ideal for reasoning about the nondeterm inism caused by unconstrained state variables. T hird, the m ajority of symbolic model checking research to date has been done on branching tim e logics and its utility for linear tim e logics has yet to be established. Finally, CTL is expressive enough to distinguish between two ■finite system s in the sense th a t a formula can be w ritten th a t is only tru e in one [particular system . Browne et al. showed th a t if a finite system can be distinguished by some CTL* form ula then it can be distinguished by a CTL form ula[BCG 88]. This means th a t, in principal, CTL is expressive enough to w rite down a system specification th a t satisfies only one of all possible systems. This does not m ean th a t jail interesting assertions can be w ritten in CTL, ju st th a t CTL is strong enough to jfinely discrim inate between systems. Such a result does not appear to be known for 'linear tim e logics. A n a lte r n a tiv e : R T L . An alternative to tem poral logics is Real-Tim e Logic (R TL)[JM 88]. RTL has been used to specify and verify simple real-tim e systems using m anual deduction. RTL is the first order language of arithm etic up to addi tion (P resburger arithm etic) augm ented w ith an occurrence predicate 0 and some associated axioms. The interpretation of 0 (e , i, t) is th a t the ith occurrence of event e happens at tim e t. For example, consider a com putation th a t can take no longer th an 20 seconds to execute. Let j run mean the com putation starts running and i run m ean th a t it stops. The tim e constraint can be expressed in RTL as V(i, x , y) [ 0 ( | run, i, x) A 0 (1 ru n , i, t/)] — * ■ x + 20 < y. 73 RTL is m ore expressive than linear tim e tem poral logics. For exam ple, let a be the 'num ber of tim es an event occurs and choose any two integers b > 0 and n > 0 . k n RTL form ula can be w ritten th a t expresses the fact th a t a and b are congruent m odulo n (a = b mod n). Such a formula is not expressible in linear tim e tem poral 'logics. Furtherm ore, any linear tim e form ula can be expressed in RTL. Branching [time logics can’t express the congruence either. However, RTL can’t express E F P , so RTL and branching tim e are of different expressive powers. RTL is known to be jundecidable which limits its utility for autom atic synthesis. Also, it is not known if there is an efficient model checking procedure. 4 .2 R T C T L S y n ta x a n d S e m a n tic s 'In this section, we give the syntax and semantics of RTCTL. In R TC TL, there are two fundam ental quantifiers which are based on strong until. The CTL quantifiers m entioned in the previous section can be defined in term s of the R TCTL quantifiers as shown below. Let V be a set of variables. The syntax of RTCTL is given by the following rules: 1. Every variable v £ V is a formula. 2. If 4 > and y ? are formulas, then so are -«j) and < j > /\ is a form ula, then so is E X 0 . 4. If < f > and ip are formulas, then so are E[0Uy?] and A[d> Uys]. 5. If 4 > and ] and A[y5>U-ay?], for a > 0. These rules define the language of well-formed RTCTL formulas £ RTCTL. An form ula in RTCTL is interpreted with respect to a model M = {V , U, / , N ) as given in Definition 2.1. A path leading from a state is a sequence of states •so«i«2 • • ■ where E E y and (si,S{+1) € N for i > 0. All paths are infinite since every state has a successor (the transition relation N is to tal). Let 0, ip be R TC TL form ulas. Intuitively, the semantics of the RTCTL quantifiers are: 74 • E X 0 : 4 > holds in a successor of the current state (so). • E [0 U(^]: there exists a p ath leading from the current state on which ~U(p] iff rem ains tru e on a p ath until rem ains tru e until = -iEX-i<£: = ’ Ei{true\J4>\: < f > is eventually true on some path. • AF4> = A [tru e U ^ ]: < j > is eventually true on all paths. • E F - a< £ = E[f rue U - a< £ ]: < f > is true on some p ath within a tim e steps. • A F - a4 > = A [true U - a< £|: < f > is eventually true on all paths within a tim e steps. • E G - a< ^ > = - iA F - a-i0: < j > is continually true on some p ath for a tim e steps. • A G - a< f > = - iE F - a-i(^: < f > is continually true on all paths for a tim e steps. Note th a t the CTL quantifiers defined in Section 4.1 are easily defined in term s of the R TCTL quantifiers and th a t the duals still hold. As an example of a real-tim e verification condition, consider a resource server th a t m ust acknowledge requests within 10 tim e units. A RTCTL form ulation is A G (req — * • A F - 10acfc^ which can be w ritten: at all times, if a request is m ade, then it m ust always be acknowledged within 10 times steps. Satisfiability is defined formally as follows. D efin itio n 4.1 S a tisfa ctio n . For all models M = { V ,U ,I ,N ) , states so € E v, and formulas if): sq \=m ' 4 1 defined inductively on the structure of ip: 75 1 - So |=m v iff •S oC 'u) (recall th a t states are m appings from variables to tru th values). 2 . so (=m ~ « f> iff not so |=m 4> - 1 —M 4 > A iff so |=m 4 > and s 0 \=m - 4- So (=m E[<£Uv?] iff there exists a path SqS\S 2 . . . and a j > 0 such that sj |=m ~ so |= A [0 U v ?] iff for all paths S 0 S 1 S2 . ■ ■ there exists a j > 0 such that sj \=m - 5- So |—m E [ 0 U - “y ?] iff there exists a path soS\S 2 ... and a 0 < j < a such that Sj |=m . so j =m A [<^U -a< ^ ] iff for all paths S0 S 1 S 2 .. ■ there exists a 0 < j < a such that sj \=m ip and for all i < j: s,- \=m < / > ■ I f so (=m Vb we say that M satisfies ip with state so- In general, the size of the models can be infinite. However, for symbolic model checking, we are only concerned with finite models. For these models, the un bounded quantifiers E[</>U<^] and A[4>\Jsp\ can be w ritten in term s of their bounded counterparts since a p ath can be of length no greater than # £ y w ithout repeating a state. L e m m a 4 .1 For all finite models M = (V ,U ,I,N ): i. A[<^>Uyj] iff A\< )> \J-^Vip] and ii. E [< ^ > U < p ] iff E[<pU^#Sv < p ]. P r o o f, i. (<=) Im m ediate since for all a, A[<pU-a(p] — * ■ is a tautology. (= $ ► ) Consider an arbitrary path s o s i^ • • • and let j be the least such th a t Sj |=m ip. By hypothesis, this j exists. Furtherm ore, the states • • - sj m ust be distinct. Assume this is not the case and th a t there is some i, i' < j such th a t Si = sy, i.e. the p ath contains a cycle. Then, another p ath is so<siS2 • • -s* ■ ■ ■ • • • where the cycle repeats forever. On this p ath, no state satisfies # E y . This is a contradiction since states m ust be distinct and jthere are only # E states. Hence, j < # E v on all paths and A.[(f>\5-^v (p\ holds, ii. Similarly for E[^U<^]. □ This m eans th a t if we are given a finite model M and a form ula ip, all term s of the form A[<£U<^] in ip may be replaced by A [^>U -^Sv^] and similarly for term s of the form E[<^U^]. In tu rn , we can w rite the bounded quantifiers solely in term s of E X using the following two simple recurrences: E[<£ U ^ V ] = > ] = A A X A [0 U ^ ° - V ] ) (4.2) recalling th a t AX.ip = ->EX->V’. This leads to the conclusion th a t the m odal quan tifiers, for finite models, are merely syntactic extensions and the sublogic given by item s 1-3 is ju st as expressive as the full logic. However, the quantifiers do have two advantages. F irst, they allow us to w rite much m ore com pact specifications. Second, they speed the checking process since the tim e complexity of the best model checking algorithm s is linear in the size of the model tim es the length of th e form ula. Using E X to sim ulate a quantifier in a formula can increase the form ula’s length by an am ount proportional to the size of the model. This can have a dram atic im pact on verification tim e. Lemma 4.1 and Equations 4.1 and 4.2 will be used in the next section to develop the RTCTL symbolic model checking rules. 4 .3 R T C T L S y m b o lic M o d e l C h eck in g Symbolic model checking schemes work by com puting the largest set of states th a t satisfy a form ula. This is the same as D ijkstra’s notion of a weakest pre- condition[Dij76]. Consider a Hoare triple P {S }Q (see Section 1.2), P is the weakest ipre-condition if P { 6'}Q holds and P is satisifed by an equal or greater num ber of 77 I ------------------------------------------------------------------------------------------------------------------------- states th an any other pre-condition P '. The weakest of all conditions is simply tru e , .which is satisfied by all states. Let ws(ip) be the set of states th a t satisfies the form ula ip. Formally, ws is a m apping from £ RTCTL to 2Sv\ T h eo rem 4.1 (W eakest Satisfaction) For all finite models M — (V , U , I , N ) and formulas ip £ £ RTCTL? define ws(ip) inductively on the structure of ip as follows: 1 . if ip = v then ws(ip) = {s|s(u) and s £ Si/}. 2 . if ip = - ' then ws(ip) = N ~ 1 ws(<p). 4. if ip = E[<j!>Uv?] then ws(ip) = E [ 0 U p\. if ip = then ws{ip) = A[^>U-^tSvip]. 5. if ip = E[^U -°<^] then ws(ip) = ws(<p). if ip — E [ U ^ a~ V ])). if ip = A[<^U-°<£>] then ws(ip) = ws(p). if ip = A [d>U -ay ?] then ws(ip) = ws((pV {< p A A X A [ ^ U - a_V ])). The claim is that for all s € £ ws(ip) iff s \ — m 't P- P r o o f. By the definition of £ RTCTL all formulas m ust be of the forms given in item s 1-5. Item s 4 and 5 follow im m ediately from Lemma 4.1 and Equations 4.1 and 4.2 assum ing th a t 1-3 are facts. Item 1 is a m atter of definition. Item 2 follows from the properties of set intersection and the fact th a t £ y is closed under com plem entation. For item 3, we need the set of all states s such th at (s , s') £ N and s' £ ws((p). This ■ is simply N ~ 1 ws((p) as given. □ The real-tim e symbolic model checking rules follow from Theorem 4.1 and the isom orphism 0 introduced in C hapter 2 (Theorem 2.1). Simply replace all sets of Ltates by their boolean representation and substitute the boolean connectives for 78 1. C heck( w ) V 2. C heck(-i $) - - iC heck(0) Check(<^ a <p) = Check(^) • Check(<^) 3. C heck(EX<£) = 5tep(CHECK(0)) 4. C heck(E[0U</>]) = C heck(E[<£U-#S v ,< p]) C heck(A[<£U<p]) = C heck(A [^ U ^ #S vv : 3 ]) 5. C h e c k (E [0 U -V ]) = Check(<p) C heck(E [^ U ^ V ]) = C heck(<^)+ C heck(^) • 5tep(CHECK(E[<£U-a~ V ])) CHECK(A[<^U^V]) = CHECK(yj) CHECK(a [<^U— ay?]) = CHECK(y?) + C heck(^) • ->5’fep(-iCHECK(A[^U^a-1v3])) Figure 4.1: RTCTL Model Checking Rules the set operations. A lgorithm Step (Section 3.2.2) is used to com pute iV'~1ws(^>). T he rules are sum m arized in Figure 4.1 in term s of a routine C heck(^)) th a t takes a form ula if) and returns the set of all states th a t satisfy if) (the model is im plicit). As an exam ple, consider a two bit counter with S = {«o, }, fv 0 = _,® 0 ) and fv 1 = vo ® v j . The set of states th a t lead to a counter value of 3 (state vq • u j) in at m ost two tim es steps is expressed by the form ula x j) = A F - 2uo Aux- For this form ula, the rules work as follows: = C h e c k (A F -2u0 A vx) = C heck( A[true U - 2i/0 A ux]) = C heck(u0 A wi) -f CHECK(true) • -i1 S'^ep(-iCHECK(A[irue U - 1^ A ux])) = u0 • v\ + -iS tep (-i[u0 • vx + ->Step(->(v0 • ux))]) = v 0 ■ vx + ->Step(->[v0 • ux + ->u0 • ux]) = vo • vx + -iStep(-ivx) = Uo • + Uo • -'V x + -'V o • Ux 79 EUntila(4>, ip, a) : S 4 , = Check(<£) S = Sv = Check(v?) for t = 1, 2 , . . . , a loop S t = S v + 5^ • S tep (S ) if S = th e n e x it loop 5 = S t en d retu rn 5 Figure 4.2: Algorithm EU ntila for computing CHECK(E[^>U-tyj]). The rules correctly com pute a boolean formula th a t represents the set of states {^3,S i, S2 }. The set of states satisfied by a form ula w ritten S^, m ust contain the initial states I as a subset. If it doesn’t, the system fails it specification when it first starts to operate. Furtherm ore, most verification conditions are of the form AG^>. If this form ula is satisfied by the initial states, then i t ’s satisfied by any state reachable from the initial states. To check if / is a subset of S^. RTSMC evaluates ( I ■ S$) / and reports a successful check if the result is true. The im plem entation of symbolic model checking follows directly from the rules w ith one trick for evaluating the quantifiers. For example, the algorithm th a t finds the set of states th a t satisfies E [ 0 U - ay > ] is given in Figure 4.2. This algorithm com putes Check(E[<^>U -V ]) for increasing t starting from zero and term inates when t — a or the result at iteration t is the same as the result a t iteration t — 1. In the later case, the algorithm has found a fixed point and further iteration is pointless. This happens often in practice and checking for fixed points is crucial to the algorithm ’s perform ance but i t ’s not theoretically required. An analogous algorithm is used for A [<£U -ay> ]. 80 4 .3 .1 I n t u it io n s a b o u t I n p u ts Here we are going to explore a very simple system and two formulas th a t it satisfies. The system consists of a single input, or unconstrained state variable, nam ed rnd (random ). F irst, consider the formula E F rnd where rnd is given the initial state 'false. If rnd starts out as false, is there a path where it eventually becomes true? To evaluate E F rn d , it is best to consider the sequence of logical formulas E F - arn d = rnd V E X E F ^ a-1rn d ;for increasing a : E F - ° r n d = rnd E F -*rnd = rnd V E X rn d = rnd V 1 = 1 E F - 2rn d = 1 This reaches a fixed point after two steps, as it m ust, since the size of the model is only two states. The end result, not surprisingly, is th a t rnd does switch state on a t least one p ath given any starting value. Now consider the form ula E G rn d , which expresses the fact th a t there is a p ath where rnd is always true. At first, it might seem th a t this form ula is false since rnd will eventually have to switch. However, this is not the case, which can be seen by this sequence: E G - ° r n d = rnd E G - 1rn d = rnd A E X rn d = rnd E G - 2rn d = rnd A E X {rnd A EX rred) = rnd I 81 ‘ So, if rnd starts out true, there is a p ath where it always stays true. T he sem antics of the logic requires th a t all possible paths be considered leading from a state. A ■natural question is to ask if i t ’s really possible for a truly random variable to rem ain jtrue forever. The probability of a random variable remaining tru e for an n step sequence is 2- n , which vanishes as n goes to infinity. This seems to suggest th a t the !path where rnd stays forever true is not possible. B ut, w hat if rnd is being used to m odel a switch? Clearly, one behavior is th a t the switch is left on for the life of the system — very useful if i t ’s the power switch. One possible way out of this “paradox” is to realize th a t all physical systems m ust have a finite life and any behaviors beyond !a system ’s lifetime, including paradoxical ones, are irrelevant. In other words, for every system , there m ust be some “cut-line” in its forest of states where the system Jstops working physically and everything beyond th a t point is meaningless. This line is unbounded and doesn’t depend on the size of the model (the random program only has two states), but it is always finite. 4 .3 .2 R e la t e d W o r k T his work builds off the work on CTL symbolic model checking perform ed at jCarnegie Mellon University. The CMU work was of a pathfinding n atu re, in th a t it showed the utility of symbolic model checking for verifying reactive system s th a t h a d a previously intractable num ber of states. Here we have extended the CMU work in some im portant new directions: • Symbolic model checking for RTCTL. • The verification of tim ing-properties for real-tim e systems. • The identification of unconstrained state variables as the fundam ental source of nondeterm inism . • A predecessor algorithm , Step, th a t allows a fully partioned representation of the state transition relation which results in superior perform ance. • A characterization of asynchronous systems in a synchronous fram ework. 82 The linguistic differences between Sal and the SMV input language were discussed in Section 2.3.3. There is also a difference in conceptual views. Here we are prim arily interested in verifying complete specifications for controllers th a t can be considered as block boxes. T he CMU researchers tended to focus on proving a single property of a circuit or protocol. Also, the derivation of the two techniques are substantially different at a technical ilevel. In M cM illan’s thesis, a lattice was constructed over sets of states using C as an ordering. Using this lattice, a fixed-point characterization of CTL is applied th a t was developed by Clarke and Em erson[CE8 la]. Finally, an application of the Tarski-K naster fixed-point theorem [Tar 5 5] gives an iterative m ethod for com puting the set of states th a t satisfies the formula. In contrast, our approach is based on naive set theory and the elimination of RTCTL quantifiers for finite models. The CMU approach is higher-level from a m athem atical point of view, but i t ’s not m ore general since the Em erson-Clarke fixed-point characterization of CTL only applies to finite models. Furtherm ore, the approach presented here is applicable to the real-tim e variant of CTL. Independently of this work, Henzinger et al. have developed a symbolic model checking procedure for a real-tim e logic called TC TL (Tim ed C om putational Tree Logic)[HNSY92]. TC TL is a relatively new branching tim e logic th a t uses a dense m odel of tim e, i.e. tim ing constraints are expressed over the real num bers, and sys tem s are assum ed to have an asynchronous interleaving semantics. U nfortunately, T C T L is an undecidable logic. Also, the perform ance of the T C T L symbolic model checking procedure for large problems has yet to be dem onstrated. The example given in their paper is a gate controller for a railroad crossing th a t has only twelve states. Finally, the refinements presented here, such as the Step , m ay not be appli cable to T C T L symbolic model checking. i I 1 [ 83 C h a p te r 5 A p p lic a tio n s In this chapter real-tim e symbolic verification is applied to three applications: the traffic light controller, an elevator controller, and a rule-based diagnostic system . The verification of the last two applications is intractable by traditional model check ing techniques. There are three parts to the presentation of each application: 1. a description and Sal im plem entation, 2. an RTCTL specification, and 3. the results of using RTSMC to verify the im plem entation. The description and im plem entation for the traffic light controller appears in Section 2.2.4. 5.1 T raffic L igh t C o n tro ller The specification of a system is the conjunction of several RTCTL form ulas. Each form ula expresses a desired property of the system and all of the form ulas, taken together, m ust be satisfied before we can assume the system is correct. Specifications will be given as a series of RTCTL formulas and w ritten justifications. Each form ula m ust be satisfied in all states, so given a specification 4r we model check A G ( f ) , i.e. 4? is true in every state of all paths. There are some useful abbreviations. The first is GoesTrue(ip) = -tip A EXV> (5.1) which is tru e in a state if ip is not true now but becomes true on at least one p ath a t the next tim e. The second, StaysT rue(ip,t) = GoesTrue(ip) — * A~K(ip — ► A G -*^ ) (5-2) i 84 expresses the fact th a t if ip goes true it will stay true for at least t ticks. Note th a t ip is only required to stay true leading from states where it actually goes true. The following is a specification for the controller. I t’s intended to be complete and clear, even if th a t means there’s some overlap between the assertions. • W \. Only one light may be green or yellow at a time: (HwyJGreen V H w y Y e llo w ) — > SideGted and (Side-Green V S i d e Y ellow) — ► H w yJled . The interpretation is th a t if the highway (side road) light allows traffic, then the side road (highway) light m ust be red. These are safety conditions. • W ?, . Traffic m ust be allowed on at least one road: HwyJGreen V iH w yY ellow V SideJGreen V S id eY ello w . This is a liveness condition. In combination with W l , it insures th a t one light will be red and the other will be either green or yellow. • W 3 . Lights m ust sequence properly from green to yellow to red in the specified am ount of tim e (Ty): S ta ysT ru e(H w yJfello w , Ty) A (H w y Y e llo w — ► A F - Ty+1 SideJGreen) and similarly for the side road: S ta y sT ru e (S id e Y e llo w ,T y) A (S id eY ello w — * A F - T y + 1 HwyJGreen). These form ulas require th a t the caution lights stay on for at least Ty seconds. Furtherm ore, if a caution light is on, the green light for the other road will be on in no m ore th an 7^ + 1 seconds. The safety assertion W l insures th a t the 85 yellow light will go red. The following assertions insure th a t the lights don’t “skip around:” H wy-Green — * wy-Red H w y-Y ellow — ► -E X H w y-G re en H w y-Red — ► -iE X H w y-Y ellow SideJGreen — * ->EX Side-R ed S id e y e llo w — + -<EX SidejG reen Side-Red — * -YEiXSideJf ellow. • W 4 . The highway light m ust rem ain green for at least T/t seconds: StaysTrue(H w y-G reen, Th). A fter th a t period, it m ust allow side road traffic: H wy-Green — * A F - Th(cars — * A X H w y-Y ello w ). In any state where the highway light is green, it m ust go yellow w ithin Th seconds if there are cars. The formula m ust hold in the very first state in which the highway light goes green, so if there are cars Th seconds in the I future they will get to go, as required. • W 5 . T he side road light m ust rem ain green as long as there are cars and it h asn ’t been green too long (Ts). This is also expressed in two steps. F irst, if the light is green and there are no cars, then it m ust go yellow: (Side-Green A -tears) — > ■ A X Side-Y ellow . Secondly, if there are continuously cars, the side road light m ust stay green for 15 seconds and then tu rn yellow, which is expressed by the formulas GoesTrue{Side-Green) — > A X |Side-Green — * A G - Ts~l (Side-Green A cars — + A X SidejG reenf^ 86 Th reachable states tim e (secs) tim e w /o W 4 (secs) 15 80 0.300 .216 30 110 0.516 .3 60 170 0.883 .433 120 290 1.35 .616 240 530 3.15 .866 480 1010 5.63 1.23 960 1970 12.3 1.9 1920 3890 — 3.05 Table 5.1: RTSMC verification timings for the traffic light controller, and Side-Green — » A F - T $ + 1 Side-Yellow. T he first form ula requires the light to remain green as long as there are cars and i t ’s currently green. The second formula says the light always goes yellow within 15 seconds. The formulas W3 . . . W 5 are a combination of correctness assertions and tim ing con straints. This should be expected for real-tim e systems: such a system is correct only if it responds properly at the right tim e. The entire specification for the controller is $ T L C = A G ( A Wi). (5.3) 1<{<5 This specification is expressed only in term s of the observables of the system , namely the lights and the car sensor. Nothing in the specification references the internal tim er or state registers, which are im plem entation dependent. The specification m ust be applicable to any im plem entation. R e su lts. To objective is to show how the verification tim e depends on the num ber of reachable states. The num ber of reachable states in the traffic light controller jean be changed by adjusting the tim e the highway light stays on: the longer the tim e, the greater the num ber of reachable states. By doubling the highway green jtime, the am ount of work RTSMC m ust do increases in two ways: 1. the size of the mathematical model doubles, and 2 . the model checker m ust search twice 87 as far into the future. At first glance, one might expect the verification tim e to depend quadratically on the num ber of reachable states. The regular RTCTL model checking a!gorithm[EMSS89] does b etter than this. Its tim e complexity is x log x where x is the num ber of reachable states. The log factor comes from the fact th a t additional state variables m ust be added to the tim er to represent larger values which increases the num ber of atom ic propositions (V ). This causes an increase in the size of the m athem atical model beyond th a t caused by the additional states. Table 5.1 gives the actual RTSMC timings for the complete specification, and the specification w ithout assertion W 4 .1 For the runs, Ts was set to 15. The d a ta in the table in plotted in Figures 5.1 and 5.2. For the complete specification, RTSM C’s tim e complexity is linear in the num ber of reachable states. This is far b etter th an quadratic, but not much of an improvement over a traditional model checker. The trouble is th a t the tim e bound on assertion W 4 is proportional to the num ber of states. If the assertion is removed, the complexity drops to x 2/ 3. The actual polynom ial fit is T ( x ) = 0.0378201 + 0.0120996a;2/3 where x is the num ber of reachable states. A few conclusions can be drawn from these results. F irst, the OBDD representa tion did not “blow up” and, instead, provided a compact representation of the m ath em atical model. Second, real-tim e symbolic model checking clearly out-perform ed regular model checking in the absence of tim e bounds th a t are proportional to the num ber of reachable states. For tim e bounds of this form, however, it m ay be dif ficult for symbolic model checking to do much better th an regular model checking. Fortunately, this is an unusual application, and tim e bounds are generally small com pared to the num ber of reachable states. j lrThe runs were perform ed on a SPA R C station-IPX w ith RTSM C com piled using SPA R C com - ipiler CH— h version 3.0.1 w ith -0 3 optim ization. 1 I 88 T i m e 12 10 t a t e s 2 5 0 7 5 0 1000 1250 1500 1750 200 500 Figure 5.1: RTSMC tim ings for the TLC verification versus the num ber of reachable states as determ ined by 2V T i m e 3 . 5 2 . 5 1 . 5 0 5 0 0 1000 1500 2000 2500 3000 3500 400 Figure 5.2: RTSMC timings for the TLC verification with assertion W 4 removed versus the num ber of reachable states as determ ined by 2V I 90 5.2 E le v a to r C o n tro ller The Elevator C ontrol System problem has a history dating back to K nuth’s use of it as an example of discrete event simulation[Knu75]. His particular application was the single elevator serving the five story M athem atics building at CalTech. The problem was first specified using a tem poral logic in Berringer’s technical report “Up and down the tem poral way” [Bar85]. Berringer’s specification is in term s of an ad-hoc linear tim e tem poral logic w ithout real-time quantifiers. It is an exten sive qualitative treatm ent of an elevator system , but it lacks real-tim e constraints. Furtherm ore, Berringer didn’t provide an im plem entation, nor show its correctness. Recently, Hale has taken a more operational approach[Hal90], based on Berringer’s work, and produced a specification and im plem entation of the problem in Tem pura, an executable tem poral logic[Mos86]. Hale’s specification is not as complete as B erringer’s, b ut it includes real-tim e constraints. Furtherm ore, he provides a proto type im plem entation th a t can be executed to simulate the operation of the system , which is very valuable for designers. In principle, given a Tem pura specification and im plem entation of a system, it’s possible to show th a t the im plem entation is correct. However, Hale left it as a (difficult) proof to the reader. Here we will apply S al and RTSMC to the problem. Somewhat different de scriptions were given by Berringer and Hale. W hat follows is quoted from Hale. The controller is to govern the operation of n identical lifts servicing an m -story building. It interacts with the environm ent through a num ber of external interfaces. 1. In each lift there is a control panel with one b u tto n for each floor. T he buttons illum inate when pressed and rem ain illum inated until the lift visits the appropriate floor. 2. On each floor (except ground and top) there are two buttons, one to request a lift going upwards, the other to request a lift on its way down. Each of these buttons illuminates when pressed and rem ains on until a lift travelling in the appropriate direction visits the floor. It then goes off. 3. The position of each lift is controlled by interaction w ith a “m otor u n it” . The m otor unit may be instructed to move the lift up or down, or to keep it stationary. The position and direction of each 91 lift is displayed on every floor. (This is one of the less secretive lift system s). 4. Each lift has doors which open and close on signals from the con troller. The doors must open when the lift visits a floor to collect or deposit passengers, and m ust be closed when the lift is in m otion. If the doors encounter an obstruction whilst closing, they should re-open. There is also a b utton within each lift for signalling the doors to rem ain open. 5. In each lift there is an emergency button. W hen this b u tto n is pressed an alarm is raised and the lift goes out of service. W e’ll lim it the im plem entation to a single elevator (n = 1) w ithout emergency or hold buttons. The addition of more elevators has two effects: 1. it increases the num ber of reachable states, and 2 . it complicates the strategy th a t decides which direction an elevator goes. A nother way to increase the num ber of reachable states is to add m ore floors to a single elevator system. T h a t’s the approach taken •here. T he control strategy for the single elevator system is fairly complex already land th e additional complexity of a multi-elevator controller only adds unnecessary Jdetail. The emergency hold buttons are of little interest since they disable the entire system .2 5 .2 .1 R T C T L S p e c ific a tio n The RTCTL specification is w ritten in term s of the observable state variables of the system and applies to any im plem entation. O b serv a b les. The observable state variables of the controller are as follows: • Motor. Turns the m otor on (true) and off (false). • Dir. If the m otor is on, the elevator travels up (down) when D ir is true (false). T he com bination of M otor and D ir control the “m otor u n it.” The state of D ir is shown at each floor. I ___________________________________ j 2T here is one interesting aspect of the hold button. A person can hold th e elevator indefinitely iwhich m akes it m ore difficult to express tim ing constraints. A solution, suggested by Hale, is to only count tim e w hen the elevator’s m otor is on. T his is expressible in R T C T L w ith a form ula .whose length grows in proportion to the tim e bound. 92 • Door. Closes the door (true) and opens it (false). • Loc. A register th a t holds the elevator’s current floor num ber. The bottom floor is num bered zero and the top floor is num bered m — 1. The current value of Loc is show at each floor. • InReqi. The request b utton for floor i inside the elevator. All bu tto n state variables read as true when the corresponding b utton is pressed. • InL ighti. T he corresponding light. • UpReqi. The up request b utton at floor i (this is outside the elevator). • U pLighti. The corresponding light. • DownReqi. The down request button at floor i. • DownReqi. The corresponding light. The controller may have other im plem entation dependent state variables th a t are used internally and th a t help model the physical environm ent. These variables are discussed in the im plem entation section. T he following shorthands make the specification more readable: UpDir = D ir D ow nD ir = -> D ir M otor On = Motor M otorO f f = -i M otor OpenDoor = ~>Door CloseDoor = Door V isitedi = (Loc = i Visitedi is true when the elevator is at floor i with the m otor off and the door com m anded to open. The syntax Loc = i is not strictly in the logic but its m eaning is clear. It can be expressed using bitwise comparison. k I 93 The controller has a control frequency / which governs how m any times a second the controller fires rules. For the traffic light controller, / = 1, which means th a t each tick of the clock corresponds to one second. For the elevator controller, a slightly faster rate of / = 2 is more appropriate (otherwise, there would be an unaccepted delay between pushing a b utton and its corresponding light illum inating.) Also required to express tim ing constraints is the am ount of tim e tm required for the elevator to move between two adjacent floors. We’ ll assume this is two seconds (i.e. ft'rn — 4). S p e c ific a tio n . The specification for the elevator controller ^ ec is the conjunction of the following formulas quantified by A G . • W \. An assertion th a t may not be obvious is th a t the elevator always resumes m otion in its indicated direction of travel. If it didn’t, people would get on the elevator assuming it will go one direction and get very upset when it starts off in the other direction. This is specified by OpenDoor A UpDir — * A\OpenD oor\5U pDir] and similarly for down OpenDoor A DownDir — ► A[OpenDoor XJ DownDir]. • W i. The door should be closed while the elevator is moving which can be expressed as M otorO n — > CloseDoor. • W 3 . The direction doesn’t change while the m otor is on: M otorO n A UpDir — ► A X.M otorO f f V UpDir. Similarly for down: M otorO n A D ow nD ir — > ■ A ~S.MotorOf f V D ownDir. 94 i • W 4 . W hever the door is opened, it stays open long enough for people to get in and out (4 seconds): StaysT rue(O penD oor, 4 /). • W 5 . The elevator doesn’t go through the roof or basem ent: V ( L o c = * ) • 0 < i< m • We- All the buttons and lights work properly. F irst, if th ere’s an internal request th a t is not already being serviced or the light is already on, then the corresponding light m ust be illum inated at the next tick: (InR eqi V L ig h ti) A - 1 V isited i — ► A 'X.InLighti. The light only goes off when its floor is serviced: V isited i — ► A X .-'In L ig h ti. The last form ula states th a t the light m ust not go on by itself: E H-Lighti — * ■ (InR eqi V In L ig h ti). T here’s an instance of each of these formulas for 0 {V isitedi A U pD ir ) — * • A ~KUpLighti V isite d i A U pD ir —* ■ A'X.-^UpLighti VK .U pLighti — * (UpReqi V U pLighti) (D ow nR eqj V D o w n L ig h tj) A -'(V isited j A D o w n D ir) — » • A X D o w n L ig h tj V isite d j A D o w n D ir — * A 'X .-'D ow nLightj TO/XDownLightj — * ■ (D ow nReqj V D o w n L ig h tj) w ith 0 < i < m — 2 and 1 < j < m — 1. 95 • W j. Finally, all internal requests are serviced in a reasonable am ount of tim e. In the worst case, the elevator could travel up and down stopping at each floor. This would give an upper bound of t = 2 m /(4 + tm + 1) where a little ex tra is added to give the controller time to com pute. The constraint for internal requests is In L ig h ti — » A F - (V isited i. Similarly, all external requests are serviced: U pLighti — * ■ A F - lV isited i A U pD ir for 0 < i < m — 2 and D ow nLighti — * • A F -* V isitedi A D ow nD ir for 1 < i < m — 1. T he set of initial states corresponds to the elevator waiting at the ground floor w ith the m otor off, direction up, door open and all lights off. 5 .2 .2 S a l I m p le m e n t a tio n The controller consists of several Sal rules which are listed in Appendix A. M any of the rules deal with simple tasks such as operating the lights and door. However, two sets of rules require further explanation. The first set deals w ith the strategy ifor controlling the elevator’s direction. The second set models the movement of the elevator between floors. Both sets are discussed in the rem ainder of this section. An im portant p art of the im plem entation is developing a strategy for determ ining jwhich direction the elevator should move after each stop. The decision is m ade right before the elevator opens the doors so th a t potential passengers know the new {direction before boarding. A fter waiting with the door open, the elevator continues I In the new direction if there are pending internal or floor requests. If the elevator approaches a floor and there’s either an internal request for the floor or th ere’s an t external request in the elevator’s new direction, the elevator will stop at the floor. T he elevator always stops at the ground and top floors. 96 The strategy used to decide the new direction when approaching a floor is: • If going up and there are requests to go higher, then keep going up. A request to go higher means th a t there’s an internal request for a higher floor, th ere’s an external up request at the current floor, or th ere’s an external up or down request at any higher floor. • If going down and there are no requests to go lower but there are requests to go higher, then go up. • If the location is the ground floor, then set the direction to up. • Otherwise, go down. This strategy makes the elevator go as far as possible in the current direction before turning around, serving every request in the current direction as it goes. One p art of the im plem entation models the tim e it takes the elevator to move between floors. A real controller would use sensors at each floor to determ ine the elevator’s location. T h a t’s not practical here since we need some way to model the bounded travel tim e between floors (the physical elevator does this for the real controller). W ithout a bound on the travel tim e, there would be no way to satisfy the assertion th a t requests are serviced within a certain am ount of tim e, or, indeed, th a t th ey ’re serviced at all. There are two ways to model the travel time. The approach taken here is to assum e the elevator takes a fixed am ount of tim e (tm) to move between floors. A nother way is to use unconstrained state variables to build a random num ber generator. W henever the elevator starts moving or passes a floor, it copies the random num ber generator into a tim e to next floor counter. The controller assumes the elevator is at the next floor when this counter reaches zero. W ith the approach, the specification is verified for a whole range of travel times. j5.2.3 R T SM C R esu lts jThe num ber of reachable states for the elevator controller is a function of the num ber jof floors. Each additional floor requires three unconstrained state variables for 97 Floors R(m) Base (secs) Perform ance (secs) 2 7,680 2.43 3.83 3 737,280 7.96 18.6 4 62,914,560 22.8 70.9 5 5,033,164,800 115 858 Table 5.2: RTSMC verification timings for the elevator controller. requests, three regular state variables for the light outputs, and possibly an increase in the size of the location register. This results in a dram atic increase in the num ber of reachable states per additional floor. Assume for a m oment th a t there are no request buttons or lights. In this case, the num ber of states grows linearly w ith the num ber of floors. For the param eters given ( / = 2, tm = 2, and a 4 second door open tim e), about 30 states are added per floor. The buttons and lights add another 6 state variables per floor. The buttons are unconstrained so th a t they can be in any state a t any instant. The lights also act like unconstrained variables since th ey ’re controlled directly by the buttons (unless the elevator is stopped at the proper floor going in the proper direction). An estim ate of the to tal num ber of reachable states as a function of the num ber of floors is R (m ) = 30m 26(ra~ 2)+7 for m > 2. The factor of 27 accounts for the fact th a t ground and top floors do not have all the buttons and lights. The exact constants in the formula are not im por ta n t, the im portant p art is th a t the number of reachable states grows exponentially in the num ber of floors. T he expected tim e complexity for a traditional model checker is 0 ( m R ( m ) logR (ra)). The factor of R (m ) log R (m ) is ju st like the traffic light controller, the size of the m odel is proportional to the number of states times the num ber of state variables. The factor m comes from the fact th at the specification is growing in length due to assertions W$ and W 7 . 98 Table 5.2 gives the RTSMC timings for an elevator w ith 2-5 floors. For each num ber of floors a tim e is given for assertions W 1 -W 5 (Base) and the com bination of the In L ig h to and D ow nL ighti performance constraints (W 7.). The tim e required to verify the We assertions was negligible. For 2, 3, and 4 floors the RTSMC verification tim e is slightly less than linear in the num ber of floors for both the base specification and the two performance constraints. The jum p in the curve for perform ance constraint for the 5 floor elevator is due to the addition of a bit to location register. The linear growth in verification times as a function of m is rem arkable because the num ber of reachable states is growing exponentially. This is a dram atic improvem ent over traditional model checkers. 5 .3 A R e a l-T im e R u le -B a se d D ia g n o stic S y s te m The Space Shuttle is a highly complex system with m any failure modes. W hen a problem is detected on the shuttle, the crew and ground controllers use a series of m alfunction procedures to diagnose the nature of the problem. These procedures naturally take the form of decisions trees, where each node is a question about the sh u ttle’s current state. Helly, as part of his 1984 Ph.D . thesis[Hel84], encoded the m alfunction procedure for a shuttle cryogenic system as a rule-based system called CRYO 6.3a.3 Each node in the tree is assigned a boolean (state) variable th a t represents if the shuttle is in th at state or not. Given the sh u ttle’s state, the rule-based system can be used to diagnose the problem. Mok considered Helly’s system in a real-time context [Mok89]. He encoded the rules into EQL which was discussed in Section 2.3.2. EQL program s are composed of a working m em ory and a set of SAL-like rules. The working memory is initialized by some external agent with the Shuttle’s state and then the EQL inference engine is started . A t each step, it fires all enabled rules which update the working memory. U nder certain conditions th a t Mok characterized, the system will reach a fixed- point: the rules no longer change the values in the working memory. T he agent then reads the working memory to determ ine the diagnosis. Mok developed a tool, 3T h e official N A SA ese for the decision tree is “C ryogenic Hydrogen Pressure M alfunction Pro cedure of the Space Shuttle Vehicle (SSV ) Pressure Control S ystem .” 99 called fp tim e , th a t finds the longest sequence of rule-firings before a fixed-point is reached. In other words we can determ ine if the system m eets a perform ance constraint. RTSMC and Sal can also be used to implement and verify the tim ing of CRYO ,6.3a. For reference, the Sal im plem entation is contained in A ppendix B. There are two advantages to using a general verifier: 1 . we can prove other assertions about the rule-based system s, and 2 . the range of systems th a t can be verified is larger. Let V be the set of state variables in the working memory. The assertion th a t ithe variables stop changing can be w ritten f p = v A X ». vev The specification th a t the system reach a fixed-point within t tim e units is then VFP = A F &FP. RTSMC was used to verify this assertion for t = 10. For the run, the race condition detection algorithm was modified to flag an error even if two rules sim ultaneously assigned the same value to a register. Under this definition, the rule pairs 27-28, 29-30, 31-32, and 34-35 conflict, which was reported by the Sal compiler. These conflicts are innocuous since, in each case, the same value is assigned to the register. The system has no control over its initial state since an external agent assigns initial values to all of the state variables. Thus, there are 259 = 576,460, 752,303,423,488 « 5.77 x 1017 reachable states. RTSMC required 2,054 seconds to verify th a t a fixed point is reached w ithin 10 tim e steps. A to tal of 24,478 OBDD nodes were created. The verification tim e is impressive. A model checker based on state enum eration would require about 183 centuries, at the rate of 1,000,000 states examined per second, to perform the same task. More interesting is th a t only 24,478 OBDD nodes were created during the entire verification process. The reason for this is th at both the rule-based system and 100 the OBDD representations are decision trees. Given the proper variable ordering, the two should m atch up. This appears to be the case. Note th a t the variables are declared in opposite order in the Sal program . I did this because Sal assigns variables num bers in reverse order of declaration which means th a t the variable declared first will always be at the bottom of an OBDD (if it appears at all in the corresponding formula). The variable declared last will be at the top. If the reverse variable ordering is used, the OBDD representation is far less efficient. This represents one of the worst possible cases, an inverted decision tree. The RTSM C run w ith the reverse variable ordering took over 10,000 seconds before it was term inated. This suggests th a t it can be helpful to have some knowledge of the application to give RTSMC hints on a good variable ordering. 101 C h a p te r 6 C o n c lu d in g R em a rk s By extending symbolic model checking to Real-Time C om putational Tree logic we have been able to verify real-tim e controllers th a t were intractable by previous model checking algorithm s. For each application, real-tim e symbolic model check ing showed a tim e complexity th a t is superior to traditional model checking. These results are encouraging w ith two caveats: 1. if the tim ing constraints grow linearly w ith the size of the model (like the traffic light controller), the benefits of symbolic model checking may be negligible, and 2. the OBDD variable ordering may require some tuning as was done for the rule-based system. A single basic notion was the driver behind most of this work: th a t an un constrained state variable (input) is the fundam ental source of non-determ inism in synchronous controllers. This affected the design of S a l, helped guide the selec tion of the logic (R TC TL), and lead to a fast algorithm , Step, for com puting the predecessors of a set of states. Sal was developed to explore a rule-based approach to implem enting reactive controllers. This approach seemed natural, the system continuously senses its en vironm ent and takes the appropriate actions. This resulted in a highly concurrent language and the issue of race conditions. Detecting race conditions is an im portant p art of the verification process. If races exists, then the m athem atical model of the system and its physical im plem entation might have different behaviors which makes verifying the im plem entation pointless. Developing specifications is a difficult process. I found th a t it was necessary to iterate between the specification (RTCTL) and im plem entation phase (S a l) of the 102 applications to get them both right. This is incom patible with the idea of a “w ater fall” approach to software engineering where a system progresses from requirem ents, to specification, to design, to im plem entation, and so on. An iterative approach (the “fountain” m odel) seems much more appropriate. By trading off of each other, both the specification and im plem entation improve which ultim ately results in a safer system. F u tu r e w o rk . There are several avenues for future study. Perhaps the m ost im p o rtan t is applying real-tim e symbolic verification to more applications to better understand its utility. A first step would be the establishm ent of a set of controller benchm arks, analogous to the ones used by the digital circuit sim ulation community, for com paring verification techniques. This would help lend m ainstream credibility to the idea of form al verification and provide a gauge for com paring different ap proaches. Ultim ately, I hope th a t formal verification in general, and the techniques of this thesis in particular, are used by practicing engineers to help design more reliable safety critical systems. One particularly interesting application area is fuzzy control systems[Lee90]. Fuzzy controllers are being used in a wide variety of devices, from washing machines to trains, and have recently received attention in the popular media. They are often m ore efficient th an controllers based on classical strategies. For exam ple, a fuzzy washing machine controller can sense how dirty the clothes are and vary the w ater tem perature and washing action accordingly. This is b etter th an turning the w ater on hot and washing for the maximum am ount of tim e on the dial. Currently, little work is being done on verifying fuzzy controllers and they are beginning to be used in critical system s, such as controlling the speed of the Shinkansen (Japanese bullet train). One common way of program m ing these systems is by “training” w ith num erous input-response patterns th a t are known to be good (correct is too strong a word). These same cases, or ones very similar, are often used for testing. This is a very dangerous practice in a system th a t may have upwards of a billion configurations: could there be a fatal combination of conditions sensed as inputs th a t will cause the train to exceed the track’s capacity? Fortunately, fuzzy controllers 103 tend to have few state variables and can be easily program m ed in Sa l. This opens up the possibility of using symbolic verification on these systems. Finally, the results of this work can be applied to asynchronous system s by using the encoding given in Section 2.1.4. The benefit is th a t S te p , w ith its fully partitioned state transition relation, can be used on asynchronous system s w ith the expectation th a t the verification times will be improved. i 104 A p p e n d ix A S a l Im p le m e n ta tio n o f th e E lev a to r C o n tro ller / / E levator c o n tr o lle r fo r 3 flo o r s It #d efin e True 1 #d efin e F alse 0 / / Constants fo r lig h t s and motors #defin e On 1 #defin e Off 0 / / E levator d ir e ctio n s #defin e Up 1 #defin e Down 0 #d efin e LocSize 2 / / Door commands #d efin e Open 0 #defin e Close 1 / / Shorthands fo r s ta te v a r ia b le s. x /* * /y i s concatenation, / / fo r example, i f n = 2, u p _ligh t_/**/n i s replaced by up _ligh t_2. / / Buttons fo r up/down requests at flo o r s #d efin e UpReq(n) up_req_/**/n #defin e DownReq(n) down_req_/**/n / / L ights fo r up/down requests at flo o r s #d efin e UpLight(n) u p _ligh t_/**/n #d efin e DownLight(n) dow n_light_/**/n 105 / / In tern al request and lig h t #d efin e InReq(n) in_req_/**/n #d efin e InLight(n) in _ lig h t_ /* * /n / / 4 seconds ♦d efin e OpenT 8 #d efin e OpenTSize 4 #d efin e SomeReq (InLight(O) I I In L igh t(l) II InLight(2) II \ UpLight(O) II UpLight(l) I I DownLight(l) II DownLight(2)) ♦d efin e InReqFor(floor) \ ( ( ( f l o o r == 0) & & InLight(O)) I I \ ( ( f lo o r == 1) & & In L ig h t(l)) I I \ ( ( f lo o r == 2) & & In L igh t(2))) ♦d efine UpReqAt(floor) \ ( ( ( f l o o r == 0) & & UpLight(O)) II \ ( ( f lo o r == 1) & & U pL ight(l))) ♦d efine DownReqAt(floor) \ ( ( ( f l o o r == i) & & DownLight(1 )) II \ ( ( f lo o r == 2) & & DownLight(2 ))) ♦d efin e ReqAbove(floor) \ ( ( ( f l o o r == 0) & & \ (UpLight(O) |I UpLight(l) I I DownLight(l) I I DownLight(2) I I \ InL ight(1) j| InLight(2 ))) I I \ ( ( f lo o r == 1) & & (UpLight(l) |I DownLight(2) | | In L ig h t(2 )))) ♦d efin e ReqBelow(floor) \ ( ( ( f l o o r == 2) & & \ (DownLight(2) I I DownLight(l) I I UpLight(l) I I UpLight(O) I I \ InL ight(0) | | InLight(1 ) )) | | \ ( ( f lo o r == 1) & & (DownLight(l) II UpLight(O) I I InL ight(O )))) ♦d efin e V is it e d ( f lo o r , dirO) \ ((Loc == flo o r ) & & (Dir == dirO) & & (Door == Open)) ♦d efin e FloorRules(n) \ UpReq(n) => UpLight(n) := On; \ 106 V isite d (n , Up) => UpLight(n) := Off; \ DownReq(n) => DownLight(n) := On; \ V is ite d (n , Down) => DownLight(n) := Off; #d efin e InRules(n) \ InReqCn) => InLight(n) := On; \ (Loc == n) & & (Door == Open) => InLight(n) := Off; #defin e ComputeNewDir ((tim er == 2) & & (Motor == On)) #defin e ComputeStop ((tim er == 3) (Motor == On)) #defin e NewFloor ((tim er == 4) & & (Motor == On)) r e g is t e r Dir := Up; LocQLocSize := 0; Motor := O ff; Door := Open; / / External request lig h t s DownLight(2) := Off; UpLight(1) := Off; DownLight(1) := Off; UpLight(0) := Off; / / In tern al request lig h t s InL ight(2) := Off; InL ight(1) := Off; InL ight(0) := Off; new_dir; stop := False; timerOOpenTSize := 0; input / / External requests DownReq(2); UpR eq(l); DownReq(l); j UpReq(O); / / In tern al requests 107 InR eq(2); In R eq (l); InReq(O); ru le / / Rules to compute new d ir e ctio n rig h t before reaching a flo o r / / Assumes Loc contains d estin a tio n flo o r ComputeNewDir & & (Dir == Up) & & ReqAbove(Loc) => new .dir := Up; ComputeNewDir & & (Dir " Down) & & ReqAbove(Loc) & & !ReqBelow(Loc) => new .dir := Up; ComputeNewDir & & (Loc == 0) => new_dir := Up; / / Rules to stop elev a to r at flo o r based on req uests and new_dir ComputeStop & & InReqFor(Loc) => stop := True; ComputeStop & & (new_dir == Up) & & UpReqAt(Loc) => stop := True; ComputeStop & & (new_dir = = = Down) & & DownReqAt (Loc) => stop := True; ComputeStop & & ((Loc ==0) I I (Loc == 2 )) => stop := True; / / Stop e lev a to r and open doors stop => Motor := Off, Dir := new_dir, Door := Open, stop := F a lse, tim er := 0; NewFloor ftft (Dir == Up) & & !stop => Loc := ++Loc, tim er := 0; 108 NewFloor & & (Dir == Down) & & !stop => Loc := —Loc, tim er := 0; (Door == Open) && (timer == OpenT) & S c SomeReq & & (Dir == Up) => Door C lose, Motor := On, Loc := ++Loc, tim er := 0; (Door == Open) & & (tim er == OpenT) & & (SomeReq II (Loc != 0)) && (Dir == Down) => Door := C lose, Motor := On, Loc := —Loc, tim er := 0; / / Floor req uests and lig h t s UpReq(O) => UpLight(0) := On; V is ite d (0 , Up) => UpLight(0) := Off; F loorR u les(l) DownReq(2) => DownLight(2) := On; V is ite d (2 , Down) => DownLight(2) := Off; I f In tern al req uests and lig h t s InRules(2) In R u les(l) InRules(O) d e fa u lt tim er != OpenT => tim er := ++timer; ComputeNewDir => new_dir := Down; 109 A p p e n d ix B S a l I m p le m e n ta tio n o f C R Y 0 6 3 a / / S h u ttle d ia g n o stic rule-based system / / From [H elly 84] appendix A.2. 63aLHS / / Rosie converted to SAL #d efin e true 1 r e g is t e r v63ax53 v63ax52; v63ax51; v63ax50 v63ax49b; v63ax49a; v63ax48 v63ax47 v63ax46; v63ax45; v63ax44 v63ax43 v63ax42; v63ax41; v63ax40 v63ax39 v63ax38; v63ax37; v63ax36 v63ax35 v63ax34b; v63ax34a; v63ax33 v63ax32 v63ax31; v63ax30; v63ax29 v63ax28 v63ax27; v63ax26; v63ax25 v63ax24 v63ax23; v63ax22; v63ax21 v63ax20 v63axl9; v63axl8; v63axl7 v63axl6 v63axl5; v63axl4; v63axl3 v63axl2 v 6 3 a x ll; v63axl0; v63ax9; v63ax8; v63ax7; v63ax6; v63ax5; v63ax4; v63ax3; v63ax2; v63axlc; v63axlb, v63axla; v63bx7; v63bx8; ru le v63axla => v63ax2 := true; / / 1 v63axlc v63ax3 => v63ax4 := true; / / 2 v63axlc & & (!v63ax3) & & v63ax5 => v63ax6 := true; / / 3 110 v63ax6 => v63ax7 := t r u e ; / / 4 v63axlc kk (!v63ax3) kk C!v63ax5) kk v63ax8 => / / 5 v63ax9 := true; v63ax9 -> v63axl0 := true; / / 6 v63axl2 | | ((!v6 3 a x l2 ) kk v63axl3) => v63axl4 := t r u e ; / / 7 v63axlc & & (!v63ax3) kk (!v63axS) kk (!v63ax8) kk / / 8 (!v 6 3 a x ll) kk v63axi2 kk v63axl4 => v63axl5 := true; v63axlc kk (!v63ax3) & & (!v63ax5) kk (!v63ax8) kk 11 9 v 6 3 a x ll kk v63axl6 & & v63axl7 => v63axl8 := true; v63axlc & & ( ! v63ax3) & & (!v63ax5) & & (!v63ax8) & & / / 10 v 6 3 a x ll & & v63axl6 => v63axl9 := true; v63axlc & & ( ! v63ax3) & & (!v63ax5) & & (!v63ax8) & & / / l l v 6 3 a x ll & & v63axl6 & & (!v63axl7) => v63ax20 := true; v63axl9 I I v63ax20 => v63ax21 := true; / / 12 v63ax22 & & (!v63axl4) & & v63axl2 & & (!v 6 3 a x ll) & & / / 13 (!v63ax8) & S t (!v63ax5) & & (!v63ax3) & & v63axlc => v63ax24 := tr u e ; ( ! v63ax22) & & (!v63axl4) & & v63axl2 & & / / 14 ( ! v 6 3 a x ll) & & ( ! v63ax8) & & (!v63ax5) & & (!v63ax3) & & v63axlc -> v63ax25 := true; v63ax26 & & ((v63ax23 & & v63axlb) I I v63bx7) => / / 15 v63ax27 :* tr u e ; v63ax25 & & v63axl5 => v63ax28 := true; j ((v63axlb kk v63ax23) I I v63bx7) kk \ C(!v63ax26) kk v63ax29) => v63ax30 := true; i ( ! v63ax32) kk v63ax31 kk (!v63ax29) kk / / 18 (!v63ax26) kk v63ax23 kk v63axlb=> v63ax33 := true; H 16 / / 17 111 v63ax32 kk v63ax31 kk (!v63ax29) kk / / 19 (!v63ax26) kk v63ax23 kk v63axlb => v63ax35 := true; v63ax34b kk (!v63ax31) & & (!v63ax29) kk (!v63ax26) kk v63ax23 kk v63axlb => v63ax36 := true; / / 20 v63ax30 kk v63ax33 kk v63ax35 kk v63ax38 => 11 21 v63ax37 := t r u e ; v63ax34a kk (!v63ax31) kk (!v63ax29) kk / / 22 (!v63ax26) kk v63ax23 kk v63axlb => v63ax38 := true; v63ax36 => v63ax39 := true; / / 23 v63ax41 kk v63ax40 kk (!v63ax23) kk / / 24 v63axlb => v63ax42 := true; (!v63ax41) kk v63ax40 kk (!v63ax23) kk v63axlb => / / 25 v63ax43 := tr u e ; v63ax42 I I v63ax47 => v63ax44 := true; / / 26 v63ax46 kk v63ax45 kk (!v63ax40) kk (!v63ax23) kk v63axlb => v63ax47 := true; / / 27 v63ax46 kk v63ax45 kk v63bx8 => v63ax47 := true; / / 28 (* v63ax46) kk v63ax45 kk (!v63ax40) kk C!v63ax23) kk v63axlb => v63ax48 := true; f t 29 (!v63ax46) kk v63ax45 kk v63bx8 => v63ax48 := true; / / 30 v63ax49b kk (!v63ax45) kk (!v63ax40) kk (!v63ax23) kk v63axlb => v63ax50 := true; / / 31 v63ax49b kk (!v63ax45) kk v63bx8 => v63ax50 := true; / / 32 v63ax50 => v63ax51 := true; / / 33 v63ax49a kk (!v63ax45) kk (!v63ax40) kk / / 34 112 v63axlb => v63ax52 := true; v63bx8 => v63ax52 := true; / / 35 v63ax49a v63ax52 => v63ax53 := true; 36 113 R e fe r e n c e L ist [Asc75] [Bar85] [BB91] [BCDM86] [BCG88] [BCM+90] [BRB90] [Bro86] [Bro90] [Bry86] [Bry92] E.A. Aschcroft. Proving assertions about parallel program s. Journal o f Computing System s, 10:110 - 135, 1975. H. Barringer. Up and down the tem poral way. Technical Report UMCS-85-9-3, University of M anchester, 1985. A. Benveniste and G. Berry. The synchronous approach to reactive and real-tim e systems. Proceedings o f the IEEE, 79(9), 1991. M.C. Browne, E.M. Clarke, D.L. Dill, and B. M ishra. A utom atic veri fication of sequential circuits using tem poral logic. IE E E Transactions on Computers, C-35(12), 1986. M.C. Browne, E.M. Clarke, and O. Griimberg. C haracterizing finite Kripke structures in propositional tem poral logic. Theoretical Com puter Science, 59:115-131, 1988. J.R . Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, and L.J. Hwang. Symbolic model checking: 1020 states and beyond. In Fifth A nnual IE E E Symposium on Logic in Computer Science, 1990. K.S. Brace, R.L Rudell, and R.E. Bryant. Efficient im plem entation of a BDD package. In 27th A C M /IE E E Design A utom ation Conference, 1990. R.A. Brooks. A robust layered control system for a mobile robot. IE E E Journal o f Robotics and Automation, RA-2:12-23, 1986. R.A. Brooks. The behavior language; user’s guide. Technical R eport A.I. Memo 1227, M assachusetts Institute of Technology, 1990. R.E. Bryant. G raph-based algorithms for boolean function m anipula tion. IE E E Transactions on Computers, C-35(8), 1986. R.E. Bryant. Ordered binary-decision diagrams. A C M Computing Sur veys, 24(3), 1992. 114 [BS79] R. Bradley and N. Swartz. Possible Worlds: A n Introduction to Logic and its Philosophy. Hackett, Indianapolis, 1979. [BS92] [CBG+91] [CBM89] [CE81a] [CE81b] [Cer89] [CMB91] [DC90] [Dij76] [Dur79] [EH86] J. Bowen and V. Stavridou. Safety-critical system s, form al m ethods and standards. Technical Report PRG-TR-5-92, Program m ing Research Group, Oxford University, 1992. E.M . Clarke, J.R . Burch, O. Grumberg, D.E. Long, and K.L. McMillan. A utom atic verification of sequential circuit designs. In Proceedings of the Royal Society o f London, Oct. 1991. O. Coudert, C. B erthet, and J.C . M adre. Verification of synchronous sequential machines based on symbolic execution. In Lecture Notes in Computer Science: Autom atic Verification Methods fo r Finite State System s, volume 407, pages 365 - 373, 1989. E.M . Clarke and E.A. Emerson. Characterizing properties of parallel program s as fixpoints. In Lecture Notes in Computer Science: Seventh International Colloqium on Automata, Languages, and Programming, volume 85, 1981. E.M . Clarke and E.A. Emerson. Design and synthesis of synchroniza tion skeletons using branching tim e tem poral logic. In Lecture Notes in Computer Science: Proceedings o f the IB M Workshop on Logics o f Programs, volume 131, pages 52 - 71, 1981. P. Ceruzzi. Beyond the Lim its: Flight Enters the Computer Age. M IT Press, 1989. O. Coudert, J.C . M adre, and C. B erthet. Verifying tem poral proper ties of sequential machines without building their state diagram s. In D IM A C S Series in Discrete M athematics and Theoretical Computer Science, volume 3, pages 75 - 84, 1991. W .R. Dunn and L.D. Corliss. Software safety: A user’s practical perspective. Technical Report ARC-12710, N ational Aeronautics and Space A dm inistration, 1990. E.W . D ijkstra. A Discipline o f Programming. Prentice-Hall, 1976. J. Durbin. Modern Algebra: A n Introduction. John Wiley & Sons, New York, 1979. E. Emerson and J. Halpern. “Sometimes” and “Not Never” revisited: On branching versus linear tim e tem poral logic. Journal o f the AC M , 33(1), 1986. 115 [EMSS89] [End72] [Flo67] [For81] [Hal90] [Har82] [HC77] [Hel84] [HMS88] [HNSY92] [Hoa69] [JM88] [Kar88] E.A. Em erson, A.K. Mok, A.P. Sistla, and J. Srinivasan. Q uantitative tem poral reasoning. In Lecture Notes in Computer Science: Workshop on Autom atic Verification Methods fo r Finite State System s, volume 407, 1989. H. Enderton. A Mathematical Introduction to Logic. Academic Press, 1972. R.W . Floyd. Assigning meaning to program s. In Proceedings o f the Am erican M athematical Society Symposium on Applied M athem atics, volume 19, pages 19 - 31, 1967. C. L. Forgy. OPS5 user’s manual. Technical Report CMU-CS-81-135, Carnegie-Mellon University, 1981. R. Hale. Using tem poral logic for prototyping: The design of a lift controller. In H.S.M. Zedan, editor, Real-Tim e System s, Theory and Applications. Elsevier Science Publishers, 1990. P.K H arter Jr. On the Application o f Temporal Logic to the Verification o f Real-Tim e Programs. PhD thesis, D epartm ent of Com puter Science, SUNY, Stony Brook, 1982. G.E. Hughes and M .J. Creswell. A n Introduction to Modal Logic. M ethuen, London, 1977. J.J. Helly Jr. A Distributed Expert System fo r Space Shuttle Flight Control. PhD thesis, D epartm ent of C om puter Science, University of California, Los Angeles, 1984. K. Hay, S. M anchanda, and R. Schlichting. A tem poral logic for proving real-tim e properties of distributed program s. Technical Report T R 88- 40, University of Arizona, 1988. T.A. Henzinger, X. Nicollin, J. Sifakis, and S. Yovine. Symbolic model checking for real-tim e systems. In Proceedings Seventh A nnual IE E E Sym posium on Logic in Computer Science, 1992. C.A.R. Hoare. An axiomatic basis for com puter program m ing. Com- m uncations o f the AC M , 12(10), 1969. F. Jahanian and A. Mok. Formal specification of real-tim e systems. Technical R eport TR-88-25, University of Texas at Austin, 1988. K. Karplus. Representing boolean functions with If-Then-Else DAGs. Technical Report UCSC-CRL-88-28, University of California, Santa Cruz, 1988. 116 [Knu75] [Koy87] [Lam80] [Lee90] [Lev86] [LL92] [LS82] [McM92] [Mok89] [Mos86] [Mot 72] [OL82] [Pnu77] D.E. K nuth. The A rt o f Computer Programming: Fundamental Algo rithm s, volume 1. Addison-Wesley, New York, 1975. R. Koymans. Specifying message passing and real-tim e systems us ing real-tim e tem poral logic. In Proceedings 6th A C M Sym posium on Principles o f Distributed Computing, pages 191-203, 1987. L. Lam port. “Sometime” is sometimes “Not Never”—on the tem poral logic of programs. In Proceedings 7th A nnual A C M Sym posium on Principles o f Programming Languages, pages 174-185, 1980. C.C. Lee. Fuzzy logic in control systems: Fuzzy logic controller. IE E E Transactions on Systems, Man, and Cybernetics, 20(2):404-435, 1990. N.G. Leveson. Software safety: W hat, why, and how. A C M Computing Surveys, 18(2), 1986. H-T Liaw and C-S Lin. On the OBDD-representation of general boolean functions. IE E E Transactions on Computers, C-41(6), 1992. L. Lam port and F.B. Schneider. The ‘Hoare Logic’ of CSP, and all th a t. Technical Report T R 82-490, D epartm ent of Com puter Science, Cornell University, 1982. K.L. McMillan. Symbolic Model Checking. A n approach to the state explosion problem. PhD thesis, School of Com puter Science, Carnegie- Mellon University, 1992. A.K. Mok. Formal analysis of real-time equational rule-based systems. In Proceedings of the Real-Time System s Symposium, volume 10, pages 308-318, 1989. B. Moszkowski. Executing Temporal Logic Programs. Cam bridge Uni versity Press, Cambridge, 1986. J. M otil. Digital System s Fundamentals. McGraw-Hill, New York, 1972. S. Owicki and L. Lam port. Proving liveness properties of concurrent program s. A C M Transactions on Programming Languages and Sys tems, 4(3), 1982. A. Pnueli. The tem poral logic of programs. In Proceedings 18th Annual Sym posium on Foundations o f Computer Science, pages 46-57, 1977. 117 [Pnu89] A. Pnueli. Applications of tem poral logic to the specification and ver ification of reactive systems: A survey of current trends. In Lecture Notes in Computer Science: Current Trends in Concurrency, volume 224, pages 510 - 584, 1989. [Tar55] A. Tarski. A lattice-theoretical fixpoint theorem and its applications. Pacific Journal o f M athematics, 5:285-309, 1955. [WTW+91] C.-K. Wang, D.-C. Tsou, R.-H. Wang, J.C . Browne, and A.K. Mok. A utom ated analysis of bounded response tim e for two NASA expert systems. In Proceedings o f the A C M SIG SO F T ’91 Conference on Soft ware fo r Critical System s, pages 147-161, 1991. [Xil92] Xilinx, San Jose, California. The Programmable Gate Array Data Book, 1992. 118

Linked assets