New verification method for embedded systems

Cyber-physical systems, in which computers control real-world mechanisms, are ever more pervasive in our society. These complex systems, containing a mixture of software, digital hardware, and analog circuitry, are often employed in circumstances where their correct behavior is crucial to the safety of their operators. Therefore, verifi cation of such systems would be of great value. This dissertation introduces a modeling and veri fication methodology sufficiently powerful to manage the complications inherent in this mixeddiscipline design space.

A NEW VERIFICATION METHOD FOR EMBEDDED SYSTEMS by Robert A. Thacker A dissertation submitted to the faculty of The University of Utah in partial ful llment of the requirements for the degree of Doctor of Philosophy in Computer Science School of Computing The University of Utah December 2010 Copyright c Robert A. Thacker 2010 All Rights Reserved THE UNIVERSITY OF UTAH GRADUATE SCHOOL STATEMENT OF DISSERTATION APPROVAL The dissertation of Robert A. Thacker has been approved by the following supervisory committee members: Chris J. Myers , Chair 21 December, 2009 Date Approved Ganesh Gopalakrishnan , Member 21 December, 2009 Date Approved Eric G Mercer , Member 21 December, 2009 Date Approved John Regehr , Member 21 December, 2009 Date Approved Ken Stevens , Member 21 December, 2009 Date Approved and by Martin Berzins , chair of the School of Computing and by Charles A. Wight, Dean of The Graduate School ABSTRACT Cyber-physical systems, in which computers control real-world mechanisms, are ever more pervasive in our society. These complex systems, containing a mixture of software, digital hardware, and analog circuitry, are often employed in circumstances where their correct behavior is crucial to the safety of their operators. Therefore, veri cation of such systems would be of great value. This dissertation introduces a modeling and veri cation methodology su ciently powerful to manage the complications inherent in this mixed discipline design space. Labeled hybrid Petri nets (LHPNs) are a modeling formalism that has been shown to be useful for modeling analog/mixed signal systems. This dissertation presents an extended LHPN model capable of modeling complex computer systems. Speci cally, this extended model uses discrete valued variables to represent software variables. In addition, a rich expression syntax has been added to model the mathematical operations performed in computer processors. No formalism is useful if it remains inaccessible to designers. To facilitate the use of this model, a translation system is presented that enables the compilation of LHPNs from intermediate descriptions similar to assembly language. Users can create an LHPN construction language appropriate to each portion of their design. Once a model is de ned, it is necessary to determine the range of behaviors of that system. Speci cally, a determination must be made if the model exhibits any behaviors that violate the design constraints. To that end, this dissertation describes an e cient state space exploration method. This method uses state sets to represent the potentially in nite state spaces of LHPN models. Complex models often yield intractably large state spaces, resulting in unacceptably long runtimes and large memory requirements. It is, therefore, often necessary to distill from a model the information necessary to prove a particular property, while removing extraneous data. This dissertation presents a number of correctness preserving trans- formations that depend on simple, easily checked properties to reduce the complexity of LHPNs. These transformations alleviate the need to model variables, transitions, and places that do not contribute to correctness of the property under test. Finally, an in depth case study is used to demonstrate the utility of this method. Each step in the modeling and analysis process is applied in turn to this example, showing its progression from initial block diagram to nal veri ed implementation. iv To new sights, new places, and new opportunities. CONTENTS ABSTRACT : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : iii LIST OF FIGURES : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : viii LIST OF TABLES: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : xi LIST OF ALGORITHMS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : xii ACKNOWLEDGEMENTS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : xiii CHAPTERS 1. INTRODUCTION : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 1.1 Formal Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Hardware Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Software Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 System Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. LABELED HYBRID PETRI NETS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 LHPN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Semantics for Extended LHPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. SYSTEMS MODELING : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16 3.1 Language De nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Software Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Hardware Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4 Interrupt Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5 Environment Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4. VERIFICATION : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38 4.1 State Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2 State Space Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Error Trace Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5. LHPN TRANSFORMATIONS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47 5.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.3 Remove Arc After Failure Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.4 Removing Dead Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.5 Remove Dangling Places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.6 Remove Write Before Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.7 Substitute Correlated Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.8 Local Assignment Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.9 Remove Unread Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.10 Constant Enabling Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.11 Remove Vacuous Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.12 Remove Dominated Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.13 Remove Vacuous Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.14 Timing Bound Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.15 Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6. CASE STUDY : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 70 6.1 Motivating Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.2 Initial Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7. CONCLUSIONS AND FUTURE WORK : : : : : : : : : : : : : : : : : : : : : : : : 104 7.1 Dissertation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.1 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.2 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.4 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.2.5 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 APPENDIX: REACTOR INPUT FILES : : : : : : : : : : : : : : : : : : : : : : : : : : : : 107 REFERENCES : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 118 vii LIST OF FIGURES 2.1 Illustrative sample LHPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 BNF for language de nition les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Typical delimiter set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Sample LHPN macro de nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Sample branch command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 BNF for a process description le. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.6 Sample program and resulting LHPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7 De nition of a 6811 Load Accumulator B instruction. . . . . . . . . . . . . . . . . . 24 3.8 Sample branch de nitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.9 6811 ADCTL write instruction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.10 Sample subroutine call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11 6811 accumulator model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.12 Sample interrupt service mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.13 Precise interrupt handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.14 Sample multibranch structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.15 LHPN with concurrency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.16 Extended memory model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1 Remove arc after failure transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 Removing dead transitions/Removing dangling places. . . . . . . . . . . . . . . . . . 54 5.3 Remove write before write. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.4 Substituting correlated variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.5 Local assignment propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.6 Removing unread variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.7 Substituting constant enabling conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.8 Deleting unnecessary transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.9 Transition elimination abstraction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.10 Remove dominated transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.11 Remove vacuous loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.12 Timing bound normalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1 Fault tolerant cooling system for a nuclear reactor. . . . . . . . . . . . . . . . . . . . 71 6.2 Nuclear reactor environment model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.3 Part of the ADC circuitry model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.4 Nuclear reactor software model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.5 LHPN representing the nuclear reactor environment and ADC circuitry . . . 75 6.6 LHPN representing the nuclear reactor software initialization loop. . . . . . . . 76 6.7 LHPN representing the nuclear reactor software main loop. . . . . . . . . . . . . . 77 6.8 LHPN representing the nuclear reactor software stall loop. . . . . . . . . . . . . . 78 6.9 System stall loop (a) before and (b) after post failure transition removal. . . 79 6.10 System stall loop after (a) dead transition removal and (b) after dangling place removal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.11 Software initialization transitions initial model and after applying Transfor- mation 4 (write before write). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.12 Software model (a) initialization loop and (b) main loop after eliminating unread assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.13 Software initialization transitions before and after applying Transforma- tion 6 (local assignment propagation). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 6.14 Software initialization transitions after constant expression transformation. 84 6.15 Software model (a) initialization loop and (b) main loop after expression propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 6.16 Main software loop before and after expression propagation. . . . . . . . . . . . 86 6.17 ADC enabling transition before and after enabling condition transformation. 87 6.18 ADC enabling transition before and after correlated variable substitution . 87 6.19 Environment and ADC processes after correlated variable substitution. . . . . 88 6.20 Software process after correlated variable substitution. . . . . . . . . . . . . . . . . . 89 6.21 Candidate for vacuous transition removal before and after removing vacuous transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.22 Software process after vacuous transition removal. . . . . . . . . . . . . . . . . . . . . 91 6.23 Simpli ed environment and ADC processes. . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.24 Normalized environment and ADC processes. . . . . . . . . . . . . . . . . . . . . . . . . 93 6.25 Normalized software process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.26 Software process without initialization loop. . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.27 ADC processes with 9-bit ADC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.28 ADC processes with 64 clock cycle conversions. . . . . . . . . . . . . . . . . . . . . . . 99 ix 6.29 Fast environmental temperature slew. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.30 Fast environmental temperature slew, low precision ADC. . . . . . . . . . . . . . . 101 x LIST OF TABLES 6.1 Veri cation results for the reactor example. . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2 Changes in abstractions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 LIST OF ALGORITHMS 4.1 Semi-algorithm to nd the reachable states. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Algorithm to nd possible events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Algorithm to update the state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4 Algorithm to re a transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5 Algorithm for advancing time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1 Algorithm for transforming an LHPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ACKNOWLEDGEMENTS It has been a long trek, and even now it is di cult to believe it is coming to an end. Or perhaps it is better to say it is time to embark on a new stage of the journey. In either case, many people have helped me along the way, and deserve to be recognized. Dr. Chris Myers, my advisor, has earned my undying gratitude. Chris has been a great adviser and a good friend. I have bene ted greatly from his mentorship, endless support, and (nearly) in nite patience. The many fellow students who have shared the o ce/lab with me over the years have provided invaluable input into my research. We have also had some great conversations on politics, literature, and a million other topics. Thanks are due to my committee for their direction in my research. Special mention should be made of Dr. Eric Mercer, who also falls into the former o ce mate category. The Semiconductor Research Corporation has funded most of my graduate career. Many people there deserve my gratitude, but chief among them is Virginia Wiggins. Ginny has worked tirelessly to support me. She helped me get extensions when funding ran dry, and poked and prodded me to get done. My relationship with the U.S. Army has been ambivalent over the last few years. It has caused signi cant delays in my progression, but has also provided much needed diversion. (Not to mention endless opportunities for creative procrastination.) My fellow soldiers have cheered me on and supported my family in many di cult situations. Finally, my wife Kay has been at my side through many tough times. She is the greatest blessing in my life, and I couldn't have made it without her. Thank you for everything. CHAPTER 1 INTRODUCTION Cyber-physical systems, or systems in which computers interact with and control real world mechanisms, are a growing area of research. The subset known as Embedded systems have been aptly described as any computer your parents would not recognize as a computer. These small, often self-contained, computer systems pervade our society. For instance, model year 2001 cars contained between 20 and 80 microprocessors, controlling everything from running the engine to the brake system to the deployment of airbags [70]. Embedded systems are unavoidable, and increasingly are used in complex, safety-critical environments, where their failure can lead to serious injury or even death. It is crucial that such systems be thoroughly understood and function properly every time. While compact, embedded systems combine a variety of components. Low level software, digital hardware, and analog components all interact. Historically, these systems have used small processors and functioned without a complex operating system. Often their software has been small and written directly in assembly language. Today they are growing increasingly complex, often including elements such as wireless networking. Even though embedded software is now often written in C or other high level languages, access to low-level hardware features often requires embedded assembly code. The e ects of this low-level code need to be taken into account. Furthermore, constructs that appear atomic at the higher level become multiple distinct steps and introduce risky behavior once compiled into assembly. Compilers also often do not appropriately treat the low level constructs critical to the proper behavior of these systems [33]. Embedded systems also interact with external analog sensors and actuators. These analog components are usually modeled using di erential equations and very small time steps, rather than the Boolean mathematics and large time steps of digital models. Environmental variables need to be modelled using continuous variables to maintain enough delity. Due to the heterogeneous nature of embedded systems, traditional system testing is often insu cient 2 1.1 Formal Veri cation All computer systems designed today are subjected to a validation process. This is a directed system aimed at identifying speci c faults and demonstrating correct behavior under speci c, limited circumstances. During the design process, a set of test cases are assembled that are believed to exercise the important elements of system behavior. Before the system is fabricated, a number of simulation runs are conducted to nd design aws. All e orts are made to nd a reasonable set of test cases that cover the important conditions under which the system is expected to function. After manufacture, many of these same or similar test cases are used to ensure that the production system matches the design to nd manufacturing aws. The shortfall of this method is it can only nd aws that are exercised by the speci c set of test vectors chosen. Formal veri cation is the process of mathematically analyzing systems to determine their properties. This usually takes one of two forms, static analysis or model checking. Static analysis is the process of studying the structure of a system. Much can be determined from this process. For instance, this process can often tell that a particular branch of an if/then/else structure is never going to be taken, or that a particular wire never takes on a high value. Model checking [23] is more useful for determining the sequential behavior of a system. A representative model is created for the system. Since most systems are too large to analyze in toto, it is often necessary to abstract it. This means reducing it to a simpli ed form that is tractable. While abstracting, it is crucial to ensure that the new system displays all of the behaviors of the original system that are pertinent to the properties that need to be tested. Note that di erent properties may require a di erent abstraction. For example, trying to prove that a CPU talks to its memory block correctly requires quite a di erent model than when trying to prove it does math correctly. It is also possible to decompose the system into simpler subsystems. Often these smaller blocks are tractable for complete, exhaustive testing. Once an adder is proven to add correctly, it can be replaced with a simpler (abstracted) representation for testing of the overall system. Once an appropriate and tractable model has been developed, state space exploration is conducted. In a sense, the model is executed, nding all possible paths it can follow and all possible states it can enter. There are two general types of properties that can be checked. Safety properties test that a speci c undesired occurrence does not happen. Liveness properties specify 3 that desirable behavior happens eventually. Safety properties can be disproved with nite traces. Liveness properties are more complex because they require in nite traces to detect them. This requires detecting that a loop has been closed and that the loop violates the liveness property. State space exploration may be performed by either forward exploration or backward exploration. To conduct forward exploration, the system is rst seeded with the initial state or states of the system. Each possible successor state is then added to the set of reachable states. This process is repeated until no new states are found. This process produces the entire reachable state space of the system, which can then be exhaustively analyzed and compared against a number of properties. Alternatively, if only a single property is being checked, run time can potentially be shortened by continually testing new states and stopping as soon as a violating trace has been identi ed. To conduct backward exploration, the system is seeded with states violating the needed property, and all possible predecessor states are determined. This process is repeated until no new states are encountered or until the initial state is found. If the initial state is encountered, the system violates the property. If not, the system is known to be safe with respect to the given property. Backward analysis can only be applied to a single property, so if multiple properties are to be checked, this is not an appropriate method. Bounded model checking [18], an alternative version, limits the depth of state space exploration. Each possible branch is explored to a xed depth, then the system moves on to the next branch. The intuition is that if something bad is going to happen, it is likely to happen quickly. This method is generally only useful for proving safety properties. 1.2 Hardware Veri cation Hardware veri cation has been quite successful [19, 20, 23, 24, 27, 28, 47, 60]. One of the key areas of focus has been equivalence checking. Intuitively, this is the process of proving that two di erent representations of a system are functionally the same. This comparison is untimed, and looks for the two blocks to compute the same set of Boolean functions. Most commonly, this method is used to compare two di erent levels of synthesis, such as register transfer level (RTL) and layout. This is most useful to analyze the functional blocks within pipeline stages of a synchronous design. State machines, which perform processes in a sequential fashion, need to be analyzed with respect to their behavior over time. Model Checking is generally used to perform this 4 analysis [24, 45, 64]. Properties expressed in linear temporal logic (LTL) or computation tree logic (CTL) can be used to prove such things as \when a request is made, an acknowledgment is eventually given." LTL expresses properties of single linear traces, while CTL expresses properties of multiple branches of executions. This methodology has gained a lot of momentum in the industrial realm, and many commercial tools are available to perform this analysis. In analyzing some systems, it is not su cient to simply model what is the next possible step. These systems require the consideration of complex timing information. Speci cally, many asynchronous systems require this style of analysis to be proven correct. Timed CTL/LTL variants have been developed to allow speci c timing requirements to be speci ed. This allows the speci cation of \when a request is received, an acknowledgement comes in 3 ms," rather than just that the response arrives eventually. This methodology has made very little inroads into industry, and few commercial tools address these issues. However, a great many academic endeavors have focused on this topic [3, 13]. Many industrial research groups have recently focused their interest on analog/mixed signal (AMS) circuits. These hybrid systems are di cult to address because of the distinct nature of their subcomponents. Analog circuits are generally analyzed using SPICE, executing low level models of current and voltage with very ne time steps. Digital hardware, on the other hand, tends to be analyzed in large time steps, allowing analog and transient e ects to settle out so they can be discounted. Recent academic work [51, 35] shows promise in using formal methods to model and analyze these systems. 1.3 Software Veri cation Software is more di cult to analyze because of several factors [31]. Software inter- acts in complex fashions with other software, including increasingly complex operating systems. Software operating on large data sets can also result in state spaces that are astronomically complex. Abstract interpretation, the analysis of static properties of a program by pseudo-evaluation, has been used for some time. In [59], the authors analyzed Algol programs by propagating types through calculations, ensuring that all operands are of a valid type for the operations being performed. Cousot and Cousot [25] further concretized rules for deriving abstract models of computer programs. Clarke and Emerson [22] proposed applying model checking to synchronization skeletons, i.e. the control ow graph of a program. In [65], the authors derive an interpreted Petri net representing 5 key elements of the program, which is then subjected to model checking. Holzmann [38, 39] introduced SPIN, one of the earliest software model checking tools. Interestingly, some research has indicated that model checking and static analysis are functionally interchangeable [69, 71]. More recent work has applied a combination of aggressive abstraction with focused local re nement to analyze more complex models. A good example are the SLAM [12] and BLAST [36] projects. These systems focus on proving basic properties of device drivers, i.e. \this line of code is never executed". Abstraction is taken to the ultimate extreme: the system starts with only information about decision points and current location in the program. Counterexample guided abstraction re nement is then used to derive a tighter abstraction that eliminates false failures as they arise [10, 21, 48]. Another promising avenue has been leveraging simulation tools to perform veri cation [54]. In general, the process is to use a simulator to execute for a time period. At the end of that period, the system may choose to interject an interrupt or continue operation. As with all state space exploration systems, both paths are explored. The bene t of this method is that it can use existing technologies and can operate on the actual object code, not a representation of it. 1.4 System Veri cation System veri cation compounds the issues of hardware and software veri cation. Much like in AMS systems, verifying software and hardware together is complicated by the fact that both are modeled in vastly di erent ways. Software is usually modeled simply by tracking the order of events, and it is considered to be correct if key events occur in the proper order. Issues such as cache misses, disk reads, context swaps, and operating system calls make trying to model timing nearly impossible. Meshing that with hardware behavior, and throwing in external stimuli makes things even harder. Work in this area has generally been focused on hardware-software co-veri cation, an o shoot of hardware-software co-design [41]. These e orts focus on proving key temporal properties of systems where hardware and software are being designed in parallel, with an emphasis on nding the right balance between the two. There are a number of interesting projects in this area. In [42] the Uppaal system is used to check timed automata representing C-like control programs. In [46] the authors use model checking of executable code to determine the presence of worms. The authors 6 of [52] test C code for sensitivity to input variation. In [9] x86 executables are translated into a weighted pushdown system, which is then checked for reachability. Concurrent with our project, the author of [68] used the [mc]square to perform model checking on ELF format source les, checking them against CTL speci cations. In the future, it would be interesting to do an in depth comparison of the similarities and di erences between that project and our work. 1.5 Contributions The research embodied in this dissertation makes four signi cant contributions. The rst contribution is an extended labeled hybrid Petri net (LHPN) model, which has been formulated to be capable of representing complete embedded systems. The second is a synthesis method for constructing LHPN models from high-level descriptions. The third contribution is an automated simpli cation and abstraction methodology to reduce complex systems to a minimal representation capable of proving a particular property. Fourth, a method has been developed that facilitates exploration of the possibly in nite state spaces of these systems. Finally, an in depth case study is explored to demonstrate the usefulness of this method. LHPNs, which were originally developed to model AMS circuits, have been extended to handle the complexities of embedded computer systems. This dissertation develops a rich expression syntax, capable of representing the mathematical operations performed by microprocessors. In addition to Boolean and continuous variables, a new discrete data type is added, to re ect values found in memories and registers. The syntax and semantics of the original LHPN language are reformulated to adapt to the complexities of arbitrary expressions, and some (but not all) of the restrictions of the original language have been eased. This dissertation describes an automatic synthesis tool to generate LHPN level repre- sentations of assembly language programs. This tool is also capable of generating hard- ware and environmental models from an intermediate representation similar to assembly language. The user can de ne a small handful of primitives and leverage them to create complex LHPNs with just a few lines of code. This dissertation also presents a state space exploration method that handles the new complexities of extended LHPNs, including indeterminate values and range mathematics. This dissertation develops abstraction methods to reduce the size and complexity of 7 systems under analysis. Transforms have been created that reduce the number of variables under consideration as well as the number of places and transitions in the graph structure of the LHPN models. These transforms fall into two classes: simpli cations that maintain exact behavior while simplifying the LHPN structure and abstractions that conservatively approximate the behavior of the original LHPN. Finally, this set of methods is used to develop, encode, abstract, and analyze a model for a practical example. A temperature sensing module for a nuclear reactor is examined, and a set of design parameters is explored. 1.6 Organization This dissertation is organized as follows. First, Chapter 2 introduces the extended LHPN model. The syntax of the language is presented, including the complex expression language now supported. Restrictions are discussed as to when completely arbitrary expressions are not allowed. Semantics for the execution of an LHPN model are developed in this chapter. Chapter 3 presents a method and tool for representing embedded computer systems using LHPNs. A new intermediate format is presented in which systems can easily be described and understood. Methods are described to represent environments, analog and digital hardware, and assembly level software. Finally, the limitations of the system are discussed. Chapter 4 presents a method for representing the potentially in nite state spaces of LHPNs. State sets are de ned, as well as the semi-algorithm used for exploring them. Special attention is given to interval mathematics and the use of intervals to represent undetermined values. Chapter 5 discusses an automated abstraction process. The goal is to eliminate unnecessary state from the system. Two approaches are presented. First, simpli cations are applied to remove redundant information from the LHPNs. Second, conservative transformations are applied to the graphs to reduce the complexity to only that required to analyze the desired property. Chapter 6 presents a case study of a nuclear reactor control system and some veri - cation results from this system. Finally, Chapter 7 presents our conclusions and future plans. CHAPTER 2 LABELED HYBRID PETRI NETS The rst step in modeling an embedded system is to develop a modeling formalism su ciently expressive to represent all elements of the system. LHPNs have been shown to be useful for modeling AMS circuits [51, 76]. This dissertation expands this formalism to represent more complex systems. This chapter presents the expanded LHPN model. Section 2.1 discusses related work and possible alternate modeling approaches are then discussed. Section 2.2 presents the complete syntax for the new, extended LHPNs. Section 2.3 gives the semantics of this formalism. Finally, Section 2.4 presents a summary. 2.1 Related Work In order to apply model checking to embedded systems, it is necessary to develop a single model that is capable of representing both discrete software and continuous interface behavior. Automata and Petri nets (PNs) [61, 62] were developed to represent the behavior of sequential systems. The basic versions merely represent the present state and the possible next states reachable as a reaction to stimuli (input). Automata are represented by a set of symbols, a set of states, and a ow relation that indicates what state changes should be made in response to those symbols. Automata and PNs are useful, but the class of interesting systems that can be represented is limited. It is not always su cient to know that event x leads to event y. Often it is important to know the temporal relationship between the two. In other words, how long does it take after x for y to occur? Therefore, the next step is to introduce clocks into the analysis. Timed automata [2, 6] and time/timed Petri nets [55] (TPNs) include timing relationships on transitions. These allow complex systems to be analyzed to determine the timing relationships between events [8, 13, 63, 78, 17, 58, 77]. Timed automata and TPNs require all clock variables to progress at the same rate, and they do not allow a clock's progress to be stopped. To address systems with true continuous quantities, hybrid automata [3, 4, 7, 5] and hybrid Petri nets (HPNs) 9 [11, 26] have been proposed. Hybrid automata are quite expressive, but their use of invariants to ensure progress is a di cult compilation target, as it is not a natural way in which such systems are expressed in higher level languages such as VHDL-AMS and Verilog-AMS. Hybrid Petri nets use separate continuous places and transitions, making them also a di cult compilation target from high level languages. Recently, the labeled hybrid Petri net (LHPN) model has been developed and applied to the veri cation of analog and mixed-signal circuits [49, 51, 76]. This model is inspired by features found in both hybrid Petri nets and hybrid automata and includes both Boolean variables for representing digital circuits and continuous variables for representing analog circuits. Compilers have been developed from VHDL-AMS as well as SPICE simulation data [49, 50]. Model checking algorithms have been developed for LHPNs using both explicit zone-based methods [49, 51] as well as implicit BDD and SMT-based methods [75]. 2.2 LHPN Syntax This dissertation extends LHPNs to accurately model assembly language level embed- ded software. Namely, discrete integer values are added to represent register and memory values. An extended expression syntax for enabling conditions and assignments is also introduced to facilitate the manipulations of variables in the model. An LHPN is a tuple N = hP, T, Tf , B, X, V , , _V , F, L, M0, S0, Y0, Q0, R0i: P : is a nite set of places; T : is a nite set of transitions; Tf T : is a nite set of failure transitions; B : is a nite set of Boolean variables; X : is a nite set of discrete integer variables; V : is a nite set of continuous variables; : is a nite set of rate variables; _V : V ! is the mapping of variables to their rates; F (P T) [ (T P) is the ow relation; L : is a tuple of labels de ned below; M0 P is the set of initially marked places; S0 : B ! f0; 1; ?g is the initial value of each Boolean; 10 Y0 : X ! (Z [ f􀀀1g) (Z [ f1g) is the initial range of values for each discrete variable; Q0 : V ! (Q[f􀀀1g) (Q[f1g) is the initial range of values for each continuous variable; R0 : ! (Q [ f􀀀1g) (Q [ f1g) is the initial range of rates of change for each continuous variable. Figure 2.1 illustrates the elements of an LHPN. The places are the circles labeled p0, p1, and p2. The places p0 and p2 are initially marked, indicated by the token within the place. The transitions are the boxes labeled t0, t1, and t2. Transition t2 is a failure transition, as indicated by the dashed box. The ow relation, F, is represented in the gure by the arcs connecting the places and the transitions. This example has one Boolean variable, g, which is initially false. This example has one discrete variable, y, with an initial value of 14. Finally, this example has one continuous variable, x, which has an initial value of 5 and an initial rate of change of 1. Initial values: g:=false x:=5 dx/dt:=1 y:=14 p0 t0 {x≥9} [0,3] <g:=true,dx/dt:=-2> t1 {x≤3} [0,3] <x:=y+2> p1 p2 t2 {x≤-3} [0,0] <y:=(x*25)/2> Figure 2.1: Illustrative sample LHPN with three places, three transitions, and two processes. 11 A connected set of places and transitions in an LHPN is referred to as a process. Every transition t 2 T has a preset denoted by t = fp j (p; t) 2 Fg and a postset denoted by t = fp j (t; p) 2 Fg. Presets and postsets for places are de ned similarly. The functions T = S t2T t and T = S t2T t apply to sets of transitions. The set of all possible successor transitions reachable from a set of transitions T is de ned with the recursive function post(T ) = (T ) [ (post(T )). Similarly, pre(T ) = ( T ) [ (pre( T )) de nes the set of all possible predecessor transitions from which T may be reached. The recursive function proc(T ) = pre(T ) [ post(T ) [ proc(pre(T ) [ post(T )) returns the set of all transitions that are graphically connected to the elements in T . The LHPN in Figure 2.1 includes two processes. One consists of transitions t0 and t1, and the other consists of just transition t2. Before de ning the labels formally, let us rst introduce the grammar used by these labels. The numerical portion of the grammar is de ned as follows: ::= ci j 1 j xi j vi j v_i j ( ) j 􀀀 j + j 􀀀 j j = j ^ j % j NOT( ) j OR( ; ) j AND( ; ) j XOR( ; ) j INT( ) where ci is a rational constant from Q, xi is a discrete variable, and vi is a continuous variable. The function v_i returns the rate variable associated with the continuous variable vi. The functions NOT, OR, AND, and XOR are bit-wise logical operations, and they are only applicable to integers and assume a 2's complement format with arbitrary precision. The function INT converts a Boolean true value to an integer 1 and false value to an integer 0. The set P is de ned to be all formulas that can be constructed from the grammar. The Boolean part of the grammar is as follows: ::= true j false j bi j : j ^ j _ j BIT( ; ) j > j j = j j < where bi is a Boolean variable, :, ^; and _ are boolean negation, conjunction, and disjunction, and BIT( 1; 2) extracts bit 2 from 1.1 The usual set of relational operators ( ; >;=; <; and ) are included. The set P is de ned to be all formulas that can be constructed from the grammar. 1This is only de ned when the expressions 1 and 2 evaluate to integer values. 12 The analysis algorithm requires that enabling conditions be restricted to a subset of the and grammars. The numerical part of this restricted grammar, e, is de ned as follows: e ::= ci j xi j ( e) j 􀀀 e j e + e j e 􀀀 e j e e j e= e j e^ e j e% e j NOT( e) j OR( e; e) j AND( e; e) j XOR( e; e) This grammar does not allow continuous variables to be used, nor does it allow Boolean expressions to be converted into integers. The set P e is de ned to be all formulas that can be constructed from the e grammar. The Boolean part of this restricted grammar, e, is de ned as follows: e ::= true j false j bi j : e j e ^ e j e _ e j BIT( e; e) j e > e j e e j e = e j e e j e < e j vi e j vi e j The set P e is de ned to be all formulas that can be constructed from the e grammar. Intuitively, enabling conditions only allow continuous variables to appear on the left side of relations of the form vi e or vi e. This guarantees that the right side of these relations remains constant between transition rings as time advances. Each transition in an LHPN is labeled with an enabling condition as well as a set of assignments. These are formally de ned using the tuple L = hEn, D, BA, XA, VA, RAi: En : T ! P e labels each transition t 2 T with an enabling condition. D : T ! Q+ (Q+ [ f1g) labels each transition t 2 T with a lower and upper delay bound, [dl(t); du(t)]. BA : T B ! P labels each transition t 2 T and Boolean variable b 2 B with the Boolean assignment made to b when t res. XA : T X ! P labels each transition t 2 T and discrete variable x 2 X with the discrete variable assignment that is made to x when t res. VA : T V ! P labels each transition t 2 T and continuous variable v 2 V with the continuous variable assignment that is made to v when t res. RA : T ! P labels each transition t 2 T and continuous rate variable v_ 2 with the rate assignment that is made to v_ when t res. For convenience in de ning other functions, the set of all assignments, i.e. AA = BA [ XA [ V A [ RA, is de ned, as well as the set of all noncontinuous assignments SA = 13 BA [XA. Note that most assignments are vacuous (i.e. reassign the existing value) and are therefore not represented in the graphical representation. Formally, vacuous(t; v) , (AA(t; v) = (v)). Transition t0 from the rst process of Figure 2.1 has an enabling condition of fx > 9g. The delay of this transition varies form 0 to 3 time units. When t0 res, the rate of continuous variable x, dx=dt, is assigned to -2. The ring of transition t0 also assigns the Boolean variable g to true. The ring of transition t1 assigns the continuous variable x to the value of the expression y+2. The ring of t2 results in a discrete variable assignment to y that sets its value to the value of the expression (x 25)=2. Note that this assignment scales a continuous variable and assigns a truncated value to an integer. 2.3 Semantics for Extended LHPNs The state of an LHPN is de ned using a 7-tuple of the form = hM, S, Y , Q, R, I, Ci where: M P is the set of marked places; S : B ! f0; 1g is the value of each Boolean variable; Y : X ! Z is the value of each discrete variable; Q : V ! Q is the value of each continuous variable; R : V ! Q is the rate of each continuous variable; I : I ! f0; 1g is the value of each continuous inequality. C : T ! Q is the value of each transition clock. The set of continuous inequalities, I, consists of all subexpressions of the form vi ./ where ./ is or , and is a member of the set P e . In this example, this includes x 3, x 􀀀3 and x 9. These inequalities are treated in a unique way because their truth values can change due to time advancement. Maintaining this set is not strictly necessary for the semantics, but it is convenient in several de nitions and is used by the analysis method. The current state of an LHPN can change either by the ring of an enabled transition or by time advancement. A transition t 2 T is enabled when all of the places in its preset are marked (i.e. t M), and the enabling condition on t evaluates to true (i.e. Eval(En(t); ) where the function Eval evaluates an expression for a given state). The function E( ) is de ned to return the set of enabled transitions for the given state. 14 When a transition t becomes enabled, its clock is initialized to zero. The transition t can then re at any time after its clock satis es its lower delay bound and must re before it exceeds its upper delay bound (i.e. dl(t) C(t) du(t)) as long as it remains continuously enabled. A transition is disabled any time one of the places in its preset becomes unmarked or its enabling condition evaluates to false. This interpretation is referred to as disabling semantics. From a state , a new state 0 can be reached by ring a transition t found in E( ). This new state is determined as follows: M0 = (M 􀀀 t) [ t ; S0(bi) = Eval(BA(t; bi); ) Y 0(xi) = Eval(XA(t; xi); ) Q0(vi) = Eval(V A(t; vi); ) R0(vi) = Eval(RA(t; vi); ) I0(vi ./ ) = (Q0(vi) ./ Eval( ; )) C0(ti) = ( 0 if ti 62 E( ) ^ ti 2 E( 0) C(ti) otherwise In other words, the marking is updated, Boolean, discrete, continuous value, and contin- uous rate assignments associated with transition t are executed, the state of the contin- uous inequalities are updated, and the clocks associated with newly enabled transitions are reset to 0. For the assignments that return ranges, a random value is chosen by Eval(AA(t; v); ) from within the range of acceptable values as speci ed by the lower and upper bound. In a state , time can advance by any value that is less than max( ). The value of max( ) is the largest amount of time that may pass before a transition is forced to re (i.e. the clock associated with it exceeds its upper bound) or an inequality changes value (i.e. for an inequality of the form vi , its continuous variable's value, vi, crosses the value returned by its expression, ). This is de ned as follows: max( ) = min ( du(ti) 􀀀 C(ti) 8ti 2 E( ) Eval( ; )􀀀Q(vi) R(vi) 8(vi )2I: I(vi )6=(R(vi) 0) The new state, 0, after time units have advanced is de ned as follows: Q0(vi) = Q(vi) + R(vi) 15 I0(vi ./ ) = ( R(vi) ./ 0 if Q0(vi) = Eval( ; ) I(vi ./ ) otherwise C0(ti) = ( 0 if ti 62 E( ) ^ ti 2 E( 0) C(ti) + otherwise To illustrate LHPN semantics, consider a few states for the example in Figure 2.1. In the initial state, p0 and p2 are marked; g is false; y has a value of 14; x has a value of 5 and is changing at a rate of 1. In this state, no transitions are enabled. Note that t0 is guarded by the Boolean expression fx 9g and t2 by fx 􀀀3g, neither of which is satis ed in the initial state. The rst event that can occur is advancing time, and the maximum time advancement max = 4. At that point, fx 9g becomes true. Transition t0 is now marked and Boolean enabled. Clock C(t0) is set to zero. Because the timing bounds on transition t0 are [0,3], it is now time enabled, and the next event that can happen in the system is for t0 to re. Transition t0 can re instantly, or in up to three time units. When transition t0 res, g is set to true, x is set to a rate of -2, and the marking is moved from p0 to p1. In this new state, p1 is marked, but not Boolean enabled. The next possible event is for time to advance. Because x can have a value anywhere between 9 and 12, It can take anywhere from 3 to 5 time units for fx 3g to become true. When that happens, transition t1 res instantly, setting x to a value of 16. The right process is a watchdog. If at any time the value of x drops below -3 for ve time units or more, transition t2 res, terminating execution. 2.4 Summary This chapter presents an LHPN formalism for analysis of embedded systems. This model includes integer variables, as well as numerical and Boolean expressions. This method provides the ability to model all aspects of an embedded system, including performing the mathematical and logical operations found in modern microcontrollers. Chapter 3 discusses a compilation system designed to make this formalism accessible to designers. CHAPTER 3 SYSTEMS MODELING Chapter 2 introduced a formalism su ciently powerful to model a complete embedded system. This formalism is, however, of little use if designers need an intimate knowledge of the underlying formalism to create models. It is especially cumbersome to hand generate models for complex systems. This chapter therefore introduces a compilation system to generate models from an intermediate form that should be comfortable for designers to use. This system allows a language to be de ned, similar in syntax to assembly language, to de ne each part of the design. The formal structure for this language is described in Section 3.1. Modeling complete systems is di cult because they are not monolithic entities. Each subsystem has its own complexities and core properties that are key to properly repre- senting its behavior. Embedded systems can be thought of as posing three essential modeling challenges: the software, the hardware (both analog and digital), and the environment. We have developed methods to represent each of these components us- ing LHPNs. Section 3.2 describes a suggested modeling schema for assembly language software. Section 3.3 describes a schema for modeling electronic hardware. Section 3.4 discusses methods for modeling interrupts. Section 3.5 describes a schema for describing the operating environment for the embedded system. 3.1 Language De nition The assembly language abstraction is a useful method of describing systems. A simple command (mnemonic) along with a set of arguments can be used to represent a complex action. In this way, a simple set of primitive commands can be rapidly formed into a more elaborate system. Allowing the user to de ne their own language provides a highly customizable environment and allows for great precision in the description of the system. This section explains the format for de ning LHPN construction languages. First, the structure of the language is explained. Example instructions are then shown. 17 The structure of program les is then discussed, followed by the presentation of a sample program. Finally, a discussion of variable typing is presented. Figure 3.1 describes the Backus-Naur form (BNF) for language de nitions to be used with this system. Each command de nes a parametrized Petri net fragment with a single initial place. An arbitrary number of transitions can branch from that place. Each transition can be followed by any number of transition/place pairs. A target must be designated for each of the hanging transitions. Parameters are pre xed with '@' and are replaced at compile time by user provided arguments. The parameter \@next" is a reserved word representing the initial place of the following command. The keyword \@ rst" is also reserved, indicating the rst place in a net de nition. The user may de ne an arbitrarily complex set of delimiters to separate the arguments to the commands. Figure 3.2 shows an example set of delimiters used in an assembly language := delimiters commands | delimiters MERGE CODE commands delimiters := CHAR | delimiters CHAR commands := OPCODE args decls legs args := ARG arg rest | delimiters ARG arg rest | ARG arg rest delimiters | delimiters ARG arg rest delimiters arg rest := | arg rest delimiters ARG decls := type vars type := '#i' | '#b' | '#r' vars := VAR | vars VAR legs := LABEL TARGET transitions transitions := transition |transitions transition transition: = delay bounds '<' '>' | delay bounds '<' assigns '>' delay := 'fg' | 'f' EXPR 'g' bounds := '[' EXPR ',' EXPR ']' assigns := assign | assigns assign assign := assigntype VAR ':=' EXPR assigntype := | '#b' | '#r' Figure 3.1: BNF for language de nitions. 18 //delimiters #,+nt-n [] //merge code NO TRANS Figure 3.2: Typical delimiters used in an assembly de nition le. de nition le. The only restriction is that none of the characters chosen as delimiters may appear in an argument, as this would cause the argument to be split and recognized as two separate arguments. (The translation tool does not parse or evaluate expressions.) In order to match at compilation time, the number of arguments must match, as well as the delimiters used to separate them. Two arguments separated by a comma, for instance, are not the same as two arguments separated by white space. Again, arguments that are meant as placeholders must start with \@". All other arguments are matched literally. Figure 3.3 shows an example of a command, \set val", which serves to make a value assignment to a single LHPN variable. This command takes ve arguments and has one transition. The rst argument, \@1", is the enabling condition for the transition. The argument \@2" is the variable to be set, and argument \@3" is the expression that it is to be set to. The arguments \@4" and \@5" are the timing bounds. Note that argument \@2" is de ned to be of type \#i". This can mean that the variable is either a discrete or continuous variable. Figure 3.4 shows an example of a command with more than one transition. Argument \@1" is the enabling condition for the \BRANCH" transition. Argument \@2" is the label for the place target that this transition links. Arguments \@3" and \@4" are the timing bounds for this transition. The \NO BRANCH" transition is enabled by the complement of \@1". Arguments \@5" and \@6" are the timing bounds for this transition. Although not shown, a transition can be followed by an arbitrary number of transitions. The BNF for a \program" written using such a language is shown in Figure 3.5. Once the user has identi ed what language de nition is to be used to expand the commands, they de ne the system by describing the macros to be used and their relation to each other. The inspiration for this method was the structure of assembly language programs. However, descriptions of the environment and hardware may be more appropriately bethought of as a netlist. 19 set val // enabling:variable:value:time bounds @1 @2 @3 @4 @5 #i @2 NO BRANCH @next @1 [@4,@5] < @2 := @3 > @next f@1g [@4; @5] h@2 := @3i Figure 3.3: Sample macro de nition and matching LHPN fragment for an assembly language instruction. Figure 3.6 shows an example of a simple description using the example.inst le (see Appendix A) and the resulting LHPN. Note the use of the univ pred command, a prede ned system command that conjuncts its parameter with every enabling condition in the process. In order to avoid having to declare an excessive variety of commands, an optional merge code can be included in language de nitions. When this value is passed as the enabling condition parameter to any command, it squashes that command into the preceding transition. This allows a small number of primitive instructions to describe a variety of complicated transitions. For instance, the user does not need to de ne a separate command to make a continuous variable assignment and one to set the value in parallel with the rate assignment. Once a command that makes a single assignment is 20 //conditional branch different times iff @1 @2 @3 @4 @5 @6 NO BRANCH @next f~(@1)g [@3,@4] < > BRANCH @2 f@1g [@5,@6] < > [@3,@4] @next t1 f@1g [@5,@6] @2 i0 f:(@1)g t0 Figure 3.4: Sample macro de nition and matching LHPN fragment for a branching command. 21 program := library commands library := 'include' PATH commands := OPCODE args | LABEL OPCODE args args := ARG arg rest | delimiters ARG arg rest | ARG arg rest delimiters | delimiters ARG arg rest delimiters arg rest := | arg rest delimiters ARG Figure 3.5: BNF for a process description le. include <example.inst> univ pred ~fail start set val true x 45 10 12 set rate NO TRANS x 2 0 0 set sig x>100 d true 10 20 set val NO TRANS g 7 10 20 link start hx := 45; x0dot := 2i i0 t1 f:fail ^ (x > 100)g [10,20] hd := true; g := 7i start f:failg t0 [10,12] Figure 3.6: Sample assembly program and resulting LHPN. 22 de ned, it can be merged with one or more others (or copies of itself) to make the more complex transitions. This construction is demonstrated in Figure 3.6. Transition t0 is the product of merging the set val and set rate instructions. Because there is no separate variable declaration section, each command is expected to take ownership of and declare some portion of the variables it uses. It is acceptable for variables to be declared more than once in a program, as they are assembled in a nonduplicating fashion into a nal list. The convention that has been followed in the examples shown in this dissertation is that each instruction declares only the variables that it assigns. This keeps the declared set of variables at a minimum. Three types of variables are recognized by the system. Variables declared as type \#b" are boolean variables. Declaration as type \#i" indicates a numerical variable that can be either discrete or continuous. In the examples used here, any command that sets a numerical value will de ne its parameter in this fashion. If a variable is declared as type \#r", it is a continuous variable. In the examples, this is used in rate assignments. This has the e ect of declaring a variable as continuous if and only if it has a rate assignment. In Figure 3.6 , the set val instruction tags x as a numerical variable, and the set rate instruction further clari es that it is a continuous variable. The variable g, which has no rate assignment, is implicitly declared to be discrete. 3.2 Software Modeling Modeling straight-line software is relatively simple because it is essentially a sequential set of instructions. However, there are several issues that arise that require careful analysis and handling. This section explores these issues in depth. The rst topic presented is the modeling of individual instructions and their composition into LHPNs representing straight-line code. A method for representing function calls is then presented. Finally, methods for managing program threads are discussed. One goal of this work is to be able to annotate assembly language les while keeping them compilable. In this way, analysis can be conducted on the same les that are assembled and executed in the live system. In order to accomplish this, it is necessary to code veri cation speci c commands embedded in assembly language les in such a way that they do not interfere with the normal compilation process. Most assemblers use \;" as the comment tag. Therefore, embedded commands are tagged with \;@" so they can be ignored by the assembler, but executed by the LHPN compiler. The translation 23 system simply strips these leading characters o and processes the line like any other. Individual instructions can be complex because many instructions have a large side e ect set. Some instructions, in fact, may not even perform the obvious, expected behavior. In the 6811/12 family, for instance, write instructions to several parts of the control register set do not change the value, but start a subsystem on a compute cycle. Some bits are not writable, so although the value changes, it is not exactly the value written. Some are unusual combinations: the ADC control register has bits that never change, some that are cleared by a write, regardless of the value written, and any write starts a new sample cycle, regardless of the current state of the previous cycle. Simple declarative commands are relatively straightforward. Each instruction directly a ects its operand, in addition to potentially a ecting the processor condition codes. The only complication is ensuring that all of the side e ects of the instruction are accounted for. Figure 3.7 shows an immediate load instruction. This instruction takes a single argument, which must be preceded by a \#" in order to match this production. That argument is loaded into the accumulator regB. Note that the BOUND construct is a method to indicate what the limitations on the operand are. At this point, it is supported for parsing but has no a ect on compilation. This instruction a ects the negative (ccrN), over ow (ccrV ), and zero (ccrZ) condition bits. The three condition codes are declared as Boolean variables, and the accumulator is declared as a discrete variable. This instruction has one transition, labeled \NO BRANCH", which connects to the following instruction in the program. The delay of this instruction is exactly one clock cycle. The assignment set assigns the constant value to regB. The condition code ccrN is set if bit 7 of the constant is set. The condition code ccrV is cleared because a load cannot result in an over ow. The condition code ccrZ is set if the constant being loaded is zero. Unconditional branches are modeled the same as declarative statements. Their only (side) e ect is to change control ow and reset the PC. This is modeled by connecting the graph to the target instruction, rather than directly representing a PC. This saves the state of an additional 16-bit variable. Conditional branches are only slightly more complicated. They are represented as two transitions with complementary enabling con- ditions. The \false" transition links to the following command, and the \true" transition links to the branch target. Figure 3.8 shows an example of both an unconditional and a conditional branch. The BRA instruction is an unconditional branch. It takes a single argument, which is the label of the instruction to branch to. This instruction takes exactly 24 //immediate LDAB #@1 @1 BOUND -128 255 #b ccrN ccrV ccrZ #i regB NO BRANCH @next [1,1] < regB:=@1 #b ccrN:=bit(@1,7) #b ccrZ:=(@1=0) #b ccrV:=FALSE > @next t0 [1,1] i0 hregB := @1; ccrN := bit(@1; 7); ccrV := false; ccrZ := (@1 = 0)i Figure 3.7: De nition of a 6811 Load Accumulator B instruction. 3 clock cycles to execute. The BEQ instruction is an unconditional branch. Based on the value of the ccrZ condition code, it either takes one clock cycle to fall through to the next instruction or takes three cycles to branch to the location speci ed by argument \@1". As mentioned before, in a microcontroller, not every command has the expected be- havior. Often writes to system memory locations are used to initiate operations, without changing the values in the register. The ADCTL register of the 6811 microcontroller is a good example. As shown in Figure 3.9, a write starts a conversion cycle, and clears bit 7, which is then asynchronously set to indicate the cycle is complete. Bit 6 is always 0. Bits 5-0 indicate the kind of conversion to be performed, and are written like any other memory location. A read from this location returns the current values, without any unusual side 25 BRA @1 BRANCH @1 fg [3,3] < > BEQ @1 #b ccrZ BRANCH @1 fccrZg [3,3] < > NO BRANCH @next f~(ccrZ)g [1,1] < > (a) [3,3] @1 b2 (b) t0 [3,3] @1 b1 t2 f:(ccrZ)g [1,1] @next t1 fccrZg Figure 3.8: Sample de nitions for (a) an unconditional branch and (b) a conditional branch. 26 @next adc cd := and(regb; 8); adc mult := and(regb; 16); adc scan := and(regb; 32); ccrN := (and(regB; 128) = 128); ccrV := false; ccrZ := (regB = 0)i i0 [3,3] hadc ca := and(regb; 1); adc cb := and(regb; 2); adc cc := and(regb; 4); adc ccf := false; Figure 3.9: Sample LHPN for a 6811 ADCTL write instruction. This instruction sets a series of control bits, rather than a traditional register value. e ects. The compilation system allows a number of di erent forms of a command, and speci c names always take precedence over placeholders. So, if a STAB @1 command and a STAB ADCTL command are both de ned, a STAB ADCTL assembly instruction always matches the latter. One distinguishing feature of software systems is the passing of control between subroutines. Although there is only one active point of control at any given time, control can be passed between unconnected portions of the code. This is modeled by passing control with a handshake using a single Boolean variable. A predicate foo 1 is used to control the execution of the function foo. The subroutine call sets the variable true, then waits on it becoming false. The subroutine, on the other hand, waits for the variable to become true, executes once through, and sets the variable false. The subroutine is assumed to have a single point of entry. This model is shown in Figure 3.10. Note that the RTS instruction links back to the top of the subroutine. In the actual system there is no such branch, because this is a snippet of straight line code, rather than a loop. Because the system is being represented by a Petri net, the token must be returned to the initial place if the subroutine is to be executed again. 27 MAIN BSR FOO ... BRA MAIN FOO ... RTS main t0 [3,3] <foo_1:=true> t2 p0 [3,3] t1 {¬foo_1} [0,0] ... i0 foo t3 {foo_1} [0,0] ... i1 t4 [0,0] <foo_1:=false> Figure 3.10: Sample LHPN construction to service a subroutine call. The left process models the main software loop, while the right process models the subroutine. 28 3.3 Hardware Modeling This section discusses a proposed methodology for representing a microcontroller and associated electronic hardware, as well as some of the choices made in creating that model. Part of the challenge of modeling computer hardware is in knowing how much to represent. It is possible to explicitly model each operational unit, passing values through an explicit bus. However, the primary purpose is not to prove the functionality of the microcontroller, so much of its internal behavior can be abstracted. Registers, accumulators, and memory locations can be represented by discrete variables. The arithmetic logic unit (ALU) can be implicitly represented by mathematical functions embedded in variable assignments. One salient feature of embedded systems is the need to read sensors, which often deliver their data as an analog voltage. Most microcontrollers contain an ADC, which converts that voltage to a discrete value. Again, instead of modeling the actual circuitry, the functionality can be encapsulated in an expression that performs the same calculation. The ability to combine discrete and continuous variables makes this simple. Microprocessors also frequently refer to the same piece of memory using di erent names. In the 6811/12 family, for instance, there are two 8 bit accumulators, A and B. These locations also form a 16 bit register, D, as shown in Figure 3.11. This relationship can be explicitly represented; however, this requires three variables. In addition, the D register needs to be updated each time the A and B registers are reassigned, and vice versa. This requires a great deal of excess computation. Intuitively, most of the time the user is likely to be doing 8-bit computation, with an occasional 16-bit calculation. The user can therefore choose to use two 8 bit values, and concatenate them together when the 16 bit value is needed. This is much more e cient. Alternatively, if the user knows that predominantly they use 16-bit math, the model can be adapted to perform most calculations on the D register. Values for the A and B registers can then be stripped out as necessary. 7 0 7 B 0 A 0 15 D Figure 3.11: The 6811 accumulator set consists of two 8-bit accumulators, A and B, which are concatenated together as D when 16-bit values (such as memory addresses) are manipulated. 29 3.4 Interrupt Modeling For many reasons, microcontroller based systems may need to switch between func- tional threads. For example, the system may need to process an asynchronous input or perform a time sensitive operation. All modern processors have an interrupt method to manage this process. This section discusses methods of interrupt control and task switching, as well as managing the e ects of interrupts on individual instructions. In [32], the author discusses several methods of modeling exceptional control ow, or interrupt handling. The environment used is the Bogor [66] framework, where each node in the control ow graph represents a complete instruction. The author's preferred method is to augment the tool with a \listener" function. After the execution of each instruction, a helper function decides the next instruction to execute and manipulates the exploration system to cause the correct behavior. While this provides for e cient software veri cation, the Bogor framework is a traditional event-based model checker, and does not seem to include support for the rich environmental descriptions possible with LHPNs. Let us therefore consider possible methods of managing interrupts within the LHPN formalism. An interrupt service routine (ISR) can be modeled in much the same fashion as earlier described for subroutines. However, an interrupt can be initiated independent of the current program ow. Servicing an interrupt can be sandwiched in between any pair of instructions. Since there is no de ned start point, every instruction that has the capacity to be interrupted has to be guarded by a predicate. To accomplish this, a predicate is de ned for each thread, including each ISR. Each transition in the main function is predicated on the variable main thr, and the ISR is guarded with ISR i. If any thread calls a subroutine, a copy of that subroutine must be created that is guarded by the predicate for that thread. The compilation system contains a pragma, univ pred, which can be used to conjunct a Boolean term with all existing enabling conditions. This command indicates that an entire process should be guarded by the Boolean expression used as its argument, conjuncted with whatever enabling expressions the individual commands may already have. In this fashion, each thread has a single variable indicating that control of the processor. A system with multiple threads, or multiple causes of interrupts, needs a centralized thread control process. This process needs to receive interrupt causing inputs and decide which pending interrupt has priority. It passes control between individual threads by 30 performing a handshake, setting and clearing thread predicates. Figure 3.12 shows a sample main program thread and interrupt service manager designed to manage two threads. The expression irqi encapsulates all of the conditions necessary to cause an interrupt to happen, such as an interrupt enabling code and an external input. Once that expression is satis ed, the control process revokes control from the main thread by clearing main thr and setting the permission bit for the appropriate ISR. Each ISR should terminate with a return from interrupt (RTI) command. This is modeled in a similar fashion to an RTS command. The token is returned to the rst instruction, resetting the ability of the ISR to be executed. In addition, the ISRi predicate is cleared, returning control to the interrupt control process. Microcontrollers often include a software interrupt (SWI) instruction. This command functions similar to a BSR call, except that it takes no argument and allows the interrupt system to decide what ISR is executed. There are a variety of models for what happens to the current instruction when an MAIN ... BRA MAIN main ... t1 {main_thr} [3,3] i0 foo {irq1} [12,12] <main_thr:=false,isr_1:=true> {irq2∧¬irq1} [12,12] <main_thr:=false,isr_2:=true> i1 {¬isr_1} [0,0] <main_thr:=true> i1 {¬isr_2} [0,0] <main_thr:=true> Figure 3.12: Sample interrupt service mechanism. The left process represents the main thread. The right process models an arbitration system that manages two con icting interrupts, irq1 and irq2. Note that irq1 has higher priority. Each of the interrupt service routines would be modeled exactly as the previously shown subroutine. 31 interrupt arrives. Some machines drop the current instruction to start the service routine, then restart the instruction when they come back. This is managed automatically in the LHPN methodology. When the enabling for the current instruction is removed by clearing the thread predicate, it automatically rolls back to the start of that instruction. Some machines have a slightly di erent model, and nish the current instruction and then jump to the service routine. When completed, they return to the following instruction. The 6811/12 is an example of this. Properly modeling this process requires adding additional places to each instruction. Each instruction would have to be able to perform a 4-phase handshake with the interrupt mechanism. This would require two predicates: interrupt requested and interrupt forbidden. Each instruction would need at least two transitions. The rst would be guarded on the interrupt requested ag, and could not start if an interrupt is pending. It would also set the interrupt forbidden bit, preventing an interrupt from initiating during the course of the instruction. The last transition would clear the interrupt forbidden bit. This creates a small window between each instruction that allows an interrupt to slip in. The interrupt system would need to raise the interrupt requested ag, then wait for interrupt forbidden to become false. It could then execute the interrupt handler code, and nally drop the interrupt requested bit, allowing the following instruction to execute. An example using this model is shown in Figure 3.13 This is a heavy burden, and there is a simpler alternative. Because the interrupt is an asynchronous event, it is probably not important which instruction it follows. If the disabling semantics are used to model the instruction squashing semantics, the interrupt system can be allowed to have a delay of [0,8] before clearing the main thr bit. Because the longest instruction in the 6811/12 instruction set takes 7 cycles, this allows the interrupt to occur both before and after the current instruction. (Indeed, it could possibly even occur after one or two more instructions.) This is an encapsulating behavior: the interrupt occurs in at least the right place. It introduces the possibility of a false failure if the property under test fails because the interrupt occurred in one of these other places. It is unlikely that a speci cation so sensitive it does not succeed if an asynchronous event is o by one instruction is going to work anyway. However, it captures all valid failures. 32 MAIN ... BRA MAIN main ... i0 {¬irq_req} [0,0] <irq_forb:=true> P5 t1 [3,3] <irq_forb:=false> foo {irq1} [0,0] <irq_req:=true> {irq2∧¬irq1} [0,0] <irq_req:=true> i1 {¬irq_forb} [12,12] <isr_1:=true> i1 {¬isr_1} [0,0] <irq_req:=false> i1 {¬irq_forb} [12,12] <isr_2:=true> i1 {¬isr_2} [0,0] <irq_req:=false> Figure 3.13: Precise interrupt handling mechanism. Each instruction of the main thread is prevented from initiating by the irq req signal. The interrupt service mechanism, on the other hand, cannot initiate an interrupt handler until the irq forb signal has been released. 33 3.5 Environment Modeling The environment tends to be much more diverse in the kinds of stimulus it can provide. Often there are a large number of choices that can be made from a given control point. This can be cumbersome to model with a simple if-then-else structure. The compilation system does allow the construction of commands that have an arbitrary number of branch targets, but creating a large body of instructions can be daunting. However, there is an alternate method. Places in the LHPNs are de ned by the labels de ned in the system de nition les. If multiple instructions are tagged with the same label, they represent di erent control paths starting from the same initial point. This can be done without de ning any kind of branch instruction at all. There is no need to ensure that the enabling conditions are mutually exclusive. In simulation, an arbitrary choice is made between overlapping enablings. In a veri cation run, both options are taken in separate traces. An example of such a structure is shown in Figure 3.14. Environmental values that need to be modeled, such as temperature, speed, etc. can be represented by continuous variables. Although di erential equations cannot be used to de ne the values of these variables, they can usually be de ned in a piecewise fashion. A net structure is built that de nes the circumstances under which the rate of the variable changes, and the new value it takes on. 3.6 Limitations This chapter presents a method for compiling LHPNs from high level, easily un- derstandable descriptions. It also proposes a model for representing embedded systems using this method. While this system is su cient for many purposes, it has a number of limitations. Simplifying assumptions were made as to the type of programs to be veri ed. Many of these were derived from [40], where the author lays out guidelines for acceptable practices for writing safety critical software. This section discusses several of these limitations, as well as possible ways to overcome many of them. One drawback of the system at present is that there is no equivalent of the continuous assignment features of Verilog and VHDL. If a relationship can be reduced to a linear rate of change, it can be modeled using a continuous variable. Otherwise, a net must be constructed to represent the circuit model in a piecewise fashion. As implemented, this system only generates a subset of LHPN behavior. Speci cally, only nets where each transition has a single place in both its preset and postset are 34 e start set rate temp<=2200 temp 2 3 5 dr rod set rate temp>=9800 temp -2 3 5 link e start dr rod set rate temp>=9800 temp -1 3 5 link e start [3; 5] < temp0dot := 2 > dr rod t1 f:shutdown ^ (temp >= 9800)g [3; 5] < temp0dot := 􀀀2 > e start t2 f:shutdown ^ (temp >= 9800)g [3; 5] < temp0dot := 􀀀1 > t0 f:shutdown ^ (temp <= 2200)g Figure 3.14: Sample multi-branch structure. Note that all instructions given the same label (e.g. dr rod) will initiate from the same LHPN place. This structure allows the creation of arbitrary branching structures without needlessly complicating the macro de nition language. 35 created. This impacts the kinds of concurrency that can be described. Consider the LHPN shown in Figure 3.15(a). The ring of transition t0 marks both places p1 and p2, allowing transitions t1 and t2 to re in parallel. This structure cannot be generated by the compilation system. However, the same behavior can be generated using the structure in Figure 3.15(b). Note that an additional Boolean variable is required to achieve this. In developing the software model presented in this chapter, a simplifying assumption is made that all memory accesses are made to named variables. Any signi cant system, however, needs more free form memory access. Computer memories are best modeled as arrays. Unfortunately, the LEMA system does not support arrays as a data type, which needs to be corrected in the future. However, a generalized memory model can be represented by the structure shown in Figure 3.16(a). This process models a system with two memory locations, but it can be expanded to an arbitrary size. Note that no matter the size of the memory, only one place and two transitions are required. The set p0 t0 {En(t0)} [0,3] p1 p2 t1 {En(t1)} [0,3] t2 {En(t2)} [0,3] (a) p0 t0 {En(t0)} [0,3] <mark_p2:=true> p1 t1 {En(t1)} [0,3] p2 t2 {En(t2)∧mark_p2} [0,3] <mark_p2:=false> (b) Figure 3.15: An example of an LHPN with concurrency (a) in a form not supported by this modeling formalism and (b) equivalent functionality using Boolean signals. 36 of assignments on the write transition and the number of terms in the read assignment grow linearly with the size of the memory. Figure 3.16(b) shows a read instruction to read the contents of memory address foo and store that value in the variable bar. Note that this method includes explicit address and data buses. Also shown is a write instruction which stores the value of variable bar to memory address foo. Another assumption made was that all jumps would be made to predetermined ad- dresses. This allows the program counter (PC) to be implicitly represented. Register mem {mem_w} [0,0] <mem_w:=false, mem_1:=INT(addr=1)*data+INT(!(addr=1))*mem_1, mem_2:=INT(addr=2)*data+INT(!(addr=2))*mem_2> {mem_r} [0,0] <mem_r:=false, data:=INT(addr=1)*mem_1+INT(addr=2)*mem_2> (a) read [0,0] <mem_r:=true,addr:=foo> {¬mem_r} [3,3] <bar:=data> write [2,2] <mem_w:=true,addr:=foo,data:=bar> (b) Figure 3.16: Model for a more general memory architecture including (a) the memory subsystem and (b) read and write instructions implemented to access it. 37 indexed branching is possible in many processors, so it is necessary to be able to explicitly represent this control ow. One method for accomplishing this is to have each instruction update the PC and include the proper value of the PC in each transitions enabling expression. In addition, the interrupt control process could be made sensitive to the PC and could use it instead of variables such as main thr and ISR i to transfer control between threads. This method does require signi cant extra computation at execution time, but it provides greater exibility in the kind of programs that can be analyzed. This chapter and Chapter 2 explain how to construct an LHPN to model an embedded system. The next chapter discusses how to perform state space exploration on that LHPN, in order to prove useful properties of the system. CHAPTER 4 VERIFICATION In order to analyze and verify properties of LHPNs, it is necessary to explore the reachable state space of the system. This process reveals all of the behaviors the system can exhibit. There are several obstacles to this process, including the fact that the state space can potentially be in nite. This chapter discusses the details of state space exploration. Section 4.1 introduces state sets, along with a discussion of the mathematics of intervals. A detailed method for exploring LHPN state spaces is presented in Section 4.2. Section 4.3 discusses an algorithm for nding failure traces. Finally, Section 4.4 discusses the contributions of this new method. 4.1 State Sets State space exploration is required to analyze and verify properties of LHPNs. This exploration is complicated by the fact that LHPNs typically have an in nite number of states. Therefore, to perform state space exploration on LHPNs, this in nite number of states must be represented by a nite number of state equivalence classes called state sets. State sets for extended LHPNs are represented with the tuple = hM; S; Y; Q;R; I;Zi where: M P is the set of marked places; S : B ! f0; 1; ?g is the value of each Boolean variable; Y : X ! Z Z is a range of values for each discrete integer variable; Q : V ! Q Q is a range of values for each inactive continuous variable; R : V ! Q Q is the current rate of change for each continuous variable;1 1Note that although the rate is de ned to be a range, the method requires the rate to be a single value. This is not a problem as an LHPN with ranges of rates can be transformed into one with only single valued rates [51]. 39 I : I ! f0; 1; ?g is the value of each continuous inequality; Z : (T [ V [ fc0g) (T [ V [ fc0g) ! Q is a di erence bound matrix (DBM) [16, 30, 67] composed of active transition clocks, active continuous variables, and c0 (a reference clock that is always 0). State sets and states di er in several ways. First, entries in S and I are extended to be able to take the value of unknown (?) to indicate uncertainty in their value. Second, discrete integer and inactive continuous variables (i.e. R(vi) = 0) are extended to allow them to take a range of values. Finally, a DBM Z is used to represent the ranges of values for clocks and active continuous variables. It should be noted that despite the use of state sets, due to the use of discrete and continuous variables, the state space of an LHPN may still be in nite making veri cation undecidable. The use of state sets requires that the expression evaluation function, Eval( , ), as well as the enabled transition function, E( ), be extended take a state set, to operate on ranges of values, and to return a range of values. For example, the relational operators on ranges are de ned as follows: ([l1; u1] = [l2; u2]) = if (l1 = l2 = u1 = u2) then 1 elseif ((l1 > u2)j(l2 > u1)) then 0 else ? ([l1; u1] > [l2; u2]) = if (l1 > u2) then 1 elseif (l2 u1) then 0 else ? ([l1; u1] [l2; u2]) = if (l1 u2) then 1 elseif (l2 > u1) then 0 else ? ([l1; u1] < [l2; u2]) = if (u1 < l2) then 1 elseif (u2 l1) then 0 else ? ([l1; u1] [l2; u2]) = if (u1 l2) then 1 elseif (u2 < l1) then 0 else ? 40 When applying relational operators to ranges, the result may be \?" since the relational operator must be applied to all values in the range. For example, the statement [1; 2] = [1; 2] returns \?" because the comparison is between all pairs of values in the ranges, not between the two ranges themselves. Arithmetic on ranges has been well studied [37]. Addition and subtraction is fairly straightforward, as shown below: [l1; u1] + [l2; u2] = [l1 + l2; u1 + u2] [l1; u1] 􀀀 [l2; u2] = [l1 􀀀 u2; u1 􀀀 l2] However, dealing with the sign of the operands makes multiplication and division some- what more complicated: [l1; u1] [l2; u2] = [min(l1 l2; l1 u2; u1 l2; u1 u2); max(l1 l2; l1 u2; u1 l2; u1 u2)] [l1; u1]=[l2; u2] = ( [l1; u1] [1=l2; 1=u2] if 0 62 [l2; u2] [􀀀1;1] otherwise Division by a range that includes 0 is quite involved [37], so for simplicity, a conservative unbounded range is returned. The modulo, bitwise, and bit extraction operations on ranges cannot be easily per- formed exactly and may result in noncontinuous ranges. For example, the operation [6; 9]%8 generates the results 0, 1, 6, and 7. These can be grouped into the ranges [0; 1] and [6; 7], but this would require splitting the zone. One method to do this is to use a multizone DBM approach, as described in [14], which we plan to investigate in the future. Currently, a more conservative approach is taken, choosing the larger region [0; 7] which encapsulates all possible values. Therefore, to address this problem, these operations are performed exactly when the operands are single values (i.e. li = ui), and an approximated solution is used when any operand is a range. The conservative approximations for these operations on ranges are the following: [l1; u1]%[l2; u2] = [min(0; max(􀀀(max(jl2j; ju2j) 􀀀 1); l1)); max(0; min(max(jl2j; ju2j) 􀀀 1; u1))] 41 NOT([l1; u1]) = [􀀀(u1 + 1);􀀀(l1 + 1)] AND([l1; u1]; [l2; u2]) = [min(l1 + l2; 0); max(u1; u2)] OR([l1; u1]; [l2; u2]) = [min(l1; l2); max(u1 + u2;􀀀1)] XOR([l1; u1]; [l2; u2]) = [min(l1 􀀀 u2; l2 􀀀 u1; 0); max(u1 + u2;􀀀(l1 + l2);􀀀1)] BIT([l1; u1]; [l2; u2]) = ? Any time abstraction is used, it is possible to capture invalid behaviors. False negatives can thus be found. Any error trace derived from an abstracted system must be scrutinized carefully to determine its validity. 4.2 State Space Exploration This dissertation extends the state space exploration method for LHPNs described in [49, 51] that uses zones that are de ned using DBMs to represent the continuous portion of the state space. In particular, this method must be extended to utilize the extended expression syntax for enabling conditions and assignments. The DBM based method shown in Algorithm 4.1 uses a depth rst search to nd the reachable state space for an extended LHPN. Note that because the state space of an LHPN may not have a nite representation, this is a semi-algorithm as it may not terminate. First, this method constructs the initial state set for the extended LHPN and adds it to the set of reachable state sets, . The initial state set is hM0, S0, Y0, Q0, R0, I0, Z0i where I0 contains the initial value for all continuous inequalities (i.e. I0(vi ./ ) = (Q0(vi) ./ Eval( ; 0))), and Z0 includes active continuous variables (i.e. R0(vi) 6= 0) set to their initial value and clocks for enabled transitions set to zero. The set of encountered state transitions, 􀀀, is initialized to be empty. Next, the method uses the findPossibleEvents function to determine all possible events, E, that can result in a new state set. A single event, e, is arbitrarily chosen from E using the select function. If after removing e from E, events still remain in E, the remaining events and the current state set are pushed onto the stack for later exploration. At this point, the current state set, , is updated to re ect the occurrence of the event, e. If that event is a member of the failure set, TF , a failure trace is calculated and exploration is terminated. If this new state set, 0, has not been seen before, it is added to the state space, , a new transition ( , 0) is added to 􀀀, a new set of possible events is calculated, and the exploration continues 42 from this new state. If the state set is not new, a previously explored state set and set of unexplored events are popped from the stack, and the exploration continues from this point. Finally, when the stack is found to be empty, the entire reachable state space has been found, and it is returned. This section now explains each of these steps in more detail. Algorithm 4.1: Semi-algorithm to nd the reachable states. 1 reach() 2 = 0 = initialStateSet() 3 = f g 4 􀀀 = ; 5 E = findPossibleEvents( ) 6 while(true) 7 e = select(E) 8 if (E 􀀀 feg =6 ;) then push(E 􀀀 feg; ) 9 0 = updateState( ; e) 10 if (e 2 TF ) then 11 findFailureTrace ( ; 􀀀; 0; 0) 12 return ( F ; 􀀀F ; false) 13 if 0 62 then 14 = [ f 0g 15 􀀀 = 􀀀 [ f( ; 0)g 16 = 0 17 E = findPossibleEvents( ) 18 else 19 􀀀 = 􀀀 [ f( ; 0)g 20 if(stack not empty) then (E; ) = pop() 21 else return ( ; 􀀀; true) The findPossibleEvents function that is shown in Algorithm 4.2 determines the set of all possible events from the current state. There are two event types: a transition can re or an inequality can change value due to the advancement of time. A transition may re at any time after its clock has reached the lower bound of the delay for that transition, and it must re before its clock exceeds the upper bound of its delay. Transition clocks become active when they become enabled, and, as mentioned before, only clocks for enabled transitions are kept in Z. Therefore, any transition whose clock is in Z (denoted t 2 Z) that can reach its lower bound (i.e. ub(Z; t) dl(t)) may re. Note that ub(Z; t) is de ned to retrieve the upper bound for t's clock from Z. An inequality, vi ./ , may change value when it is possible for time to advance to the point where the value of the continuous variable, vi, crosses the value of the expression, . This is determined by the ineqCanChange function by examining the current state set, . The ineqCanChange 43 function must be modi ed from the one described in [51] in that the original version only allowed the expression to be a rational constant. The new version must be extended to evaluate based on the current state. It is important to note that must be relatively constant. Namely, the value of must only change as a result of transition rings. It is this requirement that led to the restrictions described in Section 2.2 on the forms of expressions that can be used in enabling conditions. For each possible event, the addSetItem function is used to determine if this event can actually be the next to occur. The event may actually not be able to occur before some event already found in E, and it would not be added in this case. Alternatively, the event may be possible to occur next, and it may in turn prevent some other events in E from being next. The details of this function are the same as the previous version of the algorithm, so the interested reader should see [51]. Algorithm 4.2: Algorithm to nd possible events. 1 findPossibleEvents( ) 2 E = ; 3 for t 2 Z 4 if ub(Z; t) dl(t) then 5 E = addSetItem(E; t) 6 for (vi ./ ) 2 I 7 if ineqCanChange( ; vi; ) then 8 E = addSetItem(E; (vi ./ )) 9 return E The updateState function shown in Algorithm 4.3 determines the new state set that is reached after the occurrence of an event, e. First, this function calls the restrict function to modify Z to re ect that time must have advanced to the point necessary for the event to have occurred (i.e. the clock for the transition ring reaches its lower bound, or the continuous variable vi reaches the value of its right hand expression ). This function also must be extended to address the fact that inequalities can now be bounded by expressions. Next, the recanonicalize function uses Floyd's all-pairs shortest path algorithm to restore Z to a canonical form. When the event is an inequality changing value, the next step simply updates its value in I. When the event is a transition ring, however, the state update is more involved as shown in Algorithm 4.4, which is described below. Next, the transitions are checked to see if they have become newly enabled or disabled. A clock for a transition t not in Z that is enabled must be added to Z while a 44 clock for a transition t in Z that is not enabled must be removed from Z. Here again is another necessary modi cation in that determining if a transition is enabled requires the evaluation of the more complex expressions that are allowed in extended LHPNs. Finally, time is advanced using Algorithm 4.5 described below, Z is recanonicalized again, and nally, the new state set is returned. Algorithm 4.3: Algorithm to update the state. 1 updateState( ; e) 2 Z = restrict( ; e) 3 Z = recanonicalize(Z) 4 if e 62 T then 5 = updateIneq( ; e) 6 else 7 = fireTransition( ; e) 8 for t 2 T 9 if t 62 Z ^ t 2 E( ) then 10 Z = addT(Z; t) 11 else if t 2 Z ^ t 62 E( ) then 12 Z = rmT(Z; t) 13 Z = advanceTime( ) 14 Z = recanonicalize(Z) 15 return The fireTransition function shown in Algorithm 4.4 is called by the updateState function to re a transition t in state set . This function must rst update the marking by removing the tokens from all places in t and adding tokens to all places in t . Next, the transition t is removed from Z. Then, all assignments labeled on t are performed. This includes Boolean variable, discrete variable, continuous variable, and rate assignments. For extended LHPNs, these assignment functions are more involved. While in the basic LHPNs only constants are assigned, in extended LHPNs these assignments involve more complex expressions that must be evaluated on the current state. The assignments may have changed the values of some inequalities, so these must be updated next. The rate assignments may have activated or deactivated a continuous variable, so all continuous variables are checked and added or removed from Z as necessary. Finally, Z is warped using dbmWarp to properly account for any rate changes that may have occurred. The warping function described in [49, 51] is a technique that allows zones to be used even when continuous variables evolve at nonunity rates. The warping function does not need to be changed for extended LHPNs, so the interested reader is referred to [49, 51]. Once 45 again, the warping of zones is an abstraction of the state space that can result in false negatives. It does not, however, ever produce false positives, and it has been shown to be a reasonable abstraction allowing for accurate veri cation of several interesting systems [51]. Algorithm 4.4: Algorithm to re a transition. 1 fireTransition( ; t) 2 M0 = (M 􀀀 t) [ t 3 Z0 = rmT(Z,t) 4 S0 = doBoolAsgn( ) 5 Y 0 = doIntAsgn( ) 6 (Z0;Q0) = doVarAsgn( ) 7 R0 = doRateAsgn( ) 8 I0 = updateI(S0; Y 0;Q0;R0; I;Z0) 9 for v 2 V 10 if v 62 Z ^ R0(v) 6= 0 then 11 (Z0;Q0) = addV(Z0;Q0; v) 12 else if v 2 Z ^ R0(v) = 0 then 13 (Z0;Q0) = rmV(Z0;Q0; v) 14 (Z0;R0) = dbmWarp(Z0;R;R0) 15 return hM0; S0; Y 0;Q0;R0; I0;Z0i The updateState function calls the advanceTime function, shown in Algorithm 4.5, to advance time in Z. The basic idea behind this function is that it allows time to advance as far as possible without missing an event. To ensure that a transition ring t is not missed, advanceTime sets the upper bound value for the clock associated with t to the upper delay bound for t. To ensure that a change in inequality value is not missed on a variable v, all inequalities involving variable v are checked by the function checkIneq, and the largest amount of time that can advance before one of these inequalities changes value is assigned to the upper bound value for v. Note that this function must be modi ed to evaluate the expressions now found in these inequalities. Algorithm 4.5: Algorithm for advancing time. 1 advanceTime( ) 2 for t 2 Z 3 ub(Z; t) = du(t) 4 for v 2 Z 5 ub(Z; v) = checkIneq( ; v) 6 return Z 46 4.3 Error Trace Generation Once a failure has been identi ed, it must be reported to the user. To accomplish this, a failure trace is extracted from the state space. This process starts with the initial state 0. A breadth rst search is performed. The successors of each state are extracted from the state space, and tagged with their depth relative to 0. This continues until a failure state is found. The trace is then constructed by starting with the failure state, then iteratively selecting a single predecessor state with depth one less, continuing until a depth of zero is reached. This method results in a minimal length trace exhibiting the error. 4.4 Contributions The method presented in this chapter is an extension of that presented in [49, 51]. The primary contribution of this extension lies in the adaptation of the original method to support more complex operations and the development of methods to reasonably approximate mathematical operations on ranges of values. This exploration method becomes intractable if the systems being explored are too complex. Chapter 5 de nes some methods for simplifying LHPNs to enable analysis of larger designs. CHAPTER 5 LHPN TRANSFORMATIONS The overarching goal of this work is the analysis of real world designs. Unfortunately, the complexity of these systems increases rapidly as the number of subsystems and environmental e ects increases. Especially when descriptions are automatically compiled, a great deal of extraneous information is introduced. Therefore, most systems are much too complicated to analyze in their full explicit form. Much of that information is never used for any purpose. Even more is not useful in analyzing a particular property. It is useful to eliminate information that does not contribute to the resolution of the question at hand. At the same time, it is necessary to make sure that the reduced version has all of the essential features of the original system with respect to the property under consideration. Because each property has a di erent support set, the same system may look strikingly di erent when abstracted with di erent target properties. This chapter introduces several graph transformations that eliminate unnecessary complexity while maintaining critical data. With each transformation, the intuition for the change is discussed, as well as a set of su cient conditions for applying the transformation. The LHPN transformations introduced in this chapter fall into two general categories. Simpli cations modify the net, but do not make any changes to externally observable behavior. They can be compared to instruction reordering in compilers. Abstractions eliminate information that is thought to be unnecessary to model the behavior being tested. This is done in a conservative fashion, by adding behaviors and including states that are not part of the original system speci cation. This can introduce false failures, by including failure states that are not truly reachable. Such behaviors would then need to be weeded out by re ning the abstraction. Section 5.1 rst presents related work in this area. Then, Section 5.2 presents pre- liminary topics necessary for these discussions. Sections 5.3 through 5.14 present some correctness preserving LHPN simpli cations. Finally, Section 5.15 presents some conclu- sions. 48 5.1 Related Work Petri nets have been used for system modeling for some time, and a great deal of e ort has been devoted to the development of abstraction methodologies in order to allow the synthesis and analysis of more complex systems. In [72, 73], the authors demonstrate methods for reducing the complexity of a complex system by replacing subnets by single transitions. The graph transformations presented in [15] are intended to preserve a broad class of properties, including unavoidable states, safety, and liveness. The authors of [44, 56, 57] introduce transformations for Petri nets without con ict. While these transformations preserve liveness and safety properties, the con ict restriction makes them unsuitable to PNs modeling state machines. In addition, they apply only to untimed nets. In [74], the authors signi cantly reduce the number of preconditions required to perform correctness preserving transformations. The transformations described in [79] are de ned on timed Petri nets, but apply to networks addressing purely Boolean variables. An important part of the abstraction process is identifying which behavior can be elim- inated. There are two paths to this. First, identify the variables that contribute directly to the behavior in question, then solve backwards to nd the minimal set of assignments necessary to accurately nd their value. This is a sort of xed point calculation. Tracing back from the actual assignments should eventually reach a point where constants are assigned and no more values and/or calculations are needed. Alternatively, there may be a closed loop on a segment of the graph that has already been processed. Once the set of critical actions has been found, all other value assignments and calculations can be eliminated. Presumably, all branch control enabling conditions and those assignments that support them should be part of this critical set. The timing of the reduced places must be maintained so the overall system behavior does not change. (It should be possible to combine transitions and places that only mark time.) This approach can be computationally intensive and di cult to prove correct. The BLAST [36] and SLAM [12] projects are an extreme example of this method. Both start with an absolutely minimal set of \important" behaviors, generally just control ow points, and derive locally important behaviors as part of the abstraction-re nement loop. The other possibility is to solve it bottom up: search for behavior that is clearly unnecessary and eliminate it. This approach must be applied in an iterative fashion, as such transformations may make other behavior super uous. Much research has been done on this topic in the compiler world [1], and some of the same concepts can be applied 49 here. Other related work includes reduction techniques for timed and hybrid automata described in [29, 34, 53]. This chapter introduces some useful net transformations, based on bottom up analysis of the LHPN. 5.2 Preliminaries This section de nes some basic predicates and functions that are useful in explaining the transformations presented in this chapter. A transition t is said to read a variable v if it contains any reference to v other than its own vacuous assignment. Formally, this is de ned below: reads(t; v) , (v 2 sup(En(t))) _ (9v0 2 AV:(:vac(t; v0) ^ v 2 sup(AA(t; v0)))): It is important to note that many of the transformations discussed in this chapter can only be applied to variables that are local to a given process. Formally, a variable v is local with respect to the process containing transition t as de ned below: local(t; v) , ((v 2 B) _ (v 2 X)) ^ 8t0 2 (T 􀀀 proc(ftg)):vac(t0; v) ^ :reads(t0; v): Intuitively, this means the variable is neither referenced nor assigned in any other process. The function sup(e) returns the set of all variables that occur in the expression e. The function Local(t) = fv 2 V jlocal(t; v)g returns the set of all variables that are local to the process containing t, and the function Global(t) = AV 􀀀 Local(t) returns the set of all variables assigned or referenced by any other process. There is an interesting superset of local variables that are written only by a single process but possibly referenced elsewhere. References to these variables within this process can be reshu ed but timing relationships of assignments must be maintained. Formally, a variable v is locally written with respect to the process containing transition t as de ned below. lw(t; v) , ((v 2 B) _ (v 2 X)) ^ 8t0 2 (T 􀀀 proc(ftg)):vac(t0; v): The function LW(t) = fv 2 AV j lw(t; v)g returns the set of all variables that are locally written with respect to the process containing t. 50 As an artifact of the compilation and simpli cation process, often expressions are constructed that have clear solutions or partial solutions. The function simplify(e) applies the following simpli cations to expressions. simplify(c1 op c2) = eval((c1 op c2); 0) simplify(0 + e) = e simplify(1 e) = e simplify(e 􀀀 0) = e simplify(0 􀀀 e) = 􀀀e simplify(0=e) = 0 simplify(e=1) = e simplify(true&e) = e simplify(false&e) = false simplify(trueje) = true simplify(falseje) = e simplify(eje) = e simplify(e&e) = e simplify(e&:e) = false simplify(ej:e) = true While applying transformations, it is occasionally necessary to substitute an expres- sion for a variable. The function replace(e; v; e0) substitutes the expression e0 for every occurrence of the variable v in the expression e. It then applies the function simplify(e) to the resulting expression. The function replace(t; v; e) performs replace(En(t); v; e) and replace(AA(t; v0); v; e) for all v0 in AV . A sequence of transitions = (t0; t1; :::; tn) is de ned to be a path if 8i 2 f0; 1; :::; ng:((ti 2 T) ^ ((i = n) _ (ti+1 2 ti )). The set of paths (N) is the set of all paths de ned by the ow relation within an LHPN. Note that this is not an execution sequence, but a graphically connected ordered set of transitions. It is occasionally necessary to evaluate the result of ring a transition. The function apply( ; t) returns the new state 0 generated when the transition t is red from the state 51 . In order to generalize this, the state ? is de ned to be a state where all variables have unknown values. It is useful to know if a particular transition t cannot disable an expression e. That is, the set of assignments in A(t) does not have the potential to drive the truth value of e to false. To determine this fact exactly is challenging, but a reasonable approximation is the following: cannotDisable(t; e) , (8v 2 sup(e):vac(t; v)) _ (Eval(e; apply( ?; t)) = true) In other words, a transition t cannot disable an expression e if it does not assign to any elements of the support of e or if it assigns a controlling set of values that drive the value of e to true. In an analogous fashion, an approximate form of cannotEnable can be de ned as follows: cannotEnable(t; e) , (8v 2 sup(e):vac(t; v)) _ (Eval(e; apply( ?; t)) = false) The LHPN transformations presented in this chapter are assumed to be applied only to LHPNs in which each process may have choice but not concurrency (i.e. 8t 2 T:jt j = j tj = 1). This assumption is reasonable since all LHPNs generated by our compilation method (described in Chapter 3) satisfy this property. Concurrency is achieved by the use of communicating processes. 5.3 Remove Arc After Failure Transition The purpose of conducting state space exploration for veri cation is to nd a coun- terexample, or prove that none exist. Execution stops once a counterexample has been located, as indicated by the ring of a failure transition. It is, therefore, possible to remove the ow relation arc from such a transition without a ecting the behavior of the system. The bene t of this transformation is not immediately obvious. It neither reduces the state space nor reduces the state vector. However, if it is the only entry point into a region of the LHPN, those places and transitions reachable only from this transition can be removed from the LHPN. Because the failure set is constant, this transformation need only be applied once. Transformation 1 (Remove arc after failure transition): Consider a transition t 2 Tf . The net can be transformed as follows: 52 F = F 􀀀 f(t; p) 2 F j p 2 t g. This transformation is illustrated with the LHPN fragment in Figure 5.1. If transition t is a member of the failure set Tf , executing it will terminate state space exploration. The link from t to place p0 can be removed, preventing p0 from being marked by this transition. 5.4 Removing Dead Transitions A transition is dead if it can never re. For example, if the enabling condition of a transition is a constant false, this transition is dead. While such an enabling term is unlikely to be speci ed by a designer, it happens frequently as a result of correlated variable substitution. Similarly, if there exist no tokens in any predecessor places to a transition, it is also dead as its preset can never become marked. Again, this is likely to be the result of the removal of dead upstream transitions rather than a feature of the original design. Dead transitions can be safely removed from the LHPN. Notice that hA(t)i p t fEn(t)g [dl(t); du(t)] hA(t)i p t fEn(t)g [dl(t); du(t)] p0 t0 fEn(t0)g [dl(t0); du(t0)] h:::; v := AA(t0; v); :::i p0 t0 fEn(t0)g [dl(t0); du(t0)] h:::; v := AA(t0; v); :::i Figure 5.1: Remove arc after failure transition: Transition t is a failure transition. The link connecting it to place p0 can be eliminated, because it will never be taken. 53 this transformation breaks the graph ow, and does not connect the predecessor to the successor. This is de ned formally as follows: Transformation 2 (Removing dead Transitions): Consider a transition t. If (En(t) = false) _ (pre( t) \M0) = ; then the net can be transformed in the following way: T = T 􀀀 ftg F = F 􀀀 (f(p:t) 2 F j p 2 tg [ f(t; p) 2 F j p 2 t g). This transformation is illustrated with the LHPN fragment in Figure 5.2. If the enabling condition of transition t is false, or place p cannot be marked, t can be eliminated from the LHPN. If t is the only transition leading to place p0, transition t0 can be removed as well. 5.5 Remove Dangling Places Removing dead transitions often results in places that no longer have any transitions in their postset. These places serve no purpose, and they can be removed. This is formally de ned as follows: Transformation 3 (Remove dangling places): Consider a place p. If (p ) = ; then the net can be transformed in the following way: P = P 􀀀 fpg F = F 􀀀 f(t; p) 2 F j t 2 pg. This transformation is illustrated with the LHPN fragment in Figure 5.2. After the application of Transformation 2 to remove transition t, place p can be removed if and only if t is the sole successor transition to p. Similarly, if t0 is the only successor to p0 and t0 is removed, t0 can also be eliminated. 54 p h:::; v := AA(t0; v); :::i p0 t0 fEn(t0)g [dl(t0); du(t0)] h:::; v := AA(t0; v); :::i p t fEn(t)g [dl(t); du(t)] h:::; v := AA(t; v); :::i p0 t0 fEn(t0)g [dl(t0); du(t0)] Figure 5.2: Removing dead transitions: If the enabling condition En(t) is false, or place p has no possibility of being marked, t can be removed from the LHPN. If t is the only transition in p0, transition t0 can also be eliminated. Removing dangling places: If transition t is the only successor to place p, it can be eliminated. Similarly, if transition t0 is removed, and it is the only successor to place p0, p0 can be removed as well. 5.6 Remove Write Before Write There are many calculations that microcontrollers perform in the execution of every instruction. These values are often not used and are immediately recalculated. Removing these calculations simpli es the process of calculating a new state, reducing run time without a ecting the correctness of the system analysis. It should be noted that this does not reduce the size of the state vector, but it may conceivably reduce the number of states. The primary bene t of this transformation, however, is to reduce the number of assignments and potentially reduce an entire transition to vacuity. This enables the application of transformations that remove transitions with only vacuous assignments (Transformations 10 and 11), which are described later in this chapter. Transformation 4 (Remove write before write:) Consider a transition t and a variable v. If o 55 :vac(t; v), local(t; v), and :9(t0; t1; :::; tn) 2 (N):((t0 = t) ^ reads(tn; v) ^ 8i 2 f1; 2; :::; n 􀀀 1g:(vac(ti; v))) then AA(t; v) := v: This transformation is illustrated with the LHPN fragment in Figure 5.3. Transition t performs a nonvacuous assignment to a variable v, which is local with respect to the process associated with transition t. All paths starting at t either (a) reach a transition t0 that assigns a new value to v and does not read v before any other transition references v or (b) end without ever referencing v. In this situation, the assignment AA(t; v) can be vacated, i.e. changed to AA(t; v) = v. t fEn(t)g [dl(t); du(t)] h:::; v := v; :::i fEn(t0)g [dl(t0); du(t0)] h:::; v := AA(t0; v); :::i p0 t0 fEn(t0)g [dl(t0); du(t0)] h:::; v := AA(t0; v); :::i p t fEn(t)g [dl(t); du(t)] p0 h:::; v := AA(t; v); :::i t0 p Figure 5.3: Remove write before write: If transition t makes a nonvacuous assignment to variable v, and all paths starting at t either never reference v or terminate in a transition t0 that assigns a new value to v without reading it, the assignment AA(t; v) can be changed to AA(t; v) = v . 56 5.7 Substitute Correlated Variables Occasionally, two or more variables are closely correlated. Every time one of them is assigned, the other is assigned to a value that is easily derived from the other. That value may be the same or a clear function of the other. In either case, if they are always assigned at the same time and have the same relationship to each other every time they are assigned, it is not necessary to maintain both variables. Deleting these variables simpli es the state vector. Since the values are always in synchronization, this does not result in a state space reduction, but it may make detection of constant enabling expressions (Transformations 8 and 9) easier. This transformation is de ned formally as follows: Transformation 5 (Substitute correlated variables): Consider the variables v and v0. If 8t 2 T:(AA(t; v0) = f(AA(t; v)) _ (vac(t; v) ^ vac(t; v0))) where f(x) is any clearly de ned function of one variable, including the identity function, then 8t 2 T:replace(t; v0; f(v)). As an example, consider the LHPN fragment in Figure 5.4. Assuming v and v0 have been clearly shown to always have the relationship v0 = f(v); v0 is redundant and can be eliminated. The reference to v0 in the assignment to v00 must be replaced with the appropriate function of v. [dl(t); du(t)] h:::; v := AA(t; v); v0 := f(AA(t; v)); v00 := f0(v0):::i p t fEn(t)g h:::; v := AA(t; v); v00 := f0(f(v)); :::i [dl(t); du(t)] p t fEn(t)g Figure 5.4: The variables v and v0 are clearly and consistently assigned to an easily identi able function of each other. v0 can be eliminated, and the use in the assignment of v00 changed to the appropriate function of v. 57 5.8 Local Assignment Propagation Microprocessors and microcontrollers perform calculations in a paced, steady fashion. In exploring state spaces, it is bene cial to have calculations performed in short bursts. The timing of local variable assignments is usually unimportant. If, however, a local variable assignment has a global variable in its support, the timing of that reference to the global variable must not change. It is otherwise su cient to maintain the ordering of assignments with respect to other assignments that depend on their result. It is therefore possible to push variable assignments forward to perform \just in time" assignment. Indeed, it is often possible to substitute the expression used to calculate a variable, and to eliminate the calculation of the separate variable altogether. This can reduce the number of transitions that perform useful work, enabling the application of Transformation 10. It also reduces the state space by reducing the number of states in which variables change values. It should be noted that this is not an analog to a compiler optimization. Indeed, it is in many ways a decompilation step. Compilers need to break calculations down into minimal steps that can be mapped to assembly language instructions. State space analysis is better served by making a single, complex calculation than by creating several states to make a series of intermediate calculations. It is even preferable to calculate the same value several times, if the state where it is calculated separately can be eliminated. Delaying the assignment of a local variable requires that all transitions immediately preceding the target transition make exactly the same assignment to the variable, and that none make changes to the support set of the assignment expression. This transformation is formally de ned as follows: Transformation 6 (Local assignment propagation): Consider an assignment v := AA(t; v) on a transition t. If :vac(t; v), local(t; v), 8v0 2 sup(e):lw(t; v0), 8t00 2 ( (t )):AA(t00; v) = AA(t; v), and 8t00 2 ( (t )):(8v0 2 (sup(AA(t; v)) 􀀀 fvg):vac(t00; v0)) 58 then 8t0 2 (t ):replace(t0; v;AA(t; v)), and 8t00 2 ( (t ));AA(t00; v) := v: This transformation is illustrated with the LHPN fragment in Figure 5.5. If AA(t; v) is a nonvacuous assignment to a variable that is local with respect to the process associated with transition t, all variables v0 that are in the support of AA(t; v) are locally written, all transitions in the preset of p0 make the same assignment v, and all variables other than v in the support of e are not assigned in these transitions, then the assignment to v on transitions t and t00 can be made vacuous and all occurrences of v in transition t0 can be replaced with AA(t; v). Note that if AA(t0; v) was a vacuous assignment, this has the e ect of moving the assignment to t0. h:::; v00 := AA(t0; v00); :::i p0 t0 fEn(t0)g [dl(t0); du(t0)] p1 fEn(t1)g t1 [dl(t1); du(t1)] h:::; v := v; :::i fEn(t0)g pn fEn(tn)g tn [dl(tn); du(tn)] h:::; v := AA(tn; v); :::i p1 fEn(t1)g t1 [dl(t1); du(t1)] h:::; v := AA(t1; v); :::i pn fEn(tn)g tn [dl(tn); du(tn)] h:::; v := v; :::i h:::; v00 := replace(AA(t0; v00); v;AA(t; v)); :::i p0 t0 [dl(t0); du(t0)] Figure 5.5: Local assignment propagation example. The assignment of variable v to expression AA(t; v) on transition t is eliminated, as are all assignments in parallel transitions t00. All uses of v in transition t0 are changed to AA(t; v). 59 5.9 Remove Unread Variables The automatic compilation of an LHPN from a generalized microcontroller descrip- tion must include every e ect and side e ect of every instruction. Often, this means variables are introduced and calculated that never get used. In addition, in the process of abstraction, the uses of variables are often eliminated, leaving these orphaned variables unused and unnecessary. Eliminating these variables simpli es the system without losing any useful information. At a minimum, this reduces the state vector. In addition, states di erentiated solely by these variables are eliminated. This transformation also potentially enables the application of transformations that remove transitions with only vacuous assignments (Transformations 10 and 11), which are described later in this chapter. When a variable is written but never read, the variable can be removed from the system with no loss of precision. Note that this includes cases where a variable is used solely to calculate a new value for itself. This is formally de ned as follows: Transformation 7 (Remove unread variables): Consider variable v. If 8t 2 T::reads(t; v) then AV = AV 􀀀 fvg. As an example, consider the LHPN fragment in Figure 5.6. Assuming v has been proven unused, it can be eliminated from consideration. [dl(t); du(t)] h:::; v0 := AA(t; v0); v := AA(t; v); v00 := AA(t; v00):::i p t fEn(t)g h:::; v0 := AA(t; v0); v00 := AA(t; v00); :::i [dl(t); du(t)] p t fEn(t)g Figure 5.6: If the variable v is not ever used, it is removed from the domain of AV , e ectively eliminating all assignments to v. 60 5.10 Constant Enabling Conditions Automatic instantiation of hardware components often results in LHPNs that contain descriptions of hardware functionality that is unexercised by a particular application. For example, a microcontroller subsystem may have eight modes of operation, controlled by three bits in a control register. If those bits are only ever set one way, seven of the entry control transitions can never be taken. It is also possible for a path controlling enabling condition to evaluate to true in the initial state and never to change. These conditions occur often enough for it to be worthwhile to detect them and to replace the enabling conditions with their constant truth values. Replacing unsatis able conditions with false enables dead transition removal. Replacing tautological conditions with true results in simpli cation of evaluation, reducing runtimes. If the enabling condition of a transition is false in the initial state and no assignment made by the LHPN to its support set can make it true, it can be replaced by the constant false. Conversely, if it is true in the initial condition, and no assignment