Formal Methods Specification and Analysis Guidebook for the Verification of Software and Computer Systems

OIIICI 01 Sill 1) l\l)\llsslo\ \%s( l{\\cl NASA-GB-O01-97 1{1 I I \\l 1 (1

Volume 11: A Practitioner’s Companion

May 1997

L*L● National Aeronautics and Space Administration @ Washington, DC 20546 NASA-GB-001-97 Release 1.0

FORMAL METHODS SPECIFICATION AND ANALYSIS GUIDEBOOK FOR THE VERIFICATION OF SOFTWARE AND COMPUTER SYSTEMS

VOLUME II: A PRACTITIONER’S COMPANION

FOREWORD

This volume presents technical issues involved in applying mathematical techniques known as Formal Methods to specify and analytically verify aerospace and avionics software systems. The first volume, NASA-GB-002-95 [NASA-95a], dealt with planning and technology insertion. This second volume discusses practical techniques and strategies for verifying requirements and high-level designs for software intensive systems. The discussion is illustrated with a realistic example based on NASA’s Simplified Aid for EVA (Extravehicular Activity) Rescue [SAFER94a, SAFER94b]. The vohu-ne is intended as a “companion” and guide for the novice formal methods and analytical verification practitioner. Together, the two volumes address the recognized need for new technologies and improved techniques to meet the demands inherent in developing increasingly complex and autonomous systems. The support of NASA’s Safety and Mission Quality Office for the investigation of formal methods and analytical verification techniques reflects the growing practicality of these approaches for enhancing the quality of aerospace and avionics applications.

Major contributors to the guidebook include Judith Crow, lead author (SRI International); Ben Di Vito, SAFER example author (ViGYAN); Robyn Lutz (NASA - JPL); Larry Roberts (Lockheed Martin Space Mission Systems and Services); Martin Feather (NASA - JPL); and John Kelly (NASA - JPL), task lead. Special thanks go to John Rushby (SRI International) who provided valuable material and guidance, Sam chvre (SRI International) who graciously supplied wide-ranging technical expertise, Gerard Holzrnann (Lucent Technologies) and Peter Germ Larsen (IFAD) both of whom gave particularly thorough and thoughtful reviews, and Valerie Mathews (NASA - JPL) who served as guidebook review and publication coordinator. Special acknowledgment is also extended to NASA sponsors Kathryn Kemp (Deputy Director, NASA IV&V Facility), George Sabolish (NASA - Ames), Rick Butler (NASA - Langley), and Ernie Fridge (NASA- Johnson).

This document is a product of NASA’s Software Program, an agency-wide program that promotes continual improvement in software engineering and assurance within NASA. The goals and strategies of this program are documented in the NASA Software Strategic Plan. [NASA-95b] Funding for this guidebook was provided by NASA’s Office of Safety and Mission Assurance. Additional information about this program and its products is available via the World Wide Web at http:// www.ivv.nasa.gov. NASA-GB-O01-97 Release 1.0 m Office of Safety and Mission Assurance s

Formal Methods Specification and Analysis Guidebook for the I Verification of Software and Computer Systems $ Volume II: A Practitioner’s Companion

May, 1997

Approvals: 1 ------\ ‘\. ‘ . ...--’., _]&i-d L’ . ,e ‘, _Q”&_ n Task Lead . . .

1 Jet Propulsion Laboratory Pasadena, CA

——. Conc{mence for Publication

Kathryn Kemp a NASA OSMA Software Program, Manager NASA IV&V Facility Fairmont, WV c

This guidebook is one of the products of a cooperative study to investigate the applicability of Formal Methods and Analytical Verification for critical NASA F software systems. This guidebook was jointly developed through cooperative work from three NASA centers: Jet Propulsion Laboratory, Johnson Space B Center, and Langley Research Center. 9

Contents

1 Introduction 1

2 The Practical Application of Formal Methods 4 Q.1 w]lat Ar~~orI]lal Mctllods?...... 4

2.2 Rolwof FornlalMethods...... 5 2.3 Formal Methods: Degree of Formalization and Scope of Use ...... 5 2.3.1 Levels of Formalization ...... 6 2.3.2 Scope of Formal Methods [Jsc ...... 7 2.4 Reasonable Expectations for Formal Methods ...... 8 2.5 The Method lJndcrlyiug Formal Mctllods ...... ~ 2.6 Au Introduction toSAFER ...... 12

3 Requirements 17 3.1 Requirements and Formal Methods ...... 18 3.1.1 Impact of Requirements Spccificatio~l on Formal Methods . . . . 18 3.1.1.1 I,evcl of Requirenlents Capture ...... 18 3.1.1.2 Explicitness of Recluirenmnts Statement ...... 18 3.1.1.3 Clarity of Delineation between a System and Its Envi- ronulmt ...... 18 3.1.1.4 Traceability of Recluirements ...... 19 3.1.1.5 Availability of Underlying Rationale and Intuition . . . 19 3.1.2 Impact of Formal Methocls on Requirements ...... 20 3.2 Conventional Approaches to Requirements Validation ...... 21 3.3 SAFER Requirements ...... 23

vii . . . vlll q hbJe Of (;Olltf!I1tS

4 hlodels 25 4.1hIathen~atica lModcl s...... 25 4.1.1 Characteristics of Nlatllematica] Models ...... 26 4.1.1.1 Abstractic)~l ...... 26 4. I. I.2 Focus ...... 27 4.1. ].3 Exl)ressivel~ess l~ersus Analytic Power ...... 27 4.1.1.4 Intuit ive Versus Nonilltuitive Representation ...... 28 4.]. ].5 Accuracy ...... ”” 28 4.1.2 Bencfitsof Mathematical Models ...... 28 4.1.3 Mathenlatical h!lodels for Discrete and Continuous Donlains . . 29 4.2 Colltil~uo~ls Dol[laill Modclitlg ...... 3(I 4.3 Discretc l)omainh lodeli% ...... 32 4.3.1 Functional hIc)dels ...... 32 4.3.2 Abstract, State hlachine Models ...... 34 4.3.3 Automata-Based Models ...... 36 4.3.3.1 *- Autonlata ...... 36 4.3.3.2 ti-Autonlata ...... 38 4.3.3.3 Tind Autonlata ...... 38 4.3.3.4 Hybrid Autonlata ...... 39 4.3.4 object-oriented” Models ...... 39 4.4 A Model for the SAFER Avionics Controller ...... 45

5 Formal Specification 50 .5.1 Fornlal Specification Lauguages ...... 51 5.1.1 Foundations ...... 51 5.1.2 Fcaturcs ...... 53 5.1.2.1 Explicit Senlantic s...... 54 5.1.2.2 Expressiveness ...... 54 5.1.2.3 Progranln~ing Language Datatypes and Constructions . 55 55 5.1.2.4 Convenient Syntax ...... 5.1 .2.5 Diagranln~atic hTotation ...... 55 5.1.2 .6 Strong Type% ...... 55 5.1.2.7 ‘1’otal versus Partial Functions ...... 56 5.1.2 .8 Refilmnent ...... 57 ATASA- GB-001 -97 ix

5.1.2.9 I1ltroduction of Axiolns aud I)efiuitious ...... 57 5.1.2.10 Encapsulation N4echauism ...... 59 5.1.2.11 Ruilt-iu Model of Coml)utation ...... 6(I 5.1.2 .12 FJxecutability...... 60 5.1.2 .13 Maturity ...... 61 5.2 Formal Specification Styles ...... 61 5.3 Formal Specification atd Life Cycle ...... fjz 5.4 TIN Detection of Errors iu Formal Specification ...... 63 5.5 The Utility of Fmmal Spccificaticnl ...... (Xi 5.6 A Partial SAFER S1wcification ...... 69 ‘

6 Formal Analysis 77 6.1 Autol~latcdD ed~lctic)ll...... 77 6.1.1 Background: Fornlal Systems and !f’heir Models ...... 78 (i.l.l. ll)roofrl’heor y...... 78 6.1.1.2hIodcl ?’llc:ory ...... 8(I 6.1.1.3 An Exanq)le of a First-Ordcx Theory ...... 81 6.1.2 A Brief History of Automated Proof ...... 82 6.1.3 Techniques Underlying Automated Reasoniug ...... 85 6.1.3.1 Calculi for 14’irst-Order Predicate I,ogic ...... 85 6.1.3.1.1 NTornlal Porlns ...... 86 6.1.3.1.2 The Sequent Calculus ...... 86 6.1.3.1.3 The Resolution Calculus ...... 91 6.1.3.2 Extcncling the Predicate Calculus ...... 92 6.1.3.2.1 Reasonin~ about 13cluality ...... 93 6.1.3.2.2 Reasoning about Arithuletic ...... 95 6.1.3.2.3 Combiuing First-order Theories ...... 95 6.1.3.3 Mechanization of Proof ill tile Sequent Calculus . . . 96 6.1.4 Utility of Automated Dcdllctioll ...... 100 6.2 Finite-State Methods ...... 101 6.2.1 Background ...... 102 6.2.1.1 TemporalIJ o.gic ...... 102 6.2.1.2 Liuear Tenll)oral Logic (LT1.) ...... } 04 6.2.1.3 Brauching Time lhnporal Logic ...... 105 x 7hble of @IltC!Ilt S

6.2.1.4 Fixed Points ...... 108 6.2.1.5 The Mu-Calculus ...... 108 6.2.2 ABrief History of Finite-State Methods ...... 110 6.2.3 Approaches tc) Finite-State Verification ...... 112 6.2.3.1 The $@)olic Mode] Checkilig Approach ...... 112 6.2.3.2 ‘l’lie Automata-Theoretic Approach ...... 114 6.2.3.2.1 l,anguage Containment ...... 115 6.2.3.2.2 State Exploration ...... 116 6.2.3.2.3 Bisinlulatioli Equivalence and Prebisimulation Preorclers ...... 118

6.2.4 Utility of Finite-State Methods ...... 119 6.3 Direct Execution, Simulation, and Animation ...... 119 6.3.1 Obscrvaticnlal Techniques ...... 120 6.3.2 Utility of observational Techniques ...... 121 6.4 Integrating Autolnatcd Analysis Methods ...... 122 6.5 Proof of Selected SAFER Pro]wrty ...... 122 6.5.1 The PVS Theory SAFER-properties ...... 123 6.5.2 Informal Argument for I.cnma max.thrusters_sel ...... 126

7 conclusion 130 7.1 Factors Influencing the Use of Formal hiethods ...... 130 7.2 The Process of Fcmnal Methods ...... 131 7.3 F’airing Formal Methods, Strategy, and Task ...... 132 7.4 Formal h4cthods and Existing Quality Control and Assurance Activities ...... 133 7.5 Formal h4ethods: Verification Versus Validation and Explorat ioll . . . . 134

References 136

A Glossary of Key Terms 165 A.l Acronyms ...... 165 A.2Ternl s ...... 166 B Further Reading 169 11.1 Technical Background: h4athenlatical lmgic ...... 169 11.2 Specificatio n ...... 170 H.3hIodel Checkin g...... 170 B.4Thcorenl Proving ...... 171 1].5 hIodels of Conlputation ...... 171 B.6 Applications aud Overvicws ...... 172 1].7111torials ...... 172

C Extended Example: Simplified Aid for EVA Rescue (SAFER) 174 C.lOvervicw of SAFER ...... 174 C.].1 History, Mission Colltext, atld System Description ...... 174 C.1.2 Principal Hardware Components ...... 176 C.1.2.1 Ilackpack Propulsio:l h40dule ...... 176 C.] .2.2 IIaud Controller hlodulc (HChI) ...... 177 C.1.2.3 BatteryP ace ...... 178 C.] .2.4 Flight, Support Equipnlent ...... 178 C.1.3 Avionics ...... 178 C.1.4Systen lSoftwar c...... 179 C.1.4.1 Software Interfaces...... 181 C.1 .4.2 Maneuvering Control Subsystcnl ...... 181 C.1.4.3 Fault Detection Subsystenl ...... 182 C.2 SAFER EVA Flight Operatiorl Requirements ...... 186 C.2.1 Hand Controller Module (HCM) ...... 186 C.2.1. I Display and Control Unit ...... 186 C.2.1.2 }laud Controller [Jnit ...... 187 C.2.2 Propulsion Subsystenl ...... 1S7 C.2.3 Avionics Asscnlblies ...... 188 C.2.3.1 Iuertial Reference Unit (IRU) ...... 188 C.2.3.2 Power Supply Assen~bly ...... 188 C.2.3.3 Data Recorder Asscn~bly (DRA) ...... 188 C.2.4 Avionics Software ...... 189 C.2.5 Avionics Software Interfaces ...... 190 C.3 Formalization of SAFER Requirenlents ...... 191 xii Table of contents

C.3.1 PVS Lauguage Features ...... 191 C.3.2 Overview of Formalization ...... 193 C.3.2.1 lkwicTypcs ...... 191 C.3.2.2 Haud Controller hfloduk ...... 195 C.3.2.3 Propulsion hfoclulc ...... 195 C.3.2.4 Autonlatic Attituclc HoM ...... 195 C.3.2.5 q’hrustcx %lection ...... 195 C.3.2.6 Avionics h40del ...... 196 C.3.3 Full Text of PVSTheoric s...... 196 C.4Analysis of SAFER ...... 217 ‘ C.4.1 Fonuulatin.g System Properties ...... 217 C.4.1. I Fonl”lalization of the hlaxituutu Thruster Propczty . . . 218 C.4.1.2 PVS Theory for h!laximuln ~’hruster I’roperty . . . . 219 C.4.2 I’roving Systenl Properties ...... 221 C.4.2.1 Proof Sketch of the Maxilnutu Thruster Property . . . 221 C.4.2.2 PVS F’roof of h~axinmn] Thruster l’ro~m-ty ...... 223 9 8 List of Figures

2.1 The Range of Formal Methods O]hions Sun~u~arized in l’cnms of (a) Lev- els of Formalization and (b) Scope of Formal Methods USC...... 6 2.2 Mechanical Support for Specification aud Analysis Phases of FM. . ~ . . 12 2.3 Front and back views of SAFER s

4.1 ll~l]jlelllcl~tatiol~ of a Full Adder...... 34 4.2 Abstract State Macl~itle Modal...... 35 4.3 A-7 Model of a Sin~ple Control Systcn~...... 36 4.4 State-Update aud Actuator IWw.tions within Control Systcnl...... 37 4.5 Object Model of Cassini Generic Fault Protection lvlonito~...... 41 4.6 Functional Model of Cassini Generic Fault Protection Monitor...... 42 4.7 Dynanlic h!lodel of Cassini Generic Fault Protection Monitor...... 43 4.8 AAII Control Systenl State-lJpdate and Actuator Functions...... 47 4.9 I,alwlcd AAH Pushbutton State Transition Diagranl...... 4S

6.1 Burch et cd.’s Mu-Calculus hlodel Checking Algorithnl...... 113 6.2 A Sinlplc SMV I’rogran] [Mch193, p. 63]...... 114 6.3 Dependency ~~ierarchy for SAFER.properties...... 127 6.4 Proof Tree for SAFER-propertiesnax. thrusters.sel...... - . 128 6.5 Revised Proc)f Tree for SAFER_propertiesmax.thrusters-sel...... 129

C.1 SAFER use by an EVA crewn~en~t)er...... 225 C.2 Propulsion nlodule structure and lucchatlisnls...... 226 C.3 SAFER thrusters andaxcs...... 227 C.4 Ilandcontrollerlnoc lube ...... 228 C.5 Hand controller translational axes...... 229 C.6 Hand controller rotational axes...... 230 C.7 SAFER systenl software architecture...... 231 C.8 AAH pushbutton state diagram...... 232

& . . . Xlll m List of Tables

C-l SAFER ScIlsOr co@elllellt...... - ...... 180 C.2 Thruster select logic for X, pitch, and yaw conmarlds...... 183 C.3 Tlmuster select logic for Y, Z, aud roll commands...... 184

xiv

— Chapter 1

Introduction

This guidebook,-. the second of a two-volunlc series, is intenclccl to facilitate the transfer of fcmnal methods to the avionics and aerospace conmunity. The first volurnc concentrates on administrative and planning issues [NASA-95a], and the second volunle focuses cm the technical issues involved in applying forn~al methods to avionics and aerospace software systen~s. Hereafter, the term “guidebook” refers exclusively to the second volutnc of the series. The title of this second volunle, A Practitioner’s Conlpanion, conveys its intent. The guidebook is writteu prinlarily for the nonexpert and requires little or no prior experience with fcnvnal nwthods techniques and tools. However, it does attetnpt to distill sonw of the nlore subtle ingrecl ients in the productive application of formal nmthods. To the extexit that, it succeeds, those conversant with fo;nlal nwtliods will also find the guidel)ook useful. The discussion is illustrated through the developnlent of a realistic exanlple, relevant fragnwnts of which appear in each chapter. The guidebook focuses primarily on the use of forn~al nlethods for analysis of require- nlcnts and high-level design, the stages at which forn~al nlethods have been nlost produc- 9 tively applied. Although n~uch of the discussion applies to low-level design and inlple- nwnt at ion, the guidebook does not discuss issues involved in the later life cycle application of fornlal nlcthods. The cxan@ provided in the guidebook is based on the control 9 function for the Sinlplified Aid for EVA (Extravehicular Activity) Rescue [SAFER94a, SAFER94h], hereafter referred to as SAFER I, which has been specified and analyzed using the PVS specification language and interactive proof checker [0 RSvH95]. PVS has been selected because it has been successfully used on NASA projects, including [LR93a, NASA93, LA94, hIin95, BCC+ 95, HCL95, SM95b, DR96, ML96], and because it is representative of a class of tools that, offers a formal specification language in a conlprehensive environment, including automated proof support. In forn~alizing the 9 — —.- —. 1 SAFER is a descendent of the hlauned Nlaneuvering Unit (MM L’) [hf ML-83]. The main difference between SAFER and the MMU is that S.4FER is a small, lightlveight, “simplified” single-string system D for contingency use (self-rescue) only, whereas the IIMU is a larger, bulkier. but extremely versatile E~JA ~alleul,ering dei,i~~ The application of fox nlal methods t,o SAFER is limited to the example in this guidebook; formal methods have not been used to support SAFER development or maintenance.

. SAFER example, the priorities have been readability and portability to other formal methods paradigms. Consequently, the discussion is framed in genera] terms applicable to most formal methods strategic% and techniques, The guidebook is not a tutorial on formal ]Ilethocls; it does not pr-ovidc a groundil~,g in mathe,mat ical logic or formal specification slid verification, although t lle appendices contain references that provide technical background, as well as a glossary of key terms. Nor is it a formal metl)ods cookbook; there are no recipes that detail the step-by-step preparation of a formal methods product. Furthermore, the guidebook assumes that, the reader is aware of the potential lmnefits alld fallibility ics of formal met nods: it does not dwell on the very real benefits of the appropriate application of formal methods or the equally real pitfalls of misuse. The guidebook does contain a fairly detailed account of the technical issues involved in applying fornlal methods to avionics and aerospace software systems, including a well-developed example. in order of presentation, the topics covered in the guidebook include requirements, moclels, formal s~)ecificatiox~, and forlnal analysis. However. the application of formal methods is not an essentially linear process. Forlnal nlethods aye lnost l)roductive when integrated with existing life cycle processes, arid wlle~l they use an iterative strategy that successively refines and validates the formalization, t lle requirements, the clesigll, and if desired, critical parts of the im~)lement at ion. This guidet)ook is organized as follows: Chapter 2 reviews technical considerations relevant, to projects considerirlg the use of fornlal methods, touching briefly on general elements of the somewhat elusive method underlying formal methods. This chapter also ~Jroviclcs lmckground Iuaterial on tile SAFER example clmwlo~wcl in subsequent clmp ters. Chapter 3 examines the notion of requirements from a formal methods perspective and introduces selected requirements for the ongoing SAFER example. The concept of models and a survey of modeling strategies are introduced in Chapter 4, along u’ith a formal model for a SAFEF{ subsystem. A fragment of the specification fol tlIe SAFER requirements introduced in Chapter 3 is developed using the model defined in Chapter 4. Chapter 5 provides a discussion of formal specification, including topics ranging from specification languages, paradigms, and strategies, to type consistency of specifications. Agaill, a discussion of the pertinent step in the development of the SAFER example ap~)ears at the end of the chapter. Chapter 6 ccmsiders techniques and toc)ls for formal analysis, including such topics as the role of formal proof, the impact of specification strategy OXL formal analysis, and the utility of various analysis strategies. A discussion of formal analysis of key properties of the SAFER specification appears at the end of the chapter. Follo~ving concluding remarks iu Chapter 7 are three appendices: Ap- pendix A contains a glossary of key terms and concepts, Appendix El lists material for further reading, and Appendix C offers an extended discussion of the complete SAFER exam~dc.2 .— —— —— 2The PVS source files for the SAFER example are available 011 LaRC’s lVeb server iu the directory ftp://atb-www.l arc.nasa.gov/Gui debooks/. ATA4SA. GB_OOl .97 3

There are several ways to usc this guidebook. The heart of the discussion a~)pears in Chapters 4, 5, aud 6. Readers new to forlnal methods may waut to concentrate 011 these key chapters, along with the first three cha~)ters aud the conclusion, possibly skippillg Chapter 6 the first titnc through. in nlost cases, historical observations and ruore technical nlaterial arc bracketed with the “daugcrous bend’) signs: ~...~ .3 More experienced practitioners may waut to focus on Chapters 5 alid 6, or skip directly to the full treatnlent of the exau~ple ill Appendix C. The SAFER example that concludes each chapter should be used to further clarify the discussion as the reader proceeds, rather than saved as a finale at the end of tile chapter.

3The “dangerous beud” icon was introduced by Knuth [KIIu86] Chapter 2

The Practical Application of Formal Methods

The practical a~)~)lication of formal methods typically occurs witlliu the context of a project and, possibly, within a broader context dictated by institutionalized conventions or criteria. These contexts determi~le the role of formal methods aud the dime~i - sions of its use. This chapter contains a review’ of these contextual factors, including a brief ovcr~’iew of the formal methods process. ‘J’he discussion moves from the ex~)licitly formal nature of formal methods to the more elusive methods implied iu its use. The chapter also provides sufficient background iuformat ion on SAFER to clarify and nlot i- vate ~nwsentation of pertitlcnt aspects of the formalization and analysis of SAFER that illustrate the discussions in each of the subsequent chapters.

2.1 What Are Formal h!tethods?

The term Formal Methods refers to the use of techniques from logic and discrete n~athe- matics in the specification, design, and construction of computer systems and software. The word “formal” derives from formal logic and means ‘(~wrtaining to the structural relationship (i.e., form) between elements. ” Formal logic refers to methods of reasoning that are valid by virtue of their form and iudcpcndeut of their content. These methods rely on a discipline that requires the explicit enumeration of all assumptions and reasoning steps. Ill addition, each reasoning step must be an illstance of a relatively small number of allowed rules of inference. The most rigorous formal methods apply tllesc techniques to substantiate the reasoning used to j ust ify the requirements, or other aspects of the design or implementation of a complex or critical system. IIi formal logic, as well as formal methods, the objective is the same: reduce reliance on human intuition alld judgment, in evaluating arguments. That is, reduce the acceptability of au argument to a calculation that can, in principle, be checked mechanically, thereby replacing

4 the itdlerent subjectivity of the review process with a repeuta ble exercise. I,ess rigorous formal Incthodsl tend to emphasize the formalization and forego the calculation. This definition implies a broad spectrutn of formal methods techtliqum, as well as a similarly wide range of formal nlcthods strategies<2. Tile il~teraction of the techniques slid strategies -yields many forlnal methods options, constraiucd, for any given project. by the role of formal I[lcthods and the resources available for its application. The roles of formal met Ilods are discussed in the following section. An evaluation of resources as a factor shaping formal methods can be found in Volume 1 of this Guidebook [NASA-95a].3 The purpose of the next few sections is to emphasize the versatility of formal methods and the importance of customizing the usc of formal methods to the application.

2.2 Roles of Formal Methods

As noted above, formal nletbods may bc used to calculate. For example, a formal nlethod may be used to determine whcibcr a certain description is internally consistent, whether certain properties arc consequences of proposed requirements, whether one level of design implements another, or whether one design is preferable to another. In such cases, the focus of formal methods use is largely analytical. Formal methods may also have a primarily descriptive focus, for example, to clarify or document requirements or high-level design, or to facilitate communication of a recluiremcnt or design during inspections or reviews. Each usc reflects a particular formal methods role. Formal nlethods may also be used to satisfy standards or to provide assurance or certification data, in which case the role of formal methods, as well as the analytic or descriptive content of the forlnal methods ~woduct, is ~~rescritxxl. The intended role or roles specified for a particular application of formal methods servm to constrain the set of techniques and strategies appropriate for that project.

2.3 Formal Methods: Degree of Formalization and Scope of Use

Formal methods options may be classified in terms of techniques that are differentiated try degree or level of formalization (Figure 2.1 (a)), and strategies that are characterized by the scope of formal methods usc (Figure 2.1 (b)). Level of formalization and scope of use are independent factors that combine to determine the range of formal methods ol)tions, hence their juxtaposition in Figure 2.1. ——.——. -. — 10r, equivalently, the use of a rigorous formal n]ethod at a lo~ver level of rigor. The extent of formalization and level of rigo~ are discussed in Section 2.3. ‘As used here and throughout the remainder of the guidebook, “formal methods strategies’” refer to stratagems for productively employing the mathematical techniques that comprise formal methods. 3The material in the following sections reflects the type of technical issues typically raised in a generaI discussion of formal methods USC. h’fore complete exploration of these and related topics can be found, fol example, in [Rus93a, EIS93, Hf195tI]. (i Cha])ter 2

~- Lmels of Forma lizatio~L --7 1. Mathematical concepts and notation, FEEI.lfe cycle phases: infor~nal analysis (if ally), no mechanization I all/selected 2. Fornlalized- specificatioll languages, I System conll,onents: some mechanized su~q)ort all/selected —— 3. Formal specification languages, System functionality: comprehensive environment, including full/selected autolnated proof cllecker/theoreln prover F Figure1:---=:”:~ 2.1: The Range of Formal Methods options Sununarized in Terms of (a) I,cvels of For~nalization and (b) Scope of Formal Methods use.

2.3.1 Levels of Formalization

Formal methods techniques may lW defined at varying levels, reflecting the extent to which a technique formulates specifications in a language with a well-defined semautics, ex~)licitly enumerates all assumptions, and reduces lJroofs to applications of well-defined rules of inference. lncreasiug the degree of formality allows spczificat ions and assumptions to bc less dependent on subjective reviews and consensus and more amcnab]e to systclnatic analysis and re~)licatioll. g’here is a distinction to be drawn between the terms rigor and fornlality; it is possible to h rigorous, that is, painstakingly serious and careful, without being truly formal in the mathematical sense. Sil)ce it is difficult to use a high degree of forlllality with pencil at Id paper [I{vH93], increasing formality is associated here with increasing dependence on computer support.

As techniques mature and acquire automated support, their level of formalization typically changes. The evolution of the A-7 or Software Cost Reduction (SCR) nlethocl- ology illustrates this process. In the late 1970s, Parnas, Heninger, and colleagues at the Naval Research Laboratory (NTI{L) defined a tabular method to specify software system requirements [H+ 78]. Van Schouwen subsequently formalized the method olc)gy and its underlying mathematical model [v S90]. Researchers at NTR1, have Continuc!d to work on the SCR methodology, refining the model, providing a formal semantics, developing automated tools including co]lsistency and completeness checkers, and, lnost recently, exploit ing extant model checkers and theorem provers [HBGL95, BH97, AH97].

The levels of formalization are defined below, listed in order of increasing formality and effort. The purpose of this classification is to identify broad classes of formal met hods. The distinct ions underlying the classification are neither hard and fast, nor a measure of the inherent merit or mathematical sophistication of a technique. Instead, the distinctions reflect the extent to which a technique is both mathematically well- defined and supported by mechanized tools, yielding systematic analyses and replicable results. A7A 5’[email protected] 7

1. ‘1’hc use of notations and concepts derived from logic and discrete math to develop more precise requirements st atanents and spmificat ions. Analysis. if any, is informal. This level of formal methods typically augments existing processes without imposing wholesale revisiol~s. Examples include early formulations of the A-7 methodology [11+” 78, Hen80, vS90], varicms case- and object-ol iented modelitlg techniques [Bo091, CY91b, CY91a, RBP+ 91, Sys92], and hflills and Dyer’s Clcan- room methodolop;y [Mi193, 1.in94], although the latter is all excc!l)tion in that it supplants rather than augments existing processes.

2. l’he use of formalized specification languages with mechanized sul)port tools ranging from syntax checkers and ~)rettyprinters to typecheckers, interpreters, and animators. l’his level of formality usually includes supl]ort for modern software engineering constructs with explicit interfaces, for example, Inoc]ules, abstract data types, and objects. Historically, tools at this level haven’t offered mechanized theorem l)roving, although recent evolution of the follmvitlg tools has increased their support for mechanized proof: Larch [wSJGJMW93], RAISE [Gro92], SD]. [BHS91], VDh4 [Jon90], Z [Spi88, Wor92] and SCR [F’C87, HJL95, HLK95, HBG1J95].

3. ‘1’he use of formal specification languages with rigorous semantics and corre- s~)onding]y formal proof methods that support mechanization. Examples include HOL [GL493], NTqthn~ [BMW], ACL2 [KM96], EVES [CKM+ 91], and PVS [0 RSvH95]. State exploration [H0191, ID93], model checking [McM93], and language inclusion [Kur94] techniques also exemplify this level, although these technologies usc highly s~)ecialized, automatic theorem provers that are limited to checking properties of finite-state systems or of infinite-state systems with ccrtaill structural regularities.

One of the maxims of this guidebook is the importance of tailoring the use of formal methods to the task. In this case, the maxim implies that higher levels of rigor are not necessarily superior to lower levels. The highest level of formality may not be the most appropriate or productive for a given application. A project that intends using formal methods primarily to document tllc emerging requirements for a new system component would make very different choices than if they were formally verifying key properties of an inherently difficult algorithm for a distributed protocol. Implicit in the discussion is the importa~lce of selecting a formal methods tool appropriate to the task. A full discussion of factors influencing tool selection can be found in [Rus93a], and a summary is available in Volume 1 of this guidebook [NTASA-95a].

2.3.2 Scope of Formal Methods Use

‘The three most commonly used variations in the scope of formal methcjds application are listed here; others arc certainly possible. ]. Stuges of the development life cycle Generally, the biggest payoff from formal methods usc occurs in the early life cycle stages, given t}lat errors cost more to correct as they ~Jroccecl undetected through the development stages; early detection leads to lower life cycle costs. Moreover, formal methods use ill the early stages provides precision precisely u’here it is lacking ill conventional dcvelo~)l~lcnt methods.

2. SgslenL components Criticality assessments, assurance considerations, and architectural characteristics are among the key factors used to deterlnine which subsystems or components to analyze with formal nlethods. Since large systems are typically composed of components with widely differing criticalities, the extent of fornlal methods use should be dictated by ~)roject-specific criteria. For example, a system architecture that provides fault containment for a critical component through physical or logical partitioning provides an olwious focus for fornlal methocls activity and enhances its ability to assure key systenl properties.

3. System functionality Althcmgh formal mctllods have traditionally been associated with “ljroof of correctness, ” that is, ensuring that a system component meets its func~ional specification, they can also be applied to oI~ly the most important systenl properties. Moreover, ill some cases it is xnore important to ensure that a component does not exhibit certain negative prol)erties or failures, rather than to prove that it has certain ~)ositive l)ropcrties, including full functiol]ality.

2.4 Reasonable Expectations for Formal Methods

A formal methcd is llcither a panacea, nor a guarantee of a superior product. Realistic expectations are a functioll of the designated role(s) and extent, of formal methods use and of the project resources allocated to the formal methods activity. Judicious, skillful application of forlnal methods can cletect faults earlier than staudard development processes, thereby greatly reducing the iucide~lce of mistakes in interpreting, formalizing, and implementing correct requirements at~d high-level designs. Because formal methods encourage a systematic enumeration and ex~)lorat ion of cases, they encourage the early discovery of faults in requirements or high-level designs that would otherwise be discovered only d uri ug prc)grammiug. Of course, the same claim can be made for pseudocode, dataflcnv d iagl allls, or other quasi-formal not at ions that can be used early in the life cycle. The advantage of for[[lal methods is that by concentrating on what is required, they focus more direct ly on the topic of interest and avoid the distractions entailed by implementation factors. St rol~ger claims can even be made for fully formal techniques. Equally judicious, skillful applications of the most rigorous jormal methods can detect NASA-GB-001-97 9 more faults than would otherwise be the case and, in certain circumstances, subject to certain caveats, they catl also guarantee the abselIce of certaiu faults. III ~Jarticu- lar, by working car]y in the life cycle, on reasonably abstracted representations of the hardest part(s) of tllc cwcrall problexll, the hi.gllcst-level formal mctllods can validate crucial elements of the requirements or higlklcvel design. Finally, ill contrast to such techuiqucs as direct execution, prototyping, and sinlulation, wl)ich call cxl)lore a large, but necessarily incompleteset ofsystcm behaviors, deductive formal methods ald state exl)loration techniques support exhaustive cxamiuation of all bellaviors.~ The ext,ent to which a project realizes some or all of tile benefits described here deymds oIl the availability of essential resources, the skill with which formal methods use is tailored to the application, aud the dcgrm to which the exl)ec.tatiolls fit the dimensions of the ~)roject.

2.5 The IWethc}d Underlying Formal Nlethods

In the context of an engineering discipline, a method describes the way i~l ulhich a process is to be conducted. In the context oj system engineering, Q method is defined to consist oj (l) an underlying model oj development, (.2) Q language, or languages, (3) defined, ordered steps, and (4) guidance for applying these in a coherent manner. Most so-called jorrnal ?nethods do not address all oj these issues.. .. Indeed, tllejor~nal ~netlLods co7~L~~tu~Lity ltashee~l sloulto address such methodological aspects.5 [H~95b, p. 2]

Although the four elements in the preceding definition may be somewhat controver- sial, the observation that tllerc is a paucity of method in formal methods is not. The observation focuses in ~)articular 011 tllc a~)parent absence of “defined, ordered steps” and “guidance” in applying those methodical elements that have been identified. One reason for the absence c)f method is that the intellectual discipline involved ill modeling, slJecification, and verification eludes sim~)lc characterization; the intuitic)ll that guides effect ivc abstraction, succiuct spccificat ion, and adroit proof derives froxn skill, talent, and experience and is difficult to articulate as a process. F;xceptions to this observation include specialized methodologies for particular ap- ~)]ication areas, such as the area of embedded systems -- reactive systems that oper- ate continuously and interact with their elwironmc!nt, including l)arnas’s “four variable method’) [vS90, vSPM93], NRI~’s Software Cost Reduction (SCR) method [FC87, HBGL95], the Software Productivity Consortium>s Requirements Engineering (CORE)

4State exploration techniques require a “downscaled” or finite state version of the system and typically involve a more concrete representation than that used with theorem provers or proof checkers. These and related topics are discussed in Chapter 6. 5Thc material quoted here is based on a discussion in [Kro93]. 10 Cilapt er 2 method [FIIM7K92], and Harel’s Statecharts [Har87, H+ 90] and its derivatives, such as Levmon’s Requirements State Machine Language (RSML) [1. HIIR94]. Historically. the methods devclo})ed for reactive systems have ~)rovidecl organizing principles, com ce~)tual models, and in many cases, specification latlguagcs, and systematic checks for ~vell-formeclness of speciflcatiolls. Although many of these lncthodologies ~)rovide some mechanized analysis and arc currently exploring additional mechanized checks, few have yet to provide the range of analysis available in a true theorem prover or proof checker. Although the method i~nplicd in formal methods has been slow to emerge (with the exception of the methodologies noted above), broad outlines that effectively constit utc an “U1lderl~iIlg model of development” are worth noting. The process of applying formal methods to a chosen application typically involves the following phases: chmKkrizz7t.y the application, modelingfi, specification, analysis (validation), and documentation. The distinction between phases is somewhat artificial and should not be taken too literally. For exarnplc, it is difficult and not particularly imtructive to determine precisely where modeling ends and specification begins. Each phase consists of constituent processes. Again, the enumeration below is suggested, not, prescribed, and the overall process (i.e., the four constituent phases) is iterative rather than sequential. For example. characterization of the application may be influenced by consideration of potential models, the process of specifying the application may suggest changes to the underlying model, or the process of verifying a key property may trigger changes to the specification or even to the underlying model. Ideally, documentation accompanies all the phases summarized here:

. TIIC Characterization Phase: Synthesize a thorough understanding of the ap~)li- cat ion and the application domain.

o Conduct a thorough study of the application, noting key components and sub- components, i~lterfaces, essential algorithms, fundamental behavic)rs (nonli- nal and off-nominal), data and cent ml flows, and operational environment. 0 Identify and study related work, if any. 0 Acquire additiollal knowledge of the application domain, as needed. 0 Integrate the accumulated knowledge into a working characterization of the application. Some practitioners, especially those working alone, tend to “in- ternalize” an application, working strictly from mental notes. Other practitioners produce working documents and notes. The culture in which a project operates in large part determines the artifacts (if any) of this phase. Still, the importance of this phase should not be underestimated; total immersion in an application is crucial for developing insight into the most appropriate ]nodels and the most appropriate sl)ecification and validation strategies. In — 6As used her-c, the term ‘(model” refers to the mathematical representation of a systeui that uuderlies the system’s specification. In this usage, the “models>’ checked by state exploration tools or model checkers are viewed as spccificatious. ~TASA_ (3~_(j(71_97 11

some cases, such as hardware verification, there is considerable precedent and there am fairly well-cst ablished I )aradigms. There is also a st anclard paradigm for ~)roving hierarchical s~mcification chains, that, is, hierarchies of specifications at different lcve]s of abstraction (see Section 5.3). However, ill most other cases, there is often little apldicable precedent and them arc few, if any, established ~)aradigms.

● The Modeling l’hasc: Define a mathcnlatical representation suitable for forlllaliz- iug the application domain a~ld for calculating and ~)redictil]g the behavior of the a~)~)lication in that colltcxt. (See Clla~)tm 4.)

o I;lvaluate l)otential mathelnatical re~)resentationsl considering such general factors as the level of abstraction, generality, expressiveness, analytical power, and simplicity, as well as specific factors, such as the computational model, and explicit (implicit ) represent at ion of state and time. hlechanized tool support, if any, may also be a factor. The logic underlying a tool may support the use of certain mathematical representations and discourage the use of others. 0 Select the l[[atbcxnatical re~)rese:ltation most suitable for the application o Mode] key elements of the application and their relationships. As noted above, this (sut))process transitions into the specificatio~l phase.

● The Specification F’base: Formalize relevant aspects of the application and its o~)eratiollal cllvirolLtnent. (See Chapter 5.)

o l)cveloI) a s~w.cificatiorl strategy, colLsiderillg SUCIL factors as llicrarcllical (IIIul- tilm’cl) versus single-level specification, constructive versus descriptive specificatio~l style (SCC Section 5.2), and procedural and organizational issues, such as clc~wlo~)ing reusable theories and common definitions, and specification chronology. o Usi~lg the cllosell model and specification strategy, compose the specification. o A~ialyze tl~c syntactic and semantic correctness of the specification.

. The Analysis Phase: Validate the specification. (See Chapter 6.)

o Intq)ret or execute the specification. o I)rovc key l]ro~)crtics and invariants.

o llstatjlish the consistency of axioms, if any. o FJstablisll t}le correctness of hierarchical layers, if any.

● ‘1’he Documentation Phase: Record operative assumptions, motivate critical decisions, docunlellt tile rationale and crucial insights, provide explanatory material, trace specification to requirements (high-level design), track level of effort, and where relevant, collect cost /benefit data. ● Maintenance and Generalization: Revisit and modify the specification and its analysis as required, for example, to ~Jrcdict tl~e consequences of proposed changes to the modeled system, to accommodate mandated changes to the modclecl system, tc) support reuse of the formal specificatioll and analysis, or to distill general principles from the formalization and analysis.

l’ormal methods are supported in the s~)ecification and aualysis l)hases with lnecl(- animd tools that perform the steps shown in Figure 2.2. Tools that support user interaction typically provide these steps explicitly, whereas tools that, are fully automated do so implicitly. For example, most state exploration tools are fully automatic and do not prc)vide user control of the steps that check for syntactic and semantic consistency. h4echanized support for tile modeling phase exists, for example, in some of the informal object-oriented methodologies and in methods such as SCR. However, mechanized suplJort for modeling is not (yet) included in Illost formal methods (FM) systems and is therefore not represented in Figure 2.2.

Checks iyntactic consistency ‘llanslatis interual representation into display and outputs formatted text Checks semantic consistency

by syntactically and semantically correct s~mcification

and semantically correct specification

Figure 2.2: hlechanical Support for Specification and A1lalysis Phases of FM.

Except for documentation and maintenance, all the phases listed above form the core of subsequent chapters, beginning with the characterization phase. This chapter concludes with bacligrouncl regarding SAFER drawn from requirements documents and operations manuals typical of the kind of documentation used for developing an initial characterization of an application and its domain.

2.6 An Introduction to SAFER

Unless otherwise noted, this section is based on the SAFER Operations Man- ual [S AFER94a]. A more detailed version of the material, along with all figures cited in this discussion, can be found in Appendix C. A’AS.4-GI?-001-97 13

—. .. —. —.—.

MODULE —-. —

Figure 2,3: ~~lollt and back ~~i~r~~s of SAFER syst,e,nl WC)I-11 by NASA crcwmel~~t)cr.

SAFER, as shown in Figure 2.3, is a small, lightweight propulsive backpack system desigl]cd topro~'ide self-rescue cal)al)ility toa NASA space crewmendje rseparated during an EVA. ‘This could be necessary if a safety tether broke or was not correctly fastened during an EVA on a space station or on a Space Shuttle Orbiter docked to a s~)acx! station. SAFF.l L provides au attitude hold ca~)ahility and sufficient propellant to automatically dctumble atid (manually) return a separated crewrmember. A flight test versio~l of SAF13R was flown on S1’S-64 and STS-76, and production variants nave been used on the initial MIR docking flights. The SAFER flight unit. weighs approximately 85 pounds and folds for launch, land- ing, and on-orbit stowage inside the Orbiter airlock. SAFER attaches to the underside of the Extravehicular Mobility Unit (EMU) primary life-support subsystem backpack, without limiting suit mobility and is controlled by a single hand controller attached to the EMU display and control module. The hand controller contains a small liquid crystal display (LCD), two light-emitting diodes (LEDs), a small control unit with three toggle switches, and the hand controller grip, as shown in Figure C.4. The displays aud switches are visible frcnn all possible ‘ head positions inside the EMU helmet, and the switches are positioned for either lcft- or right-handed operation. The functions of the three displays and t hrce switches are c as follovrs:

1 1. Liquid Crystal Display: A 16-character, backlit LCD displays prompts, status information, and fault messages. R

s 14 Chapt a 2

2. I,ight-emitting L)iode: A red LED lat)elcd “TIIR” lights whenever a thruster-o~l condition is dct ectcd by the cent rol software.

3. L,igllt-ex~littillg Diode: A green I, RI) labeled “AAII>’ lights whenever automatic at t it udc hold is enabled for one or more rotational axes.

4. Switch: A three-position toggle switch labeled “I’J$7R’) l)owcrs on SAFER and initiates the self-test or activation test functions.

5. Switch: A three-position momentary toggle switch labckd “DISP>’ controls the LCD display, allowins the crewmember to select the previous or next parameter, message, or test step. The switch springs back to the center (null) position when released.

6. Switch: A two-position toggle switch Iat)eled “h40D13” selects the hand controller mod

The hand cent roller is a four-axis nlechallism with t hrec rot ary axes at Id one t rans- verse axis. To generate a command, t hc crewnmnber moves the hand cent roller grip (mounted on the right, side of the hand controller module) from the null center posi- tiol~ to mechanical hardstops on the hancl controller axes. q’o terminate a command, the crmvmember returns tile hand controller to the center position or releases the grip so that it automatically springs back to the center. Figures C.5 and C.6 illustrate the baud controller axes for translational and rotational commands, respect ively. For exaniple, Figure C.5 indicates that with the control switch set to translation mode. ~ Y commands are generated by ~)ulling or pushing t llc gri~) right or left, res~xxtivcly. Careful study of these figures reveals that the X translation command and the pitch rotation command are always available in either mode. A pushbutton switch on the top of the hand controller grip initiates and terminates automatic attitude hold. ‘The avionics software processes inputs from the hand controllers and various sensors, and includes the following components:

1. Control Electronics Assembly (CEA): The C13A microprocessor takes inputs from sensors and hand controller switches and actuates the appropriate thruster valves.

2. Inertial Reference Unit (IRU): The IRU senses angular rates and linear accelerations and is central to the attitude hold capability.

3. Data Recorder Assembly (DRA): The DRA collects flight-performance data, hand controller and automatic attitude-hold commands, and thruster firings.

4. Valve Drive Assemblies (VDAS): Each of the four VDAS, located with a cluster of six thrusters, takes firing commands from the CEA and applies voltages to the selected valves. NASA-GB-001-97 15

5. Power Supply Assembly (PSA): ‘1’hc I)SA produces regulated electrical power for all SAF13R electrical coln~mnents.

6. I1~strllll~elltatioll Electronics: SAFER instrumentation includes a variety of sensors, all of which arc listed in Table C. 1.

The avionics software has two princil)al functions: maneuveri~ig colLtrol for both commanded accelerations and automatic attitude hold actions, and fault detection, which supports inflight operation, pre-k;VA checkout, and ground checkout., A brief summary of tllc control function is prese]lted here. Sections C.1.4.2 and C.1.4.3 present a more detailed summary of the maneuvering control function atld an account of tllc fault detection function, respectively. The maneuvering-control software commancls bckh rotational and translational accelerations. Translat iox I commands provide accelcrat ion along a single translational axis and are prioritized so that X is first, Y is second, and Z is third. Wrhen rotation and translation commands are present simultaneously, rotation takes priority and tratisla- tions are suppressed. Conflicting input comlnands result in no output to the thrusters. Whenever l)ossiblc, acceleration is provided as long as a hand controller or automatic attitude-hold commancl is present. The SAFER crewmember cat) initiate (single-click) or terminate (double-click) automatic attitude hold at any time via the pushbutton on the top of the hand controller gri~). When terminated, automatic attitude hold is disabled for all three rotational axes. If a crewmernber issues a rotational command for a given axis when automatic attitude holcl is active, it is imnlediately disabled for that axis only. However, to ensure that, a failed-on hand controller command ill a rotational axis will not disable automatic attitude hold on that axis, automatic attitude hold takes precedence over a crewmen~ber- issucd rotational comnland if the two arc initiated simultaneously. Automatic attitude IIold provides an automatic rotational deceleration until all three axis rates are near zero. These near-zero rates arc automatically nlaintained whenever automatic attitude hold is active. Thruster-select logic t akcs accelcrat ion commands from the hand cent roller and from the automatic attitude-hold function, creates a single acceleration command, and chooses thruster firings to achieve the commanded acceleration. Thruster selection results in on-off commands for each thruster, with a maximum of four thrusters turned on simultaneously. llu-uster arrangement and designations are shown in Figure C .3. Tables C.2 and C.3 specify the selection logic. SAFER has 24 gaseous nitrogen (GNz) thrusters - four thrusters pointing in each of the +X, *Y, and + Z axes. The t hrustcrs are arranged in four groups of six thrust crs each, located as shown in Figure C.3. As l~oted, thruster valves open, causing the thrusters to fire in response to directives from the avionics subsystem, which commands as manj as four thrusters at once to provide six degree-of-freedom maneuvering control (+X, +Y, +Z, +roll, +pitch, +yaw). The SAFER propulsion system provides a total 16 Cklptcl’ 2 delta velocity of at least 10 feet IJCr second with an initial cllargc. ‘Tllc four GlV2 tanks have a relatively small capacity and require several recharges during an EVA. The recharge station is located ill the Orbiter payload bay. Whe~l SAFER is ]Lot itl use or if a malfunction (such as a failed-”oil thruster) occurs, the tauks can be isolated via a mauually actuated isolatiou valve. The SAFER example introduced here! is used throughout the guidebook to illustrate key ~)oiuts in each chapter. Although this example attempts to formalize the actual SAFER design, pragmatic and pedagogical considerations have inevitably resulted in differences between the act ual design atld the formal specification. These differences do not detract from the presentation of a realistic example that captures the basic characteristics of a class of space vehicles and the computerimd systems that control them. The fragment of the example chosen for inclusion at the end of each subsequent chapter focuses on the thrush’ sektioIl function responsible for creating an integrated acceleration commalld fronl hand controller and automatic attitude-hold inputs. Chapter 3

Requirements

Requirements define the set of conditions or capabilities that must be met by a system or system component to satisfy a contract, standard, or other formally imposed document or description [SFN7]. For example, IEEF, Standard 149S [I EEE194, p. 7] defines a requirement as “a characteristic that a systcm or software item must possess i~~ order to be acceptable to the acquirer.” Similarly, the NASA Guidebook for Safety Critical Software Analysis and Development [NASA-96, p. A-18] defines software requirements as “statements describing essential, necessary, or desired attributes. ” In the context of this guidebook, requirements are taken to be a statement of the essence of a system that is typically produced at or near the beginning of the life cycle and guides and informs the development, implement at ion, and maintenance of that system. 1 The number of st,e~~s between rcquirelncnts, capture, and ir~l~}le~t~c:~ltatiolI depends 011 the life cycle process for the system. Arguably, the more clearly articulated and differentiated the life cycle phases are, the more likely it is that the requirements statement will be suitable for formal analysis. A well-defined life cycle reflects a mature process, including an appreciation for the role and task of quality assurance. For example, a fairly typical, mature life cycle process might include requirements definition, system design, high-level design, ]OW-]CW1 cles@l, coding, testing (unit testing, component or function testing, systcm testing), user support, and maintenance. There are many considerations in the elicitation, capture, modeling, specification, validation, maintenance, traceability, and reuse of requirements, and a burgeol~ing group of researchers i~herested in addressing these and related issues. This activity has led to the recent emergence of a “discipline’ ) [FF93, I). vi] known as “Requirenlents 13ngineer- iug” that attempts to establish “real-world goals for, functions of, and constraints on software systems” [Zav95, p. 214] a~~d includes researchers in the social sciences as well as ill several areas of com~)uter science.2 1 This and similar remarks in Section 3.1.1 are not meant to suggest a particular life cycle model ‘Representative papers may be four,d in the proceedings of several IICIV conferences, including the biennial international symposium first held in 1993 [FU393, R1395] and the biennial international conference first held in 1994 [ICR1394, 1CRE9G].

17 18

3.1 Requirements and Formal Methods

This guidebook takes a less generic interest in requirements, focusing here on require-

ments as objects of formal analysis and, in particular: the characteristics of requirelnent,s that infiuencc the ap~dication of formal methods, ancl conversely.

3.1.1 Impact of Requirements Specification on Formal Methc)ds

The most important characteristics of requirements as objects of formal analysis ate the level at which the requirements are stated, the degree to which they are explicitly and unambiguously enumerated, the extent to which they can be traced to specific system components, and the availability of additional information or expertise to ~Jrovide the rationale tc) motivate and clarify the requirenlents definition (as necessary).

3.1.1.1 Level of Requirements Capture

Requirements for the early stages of the lif[! cycle, that is, up to and illcludiu~ the hi,gh- level design phase, should be reasonably abstract and focus on basic characteristics, including essential behaviors and key properties of the system. At this level, inqdenlen- tation considerations and low-level detail tend to distract ouc from the basic system functionality. Requirements written at too low a level or with too strong an inlplenlen- tation bias may require reverse engineering befc)re forlllal methods can be productively applied.

3.1.1.2 Explicitness of Requirements Statement

Requirements should also be completely, precisely, and unambiguously stated. At this level, the idea is to have a clear, precise statement that is reasonably complete and doesn’t admit multiple interpretations. This appears to cent radict the p!evious point, that the requirements be reasonably abstract and distill only essential behaviors and pro~)ert ies, but t}lere is really no cent radict ion. Clarity, precision, and completeness iuvol~~e explicitly identif.yiug underlying assumptions and thoroughly enumerating all relevant cases rather than specifying low-level detail and i~~ll)lex~lclltatioll factors. Am- biguous requirements that cannot bc further clarified may require the formal methods practitioner to define and explicitly record a set of operative assumptions to initiate the formal specification and aualysis. Ultimately, any operative assumptions, as well as the requirements specification, should bc validated.

3.1.1.3 Clarity of Delineation between a System and Its Environment

Requirements should clearly state the assutnptiom a system makes about its operat- ing envitolInlcnt and should clearly delineate the boundary between the system and its ATA SA_G~;-Ool _97 19 operative context. Fbr example, rcquirmncnts should explicitly identify environn~en- tat quantities that the system measures, cent rols, or assumes, such as temperatures, pressures, and user interface assumptions [HE\95a, p. 23].3

3.1.1.4 Traceability of Requirements

System-level requirements should be traceable to identifiable (functional) subsystems, components, ox interfaces. Requirements that cannot be so traced may prove diffkwlt tovalidatei ~~sofara stlleys lJecifys ystclll-levell >roIJertiesor t)ella~riortllat istoogcmeral or too ill-defined to he formally analyzed.

3.1.1.5 Availability of Underlying Rationale and Intuition

Requirements should also contain background material that motivates and illuminates the requirements statement. Although such material is typically excluded from requirements documents, it is often possible to find domain expertise, project personnel, and artifacts that provide essential information and insigl]t. Such supplemental lnatcrial is crucially important if the requirements statement is low-level, implementation-oriented, illco~nplete. or ambiguous. It is unusual to be handed a set of requirements that is well-suited to formal specification and analysis. Although formal methods provide techniques and tools for distilling a set of requirements from informal or quasi-formal spccificat ions and for exposing missing or incomplete requirements, formal methods are not a panacea. The practitioner should factor ill the availability and suitability of rcquircmcmts doculnents when considering a formal methods a~)j)licatioll. To illustrate. consider briefly the experience recounted in [NASA93], which describes an attempt to formalize the official Level C requirements for the Space Shuttle Jet-Select functioll [Roc9] ]. Although Space Shuttle flight software is exemplary among NASA software devclol)r[lent ~)rojects, the requirements analysis and quality assurance in early life cycle phases of tllc Shuttle used then-current (late 1970s and early 1980s) products and tools. Shut t k’ soft ware requirements are typically written as Functional Subsystem Software I{rxluirellleIlts (FSSRs) - low-level software requirements specifications written in English prose mid accompanied by secondary material inc]uding pseudocode, and dia~rams and fiowc}iarts Tvith imhousc notations. Interpreting the Jet-Select FSSR doc~&lents required the combined efforts of a mult icenter team for several months and relied extensively OX] resident expertise at IBM Federal Systems Division.4 WUlen a .—— 3This paraphrase of a statcmcmt by Parnas, who has been among the most vocal advocates for all explicit delineation bet ~veen a system and its wvironment, MZIS made in the context of computer soft ~rare systcwls, but the rmnark applies equally to other types of systems. 4The rnu]ticentel team consisted of personnel from N’ASA’s Jet Propulsion I,aboratory, Langley Research Center (LaRC). a!ld Johnson Space Center, and included subcontractors from Lockheed Martin Space hfission Systems (formerly Loral, and, prior to that IIILI, Houston) and SRI International. (The 20 Chaptm 3 new set of high-level Jet-Select requirements was formalized in the PVS .sI)ecification language, it bccameclearthat theJ&-Select function could twstated mores imply. TCI validate the PVS specification, approximately a dozel~ lemmas, derived from a list of high-level Jet-Select properties identified by IBhI, were formalized and proven. The fact that the algorithm and its essential properties are difficult to discern from the FSSRS illustrates two comldcnlentary points: (1) the potential problems of low-level requirements that only implicitly capture key prol)erties and essential functionality, and (2) the valueof supplemental sources and materials to provide crucial information]), for example, the list of desired Jet-Select properties and the clarifications provided by IBM domaiuexperts.5

3.1.2 Impact of Formal Methods on Requirements l’he applicat ioll of formal methods typically produces tangible artifacts, including formal models, specifications, aud analyses, that can impact the requirements to which they are applied. The nat urc oft he impact depends on the strategy used in the require- ~nents development process, and in particular, the degree to which formal methods are integrated illto the existing process. Fraser aud his colleagues [FKV94] attempt to classify integration strategies with respect to the following factors:

1. Does the strategy go directly from the informal recluirements to the formalized specification or does it introduce intermediate and increasingly formal models of the requirwncllts?

2. If the strategy introduces intermediate (semiformal) models, is the process OILC of parallel, successive rcfiuement of the requirements and the formal specification, or are the formal specifications derived after the (semiformal) requirelnents models have been finalized in a sequential strategy?

3. 10 what extent does the strategy offer mechanized support for requirements capture and for~~lalizatioll?

The question of mechanized support for requirements capture and formalization re- mai~ls somewhat academic, since the fully automatic characterization of requirements still relies primarily on research tools with limited scope and scalability. one example is a knowledge-based “specification-derivation system” that uses difference-based reasoning and analogy mapping to recognize and instantiate schemas and interactively -—. —.. _. work cited here was completed prior to either the Loral or Lockheed Martin er~$, hence the references to IBM.) ‘This example also illustrates the fundamental cost/benefit trade-offs that invariably arise Whell substantial reverse engineering is required before fornlal methods can be applied. These and related planning issues are discussed in Volume I of this guidebook [NTASA-95a]. ATASA _G~.@_JJ _97 21

derive specifications in a language similar to the Larch Shared Language [FKV94, p. 82]. Another example is the use of clata-flow diagrams and decision tables to develop “Struc- t ured Analysis” specifications that are then translated in VDM specifications by means of “interactive rule-based algcwithmic methods” [FKV94, I)p. 84-5].G of more immediate interest are the strategies that use an iterative a~)proacll to the successive refinement. of requirements. An example of the sequential applicatioll of the iterative strategy is the use of formal methods in certain re-engineering projects where the requirements are mat ure and well-established. However, it is the parallel application of the iterative strategy that, most substantively impacts the require~nellts definition. AIL example of this type of application includes formalization of immature requirements or formalization of requirements for ill-defined or ill-structured problem domains. In these cases, there is the “l)otential of lcttiug semiformal and formal specifications aicl each other in a synergistic fashion duriug the requirements discovery and refinement process” [FKV94, ]). 82]. lf this synergy is positive, the formal xnodels, specificat iolls. and analyses may ultimately become (part of) the requirements- a development some would applaud and others would view wit h concern. For example, Parlms [H B95a, p. 21] notes that “Eugiueers make a useful distinction between spcxificatious, descriptions, and models of products. This distinction seems to be forgotten in the computer science literature. >’ ‘This may be similarly applicable to requirements, models, a~ld s~)ccifications. On the other hand, active research into formal semantics and automated reasoning frameworks for industrially used notations [RS93, p. 191] points toward a coalescence in some environments of informal requirements with their formalization and analysis.

3.2 Conventional Approaches to Requirements Validation

It is well recognized that identifying and cor~ecting problems in the requirements and early-desig~l phase avoids far more costly fixes later. It is often said that late life cycle fixes are 100 times more expensive thau corrections during the early phases of software development [Boe87, p. 84]. Focused arguments for the utility of software-requirements analysis and val idat ion have become increasingly common. For example, Kelly [KSH92] documents a significantly higher density of defects found during requirements versus later life cycle inspections. IJutz [ljut93] notes that of roughly 195 “safety-critical” faults detected during integration and system testing of the Voyager and Galileo spacecraft, 3 were programming bugs, 96 were attributed to flawed requirements, 48 resulted from incorrect implementation of the requirements, aud the remaining 48 faults were traced to misuuderstoocl interfaces. Standard approaches to requirements analysis and validation typically involve nlan- ual ~)r-ocesses such as “walk-throughs” or I%gan-sty]e inspections [Fag76, Fa.g86]. The term walk-through refers to a range of activities that can vary from cursory peer reviews —— ——. ‘The relative immaturity of these particular activities does not reffect on the aclino}viedged maturity of formal methods techniques in general. See, for example, [Gla95, N!c195]. to formal inspections, although walk-throughs usually do not involve the replicable process and methodical data collection that characterize Fagau-style inspections. Fagan’s highly structured inspection process was originally developed for hardware logic. next apldied to software logic design and code, and ultimately successfully aplJlied to artifacts of virtually all life cycle phases, inducting requirements development and high-level design [Fag86, p. 748]. A F’agan inspection involves a review team with the following roles: a Moderator, an Author, a Reader, and a Tesicr. The Reader presents the design or code to the others, systematically walking through every piece of logic and every branch at least once. The Author represents the viewpoint of the designer or coder, and the perspective of the tester is represented, as expected, by the Tester. The hloderator is trained to facilitate intensive, but constructive and optimally effective, discussion. When the functionality of the system is well-understood, the focus shifts to a search for faults, possibly using a checklist of likely errors to guide the process. The inspection l)rocess includes equally intense and highly structured rework and follow-up activities. One of the main advantages of Fagau-style inspections over other con~’entional forms of verification and validation is that they can be applied early in the life cycle, fol example, to requirements and high-lcwl design. Thus potential anomalies can be detected before they become entrcmchcd in the 10 W-1CVC1 design and itll~~lell~elltatioll.

NASA supports a ~)rocess derived from Fa.gan inspections, called “Software Formal Ins~mctions” [NASA-93b, NASA-93a] that uses teams drawn from peers involved in development, test, user groups, and quality assurance. The scwen-step NASA process spelled out in [hTASA-93b] consists of planning. ovcrviev’, preparation key, inspection meeting, rework, and follow-up stages. NASA inspections use checklists, as well as stanciarclizcd forlns to recorcl ~moduct errors allcl collect metrics associated with the inspection process. g’he Colh!ction and monitoring of lnetrics is an integral part of NTASA’S inspection prc)cess bccausc it documents the progress of a project. If reiu- sl)ect ion is requirecl. scwcral of the steps may be repeated. With small variations, the NASA inspection process is USCC1 at several NASA centers, including the Gc)ddarcl Space Flight Center (G Sl~C). Jet I’rol)ulsioll laboratory (JPL) [Bus90], Johnson Space Cen- ter (J SC) 7, I,an@y Research Center (LaRC), and Leu’is Research Center (LeRC). The current validatic~ll I)rc)cess for N’ASA’s Space Shuttle flight software includes C1OSC ad- herence to the ins~)cct io~l process for requirements, high-level test plans, and source code [NASA93. ]). 21].

Although tllcxe processes are considered eflectivc and the quality of NTASA slluttlc flight softu’are is a?llong the highest in NASA software development prc)jects, the requirements analysis seems less reliable than the analyses performed on later life cycle products. F’or examl)le. [Rus93a, p. 38] notes that “a quick count of faults detected and eliminated during dcwlopmcnt of the space shuttle on-board software indicates that about 6 t itnes as n Iany faults ‘leak’ through requirements analysis, than leak through

‘~’he foruia] inspectiorls cited here are actually used by Locliheed hlartin Space Information Systems (formerly, Loral and, prior to that, IFlhl, Houston), the Space Shuttle soft~rare subcontractor. AJASA-GB-001-97 23 the processes of code development and review.” III light of these and similar observations, the following characteristics of the requirements analysis process have been uoted [NASA93, p. 9, 22]:

. Current techniques are largely manual and highly dependent on the skill ancl diligenceof individual inspectors and review teams.

● ‘l%ere is no methodology to guide the analysis process and no structured way for Requirement Analysts (RAs) to document their analysis. There are no completion criteria.

. Although these techniques catch a substantial number of defects, the density of defects found suggests that some errors escape detection.

● NASA projects using currently available techniques have reached a quality ceiling on critical software subsystems, suggesting that innovations are needed to reach new quality goals.

These types of issues constitute a significant part of the rationale for exploring the use of formal methods to complement and enhance existing requirements analysis and design analysis processes for critical aerospace and avionics software systems.

3.3 SAFER Requirements

I’he set of SAFER flight operations requirements used in this document are derived from three ofllcial project documents:

● Project Require~ncmts I)ocument [SAF’ER92]

● I’rinlc Itmn Developnlent S~mcification [SAFER941)]

● operations Manual [SA1’ER94a]

‘1’he derivation of these requirements illustrates challenges that typically confront efforts to formalize requirements for real-world systems. For example, the Project R+ quirements Document provided brief characterizations’ for major components and functions. Requirements at this level, such as those reproduced below, provide background information, but they are at too high a level to be useful in the development of formal specifications.

● The SAFER Flight Test Article shall provide six degree-of-freedom manual n~a- ncuveritlg control. ● The SAFER Flight q’est Article shall provide crcwll~cl~lber-selectable. three degrec- of-freedom Automatic Attitude Hold (A AH).

The Prime Item Developmmit S1)ecification, while more informative, lacks detail ill certai~l critical areas. In gclmal, the O1)erations hlatmal, which was not, intended as a requirements document, provides t hc most consistent )y useful in format iou. Ultimat cly, synthesizing tllc material from two of tllc three sources was necessary first in order to characterize a system that, could be meatlingfully formalized. A subset of the requirements from the Prilne Item Development Spmificatiou w’as augmented with more details from t hc O1)erat ions h~anual. This inherently subject ivc process, described here, was guided by the need for requirements that, provided a workable level of detail basecl on a well-defitled systenl architecture. If existing requirements documents directly support the applicatioll of formal methods, or if domaill expertise is readily available, the process dcscrihed here would not, bc necessary for formalization and analysis. Tile subset of the recluirements presented here (numbers 37 - 42) focuses on the thruster-select function of the avionics software. Only the requirements that directly sl)ecify thruster selection have beml i~lcluded; those indirectly iuvolved, such as the requirements that specify components providing thruster-selection input (the hand com troller unit) and output (the propulsion subsystem), appear iu Section C.2, which coll- tains the full set of SAFER requirements. Requirements 37 - 42 below specify the two basic tllruster-select functions: (1 ) integrating the in~nlt from the hand controller and automatic attitude hold (AAH) into a single acceleration command and (2) selecting the set of thrusters to accomplish the command. This functionality is specified through a combination of high-level “shall” state; nents aI~cl lower-level tables that clcfilie the thruster-select logic. The nuuli)ers associated with each requirement correspond to those used ill Appendix C.

37. The avionics software shall disable A AH on all axis if a crewmember rot at ion command is issued for t}lat axis w~lilc AAII is active.

38. Any hand controller rotation command present at the time AAH is initiated shall subsequently be ignored until a return to the off condition is detected for that axis or until AAII is disabled.

39. Hand controller rotation cO1lllllaUds shall suppress any translation commands that, are present, but A AH-gcncrat ed rot at ion commands may coexist with translations.

40. At most one translation comu~and shall be acted upon, with the axis chosen in priority order X, Y, Z.

41. The avionics software shall provide accelerations with a maximum of four simul- taneous thruster firing commands.

42. l’he avionics software shall select thrusters in response to integrated A AH and crew-generated comma]lds according to Tables C.2 and C.3. Chapter 4

Models

The term nlodel is usc!d in two diffcrcmt, alt)cit related, ways in the context of formal methods. On the one hand, “model” is used to refer to a mathematical representation of a natural or man-made systc~l~. This is consistent with tile usage in science and engi- neming, where mathematical representatio~ks are used to predict or calculate prol)ertim of the systems being modeled. Tile statistical models used to analyze and predict llle- teorological phenomena and the models of ~)lanet ary mot ion used to calculate satellite launch trajectories and orl)its are examples of these types c)f mathematical nlodels, as are the state machine models used to explore the behavior of complex hardware a~ld soft warw systems. A second usage of tile term “model” derives from precise terminology in formal logic and refers to a mathmnatical reprcmlltatioll that satisfies a set of axioms. Exhibiti~lg a model for a set of axioms demonstrates that the axioms are consistent. For example, one way to show that a specification is consistent is to show that its axioms have a model, as discussed in Chapter 6. This chapter surveys characteristics of the types of mathematical models used in forma] methods and concludes with a discussion on modeling the SAFER thruster selection function.

4.1 IMathematical NIodels

; Wllilc there is no ambiguity about the meaning of the term “model’ il ~ the formal logic sense, and lit t le confusion about its informal use in the real world of concrete objects, there is residual confusion surrounding the informal use of the term to refer to nlathematical objects. For example, when speaking of real products, such as jet planes, there is I1O problem in distinguishing the notions of Inodel, prototype, specification, and description. A model of a 747 may or may not be flightworthy and fit on a desk. 1 A 1 Jackson [Jac95, pp. 120-122] follow Ackofl [.AM2] ixl distinguishing three kinds of model: iconic, analogic, and analytic. Using this three-way distinction, the model of the 747 is iconic, that is, the

25 prototype, on the other hand, would be one of the first 747s built and would cxllit)it most, if not all, key properties of the actual 747 aircraft, including the ability to accommodate 350 passengers. A specification of the 747 would capture certain important l)roperties of the 747, l)ossibly includi]lg the property that dimensions of the wing stand in a certain relationship to the overall dimensions of the plane. A description is the least constrained representation] and may even include such useless detail as the fact that the plane has a rather bulbous profile. 2 ~n the other hand, Parnas’ definition of a model as “a product, neither a description nor a specification. ” [Par95~ p. 22] explicitly acknowledges a confusion in the context of formal methods, where models and specificat ions are frequently conflated. Concurrency provides a case in point. “It’s not that one usually wants to specify concurrency, but rather to study the properties c)f a model of concurrency resulting from a specification of a system.” [CS89, p. 89]

4.1.1 Characteristics of Mathematical Models

In the context of forulal nwthods, the II1OSL useful nlodels tend to be abstract representations that focus on essential characteristics expressed in reasonably general ternls and forn~alized in judiciously chosen nlathenlatics, that is, in nlathen]atical representations that are suitably expressive and provide sufficient analytic power. Of course, accuracy with resl)ect to the system being modeled is also essential.

4.1.1.1 Abstraction

Exploring the relationship between modeling and specifying a concrete (ph~rsical) object, such as the 747, yields insight into desirable characteristics of abstract (mathematical) models. For example, while it is possible to build a full-scale model of the 747, it is almost certainly more useful to abstract away less important or less relevant features of the 747 alld concentrate on the simplest or most general ex~)ression of essential features of interest. Two highly desirable consequences of creating suitably abstract models arc the elimination of distracting detail and the avoidance of pmniature i~~lple~l~er~tatiol] commitments. For example, imagine using a desk-size model to discuss properties of the overall design, that is, the layout and proportions of the aircraft, and of certain components, such as the shape of the fore and aft sections of the wing, while ignoring pro~)cxties relating to the aircraft’s size or to the structural materials used to build it.

The choices of mathematical represcutation and level of abstraction carry inherent implications that must be explicitly considered. For example, Hayes describes the implications of certain choices for modeling a simple symbol table. —— — —— 747 model is an icon of a real plane. See Section 4.1.1.3 for a brief discussion of analogic and analytic models. 2The 747 example is based on a discussion in [Par95]. NASA-GB-001-97 27

‘(We are describing a symbol table by modeling it as a partial function. . . . Here . . . we use it [the function] to describe a data structure. There may be many possible models that wc can use to describe the same object. Ot hcr models of a symbol table could he a list of pairs of symbol and value, or a binary tree containing a symbol and value in each node. But these other models are not as abstract, because many different lists (or trees) can relJ- rcsent, the same ful~ct ion. Aud we would like two symbol tables to be equal if they give! the same values for the same sylllbols.” [Hay87, p. 39]

4.1.1.2 FOCUS

A model defines the space that can be explored by virtue of the (concrete or abstract) representation choices it reflects, but it does not prescribe the exploration per se, which is the role of the specification. The desk-size model of the 747 facilitates certain kinds of questions and precludes others. These limitations are a direct consequence of the nature of the model, reficct ing choices with respect to both focus and mathematical representation. For exatnple, the desk-size 747 does not lend itself to a study of either the safety ~Jropcrties of the airplane’s fly-ly-wire system or the tensile pro~mrtics of production-grade materials. The same tyl)e of caveat applies to the abstract models used in formal methods. “AS with any model, we will have to deterlnine what aspects of reality we deem important and will have to ignore others. We must be quite clear. therefore, on the boundaries of our models” [CS89, p. 94].

4.1.1.3 Expressiveness Versus Analytic Power

There is inevitably a tension between expressiveness and analytic power, as notec] in the following quote [CHJ86, p. 9].

K . . . in general, the larger the class of systems that can be described, tile less is analytically decidable about them. This unfortunate property of mathematics means that great care and mathematical sophistication must be applied to the design of models, especially if a lower level of sophistication is to be expected of the engineers who use them. ”

Although the author of this quote is talking somewhat pessimistically about engineering models used to conlpute stresses, mass, friction, and so forth and appears to equate expressiveness and descriptive generality, his observation about the tension between expressiveness and analytic potential is worth noting. In the context of formal methods, expressiveness is typically used to refer to the ability to naturally and effectively char- act erize a behavior or property of interest. Although .generalit y certain ly plays a role, it is not the only hallmark of expressiveness. The analytic potential of a model is crucial in formal methods applications because it is precisely the ability to analyze, that is to calculate and predict, that confers the power and utility of formal methods. 4.1.1.4 Intuitive Versus Nonintuitive Representation

A furthm consideration can be characterized as naturalness of expression. that is, the extent, to which a mc)dcl should be intuitively similar to the physical object it represents. Jackson [Jac95, pp. 120-122] cites the exatnplc of an electrical network used to model the flow of liquid through a network of pil)cs. ‘1’he example is due to Ackoff [Ack62], who terms it an amdogic model; the wires are analogous to the pipes, aud the flow of current is analogous to the flow of liquid. Ackoff also identifies a class of models that he terms analytic, by which he appears to mcau that the mode] embodies au analysis. For example, a set of differential equations describing how prices change is analytic because it expresses the economist’s anulysis of the relevant part of the economy. ‘1’his is a somewhat different use of the term “analytic’) than that of Cohen (above) and most , of the literature on formal methods. Although Ackoff ’s classification is nc)t necessarily advocated here, the notions of aualogic and analytic content of models are useful.

4.1.1.5 Accuracy

Finally, it is important to be aware not only of the limitations of models used for formal methods, but also of their accuracy. Just as s~wcification and analysis are constrained by the nature of the model, the ultimate utility and validity of the specification and analysis are limited by the degree to which the model is an accurate repmentation of the system modeled.

4.1.2 Benefits of Mathematical Models

The advantages conferred by mathematical models are effectively those associated with the more rigorous levels of formal methods, namely

● Mathematical models are more precise than an informal description written in natural language or in quasi-formal notations, sLlch as pseudocode, diagrammatic techniques, and many CASE notations. One aspect of precision is the need to ex- amine and make explicit all underlying assumptions; hence, mathematical models also tend to force a more thorough aualysis.

● Mathematical models can be used to calculate and predict the behavior of the system or phenomenon modeled.

. Mathematical models can be analyzed using established methods of mathematical reasoning. The axiomatic method that provides a discipline for proving properties and for deriviug and predicting new behaviors from those already known is an example of one sLlch method, in this case drawn from mathematical logic.3 —————— —.— 3See Chapter 6. h7AsA_~~.ool_97 29

Grim aud Schneider [GS93, p~). 2-3] use the cliscovery of the planet Neptune to illustrate some of these benefits of mathematical models. Since it is a particularly nice exalnp]c of tllc calculative a~ld ~)redictivc power of mathcnlatical models, the story is mcouuted here. In t be early 1800s, it was Iloted that there were discr[!pancies between observations of the planet Uranus ancl tlIe extant mathcur)atical lllodels of planetary motion - largely those formulated by Kepler, Newton, and others begiuuing in the seventeenth century. l’he lnost likely conjecture was that the orbit of lJrauus was being affect ed by a~l unknown planet. Ix] 1846, after two to three years of feverish manual calculation, motivated in part by a prim offered by the Royal Society of Sciences of Gtittingen in Germaty, scientists converged OIL the probable position of the uuknowll pla~let. That same year, using telescopes, astronomers discovered ATept ut Le itl the position predicted by the models.

4.1.3 Mathematical Models for Discrete and Continuous Domains

in au introductory cha~)ter to his classic history of mathematics viewed through the lives and achievements of the great mathematicians, E. T. Bell notes that

“. . . from the earliest times, two oppositlg twldencics, sometimes hel~)itlg one another, have governed the whole involved development of n~athemat- ics. Roughly these are the discrete aud the continuous.’ ) . . . The discrete struggles to describe all nat urc aud all Itlat hemat ics atonlist ically, iu terms of distinct, recognizable individual elemeuts, like the bricks in a wall, or the l~umbers 1 ,2,3,. . . . ‘lThe collt illuous seeks to apprwkmd llat ural phcmon~e~la-- the course of a Planet iu its orbit, the flow of a current of electricity, the rise and fall of the tides, aud a nlultitude of other aplmaranccs. . . .“ [Be186, p. 13]

This dichotomy is, of course, reflected in the mathematical models used to explore the respective domains. The introductory comments in earlier sections of this chapter have becm chosen to apply equally to both discrete and contiguous models, thereby enll)llasizing the commonality between the fundamental role of models in both nlathematical domains. Recently, a growing interest iu hybrid systems - that is, systems composed of cent inuous components selected, controlled, and supervised by digital components - has led to an iutcgration of discrete and continuous models. The resultiug modeks integrate the different ial-difference- type equat ions used in classical models of continuous physical systems with the mathematical logic and discrete mathematics used ill conventional models of digitial systems.4 For most of this chapter, tllc focus will bc the discrete domain models typically used in formal methods. JVhile the mathematics ex~)loited in models for discrete domains

4Reprcsentativc papers may be found in the proceedings of several recent }vorkshops, including [C; NRFt93, .AKNS95, AIIS96].

— 30 chapter 4 is generally simpler thau that for continuous domain models, it is also less familiar to those with e~lgilleeritlg t)ackgro~l~lcls. WTith this in mind, a small example from control theory is presented first. The technical details of the example are not inlpoxtant; the focus here is not on advanced control theoretic methods, but c)n modeling tecl~niqum.

4.2 Continuous l)omain h~odeling

This discussion illustrates the use of continuous rnathema~ics to n~ode] an exam~)le drawn from spacecraft attitude control. The example was chosen to allow the reader to compare and contrast the continuous nlodcl with the discrete model used for the SAFER example, both of which derive from the domain of spacecraft attitude control. In both cases the goals are the same: rigorous description and prediction of behavior.

~~~hat differs are the ~haractf~r of t~lc underlying nlathelnatics and the techniques used for calculation. A rigid body or spacecraft in a stable orbit may experience rotational motions that require correction or nulling. A fixed or slowly rotating attitude, pointing the spacecraft at a specific target or in a specific directiou, is typically desired. Solving this problem requires a model of rigid body dynamics and, once a cent rol strategy is adopted, a model of the expected behavior under the desired cent rol regime. The mathematical basis for such models is invariably that of differential equations, which offer a well-understood theory to support calculation and ~)rediction. Following 13ryson [Rry94], the rotational motions of a rigid body in space can be nlodclcd as follows: let tlle angular velocity vector d be defined with respect to the center of mass and principal body axes, making the products of inertia zero. Let 7, ~ k be the unit vectors along the z:, y, z principal body axes so that

I)enote by ~r, IY, 12 the monmnts of inertia, and by Q~, Qu, Q. the ~ody-a~is COl~IPO- mmts of the external torque. The equations of motion describing the body rotations are then given by lr~ -..’(IY -- 12)qr = Q* IYg - (12 – lr)71~ = Qy (4.2) Iz; -- (lr -- Iv)pg = Q, where the time derivative of quantity v is denoted v. The resultant extel nal torque @ includes any intentionally applied torques as well as disturbance torques from sources such as gravitational or magnetic fields. Consider the problem of achieving attitude hold, that is, applying a time-varying torque to hold a rigid body’s rotation at zero or near-zero levels with respect to inertial space. Assume first that any disturbance torques present are small compared to the applied torques and hence may be ignored. This situation exists for “fast attitude hJASA-GB-001-97 31 control” based on the usc of thrusters. Assume further that the mass ~Jropertics of the rigid body are sufficiently symmetric about, the axes so that the axes Inay be regarded as decoupled and control can bc achieved for each axis i~ldcpendently. Finally, assume that appropriate sensors are available tc) sense both attitude and attitude rate for the axes of intemt. FoI’ purposes of this discussion, consider a single axis o~dy, the principal y-axis, whose attitude deviation is denoted by O and attitude rate by 0, where ~ equals q from equations (4.1) and (4.2). If the thrusters are proportional, that is, they can be throttled to provide variable amounts of thrust, then attitude control can be achieved using a simple linear control law. The applied torque is derived by feeding back a linear combinat ic~n of attitude deviation and attitude ratf!:

Ivti = Qy = --D8 - K(I (4.3) hJotion will be stabilized as long as D > () a~ld K >0. Proportional gas jets for attitude control are impractical, however, and the more typical method is to use thrusters whose valves are either completely open or completely closed. This leads to what is often termed “bang-bang’ ) control. In pure bang-bang control, thrust is switched between one thruster and its opposing jet, exactly one of which is on at all times. Thus, the control torque has only two values. Q1 and –Q7. Attitude deviation can be reduced through rlolilincar control to nearly zero by ap plying the torque Q = - Q~ Sg11(6 +- @ (4.4) where 1 ifz->0 Sgn(z) == (4.5) -1 otherwise { and I- is a const,ant making O + TO a linear switching function, thereby defining a line in the 0-0 phase ~dane across m’hicll thrust reversal occurs. Using this control logic results in the following relationship bctwcxm Q and the attitude quantities: 2Q I .2 (%3- e--eo+ moo (4.6) ( )

The model predicts a convergence process that drives both O and ~ toward zero, where they will eventually enter a limit cycle surrounding O = ~ = O. A further refinement in a practical design would add a “dead zone’) around the desirccl attitude where no thruster firing occurs. Such a scheme is used in the SAFER system described in Appendix C. Hysteresis is typically also incorporated, resulting in control laws with additional nonlinearities. In such cases, the modcd shown for pure bang-bang control is embellished to capture the more elaborate limit cycle behavior. The focus now shifts from continuous clomain Inodeling techniques to those of discrete CIO1llain modeling. 32 Chapter 4

4.3 Discrete Domain Nlode]ing

~’llis discussion of discrete domain models is intended to be representative rather t hall exhaustive. To that, end. the discussion is framed in terms of fc)ur broad classes of discrete domain models: functional, at)stract state Inachincj automata-based, and objcct- oriented. Of course, there arc variants and shadings both within and between these classes, so that the four categories represent a descril~t ively useful. but so]uewhat art i- ficial classification. As the application of techniques from logic alld discrete mathematics to proble~us of interest in computer (hardware and software) systems, formal methods inherently concern computation. El-y the same token, one of the ways ill which formal methods usually differ from traditional uses of logic and discrete mathematics is that, they incorporate a model of computat ion. The model of computation may be built in, that is, implicit, as it is ill Hoare logic [Hoa69] and its variants, such as VDh!l [Jon90] and Z [Spi88, Wor92]- meaning that, there is a built-in notion of program State, and a set of constructs for composing operations that affect the state. Or it may be constructed on top of an “ordinary>’ logic as Hoarc logic may bc defined within nigher-order logic [Gor89]. The advantage of the built-in approacl~ is obvious when the built-in model is appropriate to the task at hand. The advantage of the “constructed” approach is that it is possible to tailor the model to suit the circumstances of a given application. For example, adding concurrency to a sequential Hoare logic is not cas}’– it generally cannot be done within the logic, but, requires metalogical adjustments- whereas various models of parallel computation can be encoded in higher-order logic. One of the key decisions in developing models for formal methods applications is the relevance, if any, of the underlying model of computation, that is, the extent to w}lich the u!lderlying computational paradigm should be explicitly modeled. It is useful to keep this i]] nlillcl during the discussion of discrete-domain models.

4.3.1 Functional Modelss

A functional model is OI(C that employs the mathematical notion of fullction in a pure form, oftm in conjunction with an implicit and very simple computational model. A surprisingly wide variety of algorithms can be adequately described as recursive functions, assuming the most clenwntary model of computation, namely, the operation of function composition. For example, one of the crucial insights in the specification and analysis of the Byzantine Agreement protocols [Rus92] was the observation that a sinl- ple funct ional model of computation is sufficient, that is, it is not necessary to explicitly model the (inherently complex) distributed computational environments in which these —.————— 5Models for synchronous hardware circuits arc used to illustrate many of the ideas in this section. Alt houg,h these hardware models suggest lower-level, more architectural issues than those discussed elsewhere in this guidebook, the simple hardware models provide more concise, transparent examples of the modeling techniques in question than are typically a~ailabk with requiren~ents-level specifications NASA- GB-001-97 33 protocols normally execute. 6 For a more concrete example, consider a functional model for a simple synchronous hardware circuit, such as a binary (full) adder that takes three one-bit inputs x, y, and c.i (carry-in) and ~moduces sum and carry-out bits s and c-o, respectively. In the functional model, a block with several outputs is modeled by several functions, one for each output,7 and “wiring” is lnodeled by functional composition. Us- ing this functional modc!l, the binary adder would bc then be specified by two functions, one each for s atld c-o:

S ( X , y, c.i) = (x + y + c_i) rem 2—.-— —. rc_o(x, y, c_i) = (x + y + c_i) div 2 .1 The relational model, first popularized by Mike Cordon for hardware verification [Gor86], is a varialt of the functional model that exploits the more general notion of mathematical relation. In tlw relational model, a functional block is represented @ a single relatio]l on the input, ancl output ‘(wires” that specifies the overall input-output relation. For example. using the relational model, the adder might be specified by the following relation: ———. — —— adder (x, y, c_i, s, c_o) = [ (s = (x + y + ——c_i) rem 2 AND c_o = (x + y + c.i) div 2)s .---1

In the relational model, composition is accomplished by identifying “wires” with variables, conjoining the relations representing the individual blocks. and using existential quantification “to hide” the internal wires. For example, the i~l[~~lel~~exltatiol~ of a full adder ill {erms of half adders aIIcf a 11and9 gate can be accomplished by the circuit shown in Figure 4.1. A half adder takes two itl~)uts a and b, and produces sum (s) and (complemented) carry (c) bits satisfying

L-—-half. adder (a, .b, . s,. c):..p. bool = ––-–(2 * (l-c) + s = a + b) -1 while a nand gate produces an output (o) that is O if the sum of its inputs is two, and 1 otherwise: 6John Rushby provided this observation, which he credits, in turn, to Bill Young [E) J’90]. ‘In a language such as PITS, that has tuple-t~pcs, a single function that produces a tuple, that is, lmndle, of values could be used. 6A more “requirements” oriented version would be adder (x, y, c.i, s, c_o) = (2 * c_o + s = x + y + c_i) (witl~ type constraints restricting all variables to the values O and 1). g A’and is also known as the Shc~er stroke and symbolized as “1”. .4s the name suggests, nand is defined as the negation of the and (A) operation. Using IJe J’lorgan’s la}vs, the A and V (or) operations, and Boolean variables T and y. naud is defined

The nand and nor (7Lot or) operations played an iInportant role in logical design because each is ~unc- tuma~ly cornpkk, that is, every switching function can k)f? expressed entirely in terms of either of these t~vo operations. 34 CXaptcx 4

~. .-. –– -1

Figure 4.1: lrtl~~ler~lcrltatio~l of a Full Adder.

Lnand(x, y: o): bool = (o = IF x + y = 2 THEN O ELSE 1 ENDIF) ‘--] The ‘bwiril~gdiagranl” of Figure 4.1 is then spccificd by the formula _—— ——-—. . .—. -——— . .. ———. ——.. -—-— EXISTS p, q, r : [-----half_adder(x, y, p, q) AND half_adder(p,—. -.. ————.—.c_i, s, .— r) AND nand(r, q, c_o) . ..1 Tlleadvalltage of tllefl~tlctiollal approacl) is that it can lead to very simple andef- fect ivc t hcorem proving- basicallyjust term rewritil~g,allclcatl be ’’executed” to yielda ‘(rapid prototype.” Theadvantages ofthe relational approach are that it directly corre- spondsto wirillgdiagranls (variables correspond exactly to wires, relations to functional blocks), and that it cat) co~)e with feedback loops. It isoften possible tc)conlbillethc methods, as it) the first of tllc relational “adder” examples above, where the conjuncts to the relation correspond directly to the functions of the functional model. The combined approach may additiollall.v involve an explicit representation of state.

4.3.2 Abstract State hflachine Models

A state machine model typically consistsof an abstract represcntatio no fsystcm state and a set of operations that Illanilmlate the state to effect a transition from the current to the next state. I:igurc 4.2 illustrates a basic abstract state machine model. The state machine trallsitiorl function is a mathematically well-defined function that takes input values and current-statevalues, and mapsthem into output andnext-state values. Representin gc!ac~lo ft~vX’va luesasavcctor, this futlction, A4, carlbecharacterizcdas follows, wllercl atlclC)a rc:il~~)~ltsa lldout~>llts,r es~~ectively,a lldSisa setc)fstates. Note that this fcmmalization does not explicitly represent, the distitlction between current- and next-state values. M:lxs-->[oxs]

AI can be used to capture the functionality of a givell system, as well as to formalize abstract properties about system behavior. For example, if sequences I(n) = NASA-GD-UO1-97 35

state Inputs — outputs 4 Machine 1-

Figure 4.2: Abstract State h4achinc N40del.

< i] ,.. .,z7L>and O(n)= =<01, . . . . 07L > denote the flow of inputs and outputs that, would occur if the state machine were run for n transitions, then a property about the behavior of M could be expressed as a relation 1’ between l(n) and 0(7t). Ultimately, it WOUICI be possible to formally establish that the property P does indeed follow from tllc formal specification Af. The A-7 methodology [H+ 78, IIen80, vS90, Par91, Ph491] developed for describing the requirements for control systems illustrates how the state machine model can be specialized to accommodate a particular type of application. In this case, the basic idea is that a control system can be modeled as a control function plus a state. The system evolves in tinle: at each iteration or jranle it reads the values of ccrtaixl monitored vuri- ables, that is, it samples scmsors, consults tl~e current values of its state variables, and computes a function that yields a pair of results: new values for the state variables and output values fix the control variabks. The dataflow diagram in Figure 4.3 illustrates the basic A-7 mode] for a system with one monitored variable x m, one cent rol variable y-c, and a single state variable z, which is denoted z-s and z_f according to ~rhether it is being read from, or written to, the local state. The purpose of a requirements specification in this context is to specify the box labeled “control.’) 10 specify this model of computation explicitly, the variables x-m and so on would be modeled as traces: functions from time (that is, frame number) to the type of the value concerned. For exanq)le, x m(t) is the value of monitored variable x-m at time (frame number) t. It is then possible to specify how the outputs are computed and how the renaming of .f variables to .s variables occurs by means of the set of recursive equations:

‘y_c(t) = f (x_m(t) , z_s(t)) z.f(t) = g(x_m(t), z_s(t)) [ z_s(t) = z_ f(t-1) — “ - I where f is a function that specifies the computation for the control output aud g is a fuuctic)n that specifies how the local state value is updated (see Figure 4.4). III general, 36 (Xaptct 4

Xml

......

y.c

Figure 4.3: A-7 Model of a Silnple C;ontrol System. there will be many nlonitored, controlled, and state values, aud those values thenlselves can bc vectors of values or arbitrary data ty~)es. On the other hand, if there is noneed to reason about the evolution of the system over time: a far simpler representation that uses pure functions on simple values rather than traces lllaysLlfice tos~)ecifyl~our the “new” values of the various state and output variables are derived in terms of the monitored and “old” values. The conceptual model used to formalize the Jet Select function of the Space Shuttle flight software [NASA93] ~Jro~’ides an example of this approach. Jet-Select is a 10W-1CWWI Orbit DAI’ control function that is responsitic for selecting which Reaction Control System jets to fire to achieve translational or rotational acceleration in a direction determined by higher-level cent rol calculations or crew input. In the pilot study cited, the behavior of a component. such as t,hc rotation compensation module, would be represented by a function that models the external interface to the function. hTote the explicit, representation of prior- a~ld next-state values in the signature of the function, ~.

~: external inputs x prior state inputs --> [external outputs, next state outputs]

4.3.3 Automata-Based Models

An automaton is a finite-state transition system consisting of a set of states and a set of state-to-state transitiolls that occur on input symbols chosen from a given alphabet.

4.3.3.1 *-Automata

Automata may be deterministic, nleaning that there is a unique transition from a given state on a given input, or non deterministic, me,aning t hat there are zero, one, or more NASA -GB-001-97 37

x-m I

z-s–

Z.f” I L_____... _J . . . ..J *.A

Figure 4.4: State-UIJdate and Actuatc)r FLltlctio!lsv~it~li~l Control System

SUC1) transitions. Formally, a detcmninistic finite automaton is defined as a 5-tu~Jlc (S, X,6, S0,F), where Sisa finite set of states, Xisa finiteinput alpha~ctj so is the i~litial state, F Q S is the set of final states, and 6, the tratlsition function, maps S x X to S. A nondeterministic finite autonlaton is similarly defined as a 5-tuple, the only difference lleing that 6 is a map from S XX to the powcrsct of S, written P(S). In other words, 6(s, a) is the set of all states St such that there is a transition labeled a from s to s’. A thorough introduction to finite automata may be found in [Per90].

Conventional or *-autonlata accept only finite words and can express state invariant, that is, safet

—— 1°Fairness constraints specify, for exaruple, that certain actions or inactions do not persist indefinitely or that “certain sequential combinations of actious are disallowed” [Kur94, p. 57]. Anticipating the discussion in section 6.2.1.1, a fairness property can be defined as an LTL property (p) of the type GF(p). This definition uses CTL* syntax; the definition could also be written Usi[lg I,TL operators. 38

4.3.3.2 w-Automata q’o accommodate eventualities, it is necessary to use a class of automata that accepts infinite words (sequences), the so-called w-automata. Like a conventional automaton, au w-automaton consists of a set of states, au i~lput alphabetj a transitio~l relation, a~ld a dis~inguished initial state. ‘1’he difference between the two classes of automata occurs in t]le definition of acceptance. Acce~Jtance for a conventional automaton is defined in terms of a final state. Since the notion of final state is not useful for a class of machines that accepts infinite words, acceptance must be defined in some othcx way. lrarious accept auce conditions have been given for w-aut onlat a [CBK90, p. 104], two of which are given below. ‘1’he definitions that, follow are based on a discussion in [CBK90]. A (uondetermiuistic) w-automatoll is a 5-tuplc (S, 2,6, so, Y_), where S, Z, and so are as defined above, .7 is an acceptance condition, and 6: S x Z ~ P(S) is a transitioll relation. The automaton is deterministic if for every state s E S and every a c X, 16(s, u) <11. A comprehensive survey of u-automata appears iu [’Tho90).

The following definitions, agaiu taken from [CBK90], arc necessary for defining particular instances of %. A path in au w-automaton, M, is all infinite sequence of states so s] S 2 . . . E S that begins ill so and has the following property: Vi ~ I,Sai ● X: J(si, ai) ~ Si+l. A path so SI S2. . . E sd in M is a run of au infinite word a1a2. . . E V“ ifVi z l:d(sz, az) 3 Sz+.l. The i~~finitury set of a sequence SO S] S2 . . . 6 SJ, written 2n~(sosI . . .), is the set of all states that appear infinitely many times in the sequence. 4X A Buchi automaton flf is au u-automaton where the acceptance condition, >, is defined as follows. F C S is a set of states (as in the case of a *-automaton) and a path p is accepted by M if i?tf(p) n F # O. T’he acceptance condition of a Mul]er automaton is a set F Q P(S) of sets of states. A path is accepted by a Muller automaton if i?~j(p) E 1’. other w-automata that, appear in tllc literature are Rabin, Strectt, I,, and V– automaton. Although acceptance conditions for these automata are not defined here, it is worth noting that “an infinite word is accepted by a Buchi, Muller, Rabin, Streett, or I, automatol] if it has an acceptiug run in the automaton. AI] infinite word is accepted by a V-automaton if all its possible runs in the automaton are accepted.” [CBK90, p. 106]

4.3.3.3 Timed Automata

Timed automata arc a generalization of w-automata and are used to model real-time systems over time. Like w-automata, timed automata generate (accept) infinite sequences of states. However, timed automata must, also satisfy timing requirements and NAsA.G~@)l-97 39

~)roduce (accept) timed state sequences. ‘1’imecl automata nlay be given various senlantic inter~)retations, illcllldillg~~oil~t-based strictly -nlonotonic real-tinw (the original interpretation), ilkcrval-based variants, interleaving fictitious clock, alldfor sylichronic- ity [AH91]. An excellent discussionof thcthcor.y of timed automata and its application to automatic verificatioll ofrcal-til[~er eq~lirclllclltso ffi~~ite-state systen~s nlay be found ill [AL)91].

4.3.3.4 Hybrid Automata

Hybrid automata extelld finite autonlata with continuous activities and are used to n~odel systen~s that incorporate both continuous and digital conlponents. Hybrid automata may be viewed as “a generalization of tinmd automata in which the behavior of variables is governed in each state by a set of differential equations.’; [A~HH93] There are various classes of hybrid autonlata, i[lcludin,g linear hybrid autonlata and hybrid in~)utjoutput auton~ata. l,inear hybrid automata require the rate of change with time to be constant for all variables (although the constant nlay vary from location to location) and the ternls used in invariants, guards, and assignments to bc linear. 11 Alur et al. [A~HH93] provides a good introduction to hybr-id autonlata and [AH95] describes a synlbolic n~odel checker for linear IIybrid systm~ls. Hybrid input/output autolnata (HIOA) focus on the exterllal interface of a nmdeled hybrid syste~rl through distinctions in the state variables - which are partitioned into input, output, slid internal variables and the transitiol[ labels - which are similarly ~)art it ioned into input. output,. and internal actions. Lynch [LS\~W96] gives a useful introduction to H1OAS and [AHS96] contains several papers, jncludillg [l,y~lg~], describing tllc usc of H1OAS to l~lodel and analyze automated transit systen~s.

4.3.4 Object-Oriented Models

Object-oriented models represent systems as structured collections of classes and objects with explicit notions of encapsulation, inherit ante, and relations bet wee]) objects. Several informal object-oriented analysis and design methodologies are currently popular, including Booth [Bo09 1], Coad and Yourdon [CY91 a, CY91 b], Rum- baugh [RBP+ 91, RB91], Shlaer and Mellor [SM91], Goldberg [Sys92, RG92] and most recently, Unified Modeling Language (UML) [Rat97]. These methodologies offer a useful and easily assimilated approach for structuring an application based Oli multiple diagrammatic vie~w of the underlying system. UML, which represents a unification of the 1300ch, R.umbaugh, and Jacobson methods, employs static structure, use case, sequence,

1‘ A tin~ed autoxnaton is a special case of linear hybrid autonlaton iu which each continuously chang- ing variable is all accurate clock Ivhose rate of change with tinle is 1. In a timed automaton, all terlfLs involved in assignnwnts arc constants and all invariant and guards compare clock values ~vith constants [.ACHI193]. 40 Chapter 4 collaboration, state, activity, and implementation diagrams. Rumbaugh’s Object h!lod- c]ing Technique (OM’T) [RBI)7 91] nlethod, which is used ill the following exatnple, employs three separate modeling techniques: clltity-relationship)-type diagrams, state machines or Statecharts [Har87, HiY96], and data flo~v diagranls, yielding a colnposite model whose conl~)onents are typically linked rat,her than itltegrated or unified. The following fragment of a design-level OMT representation of a generic fault protection monitor based on a study of the Cassini spacecraft [LA94, AL95] illustrates the use of object-oriented teclmiques for modeling spacecraft systems. The OMT represem tation is generic ill that it attempts to explicitly document the functionality and attributes shared by all the Cassini fault protection monitors. In the context of spacecraft systems, the term “monitor” refers to software that periodically checks for system-level malfunctions and invokes recovery software as appropriate. There are eighteml moni- . tors in the system-level fault protection onboard the Cassini spacecraft, includitlg eight “over tmnl)erature” monitors. ‘Me other ten monitors detect loss of commendability (uplink), loss of telenletry (downlink), heartbeat loss (that is, loss of ccunmunicat ion between computers), overpressure, undervoltagc, and other selected failures. The OMT approach provides three view~)oints: the object model, the functional model, and the dynamic model. Figures 4.5, 4.6, and 4.7 illustrate these three models for the Cassini fault monitor at the desig[~ level. Figure 4.5 reproduces the object model, a static representation of the system that reflects four attributes and three operations that defillc the monitor class (activate, enable output, and disable output). The class is further decomposed into three object classes: sensor data, valid data, and fault indicators. The attributes and operations for these three classes define the interfaces between the monitor class and the rest of the systenl. Figure 4.6 reproduces the functional nlodcl, which represents the computation that occurs within a system and is presented as a series of data flow diagran~s. The top- level diagran~ documents the interfaces between the fault protection nlanagcr and the monitor. The mallager activates the nlonitor and processes the monitor’s request for a fault response. Tile n~onitor receives data from the hardware sensors ( “measured state” ), from the “comnanded state” that is stored in nlemory, and from the u~)dates to the state made by previous executions of the monitor itself, and uses the infornlation to determine an appropriate fault response. Figure 4.7 reproduces the dynamic model that specifies the flow of cent rol, int erac- tions, and sequencing of o~)erations. These dynanlic aspects are modeled in tern~s of events and states using standard state diagralns (that is, graphical representations of finite state nlachines). The behavior of the Cassini fault protection nlonitors is highly sequential. The state tralLsition model provides a clear and intuitively straightforward representation of the typical six-state sequence followed by an active monitor in the presence of a fault that requires a recovery response. While tile ty~)es of informal object-oriented models illustrated here have considerable utility, their usefulness in the context of fornlal methods is limited because they do not 41

Monitor

Enabled Flag Active Flag Response-kkquestccl Priority . . Activate Einablc output Iwdkoll@t

~—————. t ‘—‘1 __A -—-.—.. -l–----–_—

Sensor Data Input Valid Data Fault Indications —------

Fault status Persistence counter Measured values Prior status Persistence limit Fault threshold Valid-range filters Commanded state Detect fault persistence Test output enabled Request response 1 est data validity Detect fault Vote on fault Update flags, counters

Figure 4.5: Object h40clel of Cassini Gemric Fault, Protection N4cmitor.

have all underlying nlathematical basis and therefore lack a precise sen~antics and the ability to support fornial reasoning. More .gj.meral caveats expressed in regard to sonic or all of these informal object-oriented methods include the following [Jac95, p. 137]: (1) objects belong to fixed classes- -the rigidity of these class structures precludes transition or metamorphosis of objects: (2) objects typically inherit properties and behavior from a single class at tile next hierarchical level; this notion of single inheritance precludes many naturally occurring inheritance patterns involving shared and multiple ild~eritance; (3) objects are inherently reactive and typically cannot initiate activity of any kincl. Al- t bough these three caveats are now addressed in many object-oriented programming languages, for example, through multiple inheritance, dynamic object classification, and concurrency, the popular methodologies that support the earlier stages of development do not, typically address these issues. A fourth caveat is that the lack of integration in conllJosite models often makes it difhcult to reason effectively about system behavior. 42 Chapter 4

Thresholds/ Filters commanded State flags po;itions

1 I I __ Fault Sensor 1 indica Persistence counter input Test for Valid —~ data Test for tion valid —-* \rot~ on fault data I presence — ! Request of fault ‘atrlt Test response -~ —+ for fault Sensor n \lalid Fault indica input Test for tion [...... —––- data - - _ + Test for —* valid 1 ‘“ ” 1 data I 1.-.::-.1 1-----—

Figure 4.6: Functional Model of Cassini Generic Fault Protection Monitor.

Historically, object-oriented ideas evolved from the notions of classes and objects in Simula 67. In the following quote, Ole-Johall DaIll discusses this evolution in tile context of formal techniques.

‘(object orientation, as it appears in Simula 67, was motivated by twro mai~l concerns: To achieve good structural correspondence between discrete event simulation progratns and the systems being modelled. And to provide language mechanisms for the comtruction of reusable program components wrhile maintaining good computer efficiency.. . . Object orientation has proved to be a successful structuring strategy also outside the area of simulation. This is due to the fact that objects are useful general purpose tc)ols for concept modellirtg, and can lead to better program decomposition in ~;cneral, as well as new kinds of reusable program components. It is worth Iloticing that the class concept of Sinmla 67 is used to represent “modules” atld “packages” as well as object classes.” [I)al190]

Object-oriented ideas share this ancestry with algebraic spccificatioll; tile classes of objects and “prefixing” central to Sitnula 67 ultimately led to object-oriented pro- graming languages and to t lle theory of algebraic specifications [Bre9 I ]. Algebraic specifications treat data structures and program development concepts, suclL as refinement, in an axiomatic logical style and use high-level descriptions of data types known ATA SA. G~_OOl .97 43 -k9---_ +----+

,,,,..*@$?,@z,ePasses “---9

Figure 4.7: Dynamic Model of Cassini Generic Fault Protection h40nitor. as abstmct data types. Abstract data types am manipulated by similarly high-level operations that are specified in terms of properties, thereby avoiding i[~l~~lell~elltatioll- dependent data rcpresentatiorls. As Abadi and Cardelli note in their book on the (formal) foundations of object-oriented programming languages [AC96, I). 8], “. . . data abstraction alone is sometimes taken as the essence of object orientation. ” This historical connection is of interest because the frameworks of algebraic specification and of object-oriented programming languages nave each contributed to ongoing attempts to providea mathematical basis for the concepts underlying object-oriented models.1~ This research has taken many dircxticms, iucludillg those summarized below. In keeping with tllc focus of this guidebook, tile examIJcs iucludcd itl this discussioll suggest tile ~,ariety of t~le ~~ork in t~~is area, but arc @ I1O means exhaustive. One approach is to take a mc)del generated by one of the informal object-orimlted methodologies and formalize it using a novel or existing formal description technique. For example, Moreira and Clark [MC94] describe a technique for producing a formal object-oriented analysis model that integrates the static, dynamic, and functional properties of an ot)ject-oriented model created using one of the informal object-oriented methodologies. 13 The formal model uses LOTOS (Language of Temporal Ordering Specification) [1 S088], which has a precise mathematical semantics and represents the system as a set of coxnrnunicating COIICUtTC!Ilt objects. 14 An object is represented as the instantiation of a LOTOS process, and communication among objects takes the ——— . 12 SW) for example, recent proceedings fron) conferences such as ECOOP (Eurc~pean Conference on Object-Oriented Programming [TP94, 01t95] ) and 00PSLA (Object-Oriented Programming Systems, Languages, and Applications) [ACM94]. ‘3 [hlC94] actually describe a Rigorous Object-Oriented Analysis (ROO.A) method that combines object-oriented analysis and formal description techniques. This discussion focuses only on their mod- eli ng approach. 14That is a set of a~proach is based on I)rocess algebra, dra~~ing on >. colll~)U1liCatjng processes. T}IC elements from CXS [Mi189] and from (HSP [Hoa85]. 44 Cha~>ter 4 forln of message passin~, which is modeled by ot)jccts syllc}lronizing 011 an event during which information may be exchanged. In this a~)proach, the dynamic aspects of a class temlJlate ate modeled as a 1,()’1’0S I)rocess am] tl~c static I)roperties as abstract data types Another approach is to take nc)tatioll fronl one of the informal methodologies and formalize it, thereby lmovidillg a formal semaut ics for tllc informal notation. For example, I{ayes and Coleman [HC91] use 0bjcxtcharts15 [CHB92] and a derivative of ~~Dhfl [Jou90] to provide a coherent set of formal models corres~)onditlg to the models generated by a subset of Oh!IT. Briefly, Hayes aud Coleman introduce an object stmctum model, linking the formal representations of the informal OMT models (ot)- ject, dynamic and functional) to provide traceability and consistency checking. llle infornial OM’T functional model is replaced by VDM-styIc pre-post condition specifications over the object structure model, the informal dynamic model is formalized using Objcctcharts, and the object model uses the formalized entity-relationship notat ion described ill [FNT86]. q’here has also ken work integrating formal and object-orientccl methods using VDh4-t + and OMT [I, G96]. VDM+ + is an obj[!ct-oriented extension of VDM designed to support parallel aud real-tinlc specification. O~lgoing work at the hlichigau State Ullivcrsity Software 13ngiueeriug Research Group [BC94, Cl WBf14] is yet another variant on this a~)proach. Their prototype system uses algebraic specifications to fornlalizc a subset of the OMT object-nlodeling notation ap~mo~)riate for nlodeling requirements. Again, tllc fornlalization is based 011 tllc straightforward mapping between object-oriented software concepts and abstract data types.1~ The COIW n~ethod [FFIWK92] for spccifyilLg real-time rcquirenlents provides a further example of the coherent integration of object-orieuted and fornlal rnodcls. CORE is au an~alganl of the CAS12 Real-Tiuw hlcthc)ci (which is itself an an~algam of Rcal- Tin~e Structured Analysis [WM85] and object-oriented concepts) and the four-variat)lc xuodel [vS90, vSPM 93] developed by F’arnas and his colleagues. CORE interprets the three basic structural elel~lents of the CASII Real-Tinle method: infornlation, process, and l)chavior pattern, in terlns of object-oriented concepts. Processes correspond to object classes aud interprocess connections to interactions between objects. The state machines used to encode the behavior-patterll view are partitioned to correspond to the states of all object class. ‘The fornlal model underlying object definition and deconlpo- sitiou is based on the standard nlathcnnatical mode] of embedded-systen~ behavior used by the four-variable nlcthod. 1’lIc resulting anlalgaul retains the graphical notation and not ions of abstraction, encapsulation, separat ion of col]cerns, and nonalgorithulic

15 AU Objectchart is an extended forn~ of Statechart [Har87, HN9G] used to specify object classes. 16 The graphical environment prototype generates Larch specifications [CW’B94]. .41though current vcrsiol,s of Larch are not inherently algebraic, the illl~)leItlclltatioll cited supports only algebraic languages although it is general euough to accon~nlodate most algebraic languages that have a well-defined gramtnar. It appears that ‘object model” has replaced the previously used phrase uf,rdysis ob~ect sche71uhr (a-sche7nata) in receILt publications [BC95b]. s~)ccification associated with object-oricrltcxl a~)proaches, within a nlatl)enlatical]y well- defincd model contributed by the four-variable nlctllod. There have also bcc]l formalization in Z c)f the three OhlT notations [Spi88, Wor92], as well as object-oriented extensions to Z. The collection of papers in [S13C92] contains accounts of both approaches, including a summary of Hall’s object-oriented Z specification style, whic]l is also ctescribcd in Hall [11a190].

4.4 A Model for the SAFER. Avionics Controller

The SAFER avionics cent roller described in Section 2.6 exhibits several characteristics that, strol@y influence the choice of a model for its formalization. The basic functionality of the cent rollm requires a represent at ion that captures the mapping from input and scwsor values to outputs. The model must, also be able to capture the dependency of current everks on prior events, necessitating the use of a state- or trace-based model, or other re~mesentatioll lvith similar facility for preserving values from one “cycle” to another. The fact that tllc coutrollcr maintaitls and updates its own interns] status, including Hand Colltrollcr h40dule (IICM) display and Automatic Attitude Hold (AAH) status, provides additional nlotivatioll for an explicit representation of state. In fact, tllc SAFER avionics controller provides a nice illustration of a system that can be quite naturally modeled as a state machine (see Section 4.3.2), that is, as a model consisting of a system state and a transition function that maps inputs and current-state values into out~)uts a~~d next-state values. Arguably, a variant of the basic state machine Inodcl, suc}l as t lw A-7 [11+ 78,11 e~180, vS90, Par91 ,PM91]. which is specialized for control systems, would provide a representation that differentiates inputs, outputs, and state values by cx~)licitly idcntif.ying monitored, control, and state variables (see Figure 4.3). Although t llc diflcrellces between these two models are small, the choice bctweell a basic state machine model and a s~)ecialized state machine mode] illustrates the ty~w of trade-off that typically enters into modeling decisions. In this cas[!, the trade-off is tile relative sin]l)licity of tile basic state machine model versus the additional expressiveness of the s[)ecializcd A-7 model, where finer-grained distinctions alnong variables potent ially ~)rc)vide a clearer mapping between informal description, requirements, and the formal sl)ecificat ion. on the other hand, the level of description and the (primarily) pedagogical role oft he SAFER example motivate the use of the si@er model presented here. Nevertheless. tllc rc!ader is encouraged to consider the similarities between the basic stat[! n~acllillc model developed here and A-7-type models, in particular the notion of tile state trazlsit ion fu]lct ion defined as a control function with monitored (that, is, sensor) and stat e variat )lCS as input and cent rol and state variables as output. A final consideration concerns the representation of time. Since the basic fu~lction- ality of the ccmtrollm can be captured within a single frame or cycle, there is no need to reason about the bcllavior or evolution of the system over time or to introduce the additional com~)lexity required for an explicit representation of time. The trade-off here 46 Chapter 4 is the simplicity of the model versus a loss of analytical I)ower. Without an cxlJlicit representation of time, there is no way to explore certain types of propmties, including safety and liveness properties that establish (roughly) that nothing bad ever ha~)~)ens and something good eventually happens, respectively. For example, without an exl)licit representation of time; it would be in~l)ossiblc to denlonstrate that an HChf translatic)ll (rotation) comnland eventually results in thruster selection. ‘7 Although the nlodels presented in this chapter do not incor~)orate a notion of time, a tinw 01 trace-based model could be added, as needed, on top of the state-based n~odel presented hem. Having identified the underlying mode] as a basic state machine, the next step is to define the control (transition) function. The transition function for the top-level controller model is comprised of functions re~mesenting its constituent nlodulcs and assenlblies. Of interest here are the AAH and thruster selection functions. Thruster selection maps HCM and AAI1 commands iljto a~] integrated six degrcw-of-freedoni command that, determines the corresponding (thruster) actuator Conmands. T1lis tWTo. phase functionality can be modeled simjlly as the colnI)ositioll of the two flmctiolls, rougl]ly sclec:tcd..ac:t tluiors o i?~tc:g?atcd-c:oT?t?rluTld

The AAH model cannot be so simply discharged, because the automatic attitude lloldcal)abilit~' l[~ail~taitls il~terl~als tateil~forll~ati ol~toit~~l~lcltlcrltt lleA All control law and tc~ track whether the AAII is engaged or disengaged and which, if any, of the three rotational axes arc under AAH control. AAH control law is implemented in terms of a complex feedback loop that monitors inertial reference unit (IRU) angular rate sensors and temperature sensors (one for each of the three rate sensors), and generates rotation comn~ands. Although this account is necessarily simplified, it suggests a fairly complex control system with clearly differentiated variable types and a well-defined internal state. The rationale for considering an A-7-type interpretation of a basic state machine model for the top-level avionics controller applies equally to the A AH. The A AH state machine model is slIown in Figure 4.8. A closer look at the AAH button transition function further illustrates the type c)f issues that invariably arise in developing models for formal specification. The state transition diagranl for this function show’n in Figure 4.9 represents the single-click, double-click engagement protocol described in Section 2.6, where nodes represent AA1l states and arcs represent the two button positions (up or down) and the twc) operative constraints (timeout or all three rotational axes removed from A AH control). 18 For example, if the AAH is engaged and the AAH pushbutton switch is depressed, the A AH enters a state (“pressed once’]) that is exited only u’hell the ~)ushbut toll is ——. — —— 17\Vhether the thruster selection is correct ~rith res~wct to the thruster select logic is an important property, but not a liveness issue. ‘S1’he diagram actually represents a con~bination of pushbutton and implied events. For example, although the 3-axes-off transition reflects one or more previous HChI comnlands, it does not represent an explicit pushbutton event, such as AAH enatk/disable. 48 Chapter 4 (9 up down

down down

up up

down

— Figure 4.9: Labeled AAH Pushbutton State Transition Diagram. explicitly inactivate the AAH. The AAH model presented here reflects the second option, which is more straightforward and avoids the possibility of misleading a crewmember into thinking that the AAH is engaged when in fact all three axes have been disabled. There are also modeling issues, including those surrounding the representation of the 3- axes-off transitions. In the model diagrarnmed above, the 3-axes-off transition emanates only from the “AAII on” and “A AH closing” states, although logically, it can be argued that 3-axes-off transitions should also emanate from the “pressed-once” and “pressed- twice” states. In other words, the model should explicitly reflect that fact that if AAH is engaged and all three axes have besn disabled, AAH is terminated. ‘rhe rationale for the given model is that the behavior of the resulting system is cleaner if the “AAH off” state is entered only after the pushbutton switch is released (“up”). Otherwise the button would be depressed and cause an immediate transition to “AAH started” on the next pass. Similarly, although it is arguably preferable to omit the 3-axes-off transition from ‘LAAH closing” and allow the double click to complete, if the crewmember forgets the second click, another ill-defined situation results.

So far, the discussion l“laS focused on modeling SAFER’s functionality rather than its physical components. Although many of SAFER’s physical features fall below the NAsA_G~_()()].97 47

IRU Sensors Propulsion Sensors AAH Lng :C Button T“ “-T-r [_---~~j~al---l

‘ushbutton A _..._.._-.-~-.--;j~L~.-.---->~--;j~L--”- ‘--” m Funclion r–A “-_——.J 11 I 1 [

s t a - t e c— ---4 ‘ t AAII*–--+ L—. Transition Funclion I —- ——=..—–—— –—.–~ I i

(“onlrol F unction — — - ‘--- - -t-” -- ‘“ I

Rotation Command

Figure 4.8: AAII Ckmtml System State-update aud Actuator l?uuctioIls. released, at which poiut the A AH transitions to a state that, may be exited in onc of two ways: either the 3-axes-off constraitlt becomes satisfied and the AAH is disengaged or the pushbutton is depressed for a second tiule aud the AAH enters a twilight state ( “~)ressed twice” ) prior to button release aud disengagement. Several interesting ques- tiorls arise with respect to this model, largel.v because of uudocuuwnted behaviors. For examplej the Oymations Manual [SAF13R94a] cloesn’t mention the case represented hy the t~vo 3-axes-off arcs, where the axis-by-axis disabling (resulting from explicit rotation commauds issued while A AH ~vas engaged) effectively disengages the A AH. The two op- t ions are either to leave A AH nomiually active with all three rotational axes off or to 49

level of abstraction chosen for tile fcJrmalizatioll, certain features such as the thrusters 8 lnust be modeled. SAFER has 24 thrusters arranged ill four groups (quadrants) of six thrusters each. Consistent with the intermediate level of detail chosen to make the guidebook example easier to understand, the thrusters are modeled hy wlulneratiug each I of the 24 thrusters by name at~d providing a function that maps a thruster name to a full thruster designator. The thruster designator is a triple consisting of elements that, represent, the direction of acceleration yielded by firing the thruster, its quadrant. and 1 its physical location as sho~vn in Figure C.3. For example, thruster F1 would be mapped to the designator (FD, 1, RR) and thruster L3R would be mapped to the designator B (LT, 3, RR). Possible values for the three designator components are as follows: ● I)irection: UIJ, down, back, forward, left, right

● Quadrant: 1, 2, 3, 4 t ● IJocation: forward. rear

It is instructive to consider a more abstract model of the SAFER thrusters. For example, a considmably higher-level model might simply provide primitive (uninterpreted) elements called thrusters, some of which accelerate up, others do~vll, back, forward. right, or left. These distinctions are disjoint, that is, a thruster accelerates in exactly one direction and there are 110 otllcr kinds of accelerations. The exact number of thrusters and their physical posit ions wit h respect to quadrant and location are irrelevant at this level of abstraction, although it would certainly be possible to s~wcify atl u~)per boutld on the number of thrusters. The advantage of this highly abstract model is that it is not obscured by (arguably irrelevailt) detail a~ld it is ge]lcral enough to be applicaljle to new designs or future modifications. Chapter 5

Formal Specification

A for~nal specification is a characterization of a planned or existing systeni expressed in a formal language. The characterization typically consists of a collection of axioms and definitions whose meaning and conseclueuces are determined by the precise ~nathematical basis of the formal language and its rules of inference. In this context, ‘(consequences” denotes all the formulas that can be derived fronl the axioms and definitions using formal deduction (as prescribed by the inference rules). These derivations are also referred to as proofs, and the set of formulas constitutes the theory defined by the specification. The act of formalizing a specification does not necessarily make it relevant, coherent, or true. There are several ways to increase the certainty that a specification expresses the intentions of its author and that what it says is true, including--in ascending order of rigor- parsing, typechcckiug, animating, or exccutiug all or part of the specification, well-f ornledness checking for definitions 1, demonstrating consistency for axiomatic specificat ions2, and developing and proving theorems entailed by the specification. Of course, there is no way to completely guarantee that a formal specification is correct or accurately represents reality; the various checks and tools cited here can reduce, but never totally eliminate, the possibility of human error. Nevertheless, there are very real benefits to be gained from formal specification, benefits that are not ditninished by the inl~)ossibility of defluitive correctness. This chapter focuses exclusively on formal specification, leaving issues of formal analysis and proof to Clla~)tcr 6. The discussion covers specification languages and styles, as well as the checks and tools meutioued above with the exception of theorenl proving, whicl), as already noted, is deferred until Chapter 6. The discussion also touches on the utility of forn~al specification in the absence of forn~al proof and continues the ongoing exan~ple with a partial specification of SAF13R, using the n~odel developed at the end of Chapter 4. _—— 1 ‘1’hat is, assuring conscrvat ive extension; see Section 5.1.2.9 for a discussion of this and related topics. 2For exanlple, exhibiting a model; see Section 6.1.1.

50 hTASA -GB-001 -97 51

5.1 Formal Specification Languages

A formal language consists of a collection of symt)ols drawn from an alphabet and a set of syntactic rules that govern which combinations of symt )ols constitute valid expressions in the language. In purest form, a formal language and the rules for manipulating it are referred to as a (luathcmatical) logic. The propositional and predicate calculi are examples of this type of formal system. Although some formal specification languages use pure logics, many enrich the underlying logic with modern programming language concepts and constructs such as type systems, encapsulation, and ~Jara~~~eterizatiox~, thereby increasing thecxprcssiveness of the formal language while retaining theprccise semantics of the under].ying logic. As these remarks suggest, the distinction between a specification language and a programming language is somewhat blurred. ‘1’he same can bc said for their respective artifacts. Although a program call be viewed as a specification, a slmcification is typically not a program and often contains such nonconl- putational constituents as high-level constructs and logical elements (e.g., quantifiers). The basic difference is one of focus: a program specifies completely how something is to be computed, whereas a specification expresses constraints on what is to be computed. As a result, a specification may be partial or “incomplete” and still be meaningful, but an incomplete program is generally not executable [Win90, p. 8] [0 SR93a, p. 2]. There is a wide variety of formal specification languages, far too ma])y to be considered here. Rather than focus 011 a reprcscmtativc sample of these languages, the discussion concentrates instead on general characteristics and features of specification languages, the rationale being that discussio~l of foundational issues. general features of. and desiderata for formal s~jccificatioxl languages will provide the reader with background and access to a wide range of formal specification languages. Although nlechanized support for forma 1 systems is not discussecl, one of the additional benefits of a high degree of formalization is that specifications written in a formal language are amenable tc) mechanical analysis aud manipulation. Most formal specification languages arc supported by mechanized syntax analysis tools, and many also enjoy some level of nlechanized semantic analysis, as well as deductive apparatus in the form of theorem provers and proof checkers. A It bough most systems arc designed around a particular s~)ccification language and its proof rules, there are also generic systems such as Isabelle [Pau88] that support a variety of logics and notations. Volume I of this guidebook [NASA-95a] includes an extensive list of formal methods tools, as well as a description of approximately 15 of the most widely usmi of these systems.

5.1.1 Founclations3

As noted earlier, a formal specification language is grouuded in a mathematical logic. ‘There are, of course, a wide variety of logics: simple propositional logics (either classical

3Thc ruaterial in this section is based largely OX, a discussion in [Rus93b]. 52 CilaJjter 5 or intuitionistic), equatiol Ial logics, quantificatiollal logics, model and temporal logics, set theory, and higher-order logic, althoug}i this by no means exhausts the possibilities. ‘TIWSC and other logics were developed by lllatlielllaticial~s to ex~)lorc issues of ccnlcerll to them. As Rushby [F{us93b, p.214] notes:

“Initially, those concerns were to provide a minimal and self-evident foundation for mathematics; later, technical cluestions about logic itself became important. For these reasons, nlLIch of mathematical logic is set up for metamat hemat ical Imrposes: to show t hat cert ain elementary concepts allow SOIUC parts of mathematics to be formalized in principle, atld to support (relatively) simple proofs of prol)erties such as soundness and completeness.”

On the other hand, formal specification languages are developed primarily to be used, that is, to formalize requir emcnts, designs, algorithms, and programs and to pro~’ide an efficimlt and effective basis for reasolli~lg about ttlesc artifacts and their ~)roperties. Predictably, the languages developed by mathematicians are not necessarily well-suited to the needs of those engaged in formal specification and aualysis. This is ~)articularly true when mechanization of specification and analysis is considered. Although there are specialized uses for some of the logics mentioned above - for example, a propositional or modal logic can provide a basis for efficient deternlillatio~l of certain properties of finite state machines- the logical foundation for an expressive, general-purpose specification language is generally either axiomatic set theory or higher- order logic. Historically, these approaches were developed in response to Russell’s Para- der, which exposed a fundamental inconsistency in Frege’s logical system OIL the eve of its publication and frustrated Frege’s attenll)ts to provide a consistent foundation for the whole of mathematics. 4 Axiomatic set theory avoids contradictions by resh-icting the rules for forming sets- --basically, new sets may be constructed only from existing sets. There are different axiomatizations, characterizing distinct set-theories; the best known of these is called Zermelo-l+aenkel or simply ZF, after its founders [FEIHL84, Ha184]. ZF contains eight axioms, all of which express simple, intuitive truths about sets. ZF set theory provides the logical framework for several well-known specification languages, including Z [Spi88] and Verdi, the language of the Eves system [CKM+91]. The main issues surrounding the use of axiomatic set theory as the basis for a specification language are unconstrained expressiveness, the difficulty of providing semantic checking for an inherently untyped system, and the challcugc of providing efficient theorem proving for a system in which functions are inherently partial.

o .Actually, F’rege, Cantor, and Dedeliind were greatly disillusioned by the contradictions that plagued their set theoretical foundation for the real nunlbers, continuity, and the infinite and quit the field, leaving, the developnlent of a consistent set theory to others. The intellectual history of this period, as well as the n]athernatics, is fascinating, but ~vell beyond the scope of the guidebook. Rushby [Rus93b, pp. 254- 5] offers a brief sketch of the issues based cm material iu [Hat82, Lev79, FBHL84, Sho78a, Atld86, BP83, vB1M3, Haz83]. The last chapter of Hell [13e186] provides au equally brief history of the personalities as well as the n~athernatics. fiTASA_{;B-0ol_97 53

In the context of logics, the suffix “-order” Iefcrs to the elements over which tile logic permits quantification. Tl~e standard ~)rogressioll is as follows. The l)ropositio~lal calculus does not allow quantification and is cflcctively “zero-order.” The predicate calculus, which allows quantification over individuals, is referred to as “first-order” logic. Similarly, %colld-order” logic provides quantification over functions and predicates on individuals, and ‘{t bird-order” provides quaut ificat ion over functions and predicates on functions. The enumeration contiuues UI) to ~-order, which allows quantification over arbitrary types aucl is therefore generally equated with type theory or higher-order logic. Axiomatic set theory assumes a flat universe; individuals, sets, sets of sets, . . . . are undif[crent iated with respect to quant ificat ion. which is inherently first-order. Further- more, axiomatic set theory admits only two predicates: (E and =).5 In type theory, the universe is ordered with respect to a type hierarchy and quantification must respect the type distinctions. in other words, quantifiers apply to typed elements and the type distinctions lnust be ccmsistent]y maintained throughout the scope of the quantifier. In highly simplified terms, simple ty~w theory avoids the logical paradoxes by ob- serving a strict type disci~)line that prevents paradoxical circular constructions (also called impwdicative definitions) .6 The simple theory of types has been used as the basis for several formal methods and theorem proving systems, including IIOL [G M93], PVS [ORSVH95], and TPS [AINP88]. As a foundation for formal specification languages, type! theory offers several advantages, SUCh as strong, lllecha~~i~ed typec}lec~i?~g t bat confers early and effect ivc error detection; expressive power of quant ificat ion and higher-order constructions; and the potential for mechanized theorem proving facilitated by the total functions that, typically underlie simple type theory.

5.1.2 Features

The previous discussicm of mathematical foundations suggests that the mathematical basis of a specification language figures importantly in determining such features as expressiveness and mechanizability. This section briefly considers expressiveness and other basic features of s~wcification lauguages. .4s noted previously, mechanization issues generally lie outside the scope of this guidebook, which is aimed at the practitioner rather than the provider of fornlal nlethods tools or systenls.7 —- .—— ———. ‘Although ZF reconstructs functions and predicates within set theory as sets of pairs, this set theoretic approach is arguably less suitable for fornlal nlethods because it tends to be less expressive and less easily nlecbanized. ‘The account presented here is very sketchy. Rushby [Rus93b, pp. 270-278] presents a somic~vhat more thorough discussion, based on material in .Andrcws [And86], Hatcher [Hat82], Benacerraf and F’utnarn [BP83], van Bentharn and Doets [vB1X33], and Hazen [Haz83]. Bar}rise and ~tchenlendy [J3E87] have published a very readable analysis of the semantic paradox knoum a< “The Liar,” using an extension of ZF set theory. 7See, for example, Rushby [Rus96], which touches on the inlplications of specification language design for autonlated deduction while advocating an integrated approach to automated deduction and formal methods. 54 Chapter 5

5.1.2.1 Explicit Semantics

10 provide a basis for mathenlatically well-defined, credible specifications, as well as a standard framework for undcrstaudiug the s})c!cificationsl a specification language must itself have a mathematically secure basis. lcleally, the language should have a complete formal semantics, although languages built on staudard logics without sigllificaut extensions typically don’t have or need a completely formal semantics. on the other baud, specification languages that are Ilot based on standard logics or that employ novel or nonstandard constructions should provide a formal semantics that has undergone some form of lJeer review or collegial scrutiny. Spivey’s formal semantics for Z [Spi88] is au example of this kind of formal semantic account.

5.1.2.2 Expressiveness

As noted earlier, first-order predicate calculus with equality is generally considered the minimum foundation for a reasoi’ably ex~)ressive specification lauguage. On the other hand, more rest ricted bases may be appropriate for particular applications and more powerful bases (such as set theory and higher-order logic) are desirable for most applications. Of course, there are several dimensions to the notion of expressiveness, including flexibility, versatility, and convenience and econonly of expression. Some of these derive from other features; for example, a rich type system facilitates more succinct specification since much of the specification can be embedded in the types, as illustrated ill tile two versiol Ls of the claiul, c1 (below), that the sum of two even itltegers is even. The property of being all even integer is characterized by the predicate even?.

x, y: VAR int rcl : CLAIM even?(x) AND even?(y) IMPLIES even?(x + y) —- ——— —..J

Alternatively, the constraint nlay bc enlbeddecl in the type, so that variables x and y are declared to be elements of the type consisting (only) of even integers.

— x, y: VAR {z: int I even?(z)} rc1 : CLAIM even?(x + y)

Similarly, the availability of familiar pro.grammiug language datatypes aud constructions confers considerable convcmieuce and clarity whel~ dealing with such structures as arrays, records> lists, and sequences. There are also trade-offs; for example, in the case of executable spccificat ion languages, finit ellcss collst raiuts imposed by executability can compromise expressiveness. NA SA-GB-001 -97 55

5.1.2.3 Programming Language Datatypes and Constructions

L40st specification languages sup~)ort at least some of the familiar programming language dat,aty~)cs, such as records, tu~)les, and enunlmatious~ as wwll as constructions that uldate these structured tyqws. s SOme also support abstract data types, ilducli~lg ‘shell” mechanisms for introducing recursively defined abstract data ty~ws, such as lists and trees, and similar mechanisms for inductively defined types and functions.

5.1.2.4 Convenient Syntax

‘There are basically two aslmcts to the question of syntact ic convenience: familiarity and ease of expression, and utility for documelkation and review. The latter is someirhat 1.sss important if the language is used in an environment that includes typesetting for documentation. The former hinges on whether the language accommodates the user for example, providing infix operators for standard arithmetic operations and fan~il- iar forms of fullction application including the use of delimiters and punctuation or w’hether the user must accommodate the language, adjusting, for example, to Lisp-style prefix notation.

5.1.2.5 Diagrammatic Notation

Diagrammatic notation, including gralJllic notations as fouud, for example, in Statematc [11+ 90], and tabular notations, as found in Parnas’s “four variable method” [vSI’M93], SCR [IIJL95], and RSML [LHHI194], provide a s~)ecification format that can be readily understood and easily comlnunicatcd. These notations typically support an underlying methodology for specification and refinement. The challenge is to provide the benefits of a diagrammatic style witli suflcient utlder]yillg formality to support a range of formal analysis techniques.

5.1.2.6 Strong Typing

Strong typing is often considered a significant asset in specification languages as well as in programming languages. Tile difference is that specification languages can have much richer type systems than programming languages because the types do not have to be directly itnldenlentable.g The benefits of strting typing include economy and clarity of expression, a discipline that encourages precision, and an effective basis for nlechanized typechecking. A typechecker is a program that checks that the type discipline is

6Upriatirlg or constructing new values of structured types from existing values in a purely functional ,vay (aualogous to assiguulent to array elemeuts or record fields in imperative programn~ing languages) is also referred to as overriding. glhere are ex~eptio~ls, sur.., as the al>stract or ~irtlla] class cor~structs il~ C + +, ~)ut ‘lle gerLeraliZatiO~l is nevertheless a useful one. Chapter 5 maintained throughout the slmificatioll; entities must match their declarations and be combil~ed only with other eutities of the same (or a compatible) type. Predictably, the actual utility of the typechecker (for detectiug faults, inconsistencies, and omissions) depends both ON the logical foundation uuderlyillg the specification language and on the diligence and skill of its implementors. For example, it is difficult to provide strict typccheckin gforlanguagc sbasc don set theory without sacrificing some of the flexibility of these languages because set theory docsll’t l)rovide an intrinsic notion of ty~w. On the other hand, ty~)e theory (higher-order logic) is an inherently typed system, and languages based on higher-order logic readily su~)port strict typecheckillg. ~everthelcxs, there are certaiu caveats. 1,anlport has argued against the unques- t ioned usc of typed formalism, noting that types are not hatmless - they potentially conlpronlise the silu~)licity and elegance of mathenlatics and conlplicate forn~al systems for mathematical reasoning [IJan195]. Strongly typed languages that do not provide overloading and type infereuce call k rotationally complex and frustrating to use. For cxanlple, it 1 many specification languages, addition cm integers is often a different, function from addition on the reals, but by “ovcrloadiug” the synlttol -t and exploiting colltext to “infer’; tile correct addition fuuction, the burden of the conlplexity falls 011 the system rather than on the user. lhe sophistication of type inference nlechanislns varies; systems based on nigher-order logic that provide rich type and modularization facilities require particularly sophisticated type inference mechanisms for effective user sup~)ort. If a ricl] ty~w systenl is supported by mechanized typcchecking integrated wittl thc- oren~ proving so that typechecking has access to theorem proving, the expressiveness of tile language ca~k lx further c~lhaucecl. For example, much of the expressive power of the F’VS language is achieved through the use of predicate subtypes where a predicate is used to iuduce a sut~ty~w OX1 a parent, type. However, tile introduction of subtypes makes ty~)echecking undecidable, requiring the ty~)ecbecker to generate proof obligations (known as Type-Correctness Conditions (TINs)) that must be discharged before the s~)ccificatioll can l)e considered ty~)c correct .10

5.1.2.7 Total versus Partial Functions

A total fuuctioll ma~)s every element of its domain to some element in its range, whereas a ~)artial fullctio~! ulal)s ouly some clemeuts of its domain to elements of its range, leavi~lg others undefined. lf’llile most traditional logics incorporate the assumption ‘lO1’he standard PJ’S exalrlplc is that of the division operation (on the rational), which is specified by /: [rational, nonzero_ratlonal + rational] where nonzerozational :type = {x: rational I X # O} specifies the nonwro rational nunlbers. l’he definition of division constrains all uses of the operation to have nonzero cllvisor>. .Accordiugly, typechwking a forvnula such as x # y ~ (y-x)/(x-y) < 0 generates the ‘1’CC x # y > (x-y) # O to ensure that the occurrence of the divisiorl operatioIL is well-typed. !Notc the use of t}lc “context” (x # y) as an antecedent in the TCC. iVfost (true) TCXS generated in the PI’S system arc quickly and automatically discharged by the prover during typechccliing without user ix~terventioxl. that functions arc total, ~mtial functions occur naturally ill the kinds of applications undertaken with formal methods. Givcm that most logics assume that fuuct, ions are total, providiug a logical basis for a specification language that admits partial functions tcmds to be problematic. Although sonic recent lo.gics (including those of VDhl [Jon90]. 1{.AISI? [Gro92], three-valued lc)gics [Urq86, RT52, Res69, K’TB88], and Beeson’s logic of partiaI terms [Bec86]) allow l)artial fuuctiolls, they typically formalize partial functions at the expense of complicating theorem proviug for all specifications, even those that do not involve partiality. On the other baud, t rest illg all fuuct ions as total iu languages with only elementary type systems also has undesirable consequences, iu particular, the awkwardness of having to specify normally uudefined values (for example, havixig to specify division by zero). Total functions are less problematic in languages that support suhtyl)es and de~)cndcmt types, as illustrated previously by the P\TS specification of di~isiou on the rationals as a total operation on the domain consistillg of arbitrary numerators and nonzero denominators, where the latter was defined by the predicate Sul)typc, ?Lo7L2e7’0-rat2071 al.

5.1.2.8 Refinement

Specification languages that sul)port refinement provide an explicit formal basis for the hierarchical mappings used to verify successive steps in the development from abstract requirements and high-level specification to code. Although most specification languages allow refinement to be expressed, if somewhat paiufully, explicit support for refinement confers a distinct advat~tagc for describing the systelnatic and provably ~orre~t “iu~plc- mcn~tat ion” of a higher-lever s~)ccificat ion by a lower-level one.11

5.1.2.9 Introduction of Axioms and Definitions

In the introduction to this chapter, it was noted that a specification typically consists of a collection of axioms and definitions. Axioms can assert arbitrary l)roperties over arbitrary (new or existing) entities. Definitions arc axioms that arc restricted to dcfiuing new concepts in terms of known cmc!s. This difference has important iu~plications; axioms can introduce inconsistencies, whereas well-formed definitions cannot. Specification languages differ with respect to facilities for introducing axioms and definitions} including the rigor with which they guarantee that axioms are consistent and definitions well-defined. Some specification languages do not allow the introduction of axioms. Although this avoids the problem of inconsistency, it can create others. For example, axioms are particularly useful for statiug assumptions about the environment and the inability to define such constraints axiomatically can prese]lt a considerable

] 1 Refinement is a topic that is not covered in this volume. A representative sample of the work in this area, including both model-based and algebraic approaches, may be found in the proceedings of recent workshops 011 refinement, including [dEidRR89, hlti’90], as well as in [BHL90]. 58 Chapter 5 drawback. On the other hand, the ability to int reduce axion~s should always hc off- set & a nlethod (and, ideally, nlcchatlical support) to demonstrate their consistency. While some ]anguagcs prohibit arbitrary axionlat izat ions, others offer little or no assurance that definitions arc well-fornmd, that is. constructed according to a definitional principle appropriate to the given (specification) language. The role of this principle is to ensure what is referred to as a conservative mlension to a theory.

“A theory A is an ‘extension’ of a theory B if its language includes that of B and every theorem of B is also a tlmorem of A; A is a ‘conservative’ extension of 11 if, in addition, every theorem of A that is in the language of B is also a theorem of A’ [Rus93b, I). 58].”

The richness of the underlying logic, the strength of the definitional principle, and the degree and power of the associated Inechanizat ion determine the nature and extent of the concepts that may be defiued in a language. Recursive definitions are an exam- pie. The problem with recursive dcfinit ions is that they may not terminat c on certain arguments, that is, they may bc partial rather than tcjtal. ‘There are various strategies for extending a ddillitional princi~)le to recursive definitions. One strategy is to prcj~ride a fixed template for recursive definitions along vrith a meta-proof that establishes that all correct instantiation of the template terminate. The strategy used in PVS is to prove well-foundeduess using a technique based on a “measure’) function whose value decreases across recursive calls and is bounded from below. 12 The classic example, factorial, is defined in PI’S as follows, where the MEASURE clause specifies a fuuction to be used in the termination proof. In this case, the Ineasure is simply the (generic) identity function supplied by the PVS prelude.

factorial (x:nat) : RECURSIVE——-— nat = ————. IF x = O THEN 1 else x * factor ial(x-1) ENDIF r MEASURE id .—. “---”---1— ?’his dcfini t ion generates a type well-formedx!css condition that, must he discharged before the definition is considered type correct. The condition states that for all natural numbers, x, either x = O or x - 1 is strictly less than x. Anot]ler type of definitional principle, called a “shell”, provides a conlpact way to specify new structured types in terms of constructors, rccognizers, and accessors that respectively construct new elements of the type, recognize bona fide (suh)elements of the type, and access (sub) elements. 13 This concis~! specification is expanded schematically to generate the axioms necessary to establish the consistency of the definition, and —— .—. — 1 ‘The template approach is more restrictive, but easier to implement; it does not require theorem proving to establish the well-definedness of a definition as does the measure function strategy. 13 The name “shell” WZE first introduced by Boyer aud Moore [Div179, pp. 35-40], \vho note that their shells were inspired by Brrrstall’s “structures” [13ur69]. NASA. ~;~.ool .97 59

(i~i so,ne cases) to provide other usefu] constructs SUC1, as induction schen,es, The consistency of the axioms is assured by a meta-proof on the shell principle. Boyer a~ld Lfloore make extcllsivc use of the shell lJrinciple, axiomatizing fundamental objects ilicluding tllc llatural nutnbers, literal atoms, and ordered pairs, as well as new ty~ws. PVS uses a similar, bllt somewhat more sophisticated shell mechanism to define abstract data ty~)es [Sha93]. ‘The ubiquitous example of a pushdown stack can be very concisely sl)ecified ill I’VS.

stack [ t: TYPE] : DATATYPE BEGIN empty: empty stack? push(top: t, POP: stack): nonempty_stack? END stack -. —. -— empty and push are the constructors, empty-stack? and nonempty_stack? are the recognizes for the corres~)onding constructors, al~d top and pop are the acccssors for ~lollenlpty stacks. When stack is typechecked, a ncnv PVS theory, stack-adt, isgener- atccl that collsists of approxinlately a ~)age and a half of 1’VS a[ld prcwides the axionls a]ld inductioli principles to ensure that the datatype is well-fornled. ‘I1lIC distinction between definitional versus axiomatic specification is revisited in Sectioll 5.2, wl)ere tllc inl~)lications of the two styles are discussed. The point of this some~vhat long cxcursioll has been to underscore the utility of both approaches; powerful dcfi~litiona] ~)ri~lciplcs and arbitrary axionlatizatiolls each have a role in fornlal s~wcificatioll, and a s~)ecification language that provides both accon~~)anied by suitable nlecllallization is a I)otentially more productive tool than a language that effectively supports oIle a~)~)roacll to tile exclusion of the other.

5.1.2.10 Encapsulation Mechanism h4cchanis111s that provide tile ability to modularize and encapsulate are as important ill sl)ecificat ioll laxlguagcx as they are in programming languages. Mechanisms t hat not only support nmdularization, but also allow ~)arameterization of the modules provide even greater utility I)ecause they encourage reuse. For example, a sorting module can be defixlcd ge]lcrically and parametrized by the type of entity to be sorted and tile ordering to be used. tliereby allowing a single module to be (re)used to sort entities of difrercnlt ty~m .accordi~lg to different ordering relations. In PVS, such a module (called a THEORY) might al ]pear as follows, where the idea is to sort sequences of type T with respect to tile orderi[lg relation <=. The signature of this relation indicates that <= takes two elements of ty~w T atld returns a Boolean value.

I SO~t [T : TYPE, <= : [T, T -> bool]] : THEORY —— J 60 (hpt cl” 5

TO ensure that instantiaticms are appropriate, for example, that the values provided to tbc ordering relation in fact constitute an appropriate ordering, semantic constraints arc associated with tbe instantiation. There are various mcxhauisms for accomplishing this, including attaching assumptions to the formal parameters of tbe module, as in PVS. For exanll~le, it may be useful to constrain <= to bc a preorder (that is, reflexive and transitive).1~

sort[T:TYPE, <=: [T, T -> bool]: THEORY BEGIN ASSUMING preorder: ASSUMPTION pre-order?(<=) ENDASSUMING END sort

This assumption must be discharged whenever the module sort is instantiated.

5.1.2.11 Built-in Model of Computation

Most applicationsof formal methods iuvolvereasoniug about computational processes. Iuthediscussion ofdiscrete domain models (Section 4.3), itwasl~otedtl latsolllesl)ecification languages have a built-in model of computation, for example, in tbe form of a process algebra as in LOTOS [1 S088] or certain progral~lt~lil~g-lal~guage constructions, such as the concurrency mechanisms offered in Gypsy [GAS89]. If a model of computation is present in a lan.gtiagc, it is important to ensure that tbe ccjmputational model is suitable for tbc application at hand. For example, a study of synchronization algorithms cannot very well be performed in a notation based on synchronous con~- municat ion [Rus93b, p. 162]. On tbe other hand, many specification languages do not illcor~)oratc a model of computation, or iucor~)orate only a very elementary model, such as functional composition. Using functional application and composition, almost any logic can represent sequential computation. l,auguages such as PVS that are based on classical higher-order logic are typically rich enough to specify more complex computations, such as those involving irnperativc, concurrent, distributed, and real-time algoritbrns. For example, important properties of distributed systems can often be described and analyzed using recursive fuuctions [LR93b].

5.1.2.12 Executability

Executability provides a pragmatic approach tc) exploring and debugging specifications, and to developing and evaluating test cases. Further discussion of executability may be fouud in Sections 5.4 and 6.3.

‘“preorder? is a predicate defiued in the PI’S prelude [0 SR93a]. NASA -GB-001-97 61

5.1.2.13 Maturity

The advantages of a nmtum slmification lauguagc arc similar to those of a matutc l~rograll~t~~itlgl allg~lage: documelLtatio~l isrcasollably acccssil)lealld complete. tool sul)- ~)ort is available and generally relial)lc, there is a reasonably large body of associated literature and al)l)lications, aud tllcre is soInc ~ncasurc c)f standardization so that a s~)ecificatio~l written in the lauguage provides au unambiguous and gcmerally accepted description.

5.2 Formal Specification Styles

Specification style has various implications, rau.ging from readability to ease of proof. As Srivas and hlillcr note in reference to the formal verification of a commercial lni- crc)processor (arguably the most, ambitious microprogram verification undertaken to date) [SM95a, p. 31]: “C)llco ftllc~llorci rll~)orta~lt lesson slearned during this project was to more carefully consider the trade-offs betwwcn . . styles of specification.’ > Sri- vas and Miller are specifically referring to a collstruc.tive versus a descriptive style of specification, also known as model-oriented versus l~ro~Jerty-orieT~ted, respectively.15 A constructive or nloclel-oricmtcd style is tyl)ically associated with the usc of definitions, w]lereas a descriptive or ~)ro~)ert.y-orie~ltcd style is generally associated with tile use of axionls. For cxanlple, consider the mod function, which returns the remainder when one natural nunlber is divided by auother. mod can be s~)ecified constructively by defil~iug a recursive futlction that returns the appropriate value. or descriptively by axioulatizing certain of its nutnbcr theoretic prvpertics [SM95a, p. 28]. The descri~)tive style cmcour- ages u?lders~)ecijic:atio?l- specifying less rather than more, and doiug so as abstractly as possible thereby avoiding the tendency to focus on how a concept is realized rather thau simply wlLat is required of it, whmeas tile constructive style tends to promote ooerspcci’catiow -specifying more rather than less aud doing so in greater detail and specificity than necessary- thcreby allowillg all iltl})lelllelltatioll bias to cree~) ill earlier than warralked. On the other band, descripti~w or axiomatic specifications can introduce inconsistencies aud cau be less easily read aud uudcrstood by the uuilliti- ated reader than constructive specifications. Constructive specification also tend to correspond more naturally to the procedural requirements used in many ap~)lications. Ultimately, the trade-offs I)etween tlie two styles must be arbitrated by the application and by the options provided by t Ilc slwcificat ioll lallguagc used. Agaiu, Srivas and Miller’s cxperieuce is instructive.

“It became evident, that [the descriptive style was] in many ways a preferable style of specification . . . more readable, simpler to validate, aud . . . closer ——-— ..— — ] 50t her terminology is also found in the literature; for example, the term “prescriptive” is sometimes used to refer to a constructive style of specificatiorl and “declarati~’e” to a descriptive style. to what a user wantecl to know. . . . Usiug this style would have made specifying the core set of 13 instructions much simpler. However, doing so also would have made it easier to introduce inconsistencies in the specification. . . . The declarative [sic, that is, descriptive] style of specification is better- suited for reasoning !vith complex instruction sets [Sh195a, pp. 30-31 ].”

Many applications can benefit by the judicious usc of both styles. One approach is to use a property-oriented axionlatization as a top-level specification and introduce a suitable number of specification layers between the property-oriented requirenlents statenlents and increasingly detailed, (provably consistent ) model-oriented descripticms, possib]y culnliuating in an implementation-level specification. The idea is to establish that tile iltl~)lelllelltatioll satisfies the requirements. Few analj’ses elaborate multiple layers----the s exan~ple docunmted ill [BHMY89, Bcv89] and sumnlarizcd in Section 5.3 is a notable exception; for most applications, Inore cost-effective strategies focus on key properties early in the life cycle. There are other considerations that may be viewed as stylistic, including the trade- offs lmtween a functional style of specification versus one in which the notion of state is explicitly re~mesent,ed, for exanlple, using “Hoare Sentcnccs’) to express pie- and post- condit ,.ion< on a %ate.16. Some specification lauguages support, both styles. while others sup~)ort only an implicit Ilotion of state. If tlm notion of state is implicit., tile model of computation may be more or less explicit. For exan~plc, if t he specificat iol L of a control systelll must support the analysis of properties characterizing the evolution of the system over time, the (monitored, controlled, aud state) variables are typically represented as traces, that, is, functions from “time” to tllc type of value concerned. where t ilne represents a frame, cycle, or iteration count. l’urely functional specifications are in- trinsically closer to ordiuary logic and therefore tencl to support more effective theorem ~)roving than specifications that, involve state. In general, specifications involving state tend to be unnecessarily constructive for earlier life cycle applications; functional style s~)ecifications are often adequate for the requirements and high-level design phases.

5.3 Formal Specification and Life Cycle

One approach to integrating formal specification with system development is to construct a hierarchy of specifications at different levels of abstraction, each level corresponding to a different phase of the software life cycle and each level elaborating or “refining” the immediately preceding level. Using formal proof to establish that each level of the design is a correct i~llI~lel~~e~~tatioll of its immediate ancestor, it is possible —— —16 As an antidote to then-current program verification approaches that generated verification condi- t ions (1’CS) from programs annotated with logical assertions, yielding I’CS that }vere diflicult to map back to the original program (and the user’s intuition), Hoare extended the logic to include program elements, thereby allowing the user to reason directly about programs [Hoa69]. NASA-GB-001-97 63 to develop a proof chain that automatically demonstrates that required properties are satisfied at all levels - from the requirements specification down through the implementation (code level). Such proofs typically use a lnapping function that, relates tile objects of one level with the objects of the immediately preceding level and prove that the rnappil~g is preserved through all possible executions. NTeedless to say, hierarchical specification over multiplc levels is an arduous and costly undertaking. The “CL] short stack” [Bev89] a mechanical verification of a multilevel system from all a~)p]ications program in a high-level language down through the gate-level design of a microprocessor with intermediate lCVCIS including a compiler, assembler, and linker - exem~)lifies this approach. The LaRC verification of a reliable colnputing platform for real-time control is another of the few extant examples [13 DH94]. Formal specification is typically most cost-effective early in the life cycle of a system. This is true for several reasons, notably the eflectivencss of conventional verification and validation activities later in the life cycle versus earlier, when there is an acknowledged dearth of cfl’cctive strategies and tools, and the difficulty of formal specification during the later life cycle, in the context of highly detailed, implement at ion- sl>ecific models. ‘This rationale dovetails nicely with the largely pragmatic considerations that have focused most applications of formal methods on critical or key properties rather than on “total correctness.” As a result, formal specification is most productively used as an integral part of the iterative development of rccpiremcnts and high-level design, rather than as a one-time, bcnedictory activity at the end of the process.

5.4 The Detection of Errors in Formal Specification

There are several potential sources of error in a formal specification:

● It can say too little or uuderspecify, that is, be incomplete

● It can say too much or overspecify, that is, be overly lJrescriptive, thereby unnecessarily constraining later phases of the life cycle

● or, it can be wrong, that is, it can be internally inconsistent or it can specify something anomalous or unintended.

@erspccification is diflicult to detect mechanically and typically requires considerable experience to recognize and avoid. 17 The other faults are generally Inore amenable to tile types of fault detection discussed below. Including formal proof, there are basically five regimens for detecting anomalies in a specification. The last four of these can be

17Jones characterizes a notion of overspecification or implementation bias for constructively defined specifications. Briefly, a specification is biased with respect to a given set of operations “if there exist different elements of the [underlying,] set of states which cannot be distinguished by any sequence of the operations.’ : [J01,90, pp. 216-219]. 64 CiIaJ)t(?r 5 effectively nlechanized aud typically occuI in the order given , since there is llo point in attempt ing proofs on a spccificat ion that is not syntactically and senlant ically correct. F@ the sanle token, there is no point in checking for semantic anonlalies in a specification that is not syntactically well-formed. 011 the other hand, cacll of these tccl]niclues has a ~)articular utility, and an integrated approach that ex~)loits the strengt]l of each is undeniably the Incjst effective. Ill sonic cases, this integration is inherent in a systenl, for exalnple,, cooperating decision procedures itl a theorenl prover, or the tight coupling of a typechecker and a proof checker to provide strict typecheckitlg in the presence of non trivially decidable properties. In other cases, the integration is achieved @ judicious use of available techniques, for exanlple, “prototyping” a potentially dillicult and costly proof by using model checking, simulation, or aninlation to exanline a finite case before attenl~)ting the nlore general proof with a theorenl prover or proof checker. 111 any case, the utility of the fault-detection techniques discussed below can be significantly enhanced by exploiting the potential synergy created by their judicious conlbinat ion. Inspection: Inspections run the gamut from informal peer review to well-defined, formalized procedures. The Fagau-style inspections discussed in Section 3.2 are among the most frequently used quasi-formal inspections. In theory, these manual ins~)cctions ca~l detect all the error types ~loted above, although in practice, manual inspections are llot as effective as mechanized tools in detecting subtle or drop-seated ano~nalicsj such as logical inconsistencies and (unintended) implications, or in consistently locatixlg senlall- tic or even syntactic errors ill specifications. NTcwcrthclcss, Fagan-style inspections and other similarly exacting inspection methods can effectively complement formal methods. and vice versa. The AAMP5 microprocessor project illustrates this point nicely. hliller and Srivas note the surr)rising

“extent t,o whicl) fcmnal specifications and inspections complemented each other. The inspections were improved by the use of a formal notation, reducing the amount of debate over whether an issue really was a defect or a personal preference. In turn, the inspections served as a useful vehicle for education and arriving at consensus on the most effective styles of specification. ~’his is reflected in . . . the lower number of defects recorded in the later inspections [MS95, p. 9].”

As tliis quote suggests, the sy~nbiotic relationship between formal methods and conventional inspection techniques provides a natural medium for technology transfer.

Parsing: I)arsing is a forln of analysis that detects syntactic inconsistencies and anonlalies, such as misspelled keywords, missing delimiters, or unbalanced brackets or pareli- theses. Parsing guaranties (only) that a specification conforms to the syntactic rules of the formal specification language in which it is written. Typechecking: ~’ypechecking is a form of analysis that detects semantic inconsistencies and anomalies, such as undeclared names or ambiguous types. As noted in NASA-GII-001-97 65

Sect ion 5.1.2, formal specification languages based on higher-order logic aclmit cffec- t ive typcchecking, while in general, those based on set theory do not. When available, strict tyl)echecking is an extrelnely effective way of determining whether a specification Inakes semantic sense. Again as noted in Section 5.1.2, the type system of a specification language may ~lot be trivially decidable, ill which case typechecking is similarly undecidable and proof obligations lnust be generated and discharged before the specification is considered typechecked. Execution (Sirnulation/Animation): Direct execution , sinlulation, and a~linlation offer further options for detecting errors in a specification. If a formal specification language is directly executable, or contains a directly executable subset, execution and anitnation can be acconlnlodated in the same formally rigorous context ill wllicli the specification is developed. If not, the formal specification must be reinterpreted into ]Iigh-level, dynamically executable program text that bears no formal relation to the original specification (see [h4J3T95, Chapter 5] for an example of the latter). Some languages offer both, that is, a directly executable subset, as well as the option of user- or systerll-dcfitled l)rograI~l text to drive animation of I1011eXWUtZLb]6! l)arts of the specification. The concrete represcntat ion of algorithms and data structures required by most finite-state enumeration and model-checking methods (see below) makes them directly comparat)lc to direct execution techniques, as found, for exatnplc, in the VDM-SL Tool- box [VDh!l]. In some cases, model checkers also provide simulation. For example, the reachability analysis strategy used by state-exploration model checkers can also be used to “simulate’) system behavior by exploring a single path (rather than all l)ossible paths) through the state space. 130th Murg’~ [DDHY92, ID93] and SPIN [H0191] call sinmlate the execution of n~odels written in their respective languages. The type of errors found by direct cxccutioll techniques varies, depcndi]lg on other error detection techniques, if any, used prior to sitnulation or anitnation. For exanlplej [MW95, p. 92] aninlated a specification that had previously undcrgolic only syntactic analysis and weak type analysis (essentially lin~ited to arity checking on function and operation calls). In their case, aninlation detected two type errors in addition to errors duc to rnisinterI)retation of the requircnlcnts, incorrect s~)ccification of requircnlents, and erroneous translation from the specification into the sinlulation lauguagc. t3xecutability also supports the dc- vclopnlcnt and systcnlatic evaluation of test suites, thereby potentially exposing flaws and oversights in a test regime, as well as in the corresponding specification.

Theorem Proving, Proof Checking, and Model Checking: Tlkeoren~ proving: proof checking, and model checking are all forms of analysis that can be used to detect logical anonlalies and subtle infelicities in a forn]al specification. Although historically these forms of validation were used to prove correctness of programs and detailed hardware designs, they are llow~ typically used for fault detection and design exploration, where they arc arguably most effective, as well as for verifying correctness. Tllc analysis provided by theorenl Ixoving, proof checking, and model checking not only involves the specification, but, also its logical consequences, that is, all formulas that can be proved fronl the original specification using formal deduction. There are several issues in the validation of formal specifications. One is the issue of internal consistency, that is, whether the specification is logically consistent. If ~lot, the specification fails to say anything useful. Another is the issue of l[lcal~illgflllllcss, that is, whether the specification means what, is intended. A third is the issue of completeness. Althougll various notions of completeness have been pro~)osed, the general idea is that a specification should identify all contingencies and define t)ehavior appropriate to ‘8each. The type. of testing and error detection offered by theorem ~Jr’ovillg, proof checkino~, and modeling is in many ways analogous to traditional testing reginles; the theorem prover, proc)f checker, or model checker “executes’) the specification, allowing the practitioner to explore design options and the implications of design choices.

5.5 The Utility c]f Formal Specification

A specification may serve many different functions. Lamport [Lam89, p. 32] has suggested that a formal slwcification functions as ‘{a contract kx%wecn the user of a system and its implementer. The contract should tell the user everything hc must know to use the system, and it should tell the inlplementer everything he must know about tile system to implement, it. In princi~de, once this contract has been agreed upon, the user aud the implementer have no need for further col~~~[~~ll~icatioll.” Lamport’s simile highlights three issues. First, as noted earlier, one of the Inost important functions of a formal specification is analytic; using the deductive apparatus of the underlying formal system, a formal s~)ecification serves as the basis for calculating, l)redictillg, and (in tile case of executable specificatiolls) testing system behavior. However, a formal s~)ec- ificatiou may also serve all important descriptive function, that is, provide a basis for documenting, communicating, or I)rototyping tllc l)ehavior and properties of a systenl. Second, a (completed) specification represents the formalization of a consensus about the behavior and properties of a system. Diverging somewhat from ],allll)Ort’s descril)- tio~l and focusing on the early life cycle, we prefer to view a formal specification as a contract bet weell a client, a requirements analyst (and possibly also a designer), and a forma] methods practitioner. Third, while in l)rinciple, a fitlalized contract precludes the need for further communication among the interested parties, in practice, moving from informal requirements to a formal specification and high-level design is an iterative rather than a linear process; issues ex~)osed in the dcwelopment of the formal specification Inay IIeed to be factored back into the requirements, and similarly, issues raised by the high-level design may percolate back to impact either the formal specification, the requirements, or both.

Although a specification that has not been validated through proof can be aptly compared to a program that has not been debugged, there are nevertheless rc!al benefits

18 Rushby [Rus93b, pp. 69-71] cites several specialized definitions, including characterizations of completeness for abstract data types arid for real-time process-control systems. ~TASA_ G~_OOl .97 67 to be gained from modeling and formally specifying requirements and high-level designs, including the following.

. Clarify Ikquircments and High -Lctwl Designs: A formal specification provides a concise and unamljiguous statcmcmt of the u~ldcrlying mquircmlents and design, thereby exposing fundamental issues that tend to be obscured by lengthy informal statements. ‘1’hc formalization of the requirements for the rece~lt ol)tilnization of Space Shuttle Reaction Control System Jet Selection (JS) [NASA93, A1)pcndix B] recounted here in %ction 3.1.1 illustrates this ~)oint nicely.

● Articulate Implicit Assumptions.” Forlnalisms can help identify and express inl- p]icit assumptions in requirenwnts and design. For example, the concept of state variables is not explicitly lneutioned in S1)ace Shuttle requirements: their existcncc must bc il[ferred from context by noting the function and persistence of local variables. F,xplicitly modeling and specifying state variables can significantly increase the precision and perspicuity of the requirements, as illustrated by the partial specification of the new Space Shut tlc Global Positioning System (GF’S) navi- gatioxl capability [DR96]. Identifying ulldocunlented assunll)tions is particularly important in the context of an cwolvillg system design. Another aspect of requirements and high-level design that frequently contains inl- plicit assumptions is the interaction of the systeln with the environnlent or context in which it is assumed to ol)erate, including the input space. hlaking input coll- straints and environmental assumptions explicit often exposes requirements and design-level issues that have been overlooked. ‘g l’he specificatioll of the Space Shuttle IIeading Ali,gnnwnt Cylinder Initiation] Predictor and Pc)sition Itrror LJis- plays Change Request (HAC CR) is a good exanqde of the value of the process of formalization for identifying and capturing undocunlentedj donlaimspecific as- sunlptions. Quoting fronl the report for the HAC CR fornlal nlethods ~Jroject: “Capturing such [domain-specific] knowledge and docunlenting it as rationale with tile specification is valuable [RI196, I). 17] .“

● Ezposc Flazm: The process of formalizatioxl invariably ex~)oses significatlt flaws in requirements and high-level desig~~, even without the benefit of analysis or proof. In the case of strongly typed specification languages, typcchecking can provide a potent tool for revealing anomalies in the specification, as well as potential anomalies in the requirements and design, and cloing so early in the life cycle while errors are far less costly to correct. The previously mentioned GI’S project [DR96] provides a nice example of the utility of specification for revealing anomalies in immature requirements for large, complex systems, especially among subsystem interfaces. Executing a specification provides another productive means of expos- itg flaws, as noted in [MW95].

19T’he A-7 IvIethodology [vS90], among others, has paid particular at tentioxl to the explicit enunlera- ticm of relevant environmental variables. 68 chapter 5

● ldcnti~g Exceptions: The discipline involved in fcmnalizing requirenwnts and high- level design alsc) serves to identify “end cases” and exceptions and to encourage nlorc t borough considcrat ion of these exceptional cases, as illustrated in [LFB96].

● Ez]akute Test Coverage: An executable specification may also be used to run and evaluate proposed test suites, yielding a measure of test coverage relatively early ill the life cycle.

‘The utility of formal specification also extends to ~sork in program transformation and synthesis, that is, the mechanical application of a series of transformations that derives a program from its specification. This approach differs from traditional com- pilation of ILigh-level languages i~lsofar as it seeks to bridge a far larger language gal) between in~)ut (slJecification) and output (program). To make this feasible, the scope of the specification language must tm severely constrained, and/or the transformation process must be guided by a skilled programmer. The techniques rely on a set of correctness-preserving transformations that guarantee that the resulting program will exhibit the same behavior as its specification. Ideally, the tra~lsformation also confers additional (desired) ~woperties such as efficiency. Suggestive, but by no means exhaus- t ive, examples of this broad spectrum of techniques are the following:

. Problems expressed in a specification-oriented language (for exanlpk:, pure Lisp) typically exhibit clarity and sinlplicity, but lack the efficiency and portability that conlcs from a conventional programming language (for example, FORTRAhT and C). 130Y1c has I) UISUCCI a transformational approach to bridging this gap [BoY89] that involves successive deconlposition into a series of steps that can be acconl- I)lished by the autonlatic application of a set of s~)ecial-purpose, but straightfor- w-ard transfornlations. Ekatnplcs include the use of a succinct functional specification to derive a FOI{TRAN iltl~>le~t~er~tatio~l of an algorithm for solving one- din~ellsiollal hy~)crbolic partial differential equations [BH91].

● A certain class of lJxoblenls can be solved by a carefully programmed instance of a general al~orit IInlic technique, for example, search problems can be solved by a ditride-allcl-ccJ1lclller strategy. KIDS (Kestrel Interactive Development Sys- tmn) [Smi90] ~)rovides tools for deductive inferencing, algorithm design, expression sim~)lification. finite differencing, partial evaluation, data type refinement and other .gcneral tratlsformations that allow a user “ to synthesize complex codes enl- bodying algoritllr[ls. data structures, and code-optimization techniques that might be too difficult to produce manually [SG96, p.31].” The approach is interactive; the user guides the systenl i~L the application of powerful correctness-preserving transformat ions. KIDS has I)ecn applied to a variety of domains, including scheduling, combinatorial design, sort ing and searching, computational geometry, pattern matching, and mathematical programming. jvA5’A_~~4J91.97 69

● Tile class c)f finite futlctions, including for cxanqdc, finite state transitions, lends itself totabular representations that can bcnlanipulated toperform various consistency a~ld con~~dcieness checks and, in sonw cases, to generate code and docunlen- tation. For exanlplc, the decision table, “a tabular format for specifying a conl~)lex set of rules that choose anlong alternative actions” [HC95, p. 97] provides the basis for the ‘1’ablewise tool [HC95, HGH96] that, tests thcw tables for consistency and conlpletelless, performs a linlited fornl of structural analysis, and generates Ada code inlplelnculting the table, as well as 13nglish-language docutncmtatioll.

● If an application domain is suitably restricted, it is possible to dcwelo~) a con~- ~)letely automatic process for synthesizing a program from its s~)ecification. l’hc AMPHION system [LPPU94] illustrates this approach for the domain of solar systcn~ kinematics. The user specifics a problcm via a graphical user intcrfacc portraying the domain’s astronomical objects and desired configuration. The system then selects components from a preexisting FORTRAhT subroutine library and synthesizes the “glue” code that assenltdes these components into a complete solution. ‘1’llc system applies collst ruct ive theorem proving to perform its selection and synthesis. The cnd user, however, operates purely at the specification lcwel and need never interact with this utldmlying mcchallisnl.

5.6 A Partial SAFER Specification

The PVS specification of SAFER is constructive in style and retains the explicit notion of state represented in the SAFER models developed at the end of Chapter 4. To facilitate readability and emphasize the n)appiug between infornlal description, requirenwuts, and the PVS fornlalization, the specification also preserves the bias to}vard representative rather than abstract forn)alization introduced into the n~odels of the preceding chapter. The conlplete PVS specification is presented in full in Section C.3.3. The fragment discussed below continues the focus on thruster selection. This discussion is intended to be self-contained; if additional infornlation on the relatively few PVS language features necessary to understand the fornlal specification can be found in Section C.3. I. Full PVS docutnentation is available in [0 SR93b]. The PVS s~)ecificatioll of thruster selection is a straightforward elaboration of the underlying functic)na] model dcweloped in Chapter 4. Accordingly, t}le skeleton of the PVS theory for thruster selection shown below consists of three functions: integrated_commands, which forms an integrated, six degree-of-freedom command from the HCM and AAH inputs; selected .thrusters, which takes an integrated command and selects the thrusters necessary to achieve the command; and select ed.actuators, which acts as an interface function and consists of the composition of integrated_ commands and selected-thrusters. Each of these functions is parametrized by from onc to three parameters denoted by a parameter name followed by 7(I chapter’ 5 a type name. ‘1’he type defiuitious for these types are not, reproduced hem, but are available iu subsequent discussion and in Appendix C either iu the theory avionic s.types or in the theory most closely associated with the object iu question. For example, the types six.dof_command and rot-cormand arc defiued in the theory aviorLics_types, while the type AAH-state is defiued itl the theory automat ic_attitude_hold. The type actuator_commands is defined as a thruster_li st. Thruster selection is fcmmalizecl as a PVS theo?y aptly named thrust er_selection. The theory is the basic organizational concept iu I’VS and provides the modularization aud encapsulation familiar in modern ~)rogramluing languages; theories may export to and import fmm other theories.

—-—.——.———.—— — .—— ——.. ——. thruster_ selection: THEORY BEGIN Ir integrated. commands ( (HCM: six_dof_command) , (AAH: rot_command) , (state: AAH_state)) : six_dof_command = . . .

select ed_thrusters(crnd: six_dof_command) : thruster_list = . . .

selected_ actuators ( (HCM: six_dof_command) , (AAH: rot_command) , (state: AAH_state) ) : actuator-commands = select ed_thrusters (integrated_ commands (HCM, AAH, state) )

END thruster_ selection

Fleshing out the skeleton of thruster_selection introduces a type definition (thruster_list) and five additional functions. However, the first thing to notice about this elaborated version is the IMPORTING clause, which allows visible entities introduced iu the theories avionics-types, propulsion module, and automat ic_attitude_hold to be imported and used in the theory thruster_select ion. — —— —- IMPDRTING avionlcs_types, propulsion_ module, automat ic_attitude_hold [——. .. —..- 3

For example, this importing clause brings iu several type declarations, iucluding those mentioned above for six.dof -command and rot-command. The import iug clause is followed by a local declaration of the type thruster-ii st, which is defined as a list of thruster_names.20 The type thrust ernames is in turn imported from the theory propuls ion module. -—- —. zOThe thru~ter_ll~t d~cla~atiorl actually USeS the built-in list datatype provided in the p~s Pre- lude [0 SR93a, pp. 39 41,78 80], [Sha93]. - A’AsA-GIHlol-97 71

—— . __ .— ____ thruster.list: TYPE = list [thruster.name]

------[ ------—— ——.‘-----1.

The next declaration introduces the lloolean-valued function rot-cmds-present, whose signature includes onc patwneter of tylw rot.command.

rot_cmds_present(cmd: rot_command): bool = ( EXISTS (a: rot_axis): cmd(a) /= ZERO) [. —————— -—_1

~’lle declaration for rot-command defines a function from type rot-axis to type axis_command.

—————.——-—— .— -. rot_axis: TYPE = {roll, pitch, yaw} axis_command: TYPE = {NEG, ZERO, Pos} [.rot_command—— .—_ .— :.— TYPE = [rot.axis—. -> axis_command].— rot-axis is an enumerated type corresponding to the three rotation axes: roll, pitch, yaw. axis_command is anelmn~erated tyI~ewitl~t llree~’aluesc orresl)o~ldil~g tothe IICM or AAII command values: negative, m-o, c)r positive. Tlw notation cmd(a) denotes a fuuction that nla~)sarotatio naxis (one of: roll, ~)itch, yaw) tothe commandassociated with that axis (one of RTEG, 2ER0, PC) S). rot.cmds-present returns the value of the existentially quantified formula slLown above. That value is true if them is at least one rotational axis wlmse associated (HCM or AAH) command is ncmzero, and false otherwise.

l’hc next functiou. prioritized.tran_cmd, specifies the requirement that there is at luost one translation command at a given cycle and that translation axis commands are prioritimd ~vitll X-axis commands having highest priority and Z-axis commands lowest ~)riority. ~’llcexlf:oclillgtakes thcforn] ofanestcd-if expression and usesa PVS override ex~mssiol) to derive a new value from null -tran-command, which is written as an un~latnccl fullct io~l or lambda expression. ‘1’he result of an override expression is. a functiollzl t)lat is exact]v the Satne as the original, except that it takes on nelv values at tile s~)ccified argun~el~ts. A tran.command does the analogous mapping for the translation axes. X. Y, and Z that the rot-command does for the rotation axes.

Accordingly: in tl]e first branch of the nested-if ex~nwssion, if an X-axis conlmalld is preseilt (the value of tran(X) is not equal to ZERO), null _tran_command takes on the value of tran (X) for the argument X, and similarly for the other branches of the nested-if, whicil handle tllc cases for Y- and Z-axis updates. _—— ——— ——.. —. .. ——— —.— ..— — ‘1 Or recorrl; a PI’S record may also bc modified by an override expression 72 Cklptcv 5

tran_axis: TYPE = {X, Y, Z} tran.command: TYPE = [tran_axis -> axis.command] rnull_tran_command: tran_command = (LAMBDA (a: tran_axis): ZERO)

prioritized_tran_cmd(tran: tran-command): tran-comand = IF tran(X) /= ZERO THEN null_tran_command WITH [X := tran(X)] ELSIF tran(Y) /= ZERO THEN null_tran_command WITH [Y := tran(Y)] ELSIF tran(Z) /= ZERO THEN null_tran_command WITH [Z := tran(Z)] ELSE null_tran_command ENDIF l.. Thcfunction combinedzot .Cmdstransfornls rotation conunands fronltheHCh4and the AAH and returns a “coml~ined” rotation conmand that inhibits HCM con)nlands at the tin~e AAH is initiated (ignoreHCM), but otherwise gives nonzero HCM rotatio~l ccmunands prcxedence over AAH rotation comtnands. The argunlent ignoreHCM is a predicate, that is, a function with range type Boolean. IVote the use of the lan~bda expression to map over the three rotation axes. rrot_predicate: TYPE = [rot_axis -> bool] I combined_rot_cmds ((HCM_rot: rot_command) , (AAH : rot_command) , (ignore_HCM: rot_predicate)): rot_command = (LAMBDA (a: rot_axis): IF HCM_rot(a) = ZERO OR lgnore_HCM(a) THEN AAH(a) ELSE HCM_rot(a) ENDIF) L

Usingthepreceding definitions, integrated-commands iselaboratedas shown below. Tlleonlynew’ bit ofF’VS that requires explanation isthe record structure used tos~)ecify the integrated six degrec-of-freedomc ommand. InPVS, record types take theform

[#ol:il,... a, flt,,#] where the a~ are the accessors and the tz are the component types. Record access in PVS uses functions and functional notation, for example, az(r), rather than the more usual “dot” notation r-.ai. Elements of the PVS record type (or, equivalently, record constructors) have the form (#cll:tl,... f2,tit,l#) iVAsA-Gf3-ool-97 73

Wr example, the record type six .dof command has two acccssors, one each of type tran-coxnmand and type rot_command. In other words, at) integrated six degree-of- frecdom command has two components rcprmcntiug the commanded acceleration in the translational and rotational axes. Since both components am modified, record constructors rather that] override expressions arc used. Details of the AAH_state record type have been suppressed below, but a~qwar in full in Appendix C. The requirement that IICM rotation commands suppress IICM tramlatioxl comnlands, but HCN4 translation commands may coexist with AAH rotation commands, is specified by the two branches of t lle if-ex~)ression.

rot_ cmds_present (cmd: rot. command) : bool = (EXISTS (a: rot_axis): cmd(a) /= ZERO)

six_dof command: TYPE = [# tran: t.ran_command, rot: rot_command #]

AAH_state: TYPE = [# ignore_HCM: rot_predicate, . . . #]

integrated_commands ((HCM: six_dof_command) , (AAH: rot.command) , (state: AAH_state)): six_dof_command = rot_cmds_present (rot(HCM)) THEN (# tran := null_tran_command, rot := combined_rot_cmds(rot(HCM) , AAH, ignore_HCM(state)) #) ELSE (# tran := prioritized_tran_cmd(tran(HCM) ), rot := AAH #) ENDIF

Astute readers may have noticed that this version of integrated_commands does not take into account the additional requirement that AAH is disablecl on an axis ifa crew!~lell~ber rotatioll col~~l~lal~d isisslledfortllat axis while AAH is alive, resulting inthc ~>ossibilit~~ reflected illtlle l~~odcl ill Clla~~ter 4astlle tra1lsitio1] “threcaxesoff,” where all threcaxesh avetxcndisablcd in this way. .Actually, the version of integrated-commands presented above is slightly simplified; the full version in Appendix C does hatldle this case.

The next two functions, BF’_thrusters and LRUI.thrusters, specify the thruster select logic presented in the tables ill Figures C.2 and C.3, respectively. ‘The details are omitted here, but the full version in Appendix C specifies these tables using nested PVS tables that yield admirable traceability bciween thedocumentatioll and the s~)ecification. 74 Chapter 5

— — — BF_thrusters(X_cmd, pitch_cmd, yaw_cmd: axis_command): thruster_list = . . .

LRUD_thrusters(Y_cmd, Z..cmd, roll_cmd: axis_command): thruster_list = . . . —- 1

Thcelaboratwl version of selected.thrusters reveals son~ewbat n~ore about how an integrated six degree-of-freedom con~n~and is mapped into a vector ofactuator con}- lnallds. The specification uses a PVS let expression, a syntactic convenience that allows the introduction of bound variable nan~es to refer tc) subexpressions. In this case, the bound variables refer to the back/front (BF) and the left/rig;llt/uJ~/dow’11 . (l,RUD) thrusters defined by the thruster select logic (specified as BF-thrusters and LRUD-thrusters) to inlplenlent the conmanded translational and rotational accelerations. ‘The resulting list of thrusters is formed by appending the BF and LRUII thruster lists.

➤ ✍✎ ✿ 1 selected_thrusters (cmd: six_dof_command): thruster_list = LET BF_thr = BF_thrusters(tran(cmd) (X), rot(cmd) (pitch), rot(cmd) (yaw)), LRUD_thr = LRUD_thrusters(tran(cmd) (Y) , tran(cmd) (Z), rot(cmd) (roll)) IN append(BF_thr, LRUD_thr) L_ . . . .._____.— .— J

Once again, the function presented here is a somewhat sin~plified version of the specification in Appendix C. In this case, the sinlplificationhas been to omit the logic corresponding to the right n~ost two colutnns of Figures C.2 and C .3, which specify the use of two additional thrusters for certain commanded accelerations if the given constraints are satisfied. For exan~ple, the thruster select logic for “-X, -pitch, -yaw” (first row of the table in Figure C.2) specifies thruster 134 and, conditionally, thrusters B2 and B3; 132 and 133 arc selected only if there is no conmandcd roll.

The final function in theory thruster-selection is the interface function selected. actuators, which was previously introduced as it appears in Appendix C. Thesomcwhat abbreviated version of the full theory discussed here is collected in full below. Note that type declarations from other theories reproduced above to facilitate the discussiondo not explicitly appear, but are implicitly “visible” via the IMPORTING clause. NASA- GB-001-97 75

thruster. selection: THEORY BEGIN

IMPORTING avionics.types, propulsion.module, automatic_attitude_hold

thruster_list: TYPE = list [thruster_name]

rot_cmds_present(cmd: rot_command): bool = (EXISTS (a: rot_axis): cmd(a) /= ZERO)

prioritized_tran_cmd(tran: tran_command): tran_command = IF tran(X) /= ZERO THEN null_tran_command WITH [X := tran(X)] ELSIF tran(Y) /= ZERO THEN null_tran_command WITH [Y := tran(Y)] ELSIF tran(Z) /= ZERO THEN null_tran_command WITH [Z := tran(Z)] ELSE null_tran_command ENDIF

combined_rot_cmds ((HCM_rot: rot_command) , (AAH: rot_command) , (ignore_HCM: rot.predicate)): rot_command = ( LAMBDA (a: rot_axis): IF HCM_rot(a) = ZERO OR ignore_HCM(a) THEN AAH(a) ELSE HCM.rot(a) ENDIF)

integrated_commands ((HCM: six_dof_command) , (AAH: rot_command) , (state: AAH_state)): six_dof_.command = IF rot_cmds-.present(rot(HCM)) THEN (# tran := null_tran_command, rot := combined_rot_cmds(rot(HCM) , AAH, ignore_HCM(state)) #) ELSE (# tran := prioritized_tran_cmd(tran(HCM) ), rot := AAH #) ENDIF 9

BF_thrusters(X_cmd, pitch-cmd, yaw_cmd: axis-command): thruster-list = . . .

LRUD_thrusters(Y_cmd, Z-cmd, roll_cmd: axis-command): thruSter_list = . . .

selected_thrusters(cmd: six_dof_command): thruster_list = LET BF_thr = BF_thrusters(tran(cmd) (X) , rot(cmd) (pitch), rot(cmd) (yaw)), LRUD_thr = LRUD_thrusters(tran(cmd) (Y) , tran(cmd) (Z), rot(cmd) (roll)) IN append(BF_thr, LRUD_thr)

selected_actuators( (HCM: six_dof_command) , (AAH : rot_command) , (state: AAH_state)): thruster_list = selected_thrusters(integrated-commands (HCM, AAH, state))

END thruster_selection Chapter 6

Formal Analysis

Formal analysis refers to a broad range of tool-based techniques that can be used singly or in combination to explore, debug, and verify formal specifications, and to predict, calculate, and refine the behavior of the systems so specified. These analysis techniques, which differ primarily in focus, method, and degree of formality, include direct execution, sitnulation, and animation; finite-state methods (state exploration and model checking); and theorem proving and proof checking.

This chapter describes each of these techniques and suggests strategies for their productive combination. It also examines the role of proof in theory interpretation, proofs of properties, and enhanced typechecking, as well as the utility of the proof process for calculation, prediction, and verification. The issue of mechanized support for formal analysis is presented, albeit in a suggestive rather than exhaustive discussion. The chapter closes with the specification and proof of the SAFER requirement that describes the maximum number of thrusters that can be fired simultaneously.

6.1 Automated Deduction

Automated deduction or theorem proving refers to the mechanization of deductive reasoning. Deductive methods provide a foundation for reasoning about infinite-state systems and are typically preferred for abstract, high-level specifications and data-oriented applications. There are a variety of approaches to mechanizing formal deduction, reflecting the relative maturity of the field of mechanical theorem proving. This section begins with background material on formal systems and their models, followed by a history of automated deduction, a survey of techniques underlying automated reasoning, and concluding remarks on their utility.

77 78 Chapter 6

6.1.1 Background: Formal Systems and Their Models

The material in this section provides technical background that some readers may prefer to skip the first time through, or to detour altogether. Dangerous bend signs bracket the most technical parts of the section.

6.1.1.1 Proof Theory

A formal system consists of a nonempty set of primitives--typically a set of finite strings taken from an alphabet of symbols; a set of axioms, that is, statements, taken as given, involving the primitives; and a set of inference rules or other means of deriving further statements, called theorems. 1 The axioms and rules of inference of a formal system are referred to as its deductive sgstern. A set of axioms, together with all the theorems derivable (provable) from it and from previously derived theorems, is called a theory. A proof of a theorem in a formal system is simply a series of transformat ions that conform to the rules of inference of that system. As such, the notion of proof is strictly syntactic. The symbol t- (read “turnstile”) is used to express this notion of proof. Thus I-L +, read “@ is provable in logic L“ (or, equivalently 1- @ if the logic is unambiguous from the context ), means that + is a theorem in the given logic, that is, @ is provable using the axioms of L without further assumptions. In general, the relationship between a sentence @ and the set of sentences, -yo . . . . . ,7., asumed for its proof is expressed as -ye),..., ~n t- 2’, where each -yi is either an axiom, an additional assumption, or a previously proved theorem. The notion of formal system sketched thus far is purely syntactic, describing what is generally referred to as an uninterpreted calculus or simply a calculus. The study of the purely formal or syntactic properties of an uninterpreted calculus, including deducibility, consistency, simple completeness, and independence, is called proof theory. The three notions of consistency, completeness, and independence are not equally important. Consistency is of fundamental importance because it provides a minimal condition of adequacy on any set of (nonintentionally self-contradictory) axioms. A formal system is consistent if it is not possible to derive from its axioms both a statement and the denial (negation) of that statement. The notion of completeness has many different interpretations, all of which share the idea that a formal system is complete if it is possible 1 In this section, the terms sentence, statement, and well-fomed fOmUhI are used bterchageably, avoiding subtle distinctions sometimes made in the literature. In the context of fist-order logic, these terms are synonymous with closed formula and denote a formula in which there are no bee (unbound) variables. 2Assumptions are statements assumed to be true without proof. Axioms are assumptions whose truth is assumed to be “self -evident,” emptilcally discoverable or, in any case, stipulated for the sake of argument, rather than proved using the given rules of inference. There are logical and nonlogical axioms. The latter deal with specific aspects of a domain, for example, Peano’s axioms (postulates) which are interpreted with respect to a domain of numbers, whereas logical axioms deal with general logical properties of the given calculus, for example, the axioms of propositional calculus. ivAsA-GB-ool-97 79 to derive within it all statements satisfying a given criterion. In general, completeness has theoretical importance for logicians, but less importance for those working in formal methods. It is quite difficult to establish completeness for systems of any complexity, and many interesting and even importaut formal systems are provably incomplete. A formal s

A formal system, S, is decidable if there is an effective procedure (algorithm) for determining whether or not any closed, well-formed formula, ~~, of S is a theorem of S. Simple completeness can also be defined in terms of decidability. A formal system, S, is simply complete if it is consistent and if every closed, well-formed formula in S is decidable in S [Sho67, p. 45]. A formal system, S, is semidecidable if there is an algorithm for recognizing the theorems of S. If given a theorem, the algorithm must halt with a positive indication. If given a nontheorern, the algorithm need not halt, but if it does, it must give a negative indication. S is undecidable if it is neither decidable nor semidecidable. The prc)positional (statement) calculus is decidable. The predicate calculus is semidecidable, although there are subsystems of first-order predicate logic, such as monadic predicate logic (s~named because ~Jredicates can take only one argument), that are decidable.

In the logical tradition, the distinction between syntax and semantics largely reflects the distinction between formal systems and their interpretations, as studied by proof theory and its semantic analog, model theory, respectively. An interpretation consists of a (nonempty. abstract or concrete) domain of discourse and a mapping relative to that domain that assigm a semantic value or meaning to each well-formed sentence of the calculus. as well as to every well-formed constituent of such a sentence. For example, an interpretation for a predicate calculus would assign a value to function and predicate symbols. constants, and variables. The meaning or semantic value assigned to a syntactically well-formed sentence of the predicate calculus would be a truth value, either true or false, depending on the values assigned to its constituent parts. If the description of a forma] system includes semantic rules that systematize an interpretation for each syntactically well-formed constituent, the calculus is said to be interpreted.4 — 3Godel’s proof that arithmetic is incomplete if consistent used a proof-theoretic notion of completeness. 4Carnap [Car58, pp. 102-3] defines a calculus as “a language with syntactical rules of deduct ion,” an interpreted language as ‘a language for which a sufficient system of semantical rules is given,” and an 80 chapter 6’

6.1.1.2 hflodel Theory

An interpretation is a model for a formal system if all the axioms of the formal system are true in that interpretation. Sitnilarly, an interpretation is a model for a theory or for a set of sentences if it is a model for the formal system in which the theory or the set of sentences are expressed and all the sentences in the given theory or the given set of sentences also valuate to true in that model. If a theory has an axiomatic characterization, a model for the theory is necessarily a model for the axioms of the theory. Most interesting theories have unintended (nonstandard) models, as well as intended (standard) ones. For example, plane geometry is the standard model of the Euclidean axioms, but not, as was believed before the discovery of the non-Euclidean geometries, the only model. Similarly, the natural numbers are the standard or intended model of the Peano axioms, although, again, not the only model [Kay91]. The fact that an inconsistent system cannot have a model provides both a syntactic and semantic characterization of consistency that can be usefully exploited. For example, it is typically easier to demonstrate syntactically that a system is inconsistent, deriving a contradiction from the axioms, than to use a meta-level argument to prove that the system has no models. Conversely, it is generally easier to demonstrate semantically that a system is consistent by exhibiting a model, than to show the impossibility of deriving a contradiction from the given axioms. Model theory is the study of the interpretations of formal systems. Of particular importance are the concepts of logical consequence, validity, completeness, and soundness. Definitions of these notions reveal the rich interplay between proof theory and model theory. Let 1 be a set of interpretations for a calculus and ~~ be a sentence of the calculus. ~~ is satisfiable (under 1) if and only if at least one interpretation of 1 valuates @ to true. ~~ is (universally) valid, written ~ @, if and only if every interpretation in 1 valuates ~ to true.5 If every model of a set of sentences, S, is also a model of a sentence, @, then S is said to entail r), written S + ~~.

Let @ be a sentence and r be a set of sentences 41, ...,& of a formal system, S. S is semantically complete with respect to a model Af (weakly semantically complete) if all (well-formed) sentences of S that are true in M are theorems of S. A formal system, S, is sound if r ~ @ whenever I’ 1- G, that is, if the rules of inference of S preserve truth. Semantic completeness is the converse of soundness; soundness establishes that every sentence provable in S is true in S relative to M, and (semantic) completeness establishes that every sentence true in S relative to M is provable in S. Both the propositional calculus and the predicate calculus are sound and complete. ——. interpreted calculus as “a language for which both syntactical rules of deduction and semantic rules of interpretation are given. ” 5Arguably, for the purposes of formal methods, only those interpretations that make the theorems of a formal system true, that is, only the models of the system are of interest. With this in mind, the definitions of satisfiability and validity can be stated in terms of models rather than interpretations, as done in [Rus93b, p. 223]. NASA-GB-001-97 81

There is also a semantic characterization of independence. A given axiom, ~, of a formal system, S, is independent of the other axioms of S if the system, S’, that results from deleting O has models that are not also models of (the whole system) S. Ideally, the syntactic and semantic notions of independence are provably equivalent for a given system S. As noted with respect to the proof- and model-theoretic charac~erizations of consistency, a semantic argument may be easier in some cases and a syntactic one in others. However, it is apparently still an open question as to lvhat properties a system must possess to ensure that the syntactic and semantic characterizatiolls of independence are equivalent.

6.1.1.3 An Example of a First-Order Theory

Shoenfield’s classical axiom system for the natural numbers, N, provides a nice illustration of a class of formal system known as a first-order theory [Sho67, pp. 22,3]. In the following definition, A, l?, and C are formulas and z and v are (syntactic) variables in the given first-order language, f is an n-ary function symbol, and p is an n-ary predicate symbol. A formal system, T, is defined as

● a first-order language

● the following logical axioms, as well as certain further nonlogical axioms

o propositional axiom: 1A V A 0 substitution axiom: A=[a] –> 3zA 0 identity axiom: z = z 0 equality axiom: z] = yl + . . . + xn =yn + fzl. ..zn = fyi. ..gnor X]=yl -+... -+’z7L= gn-+pzl. ..xn+ pyl...y~~

● the following rules of inference~

o expansion rule: infer B v A from A o contraction rule: infer A from A V A o associative rule: infer (A V B) V C from A V (1? V (7) o cut rule: infer B V C’ from A V -?3 and -A V C o 3-introduction rule: if z is not free in B, infer 3zA + B from A –~ B

The definition of T provides the logical apparatus necessary for specifying a (first- order) theory. The only additions required are a specification of the theory’s nonlogical symbols and its nonlogical axioms. For example, Shoenfield’s axiomatization of the natural numbers is specified as a theory, N, with the following nonlogical symbols and axioms [Sho67, p. 22].

6An occurrence of z in A is bound in A if it occurs in a part of A of the form 31B; otherwise, it is tree in A [Sho67, p. 16]. ● nonlogical symbols: the constant 0, the unaty function symbol S (denoting the successor function), the binary function symbols + and . , and the binary predicate symbol <.

. nonlogical axioms

N1. Sz#O hT2. Sz=Sy–+x=~ N3. z+O=X N4. z+- Sy = S(Z: + y) N5. x.0==0 N6. z. Sy=(Z. y)+x N7. -,(x < O) N8. x< Sy~+x

6.1.2 A Brief History of Automated Proof

The automation of mathematical reasoning coincides with the emergence of the field of Artificial Intelligence (AI), whose early pioneers embarked on a program to (mechanically) simulate human problem solving. 7 By 1960, theorem provers for the full first-order predicate calculus had been implemented by Paul Gilmore [Gi160] and by Hao Wang [wan6~b, wan6(la] in the United States, and by Dag Prawitz [PPV60] in Sweden. Although this mechanization constituted an important proof of concept, the practical utility of the theorem provers was limited, due to the combinatorial explosion of the search s~)ace encountered in proofs of anything other than relatively simple theorems. Following Shankar’s exposition [Sha94], it is useful to distinguish three approaches in the subsequel~t development of automatic theorem proving and proof checking: resolution theorem provers, nonresolution theorem provers, and proof checkers. This discussion focuses solely on developments in Europe and the United States. There is also significant work in automated theorem proving in the region formerly known as the USSR and in the People’s Republic of China. The Chinese have been particularly active in the area of decision procedures for geometrical applications [BB89, p. 27]. The first eflicient mechanization of proof grew out of work done by Alan Robinson in the early 1960s and published in 1965 [Rob65]. Robinson combined procedures independently suggested by Davis and Putnam and by Prawitz to automate a significantly more efficient proof procedure for the first-order predicate calculus known as resolution.

7hlacKenzie [hIac95] and B15-sius and Biirckert [BB89] provide interesting histories of post-Euclidean dcwloprnents in automated reasoning. NASA-GB-001-97 83

The key notion from Prawitz was unification, an algorithm that gives the unique, most general substitution that creates a complementary pair of literals P and 7P. Reso- lution is a complete refutation procedure for first order logic (see Section 6.1.3.1.3). After its introduction in the mid 1960s, resolution was a focal point for activity in automated theorem proving, yielding numerous extensions and optimization. By 1978, Loveland’s textbook on automated theorem proving documented some 25 variants of resolution [Mac95, p. 14]. Despite this considerable activity and a steady increase in computing power, the early resolution theorem provers suffered from the same limitation that had plagued the previous generation of mechanical proof procedures: the combinatorial explosion of the proof search space. The 1970s also witnessed the emergence of logic programming, originally attributed to Kowalski and Colmerauer [Kow88]. Colmerauer and his colleagues implemented a specialized resolution theorem prover called Prolog (abbreviating the French “Progran~- mation en Logique” ) that implemented Kowalski’s procedural interpretation of Horn clause logic$. The result was a theorem proving system that could be used as a programming language [SS86]. Despite a decline in the 1970s due largely tc) disappointing performance, research in resolution theorem proving continued. Although unification remained the crucial algorithm, resolution provers added sophisticated heuristics, data structures, and optimization to manage combinatorial explosion. The result has been increasingly efficient, powerful systems. In the 1970s and early 1980s, research in resolution theorem proving existed primarily at Argonne National Laboratory, where Robinson had originally been introduced to automatic theorem proving. Argonne’s Aura (Automated Reasoning Assistant) and, more recently, Otter [WOLB92] systems have successfully proven not only known theorems, but also open conjectures in several fields of mathematics. In addition to Otter, current state-of-the-art resolution provers include SETHEO [LS1392] and PTTP [Sti86]. Paulson characterizes Otter, SETHEO, and PTTP as “automatic theorem proving at its highest point of refinement” [Pau97] and notes their extremely high inference rates, their efficient use of storage, and their ability to prove many of the toughest benchmark problems. Resolution methods yield proofs that are not readily understood by humans. This perceived weakness, as well as the difficulty of combining resolution with nonlogical inference techniques such as induction, led researchers to pursue other approaches, including various levels of human interaction and a renewed interest in heuristics. In the 1970s, Wood y Bledsoe and his colleagues at the University of Texas began work in “nonresolution theorem-prcwing,” pursuing proof procedures that yielded more natural and powerful proofs for mathematical theorems, as well as heuristics (like those of the early AI pioneers) that produced human-like proofs. Although Bledsoe initially developed an automated prover for set theory that combined both resolution and heuristics, he later replaced resolution with a more “natural” procedure, augmented with a ‘(litnit heuristic” for calculus proofs, algebraic simplification, and linear inequality routines. The — 8A clause is Horn if it has at most one positive literal, for example, -1P(z) V -@(x) V R(z). 84 Chapter 6 resulting prover successfully proved theorems in elementary calculus that had stymied existing resolution-sty]e provers [Mac95]. Robert Boyer and J Strother Moore have collaborated on several influential theorem provers that use heuristics to develop proofs by induction and rewriting. The hlqthm series of provers [13M79, BN488], and its successor ACL2 [KM94, KM96], are highly automated, but, require user guidance to accomplish difhcult proofs. In the hands of skilled practitioners, the Boyer-Moore prover has been used to prove program and hardware correct ness [BHM}’89, Hun87], as well as mathematical theorems, including tile automated proof of Godel’s incompleteness theorem undertaken by Shankar for his doctoral dissertation [Sha94]. Other productive approaches to automatic theorem proving have included conditional rewriting as found in the Rewrite Rule Laboratory (RRL) system [KZ89] and matings as used by Andrews and his colleagues to develop a theorem prover for higher- order logic [AMCP84]. The distinction between theorem provers and proof checkers is tenuous, typically reflecting the intended use of the system or the degree of automation relative to other systems, rather than hard and fast differences .9 Nevertheless, certain systems are more consistently identified as proof checkers. Automath, developed by de Bruijn and his colleagues at the Technische Hogeschool in Eindhoven, The Netherlands, was one of the earliest and most influential proof checkers, originating ideas subsequently used by several modern languages and inference systems [Sha94, p. 19]. Automat h provided a grammar whose rules encoded mathematics in a way that allowed mechanized checks of correct ness for Automath statements, as illustrated in [vBJ 79]. The LCF (Logic for Computable Functions) system is another influential proof checker. In LCF, axioms are primitive theorems, inference rules are functions from theorems to theorems, and typecheckin,g guarantees that theorems are constructed only by axioms and rules [Pau91, p. 11]. There are higher-order functions known as tactics and control structures known as tacticals (see Section 6.1.3.3), yielding a programmable system in which the user determines the desired level of automation. LCF has been used to verify program properties [GMW79] and to check the correctness of a unification algorithm [Pau84]. Several well-known systems have evolved from LCF, including HOL, hTuprl, and Isabelle. HOL (Higher-Order Logic) is a widely used system with extensive libraries that is employed primarily for verification of hardware and real-time systems. Nuprl is based on constructive type theory and was developed at Cornell Uni- versity by Joseph Bates and Robert Constable as a mechanization of Bishop’s program of constructively reconstruct ing mathemat ics [Sha94, p. 19]. The Nuprl system has been used primarily as a research and teaching tool in the areas of constructive mathematics, hardware verification, software engineering, and computer algebra. Isabelle is a generic, interactive theorem prover based on the typed lambda calculus, whose primary inference rule is a generalization of Horn-clause resolution. Isabelle supports proof in any

‘For example, Shankar variously identifies both iYqthm [Sha94] and PVS [SOR93] as theorem provers and proof checkers. 9

NASA-GB-001-97 85

logic wl~oseitlferel~ce rules callbeexpressed as Horl]clauses [Pau97]. Isabelle represents a synthesis between two largely distinct traditions in automated reasoning: resolution theorem proving and interactive theorem provin.g.

6.1.3 Techniques Underlying Automated Reasoning

The preceding discussion identified major proving traditions including resolution, equa- tional or rewrite systems, constructive type theory methods, Boyer-Moore-style systems, and a variety of other methods loosely characterizable as interactive. The resulting systems can be classified in various ways, including the interelated dimensions suggested by Gordon [Gor]: type of logic supported, extensibility, degree of automation, and closeness to underlying logic. Generic theorem provers can be configured for a variety of ‘ logics while specialized theorem provers exploit a particular application-oriented logic (for example, temporal logic model checkers) or contain features optimized for selected applications. There are several variations on extensibility; a theorem prover may not be extensible, or it may offer a metalogic (allowing the user to program the underlying logic), an extendab]e infrastructure (allowing the user to program sequences of proof steps), a reflective capability (allowing the prover to reason about its own soundness and thereby the soundness of proposed extensions), or a customizable syntax (ranging from alternative notations to parser support). In general, specialized systems such as model checkers are more automatic than general-purpose provers, all of which use some degree of automation. Degree of automation is also influenced by the closeness of proof to the underlying logic. Systems in which theorem proving differs little from the process of fornlal proof in the underlying logic tend to be more automated than those in which the difference is greater.

6.1.3.1 Calculi for First-Order Predicate Logic

In principle, inference rules may be used in one of two ways [BB89]. Starting from the logical axioms, inference rules may be applied until the formula to be proven (valid or unsatisfiable, depending on whether the calculus is positive or negative, respectively) is derived. This approach is called a deductive calculus. Alternatively, starting from the formula whose validity or unsatisfiability is to be shown, inference rules may be applied until logical axioms are derived. This second approach is termed a test calculus. The relationship between deductive and test calculi is analogous to that between forward and backward chaining state transition systems. As these remarks suggest, there is a variety of different calculi for first-order predicate logic, each offering a different perspective on the nature of validity [EIE93]. The Gentzen ‘calculus, including the variant known as the sequent calculus, is a positive deductive calculus, whereas Robinson’s resolution calculus is a negative test calculus. These two calculi are introduced following a brief discussion of normal forms for predicate logic formulas. A survey of logical calculi may be found in [BE93]. 86 Chapter 6

6.1.3.1.1 Normal Forms hTormal forms are standardized formats intended to make predicate logic formulas easier to understand and manipulate. ‘This section considers two such forms: prerwz normal form and skolem normal form. Valid formulas of the form A +> B, including important (tautological) equivalences such as the laws of quantifier distribution and the laws of quantifier movement, may be used (in conjuct ion with a variable renaming rule to avoid unintentional variable binding) as value-preserving transformations. These transformation rules yield a logically equivalent prenex form in which all quantifiers occur on the left, in front oft he quantifier-free matrix [BB89]. Skolemizationl named after the Norwegian mathematician Thoralf Skolem, yields a normal form that is particularly useful because it explicitly represents quantificational dependencies of assignments to variables. Following an explanation in [BB89], a formula Vxl, . . . . Zn ~g~ in prenex form may be transformed into VZ1, . . ., ~~1>”, where 7“ is obtained from 7 by replacing each free occurrence of y with a Skolem function, fv, of the form fv(zl,. . . . Zn). The process of skolemization is not model-preserving, that is, a formula and its skolernized form are not equivalent. However, a formula is satisfiable (unsatisfiable) j ust in case its sko~em- ized form is. Since only universal quantifiers remain after skolcmization, the quantifiers are often implicitly assumed, yielding formulas of the form 7’.

There are various skolemization strategies. The method described here begins with a formula in prenex form, but it is also possible to skolemize a formula that is not in prenex form by keeping track of the essential “parity” of the quantifier. Parity refers to the number of negations in whose scope the quantifier occurs. Almost all mechanical theorem provers use some form of skolemization.

6.1.3.1.2 The Sequent Calculus The sequent calculus is a variant of the deductive calculus developed for his dissertation by the German logician Gerhard Gentzen [Gen70]. Gent zen was interested in using syntactic inference rules to model mathematical reasoning, and he defined the sequent calculus to make the assumptions on which a formula depended more transparent. This transparency yields a calculus that is particularly suited to computer-assisted proof because the information relevant to a given part of the proof is localized. Two additional advantages attributed to the sequent calculus include the intuitively plausible nature of its inference rules and their symmetric construction, yielding relatively systematic and natural proof construction. A sequent is written r 1 A, meaning Ar 3 VA, where r is a (possibly empty) list . of formulas {Al, . . ., Am} and A is a (possibly empty) list of formulas {Bl,.. , IIn}. In a sequent r F A, the formulas in I’ are called the antecedents and the formulas in A are called the succedents or conseguents. Intuitively, the conjunction of the antecedents should imply the disjunction of the succedents, that is, Al A . . . A Am 2 B1 V . . . V Bn. A sequent calculus proof can be viewed as a tree of sequents whose root is a sequent of NASA-GB-001-97 87 the form F A, where A is the formula to be proved and the antecedent of the sequent is empty. The proof tree is generated by applying inference rules of the form

r]EAl ““. rnh AnN —.. I’}A

Intuitively, the rule natned N takes a leaf node of a proof tree of the form 17 h A and adds the n new leaves specified in the rule. If n is zero, that branch of the proof tree terminates. The propositional inference rules consist of the Propositional Azzom and rules for conjunction (A), disjunction (V), implication (2), and negation (n). The Propositional Axiom rule applies when the same formula appears in both the antecedent and succedent, corresponding to the tautology (I’ AA) > (A V A), where 17 and A consist of the conjunction and disjunction, respectively, of their elements.

Ax r, AFA, A

There are two rules for each of the propositional connective and for negation, corresponding to the antecedent and consequent occurrences of these connective. The negation rules simply state that the appearance of a formula in the antecedent is equivalent to the appearance of its negated form in the succedent, and vice versa.

rEA, A r,A}A F,lAI-AIE rFIA, AE -

The inference rules --I I and t- m are often referred to as the rules for “negation on the left” and “negation on the right,” respectively. Negation on the left rule can be derived as follows. Using the identity (X > Y) E (-TX V Y), the antecedent can be written =r v (A v A), which is equivalent to (117 V A) V A, and to =(-W V A) D A. Invoking one of De Morgan’s Laws (~(X V Y) = (1X A =Y)), 1(47 V f!) > A is equivalent to (I’ A 7A) > A, which is an interpretation of the succedent. The same symmetric formulation and naming conventions are used for the other rules, including those for the binary connective. The rule for conjunction on the left is a consequence of the fact that the antecedents of a sequent are implicitly conjoined; the rule for conjunction on the right causes the proof tree to divide into two branches, requiring a separate case for each of the two conjuncts.

A,l?, rEA Ah I’t A,A rkB, A F- A AA B, I’ t-A I’!-A/IB, A

The rules for disjunction are duals of those for conjunction. 88 Chapter 6

A, I’PA B,r}QvF . ‘E A’B’AEV AVB, I’ t-A I’I-AVB, A

The rule for implication on the right is a consequence of the implication ‘(built in” to the interpretation of a sequent. The rule for implication on the left splits the proof into two branches analogous to the two cases encountered with the rules for conjunction on the right and disjunction on the left. NTote that one case of the implication on the left rule requires the antecedent to the implication be proved and the other case allows the consequent of the implication to be assumed.

171-A, A b’, rEA —— 3t- “AFB’A t-3 A> E’,l’ I-A 17 EA>B, A

To illustrate propositional reasoning in the sequent calculus, consider the following proof of (P> QnR)>(PAQ>R). reproduced from [Rus93b, pp. 231-233]. The implies symbol > associates to the right, and binds less tightly than A. This formula is actually an instance of the law of expor- tation. The first step is to contruct the goal sequent

and then seek an applicable inferenw rule. There is only one choice in this case: the rule for implication on the right (with [A +– (1’ > Q > R), B + (F’ A Q 1) R)] and I’ and A empty). (P> QoR)E(J’AQ>R) ~= _F(P3Q3~)3(PAQ3~) Considering the sequent above the line

there are two choices for the next step: implication on the left or implication on the right. Implication on the left will cause the proof tree to branch. Since it is usually best to delay branching as long as possible, implication on the right is the best option (this time with [r e (P ~> Q > R), A + F’ A Q, B + R] and A empty)

(P> Q> R), (P AQ)I-R (P>Q>li?)E(PAQOR)~=

Focusing once again on the sequent above the line

(P> Q> R), (P AQ)FR NASA-GB-001-97 89 there are two options: implication on the left or conjunction on the left. As in the last step, the strategy of delaying branching as long as possible narrows the choice. Applying conjunction on the left yields (P> Q> R), P,QER (p3Q>R), (1’ AQ) &RAF NTOW the sequent above the line is

and the only choice is to use the rule for implication on the left

The right branch can be closed immediatelyl”

— Ax P, QFP, R

‘The left branch requires another application of the rule for implication on the left: R, P,Qt R P, QI-Q, R (QoR),p,Q~R ‘t The left and right branches can then be closed:

——— Ax R, P,Qh R

Ax P, QkQ, R Since all the branches are closed, the theorem is proved. The preceding steps can be collected into the following “proof tree” representation:

— Az Ax R, P,QFR F, QFQ, R >t — Ax (Q DR), p,Q~R P, QI-P, R _——. ——-- >} (P> Q> R), P, Qt-R ~PDQ3~),(pAQ)FftAFF3 ‘(P> Q> R) F(PAQ>R) ~= ‘- R(P>Q>R)>(PAQ>R) — —— 1°Strictly speaking, it is first necessary to use an Exchange rule to reorder the formulas in the antecedent, and similarly for closure of the left branch, below. The Exchange rules are introduced at the end of this section. 90 Chapter 6

First-order sequent calculus extends the propositional sequent calculus presented above with inference rules for universal and existential quantification and with an inference rule for nonlogical axioms. 11 In the statement of the quantifier rules, a is a new constant (that is, a constant that does not occur in the consequent of the sequent) and t is a term.

rRA[zwt], AE3 —.—I’, A[x-a]FA3F——— I’, (3z: A) F A TR (3z:A), A

The quantifier rules are the sequent calculus analog of skolemization (cf. Sec- t ion 6.1.3.1.1). The basic idea is that to prove a universally quantified formula, it is sufficient to show that the formula holds for an arbitrary constant (a), and to prove an existentially quantified formula, it is only necessary to show that the formula holds for a given term (t). The four quantifier rules reflect the underlying duality between universal and existential quantification. The rule for nonlogical axioms is used to terminate a branch of the proof tree when a nonlogical axiom or previously proved lemma appears in the consequent of a sequent.

.—— — Nonlog-az I’t-A, A

~,here A is a nonlogical axiom or previously proved lemma For convenience in developing proofs, it is useful to provide an additio~ial rule called “cut” as a mechanism for introducing a case-split or lemma into the proof of a sequent 17 E A to yield the subgoals I’, A 1- A and I’ t- A, A. The subgoals are equivalent to assuming A along one branch and having to prove it on the other. Alternatively, applying the rule for negation on the right, the subgoals are equivalent to assuming A along one branch and -A along the other.

A, I’ t-A I’I-A, A -—— ———.—— —- cut rFA

The Cut rule can be omitted; a well-known result in proof theory, the Cut Elimin- ation Theorem (also known as Gentzen’s Hauptsatz), establishes that any derivation involving the cut rule can be converted to another (possibly much long;er proof) that ————.. — 11 Technical]~, it is also ~onk,enient to ~lodify the propositional aXiOIn to alh’ not onlY ‘or the case where the formula in the antecedent is the same as that in the consequent, but also for the case of two syntactically equivalent formulas, that is, formulas that are the same modulo the renaming of bound variables. NASA-GB-001-97 91 does not use cut. Since cut is the only rule in which a formula (A) appears above the line that does not also appear below it, it is the only rule whose use requires “inven- tion’> or “insight”; thus, the cut elimination theorem provides the foundaticm for another demonstration of the semi-dccidability of the predicate calculus [Rus93b, p. 244]. Finally, there are four structural rules that simply allow the sequent to be rearranged or weakened. These rules have the same status as the Cut rule; they can also be omitted. The Exchange rules allow formulas in the antecedent and consequent to be reordered.

—.rl, B, A,r2}Ax E rEAl, B, A, A2Fx 1’11 A, B, rz F A rI-A1, A,l?, A2

The Contraction rules allow multiple occurrences of the same sequent formula to be replaced by a single occurrence.’2

6.1.3.1.3 The Resolution Calculus The resolution calculus is a negative test calculus for formulas in clausal forn~13; it contains a single logical axiom and uses only one rule of inference, the resolution rule. The single axiom is an elementary contradiction denoted by the empty clause (D). In its simplest form, the resolution rule may be viewed as a special instance of the cut rule (of the sequent calculus) in which all single formulas are Iiterals [BB89, p. 56]. Using notation from [131389], the resolution rule is defined as follows. clausel: L, Kl,... ,Kn clause2: TL, M1,. ... M~, resolvent: K1,. ... Kn Ml,... ,M~ ~rhere clauses ] and 2 are referred to as the parent clauses of the resolvent and L and -IL are the resolution literals. A generalization of this rule allows an instantiation of the formulas in terms of a substitution that maps variables to terms uniformly across both resolution literals. Using the same notation, the general resolution rule is expressed as shown below, where u represents a substitution that makes the atoms L and L’ equal, that is, UL = crL’. clausel: L, Kl,... ,Kn clause2: TL’, M1,... ,Mm rcsolvent~ oK], . . . ,oK,, OMl,, ... uMn — 12 The structural rules (Contraction and Exchange) are sometimes formulated in terms of a single weakening rule. Is’That is a disjunction of literals, w,here a literal is a proposition or a negateCl proposition. Quan- tifiers are n~t permitted. Universal quantifiers are implicit, and existential quantifiers are replaced by Skolem functions as described in Section 6.1.3.1.1. For example, in clausal form, VX3V12(Z, y) becomes R(Z, f(z)). 92 Chapter 6

If a substitution, o exists for two expressions, the expressions are said to be unifiable and the substitution is called a unifier for the two expressions. Given a pair cjf expressions, there are distinguished unifiers, known as the most generui unifiers from which all other unifiers may be derived by instantiation. The following examples are taken from [BB89]. The terms z and j(g) are unifiable. The substitution {x e ~(y), y ~- a} is a unifier for x and f(y), although it is not a most general one, since it can be obtained from the most general unifier {z ~ .f (Y)} W further instantiating y with a. There are two equivalent most general unifiers for the pair of terms ~(x, g(x)) and ~(y, g(y)): {z ~ y} and {y - x}, which differ only with respect to variable names. The terms x and ~(x) are not unifiable. Neither are the terms g(x) and ~(~). Resolution is a complete refutation procedure for first-order logic. If a sentence is false under all interpretations over all domain-- that is, unsatisfiable, then resolution will terminate with the empty clause indicating a contradiction has been derived. If the negation is unsatisfiable, the original theorem is true. If the origirlal theorem is not true, resolution may not terminate. The proof of the completeness of resolution is based on a result from Jacques Herbrand’s 1930 dissertation. Rough] y, Herbrand’s theorem states that in proving a set of clauses, S, unsatisfiable, the only substitutions that need to be tried are those drawn from the set, H, of all variable-free terms formed from the functions (inclucling constant functions) occurring in S. The set, H, is known as the Herbrand Universe of S. Since H is always either finite or counts.bly infinite, a contradiction, if one exists, will always be found [CL73]. Resolution theorem provers can be highly effective in some domains. In general, they have not been used in formal methods because it has been difficult to combine resolution with induction and with the additional first-order theories necessary for formal methods applications. Furthermore, resolution methods do not readily support proof exploration and typically yield proofs that are not easily understood by humans. Nev- ertheless, fundamental techniques from resolution-based provers, such as highly efficient uuificatiou algorithms, have been incorporated in most modern theorem provers.

6.1.3.2 Extending the Predicate Calculus

The predicate calculus is not sufficient for most applications of formal methods, which typically require the addition of first-order theories such as equality, arithmetic, simple computer science datatypes (lists, trees, arrays, and so forth), and set theory. These four theories are basic to most applications. Particular applications may benefit (significantly) from the inclusion of additional first-order theories. Formal methods also require support for induction. In general, methods for automating inductive proofs are less well-developed, and user guidance is typically required for such proofs. A discussion of the current status of automated induction and the role of induction in formal methods appears in [Rus96]. The discussion includes an interesting fragment drawn from a specification of Byzantine fault-tolerant clock synchronization. NASA-GB-001-97 93

The next three sections sumtnarize some of the issues involved in developing first- order theories for equality and arithmetic, and introduce the topic of combinations of theories.

6.1.3.2.1 Reasoning about Equality The fundamental notion of equality is that if x and y are equal, then z and g have all properties in common, that is, z = y if and only if, z has every property that y has and, conversely, y has every property that x has. This idea was first formulated by I,eibniz and is also referred to as “Leibniz’s Law” [Tar76, p. 55]. Equality is reflexive, symmetric, and transitive and is therefore an equivalence relation. However, equality also satisfies the property of substitutivity (that is, equals may always be substituted for equals) and is thereby distinguished from mere equivalence relations. A model for a first-order theory with equality that interprets ‘(=” as the identity relation on the domain of interpretation is referred to as a normal model. Since it is possible to show that a first-order system with equality has a model if and only if it has a normal model, nothing is lost by restricting the focus to a normal model. An initial lnodel is one without “confusion” or “junk, ” where confusion and junk may be informally defined as the ability to assign elements to terms in a way that simultaneously preserves as distinct those terms not required to be equal by the axioms (no confusion) an’d leaves no element unassigned (no junk). The sequent calculus rules for equality directly encode the axiom for reflexivity (that states that everything equals itself) and Leibniz’s rule. The rules of transitivity and synnnetry for equality can be derived from these rules. The notation A[e] denotes occurrences of e in A in which no free occurrences of variables of e appear bound in A[e] and, similarly, for A[C]. ntathbf Ref/ additionally requires that a and b be syntactically equivalent, that is. a :: b,

Reasoning about equality is so basic that most theorem provers use very efficient methods to handle the chains of equality reasoning that invariably arise in automated theorem proving. Examples include efficient algorithms for computing the congruence closure relation ml the graph representing the terms in a ground formulal 4 [Sho78b, DST80, N{)79]. Equations alsc) commonly arise in the form of definitions, such as that for the absolute value functionl~: Irl = if x <0 then -- x else x.

14A ground formula is OIle in which there are no occurrences of free variables 15This and the following example are reproduced from [Itus93b]. 94 Chapter 6

One way to prove a theorem such as la +- bl < Iul + Ibl is to expand the definitions and then perform propositional and arithmetic reasoning. “13xpanding a definition” involves finding a substitution for the left side of the definition that causes it to match a term in the formula (for example, [x e a + b] will match lx I with la -k bl ), and then replacing that term by the corresponding substitution instance of the right side of the given definitiol~-- for example,

la+ bl=ifa-tb

Expanding definitions is a special case of the more general technique of rewriting. “The basic idea is to impose directionality on the use of equations in proofs; . . . directed equations are used to compute by repeatedly replacing subterms of a given formula with equal terms until the simplest form possible is obtained.” [DJ90] The notion of directed equation refers to the fact that although equations are symmetric--a = b means the same thing as b = a–- rewriting imposes a left-to-right orientation, hence equations viewed with this orientation are generally called rewrite rules. Rewriting may be used with arbitrary equations provided the free variables appearing on the right side of each equation are a subset of those appearing on its left. The process of identifying substitutions for the free variables in the left side of the formula of interest as a prerequisite to rewriting is called matching. Matching is sometimes referred to as ‘(one way” unification; although the process is essentially the same, only substitutions for the variables in the equation being matched are of interest. Rewriting may be automated or performed by the user. Two desirable properties of rewrite rules are jinite termination and unique termination, also knou’n as Church- Rosser. A set of rewrite rules has the finite termination property if rewriting always terminates. A set of rewrite rules is Church-Rosser if the final result after rewriting to termination is independent of the order in which the rules are applied. There are effective heuristic procedures for testing for the finite and unique termination properties, including Knuth-Bendix completion [KB70, DJ90], which can often be used to extend a set of rewrite rules that is not Church-Rosser into one that is. A theory that can be specified by a set of rewrite rules with both the finite and unique termination properties may be used as a decision procedure for that theory. Moreover, any such decision procedure is sound and, for ground formulas, complete, However, deducing disequalities is sound and complete only for the initial model. Therefore, systems that use rewriting to normal form as their primary or only means of deduction typically use an initial model semantics, whereas systems that use rewriting in conduction with other methods typically use a classical semantics and (only) infer disequalities axiomatically. There are several variations on rewriting, including order-sorted rewriting, conditional rewriting, priority rewriting, and graph rewriting. A description of these variants appears in the comprehensive survey of rewrite systems provided in [DJ90]. Term rewriting is highly effective, and essential to the productive use of theorem proving for formal methods applications. It serves as the primary means of deduction NASA-GB-001-97 95 in Afhrm [GM’I’+ 80, Mus80], Larch [wSJGJMW93], and RRL [KZ89] and is one of the most important techniques in the Boyer-Moore provers [BM88, Kh!196]. Rewriting may also be used for computation [GKK+ 88]. The paramodulat ion techniques [RW69] used in resolution are similar to rewriting.

6.1.3.2.2 Reasoning about Arithmetic Formal methods applications typically involve arithmetic expressions and relations o~,er both real atld Ilatural numbers, and both interpreted and uninterpreted function symbols. The ubiquity and often the complexity of this arithmetic make efficient deductive support for arithmetic essential to the productive use of formal methods [Rus96]. Integer arithmetic is sutliciently important that some formal methods systems include decision procedures for the quantified theory of integer arithmetic, often referred to as Presburger arithmetic after the Polish mathematician who first studied these arithmetics in the late 1920s. The decidable fragment essentially includes linear arithmetics with addition, subtract ion, mult iplicat ion, equality, the “less than” predicate (<), and, by simple constructions, the predicates >, s, ~. Classic Presburger arithmetic, which contains neither function symbols nor anything other than simple constants, is decidable. However, given the importance of function symbols and the fact that they may be introduced into formulas in which they do not originally appear through the process of skolernization, it is easy to appreciate the tension between efficiency (decidability) and expressiveness. Tools for formal methods often opt to restrict the arithmetic decision procedures to the ground (that is, propositional) case, where the combination of linear arithmetic wit h uninterpreted function symbols is decidable [CLS96].

6.1.3.2.3 Combining First-Order Theories One of the challenges in designing a truly useful theorem prover or proof checker is combining decidable theories both with one another and with user interaction. There are algorithms dating back to the late 1970s for combining decision procedures, including Nelson- Oppen [N079] and Shostak [Sho78b, CL S96]. The Nelson- Oppen algorithm combines decision procedures for two disjoint ground theories (for example, linear arithmetic and lists) by “introducing variables to name subterms and iteratively propagating any deduced equalities between variables from one theory to another” [CLS96]. Shostak combines theories that are canonizable (that is, can be converted to a canonical or normal form) and algebraically solvable using an optimized implementation of the congruence closure algorithm for ground equality over uninterpreted function symbols [CLS96]. Since Shostak’s approach appears to be very efficient, but is restricted to algebraically solvable theories, there is some interest in combining it with Nelson-Oppen. Most automated theorem provers and proof checkers minimally contain inlplementa- tions of decision theories for propositional logic, equality, and linear arithmetic. Cyrluk et al. note that the method used to combine decision procedures is more critical to 96 Chapter 6 the overall efficiency of the system than the efficiency of any single decision procedure (CLS96]. Therefore, it is important that new decision procedures, such as those that arise in response to needs identified in formal methods applications, wcmk effectively in combination with other theories.

6.1.3.3 Mechanization of Proof in the Sequent Calculus

‘This section illustrates how the proof of (P > Q ~ R) ~ (F A Q > R) from Sec- t ion 6.1.3.1.2 might proceed with the help of an interact ive theorem prover built on the sequent calculus style of reasoning. The presentation asssumes that the formula has been introduced to the toolset and given the name “theorem_l .“ Invoking a proof attempt on this theorem places the user at the theorem prover’s interactive interface. Intermediate scquents developed during the course of the proof are displayed, allowing the user to guide the proof at each step.

Beginning proof of “theorem_l” :

Antecedents: None —----._——--. — — > Consequent: Formula 1: (P => (Q => R)) => ((P & Q) => R)

‘The imaginary prover used in this example displays sequents in the format shown above. Actual provers use similar formats, although they are usually less verbose. The theorem prover’s interaction style is based on the user’s entry of a command to invoke a proof step, and the prover’s display of the results of that command. Application of inference rules is the main type of command, with various supporting utility functions, such as proof status and proof display commands, provided as well.

Step 1: apply-rule “implies-right”

Applying rule “implies-right” to the current sequent yields:

Antecedents: Formula 1: P => (Q => R) ===== .= > Consequent: Formula 1: (P& Q)=>R

The user would type the command after the ‘(Step 1:” prompt shown above. In this case, the inference rule causes a new sequent to be generated, as shown. NASA-GB-001-97 97

Step 2: apply-rule “implies-right”

Applying rule “implies-right” to the current sequent yields:

Antecedents: Formula 1: P => (Q => R) Formula 2: P&Q ======> Consequent: Formula 1: R

A second applicationofthe “implies-right” rule creates multiple antecedents. De- pendingon the formulas involved, this might mean future commands could apply to ‘ more than one formula. The prover would have to pick one by default or require the user to specify the formula.

Step 3: apply-rule “and-left”

Applying rule “and-left” to the current sequent yields:

Antecedents: Formula 1: P => (Q => R) Formula 2: P Formula 3: Q ======> Consequent: Formula 1: R

At this point, the proof has progressed without branching, but case splitting will now be required. The next rule application causes branching inthe proof tree, for which the prover supplies suitable node numbers tokeep trackof current and future locations.

Step 4: apply-rule “implies-left”

Applying rule llimPlles-leftl! to the current sequent produces two cases, the first of which, case 4.1, is as follows:

Antecedents: Formula 1: Q=>R Formula 2: P Formula 3: Q —---_———------> Consequent: Formula 1: R 9

98 Chapter 6

Only cme branch can be ?mrsued at a time. The prover will automatically return to the second branch after the current one is completed. I Case 4.1, step 1: apply-rule “implies-left” D Applying rule “implies-left” to the current sequent produces two cases, the first of which, case 4.1.1, is as follows:

Antecedents: Formula 1: R Formula 2: P B Formula 3: Q ------_——----- > Consequent: 9 Formula 1: R I Asecond application ofthc same rule causes further case splitting. Systenlaticnaviga- tionof the proof tree helps theuscr keep his or her bearings. The current branch can be terminated by applying the Propositional Axiom that B acknowledges when the sequent is a tautology. Normally, a user need not explicitly invoke this rule; most provers will recognize such opportunities and apply the rule 8 automatically.

Case 4.1.1, step 1: apply-rule “prop-axiom” I

Applying rule “prop-axiom” to the current sequent completes the proof of case 4.1.1. 9

Resuming with case 4.1.2: 9 Antecedents: Formula 1: P Formula 2: Q ===== .= > Consequent: Formula 1: Q B Formula 2: R

After dispensing with one branch ofcase4.1, the prover presents theuser with the other branch, and the “prop-axiom” rule applies again. NAsA.G~4joJ-97 99

Case 4.1.2, step 1: apply-rule “prop-axiom”

Applying rule “prop-axiom” to the current sequent completes the proof of case 4.1.2. This also completes the proof of case 4.1.

Resuming with case 4.2:

Antecedents: Formula 1: P Formula 2: Q ===== .= > Consequent: Formula 1: P Formula 2: R

After finishing allofcase 4.1, theprover pops back uptocase 4.2 to finish off the only remaining branch c)fthe proof.

Case 4.2, step 1: apply-rule “prop-axiom”

Applying rule “prop-axiom” to the current sequent completes the proof of case 4.2. This also completes the proof of “theorem_l”.

Q.E.D.

Recognizing that all branches ofthc tree have resulted invalid proofs, the prover an- nounces the successful completionofthe overall proof. Although this example has been cast in terrnsof a fictitious theorem prover, many actual provers follow a similar style of interaction. Level of automation, and therefore the nature of the interaction, varies considerably from one prover to another. For exarnplc,t helevel ofautomation may makeit unnecessaryto invoke rulesat the levelof detail presented here. Although the prover typically builds the full proof tree, the user generally sees only those portions of the tree requiring user guidance. ‘l?rivialcasesare typically not displayed, although there may bea facility for revisiting both the implicit and explicit steps ofa proof. On first attempt, most putative theorems attempted are incorrect, that is, they are not in fact theorems. Therefore it isat least as important that an automate ddeductionsystem facilitate the discovery oferror, as that it should efficiently prove true theorems. In addition to mechanizing routine manipulations, automated deduction systems should reduce the low-level interaction and repetitive tedium involved in large proofs. To this end, many interactive provers provide higher-order functions known as tactics and control structures known as tacticals that allow simple tactics to be combined into 100 Chapter 6 more complex ones. Paulson [Pau92, p. 456] notes that ideally tactics should capture the control structures typically used in describing proofs. He also remarks that, in practice, tactics often do not work at the level of proof description, but rather at a somewhat lower level. Nevertheless, tacticals potentially allow the user to perform hundreds of inferences with a single command. The concept and implementation of tactics and tacticals varies from prover to prover, but all share the idea that a theorem prover should be programmable. The challenge in using any automated reasoning system is to learn to use the automation effectively by exploiting the system’s strengths and realizing its limitations. Given the number and diversity of automated reasoning systems, the question invariably arises as to which system is most appropriate for a given application. Young [You95] suggests the use of benchmark problems to facilitate comparison of system performance . within specific areas. Although standard benchmarks have yet to be identified, there are problems, such as the railroad gate controller in the area of safety-critical systems, that have been attempted on a variety of systems.

6.1.4 Utility of Automated Deduction

Deductive techniques support more varied and more abstract models, more expressive specification, more varied properties, and more reusable verifications than finite state verification techniques. The essential utility of theorem proving or proof checking includes the following. With the exception of establishing the consistency of axioms, these benefits are self-explanatory and are listed with little additional comment.

● Guarantee Type Correctness: The type correctness of some specification languages is undecidable. In such cases, theorem proving or proof checking may be used to discharge obligations incurred during typechecking, thereby establishing that a specification is type-correct. As noted in Chapter 5, significant benefit accrues from typechecking alone.

● Establish (Relative) Consistency of Axioms: A specification can be shown to be consistent by demonstrating that its axioms have a model. In the context of mechanical verification, this is accomplished via theory interpretations that re- late a source specification (the one to be shown consistent) to a target specification whose consistency has presumably already been established16. This is accomplished by defining a mapping from the types and constants of the source specification to those of the target specification and proving that. the axioms of the source specification expressed in terms of that mapping are provable theorems of the target specification. The proof demonstrates relative consistency; .—. —_ .—— lGFor example, by specifying the target specification definitionally in a system that guarantees conservative extension. NASA-GB-001-97 101

that is, if the target specification is consistent, the source specification is consistent. [ORSVH95, p. 111] cites an example that underscores the need to validate axiomatic specifications by exhibiting an intended model.

● Challenge Underlying Assumptions: One of the benefits of formal specification is the explicit statement of underlying assumptions. Once formalized, these assumptions may be challenged by formulating and proving conjectures that exercise them. Design implications of new or modified assutnptions may be sitnilarly probed in this way.

● Establish the Correctness of Hierarchical Layers: Theory interpretations may also be used to demonstrate the correctness of hierarchical development, that is, to prove that a niore concrete specification is a satisfactory implementation of a more abstract one, as illustrated in [Bev89, BDH94]. The approach is similar to that previously mentioned in the context of establishing the consistency of a set of axioms.

● Conjirm Key Properties and Invariant: System properties and constraints may be precisely stated and deductively verified.

● Predict and Calculate System Behavior: System behavior may be predicted or calculated by formulating and proving challenges or putative theorems that characterize the behavior or functionality of interest.

● Facilitate Replication and Reuse: Reusing and adapting extant proofs, as well as formulating new challenges, provides a systematic exploration of the implications of changes and extensions, as well as an effective vehicle for generalizing results for later reuse. Automation is the key to faithfully replicating or reusing a detailed deduction. The L,aRC bit vectors library [BMS+96] illustrates many of the issues involved in developing general and effectively reusable formal analyses.

The use of proof as a form of absolute guarantee is not included in this list for reasons outlined in Section 7.5, and succinctly captured in the following quote from [RvH93]: “A mechanical theorem prover does not act as an oracle that certifies bewildering arguments for inscrutable reasons, but as an implacable skeptic that insists on all assumptions being stated and all claims justified.”

6.2 Finite-State Methods

The state space of a system can be loosely defined as the full range of values assumed by the state variables of the program or specification that describes it. The behaviors that the system can exhibit can then be enumerated in terms of this range of values. If the state space is finite and reasonably small, it is possible to systematically enumerate 102 Chapter 6 all possible behaviors of the system. However, few interesting systems have tractable state spaces. Furthermore, the state space of a formal specification can be infinite, for example, if it uses true mathematical integers as values for state variables. Nevertheless, there are various techniques for “downscalin.g” or reducing the state space of a system, while preserving its essential properties. Finite-state methods refer to techniques for the automatic verification of these finite-state systems or of infinite-state systems that can be similarly ‘keduced” by virtue of certain structural symmetries or uniformities. Given a formula specifying a desired system property, these methods deterl-nine its truth or falsity in a specific finite model (rather than proving its validity for all models). For linear-time and branching-time logics, the model checking problem is computationally tractable, whereas the validity problem is intractable.

6.2.1 Background

This section provides background information useful for an understanding of finite-state systems, including a brief introd uct ion to temporal logics, fixed point characterizations, and the modal mu-calculus.

6.2.1.1 Temporal Logic

Temporal logic (also known as tense logic) [Pnu77, Bur84] augments the standard operators of propositional logic with tense oyemtom that are used to formalize time-dependent conditions. The simplest temporal logic adds just two operators: the (weak) future operator, F’, and the (weak) past operator, P. The formula Fq is true in the present if q is true at some time in the future and, similarly, the formula Pq is true in the present if g is true at some titne in the past. These operators can be combined to assert quite complex statements about time-dependent phenomena. For example, q =+ FPq can be interpreted as “if q holds in the present, than at some time in the future q will have held in the past.” [McM93, p. 13] The duals of these operators, -@’m, usually abbreviated G and 1P–I, usually abbreviated H, yield the corresponding strong future and past operators. Gq - ~F7g means that q is true at every moment in the future, and Hq G -+’~g means that g is true at every moment in the past. A temporal logic system consists of a complete set of axioms and inference rules for proving all valid statements in the logic relative to a given model of titne. Some of the more commonly used models include partially ordered time, linearly ordered time, discrete time, and branching (nondeterministic) time. Linear time corresponds to commonly held notions of time as a linearly ordered set measured with either the real or natural numbers. Discrete time refers to a model in which time is represented as a discrete sequence measured by the integers, as commonly found in engineering. Interval Temporal Logic [Mos85] is based on discrete time. Branching time is a model in which the temporal order < defines a tree that branches toward the future; every instant has a unique past, but an indeterminate future [McM93, p. 15]. Temporal ArAcJA.~B_oo]-97 103 logic andthe closely related dynamic logzc“ 17 have been used to express program properties such as termination, correctness, safety, deadlock freedom, clean behavior, data integrity, accessibility, responsiveness, and fair scheduling [Bur84, p. 95]. Duration Cal- culus [CHR92], a notation used to specify and verify real-time systems, is an extension of interval temporal logic that uses a notion of durations of states within a time interval, but without explicit mention of absolute time. Temporal logics, and modal logics in general, are typically given a model theoretic semantics known as possible worlds semantics. A model in this semantics is usually referred to as a Kripke model, after Saul Kripke, one of the first mathematicians to give a model-theoretic interpretation of modal logic [Kri63a, Kri63h, Kri65]. The basic idea of Kripke semant ics is to relat ivize the truth of a statement to temporal stages or states. Accordingly, a statement is not simply true, but true at a particular state. ‘The states are temporally ordered, with the type of temporal order determined by the choice of axioms. For example, the sc)-called minimal tense logic, Kt, is defined by vau Benthem as follows [vB88, p. 7].

● Axioms:

● Rules of Inference:

1. 0,@ ~ ~~/4 (Modus Ponens) 2. if r#I is a theorem, then so are G@, If@ ((’Temporal) Generalization)

Various axioms may be added to Kt to characterize further assumptions on the temporal order, such as transitivity and antisymrnetry (which together yield a partial order), as well as density, linearity, and so forth. In the context of finite state methods, the notions of linear time and branching time are of particular interest.

‘ 7The term “dynamic logic” refers generically to logical systems used to reason about computer programs. The basic premise is that certain classical logical systems that are inherently “static” can be extendeci quite naturally to reason about ‘(dynamics.” In addition to its application to computational systems, the study of dynamic logic and related topics has more general philosophical and mathematical implications as a natural extension of modal logic to general dynamic situations [Har84]. 104 Chapter 6

Qz The set of states in an interpretation represents not only past states, but all accessible (possible) future states. Furthermore, truth is persistent. Intuitively, this means that a sentence true at a given state will always be true at later states. The following definitions are due to Burgess [Bur84, pp. 93-4]. A Kripke frame is composed of a nonempty set S, equipped with a binary relation R. A valuation in a frame (S, R) is a function, V, that assigns to each variable, pi, a subset of S, and each (syntactically well-formed) sentence a truth value. Intuitively, S represents the set of states and R represents the earlier-later relation. A formula, Q is valid in a frame (S, 1?) if V(a) = X for every valuation ~’ in (X, R). a is satisfiable in (X, R) if V(a) # 018 for some valuation V in (S, R), or, equivalently if -la is not valid in (S, R). In addition, a is valid over a class, K, of frames if it is valid in every (S, R) E K, and is satisfiable over K if it is satisfiable in some (S, R) c K or, equivalently, if ma is not valid over K. The interaction of universal and existential quantification with temporal operators is complex, introducing both philosophical and technical difhcult ies. Burgess [13ur84, p. 131] notes that the philosophical issues include “identity through changes, cent inuity, motion and change, reference to what no longer exists or does not exist, essence and many, many more” and the technical issues include “undecidability, nonaxiomatizability, undefinability or multidimensional operators, and so forth.” Thoughtful discussion of these issues can be found in [Gar84] and [COC84].

6.2.1.2 Linear Temporal Logic (LTL)

Linear time corresponds to the usual notion of time as a linearly ordered set, measured either with the real or the natural numbers. The temporal order relation < is total, that is, antisymmetric, transitive, and comparable. comparability means that for all states

S 1 and sz in the same execution sequence, either SI < sz or sz < sl or S1 = SZ). The extension of Kt obtained by adding the following two axioms (of right- and left-linearity, respectively) characterizes the linear temporal frames.

Alternatively, the following, somewhat more intuitive axioms can be used to characterize total orders [Bur84, p. 104].

180 denotes the empty set NAsA_ GB_ooj .97 105

Linear temporal logic is typically extended by two additional operators, the until operator and the since operator, abbreviated U and S, respectively.

z Q

The following definitions are based on a discussion in [hlcM93, p. 14] and assume that, all subscripted states, s.., are comparable. @ UI/~ is true in state Sj if there is some state Sk such that Sj < Sk and @ is true in sk, and for all Sz, such that sj < si < sk, ~ is true in state s~. Intuitively, @ holds at some time in the future, until which time @ holds. Similarly, qMI/J is true in state s~ just in case there is some state sk such that Sk < sj and @ is true in %, and for all sz, suc~l that sj < Si < Skt @ is true in state Si. Informally, @ held at some time in the past, since which time ~ has held.

6.2.1.3 Branching Time Temporal Logic

A treelike or branching fratne is one in which the temporal order defines a tree that branches toward the future. Treelike frames represent ways in which things can evolve nondeterministically; every moment, or state has a unique, linearly ordered past, hut an indeterminate future. Following Thomason [Tho84, p. 142], a t reelike frame for a tense logic consists of a pair (T, <), where T is a nonempty set and < is a transitive ordering on T such that if t] < t and tz < t, then either tl = t2 or tl < t2 or t2 < tl. The tree-ordered frames can be characterized by dropping the axiom

(PF~,) –+ (1’() v ~ v Fd) from the axioms of linear time logic. A branch through t 6 T is a maximal linearly ordered subset of T containing t.

The semantics for branching time temporal logic are somewhat problematic. As Thomason [Th084. p. 142] notes, interpreting future tense in these t reelike structures can be perplexing. For example, take a simple structure with three rncments, the root, to, and two branches labeled t] and t2, respectively. Assume @ true at to and tl and false at t2. Is F@ true at to? It is hard to say. The answer involves technical issues that revolve around the reconciliate ion of tense with indeterminism. The logical argument for determinism claims that it is not possible to provide a correct definition of satisfaction for these struct m-es, that is, to provide a definition that does not generate validities that are incompatible with the intended interpretation. Thomason [Tho84] presents 106 Chapter 6 an interesting discussion of strategies advanced by indeterminists to circumvent these claims.

The propositional branching time temporal logics that provide the foundation for one of the principal approaches to finite state verification of concurrent systems are called Computational Tree Logics. There are basically two variants: CTL and CTL*. The logic CTL* combines both branching-titne and linear-time operators. A (computational) path quantifier, either A or E, denoting all or some paths, respectively, can prefix assert ions composed of arbitrary combinations of the linear time operators G, F, U, and the “nextt ime” operator, X (see below). There are two types of formulas in CTL*: state formulas that are true in a given state and path formulas that hold along a given path. The following definitions are taken from [CGK89, pp. 83-84]. Let AF’ be the set of atomic proposition names. A state formula is either:

. A, if A E AP.

● If f and g are state formulas, then Vf and f V g are state formulas.

● If ~ is a path formula, then E(f) is a state formula.

A path formula is either:

● A state formula.

● If f and g are path formulas, then =f, f V 9, Xf and fUg are path formulas.

CTL*” is the set of formulas generated by the above rules. CTL is a restricted subset of CTL* that permits only branching-time operators. CTL is obtained by limiting the syntax for path formulas to the following rule.

● If f and g are state formulas, Xf and fUg are path formulas.

The following abbreviations are also used in writing CTL* and CTL formulas:

● jAgG1(7fV7g)

● A(f) - YE(-lf)

. F(f) - trueUf

● G(f) s -TF-lf NASA-GB-001-97 107

Q2’

The semantics of CTL* are defined with respect to a (finite Kripke) structure K = (117, R, L), where

● W is a set of states or worlds.

● R c W x W is the transition relation. R is total. WI ~ W2 indicates that (ul,, u)~) G R.

● L: W -+ P(AP) is a function that labels each state with a set of atomic proposi- tions true in that state.

Let .fl and ~z be state formulas, gl and gz be path formulas. A path in K is defined as a sequence of states 7r = too, wl, . . . such that for every i > 0, wi ~ wi+l. n~ denotes the sufiz of 7T starting at w~. K, w ~ ~ means that ~ holds at state w in structure K. Similarly, if g is a path formula, K, m ~ g means that g holds along path n in structure K. The relation 1= is inductively defined as follows.

● w + A IFF A G L(w).

● u) ~ -Tfl IFF it is not tile case that w ~ il.

● w + fl V fz IFF W + fl 0’7’ W) (== fz.

● w + E(gl ) IFF there exists a path 7r starting with w such that tr # 91.

● n ~ ~1 IFF w is the first state of m and w ~ .fI.

● m + ~gl IFF it is not the case that n ~ gl.

● n ~ g1Ug2 IFF there exists a k ~ O such that # \ g2 and for all O ~ j < k, 7rJ +gl. 108 Chapter .5

6.2.1.4 Fixed Points

A functiod is a function that maps functions to functions, that is, a function that takes functions as arguments and returns functions as values. A functional may be denoted by a lambda expression, kz.j, where z is a variable and ~ is a formula. The variable z is effectively a place holder. When the functional is applied to a parameter, p, p is substituted for all instances of x in j. 19 For example, if -T = k. (Z A y), then ~(true) = true A y = y. A functional ~ is monotonic if p c q -+ ~(p) C ~(g). The following definition and example are taken from a discussion in [McM93, p. 19]. A fixed point of a functional -y is any p such that ~(p) = p. For example, if ~ is defined as above, then x A y is a fixed point of T, since 7(x A y) = (Z A y) A y = z A g. A monotonic functional has a least fixed point and a greatest jized point, also referred to as extremal jized points. The least (greatest) fixed point was defined by Tarski [Tar55] as the intersection (union) of all the fixed points of the functional. The least and greatest fixed points of a functional Az..f are denoted /Lx.f and zm..f, respectively. Assumiug the functional is continuous, the extremal fixpoints can be characterized as the limit of a series defined by iterating the functional. z f? The following definitions are also taken from [h1cM93, p. 19]. A functional, -Y, is union-continuous (intersection-continuous) if the result of applying -Y to the union (intersection) of any nondecreasing infinite sequence of sets is equal to the result of taking the union (intersection) of ~ applied to each element of the sequence. Tarski showccl that if a functional is monotonic and union-continuous, the least fixed point of the functional is the union clf the sequence generated by iterating the functional starting with the initial value false, that is, for any such functional, -Y, the least fixed point is UZVZ (faZse). Similarly, the greatest fixed point of a monotonic, intersection-continuous functional, -y, is ni~i(i~2f~). Any monotonic fuuctioual is necessarily continuous (that is, union-continuous and iutersect ion-cent inuous) over a finite set of states [McM93, p. 19]. Fixed points of fuuc- tionals have been used to characterize CTL operators, resulting in E’ffiCkIlt algorithms for temporal logic model checking. The standard reference for fixed point characteriza- t ions of CTIJ formulas is [EI.86].

6.2.1.5 The Mu-Calculus

The mu-calculus is a logic based on extremal fixed points that is obtained by adding a recursion operator. p, to first-order predicate logic (FOL) or to propositional logic. — lgThe discussion a.ssurnes the usual restrictions on lambda-conversion that ensure that variables occurring free in p are not bound by operators or quantifiers in f. NASA-GB-001-97 109

In the context of FOL, the p operator can be viewed as an “alternative quantifier for relations” that replaces the standard quantifiers V and 3 on relations (but not on individuals) [Par76, p. 174], while in propositional logic, the p operator provides new n-ary connective. Kozen [Koz83] credits Scott and De !dakker [SB69] with originating the mu-calculus and Hitchcock and Park [H P73], Park [Par70], and De Bakker and De Roever [13R73] with initit ially developing the logic. Park [Par76, p. 173] notes that the mu-calculus was a natural response to the inability of first-or(ler predicate logic ‘(to express interesting assertions about programs“ in a reasonable way. The mu- calculus is “strictly intermediate” in expressive power between first- and second-order logics [Par76]. There are several different formulations of the mu-calculus. Some, like those of [BR73, HP73], present the calculus as a polyadic relational system that sup- presses individual variables and replaces existential quantification (3) on individuals wit h a composition operator on relations [Par76]. Others, like the version below reproduced from [McM93, pp. 114-115] and based on [Par76], retain the more traditional system of predicate logic. There are two kinds of mu-calculus formulas: relational formulas and Boolean formulas, and, correspondingly, two kinds of variables: relational variables (for example, the transition relation, R) and individual variables (for example, the state, Z). A model for the mu-calculus is a triple M = (S,@, #~), where S is a set of states, @ is the individual interpretation function that maps every individual variable to an element of S, and @ is the relational interpretation that maps every n-ary relational variable onto a subset of Sn. The syntax of Boolean formulas is defined as follows, where p and q are syntactic variables representing Boolean formulas, z is an individual variable, (z], . . . . ~n ) is a vector of individual variables, and R is an n-ary relational formula.

. true and false are Boolean formulas.

● p V q and Yp are Boolean formulas.

● %.p is a Boolean formula.

● R(zl, ...> Zn ) is a Boolean formula.

The formula 3x.p is true just in case there exists a state z in S such that p is true in x. Similarly, the formula R(z, y) is true just in case the pair (q5(z), ~(y)) is a member of V(R). The relational formulas are defined as follows, where, in addition to the definitions given above, F is an n-ary relational formula that is formally monotonic in R.

● Every n-ary relational variable R is an n-ary relational formula.

● A(zl, . . . , Xn ) .p is an n-ary relational formula. 110 Chapter 6

● llR.P and vR. F are relational fornlulas.20

In a given model (S, ~, ~~),

● The relational variable R is identified with the relation ~)(R).

● A(z] >... , Zr, ).p denotes the set of all n-tuples (X:l, . . . . Z,l) such that p is true.

● The formulas p R.F and vR. F stand for the least fixed point and greatest fixed point (of ~ = ~R.F), respectively.

6.2.2 A Brief History of Finite-State Methods

Finite-state methods grew out, of several independent developments in the mid to late 1970s, including early work on temporal logic and early activity in protocol specification and verification. Pnueli first proposed the use of temporal logic to reason about concurrent and reactive programs [Pnu77]. Formalization of safety properties for concurrent systems followed shortly thereafter. Pnueli’s early proofs were largely manual, as were the initial techniques used to verify protocols. The realization that many concurrent programs can be viewed as communicating finite-state machines combined with results in reachability analysis and the realization of their applicability to protocol analysis soon led to techniques for automatic verification of correctness properties. 21 The first such techniques arose in the context of protocol validation [BWHJ78,Haj78, WZ78, R1380]. Shortly thereafter, in the early 1980s, Holzmann built a general protocol verifier based on reachability analysis [H0181], Sifakis and his students at Grenoble Uni- versity in lhance began work on the French validation system Cesar [Que82, QS82], and Clarke and his students at Carnegie Mellon University (CMU) independently developed the Extended Model Checker (EMC) system [CE81, CES86]. Both Cesar and EMC used algorithms for the braIIChillg-tiIlle logic CTL. The CMU system also incorporated slight modifications to CTL to accommodate fairness constraints [B Ch!l+ 90]. Holzmanrr’s initial protocol verifier was based on a simple process algebra, but his subsecprent systems use standard automata theory. In all three cases, this early work led to currently in~- portant systems: Holzmann’s work culminated in SPIN, the Grenoble eflort produced Cesar and several specialized variants, and CMU’S EMC evolved into SMV. Research in model checking for verifying lletwork protocols and sequential circuits quickly led to the realization that application of model checking techniques to nontrivial systems required viable approaches to the so-called state explosion problem. The term refers to the fact that in the worst case, the number of states in the global state graph for a system with N processes may grow exponentially with AT. There has been a great

—20 v may be defined in terms of p (vR.1’ = =p12. =F) or specified as a (primitive) fixpoint operator as shown here. 21 Initially, safety properties. Liveness and fairness followed later. NASA-GB-O01-97 111 deal of work on the computational complexity of model checking algorithms, as well as on techniques to address the state explosion problem. One of the earliest and most important techniques for CTL-based model checking systems is a symbolic, rather than an explicit, representation of the state space. That is, the set of states is represented by a logical formula that is satisfied in a given state if and only if the state is a member of the set, rather than by a labeled global state graph. Similarly significant benefits for LTL-based model checking have been obtained with partial order techniques [God90, Va190, Pe193, GPS96]. For certain applications, both techniques can reduce exponential growth of the state space to linear or sublinear growth [HoI].

To provide further economies for CTL-based model checking, symbolic representations capable of exploiting structural regularities and thereby avoiding explicit construc- t ion of the state graphs of modeled systems have been sought. The representat ion that is currently most widely used is a canonical, but highly compact form for Boolean formulas known as ordered binary decision diagrams or OBDDS [Bry86].22 An OBDD is similar to a binary decision tree, except that its structure is a directed acyclic graph rather than a tree and a strict order governs the occurrence of variables. Bryant [Elry86] has shown that there is a unique minimal 013DD for a given formula under a given variable ordering. Variable ordering is thus critical for determining the size of the minimal OBDD for a given formula. Although the use of symbolic representation allows significantly larger systems to be modeled, the state explosion problem persists as a computational barrier restricting the size and complexity of systems that can be verified using finite state methods.

Other strategies have been and continue to be proposed to address this problem. These include exploiting structural symmetries in the systems to be verified [CFJ93, ES93, ID93], using hierarchical [MC85] and compositional [CLM89, GS90] techniques, applying abstraction methods [CGL92, Kur94], and employing on-the-fly intersection tec}miques [H0184, CV WY92, FMJJ92]. For LTL-based model checking, efFicient on-the-fly techniques have been a significant development because on-the-fly verification algorithms require only that part of the graph structure necessary to prove or disprove a given property, rather than the entire Kripke structure (for example, as required by fixpoint algorithms). Compositionality and abstraction exemplify a “divide- and-conquer” strategy that attempts to reduce the verification problem to a series of potentially more manageable subproblems [God96, p. 17], whereas partial order and on-the-fly methods attempt to reduce the size of the checked state space and the extent of the search, respectively. Some of these techniques may be usefully combined. Par- tial order and on-the-fly methods are a good example, as noted in [Pe194]. Others are complementary. Compositional and abstraction methods, for example, are essentially orthogonal – and thereby complementary to - partial order techniques [God96, p. 17].

220BBD is sometimes written simply as BL)D, although as McMillan notes [Mch193, p. 32], the variable ordering (which is crucial to obtaining the canonical reduced form) is what distinguishes OBDI)S from the more general class of BI)Ds. 112 Chapter 6

6.2.3 Approaches to Finite-State Verification

As noted earlier, finite-state verification techniques emerged in the late 1970s and early 1980s from two independent developments: temporal logic model checking [C1381 ,Que82] and protocol analysis [Haj78, Wes78]. Subsequent developments can be classified with respect to several dimensions, reflecting factors such as representation strategy, type of algorithm, and class of system addressed. The distinctions made by representation strategy are broad and therefore well-suited tothe general discussion offered here. Representation strategy distinguishes approaches that useafinite state representation for the system modeland a logical calculus for thespecificatioll- the symbolic model checking approach, from techniques that use finite state machines to represent both thesysteln lnodelatld thespecificatioll----the auto1nata-theoretic approach. In practice, verification systems for asynchronous systems (software) are largely automata-based, ‘ exploit on-the-fly techniques, and support LTL, while systems for synchronous systems (hardware) are based either on fixpoint algorithmso rsymbolicmethods, and support CTL, CTL*, or propositional mu-calculus [Hoi].

6.2.3.1 The Symbolic Model Checking Approach

In the symbolic model checking approach, verification means determining whether a given logic formula ~ is valid in a given Kripke model M, that is, determining which states S in a finite Kripke structure M = (S, R, L) satisfy j. Initially, the temporal logics CTL, CTL*, and I,TI, were used. Later algorithms typically characterize the CTL (LTL) operators (or more precisely, the interpretation of CTL (LTL) operators in a Kripke model) in the Mu-calculus, a logic of extrernal fixed points that has been shown to be strictly more expressive than CTL [EL85] .23 The Mu-calculus is attractive because it can be used to express a variety of properties oft ransition systems and provides a general framework for describing model checking algorithms. A model checking algorithm for the Mu-calculus taken from [BCM+ 90, p. 7] is presented in Figure 6.1. Verification systems that perform temporal logic model checking are generally referred to as model checkers, reflecting the fact that the basic function of these systems is to decide whether a given finite model (that is, a Kripke model) satisfies a formula in a given logic. Models are expressed in suitable languages, and assertions about the model are specified in a different language, typically a temporal logic. In the context of model checking, a suitable language is a reasonably expressive, high-level language, with a precise mathematical semantics that defines its translation to Boolean formulas (OB- DDs) or other forms suitable for symbolic model checking.24 There are several varieties of model checkers, the most common being I,TL model checkers that verify linear-time .— 23A ‘language L’ is strictly more expressive than a language L if there are formukrs that can be expressed in L’ but not in L, and all formulas expressable in L are also expressable in L’. 24 Althou@ BDDs are still the ~,ost ~idelY used symbolic repreSeUtatiCM for finite state ~’erificatiO1l) other representations have been used instead of or in addition to BDDs. For example, LUSTRE is a synchronous dataflow language stylistically similar to the ShlV language. Verirnag’s POLKA system IVASA-GB-001-97 113

— — — function Bdd.f(f: formula, I_p: rel-interp) : BDD; case f: an individual variable return Bdd_Atom(f); f: of the form fl AND f2 return Bdd_And(Bdd_f(fl, I_p), Bdd_f(f2, I_p)); f: of the form NOT fi return Bdd_Negate(Bdd_f(fl, I_p)); f: of the form EXISTS x [fl] return Bdd_Exists(x, Bdd_f(f, I-p); f: of the form Z(xl, . . ..xn) return Bdd_R(Z, I_p)(dl <- xl). ..(dn <- xn); end case;

function Bdd_R(R: rel-term, I_p: rel-interp) : BDD; case R: a relational variable return I_p(R); R: of the form LAMBDA xl, . . ..xn [f] return Bdd_f(f, I_p)(xl <- all). ..(xn <- dn); R: of the form MU Z [RI] return FixedPoint(Z, RI, I_p, FalseBdd); end case;

function FixedPoint(Z: rel-var, R: rel-term, I_p: rel-interp, T_i: BDD) : BDD; let T_i+l = Bdd_R, R-p(Z <- T_i); if T_i+l = T_i return T_i else return FixedPoint(Z, R,—— I_p, T_i+l);

Figure 6.1: Burchet cd.’s Mu-Calculus ModeI Checking AIgorithnl. properties of finite Kripken~odels, and CTLrnodel checkers that verify branching-time properties of finite Kripke models. Forexample, the SMVsystem[McM93, CMCHG96], one ofseveral CMU systemsto evolve from EMC, uses asynchronous dataflow language (also called SMV) with high- level operations and nondeterrninistic choice. The transition behavior ofan SMVpro- gram, including its initial state(s) , is determined by a collection of parallel assignments,

~oneofseveral systems toevolvefrom Cesar) isusedto verify LUSTRE[HCRP91, HLR92, HFB93] programs with integer variables. POLKA uses convex polyhedra to represent linear constraints. Re- cently, a new data structure named Queue-content Decision Diagram (QDD) has been introduced for representing (possibly infinite) sets of queue-contents. QDDs have been used to verify properties of col~~n~unication protocols nlodeled by finite-state ~nachines that useunbounded first in, first out (FIFO) queues to exchange messages [BG96]. QDDshawal sobeen used incombination with BDDs to improve the efficiency of (BDD-based) symbolic model-checking techniques [G L96]. 114 Chapter 6 possibly involving a unit of delay. Asynchronous systems may be modeled by introducing processes that have arbitrary delay. The SMV language supports modular hierarchical descriptions, reuse of components, and parametrization [CMCHG96, p. 420]. An SMV program consists of a Kripke model and a CTL specification. The state of the model is defined as the collection of the program’s state variables, and its transition behavior is determined by the collective effect of the parallel assignment statements. Variables arc restricted to finite types, including Boolean, integer subrange, and enumerated types. The ShflV program in Figure 6.2 for a very simple protocol illustrates the basic idea. The example is from McMillan [Mch193]. .—— ———. ——— — ————— .—. —. —.... MODULE main VAR request: boolean; state: {ready ,busy}; ASSIGN init(state) := ready; next(state) := case state = ready & request : busy; 1 : {ready ,busy}; esac; SPEC AG(request -> AF state = busy) 1— _—— — —.— —.—.———

Figure 6.2: A Simple SMV Program [hlch193, p. 63].

Values are chosen nondeterministically for variables that are not assigned a value or whose assigned value is a set. For example, the variable request is not assigned in the program, but chosen nondeterministically by the SMV system. Similarly, the value of the variable state in the next state is chosen nondcterministically from the values in the set {ready, busy}. 25 The specification states that invariant Iy, if reque st is true, then the value of state is busy. An SMV program typically consists of reusable modules. ShIV processes (not illustrated here) are module instances introduced by the keyword process. Safety and livencss properties are expressed as CTL specifications. Fairness is specified by means of fairness constraints that restrict the model checker to execution paths along which a given CTL formula is true infinitely often.

6.2.3.2 The Automata-Theoretic Approach

In the automata-theoretic approach, verification means comparing the externally visible behaviors of the finite state machine representing a system model with the finite state — 251,ik~ ~niIlter~reted tY~es, nondeterminisnl can be useful for describing SyStems abstractly (~~rhere values of certain variables are not determined) or at levels that leave design choices open (to the implementor). ivAsA-GB-ool-97 115 machine representing its specification. ‘The method of comparison varies, depending on the technique and the particular class of system for which it was developed.

6.2.3.2.1 Language Containment In the language intersection approach first described by [VlfT86], verification consists of testing inclusion between two w-automata, where one automaton represents the system that is being verified and the other represents its specification or task. Inclusion denotes the strict subset relation between the languages of the two automata. For a process F’ modeling a system to be verified and a task T that P is intended to perform, verification consists of the test L(P) C L(T), where L(P) denotes the set of all “behaviors” of the modeled system and L(T) denotes the set of all “behaviors” consistent with the performance of the modeled task or specification. Typically, F’ is a system of coordinat iug processes modeled by the product process I’ = @F’z, where each Pi is an u-automaton .26 This semantic model accommodates specific reduction algorithms that provide one response to the computational complexity problems associated with more general model checking. The basic idea is to replace a computationally expensive test L(P) c L(T) with a computationally cheaper test L(F”) c L(T’), such that .C(P’) c .C(T’) =+ L(P) C L(T). P’ and 2“ are derived from P and T, respectively, by homomorphisms on the underlying Boolean algebra.27 The reduction of P is relative to T, that is, relative to a given task or specification; each task induces a different reduction. Kurshan [Kur94] develops the theory underlying such reductions. The verification system typically associated with the language-inclusion approach is COSPAhT (Coordination Specification Analyzer) 2$. COSPAN’S native language is S/R, a data-flow language based on the selection/resolution model of coordinating processes. S/R distinguishes state variables from combinational variables, the latter being dependent variables whose values are functions or relations of the state variables. The S/R language provides nondeterministic, conditional (“if-then-else” ) variable assignments; bounded integer, enumeration, 13001ean, array, record, and (array and record) ——. ‘26 For ~urpose~ of this dis~u~~i~n, the distinction between finite State machines or generators (of behavior) and finite state automata or acceptors (of behavior) has been glossed over. The former is most convenient for modeling a system and the later for modeling its properties. Interested readers should see [VW86] or [Tho90]. 27A Boolean algebra is a set closed under the Boolean operations A, V, ~. A homomorphism is a mapping (function) from one algebraic structure to another that is defined in terms of the algebraic operations on the two structures. In the case of two Boolean algebras, B and B’, a map # is a homomorphism just in case @(2 A y) == @(x) A @(y) @(z v y) = ~(x) v #J(y) @(nr) == -@(r)

2SCOSPAN is also used as the “verification engine” in the commercial hardware verification tool FormalCheck, a trademark of the Bell Labs Design Automation center [HHK96]. 116 Chapter 6 pointer types; and integer and bit-vector arithtnetic. S/R also supports modular hi- erarchal development, scoping, parallel and sequential execution, hOInOInOrphiSrn declaration, general u-automaton fairness (acceptance), and (ti-regular) property specification [HHK96, p. 425]. COSPAN provides both symbolic- (that is, 13 DD-based) and explicit-state enumeration algorithms.

6.2.3.2.2 State Exploration The terms “state exploration” and “reachability analysis” refer to finite-state verification techniques that begin with an initial state and explicitly enumerate or construct the reachabIe state space of a system model, typica]ly using standard search algorithlns-- -such as depth-first or breadth-first search-- that have been optimized to alleviate state-space explosion. The state exploration approach contrasts with BDD- based techniques, which use a symbolic (implicit) representation of the state space. Sms [HP96] and Mur@ [Di196] exemplify this approach. Both verifiers use an asynchronous, inter-leaving model of execution in which atomic operations from a collection of processes execute in an arbitrary order.

SPIN. SPIN is automata-based and has full LTL model-checking capability. Each process of the model is translated into a finite automaton. Properties to be checked are represented as Btichi automata that correspond to a never claim, so-called because these claims formalize behavior that should never occur. In other words, never-claims correspond to violations of given correctness properties. A model is checked against its required properties by calculating the intersection of the property automaton and the process automata. A nonempty intersection indicates a possible correctness property violation. SPriN uses a verification procedure based on reachability analysis of a model by means of optimized graph traversal algorithms. This approach is also referred to as state exploration.

The SPIN model checker uses a nondeterministic, guarded command language called PROMELA that was developed to specify and validate protocols by modeling process interaction and coordination. PItOM~LA provides variables and general control-flow structures in the tradition of Dijkstra’s guarded command language [Dij76] and Hoare’s language CSP [Hoa85]. Correctness criteria are formalized in PROMELA in terms of assertions that capture both local assertions and global system invariants, labels that can be used to define frequently used correctness claims for both terminating and cyclic sequences (for example, cleadlock, bad cycles, and liveness (acceptance and progress) properties), and general temporal claims that define temporal orderings of properties of states expressed either as never-claims or as LTL formulas (that SPIN translates into PROMELA never-claims) [Ho191, HP96]. SPIN uses depth-first search and a single-pass, on-the-fly verification algorithm cou- pled with partial order reduction techniques to reduce the state explosion problem. On-the-fly algorithms attempt to minimize the amount of stored information, computing the intersection of the process and property automata only to the point necessary NASA -GB-001-97 117 to establish the nonemptiness of the resulting (composite) automaton. Partial order reduction algorithms exploit the observation that the order in which concurrent or independently executed events are interleaved typically has no impact on the checked property. It follows that instead of generating all execution sequences, it is sufficient to generate a reduced state space composed of representatives for classes of sequences that are not distinguishable with respect to execution order. ‘The reduction must be shown to preserve safety and liveness properties, but this is accomplished in the course of the verification. Mur@ The name “Mur@’ refers both to a verifier developed to analyze finite-state concurrent systems such as protocols and memory models for multiprocessors, and to its language. The Mur@ description language is a guarded-command language based on a Unity-like formalism [CM88] that includes user-defined datatypes, procedures, and parametrized descriptions. A Mur@ description consists of a collection of constant and type declarations, variable declarations, transition rules (guarded commands), start states, and invariants. Predefine data types include subranges, records, and arrays. Mur@ statement types include assignment, condition, case selection, repetition (for- and while-loops), and procedure calls. Mur@ rules consist of a condition and an action. A condition is a Boolean expression on the global variables, and an action is an arbitrarily complex statement. Each rule is executed atomically, that is, without interference from other rules. Correctness requirements are defined in Mur@ in terms of invariants written as predicates or conditions on the state variables. Invariants are equivalent to error statements, which may also be used to detect and report an error, that is, the existence of a sequence of states beginning in a start state and terminating in a state in which a given invariant fails to hold. in addition to invariant violations, error statements, and assertion violations, Mur@ can check for deadlock and, in certain versions, liveness properties. Mur~ uses standard breadth- or depth-first search algorithms to systematically generate all reachable states, where a state is defined as the current values of the global variables. State reduction techniques, including symmetry reduction, reversible rules, replicated component abstraction, and probabilistic algorithms are exploited to alleviate state explosion [Di196]. Symmetry reduction uses structural symmetries (in the modeled system) to partition the state space into equivalence classes, thereby significantly reducing the number of states generated in applications such as certain types of cache coherence protocols [I D93]. Reversible rules are rules that preserve information and can tlierefore be executed “backwards,” yielding an optimizaticm that avoids storing transient states [I D96a]. Systems with identical replicated components can be analyzed using explicit state enumeration in an abstract state space in which the exact number of replicated components is treated qualitatively (for example, zero, one, or more than one replicated components) rather than quantitatively (the exact number of replicated components) [I D96b]. The combination of symmetry reduction, reversible rule exploitation, and replicated component abstraction has been reported to yield mas- sive reductions in the state explosion problem for cache coherence protocols and sitnilar 118 Chapter 6 applications [Di196, p. 392]. Probabilistic verification algorithms are being explored as a way of reducing the number of bits in the hash table entry for each state [SD96].

6.2.3.2.3 Bisimulation Equivalence and Prebisimulation Preorders

Bisimulation equivalence provides a logical characterization of when two systems are equivalent and is used to check statewise isomorphism between two finite Kripke models. Prebisinmlation preorders similarly provide a logical characterization of when one system minimally satisfies another. Informally, this means that bisimulation provides a notion of behavioral equivalence: two systems are equivalent if they exhibit the same behavior, whereas prebisimulation provides a notion of behavioral relatedness: one system exhibits at least certain behaviors exhibited or required by the other. In both cases, a more abstract or higher-level system serves as a specification of a lower-level one. Verification consists c~f showing that the lower-level model or ‘(itnplementation” satisfies its specification by establishing the given relation between the two models. For example, the correctness of a protocol can be established by showing that it is semantically equivalent to its service specification by modeling both the protocol and its specification as finite state machines and using equivalence-checking verification to establish the statewise, transition-preserving correspondence between the two finite-state models. Various formal relationships have been proposed. In general, these relations are either equivalences (bisimulations) or preorders (prebisimulations) [CH89].

Milner’s Calculus of Communicating Systems (CCS29 ) [MiU19] forms the basis for several of the “most visible equivalence-checking verifiers for concurrent systems. Pro- cesses are defined as CCS agents that are given an operational semantics deflncd in terms of transition relations. CCS processes may define an arbitrary number of subpro- cesses, in which case the transition graph may have infinitely many states. Although some properties may be decidable in such cases, most interesting properties are undecidable on agents that correspond to graphs with infinite state spaces. Automated tools for analyzing networks of finite-state processes defined in CCS include the NCSU Con- currency Workbench [CS96] and its predecessor, the (Edinburgh) Concurrency Work- bench [CPS93], and the Concurrency Factory [CLSS96]. Both versions of the Concur- rency Workbench support equivalence checking, preorder checking, and model checking (for the modal mu-calculus). The NCSU Concurrency Workbench also provides diag- nostic information if two systems fail to be related by either semantic equivalence of preorder, and language flexibility that allows the user to change the system description language [C S96]. The Concurrency Factory is also an integrated toolset, but focuses on practical support for formal design analysis of real-time current systems. This is achieved in part through a graphical design language (G CCS), a graphical editor, and a graphical simulator [CLSS96]. In addition to a CCS-based semantics, GCCS has a structural operational semantics [CLSS96, p. 400].

29CCS and related approaches are also referred to M process algebras. NASA-GB-001-97 119

6.2.4 Utility of Finite-State Methods

The various approaches to finite-state verification outlined earlier are in theory very sin~- ilar and in many cases itker-definable, as noted in [VW86, CGK89, CBK90]. In practice, the approaches have led to the development of tools with often overlapping capabilities, but different foci and strategies. For example, SPIN has been developed for modeling distributed software using an asynchronous process model; Mur@ and SMV have focused on hardware verification Murq5 on asynchronous concurrent systems using explicit state exploration and SMV on both synchronous and asynchronous systems using symbolic model checking; and COSPAIl has been driven by a top-down design methodology inl- plemented through successive refinement of (fundamentally) synchronous models and has beclL used for both software and hardware design verification. In some cases, the capabilities are complementary, and there is work on integrating different finite-state verification strategies as done in COSPAN, which offers either symbolic- (BDD-based) or explicit state enumeratioli algorithms, as well as on integrating different approaches in a single tool, as done in both versions of the Concurrency Workbench, which offer equivalence checking, preorder checking, and model checking. Finite-state methods offer powerful, automated procedures for checking temporal properties of finite-state and certain infinite-state systems (Kripke models). ‘1’hey also have the ability to generate cozmterezarnphx—ty pically in the form of a computation path that establishes, for example, the failure of a property to hold in all states, and witnesses--in the form of a computation path that establishes the existence of one or more states in which a property is satisfied. Finite-state methods are least effective on large, unbounded state spaces, high-level specifications, and data-oriented applications---areas in which deductive methods are more appropriate. For this rea- S011, there has been increasing interest in integrating finite-state methods and deductive theorem proving. This topic is revisited in Section 6.4.

6.3 Direct Execution, Simulation, and Animation

Direct execution, simulation, and animation are techniques used to observe the behavior of a model of a system. Formal analysis, on the other hand, is used to analyze modeled behavior and properties. In many cases, there are fundamental differences between these observational and analytical methods, including the models they use and their expected performance. Typically, models used for verification cannot expose their own inaccuracy and, conversely, models used for conventional simulation cannot con- firm their own correctness [Lan96, p. 309]. Models used for simulation of large systems must be able to handle realistic test suites fast, since these suites may literally run for weeks. This kind of efficiency is not a reasonable expectation in executable specification languages. Formal verification techniques generally treat the notion of time as an abstraction and largely avoid probabilities, whereas more concrete representations of 120 Chapter 6 time and probabilistic analyses play an important role in observational methods. Fi- nally, direct execution, simulation, and animation show behavior over a finite number of cases, whereas formal analysis can be used to explore all possibilities, the former offering statistical certainty and the latter, mathematical certainty. Although some of these differences are attenuated when “simulation” is considered in the context of formal specification languages (for example, the models used for execution and simulation typically coincide), others persist (for example, verification still proceeds by extrapola- tion from a finite number of cases, rather than by mathematical argumentation over all possible cases). The remainder of this section summarizes the notions of executability, simulation, and animation in the context of formal methods.30

6.3.1 Observational Techniques

Some formal specification languages are directly executable, or contain a directly executable subset, meaning that the specification itself can be executed or run and its behavior observed directly. For example, a logic based on recursive functions, such as that, used in Nqthrn [BM88] and ACL2 [Kh!194], supports direct execution and “sinm- lation” on concrete test cases because it is always possible to compute the value of a variable-free term or formula in the executable subset of these logics. The following quote from [KM94, p. 8] describes the role of executability in the formalization of a model of a digital circuit (the FM9001 ) in Nqthm.

[The Nqthm model] can be thought of as a logic sitnulator (without, however, the graphic and debugging facilities of commercial simulators). . . . Running [the model] on a concrete netlist31 and data involves simulating in the proper sequence the input/output behavior of every logical gate in the design . . .

The spccificat ion language for the Vienna Development Method (VDM), VDM-SL, also has a large executable subset, as well as tool support for dynamically checking type invariants and pre and I)ost conditions, and for running test suites against a VDM- SL specification [VDM]. Similarly, the concrete representation of algorithms and data structures required by most finite-state enumeration and model-checking methods (see Section 6.2) make them ccmlparakde to direct execution techniques. Certain finite state verification tools also provide ‘(simulation,” by exploring a single path through the state space rather than all possible paths [H0191, DDHY92, ID93].

30 Planning and administrative trade-offs involving, for example, cost, available resources, criticality of the system, and desired levels of formality, are discussed in the first volume of the guidebook [hTASA- 95a]. 31 The ,!netli~t,~. i$ .aIL ~qth[ll constallt that describes a tree of hardware nloduleS and their intercon- nections via named input/output lines. ArAsA.~~_ool.97 121

The dynamic behavior of specifications written in nonexecutablc languages may be studied indirect ly, by reinterpreting the specification in a (high-level) programming language. Execution of the resulting program is referred to as an emulation or animation of the specification. Some formal specification languages offer both a directly executable subset and the option of user- or system-defined program text to drive animation of nonexecutable parts of the specification. Specifications written in a nonexecutable language using a constructive functional st~rle may be “executed” by exploiting a rewrite facility (assuming one is available) to rewrite function definitions, starting from a particular set of arguments. This amounts to writing an emulator for the system being modeled and may not he either possible or desirable. For example, making an entire specification executable typically precludes using axioms to dispense with those parts of a system or its environment that are not of interest or do not warrant verification.

Direct execution, simulation, and animation are not alternatives to more rigorous formal analysis, but rather effective complements. For example, during the requirements and (or) high-level design phase, executability can be used to probe the behavior of a system on selected test cases, and deductive theorem proving can be usecl to exhaustively establish its general high-level properties. in this type of strategy, executability provides an efficient way to avoid premature proof efforts and, conversely, to focus the more rigorous (and thereby more expensive) proof techniques on the most appropriate behaviors and properties. This symbiotic use of different techniques is nicely illustrated in the development of a formal specification of the Synergy File System using ACL2 [BC95a]. In this application, formalization of an ACL2 executable model, execution of the model, and proof of an invariant about transitions in the model each revealed significant errors.

6.3.2 Utility of Observational Techniques

The main advantages of executability are that it allows the specification and underlying model to be “debugged, ” and it allows the specification to serve as a- “test oracle” relatively early in the life cycle. Animation and emulation confer similar benefits. A further advantage of executability is that it allows behavior to be observed and explored in the same formally rigorous context as that in which the specification is developed. Other documented roles for executability include post-implementation testing, as illustrated, for example, in post-fabrication execution of the FM9001 specification to test the fabricated devices for conformance to the (verified) design [KM94, p. 9]. Although this example represents a somewhat novel use of executability, it is potentially an important technique by means of which formal methods can make a unique contribution to conventional testing regimes. The technology transfer potential of executability, animation, and emulation is also worth noting. Because simulation, animation, and enl- ulation are techniques familiar to analysts and engineers, they offer an effective vehicle for integrating formal methods into ongoing system development activities. The VDM- S1, study carried out at British Aerospace provides an interesting example of the role 122 Chapter 6 of executability in the integration of formal specification in a traditional development process [LFE196].

6.4 Integrating Automated Analysis Methods

No single technique is effective across a wide range of applications or even across a single application with disparate components or algorithms. Industrial-strength examples typically require a variety of approaches, currently used as standalone systems, as illustrated, for example, in [M PJ94]. Rushby [Rus96] argues that effective deductive support for formal methods requires not standalone, but integrated techniques effective across a broad range of applications. Shankar [Sha96] makes a similar argument, noting that the “sheer scale” of mathematics necessary for formal methods argues for a unification of verification techniques. The three analysis techniques surveyed in this chapter- automated deductive nlethods, finite-state methods, and simulation methods- have complementary strengths and there is increasing interest in the synergistic integration of these techniques within a uniform framework. Synergistic integration simply means that the resulting system should be more than the sum of its parts. Logical frameworks, such as Isabelle [Pau88], support the definition and construction of deductive tools for specialized logics, but do not provide systematic support for coherent integration of different capabilities [Sha96]. The Stanford TEmporal Prover (STEP) [Man94], which integrates model checking with algorithmic deductive methods (decision procedures) and interactive deductive nmthods (theorem proving) to support verification of reactive systems, is an example of one strategy in the search for effective integration. The STEP system is interestillg because it also combines powerful algorithmic and heuristic techniques to automatically generate invariants. A different approach has been used to integrate model checking and automated proof checking in PVS [RSS95], where a BDD-based model checker for the propositional mu-calculus is integrated as an additional decision procedure within the proof checker. The notion of integrated verification techniques introduced here provides a glimpse of the direction verification technology is heading. One implication of this discussion is the relative maturity of existing formal methods techniques, which offk!r effective specification and analysis options for aerospace applications.

6.5 Proof of Selected SAFER Property

The property that no more than four thrusters may be fired simultaneously follows directly from the detailed functional requirements of the SAFER system. Thruster selection is a function of the integrated hand grip and A AH-generated commands. The thruster select logic specified in Tables C.2 and C.3 is used to choose appropriate thrusters based on a given integrated command. An initial survey of these tables NASA- GI?-001-97 123 might suggest that as many as four thrusters can be selected from each table, resulting in as many as eight thrusters chosen in all. However, several additional constraints render certain command combinations invalid. Furthermore, the table entries thenlselves are interrelated in ways that limit the thruster count for multiple commands. The four-thruster maximum follows directly from the combination of these two types of constraint.

The four-thruster max property is fundamental and is explicitly captured as Re- quirement 41, one of the avionics software requirements (see Sections 3.3 and C.2):

41. The avionics software shall provide accelerations with a maximum of four sinlul- taneous thruster firing commands.

The four-thruster max property can be expressed as a PVS theorem as shown here.

max.thrusters: THEOREM I FORALL (a. in: avionlcs_inputs), (a_st: avionics-state): I 1-————length(prop_actuators—— (output(SAFER_control (a_in, a_st)))) <= 4 I

The theorem asserts that for any input and state values, the outputs producedby the SAFER controller, which include the list of thrusters to fire in the current frame, obey the maximum thruster requirement. This claim applies to any output that canbe generated by the model.

6.5.1 The PVS Theory SAFER.properties

Proof of themax_thrusters theorem requires several supportillg lenlrnas. These lemmas and the theorem itself are packaged as the PVS theory SAFER_propert ies, which is reproduced here. 124 Chapte~- 6’

———— SAFER_ properties: THEORY BEGIN

IMPORTING avionics.model

A,B,C: VAR axis_comnland tr: VAR tran_command HCM,cmd: VAR six”_dof_command AAH : VAR rot_command state: VAR AAH_state thr,U,V: VAR thruster..list act: VAR actuator-commands BF,LRUD: VAR thruster_list_pair

%% Only one translation command can be accepted for thruster selection.

only_one_tran(tr): bool = (tr(X) /= ZERO IMPLIES tr(Y) = ZERO AND tr(Z) = ZERO) AND (tr(Y) /= ZERO IMPLIES tr(Z) = ZERO)

only_one_tran_pri: LEMMA only_one_tran(prioritized_tran_cmd(tr))

only_one_tran_int: LEMMA only_one_tran(tran(integrated_commands(HCM, AAH, state)))

%% All categories of selected thrusters (BF vs. LRUD and mandatory %% vs. optional) are bounded in size by two, which follows directly %% from inspection of the tables.

max_thrusters_BF: LEMMA length(proj_l (BF_thrusters(A, B, C))) <= 2 AND length(proj_2(BF_thrusters (A, B, C))) <= 2

max_thrusters_LRUD: LEMMA length(proj_l (LRUD_thrusters(A, B, C))) <= 2 AND length(proj_2(LRUD.thrusters(A, B, C))) <= 2 —— .—.—..—.— — ————.— .—— .—-— .——————.. AJASA-GB-001-97 125

—- .———— ————————-——— — YL Absence of translation commands implies no optional thrusters %% will be selected.

no.opt_thr_BF: LEMMA tr(X) = ZERO IMPLIES length(proj_2(BF_thrusters(tr(X) , B, C))) = O

no_opt_thr_LRUD: LEMMA tr(Y) = ZERO AND tr(Z) = ZERO IMPLIES length(proj_2(LRUD_thrusters(tr(Y) , tr(Z), C))) = O

%% Top level theorems establishing bounds on number of selected thrusters:

max_thrusters_sel: LEMMA only_one_trarI(tran(cmd) ) IMPLIES length(selected_thrusters(cmd) ) <= 4

max_thrusters: THEOREM FORALL (a_in: avionics_inputs), (a_st: avionics-state): length(prop_actuators (output(SAFER_control(a_in, a_st)))) <= 4

END SAFER_properties —— ——..

TheSAFER-properties theory depends on other theories iutheSAFE Rspecifica- tiou, as shown inthe graphof the dependency hierarchyin Figure 6.3. Onlythedepen- dencyon the theory avionics-model is explicitly represented (iuthe IMPORTING clause in SAFER_properties). The remaining dependency chains are established through sinl- ilar clauses in the other theories. The lemmas in SAFER_properties differ iu import. Some are used to decompose the proof. Others express general properties of the prob]em domain that are likely to be useful in the proof of additional SAFER properties as well as in the proofof max-thrusters. Annotations (indicated by the PVS comment character %) indicate whether the lemma represents an intermediate proof step or a general property. The mechanically assisted proof of the SAFER_properties theory consists of a proof of the top-level theorem, max-thrusters, whose proof follows from the Iemmass max-thrusters_sel and only-one-tran_int. Each of these lemmas is, in turn, proved in terms ofother lemmas from this theory. ThePVS theorem prover employs a sequent calculus similar to that sketched in Section 6.1.3.l.2, but mechanized at a considerably higher level than that reflected in the proof hlSection6.1.3.3. Section C.4.2.2 showsa transcript from the proofof theorem max_thrusters. The proofcontains only five steps in the PVS theorem prover. Proofs of the remaining lemruas are similarly straightforward and require only a few steps. The single exception is max-thrusters_sel, whose proof iuvolvesa case analysis. 126 Chapter 6

6.5.2 Informal Argument for Lemma max.thrusters.sel

Consider, first, an informal argument for the max thrust ers-sel lemma. At most two mandatory and two optional thrusters can be selected from each of the two thruster tables. The argument proceeds by cases defined in terms of possible commands. The first case concerns a translation command for the X axis.

● Case 1: No X command present. Inspection of Table C.2 shows that there will be no optional thrusters selected in this case. There are two subcases, depending on the presence of a pitch or yaw command.

o Case 1.1: No pitch or yaw commands. Inspection of Table C.2 shows that no thrusters at all are selected in this case. At most four can come from ‘ Table C.3. Hence, the max thruster property holds. o Case 1.2: Pitch or yaw command present. Inspection of Table C.3 indicates that no optional thrusters are chosen from this table. Hence, only mandatory thrusters from each table are chosen, and, again, the number selected cannot exceed 4.

● Case 2: X command present. Because only one translation command is allowed, it follows that no Y or Z command can appear. This, in turn, implies that no optional thrusters are chosen from Table C.3. The subcases take into account the possibility of a roll command.

o Case 2.1: No roll command. lf’ithout a roll command, no thrusters are selected from Table C.3. Hence, the max thruster property holds. o Case 2.2: Roll command present. A roll command implies that T’a- ble C.2 yields no optional thrusters. This leaves only mandatory thrusters from each table, and the bound of four thrusters is satisfied.

The case analysis sketched in this informal proof can be directly formalized in F’VS. The result ing proof is quite lengthy, as shown in the proof tree in Figure 6.4. As noted earlier, the level of automation represented in this figure is higher than that illustrated in Section 6.1.3.3. Although it is certainly possible to use mechanized proof tools to verify informal proofs in this way, it is often far more productive to exploit the strengths of a particular tool to make the proof more automatic, more comprehensible, or more optimal with respect to other desired metrics. This kind of optimization follows quite naturally as one of the later steps in the inherently iterative process of developing and refining a proof. Figure 6.5 shows a considerably simpler and more automated proof for the max-thrusters–sel property. This second proof exploits the high-level PVS GRIND command that packages many lower-level commands, thereby automating most of the proof of max-thrusters_sel. II

‘c 3 -, . 128 Chapter 6

F (.k..,.P., 1-

(-s.”. . . . ----- ,,, ”,,.,..,

(,.., ,,. .,..”* umn.. ,

,,.., ,,. .,..”,. .@*.,. , h (r.. r,u .l.mih .4P..,., 1- (“9.”. .1..0 <,. , (, ,,, 1-

(... .“. mr.. t.:, ,r. ) 1-

(“...... win.) 1- (,1.,-”

,... .“...... E,., 1-

(... .“. .,< or u,.., E

{“,-...4 ..”1, m. ,,. ”.,

(e... .,..” (-?,,,., . ,,”.. ,

(“c..., .-L,.,.., \ (.X*. .,.ta,h. , ,, 7 (....., )

Figure 6.4: Proof Tree for SAFER_propertiesmax_thrusters_sel. NASA-GB-001-97 129

(skos”imp* )

(auto-rewrite . ..)

t- (expand . ..)

(use “max_thrusters_BF”)

(use ‘rnax_thfisters_LR~”)

(use “no_opt_thr_BFH)

(use “no_opt_thr_LRUD”)

(grind . ..)

k (expand IILRUD thrusters) (expand “BF_thruSter$”)7 (expand “BF._thrusters”)‘i

F y (assert) (assert) (assert)7

Figure 6.5: Reitised Proof ~eefor SAFER-propertiesmax-thrusters.sel. (,,arn+-sqa-ado-ou,, asn)

(uaa–sxaqsnxqq–x~m. asn)

-1

(*duITsoys)

L6-1OO-G3-WWN Chapter 7

Conclusion

This guidebook has presented a discussion of the technical issues involved in the use of forma] methods. The focus has been on using formal methods to analyze requirements and high-level designs, that is, on a spectrum of activities that apply mathematical techniques to formalize, explore, debug, validate, and verify software and hardware systems. ‘1’he development of the SAFER specification has exemplified the process of applying formal methods to aerospace applications. TIIC guidebook characterizes formal methods as an iterative process whose broad outlines are determined by contextual factors. Effect ive use of this prc}cess involves judiciously pairing formal methods with an application and its careful integration with existing quality control and assurance activities.

7.1 Factors Influencing the Use of Formal Methods

Two types of factors influence the use of formal methods: administrative factors and technical factors. Administrative factors- including project scale and staffing, integration of formal methods with traditional processes, and general project guidelines: training, specification and documentation standards and conventions, and so 011-- are discussed in Volume I of this Guidebook [NASA-95a]. Technical factors-–including the type, size, and structure of the application; level of formalization; scope of formal methods use; characteristics of available documentation, and choice of formal methods tool- -have been the subject of this second volume of the guidebook. These technical factors are summarized here.

● Type, Size, and Structure of the Application Formal methods are best suited to the analysis of complex problems, taken singly or in combination, and less suited for numerical algorithms or highly computational applications. Applications of moderate size with a coherent structure that can be decomposed into subsystems or components are typically most appropriate.

130 NASA-GB-001-97 131

. Level of Formalization Formal methods can be productively applied at various levels of formality or rigor, ranging from the occasional use of mathematical notation to exclusive use of semantically well-defined specification languages with mechanized proof support.

● Scope of Formal Methods Use Formal methods can be effectively applied in a variety of ways depending on which stages of the developmental life cycle, which system components, and what system functionality are formalized.

● Documentation Formal methods benefit from the availability of adequate documentation. The most important characteristics are the level at which the requirements (high-level design) are stated, the degree to which they are explicitly and unambiguously enumerated, the extent to which they can be traced to specific system components, and the availability of additional information or expertise to motivate and clarify their definition.

● Tool(s) Formal methods typically involve some level of mechanical support. The choice of formal methods tool, if any, is determined by administrative factors and the preceding technical factors (excepting documentation). Information on formal methods tools is available from several databases, including those maintained by Jonathon 130wen, Larry Paulson, and Carolyn Talcott, respectively [Bowen, Pauls, Talco].

7.2 The Process of Formal Methods

Contextual factors determine the broad outlines of formal methods use for a given application. The substance of the formal methods process has been characterized in previous chapters of this volume as a discipline composed of the following activities: characterizing, modeling;, specifying, analyzing, documenting, and lllaintaillillg/gelleralizi~lg.

● Characterizing Synthesizing a thorough understanding of the application and the applicat ioxl domain, resulting in a working characterization of the application and relevant par ts of its environment.

● Modeling Selecting a mathematical representation expressive enough to formalize the applicatioll domain, while providing sufficient analytical power to explore, calculate, and predict the behavior of the system.

● Specifying Developing a specification strategy, formalizing the application in terms of the underlying model and articulated strategy, and checking the syntactic and semantic correctness of the specification.

● Analyzing Predicting and calculating system behavior, challenging uuderlyiug assumptions, validating key properties and invariants, establishing the consistency of axioms, and establishing the correctness of hierarchical layers. 132 Chapter 7

● Documenting Recording underlying assumptions, motivating critical decisions, docutnenting rationale and crucial insights, providing additional explanatory material, tracing specification to requirements (high-level design), tracking level of effort, and collecting cost/benefit data.

● Maintaining/Generalizing Revisiting and, as necessary, modifying the specification and analysis to predict the consequences of proposed changes to the modeled system, to reflect mandated changes to the modeled system, to accommodate reuse of the formal specification and analysis, or to distill general principles from the formalization.

Although this linearization of the process is informative, it is important to keep two additional facts in mind. First, applying formal methods is an iterative process. A specification, like a conventional program, must be methodically developed, explored, modified, and refined through many iterations until the result is free of syntactic and semantic errors and captures desired characteristics and behaviors in a concise aud easily communicated form. SeCO1ld, the list is not prescriptive. Each project necessarily selects the most appropriate subset of the activities listed above, namely those most consistent with its mandate and the resources at its disposal.

7.3 Pairing Formal Methods, Strategy, and Task

Formal methods offer a diverse set of techniques appropriate for a wide variety of applications. Moreover, there arc many ways to use these techniques to model systems and to calculate and explore their properties. The implications of this rich repertoire of techniques and strategies is that the effective use of formal methods involves judicious pairing of method, strategy, and task. For example, control-intensive algorithtns for small finite systems, such as mode sequencing algorithms, are often most effectively analyzed usiug state exploration, while general properties of complex algorithms, such as Byzantine fault-tolerant clock synchronization, typically require efficient deductive support for arithmetic in the form of arithmetic decision procedures. When an optimal pairing of methods, strategy, and task is not readily apparent, a rapid prototype of an aggressively downscaled or abstracted model that preserves essential properties of interest can help to focus the selection. Precedence, that is, techniques or strategies successfully applied to similar tasks, can also serve as a guide in these cases. A complex application is typically decomposable into subtasks. In such cases; it may be productive to apply a combination of methods, or to apply a “lightweight” method such as model checking, animation, or direct execution to specific or reduced cases of all or part of a specification before attempting a more rigorous and costly analysis. For example, [HS96] reports the analysis of a communications protocol using a combination of finite state exploration, theorem proving, and model checking. The protocol was first manually reduced to finite state to allow certain safety properties to be checked using ArAsA.GB_ool_97 133 finite state exploration. These properties were then verified for the full protocol using deductive theorem proving. The invariant used for the proof had tcl be strengt,hencd through additional conjuncts discovered incrementally during the proof process. Each proposed new conjunct was checked in the reduced model, using state exploration before it was used in the evolving proof. This iterative process eventually yielded an invariant composed of 57 conjuucts. Exploiting the knowledge gained in this exercise, a finite-state abstraction of the original protocol was developed and nlcchanically verified. Finally, properties of the abstraction were verified, using a model checker for the propositional mu-calculus (see Chapter 6, Section 6.2.1.5). Although this particular example reflects a demanding exercise carried out by expert practitioners, it is a nice illustration of the productive interaction of combinations of techniques and strategies that are available to expert and nonexpert alike.

7.4 Formal Methods and Existing Quality Control and Assurance Activities

Formal methods complement, but do not replace, testing and other traditional quality control and assurance activities. 1 This symbiotic relationship between formal methods and traditional quality control and assurance methods derives from the fact that formal methods are most effectively used early in the life cycle, on suitably abstract representations of traditionally hard problenls,2 in order to provide complete exploration of a model of possible behaviors. Conversely, traditional quality control and assurance methods have proven highly effective late in the life cycle on concrete (implemented) solutions to hard problems, in order to establish the correctness of detailed and extensive, but necessarily finite behavioral scenarios. There are many ways to exploit the complementarily between formal methods and existing quality control and assurance activities. Some of these directly target formal methods’ products. For example, [CRS96, SH94] describe a fully automatable structural ( “black box”) specification-based testing technique that complements implenlentation- based testing. This technique derives descriptions of test conditions from a formal specification written in a predicate logic-based language. The test conditions guide selection of test cases and measure the comprehensiveness of existing test suites. Recent conference proceedings, for example [COMP95, ISSTA96], attest to current interest in developing automated methods that use formal specifications to generate test artifacts for concrete implementations. Other approaches reflect a more indirect use of formal methods. For example, formal, or even quasi-formal models developed during the application of formal methods can be 1 Following Rushby [Rus93b, p. 144], quality control denotes “methods for eliminating faults” and quality assurance denotes “methods for demonstrating that no faults remain,” 21ncluding, but not limited to, fault tolerance, concurrency, and nondeterminism, where capabilities distributed across components must be synchronized and coordinated, aud where subtle interactions, for example, due to timing and fault status, must be anticipated. 134 Chapter 7 used to facilitate traditional safety analyses. Leveson et al. report [MLR+ 96, p. 14] that CL . . . the state abstraction and organization [of their state-transition models] facilitated . . . fault tree analysis.” A further input to traditional safety analyses might involve the formal specification and analysis of key safety properties. For example, it can be demonstrated that a particular formal model satisfies (or fails to satisfy) given safety properties, that proposed system modifications captured in a model fail to preserve desired safety properties, or that an executable specification fails to satisfy a given test suite. The results of these and other formal analyses can, in turn, be used to expose areas of potential concern and, thereby, concentrate conventional testing activities. If the results of the testing are then iterated back into the formal analysis, the increasingly focused iteration can be used to refine requirements or high-level designs. The examples cited here are suggestive, only. III general, the tighter the integration of formal and conventional methods, the more productive the interplay between formal techniques and traditional quality control and assurance activities.

7.5 Formal Methods: Verification Versus Validation and Exploration

The real value of formal methods lies not in their ability to eliminate doubt, but in their capacity to focus and circumscribe it.3

The use of formal methods is often seen as a form of absolute guarantee – a proof of total correctness. However, as Rushby [Rus93b, pp. 74-75] notes, equating formal verification with total correctness is doubly misleading in that it overestimates the guarantee conferred by formal verification while it underestimates the value of the formal verification process, per se. The guarantee conferred by formal verification assures the mutual consistency of the specifications at either end of a chain of verification, but necessarily fails to address the adequacy of the underlying model, the extent to which the highest-level specification captures the requirements, or the fidelity with which the lowest-level specification captures the behavior of the actual system. The potentially contentious issue of the adequacy of the model is typically resolved through extensive use, challenge, and review, although there have been a few interesting attempts to characterize and automate the selection of “adequate” models of physical systems [Nay95]. The fidelity of the upper- and lowermost specifications in a chain of verification is established through validation. The value of the process of formal verification lies not only, or even primarily, in the end product—-that is, in a proof of correctness, but rather in the benefits accumulated along the way. These benefits include many of those discussed in previous chapters of this guidebook. — —— 3Paraphrase of a comment from John Rushby. ivAsA-G13-ool-97 135

● A detailed enumeration of all the assumptions, axioms, and definitions that provide the underlying basis for the verification and characterize the requirements and properties whose satisfaction or utility in the physical world must be empirically va] i dated.

● The validation of these assumptions and properties (for example, through proof checking or model checking).

● The (early) detection of inconsistent requirements or of design faults. Most verifications fail, at least initially, and the information gained from these failed attempts reveals unstated assumptions, missing cases, and other errors of interpretation or omission. Although some of these errors would probably be caught by conventional techniques, others are quite subtle and less likely to be exposed by informal techniques or sampled behaviors.

● The ability to explore readily and reliably the consequences of additional or modified assurnptions, requirements, and designs, reinforcing and informing the necessarily iterative process of developing large and complex systems.

● The ability to identify and develop reusable formal methods techniques, strategies, and products, contributing to a cost-effective approach to the development of large and complex systems.

● The improved understanding and identification of better solutions derived from the intense scrutiny and discipline involved in the process of formalization and formal analysis.

In summary, formal methods do not focus exclusively or even primarily on “proving correctness’’ –-the verification activities associated with software implementations and hardware layouts- but rather on exploring, debugging, and validating artifacts, such as requirements and high-level designs, leading to a deeper understanding of their properties and assumptions, an earlier capability for calculating and predicting their behavior, and a fuller appreciation of the consequences of modifying their structure, properties, or environment. This guidebook has attempted to provide formal methods practitioners with the information and insight essential to the productive use of formal methods. References

[AC96] M. Abadi and L. Cardelli. A 2%eory of Objects. Monographs in Conl- puter Science. Springer-Verlag, New York, NY, 1996.

[ACHH93] R. Alur, C. Courcoubetis, T. A. Henzinger, and Pei-Hsin Ho. Hybrid Automata: An Algorithmic Approach to the Specification and Verifica- tion of Hybrid Systems. In Grossman et al. [GNRR93], pages 209--229.

[Ack62] R. L. Ackoff, editor. Scientific Method: Optimizing Applied Research Decisions. John Wiley and Sons, 1962.

[ACM94] Ninth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA ‘91), Portland, Oregon, Octo- ber 1994. ACM/SIGPLAN(in SIGPLAN Notices Vol 29, No. 10, Octo- ber 1994).

[AD91] R. Alur and D. Dill. The Theory of Timed Automata. In de Bakker et al. [dBHdRR91], pages 45-- 71.

[AH91] R. Alur and T. A. Henzinger. Logics and Models of Real Time: A Survey. In de Bakker et al. [dElHdRR91], pages 74—106.

[AH95] R. Alur and Pei-Hshl Ho. HYTECH: The Cornell HYbrid Technology Tool. In Antsaklis et al. [AKNS95], pages 265—293.

[AH96] Rajeev Alur and Thomas A. Henzinger, editors. Computer-Aided Veri- fication, CAV ’96, volume 1102 of Lecture Notes in Computer Science, New Brunswick, New Jersey, July/August 1996. Springer-Verlag.

[AH97] M. Archer and C. Heitmeyer. Verifying Hybrid Systems Modeled as Timed Automata: A Case Study. In Proceedings of the International Workshop on Hybrid and Real-Time Systems (HA RT’97), Grenoble, Fiance, March 1997.

[AHS96] Rajeev Alur, Thomas Henzinger, and Eduardo Sontag, editors. Hybrid Systems III, Verification and Control, volutne 1066 of Lecture Notes in Computer Science, New York, NY, 1996. Springer-Verlag.

136 j/TAc&,4.(-3B.ool-97 137

[AINP88] Peter B. Andrews, Sunil Issar, Daniel Nesmith, and Frank Pfenning. The TPS Theorem Proving System. In Lusk and Overbeek [L088], pages 760 761.

[AKNS95] Panes Antsaklis, Wolf Kohn, Anil Nerode, and Shaukar Sastry, editors. Hybrid Systems II, volume 999 of Lecture Notes in Computer Science, New York, NY, 1995. Springer-Verlag.

[AL95] Y. Ampo and R. Lutz. Evaluation of Software Safety Analysis Using Formal Methods. In Foundation of Software Engineering Workshop, Hamana-ko, Japan, December 1995.

[AMCP84] P. B. Andrews, D. A. Miller, E. L. Cohen, and F. Pfenning. Automating . Higher-Order Logic. In Automated Theorem Proving: After 25 Years, pages 169 192. American Mathematical Society, 1984.

[And86] Peter B. Andrews. An Introduction to Logic and T~pe Theory: To Truth through Proof. Academic Press, New York, NY, 1986.

[BB89] Karl Hans Blasius and Hans-Jurgen Burckert. Deduction Systems in Artificial Intelligence. Ellis Horwood Series in Artificial Intelligence. Ellis Horwood Limited, Chichester, West Sussex, UK, 1989. Distributed in the U.S. by Halsted Press: a division of John Wiley and Sons.

[BC94] R. Bourdeau and B. Cheng. A Formal Semantics of Object Models. Technical Report MSU-CPS-94-6, Department of Computer Science, Michigan State University, East Lansing, Michigan, January 1994.

[BC95a] William R. Bevier and Richard M. Cohen. An Executable Model of the Synergy File System. Technical report, Computational Logic, Inc., May 1995.

[BC95b] R. 130urdeau and B. Cheng. A Formal Semantics for Object Model Diagrams. IEEE Transactions on Software Engineering, 21 (10):799 821, October 1995. .

[BCC+ 95] Ricky W. Butler, James L. Caldwell, Victor A. Carreno, C. Michael Holloway, Paul S. Miner, and Ben L. Di Vito. NASA Langley’s Re- search and Technology ~kansfer Program in Formal hlethods. In Tenth Annual Conference on Computer Assurance (COMPASS 95), Gaithers- burg, MD, June 1995.

[BCM+-90] J. R. Burch, E. M. Clarke, K. L McMillan, D. L. Dill, and L. J. Hwang. Symbolic Model Checking: 1020 States and Beyond. In 5th Annual IEEE Symposium on Logic in Computer Science, pages 428- 439, Philadelphia, PA, June 1990. IEEE Computer Society. 138 References

[BDH94] Ricky W. Butler, Ben L. Di Vito, and C. Michael Holloway. Formal Design and Verification of a Reliable Computing Platform for Real- Time Control: Phase 3 Results. NASA Technical Memorandum 109140, NASA I,augley Research Center, Hampton, VA, August 1994.

[BE87] Jon Barwise and John Etchemcndy. The Liar: An Essay in Truth and Circularity. Oxford University Press, New York, NY, 1987.

[13E93] ~T. Bi~el alld ~. Eder. Methods al)d cal~u]i for Deduction. 111 ~and~oo~ of Logic in Artificial Intelligence and Logic Programming, volume 1: Logical Foundations, pages 68-182. Oxford, 1993.

[Bee86] Michael J. Beeson. proving Programs and Programming Proofs. In 17L- ternational Congress on Logic, il!ethodology and Philosophy of Science VII, pages 51-82, Amsterdam, 1986. North-Holland. Proceedings of a meeting held at Salzburg, Austria, in July 1983.

[Be186] E. T. Bell. lt4en of Mathematics. A Touchstone Book. Simon k Schuster, Inc., New York, NY, 1986. First published in 1937.

[Bev89] William R. Bevier. Kit and the Short Stack. Journal of Automated Reasoning, 5(4):519- 530, December 1989.

[BG96] Bernard Boigelot and Patrice Godefroid. Symbolic Verificat ion of Com- munication Protocols with Infinite State Spaces Using QDDs. In Alur and Henzinger [A H96], pages 1-12.

[BH91] J.M. Boyle and T.J. Harmer. Functional Specifications for Mathemat- ical Computations. In B. Moller, editor, Constructing Programs from Specifications, pages 205-224. North-Holland, 1991. Proceedings of the IFIP TC2/WG 2.1 Working Conference on Constructing Programs from Specifications, Pacific Grove, CA, USA, 13-16 May 1991.

[BH97] R. Bharadwaj and C. Heitmeyer. Verifying SCR Requirements Speci- fications using State Exploration. In First ACM SIGPLAN Workshop on Automatic Analysis of Software, Paris, France, January 1997. Asso- ciation for Computing Machinery.

[BHL90] D. Bjtmner, C.A.R. Hoare, and H. Langmaack, editors. VDM ’90: VDh4 and Z - Formal Methods in Software Development, volume 428 of Lecture Notes in Computer Science, Kiel, FRG, April 1990. Springer- Verlag.

[BHMY89] William R. Bevier, Warren A. Hunt, Jr., J Strother Moore, and William D. Young. An Approach to Systems Verification. Journal of Automated Reasoning, 5(4):41 1-428, December 1989. NASA-GB-001-97 139

[BHS91] F. Belina, D. Hogrefc, and A. Sarma. SDL with Applications jrom Pro- tocol Specification. BCS Practitioner Series. Prentice Hall International Ltd., Hemel Hempstead, UK, 1991.

[BM79] R. S. Iloyer and J S. Moore. A Computational Logic. Academic Press, New York, NY, 1979.

[BM88] R. S. Eloyer and J S. Moore. A Computational Logic Handbook. Aca- demic Press, New York, NY, 1988.

[BMS+96] Ricky W. Butler, Paul S. Miner, Mandayam K. Srivas, Dave A. Greve, and Steven P. Miller. A Bitvectors Library for PVS. hTASA Technical Memorandum 110274, NASA Langley Research Center, Hampton, VA, August 1996.

[Iloe87] B. Boehm. Industrial Software Metrics Top 10 List. IEEE Software, 4(5):84-85, September 1987.

[Bo091] G. Bc)och. Object- Oriented Design with Applications. Ben- jamin/Cunlmings Series in Ada and Software Engineering. Ben- jamin/Cutnmings Inc., Redwood City, CA, 1991.

[Bowcn] http: //w'ww.conllab. ox.ac.uk/archive/f orll~al-n~ethods. ht~nl. Follow the link “individual notations, methods and tools”.

[Boy89] J .M. Boyle. Abstract Programming and Program Transfornlat ions - An Approach to Reusing Programs. In T. J. Biggerstaff and A. J. Perlis, editor, Software Reusability, Volume 1, pages 361-413. ACM Press, Addison-Wesley Publishing Company, 1989.

[BP83] Paul Benacerraf and Hilary Putnam, editors. Philosophy of Mathe- matics: Se/ected Readings. Cambridge University Press, Cambridge, England, second edition, 1983.

[BR73] J. W. De 13akker and W. De Roever. A Calculus for Recursive Program Schemes. In M. Nivat, editor, Automata, Languages, and Programming, pages 167-196, Amsterdam, 1973. North Holland.

[Bre91] Algebraic Specification Techniques in Object Orienied Programming Environments, volume 562 of Lecture Notes in Computer Science. Springer-Verlag, 1991.

[Bry86] R. E. Bryant. Graph-Based Algorithms for Boolean F’unction Manipu- lation. IEEE Transactions on Computers, C-35(8), 1986.

[Bry94] Arthur E. Bryson, Jr. Control of Spacecraft and Aircraft. Princeton University Press, Princeton, New Jersey, 1994. 140 References “

[BS93] Jonathan Bowen and Victoria Stavridou. The Industrial Take-up of Formal Methods in Safety-Critical and other Areas: A Perspective. In J. C. P Woodcock and P. G. Larsen, editors, FhJE ‘9.?: Industrial- Strength Formal Methods, pages 183-195, Odense, Denmark, April 1993. Volume 670 of Lecture Notes in Computer Science, Springer- Verlag.

[Bur69] R. Burstall. Proving Properties of Programs by Structured Induction. Computing Journal, 12(1):41- 48, 1969.

[Bur84] John P. Burgess. Basic Tense Logic. In Gabbay and Guenthner [GG84], chapter 11.2, pages 89 133.

[Bus90] Marilyn Ilush. Improving Software Quality: The Use of Formal In- spections at the Jet Propulsion Laboratory. In 12th International Con- ference 071 Software Engineering, pages 196-199, Nice, France, March 1990. IEEE Computer Society.

[BwHJ78] D. Brand and Jr. W. H. Joyner. Verification of Protocols lJsing Sym- bolic Execution. Computer Networks, 2:351-360, 1978.

[BY90] W. R. Bevier and W. D. Young. Machine-Checked Proofs of a 13yzan- tine Agreement Algorithm. Technical Report 55, Computational Logic Incorporated, Austin, TX, June 1990.

[Car58] Rudolf Carnap. Introduction to Symbolic Logic and Its Applications. Dover Publications, Inc., New York, NY, 1958. English translation of Einfiihrung in die symbolische Logik, 1954.

[CBK90] E. M. Clarke, 1. A. Browne, and R. P. Kurshan. A Unified Approach for Showing Language Containment and Equivalence Between Various Types of w-Automata. In A. Arnold, editor, CAAP ’90, 15th Collo- quium on Trees in A /gebra and Programming, pages 103-116, Copen- hagen, Denmark, May 1990. Volume 431 of Lecture Notes in Computer Science, Springer-Verlag.

[CE81] E. M. Clarke and E. A. Iihnerson. Characterizing Properties of Parallel Programs as Fixpoints. In 7th International Colloquium on Automata, Languages and Programming. Volume 85 of Lecture Notes in Computer Science, Springer-Verlag, 1981.

[CES86] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automatic Verification of Finite-State Concurrent Systems using Temporal Logic Specifications. ACM Transactions on Programming Languages and Systems, 8(2):244- 263, April 1986. NASA-GB-001-97 141

[CFJ93] E. M. Clarke, T. Filkorn, and S. Jha. Exploiting Symmetry in Temporal I,ogic Model Checking. In Courcoubetis [COU93].

[CGK89] )3. M. Clarke, O. Grumberg, and R. P. Kurshan. A Synthesis of Two Ap- proaches for Verifying Finite State Concurrent Systems. In A. R. Meyer and M. A. Taitslin, editors, Logic at Botik ’89, Symposium on Logi- cal Foundations of Computer Science, pages 81-90, Pereslavl-Zalessky, USSR, July 1989. Volume 363 of Lecture Notes in Computer Science, Springer-Verlag.

[CGI,92] Edmund M. Clarke, Orna Grutnberg, and David E. Long. Model Check- ing and Abstraction. In 19th ACM Symposium on Principles of Pro- gramming Languages, pages 343-354, Albuquerque, NM, January 1992. Association for Computing Machinery.

[CH89] Rance Cleveland and Matthew Hennessy. Testing Equivalence as a Bisimulation Equivalence. In International Workshop on Automatic Verification Methods for I’inite State Systems, Grenoble, France, June 1989. Volume 407 of Lecture Notes in Computer Science, Springer- Verlag.

[CHB92] D. Coleman, F. Hayes, and S. Bear. Introducing Objectcharts or How to Use St atecharts in Object-Oriented Design. IEEE Transactions on Software Engineering, 18(1 ):9-- 18, January 1992.

[CHJ86] B. Cohen, W. T. IIarwood, and M. 1. Jackson. The Specification of Complex Systems. Addison- Wesley, Wokingham, England, 19S6.

[CHR92] Zhou Chaochen, C. A. R. Hoare, and A. P. Ravn. A Calculus of Dura- tions. Information Processing Letters, 40(5):269 -276, 1992.

[CK90] E. M. Clarke and R. P. Kurshan, editors. Computer-Aided Verifica- tion, CA Jr ’90, volume 3 of DIMA CS Series in Discrete Mathematics and Theoretical Computer Science. American Mathematical Society and Association for Computing Machinery, June 1990.

[CKM’91] Dan Craigen, Sentot Kromodimoeljo, Irwin Meisels, Bill Pase, and h4ark Saaltink. EVES: An Overview. In S. Prehn and W. J. Toetenel, editors, VDM ’91: Formal Software Development Methods, pages 389- 405, Noordwijkerhout, The Netherlands, October 1991. Volume 551 of Lecture Notes in Computer Science, Springer-Verlag. Volutne 1: Con- ference Contributions.

[CI,73] Chin-Liang Chang and Richard Char-limg Lee. Symbolic Logic and it4echanical Theorem Proving. Computer Science and Applied nlathe- matics. Academic Press, New York, NY, 1973. 142 References

[CLM89] E. L4. Clarke, D. E. I,ong, and K. I,. Mchlillan. Compositional Mode] Checking. In Jth Annual IEEE Symposium on Logic in Computer Sci- ence, pages 353-362, Asilomar, Pacific Grove, CA, June 1989. IEEE Computer Society.

[CLS96] David Cyrluk, Patrick Lincoln, and N. Shankar. On Shost ak’s Decision Procedure for Combinations of Theories. In M. A. McRobbie and J. K. Slaney, editors, Automated Deduction--- CA DE-13, pages 463-477, ~ew Brunswick, NJ, July/August 1996. Volume 1104 of Lecture Notes in Artificial Intelligence, Springer-Verlag.

[CLSS96] Rance Cleaveland, Philip Lewis, Scott Smolka, and Oleg Sokcdsky. The Concurrency Factory: A Development Environment for Concurrent Systems. In Alur and Henzinger [AH96], pages 398-401.

[CM88] K. Mani Chandy and Jayadev hlisra. Parallel Program Design: A Foundation. Addison-Wesley, Reading, hIA, 1988.

[CMCHG96] E. Clarke, K. McMillan, S. Carnpos, and V. Hartonas-Garmhausen. Symbolic Model Checking. In Alur and Henzinger [AH96], pages 419- 422.

[COC84] Nino B. Cocchiarella. Philosophical Perspectives on Quantification in Tense and Modal Logic. In Gabbay and Guenthner [G G84], chapter 11.6, pages 309-353.

[COMP95] COMPASS ’95 (Proceedings oj the Ninth Annual Conference on Com- puter Assurance), Gaithersburg, MD, June 1995. IEEE Washington Section.

[COU93] Costas courcoubetis, editor. Computer-Aided Verificationj CA V ’93, volume 697 of Lecture Notes in Computer Science, Elounda, Greece, June/July 1993. Springer-Verlag.

[CPS93] Rance Cleaveland, Joachim Parrow, and Bernhard Steffen. The Con- currency Workbench: A Semantics-Based Tool for the ~~erification of Concurrent Systems. ACM Transactions on Programming Languages and Systems, 15(1):36-72, January 1993.

[CRS96] J. Chang, D. Richardson, and S. Sankar. Structural Specification-Based Testing with ADL. In ISSTA [ISSTA96], pages 62-70.

[CS89] Dan Craigen and Karen Summerskill, editors. Formal Methods for Trustworthy Computer Systems (FM89), Halifax, iNova Scotia, Canada, July 1989. Springer-Verlag Workshops in Computing. NASA-GB-001-97 143

[CS96] Rance Cleavelaud and Steve Sims. The NCSU Concurrency Workbench. In Alur and Henzinger [AH96], pages 394-397.

[CVWY92] C. Courcoubetis, M. Vardi, P. Wolper, and M. Yanakakis. hJenlory- Efficient Algorithms for the Verification of Tempo[al Properties. In Formal hlethods in Sgstem Design 1, pages 275--288. Kluwer, 1992.

[CWB94] B. Cheng, E. Wang, and R. Bourdeau. A Graphical Environment for Formally Developing Object-Oriented Software. In IEEE International Conference on Tools with AI, San Diego, CA, November 1994.

[CY91a] P. Coad and E. Yourdon. Object-Oriented Analysis. Yourdon Press Computing Series. Prentice Hall, Euglewood Cliffs, NTJ, 1991. Second Edition.

[cY91t)] P. Coad and E. Yourdon. Object-Oriented Design. Yourdon Press Com- puting Series. Prentice Hall, Englewood Cliffs, hTJ, 1991.

[Dah90] Ole-Johan Ilahl. Object Orientation and Formal Techniques. In D. Bjorner, C.A.R. Hoare, and H. I,angrnaack, editors, VDLf’90: VDM and Z, pages 1-11. Number 428 in Lecture N1otes in Computer Science, Springer-Verlag, 1990.

[d13dRR89] J. W. de Bakker, W. P. de Roever, and G. Rozenberg, editors. Step- wise Refinement of Distributed Systems, volume 430 of Lecture Notes in Computer Science, REX Workshop, Mook, The Netherlands, May/June 1989. Springer-Verlag.

[dBHdRR91] J. W. de Bakker, C. Huizing, W. P. de Roever, and G. Rozenberg, editors. Real Time: Theory in Practice, volume 600 of Lecture Notes in Computer Science, REX Workshop, Mook, The Netherlands, June 1991. Springer-Verlag.

[DDHY92] David L. Dill, Audreas J. Drexler, Alan J. Hu, and C. Hau Yang. Proto- col Verification as a Hardware Design Aid. In 1992 IEEE International Conference on Computer Design: VI,SI in Computers and Processors, pages 522-525. IEEE Computer Society, 1992. Cambridge, h4A, Octo- ber 11-14.

[I)ij76] E. M’. Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Cliffs. NJ, 1976.

[Di194] D. L. Dill, editor. Computer-Aided Verification, CA V ’94, volume 818 of Lecture Notes in Computer Science, Stanford, CA, June 1994. Springer- Verlag. 144 References

[Di196] D. Dill. The Mur~~ Verification System. In Alur and Henzinger [AH96], pages 390-393.

[DJ90] IN. Dershowitz and J.-P. Jouannaud. Rewrite Systems. In van Lecuwen [vL90], chapter 6, pages 243-320.

[DN89] J. Daintithand R. Nelson, editors. The Penguin Dictionary of Mathe- matics. Penguin, London, UK, 1989.

[DR96] Ben L. DiVitoand Larry W. Roberts. Using Fornlal Methods to As- sist in the Requirements Analysis of the Space Shuttle GPS Change Re- quest. NASA Contractor Report 4752, NASA Langley Research Center, Hampton, VA, August 1996.

[DST80] P. J. Downey, R. Sethi, and R.. E. Tarjan. Variations on the Common Subexpressions Problem. Journal of the ACM, 27(4):758--771, October 1980.

[EL85] 13.A. Emerson and C.L. I,ei. Efficient Model Checking in Fragments of the Propositional Mu-Calculus. In Proceedings of the 1 W Symposium on Principles of Programming Languages, pages 84–96, New Orleans, LA, January 1985. Association for Computing Machinery.

[EL86] E. Allen Emerson and Chin-I,aung Lei. Efficient Model Checking in Fragments of the Propositional Mu-Calculus. In 2no! Annual IEEE Symposium on Logic in Computer Science, pages 267-278. IEEE Conl- puter Society, June 1986.

[ES93] E.A. Emerson and A. Prasad Sistla. Symmetry and Model Checking. In Courcoubetis [COU93].

[Fag76] M. E. Fagan. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15(3):182-21 1, March 1976.

[Fag86] M. E. Fagan. Advances in Software Inspection. IEEE Transactions on Software Engineering, SE-12(7):744- 751, July 1986.

[FBHL84] A. A. Fraenkel, Y. Bar-Hillel, and A. Levy. Foundations of Set Theory, volume 67 of Studies in Logic and the Foundations of Mathematics. North-Holland, Amsterdam, The Netherlands, second printing, second edition, 1984.

[FBWK92] Stuart Faulk, John Brackett, Paul Ward, and James Kirby, Jr. The CORE Mc!thod for Real-Time Requirements. IEEE Software, 9(5):22- 33, September 1992. NASA-GB-001-97 145

[FC87] S. Faulk and P. Clements. The NRL Software Cost Reduction (SCR) Requirements Specification Methodology. In Fourth International Workshop on Software Specification and Design, Monterey, CA, April 1987. IEEE Computer Society.

[FF93] Stephen F’ickas and Anthony Finkelstein. Requirements Engineering 1993. In RF; [RE93], pages v- vi.

[FKV94] hl. D. Flaser, K. Kutnar, and V. K. Vaishnavi. Strategies for Incorporat- ing Formal Specifications in Software Development. Communications of the ACM, 37(10):74- 86, october 1994.

[FMJJ92] J. Fernaudez, L. Mouuier, C. Jard, and T. Jeron. On-the-fly Verificat ion of Finite Transition Systems. In Formal Methods in System Design 1, pages 251--273. Kluwer, 1992.

[FN86] A. Furtado and E. Neuhold. Formal Techniques for Data Base Design. Springer-Verlag, 1986.

[Gar84] James W. Garson. Quantification in Modal Logic. In Gabbay and Guenthuer [GG84], chapter 11.5, pages 249-307.

[GAS89] D.1. Good, R.L. Akers, and L.M. Smith. Report on Gypsy 2.05. Tech- nical Report 1, Computational Logic Inc., Austin, TX, January 1989.

[Gen70] Gerhard Gent zen. Collected Papers, edited @ M. E. Szat)o. Studies in Logic. North Holland, New York, NY, 1970.

[GG83] Dov M. Gabbay and Ihanz Guenthner, editors. Handbook of Philosophi- cal Logic– Volume I: Elements of Classical Logic, volume 164 of Synthese Library. D. Reidel Publishing Company, Dordrecht, Holland, 1983.

[GG84] Dov M. Gabbay and Franz Guenthner, editors. Handbook of Philo- sophical Logic- Volume II: Extensions oj Classical Logic, volume 165 of Synthese Library. D. Reidel Publishing Company, Dordrecht, Holland, 1984.

[Gi160] P. C. Gilmore. A Proof Method for Quantification Theory: Its Justi- fication and Realization. IBA4 Journal of Research and Development, 4:28-35, 1960.

[GKK+ 88] J. Goguen, C. Kirchner, H. Kirchner, A. M6grelis, J. Meseguer, and T. Winkler. An Introduction to 0BJ3. In Proceedings of the Co?lference on Conditional Term Rewriting, pages 258–263, Orsay, France, 1988. Number 308 in Lecture Notes in Computer Science, Springer-Verlag. 146 References

[GL96] P. Godefroicl and D. E. Long. Symbolic Protocol Verification with Queue BDDs. In Ilth Annual IEEE Symposium on Logic in Computer Science, pages 198-206, Ncw Brunswick, New Jersey, July 1996. IEEE Computer Society.

[GIa95] James Glanz. Mathematical Logic Flushes Out the Bugs in Chip De- signs. Science, 267:332–333, January 20, 1995.

[GM93] M. J. C. Gordon and T. F. Mclham, editors. Introduction to HOI,: A Theorem Proving Environment for Higher-Order Logic. Cambridge University Press, Cambridge, UK, 1993.

[GMT+ 80] S. L. Gerhart, D. R. Musser, D. H. Thompson, D. A. Baker, R. L. ‘ Bates, R. W. Erickson, R. L. London, D. G. Taylor, and D. S. Wile. An Overview of Atlirm: A Specification and Verification System. in S. H. Lavington, editor, Information Processing ’80, pages 343-347, Australia, October 1980. IFIP, North-Holland Publishing Company.

[GMW79] M. J. Gordon, A. J. Milner, and C. P. Wadsworth. Edinburgh LCF: A Mechanised Logic of Computation, volume 78 of Lecture Notes in Computer Science. Springer-Verlag, 1979.

[GNRR93] Robert L. Grossman, Anil Nerode, Anders P. Ravn, and Hans Rischel, editors. Hybrid Systems, volume 736 of Lecture Notes in Computer Science, New York, RTY, 1993. Springer-Verlag.

[God90] P. Godefroid. Using Partial Orders to Improve Automatic Verification Methods. In Clarke and Kurshan [CK90], pages 321-339.

[God96] Partial- Order Methods for the Verification of Concurrent Systems, An Approach to the State-Explosion Problem, volume 1032 of Lecture Notes in Computer Science. Springer-Verlag, 1996.

[Gor] M. J. Gordon. Varieties of Theorem Provers. Unpublished manuscript.

[Gor86] M. Gordon. Why Higher-Order Logic is a Good Formalism for Speci- fying and Verifying Hardware. In G. Milne and P. A. Subrahmanyam, editors, Formal Aspects of VLSI Design, pages 153-177. Elsevier, 1986. Reprinted in Yoeli [Yoe90, pp. 57- 77].

[Gor89] Michael J. C. Gordon. Mechanizing Programming Logics in Higher- Order Logic. In G. Birtwistle and P. A. Subrahmanyam, editors, Cur- rent Trends in Hardware Verification and Theorem Proving, pages 387- 439, New York, NY, 1989. Springer-Verlag. NASA-GB-001-97 147

[GPS96] Patrice Godefroid, Doron Pcled, and Mark Staskauskas. Using Partial- Order Methods in the Formal Validation of Industrial Concurrent Pro- grams. IEEE Transactions on Software Engineering, 22(7):496--507, July 1996.

[Gro92] RAISE Language Group. The RAISE Specz’’cation Language. 13CS Practitioner Series. Prentice Hall, Hemel Hempstead, UK, 1992.

[GS90] Susanne Graf and Bernhard Steffen. Compositional Minimization of Finite-State Systems. In E. M. Clarke and R. P. Kurshan, editors, Computer-Aided Verification, CA V ’90, pages 186--196, New Brunswick, NJ, June 1990. Volume 531 of Lecture Notes in Computer Science, Springer-Verlag.

[GS93] David Cries and Fled B. Schneider. A Logical Approach to Discrete Math. Texts and Monographs in Computer Science. Springer-Verlag, New York, NY, 1993.

[H+ 78] K. L. Heninger et al. Software Requirements for the A-7)3 Aircraft. NRL Report 3876, Naval Research Laboratory, Novelnber 1978.

[H~90] D. Harel et al. STATEMATE: A Working Environment for the Devel- opment of Complex Reactive Systems. IEEE Transactions on Software Engineering, 16(4):403-414, April 1990.

[Haj78] J. Hajek. Automatically Verified Data TYansfer Protocols. In Proceed- ings of the lth ICCC, pages 749 756, Kyoto, Japan, 1978.

[Ha184] Michael Hallett. Cantorian Set Theory and Limitation of Size. Num- ber 10 in Oxford Logic Guides. Oxford University Press, Oxford, Eng- land, 1984.

[Ha190] A. Hall. Using Z as a Specification Calculus for Object-Oriented Systems. In D. Bjorner, C.A .R. Hoare, and H Langmaack, editors, VDM’90: VDM and Z, pages 290-318. Number 428 in Lecture Notes in Computer Science, Springer-Verlag, 1990.

[Har84] David Harel. Dynamic Logic. In Gabbay and Guenthner [G G84], chapter 11.10, pages 497-604.

[Har87] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Sci- ence of Computer Programming, 8(3):231-274, 1987.

[Hat82] William S. Hatcher. The Logical Foundations of Mathematics. Perga- mon Press, Oxford, UK, 1982. 148 References

[Hay87] Ian Hayes, editor. Specification Case Studies. Prentice Hall Interna- tional Ltd., Hernel Hempstead, UK, 1987.

[Haz83] Allen Hazen. Predicative Logics. In Gabbay and Guenthner [GG83], chapter 1.5, pages 331-407.

[HB95a] M. G. Hinchey and J. P. Bowen, editors. Applications of Formal Meth- ods. Prentice Hall International Ltd., Hemel Hempstead, UK, 1995. International Series in Computer Science.

[HB95b] M. G. Hinchey and J. P. Elowen. Applications of Formal Methods FAQ. [HB95a], pages 1-15.

[HBGL95] Constance Heitmeyer, Alan Bull, Carolyn Gasarch, and Bruce Labaw. SCR*: A Toolset for Specifying and Analyzing Requiremelks. In COMP [COMP95], pages 109-122.

[HC91] F. Hayes and D. Coleman. Coherent Models for Object-Oriented Anal- ysis. In 00PSLA ’91 (Object-Oriented Programming Systems, Lan- guages, and Applications 1991) Conference Proceedings, Phoenix, AZ, October 1991. Communications of the ACM.

[HC95] D. N. Hoover and Zewei Chen. Tablewise, a Decision Table Tool. In COMP [COMP95], pages 97-108.

[HCL95] David Hamilton, Rick Covington, and Alice Lee. Experience Report on Requirements Reliability Engineering Using Formal Methods. In lS- SRE ’95: International Conference on Software Reliability Engineering, Toulouse, France, 1995.

[HCRP91] NT. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The Synchronous Dataflow Programming Language Lustre. Proceedings of the IEEE, 79(9):1305- 1320, September 1991.

[Hen80] K. L. Heninger. Specifying Software Requirements for Complex Sys- tems: New Techniques and Their Application. IEEE Transactions on Software Engineering, SE6(1):2-13, January 1980.

[HFB93] N. Halbwachs, J.-C. Fernandez, and A. Bouajjanni. An executable temporal logic to express safety properties and its connection with the language Lustre. In Sixth International Symposium on Lucid and In- tentional Programming, ISLIP’93, Quebec, April 1993.

[HGH96] D. N. Hoover, David Guaspari, and Polar Humenn. Applications of For- ma] Methods to Specification and Safety of Avionics Software. NASA Contractor Report 4723, NASA Langley Research Centx!r, Hampton, VA, April 1996. (Work performed by Odyssey Research Associates). NASA-GB-001-97 149

[HHK96] R. Hardin, Z. Har’El, and R. Kurshan. COSPAN. I~L Alur and Hen- zinger [AH96], pages 423–427.

[HJL95] Constance Heitrneyer, Ralph Jeffords, and Bruce Labaw. Tools for An- alyzing SCR-Style Requirements Specifications: A Formal Foundation. Technical Report 7499, Naval Research Laboratory, Washington DC, 1995. in press.

[HLK95] Constance Heitmeyer, Bruce Labaw, and Daniel Kiskis. Consistency Checking of SCR-Style Requirements Specifications. In International Symposium on Requirements Engineering, York, England, March 1995. IEEE Computer Society.

[HLR92] N. Halbwachs, F. Lagnier, and C. Ratel. Programming and Verifying ‘ Real-Time Systems by Means of the Synchronous Data-Flow Program- ming Language Lustre. IEEE Transactions on Software Engineering, Special Issue on the Specification and Analysis of Real-Time Systems, September 1992.

[HN96] D. Harel and A. Naamad. The STATEMATE Semantics of Statecharts. ACM Transactions on Software Engineering Methodology, 5(4) :293-- 333, 1996.

[Hoa69] C. A. R. Hoare. An Axiomatic Basis of Computer Programming. Com- munications of the ACM, 12(10):576 580, October 1969.

[Hoa85] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall International Series in Computer Science. Prentice Hall, Hemel Henq~- stead, UK, 1985.

[Hoi] G. Holzmann. Persormal communicant ion.

[H0181] G. Holzmann. A Theory for Protocol Validation. In Proceedings of the First IFIP PSTV Conference on Protocol Specification, Testing, and Verification, pages 377-391, Teddington, UK, 1981. Also appeared in IEEE Transactions on Computers, C-31(8):730-738, August 1982.

[H0184] G. Holzmann. Backward Symbolic Execution of Protcjcols. In Proceed- ings of the Fourth IFIP PSTV Conference on Protocol Specification, Testing, and Verification, pages 19--30, Skytop, PA, 1984.

[H0191] G. J. Holzrnann. Design and Validation of Computer Protocols. Prentice Hall Software Series. Prentice-Hall, 1991.

[HP73] P. Hitchcock and D. Park. Induction Rules and Termination Proofs. In M. NTivat, editor, Automata, Languages, and Programming, pages 225-251, Amsterdam, 1973. North Holland. 150 References

[HP96] G. Holzrnann and D. Peled. The State of SPIN. In Alur and Henzinger [AH96], pages 385-389.

[HS96] Klaus Havelund and NT. Shankar. Experiments in Theorem Proving and Model Checking for Protocol Verification. In Formal Methods Europe FME ’96, pages 662-681, Oxford, UK, March 1996. Number 1051 in Lecture Notes in Computer Science, Springer-Verlag.

[Hun87] Warren A. Hunt, Jr. The Mechanical Verification of a Microprocessor Design. Technical Report 6, Computational Logic Incorporated, Austin, TX, 1987.

[ICRE94] ICRE ’94 (Proceedings of the First International Conference on Re- quirements Engineering), Colorado Springs, CO, April 1994. IEEE Computer Society.

[ICR1396] IG’RE ’96 (Proceedings of the Second International Conference on Re- quirements Engineering), Colorado Springs, CO, April 1996. IEEE Computer Society.

[ID93] C. Norris lp and David L. Dill. Better Verification through Symmetry. In CHDL ’93: Ilth Conference on Computer Hardware Description

Languages and their Applicationsj pages 87-100. IFIP, 1993. Ottawa, Canada.

[ID96a] C. Norris 1P and David L. Dill. State Reduction Using Reversible Rules. In Proceedings of the 33rd Design Automation Conference, pages 564- 567, Las Vegas, NV, June 1996.

[ID96b] C. Norris Ip and David L. Dill. Verifying Systems with Replicated Components in Murphi. In Alur and Henzinger [AH96], pages 147-158.

[IEEE194] Software Development, IEEE Standard 1498. IEEE Publications OfFice, Los Alamitos, CA, March 1994. Interim Standard.

[1s088] LO TOS-- A Formal Description Technique Based on the Temporal Ordering of Observational Behavior. International Organization for Standardization- Information Processing Systems-– Open Systems In- terconnection, Geneva, Switzerland, September 1988. 1S0 Standard 8807.

[ISSTA96] ISSTA ’96 (Proceedings of the 1996 Symposium on Software Testing and Analysis), San Diego, CA, January 1996. Association for Computing Machinery. NASA-GB-001-97 151

[Jac95] M. Jackson. Software Requirements and Specifications, a lexicon of practice, principles and prejudices. ACM Press Books. Addison-Wesley, Reading, MA, 1995.

[Jon90] Cliff B. Jones. Systematic Software Development Using ITDA4. Prentice Hall International Series in Computer Science. Prentice Hall, Hemel Hempstead, UK, second edition, 1990.

[Kay91] Richard Kaye. Models of Peano Arithmetic. Number 15 in Oxford Logic Guides. Oxford University Press, Oxford, England, 1991.

[KB70] D. E. Knuth and P. B. Bendix. Simple Word Problems in U-niversal Algebras. In Computational Problems in Abstract Algebra, pages 263- 297. Pergamon Press, Oxford, UK, 1970. Reprinted in Automation of Reasoning 2 (Springer-Verlag, Berlin, 1983) 342-376.

[KM94] Matt Kaufmaun and J Strother Moore. Design Goals for ACL2. Tech- nical Report 101, Computational Logic, Inc., Austin, TX, August 1994.

[KM96] Matt Kaufmann and J Strother hloore. ACL2: An Industrial Strength Version of Nqthrn. In COMPASS ’96 (Proceedings of the Eleventh An- nual Conference on Computer Assurance), pages 23-34, Gaithersburg, MD, June 1996. IEEE Washington Section.

[Knu86] Donald Knuth. Computers & Typesetting / A: The Z!wook. Addison- Wesley, Reading, MA, 1986.

[Kow88] R. A. Kowalski. The Early Years of I,ogic Programming. Comnlunica- tions of the ACM, 31 (1):38- 42, 1988.

[Koz83] Dexter Kozen. Results on the Propositional p-Calculus. Theoretical Computer Science, 27:333-354, 1983.

[Kri63a] Saul Kripke. Semantical Analysis of Modal Logic I, Normal Proposi- tional Calculi. Zeitschrijt fir Mathematische Logik und Grundlagen der Mathematik, 9:67-96, 1963. VEB Deutscher Verlag der Wissenschaften, Berlin.

[Kri63b] Saul Kripke. Semantical Considerations on Modal Logic. Acts Philo- sophic Fennica, 16:83--94, 1963.

[Kri65] Saul Kripke. Semantical Analysis of Modal Logic II, Non-Normal Modal Propositional Calculi. In J. JtT. Addison, L. Henkin, and A. Tarski, editors, The Theory of Models, pages 206-220. North-Holland, Amster- dam, 1965. 152 References

[Kro93] K. Kronof, editor. Method Integration: Concepts and Case Studies. John Wiley 8z Sons, New York, NY, 1993.

[KSH92] John C. Kelly, Joseph S. Sherif, and Jonathan Hops. An Analysis of De- fect Densities Found During Software Inspections. Journal of Systems Software, 17:111-117, 1992.

[KTB88] B. Konikowska, A. Tarlecki, and A. 131ikle. A Three-Valued Logic for Soft ware Spccificat ion and Validation. In R. Bloomfield, L. Mar- shall, and R. Jones, editors, VDiVf ’88: VDi14 — The Wap Ahead, pages 218-242. Nutnber 328 in Lecture Notes in Computer Science, Springer- Verlag, 1988.

[Kur94] Robert P. Kurshan. Conqmter-Aided Verification oj Coordinating Pro- cesses. Princeton Series in Computer Science. Princeton lJniversity Press, Princeton, NJ, 1994.

[KZ89] D. Kapur and H. Zhang. An Overview of Rewrite Rule Laboratory (RRL). In Proceedings of the Third International Conference on Rewrit- ing Techniques and Applications, pages 559-563, Chapel Hill, hTC, 1989. Number 355 in Lecture hTotes in Computer Science, Springer-Verlag.

[LA94] R. Lutz and Y. Ampo. Experience Report: Using Forlnal hlethods for Requirements Analysis of Critical Spacecraft Software. In Proceed- ings of the Nineteenth Annual Software Engineering Workshop, NASA Goddard Space Flight Center, Greenbelt, MD, December 1994.

[Lan189] Leslie Lamport. A Simple Approach to Specifying Concurrent Systems. Communications of the ACM, 32(1):32- 45, January 1989.

[I,an195] Leslie Larnport. Types are not Harmless, July 1995. http: //www.researcll. digital. col~l/SRC/tla/tla. html (under Related Issues).

[Lan96] Christopher Landauer. Discrete Event Systems in Rewriting Logic. In J. Meseguer, editor, First International Workshop on Rewriting Logic and its Applications, pages 309-320. Elsevier Science B .V., September 1996. Elect ronic Notes in Theoretical Computer Science, Volume 4.

[Lev79] Azriel Levy. Basic Sef Theory. Perspectives in Mathematical Logic. Springer-Verlag, Berlin, Germany, 1979.

[LFB96] Peter Germ Larsen, John Fitzgerald, and Tom Brookes. Applying For- mal Specification in Industry. IEEE Software, 13(3):48-56, May 1996. NASA-GB-001-97 153

[LG96] K. Lano and S. Goldsack. Integrating Formal and object-oriented” hfethods: The VI)M+ + Approach. In 2nd Methods lrztegration Wont- shop, Leeds, UK, 1996. To appear in Springer-Verlag EWTC Series.

[LHHR94] Nancy G. Leveson, Mats Per Erik Heimdahl, Holly Hildreth, and Jon Damon Reese. Requirements Specification for Process-Control Systems. IEE13 Transactions on Software Engineering, 20(9):684-707, September 1994.

[Lin94] Richard Linger. Cleanroom Process Model. IEEE Software, 11(2):50- 58, March 1994.

[L088] E. Lusk and R. Overbeck, editors. 9th International Conference on Au- tomated Deduction (CADE), volume 310 of Lecture Notes in Computer Science, Argonne, IL, May 1988. Springer-Verlag.

[LPPU94] M. Lowry, A. Philpot, T. Pressburger, and I. Underwood. A Ilanle- work for Distributed System Designs. In Proceedings, KBSE ’94, The Ninth Knowledge-llased Software Engineering Conference, pages 48-57, Monterey, California, September 1994. IEEE Computer Society Press.

[LR93a] Patrick Lincoln and John Rushby. Formal Verification of an Algorithm for Interactive Consistency under a Hybrid Fault Model. NASA Con- tractor Report 4527, NASA Langley Research Center, Hampton, 17A, July 1993.

[1.R93b] Patrick Lincoln and John Rushby. Formal Verificatio~l of an Algorithm for Interactive Consistency under a Hybrid Fault Model. In Courcou- betis [COU93], pages 292-304.

[LSB92] R. I,etz, J. Schumann, and S. Bayerl. SE’THEO: A IIigh-Perfornlance Theorem Prover. JournaZ of Automated Reasoning, 8(2):183-212, 1992.

[I,SVW96] N. Lynch, R. Segala, F. Vaandrager, and H. B. Weinberg. Hybrid 1/0 Automata. In Alur et al. [AHS96], pages 496---510.

[Lut93] Robyn R. Lutz. Analyzing Software Requirements Errors in Safety- Critical Embedded Systems. In IEEE International Symposium on Re- quirements Engineering, pages 126-133, San Diego, CA, January 1993.

[Lyn96] N. Lynch. Modeling and Verification of Automated Transit Systems, using Timed Automata, Invariants, and Simulations. In Alur et al. [AHS96], pages 449 -463.

[Mac95] Donald MacKenzie. The Automation of Proof: A Historical and Socio- logical Exploration. IEEE Annals of the Historg of Computing, 17(3):7- 29, Fall 1995. 154 References

[Man94] Z. Manna. Beyond Model Checking. In Dill [Di194], pages 220-221.

[MC85] B. Mishra and E. hl. Clarke. Hierarchical Verification of Asynchronous Circuits Using Temporal Logic. Thecmeticat Computer Science, 38:269- 291, 1985.

[MC94] A. Moreira and R. Clark. Combining Object-Oriented Analysis and Formal Description Techniques. In Tokoro and Pareschi [TP94], pages 344-364.

[Mc195] A. McIver. Why Be Formal. New Scientist Magazine, pages 34-38, 1995. 26 August.

[MCM93] Kenneth L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, Boston, MA, 1993.

[Mi189] R. hlilncr. Communication and Concurrency. Prentice Hall Interna- tional Series in Computer Science. Prentice Hall, Hemel Hernpstead, UK, 1989.

[Mi193] H. D. Mills. Zero Defect Software: Cleanroom Engineering. In Advances in Computers, volume 36, pages 1-41. 1993.

[Min95] Paul S. Miner. Defining the IEEE-854 Floating-Point Standard in PVS. NASA Technical Memorandum 110167, NASA Langley Research Cen- ter, Hampton, VA, June 1995.

[ML96] Paul S. h4iner and James F. Leathrum, Jr. Verification of IEEE Compli- ant Subtractive Division Algorithms. In Mandayarn Sriv&s and Albert Camilleri, editors, Formal Methods in Computer-Aided Design (FM- CAD ‘96), pages 64-78, Palo Alto, CA, November 1996. Volume 1166 of Lecture Notes in Computer Science, Springer-Verlag.

[MLR+96] F. hflodugno, N. Leveson, J. Reese, K. Partridge, and S. Sandys. In- tegrated Safety Analysis of Requirements Specifications. I)raft, May 1996.

[MMU83] MA4U Systems Data Book. NASA Mh!fU-SE17-73, revision: Basic edition. JUIW 1983. Volume 1 of MMU Operational Data Book.

[MOS85] Ben hloszkowski. A Temporal Logic for Multilevel Reasoning about Hardware. Il;I~E Computer, 18(2):10 19, 1985.

[MPJ94] Paul S. hlincr, Shyamsundar Pullela, and Steven D. Johnson. Interac- tion of Formal Design Systems in the Development of a Fault-Tolerant Clock Synchronization Circuit. Technical Report 405, Conlputer Sci-

ence Depart mcnt, Indiana University, Bloomingtonj IhT, April 1994. NASA-GB-001-97 155

[MS95] Steven P. Miller and Mandayam Srivas. Formal Verification of the AAMP5 Microprocessor: A Case Study in the Industrial Use of Formal Methods. In WIFT ’95: Workshop on Industrial-Strength Formal Speci- fication Techniques, pages 2-16, Boca Raton, FL, 1995. IEEE Computer Society.

[MUS80] D. R. hlusser. Abstract Data Type Specification in the Affirm System. IEEE Transactions on Software Engineering, 6(1):24- 32, January 1980.

[MW90] Carroll Morgan and J. C. P. Woodcock, editors. Springer-Verlag Work- shops in Computing, January 1990.

[MW95] P. Mukherjee and B. Wichmann. Formal Specification of the STV Al- gorithm. In Hinchey and 130wen [HB95a], pages 73-96.

[NASA-92] NASA Software Assurance Standard. NASA Office of Safety and h4is- sion Assurance, November 1992.

[NASA-93a] NASA Sojtware Formal Inspections Standard. NASA Engineering Di- vision Publication, 1993.

[NASA-93b] NASA Software Formal Inspections Guidebook. NASA Office of Safety and h~ission Assurance, August 1993.

[NASA-95a] Formal il!ethods Specification and Verification Guidebook jor Software and Computer Systems, Volume I: Planning and Technology Insertion. NASA Oflice of Safety and Mission Assurance, Washington, DC, July 1995. NASA-G13-002-95, Release 1.0.

[NASA-95b] NASA Software Strategic Plan. National Aeronautics and Space Ad- ministration, July 1995.

[NASA-96] NASA Guidebook for Safety Critical Software Analysis and Develop- ment. NASA Office of Safety and Mission Assurance, April 1996.

[NASA93] Formal Methods Demonstration Project for Space Applications - Phase I Case Study: Space Shuttle Orbit DAP Jet Select. Multi-Center NASA Team from Jet Propulsion Laboratory, Johnson Space Center, and Lan- gley Research Center, December 1993. NASA Code Q Final Report (Unnumbered).

[Nay95] P. Pandurang Nayak. Automated Modeling of Physical Systems. ACM Distinguished Theses. SV, Berlin, Germany, 1995.

[N079] G. Nelson and D. C. Oppen. Simplification by Cooperating Decision Procedures. ACM Transactions on Programming Languages and Sys- tems, 1(2):245-257, 1979. 156 References

[olt95] Walter Olthoff, editor. 9th European Conference on Object-Oriented Programming (ECOOP ‘95), volume 952 of Lecture Notes in Computer Science, Aarhus, Denmark, August 1995. Springer-Verlag.

[ORSVH95] Sam Owrc, John Rushby, Natarajau Shankar, and Friedrich von Henke. Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering, 21(2):107-125, February 1995.

[OSR93a] S. Owre, N. Shankar, and J. M. Rushby. The PVS Specification Lan- guage. Computer Science I,ahoratory, SRI International, Menlo Park, CA, February 1993. A new edition for PVS Version 2 is expected in 1997.

[OSR93b] S. Owre, N. Shankar, and J. M. Rushby. User Guide for the PITS Specification and Verification System. Computer Science Laboratory, SRI International, Menlo Park, CA, February 1993. Three volumes: Language, System, and Prover Reference Manuals; A new edition for PILS Version 2 is expected in late 1997.

[Par70] D. M. R. Park. Fixpoint Induction and Proofs of Program Properties. Machine Intelligence, 5, 1970.

[Par76] David Park. Finiteness is Mu-Ineffable. Theoretical Computer Science, 3:173-181, 1976.

[Par91] David L. Parnas. Proposed Standard for Computers in the Safety Systems oj Nuclear Power Stations. Telecommunications Research Institute of Ontario (TRIO), Queen’s University, Kingston, Ontario, Canada, March 1991.

[Par95] D. L. Parnas. Using Mathematical Models in the Inspection of Critical Software. In Hint.hey and Bowen [HB95a], pages 17-31.

[Pau84] L. C. Paulson. Verifying the Unification Algorithm in LCF. Technical Report 50, University of Cambridge Computer Laboratory, Cambridge, UK, 1984.

[Pau88] Lawrence C. Paulson. Isabelle: The next seven hundred theorem provers. In Lusk and Overbeek [1,088], pages 772-773.

[Pau91] L. C. Paulson. ML for the Working Programmer. Cambridge University Press, Cambridge, UK, 1991.

[Pau92] Lawrence C. Paulson. Designing a Theorem Prover. In S. Abramsky, Dov M. Gabbay, and T. S. E. Maibaum, editors, Handbook oj Logic in NASA-GB-001-97 157

Computer Science; Volume 2 Background: Computational Structures, pages 415-475. Oxford Science Publications, Oxford, UK, 1992.

[Pau97] L. C. Paulson. Generic Automatic Proof Tools. In R. Veroff, editor, Automated Reasoning and Its Applications. The MIT Press, 1997. To appear.

[Pauls] ht tp://w’ww.cl.canl. ac.uk/users/lcp/hotlist #Systems.

[Pe193] I). Peled. All from One, One for All, on Model-Checking Using Repre- sent at ives. In Courcoubet is [COU93], pages 409-423.

[Pc!194] 1). Peled. Combining Partial Order Reductions with On-the-fly Model- Checking. In Dill [Di194], pages 377-390.

[Per90] Dominique Perrin. Finite Automata. In van Leeuwen [1L90], chapter 1, pages 1-57.

[Phf91] David L. Parnas and Jan Madey. Functional Documentation for Computer Systems Engineering (Version 2). Technical Report TRIO- CRL 237, Telecommunications Research Institute of Ontario (TRIO), Queen’s University, Kingston, Ontario, Canada, September 1991.

[Pnu77] A. Pnueli. The Temporal Logic of Programs. In P7>OC. 18th Sympo- sium on Foundations of Computer Science, pages 46-57, Providence, RI, hTovember 1977. ACM.

[PPV60] I). Prawit z, H. Prawitz, and NT. Voghera. A Mechanical Proof Proce- dure and its Realization in an Electronic Computer. Journal of the Association for Computing Machinery, 7:102-128, 1960.

[QS82] J. 1’. Queille and J. Sifakis. Specification and Verification of Concurrent Systems in Cesar. In Proc. 5th International Symposium on Program- ming. pages 337--351, Turin, Italy, April 1982. Volume 137 of Lecture Notes in Computer Science, Springer-Verlag.

[QueS2] J. P. Queille. Le Syst6me CLsar: Description, Specification et Analyse des Applications R&parties. PhD thesis, Computer Science Department, University de Grenoble, June 1982.

[Rat97] UML Documentation. Rational Software Corporation, Santa Clara, CA, 1997. Several documents, including “UML Summary”, “UhlL Notation Guide”, and “UML Semantics” are available via the URL http: //www.rational. conl/uml. 158 References

[R1391] J. Rumbaugha ndM.Blaha.T utorialNotes: Object-Orientecl Modeling and Design. In OOPSLA ’91 (Object-Oriented Programming Systems, Languages, and Applications 1991) Conference Proceedings, Phoenix, AZ, October 1991. Communications of the ACM.

[RB96] Larry W. Roberts and Mike 13eitns. Using Formal Methods to Assist in the Requirements Analysis of the Space Shuttle HAC Change Request (CR90960E). JSC Technical Report, Loral Space Information Systems, Houston, TX, September 1996.

[RBP+”91] James Rumbaugh, hflichael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object-Oriented Modeling and Design. Prentice Hall, Euglewood Cliffs, NJ, 1991.

[RE80] B. Razouk and C. Estrin. Modeling and Verification of Communica- tion Protocols in SARA: the X.21 interface. IEEE Transactions on Computers, C-29(12):1038- 1052, 1980.

[RE93] RE ’93 (Proceedings of the IEEE International Symposium on Require- ments Engineering), San Diego, CA, January 1993. IEE,E Computer Society.

[RE95] RE ’95 (Proceedings of the IEEE International Symposium on Require- ments Engineering), York, England, March 1995. IEEE Computer So- ciety.

[Res69] N. Rescher. Many- Valued Logic. McGraw-Hill, New York, NY, 1969.

[RG92] K.S. Rubin and A. Goldberg. Object Behavior Analysis. Communica- tions of the A CM, 35(9):48- 62, September 1992.

[Rob65] J. A. Robinson. A Machine-Oriented Logic Based on the Resolu- tion Principle. Journal of the Association for Computing Machinery, 12(1):23-41, January 1965.

[Roc91] Space Shuttle Orbiter Operational Level C Functional Subsystem Soft- ware Requirements: Guidance Navigation and Control–Part C Flight Control Orbit DA P. Rockwell International, Space Systems Division, 01-21 edition, February 1991.

[RSS95] S. Rajan, N. Shankar, and M.K. Srivas. An Integration of Model- Checking with Automated Proof Checking. In Pierre Wolper, editor, Computer-Aided Verification, CA V ’95, pages 84-97, Liege, Belgium, June 1995. Volume 939 of Lecture Notes in Computer Science, Springer- Verlag. NASA-GB-001-97 159

[RT52] J. B. Rosser and A. R. Turquette. Many- Valued Logics. North-Holland, Amsterdam, Holland, 1952.

[Rus92] John Rushby. Formal Verification of an Oral Messages Algorithm for interactive Consistency. ‘Technical Report SRI- CSL-92- 1, Computer Science Laboratory, SRI International, Menlo Park, CA, July 1992. Also available as NASA Contractor Report 189704, October 1992.

[Rus93a] John Rushby. Formal Methods and Digital Systems Validation for Air- borne S@ems. Federal Aviation Administration Technical Center, At- lantic City, ATJ, 1993. Forthcoming chapter for “Digital Systems Vali- dation Handbook,” DOT/FAA/CT-88/10.

[Rus93b] John Rushby. Formal Methods and Digital Systems Validation for Air- borne Systems. Technical Report SRI-CSL-93-7, Computer Science Laboratory, SRI International, Menlo Park, CA, December 1993. Also available as NASA Contractor Report 4551, December 1993.

[Rus96] John Rushby. Automated Deduction and Formal Methods. In Alur and Henzinger [AH96], pages 169-183.

[RVH93] John Rushby and kliedrich von Henke. Formal Verification of Algo- rithms for Critical Systems. IEEE Transactions on Software Engineer- ing, 19(1):13–23, January 1993.

[RW69] G. Robinson and L. Wos. Paramodulat ion and Theorenl-Proving in First Order Theories with Equality. In Machine Intelligence, Edin- burgh, Scotland, 1969. Volume 4, Edinburgh University Press.

[SAFER92] Project Requirements Document for the Simplified Aid for EVA Rescue (SAFER) Flight Test Project, December 1992. NASA JSC-24691.

[SAFER94a] Simplified Aide for EVA Rescue (SAFER). NASA JSC-26283, Septem- ber 1994. Operations hflanual.

[SAFER94b] Simplified Aid for EVA Rescue (SAFER) Flight Test Project - Flight Test Article Prime Item Development Specification, July 1994. NASA JSC-25552.

[S1369] I). Scc)tt and J. W. De Bakker. A Theory of Programs. Unpublished Manuscript. IBM. Vienna, 1969.

[SBC92] Susan Stepney, Rosalind Barden, and David Cooper, editors. Object Orientation in Z. Workshops in Computing. Springer-Verlag, 1992. 160 References

[SD96] UIrich Stern and David L. Dill. A New Scheme for Menlory-Efficient Probabilistic Verificatioll. 111 Proceedings ojthe IFIP TC6/WG6.l Joint International Coltferenee on Formal Description Techniques jor Ilis-

tributed Systems and Communications Protocolsj and Protocol Specifi- cation, Testing and Verification, 1996. To appear.

[SE87] Sofiware Engineering Standards. Institute of Electrical and 131ectronics Engineers, Inc., New York, NY, 1987.

[SG96] D.R. Smith and C.C. Green. Toward Practical Applications of Soft- ware Synthesis. In Fh!SP ’96, The First Iirorkshop on Formal Methods in Software Practice, pages 31-39, San Diego, CA, January 1996. As- sociation for Computing Machinery.

[SH94] S. Sankar and R. Hayes. Specifying and Testing Software Components Using ADL. Technical Report SMLI TR-94-23, Sun Microsystems Lab- oratories, Inc. (SMLI), Mountain View, CA, April 1994.

[Sha93] N. Shankar. Abstract Datatypes in PVS. Technical Report SRI-CSL- 93-9, Computer Science Laboratory, SRI International, Menlo Park, CA, December 1993.

[Sha94] AT. Shankar. A!etamathematics, Machines, and Godel’s Proof. Cam- bridge Tracts in Theoretical Computer Science. Cambridge University Press, Cambridge, UK, 1994.

[Sha96] Natarajan Silankar. Unifying Verification Paradigms. In Bengt Jon- sson and Joachim Parrow~, editors, Formal Techniques in Real-Time and Fault- Tolerant Systems, pages 22-39, Uppsala, Sweden, September 1996. Volume 1135 of Lecture Notes in Computer Science, Springer- Verlag.

[Sho67] Joseph R. Shoenfield. Mathematical Logic. Addison-Wesley, Reading, MA, 1967.

[Sho78a] J. R. Shoenfield. Axioms of Set Theory. In Jon Barwise, editor, Hand- book of Mathematical Logic, volume 90 of Studies in Logic and the Foun- dations of Mathematics, chapter B], pages 321-344. North-Holland, Amsterdam, Holland, 1978.

[Sho78b] Robert E. Shostak. An Algorithm for Reasoning about Equality. Cmn- munications oj the ACM, 21(7):583- 585, July 1978.

[SM91] S. Shlaer and S. Mellor. Object-Oriented Systems Analysis: Modeling the World in Data. Yourdon Press Computing Series. Prentice Hall, Englewood Cliffs, NJ, 1991. hM4-GB-001-97 161

[SM95a] Mandayam Srivas and Steven P. Miller. Formal Verification of a Con~- mercial Microprocessor. Technical Report SRI-CSL-95-4, Computer Science Laboratory, SRI International, Menlo Park, CA, February 1995. Also available under the title Formal Verification of an Avionics J4i- croprocessor as NASA Contractor Report 4682, July, 1995.

[SM95b] Mandayam K. Srivas and Steven P. Miller. Formal Verification of the AAMP5 Microprocessor. In Hinchey and Bowen [HB95a], chapter 7, pages 125-180.

[Snli90] D.R. Smith. KIDS: A semiautomatic program dev(!lopment system. IEEE Transactions on Software Engineering, SE-16(9):1024- 1043, 1990.

[SOR93] N. Shankar, S. Owre, and J. M. Rushby. The P VS Proof Checker: A Reference Manual. Computer Science Laboratory, SRI International, Menlo Park, CA, February 1993. A new edition for PVS Version 2 is expected in late 1997.

[Spi88] J. M. Spivey. Understanding Z: A Specification Language and its Fbr- mal Semantics. Cambridge Tracts in Theoretical Computer Science 3. Cambridge University Press, Cambridge, UK, 1988.

[ss86] Leon Sterling and Ehud Shapiro, editors. The Art of Prolog. MIT Press Series in Logic Programming. The MIT Press, 1986.

[Sti86] M. E. St ickel. A Prolog Technology ~’heorem Prover. III J. H. Sieknlalln, editor, 8th International Conference on Automated Deduction (CADE), pages 573-587, Oxford, England, July 1986. Volume 230 of Lecture Notes in Computer Science, Springer-Verlag.

[SYS92] ParcPlace Systems. Object-Oriented Methodology Course Notes. Parc- Place Systems, Inc., Sunnyvale, CA, 1992.

[Talco] http: //www-formal.stal~ford. edu/clt/ARS/ars-db. htnll. Follow the link “Existing systems, related fields/pages, archives, . . . .“.

[Tar55] Alfred Tarski. A Lattice-Theoretical Fixpoint Theorem and its Appli- cations. Pacific Journal of Mathematics, 5:285–309, 1955.

[Tar76] Alfred Tarski. Introduction to Logic and to the Methodology of Deductive Sciences. Oxford University Press, New York, NY, third edition, 1976. First published 1941.

[Tho84] Richmond H. Thomason. Combinations of Tense and Modality. In Gabbay and Guenthner [G G84], chapter 11.3, pages 135--165. 162 References

[Tho90] Wolfgang ThOnlas. Automata on Infinite Objects. In van Leeuwen [vL90], chapter 4, pages 133--187.

[TP94] M. Tokoro and R. Pareschi, editors. 8th European Conference on Object- Oriented Programming (ECOOP ‘94), volume 821 of Lecture Notes in Com@er Science, Bologna, Italy, July 1994. Springer-Verlag.

[Urq86] A. Urquhart. Many-Valued Logic. In Dov hfl. Gabbay and Franz Guenthner, editors, Handbook of Philosophical Logic- Volume III: Al- ternatives to Classical Logic, Synthese Library, pages 71-116. D. Reidel Publishing Company, Dordrecht, Holland, 1986.

[Va190] A. Valmari. A Stubborn Attack on State Explosion. In Clarke and Kurshan [CK90], pages 25-42.

[vB88] Johan van Benthem. Time, Logic and Computation. In J.W. de Bakker, W.-P. de Roever, ancl G. Rozenberg, editors, Linear Time, Branching Time and Partial Order in Logics and Models for Concurrency, pages 1-49, Noordwijkerhout, The Netherlands, May/June 1988. Volume 354 of Lecture Notes in Computer Science, Springer-Verlag.

[vBD83] Johan van Bentham and Kees Doets. Higher-Order Logic. In Gabbay and Guenthner [GG83], chapter 1.4, pages 275--329.

[v13J79] L. S. van Benthem Jutting. Checking Landau’s ‘Grundlagen’ in the Au- tomath System. Technical report, Mathematical Centre, Amsterdam, 1979. Mathematical Centre Tracts.

[VDM] http: //lt’WW.ifad.dk/vdnl/vdn~.htnd.

[vL90] Jan van Leeuwen, editor. Handbook of Theoretical Computer Science, volume B: Formal Models and Semantics. Elsevier and MIT press, Amsterdam, The Netherlands, and Cambridge, MA, 1990.

[VS90] A. John van Schouwen. The A-7 Requirements Model: Re-Examination for Real-Time Systems and an Application to Monitoring Systems. Technical Report 90-276, Department of Computing and Information Science, Queen’s University, Kingston, Ontario, Canada, May 1990.

[vSPM93] A. John van Schouwen, David Lorge Parnas, and Jan Madey. Docunlen- tation of Requirements for Computer Systems. In IEEE International Symposium on Requirements Engineering, pages 198-207, San Diego, CA, January 1993.

[VW86] hf. Vardi and P. Wolper. An Autonlata-Theoretic Approach to Auto- matic Program Verification. In lstAnnual IEEE Symposium on Logic in Computer Science, Boston, MA, June 1986. IEEE Computer Society. NASA-GB-001-97 163

[Wan60a] H. Wang. Proving Theorems by Pattern Recognition. Commtinica tions oj the AClt4, 4(3):229 -243, 1960.

[Wan60b] H. Wang. Toward Mechanical Mathematics. IBM Journal of Research and Development, 4:2-21, 1960.

[WB93] Trevor Williams and David Baughman. Exploiting Orbital EfTects for Short-Range Extravehicular Transfers. In AA S/AIAA Spacefiight A4e- chanics Meeting, Pasadena, CA, 1993. American Astronautical Society.

[WB94J Trevor Williams and David Baughman. Self-Rescue Strategies ‘for EVA Crewmembers Equipped with the SAFER Backpack. In Proceedings of the Goddard Flight h4echanics/Estintation Theory Symposium, May 1994. Paper 28.

[Wes78] C. H. West. General Technique for Communications Protocol Valida- tion. IBM Journal of Research and Development, 22(3):393- 404, 1978.

[Win90] J. M. Wing. A Specifier’s Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September 1990.

[WM85] P. T. Ward and S. J. Mellor. Structured Development for Real-Time Systems. Prentice Hall, Englewood Cliffs, NJ, 1985.

[WOLB92] Larry Wos, Ross Overbeek, Ewing Lusk, and Jim Boyle. Automated Reasoning: Introduction and Applications. McGraw-Hill, New York, NY, second edition, 1992. Includes a copy of the Otter theorem prover for IBM-PCs.

[Wor92] J. B. Wordsworth. Software Development with Z. Addison-Wesley, Wokingham, England, 1992.

[WSJGJMW93] John V. Guttag and James J. Horning with S. J. Garland, K. D. Jones, A. Mc)det, and J. hl. Wing. Larch: Languages and Tools for Formal Specification. Texts and Monographs in Computer Science. Springer- Verla.g, 1993.

[WZ78] C. H. West and P. Zafiropulo. Automated Validation of a Communi- cations Protocol: the CCITT X.21 Recommendation. IBM Journal oj Research Development, 22(1):60--71, 1978.

[Yoe90] Michael Yoeli, editor. Formal Verification of Hardware Design. IEEE Computer Society, I,os Alamitos, CA, 1990.

[YOU95] William D. Young. Modelling and Verification of a Simple Real-Time Railroad Gate Controller. ]n Hinchey and Bowen [HB95a], chapter 8, pages 181-201. References 164

[Zav95] Pamela Zave. Classification of Researcl~ Efforts in Requirements Engi- neering. In RF, [RE95], pages 214-216. Appendix A

Glossary of Key Terms

This appendix contaim an alphabetized list of the acronynls aud key terms used in tbc body of the Guidebook.

AAH: Automatic Attitude llold CEA: Control Electronics Assembly of the MMLJ CTL: ~onl~)utational ‘Tree Logic DCU: Display and control Unit, DRA: Data Itccordcr Assembly EMU: Extrave]licular Mobility lJnit EVA: Extravehicular .Activity FOL: F’irst-Order (1’rcdicate) Logic FSSR: Nmctio)lal Subsystem Software Requirements GPS: Global l)ositioning System HCM: Hand Controller hlodule HCU: IIatld Cc)ntroller Unit HHh!IU: Hand Held klaueuverillg Unit IRU: Inertial Referellce Unit LCD: Liquid Crystal I)isl)lay LED: Light E1nit ti118 Diode LTL: Linear Temporal Logic MIR: Mode Identificatioll and Reconstruction MMU: Manned hfaneuvering Unit OMT: Object h[odeling !khtliquc PLSS: Primary Life Su~)])ort Subsystem PSA: Power Sup~)ly Assembly PVS: Prototype Verification System

165 166 Appe:lclix- A

RHC: Rotational Iland Control of the i14hNJ ROT: Rotational SAFER: Simplified Aid for E\7A SCR: Software Cc)st Reduction (Methodology) TCC: Type Correctness Collditions THC: Translational Hand Control of the MMLJ TRAN: Translational VDA: Valve Drive Assemblies

A.2 Terms]

Assurance: T~lose activities that demonstrate the conformance of a product or IMocess to a slwcified criterion such as a functional requirement. Quality assurance refers to those activities that focus particularly on conformance to standards or ~}roccdures [NASA-92]. axiom: A statement or well-formed formula that is stipulated or assumed rather than proved to be true through the ap~)lication of rules of inference. The axioms and the rules of inference togetlwr provide a basis for proving all other theorems. Axioms are typically identified as logical or ~wnlogical. The latter deal with specific domain information, while the former characterize logical properties. A given formal system may have several (different) azion~atization

1 Material from [DN’89] has been used in SOItle of the fo)low’ing definitions NASA-GB-001-97 167 functional: A function that takes a set of functionsas domain and asct of functions as range. For cxanqdc$ tllc differential operator d/d~ is a functional of differentiable functions j(x). model: (1) In logic, an iuterprctation, 1, of a set of wwll-formed formulas of a formal language such that, czacll men~bcr of the set is true in 1. (2) A system of definitions, assumptions, and equations set u]) to rc~)rescnt a~ld discuss physical phenomena and S-ystcms. model theory: The study of the interpretations (nlodels) of fornlal systenls, especially the notions of logical consequence, validity, co]npleteuess, and soundness. mu-Calculus: !t’hc J1-calculus is a qualltified Boolean logic with least and greatest fixed-point, ol)crators. parsing: A form of analysis that detects syntactic inconsistencies and anomalies, includiug nliss~)elled keywords, ~nissiug deliluiters, and ullbala~lced brackets or lJaren- theses. power set: ‘The ~)ower set of a set A is the set of all sets included in A. If a set has n elements, its power set will have 27~ elements. For example, if a set S = {a, b}, then the power set c)f S, P(S), is the set {0, {a}, {6}, {a, b}}. proof: A chai~l of reasonitlg usiug rules of inference and a set of axioms that leads to a conclusion. proof theory: The study of proofs and provability in forn~al languages, including notions of deducibility, indepcndcuce, sinl~)le conlplctelless, and, particularly, consistency. quantifier: A logical operator that binds a variable in a logical formula and is used to indicate the quantity of a pro~)osition, for example, the univeral quantifier V (read “for all” ), and the ezistentiai quantifier 3 (read “there exists”). requirements: The set of conditions or essential, necessary, or desired capabilities that must be met by a systenl or systenl component to satisfy a cent ract, stalldard, or other forn~ally implied docutnent or description. rule of inference: A rule in logic that deflues the reasoning that determines when a conclusion may be drawn from a set of premises. In a formal system, the rules of inference should guarantee that if the premises are true, then the conclusion is also true. 168 specification (formal): A charackrization of a planned or existing system expressed in a formal la~lguage. testing: Process of exercising or evaluating software by manual or automated mealls to demonstrate that, it satisfies specified requirements or to idc!ntify differences between expected ancl actual results [NASA-92]. trace: A function fronl time to a given ty~jc of ~’alue, where tinle represents, fo~ exanlple, a franle, cycle, or iteration count,. t ypechecking: A fornl of analysis that det ecks semantic inconsistencies and auonlalies, including undeclared naules and anlbiguous types. validation: Tile ~)rocess by which a delivered system is demonstrated to satisfy its requirements by testing it in execution. Informally, dcmonstrat ing that the requirements arc right. verification: The process of deternlining whether each level of a specification, and the final systeln itself, fully alld exclusively itnplements the recluirenlents of its superior specification. Infornlally, demonstrating that a systenl is built according to its requirenlents. Appendix B