Dataflow Networks

10/5/2006 Formal methods 1Fault Tolerant SystemsResearch Group

Dataflow Networks

László Gö[email protected]

BME Méréstechnika és Információs Rendszerek Tanszék

Based on slides of Dr. András Pataricza and Dr. Tamás Bartha

mailto:[email protected]


Dataflow modeling

Nondeterministic DFN formalism– [Jonsson, Cannata]

• Structure– Dataflow Graph (DFG)

• Nodes (units)• Directed arcs (FIFO channels)

• Behavior– Firing rules: <0; in=0; 1; out=2, >

• Data– Tokens


Benefits of the methodProperty Benefit

Graphical representation, modularity, compact, hierarchy

Human readable notation

„Black box” and „white box” model

Modeling in multiple phases

Refinement rules Multilevel modeling

Direct information flow Error propagation

Data-driven operations Event driven real-time systems

Mathematical formalism Formal methods can be applied

Transformations: TTPN, PA Validation, time analysis


Formal description

• Dataflow network: tuple (N, C, S )– N : set of nodes– C : set of channels

• I: incoming channels• O: outgoing channels• IN: internal channels (between nodes)

– S : set of states

• Dataflow channel:– FIFO channel of infinite capacity– between two nodes

– state: Sc = Mc sequence of tokens

kapcsolat a külvilággal


Formal description of nodes

Dataflow node: n = (In,On,Sn,sn0,Rn,Mn), where

In – set of incoming channels

On – set of outoging channels

Sn – set of node states

sn0 – initial state of the node, sn

0 Sn

Mn – set of tokens

Rn – set of firing fules, rn Rn is a tuple (sn, Xin, s’n, Xout, )

sn – states before and after firing, s’n S

Xin – mapping of incoming channels, Xin : In Mn

Xout – mapping of outgoing channels, Xout : On Mn

– priority, N


Example

• Channels with capacity of 1• Network:

– DFN = ({n}, {in, out},– {(s,0,0), (s,ok,0), (s,0,ok), (s,ok,ok)})

• Nodes:– n = ({in}, {out}, {s}, s, {ok,0}, {r1})

• Firings:– r1=<s; in=ok; s; out=ok; 0>

nin out


DFN example (Eclipse plugin)


Evaluation of DFN

+ Interactive simulation• Validation, proof of correctness (direct/indirect)

Dinamyc properties: reachability, no deadlocks

+ Time analysis (indirect) Firing rules etxended with a probabilistic variable

+ Fault simulation (direct, discrete events) Extension of the operational model with a fault model

+ Test design (indirect) Test generation, analysis of testability, optimization of test set

• Analysis of faults (indirect) FMEA: Fault Mode and Effect Analysis, fault tree and event tree

• (Dependability analysis) (indirect) Measures: reliability, availability, Mean Time Between Failures,

…


Example: reference signal generator

Basic functionality:r0 = <s0; power_in=OK; s0;

ref_out=OK>

power_in ref_out

Analogous operation can also be modeled


Example: reference signal generator

Fault model:OK – nominal valueFTY – any other value (range)UNC – uncertain value

Extended operations (normal + erroneous +

uncertainity):

r0 = <s0; power_in=OK; s0; ref_out=OK> r1

= <s0; power_in=FTY; s1; ref_out=UNC> r2 =

<s1; power_in=OK; s1; ref_out=FTY> r3 =

<s1; power_in=FTY; s1; ref_out=FTY>


Vending machine

coin_in/out select

controller

candies_out

coin_in change select_candy

from_coin_in/out

to_coin_in/outfrom_select

to_candies_out from_candies_out

out


Model refinement for DFN

• Black box view– Only the relationship with the enviroment

• Syntactic interface: in-out channels, message types• Semantic interface: in-out messages (behaviour)

• White box view– Communication refinement

• Changing the syntactic interface of a component• In-out channels and message types may change

– State space refinement• State of nodes may change

– Structural refinement• decomposition



Model refinement:

• Multilevel modeling

• Preserving concistency of state and behavior



Generalization of black box and white box principles for dataflow networks:

• Domain refinement– Set of tokens

– Set of states

• Structural refinement– Nodes replaced with networks


Relation between elements and disjoint subsets

ai, A, R(ai) B so that R(ai) R(aj)=0 i, j

Set refinement

B1

B3

B2

a1 a2a3


Domain refinement

• Refinement of token set: M’n is a refinement

of Mn

• In-and out channels are unchanged

• Refinement of state set: S’n is a refinement

of Sn-nek

• Firing rules must be changed!


Token set refinement: example

• r1 = <on; in=a; off; out=a>

• r2 = <off; in=b; on; out=b>

• r11 = <on; in=aa; off; out=aa>

• r12 = <on; in=ab; off; out=ab>

• r21 = <off; in=ba; on; out=ba>

• r22 = <off; in=bb; on; out=bb>

n1

States on

{on}

off

{off}

Tokens a {aa, ab}

b {ba, bb}

Firing rules

r1 {r11, r12}

r2 {r21, r22}

2 1( )n n


Domain refinement: tokens


State set refinement: example

• r1 = <good; in=a; good; out=a>

• r2 = <good; in=b; fty; out=b>

• r3 = <fty; in=a; fty; out=c>

• r11 = <good; in=a; good; out=a>

• r21 = <good; in=b; cold; out=b>

• r22 = <good; in=b; hot; out=b>

• r31 = <cold; in=a; cold; out=c>

• r32 = <hot; in=a; hot; out=c>

n1

States good

{good}

fty {hot, cold}

Tokens a {a}

b {b}

c {c}

Firing rules

r1 {r11}

r2 {r21, r22}

r3 {r31, r32}

2 1( )n n


Domain refinement: example


Example: Reference signal generator

• Fault model:OK – nominal voltageFTY – any other value

• Operation: r0 = <s0; power_in=OK; s0; ref_out=OK> r1 = <s0; power_in=FTY; s0; ref_out=OK>r2 = <s0; power_in=FTY; s1; ref_out=FTY> r3 = <s1; power_in=OK; s1; ref_out=FTY> r4 = <s1; power_in=FTY; s1; ref_out=FTY>

power_in ref_out


Example: refined operation

1. State space refinement: s1 s1a, s1br0=<s0; power_in=OK; s0; ref_out=OK>r1=<s0; power_in=FTY; s0; ref_out=OK>r21=<s0; power_in=FTY; s1a; ref_out=FTY>r31=<s1a; power_in=OK; s1a; ref_out=FTY>r32=<s1b; power_in=OK; s1b; ref_out=FTY>r41=<s1a; power_in=FTY; s1b; ref_out=FTY>r42=<s1b; power_in=FTY; s1b; ref_out=FTY>

2. Token set refinement: FTY LOW, HIGH (state s0),

3. Token set refinement: FTY LOW, HIGH (state s1)



1. State space refinement: s1 s1a, s1b2. Token set refinement: FTY LOW, HIGH

(state s0) r0=<s0; power_in=OK; s0; ref_out=OK>

r11=<s0; power_in=LOW; s0; ref_out=OK>r21=<s0; power_in=HIGH; s1a; ref_out=HIGH>r31=<s1a; power_in=OK; s1a; ref_out=FTY>r32=<s1b; power_in=OK; s1b; ref_out=FTY>r41=<s1a; power_in=FTY; s1b; ref_out=FTY>r42=<s1b; power_in=FTY; s1b; ref_out=FTY>

3. Token set refinement: FTY LOW, HIGH (state s1)



1. State space refinement : s1 s1a, s1b2. Token set refinement: FTY LOW, HIGH (state s0)3. Token set refinement: FTY LOW, HIGH (state s1)

r0=<s0; power_in=OK; s0; ref_out=OK>r11=<s0; power_in=LOW; s0; ref_out=OK>r21=<s0; power_in=HIGH; s1a; ref_out=HIGH>r311=<s1a; power_in=OK; s1a; ref_out=LOW>r321=<s1b; power_in=OK; s1b; ref_out=HIGH>r411=<s1a; power_in=LOW; s1b; ref_out=LOW>r412=<s1a; power_in=HIGH; s1b; ref_out=HIGH>r421=<s1b; power_in=LOW; s1b; ref_out=HIGH>r422=<s1b; power_in=HIGH; s1b; ref_out=HIGH>

No u

nce

rtain

ity


Structure refinement

• Modification of structure

• In-out channels unchanged

• New internal channels and nodes

• State mapping: node subnet

• Token set unchanged

• Firings -> sequences of firings


Example: structure refinement

out

n1 n2

int

in

nin out

DFN ( )n


Example: structure refinement

• rn1 = <good; in=a; good; out=a>

• rn2 = <good; in=b; fty; out=b>

• rn11 = <good; in=a; good; int=a>

• rn12 = <good; in=b; fty; int=b>

• rn21 = <good; in=a; good; out=a>

• rn22 = <good; in=b; good; out=b>

• rn23 = <fty; in=a; fty; out=a>

• rn24 = <fty; in=b; fty; out=b>

n1

States good {{good, good, X},

{good, fty, X}}fty {{fty, good, X},

{fty, fty, X}}Tokens a {a}

b {b}

Firing rules

r1 {rn11; rn21;

rn11; rn23}

r2 {rn12; rn22;

rn12; rn24}

2 1( )n n


Example: Vending machine

coin_in/out select

controller

candies_out


from_coin_in/out



out


candies_out

Refinement

coin_in/out select

controller


from_coin_in/out



out

hw_logic mechanicsto_mechanics


Verification of refinement

1. Rule-based design tool2. Applicaiton of definitions (by hand)3. By using Finite State Machines (FSM)

• Structural check• Transformation of node-node and node-subnet

pairs NDFST• Bisimulation of automaton pairs


Model extension

Mechanisms to be modeled:• Faults• Impact of faults• Error propagation

Extension of the basic model (based on the fault model).


Model extension

1. Physical model (low level)– Faults are physical defects

2. Logical model (higher level)– Model perturbation

• Model extended with erroneous operation systematically• „if-then-else” or „switch-case” description

– E.g. wrong evaluation of a condition

• List of perturbations is the fault model

– Graph models• Nodes are system components• Each containging its own fault model• Wrong components propagate the error


Fault modeling

Tokens and states of nodes have to be extended New firing rules

Non-interpreted (quailitative) modeling:

• Token can be good or faulty (coloring)

• Detailed fault model multiple levels

Severity of faults:• correct• incorrect• bad• catastrophic

E.g. result of a floating point operation:

• correct• appr. correct• too small• too big


Aspects of Fault Tolerance

error-free operation <ok; in=ok; ok; out=ok; 0>

erroneous operation <fty; in=ok; fty; out=fty; 0>

internal fault <ok; ; fty; ; 0>

external fault <ok; in=fty; fty; out=fty; 0>

repair <fty; in=ok; ok; out=ok; 0>

error correction <ok; in=fty; ok; out=ok; 0>

error masking <fty; in=fty; fty; out=ok; 0>

error propagation <ok; in=fty; ok; out=fty; 0>


Application of DFN principles

• Workflow Modeling– Aim: high level modeling of the system– Analysis– Optimization– Code generation (for control flow)

• Elements– Processes– Activities– Data flow– Control flow

• Sequence• Loops• Parallelism• Switch• Etc.


A Workflow Example

RecordingEstablish

type

Policy

Premium

Reject

Basic activity

Beginning of parallel execution

End of parallel execution

PayControl flow

Selection


Verification of Workflows

Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

Model checker(SPIN )

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation



Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

IBM WebSphereIntegration Developer



Dataflow Network (generated)

• Abstract data• Hierarchic modeling • Model refinement

Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

Representation in the VIATRA2 framework

• Dataflow Network generated from parsed BPEL model



Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation

Requirements• LTL: linear temporal logical expression

Target requirement•Business level: „no unauthorized business transaction” •Implementation level: „each variable should be initialized prior to a read access”


Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation


Model checker• Evaluation of LTL expressions• Exhaustive state space traversal


Workflow (BPEL)

Formal model

(dataflow network)

Analysis model

(Promela)

SPIN modelchecker

Requirement (LTL

expression)

Positive result

Negative result +

counterexample

Simulation


ModelltranszformációModel transformationVIATRA2 framework

Documents

Dataflow Networks