Action Language: A Specification Language for Model Checking Reactive Systems

1
Action Language A Specification Language for
Model Checking Reactive Systems

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan/

2
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?

3
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

4
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

5
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 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
6
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

7
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

8
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

9
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

10
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

11
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

12
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.

13
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

14
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

15
An Action Language Specification

• module producer_consumer
• integer produced, consumed, count
• parameterized integer size
• initial produced consumed count 0
• restrict size gt 1
• producer count lt size count count 1
• produced produced 1
• consumer count gt 0 count count 1
• consumed consumed 1
• producer_consumer producer consumer
• spec invariant(produced consumed count
• count lt size)
• endmodule

16
A Closer Look at Action Language

• module producer_consumer
• integer produced, consumed, count
• parameterized integer size
• initial produced consumed count 0
• restrict size gt 1
• producer count lt size count count 1
• produced produced 1
• consumer count gt 0 count count 1
• consumed consumed 1
• producer_consumer producer consumer
• spec invariant(produced consumed count

S Cartesian product of variable domains
defines the set of states
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
17
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 lt size count count 1
• produced produced 1

18
No Assignments, Guards, Ifs, etc.

• Assignment
• x y 1
• Equivalent to x 1 y, 0 y x 1
• Guarded commands
• x gt 0 xy1
• If-then-else
• (x gt 0 xx1) (!(x gt 0) xx-1)

guard
assignment
19
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

20
Asynchronous Composition

• Asynchronous composition is equivalent to logical
  OR if composed actions have the same next state
  variables
• a1 i gt 0 i i 1
• a2 i lt 0 i i 1
• a3 a1 a2
• a3 (i gt 0 i i 1)
• (i lt 0 i i 1)

21
Asynchronous Composition

• Asynchronous composition preserves values of
  variables which are not explicitly updated
• a1 i gt j i j
• a2 i lt j j i
• a3 a1 a2
• a3 (i gt j i j) j j
• (i lt j j i) i i

22
Asynchronous Composition Example

• module producer_consumer
• integer produced, consumed, count
• parameterized integer size
• initial produced consumed count 0
• restrict size gt 1
• producer count lt size count count 1
• produced produced 1
• consumer count gt 0 count count 1
• consumed consumed 1
• producer_consumer producer consumer
• spec invariant(produced consumed count
• count lt size)
• endmodule

23
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

24
Synchronous Composition

• A disabled action does not block synchronous
  composition
• a1 i lt max i i 1
• a2 j lt max j j 1
• a3 a1 a2
• a3 (i lt max i i 1 i gt max i i)
• (j lt max j j 1 j gt max j j)

25
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

26
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

27
Modular Producer-Consumer Example

• module producer
• integer produced
• shared integer count
• shared parameterized integer size
• initial produced 0
• restrict sizegt1
• producer countltsize countcount1
• producedproduced1
• endmodule
• module consumer
• integer consumed
• shared integer count
• shared parameterized integer size
• initial consumed 0
• restrict size gt 1
• consumer countgt0 countcount1
• consumedconsumed1
• endmodule

• module producer_consumer
• module producer, consumer
• shared int count 0
• initial count0
• producer_consumer
• producer consumer
• spec invariant(produced
• consumed count) count lt
  size)
• endmodule

28
Temporal Properties in Action Language

• Temporal properties can be declared using high
  level temporal operators
• invariant
• eventually
• Or CTL temporal operators
• AG, AF, etc.

29
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

30
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

31
Statecharts to Action Language
Alarm

• module AlSys
• enum Alarm Shut, Op
• enum Mode On, Off
• enum Vol 1, 2
• initial AlarmShut ModeOff Vol1
• t1 AlarmShut AlarmOp ModeOn Vol1
  
• t2 AlarmShut AlarmOp ModeOff
  Vol1
• t3 AlarmOp AlarmShut
• t4 AlarmOp ModeOn ModeOff
• t5 AlarmOp ModeOff ModeOn
• ...
• AlSys t1 t2 t3
• (t4 t5) (t6 t7)
• endmodule

Shut
t1
t2
Op
t3
Mode
Vol
On
1
t4
t5
t6
t7
Off
2
32
SCR

• Tabular specifications
• Mode transition tables
• Condition tables
• Event tables
• Events
• _at_T(c) ?c ? c
• In action language !c c
• _at_T(c) WHEN d ?c ? c ? d
• In action language !c c d

33
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

34
SCR to Action Language

• module HeaterACSys
• enum HeaterOn, Off
• enum ACOn, Off
• int temp
• parameterized int low, high
• initial lowlttemplthigh
• HeaterACOff
• r1 !(templtlow) templtlow
• HeaterOff HeaterOn
• r2 !(tempgtlow) tempgtlow HeaterOn
  HeaterOff
• t_heat r1 r2
• ...
• HeaterACSys t_heat t_AC
• endmodule

Heater
AC
35
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

36
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

37
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

38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
(No Transcript)