System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

45
System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich

Transcript of System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Page 1: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

System Modelling and Verification

The lecture contains material from Lothar Thiele, ETH Zurich

Page 2: 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

Page 3: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 4: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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 systematic errors and fulfills its requirements?

Examples: Reactivity within time bound, Deadlock-freeness, Buffer does not over-/underflow, absence of PI, timing correctness…..

Need for scalable analysis methods of ensure that system designs satisfies predefined properties. implementation and analysis methods!

Page 5: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 6: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

6

Kai Lampka

Empirical Methods Deductive MethodsReal 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

Page 7: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 8: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Requirements for Modeling Techniques (2)

Represent timing behavior/requirements

Represent state-oriented behaviorsuitable for reactive systems and complex behavior of SW.

Represent dataflow-oriented behaviorComponents send streams of data to each other.

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

Page 9: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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 …

Page 10: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 11: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Semantic of communication:Non-blocking/asynchronous message

passingSender does not have to wait until message has

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

…send ()…

…receive ()…

Page 12: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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 ()…

Page 13: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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 actionend

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

process B..var b ... ... c?b; -- input actionend

process B..var b ... ... c?b; -- input actionend

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)

Page 14: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Semantic of computation

Discrete State Systems

Finite state machines

Petri Nets

Continuous State Systems

Differential equations

Hybrid (continous states/ discrete control states) Timed Automata

bt

x

2

2

Page 15: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Model of computation

No language that meets all language requirements

Use-case give needs and determines capabilities required from the modeling technique

But, remember: Computation effort to do analysis differs

considerably! Extension of Formalisms: Small changes in the

modeling technique can easily result in undecidability for deciding state reachability!

Page 16: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 17: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Introducing Hierarchy

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

Page 18: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Definitions Current states of FSMs are also called active 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 active whenever S is active.

ancestor state of E

superstate

substates

Page 19: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Default State Mechanism

Default state

Filled circleindicates sub-state entered whenever super-state is entered.

Entrance point, not a state by itself!

Page 20: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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)

km

Saving history

Page 21: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Combining History and Default State

same meaning

Page 22: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Concurrency Convenient ways of describing concurrency are

required. AND-super-states: FSM is in all (marked) sub-

states of a super-state.

Page 23: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Entering and Leaving AND-Super-States

Line-monitoring and key-monitoring are entered and left, when service switch is operated.

incl.

Page 24: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Tree representation of state sets

basicstate

OR-super-state AND-super-state

Y Z

XA

A

C

D

B E F

I K L

M

G H

AB E

C D F M

G H

I K L

A

X Y

B C

Page 25: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Computation of state sets

Computation 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

AB E

C D F M

G H

I K L

Page 26: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Types of States

In StateCharts, states are either

Basic states, or

AND-super-states, or

OR-super-states.

Page 27: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Timers Since time needs to be modeled in embedded

systems, timers need to be modeled. In StateCharts, special edges can be used for

timeouts.

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

Page 28: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Using Timers: Example of an answering Machine

Page 29: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

transition (“action”). State transitions can be dependent on these variables

(“condition” ).

unstructuredstate space

condition

action

variables

Page 30: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 31: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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!

Page 32: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Example

e:

a1:

a2:

c:

x y z

e/a1 [c]/a2

e:

a1:

a2:

c:

truefalse

truefalse

Page 33: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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.

Page 34: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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, executing the left state first would assign the old value of b (=0) to a and b. Executing the right state first would assign the old value of a (=1) to a and b.

=> Execution is non-deterministic, one needs to consider all permutations.

Page 35: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Model of compuation

State Space exploration (step-wise execution) 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)

Statusphase 2

phase 3

phase 1

Page 36: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

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

Page 37: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Alternative interpretation

external events

steptransport of internal events

stablestate

stablestate

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

Page 38: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

state diagram:stable states

Example

Page 39: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

Example

F H

G I

d c/da d

C

A

B

D E

a/c

bb

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

_ _

Page 40: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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:

Page 41: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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.

Page 42: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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.

Page 43: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 44: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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

Page 45: System Modelling and Verification The lecture contains material from Lothar Thiele, ETH Zurich.

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.