/
System Modelling and Verification System Modelling and Verification

System Modelling and Verification - PowerPoint Presentation

celsa-spraggs
celsa-spraggs . @celsa-spraggs
Follow
383 views
Uploaded On 2016-07-23

System Modelling and Verification - PPT Presentation

The lecture contains material from Lothar Thiele ETH Zurich 2 Kai Lampka Processing system are everywhere and they are highly interconnected ABS gear box motor control climate control ID: 416448

states state system super state states super system variables model systems communication events statecharts time computation process message hierarchy

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "System Modelling and Verification" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

System Modelling and Verification

The lecture contains material from

Lothar

Thiele, ETH ZurichSlide2

2

Kai Lampka

Processing system

are everywhere and they are highly inter-connected

ABS

gear box

motor control

climate control

entertainment

IntroductionSlide3

3

Kai Lampka

Systems are distributed and

loosely coupled → high degree of concurrencyLarge degree of uncertainty w.r.t. timing and interaction → high degree of non-determinismSystems need to fulfill a set of (quantifiable) constraints, e.g. given in TCTL

IntroductionSlide4

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!Slide5

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 + DeploymentSlide6

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 practiceSlide7

Requirements for Modeling technique

Represent hierarchyHumans not capable to understand systems containing more than a few objects, particularly when here is feedback/complex interactionMost actual systems require more objectsHierarchy of objectsBehavioral hierarchyExamples: states, processes, procedures.Structural hierarchyExamples: processors, racks, printed circuit boardsSlide8

Requirements for

Modeling Techniques (2)Represent timing behavior/requirementsRepresent 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)Slide9

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 memoryMessage passing…Slide10

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 possibleSlide11

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

Semantic

of communication: Blocking/synchronous message passingSender 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 ()…Slide13

Semantic

of communication:Synchronous message passing: CSPCSP (communicating sequential processes) [Hoare, 1985], rendez-vous-based communication.process A..var a ... a:=3; c!a; -- output actionendprocess 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)Slide14

Semantic

of computationDiscrete State SystemsFinite state machinesPetri NetsContinuous State SystemsDifferential equationsHybrid (continous states/ discrete control states)Timed AutomataSlide15

Model of computation

No language that meets all language requirementsUse-case give needs and determines capabilities required from the modeling techniqueBut, 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!Slide16

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 UMLSlide17

Introducing Hierarchy

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

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

substatesSlide19

Default State Mechanism

Default stateFilled circleindicates sub-state entered whenever super-state is entered.Entrance point, not a state by itself!Slide20

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 historySlide21

Combining History and Default State

same meaningSlide22

Concurrency

Convenient ways of describing concurrency are required.AND-super-states: FSM is in all (marked) sub-states of a super-state.Slide23

Entering and Leaving AND-Super-States

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

Tree representation of state sets

basicstateOR-super-stateAND-super-stateYZ

XAA

CDB

E

F

I

K

L

M

G

H

A

B

E

C

D

F

M

G

H

I

K

L

A

X

Y

B

CSlide25

Computation of state sets

Computation of state sets by traversing the tree top-downbasic states: state set = stateOR-super-states: state set = union of childrenAND-super-states: state set = Subset of cartesian product of childrenABEC

DFMGH

IKLSlide26

Types of States

In StateCharts, states are either Basic states, or AND-super-states, or OR-super-states.Slide27

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

Using Timers: Example of an answering MachineSlide29

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

variablesSlide30

Syntax:

General Form of Edge LabelsEvents: Exist only for the next evaluation of the model Can be either internally or externally generatedConditions: Refer to values of variables that keep their value until they are reassignedActions: Can either be assignments for variables or creation of eventsExample: service-off [a <= 7] / service:=0event [condition] / actionalso called guardSlide31

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!Slide32

Example

e:a1:a2:c:

x

yz

e

/

a1

[c]/a2

e

:

a1

:

a2

:

c

:

true

false

true

falseSlide33

StateChart

Model execution PhasesHow 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.Slide34

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

Model of

compuationState Space exploration (step-wise execution) of a StateChart model consists of a sequence of (status, step) pairsStatus= values of all variables + set of events + current time (state)Step = execution of the three phases (state-to-state transition)Status

phase 2

phase 3phase 1Slide36

Motivation for this modus operandi: It reflects

model of clocked hardwareIn 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).Slide37

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

state diagram:

stable states

ExampleSlide39

Example

FHGI

d

c/dad

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

_

_Slide40

Example

Non-determinismACB

D

EGF

H

a

a

a

a

A,B

C,D

E,H

F,G

a

a

a

state diagram:Slide41

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

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

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 systemsSlide44

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

Deterministic?

Let tokens be arriving at FIFO at the same time.Order in which they are stored, is unknownAll orders are legal: simulators can show different behaviors for the same input, all of which are correct.