Action Language:
A Specification Language for Model
Checking Reactive Systems
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
bultan@cs.ucsb.edu
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
Reactive System Specification
(Statecharts, RSML, SCR)

Translation requires
abstractions or simplifications
Input Language of the
Model Checker
(Promela, SMV)
Automated translation
by the model checker
Transition System Model

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
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_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
A Closer Look at Action Language
module producer_consumer
integer produced, consumed, count;
parameterized integer size;
S : Cartesian product of
variable domains defines
the set of states
initial : produced = consumed = count = 0;
restrict : size >= 1;
S : Restricts set
of states
producer : count < size & count’ = count + 1
& produced’ = produced + 1;
consumer : count > 0 & count’ = count – 1;
& consumed’ = consumed + 1;
producer_consumer : producer | consumer;
R : Atomic actions of the
system used to define
the transition relation
R : Defines the transition relation
spec : invariant(produced – consumed = count
& count <= size);
endmodule
I : Predicate defining
the initial states
Temporal property
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
guard

assignment
If-then-else
– (x > 0 & x’=x+1) | (!(x > 0) & x’=x-1)
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_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
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 Example
module 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 producer_consumer
module producer, consumer;
module consumer
shared int count = 0;
integer consumed;
initial count=0;
shared integer count;
producer_consumer :
shared parameterized integer size;
producer | consumer;
initial : consumed = 0;
spec : invariant(produced
restrict : size >= 1;
– consumed = count)
consumer : count>0 & count’=count–1;
& consumed’=consumed+1;
endmodule
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
Alarm
Shut
Op
t1
t2
Mode
Vol
On
t4
1
t5
Off
t3
t6
t7
2
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
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
Heater
Old Mode
Event
New Mode
Off
@T(temp < low)
On
On
@T(temp  low)
Off
AC
Old Mode
Event
New Mode
Off
@T(temp > high)
On
On
@T(temp  high)
Off
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
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