System Modelling and Verification

The  lecture  contains  material  from  Lothar  Thiele,  ETH  Zurich  

2

Kai Lampka

Processing system are everywhere and they are highly inter-connected

ABS gear box

motor control

climate control

entertainment

Introduction

3

Kai Lampka

²  Systems are distributed and loosely coupled → high degree of concurrency

²  Large degree of uncertainty w.r.t. timing and interaction

→ high degree of non-determinism

²  Systems need to fulfill a set of (quantifiable) constraints, e.g. given in TCTL

Introduction

Modelling and Analysis ²  System  complexity  can  not  be  grasped  by  human-­‐

beings,  at  least  as  a  whole,  see  PI-­‐Problem.  

²  How  does  one  ensure  that  a  system  design  is  free  of  systema=c  errors  and  fulfills  its  requirements?  

²  Examples:  Reac;vity  within  ;me  bound,  Deadlock-­‐freeness,  Buffer  does  not  over-­‐/underflow,  absence  of  PI,  ;ming  correctness…..  

²  Need  for  scalable  analysis  methods  of  ensure  that  system  designs  sa;sfies  predefined  proper;es.  implementa;on  and  analysis  methods!  

Source: US department of transportation (see also wikipedia.org)

Time

5

Concept of Operations

Operations & Maintenance

Implementation

Integration, Test & Verification

System Verification &

Validation

Verification & Validation

Requirements & Architecture

Detailled Design

System Engineering with the V-process

For avoiding mal-developments and costly re-design of existing systems Verification, Validation, and Testing has to be

integrated into the design process as early as possible!

Verification &

Validation

Engineering = Design and Implementation + Deployment

6

Kai Lampka

Empirical Methods Deductive Methods Real System

(Prototype) Model-based

Methodologies for evaluating System Designs

²  Simulation: behaviour is evaluated by statistics over individual runs (some snap-shots)

²  Measurement, Monitoring

²  Testing

Non-exhaustive Exhaustive

²  Analytic methods: behaviour is deduced from closed-form formulae.

²  Example: Process Networks, PN

²  State-based methods: behaviour is captured by finite graphs,

²  Examples: PN, StateCharts

Industrial practice

Requirements for Modeling technique

Represent hierarchy

²  Humans not capable to understand systems containing more than a few objects, particularly when here is feedback/complex interaction

²  Most actual systems require more objects ²  Hierarchy of objects

Behavioral hierarchy ²  Examples: states, processes, procedures.

Structural hierarchy ²  Examples: processors, racks, printed circuit boards

Requirements for Modeling Techniques (2)

² Represent timing behavior/requirements ² Represent state-oriented behavior

suitable for reactive systems and complex behavior of SW.

² Represent dataflow-oriented behavior Components send streams of data to each other.

² No obstacles for efficient implementation, of the analysis methods and the system (synthesis of skeletons)

Models of Computation: Definition

² What does it mean, “to compute”?

²  Models of computation define:

²  Components and an execution (semantic) model for computations for each component, e.g., Token-game for PN)

²  Communication model for exchange of information between components (semantic of interaction synchronous/asynchronous)

²  Shared memory ²  Message passing ²  …

Semantic of communication: Shared memory

²  Potential race conditions (inconsistent results possible) ²  Communication must be implemented as critical

section (sections at which exclusive access to resource r (e.g. shared memory) must be guaranteed).

process a { .. P(S) //obtain lock .. // critical section V(S) //release lock }

process b { .. P(S) //obtain lock .. // critical section V(S) //release lock }

Race-free access to shared memory protected by S possible

Semantic of communication: Non-blocking/asynchronous message

passing Sender does not have to wait until message has

arrived; potential problem: buffer overflow, e.g., PN without inhibitor arcs

… send () …

… receive () …

Semantic of communication: Blocking/synchronous message

passing Sender will wait until receiver has received

message, e.g., joint execution of transitions in PN (transitions are merged according to an logical AND)

… send () …

… receive () …

Semantic of communication: Synchronous message passing: CSP

CSP (communicating sequential processes) [Hoare, 1985], rendez-vous-based communication.

process A .. var a ... a:=3; c!a; -- output action end

process B .. var b ... ... c?b; -- input action end

² This basic mechanism can be found in most automata-based modelling formlisms, e.g., Timed Automata of Uppaal.

² Modeling asynchronous behaviour by explicitly modeling communication media (Queue)

Semantic of computation

Discrete State Systems

² Finite state machines

² Petri Nets

Continuous State Systems

² Differential equations

² Hybrid (continous states/ discrete control states)

²  Timed Automata

btx=

∂

∂2

2

Model of computation

²  No  language  that  meets  all  language  requirements  

²  Use-­‐case  give  needs  and  determines  capabili;es  required  from  the  modeling  technique  

²  But,  remember:    ²  Computa;on  effort  to  do  analysis  differs  

considerably!    

²  Extension  of  Formalisms:  Small  changes  in  the  modeling  technique  can  easily  result  in  undecidability  for  deciding  state  reachability!  

StateCharts

Classical  automata  not  useful  for  complex  systems  (complex  graphs  cannot  be  understood  by  humans).

Introduction of hierarchy

²  StateCharts [Harel, 1987]

²  in parts re-used in UML

Introducing Hierarchy

FSM will be in exactly one of the substates of S if S is active (either in A or in B or ..)

Definitions ² Current  states  of  FSMs  are  also  called  ac#ve  states.  

² States  which  are  not  composed  of  other  states  are  called  basic  states.  

² States  containing  other  states  are  called  super-­‐states.  ² For  each  basic  state  s,  the  super-­‐states  containing  s  

are  called  ancestor  states.  

² Super-­‐states  S  are  called  OR-­‐super-­‐states,  if  exactly  one  of  the  sub-­‐states  of  S  is  ac;ve  whenever  S  is  ac;ve.  

ancestor state of E

superstate

substates

Default State Mechanism

Default  state  

Filled  circle  indicates  sub-­‐state  entered  whenever  super-­‐state  is  entered.  

Entrance  point,  not  a  state  by  itself!  

²  For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies.

²  History and default mechanisms can be used hierarchically.

(behavior different from last slide)

k m

Saving history

Combining History and Default State

same meaning

Concurrency ² Convenient  ways  of  describing  concurrency  are  

required.  

² AND-­‐super-­‐states:  FSM  is  in  all  (marked)  sub-­‐states  of  a  super-­‐state.  

Entering and Leaving AND-Super-States

Line-­‐monitoring  and  key-­‐monitoring  are  entered  and  leW,  when  service  switch  is  operated.  

incl.

Tree representation of state sets

basic state

OR-super-state AND-super-state

Y Z

X A

A

C

D

B E F

I K L

M

G H

A B E

C D F M

G H

I K L

A

X Y

B C

Computation of state sets Computa;on  of  state  sets  by  traversing  the  tree  top-­‐down  ²  basic  states:    

 state  set  =  state  ²  OR-­‐super-­‐states:    

 state  set    =    union  of  children  ²  AND-­‐super-­‐states:    

 state  set  =        Subset  of  cartesian  product  of  children  

A B E

C D F M

G H

I K L

Types of States

In StateCharts, states are either

Basic states, or

AND-super-states, or

OR-super-states.

Timers ² Since  ;me  needs  to  be  modeled  in  embedded  

systems,  ;mers  need  to  be  modeled.  

²  In  StateCharts,  special  edges  can  be  used  for  ;meouts.  

If event a does not happen while the system is in the left state for 20 ms, a timeout will take place.

Using Timers: Example of an answering Machine

Extension of sematic to variables

²  Besides  states,  arbitrary  many  other  variables  can  be  defined.  This  way,  not  all  states  of  the  system  are  modeled  explicitly.  ²  These  variables  can  be  changed  as  a  result  of  a  state  

transi;on  (“ac#on”).    

²  State  transi;ons  can  be  dependent  on  these  variables  (“condi#on”  ).  

unstructured state space

condition

action

variables

Syntax: General Form of Edge Labels

Events: ²  Exist only for the next evaluation of the model ²  Can be either internally or externally generated

Conditions: Refer to values of variables that keep their value until they are reassigned

Actions: Can either be assignments for variables or creation of events

Example: service-off [a <= 7] / service:=0

event [condition] / action

also called guard

Events and actions “event” can be composed of several events:

²  (e1 and e2) : event that corresponds to the simultaneous occurrence of e1 and e2.

²  (e1 or e2) : event that corresponds to the occurrence of either e1 or e2, or both.

²  (not e): event that corresponds to the absence of event e.

„action“ can also be composed: (a1; a2) : actions a1 und a2 are executed in parallel.

Note: Events, states and actions are globally visible!

Example

e:

a1:

a2:

c:

x y z e/a1 [c]/a2

e:

a1:

a2:

c:

true false

true false

StateChart Model execution Phases

How are edge labels evaluated?

Three phases:

1. Effect of external changes on events and conditions is evaluated,

2. The set of transitions to be made in the current step and right hand sides of assignments are computed,

3. Transitions become effective, variables obtain new values.

Example

²  In  phase  2,  variables  a  and  b  are  assigned  to  temporary  variables.  In  phase  3,  these  are  assigned  to  a  and  b.  As  a  result,  variables  a  and  b  are  swapped.  

²  In  a  single  phase  environment,  execu;ng  the  leW  state  first  would  assign  the  old  value  of  b  (=0)  to  a  and  b.  Execu;ng  the  right  state  first  would  assign  the  old  value  of  a  (=1)  to  a  and  b.    

=>  Execu;on  is  non-­‐determinis;c,  one  needs  to  consider  all  permuta;ons.

Model of compuation

State  Space  explora;on  (step-­‐wise  execu;on)  of  a  StateChart  model  consists  of  a  sequence  of  (status,  step)  pairs  

Status= values of all variables + set of events + current time (state) Step = execution of the three phases (state-to-state transition)

Status phase 2

phase 3

phase 1

Motivation for this modus operandi: It reflects model of clocked hardware

In  an  actual  clocked  (synchronous)  hardware  system,  both  registers  would  be  swapped  as  well.  

Same separation into phases found in other languages as well, especially those that are intended to model hardware (e.g., synchronous languages, LUSTRE).

Alternative interpretation

external events

step transport of internal events

stable state

stable state

t state transitions

Unfortunately, there are several (synchronous) time-semantics for StateCharts available.

This is another possibility:

² A step is executed in arbitrarily small time.

²  Internal (generated) events exist only within the next step.

² Difference: External events can only be detected after a stable state has been reached.

state diagram: stable states

Example

Example

F H

G I

d c/d a d

C

A

B

D E

a/c

b b

a

state diagram (only stable states are represented, only a and b are external):

B

G,H

F,H

a b

a b _

a b ∨ a b _ _

_

a b ∨ a b _ _

Example Non-determinism

A C

B D

E G

F H

a

a a

a

A,B C,D

E,H

F,G

a

a

a state diagram:

Evaluation of StateCharts (1)

Pros: Hierarchy allows arbitrary nesting of AND- and OR-

super states.

Semantics defined in a follow-up paper to original paper.

Large number of commercial simulation tools available (StateMate, StateFlow/Matlab, BetterState, UML, ...)

Available „back-ends“ translate StateCharts into C or VHDL, thus enabling software or hardware implementations.

Evaluation of StateCharts (2)

Cons: Generated C programs frequently inefficient,

Not useful for distributed applications,

No description of non-functional behavior,

No object-orientation,

No description of structural hierarchy.

SDL Specification and Description Language

(SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems.

Used here as a (prominent) example of a model of computation based on asynchronous message passing.

Appropriate also for distributed systems

Communication of SDL-FSM Communication between FSMs (or “processes“) is based on message-passing, assuming a potentially indefinitely large FIFO-queue.

² Each process fetches next entry from FIFO, ² checks if input enables transition, ²  if yes: transition takes place, ²  if no: input is discarded (exception: SAVE-mechanism).

Deterministic? ² Let tokens be arriving at FIFO at the same

time.

² Order in which they are stored, is unknown

All orders are legal: simulators can show different behaviors for the same input, all of which are correct.