Action Language: A Specification Language for Model Checking Reactive Systems
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
http://www.cs.ucsb.edu/~bultan/
Initial Goal
To develop an input language for a model checker that is based on following techniques:– [Bultan, Gerber, Pugh 97, 99] Using Presburger arithmetic
constraints for model checking infinite state systems– [Bultan, Gerber, League 98, 00] Composite model checking:
Model checking with type-specific symbolic representations (using Presburger arithmetic constraints and BDDs together)
How about a broader perspective?
Model Checking Software Specifications
[Atlee, Gannon 93] Translating SCR mode transition tables to input language of explicit state model checker EMC [Clarke, Emerson, Sistla 86]
[Chan et al. 98] Translating RSML specifications to input language of symbolic model checker SMV [McMillan 93]
[Bharadwaj, Heitmeyer 99] Translating SCR specifications to Promela, input language of automata-theoretic explicit state model checker SPIN [Holzmann 97]
Issues Addressed in These Studies
Using abstractions and simplifications to avoid the state-space explosion problem – State-space explosion is the main weakness of model
checking
Expressing correctness properties in temporal logics Translation from a high level specification language
– SCR, RSML, Statecharts
to a lower level specification language– input language of the model checker: Promela, SMV
Language Translation
Why should we have two languages?
– User can make abstractions on the intermediate language
– User can interact with various options of the model checker using the intermediate language
– Separation of concerns Analogy: A programming
language and instruction set of a microprocessor
– Input language of the model checker is like an assembly language
Reactive System SpecificationReactive System Specification(Statecharts, RSML, SCR)(Statecharts, RSML, SCR)
Input Language of the Input Language of the Model CheckerModel Checker(Promela, SMV)(Promela, SMV)
Transition System ModelTransition System Model
Translation requires Translation requires abstractions or simplificationsabstractions or simplifications
Automated translationAutomated translationby the model checkerby the model checker
Revised Goal
Develop a low level specification language for model checking
The language should be able to “handle” different high level specification languages
The language should expose the structure of the transition system model for interactive use of the model checker
Outline
Model Checking– Symbolic model checking– Automata theoretic model checking
Action Language– Actions: State Changes– Synchronous vs. Asynchronous Composition
Translating Statecharts to Action Language Translating SCR to Action Language Conclusions and Future Work
Model Checking View
Every reactive system – safety-critical software specification,– cache coherence protocol,– communication protocol, etc.
is represented as a transition system:– S : The set of states– I S : The set of initial states– R S S : The transition relation
Model Checking View
Properties of reactive systems are expressed in temporal logics
Invariant(p) : is true in a state if property p is true in every state reachable from that state– Also known as AG
Eventually(p) : is true in a state if property p is true at some state on every execution path from that state– Also known as AF
Model Checking Technique
Given a program and a temporal property p:
Either show that all the initial states satisfy the temporal property p– set of initial states truth set of p
Or find an initial state which does not satisfy the property p– a state set of initial states truth set of p
Symbolic Model Checking
Represent sets of states and the transition relation using Boolean logic formulas (and linear arithmetic formulas).
Represent these formulas using an efficient data structure (such as BDDs)
Using this data structures compute the truth set of temporal logic formulas: backward, or forward fixpoint computations
Automata-Theoretic Model Checking
Represent the negation of the input temporal property as a Büchi automata
Represent the transition system as a Büchi automata Take the synchronous product of these two automata If the language accepted by the product automata is
empty, then the property is true. If not generate a counter-example.
Action Language
A state based language, actions correspond to state changes – Unlike CCS
Transition relation is defined using actions– Basic actions: Predicates on current and next state variables– Action composition: synchronous or asynchronous
Modular– Local, imported, exported, shared variables– Modules can be composed using synchronous or
asynchronous composition
Action Language – TLA Connection
Similarities:– Transition relation is defined using predicates on current and
next state variables– Each predicate is defined mathematically using
• integer arithmetic, boolean logic, etc.
Differences: In Action Language– Temporal operators are not used in defining the transition
relation • Dual language approach: temporal properties are redundant,
they are used to check correctness
– Synchronous and asynchronous composition operators are not equivalent to logical operators
An Action Language Specification
module producer_consumerinteger produced, consumed, count;parameterized integer size;initial : produced = consumed = count = 0;restrict : size >= 1;producer : count < size & count’ = count + 1
& produced’ = produced + 1;consumer : count > 0 & count’ = count – 1;
& consumed’ = consumed + 1;producer_consumer : producer | consumer;spec : invariant(produced – consumed = count
& count <= size);endmodule
A Closer Look at Action Languagemodule producer_consumer
integer produced, consumed, count;parameterized integer size;
initial : produced = consumed = count = 0;
restrict : size >= 1;
producer : count < size & count’ = count + 1& produced’ = produced + 1;
consumer : count > 0 & count’ = count – 1;& consumed’ = consumed + 1;
producer_consumer : producer | consumer;
spec : invariant(produced – consumed = count& count <= size);
endmodule
S S : Cartesian product of: Cartesian product of variable domains defines variable domains defines the set of statesthe set of states
S S : Restricts set : Restricts set of statesof states
I I : Predicate defining : Predicate defining the initial statesthe initial states
RR : Defines the transition relation : Defines the transition relation
Temporal propertyTemporal property
RR : Atomic actions of the : Atomic actions of the system used to define system used to define the transition relationthe transition relation
Actions in Action Language
Basic actions (no composition) Predicates on current and next state variables
– Current state variable: produced– Next state variable: produced’– Logical operators
• Negation !• Conjunction &• Disjunction |
An action is a predicate:count < size & count’ = count + 1 & produced’ = produced + 1
No Assignments, Guards, Ifs, etc.
Assignment– x’ = y + 1– Equivalent to x’ – 1 = y, 0 = y – x’ + 1
Guarded commands – x > 0 & x’=y+1
If-then-else– (x > 0 & x’=x+1) | (!(x > 0) & x’=x-1)
guardguard assignmentassignment
Composition in Action Language
There are two basic composition operators in action language– Asynchronous composition: a1 | a2– Synchronous composition: a1 & a2
Asynchronous composition is almost equivalent to logical OR
Synchronous composition is almost equivalent to logical AND
Asynchronous Composition
Asynchronous composition is equivalent to logical OR if composed actions have the same next state variables
a1 : i > 0 & i’ = i + 1;
a2 : i <= 0 & i’ = i – 1;
a3 : a1 | a2
a3 : (i > 0 & i’ = i + 1)
| (i <= 0 & i’ = i – 1);
Asynchronous Composition
Asynchronous composition preserves values of variables which are not explicitly updated
a1 : i > j & i’ = j;
a2 : i <= j & j’ = i;
a3 : a1 | a2;
a3 : (i > j & i’ = j) & j’ = j
| (i <= j & j’ = i) & i’ = i
Asynchronous Composition Example
module producer_consumerinteger produced, consumed, count;parameterized integer size;initial : produced = consumed = count = 0;restrict : size >= 1;producer : count < size & count’ = count + 1
& produced’ = produced + 1;consumer : count > 0 & count’ = count – 1;
& consumed’ = consumed + 1;producer_consumer : producer | consumer;spec : invariant(produced – consumed = count
& count <= size);endmodule
Synchronous Composition
Synchronous composition is equivalent to logical AND if two actions do not disable each other
a1 : i’ = i + 1;
a2 : j’ = j + 1;
a3 : a1 & a2;
a3 : i’ = i + 1 & j’ = j + 1;
Synchronous Composition
A disabled action does not block synchronous composition
a1 : i < max & i’ = i + 1;
a2 : j < max & j’ = j + 1;
a3 : a1 & a2;
a3 : (i < max & i’ = i + 1 | i >= max & i’ = i)
& (j < max & j’ = j + 1 | j >= max & j’ = j);
Modules in Action Language
A module has – A set of states– A set of initial states– A transition relation
Modules can be composed like actions using asynchronous and synchronous composition
Shared Variables
Modules can share variables
exported :gives read access to other modules
imported :gets read access of an exported variable
shared :both read and write accessed by different
modules
Modular Producer-Consumer Examplemodule producer integer produced; shared integer count; shared parameterized integer size; initial : produced = 0; restrict : size>=1; producer : count<size & count’=count+1
& produced’=produced+1;endmodule
module consumer integer consumed; shared integer count; shared parameterized integer size; initial : consumed = 0; restrict : size >= 1; consumer : count>0 & count’=count–1;
& consumed’=consumed+1;endmodule
module producer_consumer module producer, consumer; shared int count = 0; initial count=0; producer_consumer : producer | consumer; spec : invariant(produced – consumed = count) & count <= size);endmodule
Temporal Properties in Action Language
Temporal properties can be declared using high level temporal operators – invariant– eventually
Or CTL temporal operators– AG, AF, etc.
Statecharts
Hierarchical state machines States can be combined to form superstates OR decomposition of a superstate
– The system can be in only one of the OR states at any given time
AND decomposition of a superstate – The system has to be in both AND states at the same time
Transitions– Transitions between states
Statecharts to Action Language
Statecharts transitions (arcs) correspond to actions OR states correspond to enumerated variables and
they define the state space Transitions (actions) of OR states are combined
using asynchronous composition Transitions (actions) of AND states are combined
using synchronous composition
Statecharts to Action Language
module AlSys enum Alarm {Shut, Op}; enum Mode {On, Off}; enum Vol {1, 2}; initial : Alarm=Shut &
Mode=Off & Vol=1; t1 : Alarm=Shut & Alarm’=Op &
Mode’=On & Vol’=1; t2 : Alarm=Shut & Alarm’=Op &
Mode’=Off & Vol’=1; t3 : Alarm=Op & Alarm’=Shut; t4 : Alarm=Op & Mode=On &
Mode’=Off; t5 : Alarm=Op & Mode=Off &
Mode’=On;... AlSys : t1 | t2 | t3 | (t4 | t5) & (t6 | t7); endmodule
AlarmAlarm
ShutShut
OpOp
OnOn
OffOff
11
22
ModeMode VolVol
t1t1 t2t2 t3t3
t4t4 t5t5 t6t6 t7t7
SCR
Tabular specifications– Mode transition tables– Condition tables– Event tables
Events– @T(c) = c c’ – In action language: !c & c’ – @T(c) WHEN d = c c’ d– In action language: !c & c’ & d
SCR to Action Language
Each row in an SCR table corresponds to an action The transition relation of a table is defined by
asynchronous composition of actions that correspond to its rows
The transition relation of the whole system is defined by the synchronous composition of transition relations of tables
SCR to Action Language
module HeaterACSys enum Heater{On, Off}; enum AC{On, Off}; int temp; parameterized int low, high; initial : low<=temp<=high & Heater=AC=Off; r1 : !(temp<low) & temp’<low & Heater=Off & Heater’=On; r2 : !(temp>=low) & temp’>=low
& Heater=On & Heater’=Off; t_heat : r1 | r2;
...
HeaterACSys: t_heat & t_AC; endmodule
Old Mode Event New Mode
Off @T(temp < low) On
On @T(temp low) Off
Old Mode Event New Mode
Off @T(temp > high) On
On @T(temp high)
Off
Heater Heater
ACAC
Conclusions
It is possible to represent specification languages such as Statecharts and SCR using simple composition operators
Action language can provide an intermediate language for verification– It preserves the structure of high-level specifications– It is closer to the transition system models used by model
checkers
Related Work
Specification languages for verification– [Milner 80] CCS– [Chandy and Misra 88] Unity– [Lamport 94] Temporal Logic of Actions (TLA)
Specification languages for model checking– [Holzmann 98] Promela– [McMillan 93] SMV– [Alur and Henzinger 96, 99] Reactive Modules
Future Work
Developing efficient model checking procedures for Action Language specifications
Exploiting modularity in model checking Action Language specifications
Introducing constructs in Action Language for user directed state-space reductions– Abstractions– Variable hiding
Top Related