DTIC ADA492019: Applying Infinite State Model Checking and Other Analysis Techniques to Tabular Requirements Specifications of Safety-Critical Systems

0.48 MB·English

by  Defense Technical Information Center

Applying Infinite State Model Checking and Other Analysis Techniques
to Tabular Requirements Specifications of Safety-Critical Systems
Tev(cid:2)kBultan Constance Heitmeyer
Department ofComputerScience NavalResearch Laboratory (Code5546)
University ofCalifornia, SantaBarbara Washington, DC20375 USA
SantaBarbara,CA93106 USA
Abstract
Although it is most often applied to finite state models, in recent years, symbolic model checking has
been extended to infinite state models using symbolic representations that encode infinite sets. This paper
investigates the application of an infinite state symbolic model checker called Action Language Verifier
(ALV) to formal requirements specifications of safety-critical systems represented in the SCR (Software
Cost Reduction) tabular notation. After reviewing the SCR method and tools, the Action Language for
representingstatemachinemodels,andtheALVinfinitestatemodelchecker,thepaperpresentsexperimental
results of formally analyzing two SCR specifications using ALV. The application of ALV to verify or falsify
(by generating counterexample behaviors) the state and transition invariants of SCR specifications and to
check Disjointness and Coverage properties is described. The results of formal analysis with ALVare then
comparedwiththeresultsofformalanalysisusingtechniquesthathavebeenintegratedintotheSCRtoolset.
Basedontheexperimental results,strengths andweaknesses ofinfinite statemodelchecking withrespectto
other formal analysis approaches such as explicit and finite state model checking and theorem proving are
discussed.
1 Introduction
Because the cost of (cid:2)xing software errors increases signi(cid:2)cantly if the errors are found late in devel-
opment, detecting software errors as early as possible is crucial. Formal requirements languages such as
RSML (Requirements State Machine Language) [37], a Statecharts variant, and SCR (Software Cost Re-
duction) [28,25],atabular language forspecifying requirements, havebeensuccessfully usedinspecifying
the required behavior of real-world, safety-critical systems such as air traf(cid:2)c control systems and nuclear
power plants. Because formal languages such as RSML and SCR produce precise, unambiguous speci(cid:2)-
cations of the required system behavior, they can expose errors before the errors creep into the software
implementation. Theexplicit formal semantics ofthese languages makes itpossible to useautomated tech-
niques to detect errors in requirements speci(cid:2)cations. By using such techniques, software practitioners can
correct therequirements speci(cid:2)cations earlyindevelopment whenthecostofcorrecting errors islow.
(cid:3)This is an extended version of a paper published in the Proceedings of the Fourth ACM-IEEEInternational Conference on
FormalMethodsandModelsforCodesign(MEMOCODE2006).
yThemajorpartofthiseffortwasperformedwhileTev(cid:2)kBultanwasvisitingtheNavalResearchLaboratoryonsabbaticalleave
fromtheUniversityofCalifornia,SantaBarbara.HisresearchissupportedinpartbyNSFgrantsCCF-0341365andCCF-0614002.
zConstanceHeitmeyer’sresearchissupportedbytheOf(cid:2)ceofNavalResearch.
1
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
2006 2. REPORT TYPE 00-00-2006 to 00-00-2006
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Applying Infinite State Model Checking and Other Analysis Techniques
5b. GRANT NUMBER
to Tabular Requirements Specifications of Safety-Critical Systems
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,Washington,DC,20375 REPORT NUMBER
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
Although it is most often applied to finite state models, in recent years, symbolic model checking has been
extended to infinite state models using symbolic representations that encode infinite sets. This paper
investigates the application of an infinite state symbolic model checker called Action Language Verifier
(ALV) to formal requirements specifications of safety-critical systems represented in the SCR (Software
Cost Reduction) tabular notation. After reviewing the SCR method and tools, the Action Language for
representing state machine models, and the ALV infinite state model checker, the paper presents
experimental results of formally analyzing two SCR specifications using ALV. The application of ALV to
verify or falsify (by generating counterexample behaviors) the state and transition invariants of SCR
specifications and to check Disjointness and Coverage properties is described. The results of formal
analysis with ALV are then compared with the results of formal analysis using techniques that have been
integrated into the SCR toolset. Based on the experimental results, strengths and weaknesses of infinite
state model checking with respect to other formal analysis approaches such as explicit and finite state
model checking and theorem proving are discussed.
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 Same as 37
unclassified unclassified unclassified Report (SAR)
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
In the last two decades, signi(cid:2)cant progress has been made in automated techniques for verifying (cid:2)nite
state systems, especially in techniques based on model checking [20]. In hardware design, model checking
has been successfully transferred from academic research into industrial use. Given a state machine model
andaproperty (oftenexpressed intemporallogic), amodelchecker exhaustively searches themodel’sstate
spacetodetermineifthemodelsatis(cid:2)esthegivenproperty. Sinceearlymodelcheckingresearchfocusedon
theanalysis of(cid:2)nitestatemodels,modelchecking isknownmainlyasa(cid:2)nitestateveri(cid:2)cation technique.
Asanexception,veri(cid:2)cationtechniquesthatfocusonreal-timesystemshavebeensuccessfulinanalyzing
speci(cid:2)cations with in(cid:2)nite state spaces (see, for example, [34]). These techniques, which are based on
the timed automata model [1], show that veri(cid:2)cation of timed automata can be achieved by using a (cid:2)nite
representation basedonclockregions. Veri(cid:2)cationofhybridsystemshasalsobeenstudiedextensively(see,
forexample,[30])toanalyzebehaviorsofdiscretecontrolsystemsthatinteractwithcontinuously changing,
externalenvironments. Researchinthisareatypicallyassumesacontinuousdomain,thusresultinginin(cid:2)nite
statespeci(cid:2)cations.
In recent years, model checking using symbolic representations that can encode in(cid:2)nite sets has been
extended to analyze in(cid:2)nite state models outside the domain of real-time or hybrid systems [2, 23,35,36].
These in(cid:2)nite state model checkers have reached a maturity level comparable to that of (cid:2)nite state model
checkers a decade ago. This paper investigates the application of an in(cid:2)nite state model checker called the
Action Language Veri(cid:2)er (ALV) [19, 44] to the formal analysis of requirements of safety-critical systems
speci(cid:2)ed in the SCR (Software Cost Reduction) tabular notation. It then compares the results of applying
in(cid:2)nitestatemodelcheckingusingALVwiththeresultsofapplyingtheformalanalysistoolsandtechniques
oftheSCRtoolset[25],identifying boththestrengthsandweaknessesofthetwoapproachesanddiscussing
potential synergies among thevarious analysis techniques.
Theremainder of thepaper isorganized as follows. Afterreviewing theSCRmodeland tools, Section 2
presents the two SCR speci(cid:2)cations used in our experiments. Section 3 gives an overview of the Action
Language, and Section 4 discusses the veri(cid:2)cation techniques used in ALV. Section 5 describes the appli-
cation of ALV and the SCR tools to the veri(cid:2)cation of the two SCR speci(cid:2)cations presented in Section 2.
Section 6discusses howALVcan be used for consistency checking and howits approach and performance
compare withthose of the SCRtools for consistency checking. Section 7 compares the in(cid:2)nite state model
checking techniques used in ALV with the veri(cid:2)cation techniques used in the SCR toolset, and Section 8
discusses theutility ofALVintheSCRtoolset. Finally,section 9presents someconclusions.
2 SCR Languageand Toolset
Theobjective of anSCRspeci(cid:2)cation isto specify the required externally visible behavior of asoftware
systemasarelationonenvironmental quantities. InanSCRspeci(cid:2)cation[25,28],monitoredandcontrolled
variables represent the quantities in the system environment that the system monitors and controls. The
required system behavior is speci(cid:2)ed as relations the system must maintain between the monitored and
controlled variables. Tospecify these relations clearly and concisely, the SCRlanguage provides twotypes
ofauxiliaryvariables,termsandmodeclasses. Atermisanauxiliaryvariablewhichmakesthespeci(cid:2)cation
more understandable by assigning some logical expression to the variable or more concise by assigning a
logical expression occurring more than once in the speci(cid:2)cation to the variable. A mode class is a special
case of a term whose values are modes. If a monitored variable changes, the effects of the change may
differ if the system is in one mode rather than another mode. Also of signi(cid:2)cance in SCR speci(cid:2)cations
are conditions and events, where a condition is a predicate de(cid:2)ned on a system state, and a basic event,
represented as@T(c),indicates that condition cchanges fromfalse totrue. Theevent @F(c)isde(cid:2)ned by
@T(:c),andindicatesthatconditioncchangesfromtruetofalse. Ifc’svalueinthecurrent-stateisdenoted
canditsvalueinthenext-state asc0,thenthesemanticsof@T(c)isde(cid:2)nedby:c^c0 andthesemanticsof
@F(c)byc^:c0. Aconditionedevent,denoted @T(c) WHEN d,addsaqualifying condition dtoanevent
andhasthesemantics :c^c0 ^d.
2
Table1.FormatofaModedConditionTable
ModeM Condition
m c c ::: c
1 1;1 1;2 1;p
::: ::: ::: ::: :::
m c c ::: c
n n;1 n;2 n;p
r v v ::: v
1 2 p
Table2.FormatofaModeTransitionTable
CurrentModeM Event NewModeM0
m e m
1 1;1 1;1
::: :::
e m
1;k1 1;k1
::: ::: :::
m e m
n n;1 n;1
::: :::
e m
n;kn n;kn
InSCRspeci(cid:2)cations,themonitoredvariablesareindependentvariables,andthemodeclasses,termsand
controlled variables are dependent variables. SCR speci(cid:2)cations de(cid:2)ne the values of dependent variables
using three types of tables: condition, event and modetransition tables. Each term and controlled variable
isde(cid:2)ned byeither acondition oranevent table. Typically, acondition table de(cid:2)nes thevalue ofavariable
in terms of a mode class and a set of conditions, and an event table de(cid:2)nes the value of a variable in terms
of a mode class and a set of conditioned events. A mode transition table associates a source mode and
a conditioned event with a destination mode. If the given event occurs in the source mode, then in the
next-state thesystemmakesatransition tothedestination mode.
Table 1 gives the format of a condition table de(cid:2)ning the value of a dependent variable r in terms of a
mode class M and a set of conditions c . The value of variable r described by the table can be de(cid:2)ned as
i;j
aformula F ,
r
n p
F (cid:17) (M =m ^c ^r =v ); (1)
r _ _ i i;j j
i=1j=1
where n is the number of modes in M, p is the number of conditions for each mode in the table, and the
value v isa type-correct value of r. Notethat acondition table de(cid:2)nes the value ofa variable with respect
j
toasinglestate. Incontrast,thevalueofamodeclassoravariabledescribedbyaneventtableisde(cid:2)nedon
twoconsecutive states, i.e.,onstatetransitions.
The format of a moded event table de(cid:2)ning a variable r0 is identical to the format in Table 1 with each
condition c replaced by a conditioned event e and r replaced by r0. The semantics of a moded event
i;j i;j
tablecanbede(cid:2)nedasaformulaFr0,
n p n p
Fr0 (cid:17)2_ _(M =mi^ei;j ^r0 =vj)3 _ 2:(_ _ M =mi^ei;j)^r0 =r3; (2)
4i=1j=1 5 4 i=1j=1 5
where n, p, and v are de(cid:2)ned above. The right-hand expression in the disjunction in (2) describes the
j
no-change case; it states that when an event occurs that is not explicitly speci(cid:2)ed in the table, the value of
variable r doesnotchange.
Table 2 shows the format of a mode transition table describing the transitions of a mode class M. The
semantics ofthetablecanbede(cid:2)ned asaformula FM0,
3
n ki n ki
FM0 (cid:17)2_ _(M =mi^ei;j ^M0 =mi;j)3_2:(_ _ M =mi^ei;j)^M0 =M3; (3)
4i=1j=1 5 4 i=1j=1 5
where m denotes the ith source mode, e the jth conditioned event for the ith source mode, and m
i i;j i;j
the associated destination mode. As in event tables, if an event occurs that is not speci(cid:2)ed in the table, the
semantics ofamodetransition tablearethatthemodedoesnotchange.
Two relations introduced in Parnas’ Four Variable Model [40], NATand REQ,de(cid:2)ne constraints on the
monitoredandcontrolledvariables. NATspeci(cid:2)esthenaturalconstraintsonthesystemimposedbyphysical
laws and the system environment. In SCR,the NATconstraints are called assumptions. REQspeci(cid:2)es the
required system behavior as further constraints on therelation between monitored and controlled variables.
REQ is written using the SCR tables and it speci(cid:2)es the required system behavior as constraints on the
dependent variables. In this paper, we focus on veri(cid:2)cation of the REQ speci(cid:2)cations written using SCR
tables. Givenasetofdependent variables, REQisde(cid:2)ned astheconjunction ofthesemantics described by
eachtable.
An SCR speci(cid:2)cation de(cid:2)nes the required system behavior as a state machine (cid:6) = (S;(cid:18);(cid:26)), where S
is the set of states (each state is a function mapping a state variable name to a type-correct value), (cid:18) is a
predicate onS which de(cid:2)nes theset ofinitial states, and (cid:26) (cid:18) S (cid:2)S isthetransition relation whichde(cid:2)nes
the allowable state transitions. The transition relation of an SCR speci(cid:2)cation is based on the One Input
Assumption, which states that in any state transition, exactly one monitored variable changes its value. For
further details oftheSCRsemantics, see[28].
2.1 Two SCR Speci(cid:12)cations
ThissectionprovidesexcerptsfromSCRspeci(cid:2)cationsoftwosafety-critical softwaresystems(cid:151)aSafety
Injection System (SIS) [21], which controls safety injection in a nuclear power plant, and a Cruise Control
System (CCS) [25], which manages cruise control in an automobile. The speci(cid:2)cations of both the SIS
and the CCSdescribe how each system is required to respond to changes in the monitored variables. Both
speci(cid:2)cationsusemodestocapturethehistoryofchangesinthemonitoredvariablesandoneormoremodes
tomakethespeci(cid:2)cation moreunderstandable andmoreconcise.
Figure1.SCRrequirementsspecificationoftheSafetyInjectionSystem.
TheSafetyInjectionSystem(SIS). TheSISspeci(cid:2)cation describes therequirements ofthe control soft-
ware for a nuclear reactor’s cooling system [21]. SIS monitors the water pressure of the cooling sys-
tem. When water pressure drops below a certain constant value Low, the system starts safety injection
(if it is not overridden). In the SCR speci(cid:2)cation of SIS, the monitored variables(cid:151)mBlock, mReset,
4
Table3.TypesandinitialvaluesofvariablesintheSISspecification.
VariableName Class Type Init.Value
mWaterPres Monitored yPresRange 14
mBlock Monitored ySwitch Off
mReset Monitored ySwitch On
tOverridden Term Boolean false
mcPressure ModeClass Enumerated TooLow
cSafetyInjection Controlled ySwitch On
and mWaterPres(cid:151)denote the states of the block and reset switches and the water pressure reading; the
mode class mcPressure indicates one of three system modes, TooLow, Permitted, and High; the
Boolean term tOverridden indicates whether safety injection is overridden; and the controlled variable
cSafetyInjection indicates whether safety injection is turned on. To illustrate the SCR method for
specifying the required behavior of a software system, Figure 1 illustrates the relationship between the SIS
inputs, represented asmonitored variables; the SISmodes; and the single SISoutput, represented as acon-
trolled variable.It also gives examples of two conditioned events, those that label the transitions between
TooLow and Permitted. The (cid:2)gure shows that when the system is in TooLow and the water pressure
reading changes from Low to greater than or equal to Low, the SIS mode changes to Permitted; simi-
larly, when SIS is in the mode Permitted and the water pressure reading changes from a value greater
than or equal to Low to less than Low,the SISmode changes to TooLow. In the SIS speci(cid:2)cation, a NAT
assumption is that mWaterPreshas a value between 0 and 2000, i.e., 0 (cid:20)mWaterPres(cid:20) 2000, and that
mWaterPrescanchangebyatmostonefromonestatetothenext,i.e.,jmWaterPres0(cid:0)mWaterPresj (cid:20) 1.
An alternate NAT assumption could allow mWaterPres to change by more than one in each step, e.g.,
jmWaterPres0(cid:0)mWaterPresj (cid:20) 10.
Table3indicatestheclass,type,andinitialvalueofeachvariableintheSCRspeci(cid:2)cation ofSIS,stating
for example that the type of two monitored variables, mBlock and mReset, and the controlled variable
cThrottle is ySwitch, a user-de(cid:2)ned enumerated type with values in fOn, Offg. Table 3 also in-
dicates that, in the initial state, water pressure has the value 14, tOverridden is false, the switches
mReset and cSafetyInjectionare on, and the switch mBlock is off. In the SCR speci(cid:2)cation of
SIS,theuser-de(cid:2)ned types ySwitchandPresRangearede(cid:2)ned inatype dictionary (notshown).
Figure 2 contains the mode transition, event, and condition tables de(cid:2)ning the transition relation of
the SIS speci(cid:2)cation. The top table, the mode transition table, de(cid:2)nes the transitions for the mode class
mcPressure,and the middle table, the event table, the transitions for the term variable tOverridden.
The(cid:2)rstrowofthe mode transition table states that ifthe system is inmode TooLowwhenwater pressure
changesfromlessthanLowtoavalueexceedingorequaltoLow,thesystemmodechangestoPermitted.
The entry (cid:147)Never(cid:148) in the event table means that if the system is in the mode High, no event can cause
tOverriddentochangetotrue. Themiddleentryinthesecondrowoftheeventtableindicatesthatifthe
system is in either TooLowor Permittedand the user turns the Block switch on when the Reset switch
isoff,then thevalue oftOverriddeninthenewstateistrue. Inthemiddle table,theconstants Lowand
Permit have the values 900 and 1000. The bottom table, a condition table de(cid:2)ning the controlled vari-
able cSafetyInjection, describes a state invariant de(cid:2)ning the required relation between the values
of cSafetyInjection,tOverridden,and mcPressure. Because the water pressure reading can
vary from 0to 2000 and because water pressure affects the value of cSafetyInjection(by determining
thecurrent mode),analyzing theSISspeci(cid:2)cation mechanically canbechallenging.
5
CurrentMode Event NewMode
mcPressure mcPressure
TooLow @T(mWaterPres (cid:21) Low) Permitted
Permitted @T(mWaterPres (cid:21) Permit) High
Permitted @T(mWaterPres < Low) TooLow
High @T(mWaterPres < Permit) Permitted
ModemcPressure Events
High Never @F(mcPressure = High)
TooLow, @T(mBlock=On) @T(mcPressure = High)OR
Permitted WHEN mReset=Off @T(mReset=On)
tOverridden’ True False
ModemcPressure Conditions
High, Permitted True False
TooLow tOverridden NOTtOverridden
cSafetyInjection Off On
Figure2.ThreetablesintheSCRspecificationoftheSIS.
TheCruiseControlSystem(CCS). Thespeci(cid:2)cation ofCCSdescribes therequired behavior ofacruise
control system for an automobile. CCS controls the automobile’s throttle and speed (via the throttle po-
sition) based on the state of the brake, engine, ignition switch, actual and desired car speeds, and cruise
controllever. TheSCRspeci(cid:2)cation ofCCS[25]usesamodeclassmcCruisetoindicatethecurrentmode
of CCS(cid:151)either Off, Inactive, Cruise, or Override. The monitored variables of CCS(cid:151)mIgnOn,
mSpeed, mBrake, mLever, and mEngRunning(cid:151)indicate the state of the car’s ignition, the speedometer
reading, thepositions ofthe brake and cruise control switch, and the state ofthe engine. Thelever position
is either off, const, release, or resume. Another monitored variable represents time. The controlled
variable cThrottle represents the state of the throttle, and the term tDesiredSpeed represents the de-
siredspeed.
Figure3illustratestherelationship betweentheCCSmonitoredvariables,theCCSmodes,andthesingle
CCScontrolled variable. It also shows the two events that trigger transitions between Off and Inactive.
For example, in response to the driver turning the ignition on (represented as (cid:147)@T(mIgnOn)(cid:148)) when the
system is in mode Off, the system enters the mode Inactive, and when the driver turns the ignition off
(representedas(cid:147)@F(mIgnOn)(cid:148))whenthesystemisnotalreadyinmodeOff,thesystemre-entersthemode
Off. The value of the term tDesiredSpeed represents the desired car speed. The value of the controlled
variable cThrottle depends on the mode the system is in, the actual car speed compared to the desired
automobile speed, and the length of time the cruise control system has been in the const position. The
Figure3.SCRrequirementsspecificationoftheCruiseControlSystem.
6
Table4.TypesandinitialvaluesofvariablesintheCCSspecification.
VariableName Class Type Init.Value
mBrake Monitored Boolean false
mEngRunning Monitored Boolean false
mIgnOn Monitored Boolean false
mLever Monitored yLever release
mSpeed Monitored ySpeed 0.0
time Monitored integer 0
tDesiredSpeed Term ySpeed 0.0
tDURLeverEQconst Term integer 0
mcCruise ModeClass Enumerated Off
cThrottle Controlled yThrottle Off
Table5.ExcerptsfromtheModeTransitionTableformcCruise
CurrentMode Event NewMode
mcCruise mcCruise
Off @T(mIgnOn) Inactive
Inactive @F(mIgnOn) Off
Inactive @T(mLever=const)WHENmIgnOn Cruise
ANDmEngRunningANDNOTmBrake
::: ::: :::
Override @T(mLever=resume)WHENmIgnOn Cruise
ANDmEngRunningANDNOTmBrakeOR...
amount of time that the cruise control system has been in the const position is represented by a term
called tDURLeverEQconst. Table 4 gives the class, type, and initial value of each variable in the SCR
speci(cid:2)cation of CCS. The user-de(cid:2)ned types in Table 4 are ySpeed, an integer in [0;180], and yLever
andyThrottle,enumeratedtypesde(cid:2)nedbyyLeverinfconst, release, off, resumegand
yThrottleinfaccel, maintain, decel, offg.
Table5containsexcerptsfromthemodetransitiontablefortheCCS.The(cid:2)rstrowspeci(cid:2)esthemonitored
event ((cid:147)@T(mIgnOn)(cid:148)) that causes the system to make a transition from Offto Inactive. The third row
states that when the system is in the mode Inactive and the driver puts the cruise control lever in the
position const when the ignition is on, the engine is running, and the brake is off, the mode changes to
Cruise. The requirement that the throttle value depends on 1) the difference between the car speed and
some constant value and 2) whether the CCS has been in a given mode for more than 500 ms can make
analysis oftheCCSspeci(cid:2)cation dif(cid:2)cult. Forthecomplete SCRspeci(cid:2)cation oftheCCS,see[25].
2.2 SCR Toolset
The SCR toolset integrates the formal analysis tools and techniques presented below. Each may be
used alone, or in combination with others in the toolset, to analyze an SCR speci(cid:2)cation [25]. The toolset
includes an editor, a consistency checker, a simulator, and several tools and techniques useful in verifying
critical application properties, such as safety properties. Among the latter are Spin, an explicit state model
checker; twotheorem provers,SalsaandTAME;asetofabstraction techniques; andaninvariant generator.
(cid:15) Specification Editor. The editor supports the creation of SCR speci(cid:2)cations, which consist of a set
oftablesandasetofdictionaries. Thedictionaries specifythevaluesofconstants, user-de(cid:2)nedtypes,
thenames,initial values,andtypes ofvariables, andsetsofassertions andassumptions.
7
(cid:15) Consistency Checking. The SCR consistency checker checks for syntax and type errors, circular
de(cid:2)nitions, and for violations of Disjointness and Coverage [28]. The checks other than those for
Disjointness andCoverageareanalogous tostandard compilerchecks. CheckingDisjointness detects
nondeterminism intheSCRtables. Checking Coverageexposes missing cases.
(cid:15) Simulator. The SCR simulator symbolically executes an SCR speci(cid:2)cation to allow users to vali-
date that the speci(cid:2)cation captures the intended system behavior. The simulator is also useful for
demonstrating andvalidating property violations detected byamodelchecker.
(cid:15) Model Checking with Spin. The SCR toolset includes a translator from SCR to Promela [10], the
language of the model checker Spin [31]. (Translators from SCR also exist for symbolic model
checkers, such as SMV.) Using Spin, a user can check SCR speci(cid:2)cations for both state invariants,
one-state properties that hold in every reachable state, and transition invariants, two-state properties
thathold ineveryreachable transition.
(cid:15) Property Checking with Salsa. The SCR property checker Salsa [12] may be used to check SCR
speci(cid:2)cations for Disjointness and Coverage and for satisfaction of state and transition invariants.
Salsa can check the validity of formulas on Boolean, enumerated and integer variables restricted to
Presburgerarithmetic. ItusesBDDsforanalyzingformulasonBooleanandenumeratedvariablesand
anautomata representation foranalyzing Presburger arithmetic formulas.
(cid:15) Theorem Proving with TAME. TAME (Timed Automata Modeling Environment), a specialized
interface to PVS [39], offers templates for specifying automata models and customized strategies
which implement high-level proof steps for proving automaton properties [3]. Initially developed
for Timed Input/Output Automata, TAMEhas been adapted to SCRby an automatic SCR-to-TAME
translator andbyaddingSCR-speci(cid:2)cstrategiesthatprovemanyproperties automatically andexhibit
(cid:147)problem transitions(cid:148) forundischarged proofgoals.
(cid:15) Abstraction. In[10,11,27],three abstraction techniques are described which reduce the state space
of an SCRrequirements speci(cid:2)cation. The (cid:2)rst technique called slicingremoves variables irrelevant
to the validity of the property under analysis. The SCR toolset can apply slicing automatically. The
secondandthirdtechniquesperformdataabstractionbyreplacingvariableswithlargedomains(such
as integers) with enumerated type variables, where each value of an enumerated abstract variable
represents arangeofvaluesforthecorresponding concrete variable.
(cid:15) Invariant Generation. Algorithms for generating state invariants from SCR speci(cid:2)cations are de-
scribed in [32, 33]. Such invariants are useful as auxiliary lemmas in proving properties of SCR
speci(cid:2)cations withTAMEandSalsa. TheSCRinvariantgenerator generatesinvariants automatically.
Theuser maychoose which algorithms toapply and mayalso choose which tables (condition, event,
ormodetransition tables) toanalyze.
3 Action Language
ActionLanguageisaspeci(cid:2)cation language forreactivesoftwaresystems[14,19]. AnActionLanguage
speci(cid:2)cation consists of integer, Boolean and enumerated variables, parameterized integer constants, and a
setofmodulesandactionswhicharecomposedusingsynchronousandasynchronouscompositionoperators.
Thestatespaceofamoduleisde(cid:2)nedbyitsvariables andarestrict expression, itsinitialstatesbyaninitial
expression, and its transition relation by a module expression. Action Language expressions can contain
linear arithmetic operators, Boolean logic connectives, and universal and existential quanti(cid:2)cation over
8
integers. Semantically, each Action Language module corresponds to a transition system T = (I;S;R)
whereS isthesetofstates,I (cid:18) S isthesetofinitial statesandR (cid:18) S (cid:2)S isthetransition relation.
A state of an Action Language speci(cid:2)cation assigns a value to each variable in the speci(cid:2)cation. The
state space of the module is de(cid:2)ned as all states that satisfy the restrict expression of that module. For
example, if a variable r is declared as an integer in Action Language, by default its domain is the in(cid:2)nite
set of allintegers. Such avariable can be restricted toa (cid:2)nitedomain from 1to 100 by using the following
expression: restrict: r >= 1 and r <= 100. Thefollowing restrict expression, on the other hand,
restrict: r < trestrictsthestatespacetostatesinwhichthevalueofvariablerislessthanthevalue
ofthevariable t;however,inthiscase,variables randtcantake anin(cid:2)nitenumber ofvalues.
The initial expression of a module de(cid:2)nes the set of initial states of that module. For example, given
two variables r and t, all of the following are valid initial expressions: initial: r = 1 and t =
2; initial: r >= 1 and r <= 10 and t = r; initial: r >= 1 and r < t. According to
the (cid:2)rst initial expression, in any initial state, r equals 1 and t equals 2. According to the second initial
expression,inanyinitialstate,randtmusthavethesamevalue,andtheycantakeanyvaluebetween1and
10, inclusive. Finally, the third initial expression states that, in anyinitial state, rmust have avalue greater
than or equal to 1 but less than the value of t. In this case there is no upper bound for r or t in the initial
states. However,in anyinitial state (orany other state), the variables cannot have avalue disallowed by the
restrict expression.
InActionLanguage,thetoplevelmoduleisalwayscalledthemainmodule. Amoduleexpression(which
starts with the name of the module) de(cid:2)nes the transition relation of the module. Amodule expression can
either bewritten asalogical expression onprimed andunprimed variables, orasacomposition expression.
In module expressions, primed variables (called next-state variables) denote the next-state values and un-
primed variables (called current-state variables) denote the current-state values. A module expression can
bewrittenusing current andnext-state variables andlogical connectives and,or,andnot.
A composition expression, on the other hand, is written in terms of actions and submodules of a mod-
ule using asynchronous and synchronous composition operators [14]. The composition operations are not
discussed here, because they are not needed in translating SCR speci(cid:2)cations to Action Language. Since
Action Language Veri(cid:2)er (ALV)constructs a symbolic representation from the input speci(cid:2)cation, speci(cid:2)-
cation of the input system with or without the composition operators is not likely to affect the veri(cid:2)cation
performance, aslong asspeci(cid:2)cations aresemantically equivalent.
SCR to Action Language Translation. Given the SCR semantics in Section 2, translating SCR speci(cid:2)-
cations to Action Language is straightforward. In Action Language, the module expression for the main
module de(cid:2)nes thetransition relation ofthe system. Totranslate anSCRspeci(cid:2)cation toAction Language,
we generate a module expression which is a conjunction in which each conjunct corresponds to one of the
tablesintheSCRspeci(cid:2)cation. Theformulaforeachtableisinthedisjunctive formfollowingthestructure
oftheformulas in(1)(cid:150)(3) thatde(cid:2)nethesemantics oftheSCRtables.
The semantics of SCRtables can be expressed in Action Language using logical expressions on current
andnext-state variables. Considerthethesemanticsofthemodetransition tablesin(3). Theformulaonthe
righthand sidecanbeexpressed inActionLanguage directly usingthecurrent andnextstate variables, and
the logical connectives. Because the semantics of event tables have the same structure, event tables can be
translated toActionLanguage inthesamemanner.
Thesemantics of condition tables are de(cid:2)ned in (1) (see Section 2). These semantics de(cid:2)ne state invari-
ants rather than transition invariants. A condition table can be translated into Action Language by making
surethattheinvariantde(cid:2)nedbythecondition tableholds1)intheinitialstatesofthesystemand2)ineach
possible next-state. Thiscanbeachieved by1)adding theformulaontherighthandsideof(1)totheinitial
expression oftheAction Language translation asaconjunct, and 2)rewriting theformula ontheright hand
9