Table Of Content

REQUIREMENTS SPECIFICATIONS FOR HYBRID SYSTEMS Constance Heitmeyer Code 5546 Naval Research Laboratory Washington, DC 20375 1 Introduction The purpose of a computer system requirements speci(cid:12)cation is to describe the computer system’s required external behavior. To avoid overspeci(cid:12)cation, the requirements speci(cid:12)cation should describe the system behavior as a mathematical relation between entities in the system’s environment. When some of these entities are continuous and others are discrete, the system is referred to as a \hybrid" system. Although computer science provides many techniques for representing and reasoning about the discrete quantities that a(cid:11)ect system behavior, practical approaches for specifying and analyzing systems containing both discrete and continuous quantities are lacking.The purpose of this paper is to present a for- malframeworkforrepresenting andreasoning about the requirements ofhybrid systems.Asbackground,thepaperbrie(cid:13)yreviewsanabstractmodelforspecify- ing system and software requirements, called the Four VariableModel [12], and a related requirements method, called SCR (Software Cost Reduction) [10, 1]. Thepaperthen introduces aspecial discrete versionofthe FourVariableModel, the SCR requirements model [8] and proposes an extension of the SCR model for specifying and reasoning about hybrid systems. 2 Background 2.1 The Four Variable Model TheFourVariableModel,whichisillustratedinFigure 1,describes therequired system behavior as a set of mathematical relations on four sets of variables| monitored and controlled variables and input and output data items. A monitored variable represents an environmental quantity that in(cid:13)uences system behavior,acontrolledvariableanenvironmentalquantitythatthesystemcontrols. Input devices (e.g., sensors) measure the monitored quantities and output devices set the controlledquantities.The variablesthat the devices read andwrite are called input and output data items. ThefourrelationsoftheFourVariableModelareREQ,NAT,IN,andOUT. The relations REQ and NAT provide a black box speci(cid:12)cation of the required Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 3. DATES COVERED 1996 2. REPORT TYPE 00-00-1996 to 00-00-1996 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Requirements Specifications for Hybrid Systems 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Naval Research Laboratory,Code 5546,4555 Overlook Avenue, REPORT NUMBER SW,Washington,DC,20375 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE 11 unclassified unclassified unclassified Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 System Input Output Monitored Data Data Controlled EnvironmentVariables DIenvpiucets Items Software Items DOeuvtipcuets Variables Environment IN SOFT OUT REQ and NAT Fig.1. Four Variable Model. system behavior. NAT describes the natural constraints on system behavior| thatis,theconstraintsimposedbyphysicallawsandbythesystemenvironment. REQ de(cid:12)nes the system requirements as a relation the system must maintain between the monitored and the controlled quantities. Oneapproachtodescribing therequired systembehavior,REQ,istospecify the ideal system behavior, which abstracts awaytimingdelays and imprecision, and then to specify the allowable system behavior, which bounds the timing delays and imprecision. Typically, a function speci(cid:12)es ideal system behavior, whereas arelationspeci(cid:12)es theallowablesystembehavior.Theallowablesystem behaviorisarelationratherthanafunctionbecauseitmayassociateamonitored variable with more than a single value of a controlled variable. For example, if the system is required to display the current water level, it may be acceptable for the displayed value of water level at time t to deviate fromthe actual value at time t by as much as 0.1 cm. Thesystemrequirementsareeasiertospecifyandtoreasonaboutiftheideal behavior is de(cid:12)ned (cid:12)rst. Then, the required precision and timing can be speci- (cid:12)ed separately. This is standard engineering practice. Moreover, this approach providesanappropriateseparationofconcerns, sincetherequiredsystemtiming and accuracy can change independently of the ideal behavior [3]. The relation IN speci(cid:12)es the accuracy with whichthe input devices measure themonitoredquantitiesandtherelationOUTspeci(cid:12)estheaccuracywithwhich the outputdevices set the controlledquantities.Toachievethe allowablesystem behavior, the input and output devices must measure the monitored quantities and set the controlled quantities with su(cid:14)cient accuracy and su(cid:14)ciently small timingdelays. In the Four Variable Model, the software requirements speci(cid:12)cation, called SOFT, de(cid:12)nes the required relation between the input and output data items.SOFT can be derived fromREQ, NAT, IN, and OUT. 2.2 SCR Requirements Speci(cid:12)cations The SCR requirements method was introduced in 1978 with the publication of the requirements speci(cid:12)cation for the A-7 Operational Flight Program [10, 1]. Since its introduction, the method has been extended to specify system as well as software requirements and to include, in addition to functional behavior, the required systemtimingand accuracy [12,13,14].Designed for use byengineers, { Pressure High {Overridden Mode . Class TooLow Terms . . Permitted Safety Injection System Safety EnvironmentWaBRtleeosrcePktres DDIIeennvvppiiuucceettssSSeSenensnsosoror3r12 Software IDniDjseepvclitaciyeon DODOeueuvtviptcipuceuetstsIDniSjsaepfcletatiyyonEnvironment Device Pres Fig.2. Requirements Speci(cid:12)cation forSafety Injection. the SCR methodhas been successfully applied to avariety ofpractical systems, including avionic systems; a submarine communicationssystem [9]; and safety- criticalcomponentsofanuclear powerplant[14].Morerecently,aversionofthe SCRmethodcalled CoRE[4]wasused todocumentrequirements ofLockheed’s C-130J Operational Flight Program(OFP) [5]. The OFP consists of more than 100K lines of Ada code, thus demonstrating the scalabilityof the SCR method. To represent requirements both abstractly and concisely, SCR speci(cid:12)cations use two special constructs, called mode classes and terms. A mode class is a state machine, de(cid:12)ned on the monitored variables, whose states are called system modes (or simplymodes) and whose transitions are triggered by changes in the monitored variables. Complex systems are de(cid:12)ned by several mode classes operatingin parallel.A termis an auxiliaryfunctionde(cid:12)ned on monitoredvariables,modeclasses, orotherterms.InSCRspeci(cid:12)cations,conditionsandevents are used to describe the system states. A condition is a logical proposition de- (cid:12)ned on a single system state, whereas an event is a logical proposition de(cid:12)ned on a pair of system states. An event occurs when a system entity (that is, a monitoredor controlledvariable,a modeclass,or aterm) changes value.A spe- cialevent, calledan monitored event,occurs when a monitoredvariablechanges value.Anotherspecialevent,calledaconditioned event,occursifaneventoccurs when a speci(cid:12)ed condition is true. To illustrate the SCR method, we consider a simpli(cid:12)ed version of the control system for safety injection described in [2]. The system uses three sensors to monitor water pressure and turns on a safety injection system (which adds coolant to the reactor core) when the pressure falls below some threshold. The system also displays the current value of water pressure. The system operator blockssafetyinjectionbyturningona\Block"switchandresetsthesystemafter blockage by turning on a \Reset" switch. Figure2 shows how SCR constructs are used in specifying the requirements of the control system. Water pressure and the \Block" and \Reset" switches are represented as monitored variables, WaterPres,Block,andReset;safetyinjectionandthedisplayascontrolledvari- ables, SafetyInjection and DisplayPres;each sensor value as an input data item;and the hardware interfaces between the control system software and the safety injection system and the display output as output data items. The speci(cid:12)cation for the control system includes a mode class Pressure, a termOverridden,andseveral conditionsandevents. The modeclass Pressure, Old Mode Event New Mode TooLow @T(WaterPres(cid:21) Low) Permitted Permitted @T(WaterPres(cid:21) Permit) High Permitted @T(WaterPres< Low) TooLow High @T(WaterPres< Permit) Permitted Table 1. Mode Transition Table for Pressure. Mode Events High False @T(Inmode) TooLow, @T(Block=On) @T(Inmode) OR Permitted WHEN Reset=Off @T(Reset=On) Overridden True False Table 2. Event Table for Overridden. an abstract model of the monitored variable WaterPres, contains three modes, TooLow,Permitted,and High.At any giventime,the system mustbe inone of these modes. A drop in water pressure below a constant Low causes the system to enter mode TooLow; an increase in pressure above a larger constant Permit causes the systemtoenter modeHigh.ThetermOverriddendenotes situations inwhichsafetyinjectionisblocked.Anexampleofaconditioninthespeci(cid:12)cation is\WaterPres<Low".Eventsaredenotedbythenotation\@T".Twoexamples ofeventsarethemonitoredevent@T(Block=On)(theoperatorturnsBlockfrom Off to On)and the conditionedevent @T(Block=On)WHEN WaterPres< Low (the operator turns Block to On when water pressure is below Low). SCR requirements speci(cid:12)cations use special tables, called condition tables, event tables, and mode transition tables, to represent the required system be- 1 havior precisely and concisely. Each table de(cid:12)nes a mathematical function. A conditiontable describes acontrolledvariableora termasa functionofamode and a condition; an event table describes a controlled variable or term as a function of a mode and an event. A mode transition table describes a mode as a function of another mode and an event. While condition tables de(cid:12)ne total functions, event tables and mode transition tables may de(cid:12)ne partial functions, because some events cannot occur when certain conditions are true. For example, in the control system above, the event @T(Pressure=High) WHEN Pressure=TooLowcannot occur, because starting from TooLow,the system can only enter Permittedwhen a state transition occurs. Tables1{3 are part of REQ, the requirements speci(cid:12)cation for the control system.Table1isamodetransitiontabledescribingthemodeclassPressureas 1 Although SCRspeci(cid:12)cations can benondeterministic, our initial model is restricted to deterministic systems. Mode Conditions High,Permitted True False TooLow Overridden NOTOverridden Safety Injection Off On Table 3. Condition Table forSafety Injection. a function of the current mode and the monitored variable WaterPres.Table2 is an event table describing the term Overridden as a function of Pressure, Block,andReset.Table3isaconditiontabledescribingthe controlledvariable Safety Injection as a function of Pressure and Overridden. Table3 states, \If Pressure is High or Permitted, or if Pressure is TooLow and Overridden is true, then Safety Injectionis Off; if Pressure is TooLow and Overridden 2 is false, then Safety Injectionis On." 3 SCR Requirements Model To provide a formalfoundation for tools analyzing the speci(cid:12)cations and simu- lating system execution [7, 6], we have developed a discrete version of the Four Variable Model, called the SCR requirements model [8]. The SCR model represents a system as a (cid:12)nite state machine and each monitored and controlled quantityas adiscrete variable.Presented beloware excerpts fromthe de(cid:12)nition of the formalmodel [8] and a description of the interpretation of the REQ and NAT relations within the SCR model. 3.1 Summary of the SCR Model Entitiesand Types. We require the followingsets. { MS is the union of N nonempty, pairwise disjoint sets, M1;M2;:::;MN, called mode classes. 3 { TS is a union of data types, where each type is a nonempty set of values. { VSis a set ofentity values with VS=MS[TS. { RFisasetofentitynamesr,whichispartitioned intothesetofmodenamesMR, the set ofmonitored variable names IR, theset of termnames GR,and the set of controlled variable names OR. For all r 2 RF, TY(r) (cid:18) VS is the type (i.e., the set of possible values) ofentity r. System State and Conditions. A system state s is a function that maps each entity name r in RF to a value. That is, for all r 2 RF: s(r) = v, where v 2TY(r). Conditions are logical propositions de(cid:12)ned on entities in RF. 2 The notation \@T(Inmode)" in a row of an event table describes system entry into the group of modes in that row. 3 For example, the type \nonnegative integers" is the set N = f0;1;2;:::g, the type Boolean is the setB=ftrue;falseg,etc. System and Events. A system is a state machine whose transition from one state to the next is triggered by special events, called monitored events. More m precisely, a system, (cid:6), is a 4-tuple (cid:6) =(E ;S;s0;T); where m { E is a set of monitored events. A primitive event is denoted as @T(r = v), where r 2RF is an entity and v2TY(r). A monitoredeventis a primitive event @T(r=v),where r2IRis a monitored variable. { S is the set of possible system states. { s0 is a special state called the initial state. m { T is the system transform, a function from E (cid:2)S into S. In addition to denoting primitive events, the \@T" notation also denotes conditioned events. A simple conditioned event is expressed as @T(c) WHEN d; where @T(c) is any event (i.e., a change in a state variable) and d is a simple condition or a conjunction of simpleconditions. A conditioned event e is a logical proposition composed of simple conditioned events connected by the logical connectors ^ and _.The proposition represented by a simpleconditioned event is de(cid:12)ned by 0 @T(c) WHEN d = NOT c^c ^d; where the unprimedversionofcrepresents cinone state (the oldstate) andthe primed version of c represents c in another state (the new state). System History Associated with every monitored variable r 2 IR is a set of ordered pairs Vr, 0 0 0 Vr =f(v;v ) j v 6=v ;v2TY(r);v 2TY(r)g; that de(cid:12)nes all possible transitions of r and that contains r’s initial value. A 0 0 monitored event @T(r =v ) is enabled in state s if (s(r);v )2Vr. A history (cid:5) m ofa systemisa functionfromthe set ofnonnegative integers N toE (cid:2)S such that(1)thesecondelementof(cid:5)(0)iss0,(2)foralln2N,if(cid:5)(n)=(e;s),then 0 0 e isenabled ins,and(3)foralln2N,if(cid:5)(n) = (e;s)and(cid:5)(n+1)=(e;s), 0 then T(e;s)=s. m 0 Ordering the Entities. Given an input event e in E , states s and s in S, 0 0 and T(e;s)=s, the value ofeach entityr in state s maydepend on anyentity 0 in the old state s but on only some entities in the new state s. To describe the dependencies of any entity r 2 RF on entities in the new state, we order the entities in RF as a sequence R, R= <r1;r2;:::;rI;rI+1;:::;rK;rK+1;:::;rP>; where < r1;r2;:::;rI >; ri 2 IR, is the subsequence of monitored variables, <rI+1;rI+2;:::;rK>; ri 2GR[MR, is the subsequence containingterms and modes, and <rK+1;rK+2;:::;rP >; ri 2 OR is the subsequence of controlled variables. Modes Conditions m1 c1;1 c1;2 ::: c1;p m2 c2;1 c2;2 ::: c2;p ::: ::: ::: ::: ::: mn cn;1 cn;2 ::: cn;p ri v1 v2 ::: vp Table 4. Typical Format for a Condition Table. 0 0 Theentitiesri 2Rarepartiallyorderedsothatforalli,i,i>I,1(cid:20)i (cid:20)K; the valueof entityri inany state s can onlydepend on the valueof entityri0 in 0 the same state s if i < i. This de(cid:12)nition re(cid:13)ects the fact that each monitored variablecanonlybe changedbyexternal eventsandcannotdepend ontheother entitiesinR.Incontrast, eachtermins candepend onthe monitoredvariables, the modes, or other terms in s. Similarly, each mode in s can depend on the monitored variables, the terms, or other modes in s. Finally, each controlled variablein s can depend on any entity that precedes it in the sequence R. Computing the Transform Function. Each controlled variable, term, and mode class ri 2 RFnIR is de(cid:12)ned by a function Fi. The transform function T computes the new state by composing the Fi’s. In an SCR requirements speci- (cid:12)cation, mostof the Fi’s are described by tables. Table4 shows a typical format for one class of tables, condition tables. A condition table describes an output variable or term ri as a relation (cid:26)i, (cid:26)i =f(mj;cj;k;vk)2M(cid:22)(i)(cid:2)Ci(cid:2)TY(ri) j 1(cid:20)j (cid:20)n;1(cid:20)k (cid:20)pg; where Ci is a set of conditions de(cid:12)ned on entities in RF and M(cid:22)(i) is the mode class associated with ri. The relation (cid:26)i must satisfy the followingproperties: 1. The mj and the vk are unique. n 2. [i=1mj =M(cid:22)(i) (All modes in the mode class are included). p 3. For all j: _k=1cj;k = true (Coverage: The disjunction of the conditions in each row of the table is true). 4. For all j;k;l; k6=l: cj;k^cj;l=false(Disjointness:The pairwise conjunction of the conditions in each row of the table is always false). Giventheseproperties,wecanshowthat(cid:26)i isafunction,whichcanbeexpressed as: for allj;k; 1(cid:20)j (cid:20)n;1(cid:20)k(cid:20)p, (cid:26)i(mj;cj;k)=vk. To make explicit entity ri’s dependencies on other entities, we consider an alternateformFi ofthefunction(cid:26)i.Tode(cid:12)neFi,werequirethenewstatedepen- dencies set,fyi;1;yi;2;:::;yi;nig,where yi;1 is the entity nameforthe associated mode class and for all j, 2 (cid:20) j (cid:20) ni, yi;j appears in some condition c in Ci. Based on this set and (cid:26)i, we de(cid:12)ne Fi as v1 if (yi;1=m1^c1;1)_:::_(yi;1=mn^cn;1) 8v2 if (yi;1=m1^c1;2)_:::_(yi;1=mn^cn;2) Fi(yi;1;yi;2;:::;yi;ni)=>>. <. . >vp if (yi;1=m1^c1;p)_:::_(yi;1=mn^cn;p): >: The four properties guarantee that Fi is a total function. 3.2 The SCR Model, REQ, and NAT NAT. In the SCR model, NAT models the behavior of the monitored and controlled quantities. Consider the monitored variable Block in the example above and let m1 = Block. The type de(cid:12)nition of m1 is TY(m1) = fOff, Ong and the possible changes of m1 from one state to the next are de(cid:12)ned by Vm1 = f(Off, On);(On, Off)g; that is, Block can change from Off to On or from On to Off. Similarly,for the monitored variable m2 = Reset and the controlled variable c1 = SafetyInjection, TY(m2) =TY(c1) = fOff, Ong and Vm2 =Vc1 =f(Off, On);(On, Off)g. The current SCR model describes all monitored and controlled quantities, even those whichare naturallycontinuous,asdiscrete variables.Doingso allows us to represent the system as a (cid:12)nite state machine. This representation facili- tates formalanalysis of the speci(cid:12)cations and symbolicexecution of the system via simulation.For example, to model WaterPres as a discrete variable, we as- sign m3 =WaterPres the type de(cid:12)nition TY(m3) =f14;15;:::;2000g,that is, m3 is any integer between 14 and 2000. We constrain changes in WaterPres by requiring that WaterPres can change from one state to the next by no more than 1 psi, that is, 0 js(m3)(cid:0)s(m3)j2f0;1g; 0 where s and s are any two consecutive states. This assumption implies the statementinSection2.2thatthemodeclassPressurecannottransitiondirectly fromTooLow to High or fromHigh to TooLow.Similarly,we can de(cid:12)ne the type of controlled variable c2 = DisplayPres as TY(c2) = f14;15;:::;2000g and 0 constrain changes in c2 by requiring that, if s and s are any two consecutive 0 states, then js(c2)(cid:0)s(c2)j2f0;1g. Ideal Behavior.In the SCR model,the transformfunction T de(cid:12)nes the ideal system behavior. As noted above, T computes the new state froman event and the current state by composingthe functions Fi that de(cid:12)ne the values of terms, modeclasses,andcontrolledvariables.Clearly,reasoningaboutthe idealsystem behavior using T abstracts awaytimingdelays and imprecision. 4 Extending the SCR Model to Hybrid Systems To use the SCR model to specify and to reason about hybrid systems, we need to extend the modelin two ways: { Eachmonitoredquantityandcontrolledquantitythatisnaturallycontinuous is represented by a continuous (rather than a discrete) variable. { Theallowablesystembehaviorisde(cid:12)ned byassociatingtimingandaccuracy requirements with each controlled variable. 4.1 Adding ContinuousVariables As an example, consider the monitored variable m3 = WaterPres and the controlled variablec2 =DisplayPres. We can de(cid:12)ne m3 as a real number between + 14.0and2000.0,thatis,TY(m3)=fxjx2R ^ 14:0(cid:20)x(cid:20)2000:0g.Physical laws (part of NAT) bound the rate at which m3 can change. To express this bound, we maystate in the speci(cid:12)cation that,in any timeinterval oflength 0.1 seconds, the maximumchange in the value of WaterPresis 0.03 psi; that is, 0 jm3(t)(cid:0)m3(t)j(cid:20):03; 0 when t (cid:0)t = 0:1 sec. The constraints on c2 may be de(cid:12)ned in a similar way. Clearly,theboundscanbeexpressed bymorecomplexfunctions,e.g.,bycontin- uouslydi(cid:11)erentiablefunctions,bypiecewisecontinuousfunctions,orbybounded derivatives. We note that any reasoning that used the discrete models of WaterPres and DisplayPres to analyze system behavior should be reevaluated to make sure the reasoning is still valid when more accurate models of these two natu- rally continuous quantities are used. This is especially importantwhen discrete approximations of continuous quantities are used in verifying critical system properties. 4.2 Adding Time The SCR model introduced in Section 3.1 is untimed. Thus if an event occurs 0 in state s that changes a controlled variable, we assume that the next state s re(cid:13)ects thechangeinthecontrolledvariable(aswellaschangesinthemonitored variablethat triggered the new state and anyresulting changes inmodeclasses, terms,andother controlledvariables).Toaddtimetothe SCRmodel,weadapt theapproachdevelopedbyLynchandVaandrager[11]fortimedautomata.This approach associates each event in a state history with a time. More precisely, for each state history, s0;(e1;s1);(e2;s2);:::, we de(cid:12)ne a sequence of the form (e1;t1);(e2;t2);:::,whereeacheiiseitheramonitoredeventoraneventchanging the value of acontrolled variable and each ti is a non-negative real-valuedtime. Werequire that,foralli,i+1,ti+1 (cid:21)ti andde(cid:12)ne a functionTIME that maps each event e in a system history to a timet, that is, TIME(e)=t. 4.3 Specifying the Actual System Behavior To specify the allowable system behavior, we associate timing and accuracy requirementswitheachcontrolledvariable.Consider,forexample,thecontrolled