Action language a specification language for model checking reactive systems
Download
1 / 41

Action Language: A Specification Language for Model Checking Reactive Systems - PowerPoint PPT Presentation


  • 238 Views
  • Uploaded on

Action Language: A Specification Language for Model Checking Reactive Systems. Tevfik Bultan Department of Computer Science University of California, Santa Barbara [email protected] http://www.cs.ucsb.edu/~bultan/. Initial Goal.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Action Language: A Specification Language for Model Checking Reactive Systems' - asabi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Action language a specification language for model checking reactive systems l.jpg

Action Language: A Specification Language for Model Checking Reactive Systems

Tevfik Bultan

Department of Computer Science

University of California, Santa Barbara

[email protected]

http://www.cs.ucsb.edu/~bultan/


Initial goal l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
Language Translation

Reactive System Specification

(Statecharts, RSML, SCR)

  • 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

Translation requires

abstractions or simplifications

Input Language of the

Model Checker

(Promela, SMV)

Automated translation

by the model checker

Transition System Model


Revised goal l.jpg
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 l.jpg
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 l.jpg
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 view9 l.jpg
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 l.jpg
Model Checking Technique

Given a program and a temporal propertyp:

  • Either show that all the initial states satisfy the temporal propertyp

    • set of initial states  truth set of p

  • Or find an initial state which does not satisfy the propertyp

    • a state  set of initial states  truth set of p


Symbolic model checking l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
A Closer Look at Action Language

S : Cartesian product of

variable domains defines

the set of states

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

I : Predicate defining

the initial states

S : Restricts set

of states

R : Atomic actions of the

system used to define

the transition relation

R : Defines the transition relation

Temporal property


Actions in action language l.jpg
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 l.jpg
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)

guard

assignment


Composition in action language l.jpg
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 l.jpg
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 composition21 l.jpg
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 l.jpg
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 l.jpg
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 composition24 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 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 l.jpg
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 l.jpg
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 l.jpg
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 language31 l.jpg
Statecharts to Action Language

Alarm

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

Shut

t1

t2

Op

t3

Mode

Vol

On

1

t4

t5

t6

t7

Off

2


Slide32 l.jpg
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 l.jpg
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 language34 l.jpg
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

Heater

AC


Conclusions l.jpg
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 l.jpg
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 l.jpg
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


ad