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

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