Petri Nets & Performance Evaluation - Universidad de Zaragoza

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation Javier Campos Departamento de Informática e Ingeniería de Sistemas Universidad de Zaragoza, Spain [email protected]

LSI-UPC Barcelona, June 2007

Course details 15 lectures of 50 minutes Topics:

Formal models of concurrent systems, Petri nets Qualitative and quantitative (performance) analysis Software performance engineering

Slides available at:

http://webdiis.unizar.es/~jcampos/barcelona07.pdf

Bibliography:

At the end of each lecture

Orientation:

Post-graduate (master/PhD)

Javier Campos. Petri nets and performance modelling

2

Contents Introduction to discrete event systems Petri nets: definitions, modelling and examples Functional properties and analysis techniques Time augmented Petri nets Performance evaluation with PNs: classic technique Structure based performance analysis techniques Bounds Approximations Kronecker algebra-based exact solution

Software performance engineering with UML and PNs Javier Campos. Petri nets and performance modelling

3

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 1. Introduction to discrete event systems

Javier Campos Departamento de Informática e Ingeniería de Sistemas Universidad de Zaragoza, Spain [email protected]

Outline Basic concepts Formal models

Javier Campos. Petri nets and performance modelling: 1. Introduction to DES

5

Basic concepts Discrete Event Systems (DES): Systems whose state variables are seen/considered discrete (they take values in N or in a fixed alphabet) The state space is discrete Changes of state are due to events

Time is a singular variable Synchronous systems: a clock −accesible from all nodes of the system− exists Î strong synchronization of clocks Î total order of events Asynchronous systems: there is no global time Î events are ordered by causal relations Î partial order of events

… Javier Campos. Petri nets and performance modelling: 1. Introduction to DES

6

Basic concepts Discrete Event Systems (cont.): … DES appear in several application domains Integrated manufacturing, Protocol engineering, Logistics, Computer architecture, Software engineering…

There exist simulation languages for DES with constructors valid to represent: Jobs/activities, resources, duration of activities, logic validation…


7

Basic concepts Discrete? / continuous? 1) Discrete, n ∈ {0, 1, 2} 2) Continuous, n ∈ (0, nmax) 3) Discrete: molecules 4) ¿…?

Predator/prey problem Volterra-Lotka equation


8

Basic concepts Models Abstraction of reality Physical model Simulation program Textual/graphic description Formal model

DES: many complex/paradoxical situations ⇒ Interest of formal models


9

Outline Basic concepts Formal models


10

Formal models Advantages using formal models

Better comprehension (avoid ambiguities and contradictions; identify properties; suggest potential solutions…) Increase the confidence level on the design Help in the correct dimensioning Help in the implementation and documentation Increase re-usability

Need of formal methods is well-accepted in mature engineering domains (vs. emerging) Javier Campos. Petri nets and performance modelling: 1. Introduction to DES

11

Formal models Formal models: credibility versus tractability Reality

Mod 1

Mod 2

Mod 3

Mod 4

Not very credible Very tractable Relatively credible Tractable Credible Relatively tractable

size Real system

Very credible Intractable

complexity Javier Campos. Petri nets and performance modelling: 1. Introduction to DES

12

Formal models Maturity of a scientific/technical discipline Formalisms Models (paradigmatic) Analysis/synthesis techniques Tools (automated) to build/analyse/implement Standardization: Norms (ISO, CCITT, ...)

First DES problem:

No consensus on a “better formalism” (it does not exist a formalism so concise and tractable as differential equations for continuous systems)


13

Formal models It does not exist a single formalism… Life cycle: family of formalisms (each one adapted for a given phase) Paradigm:

An entire constellation of beliefs, values and techniques, and so on, shared by the members of a given community. A conceptual framework for reducing the chaotic mass to some form of order. The total pattern of perceiving, conceptualizing, acting, validating, and valuing associated with a particular image of reality that prevails in a science or a branch of sience (T. Kuhn).

Modelling paradigm:

Conceptual framework allowing to obtain formalisms from some common (few and basic) concepts and principles. Conceptual and operative economy Coherence


14

Formal models Formalisms for the modelling of DES Sequential

Functional (untimed)

Regular expresions, grammars… Automata, state diagrams, abstract state machines… + Probabilistic/possibilistic extensions…

Timed

Timed automata (deterministic, probabilistic, possibilistic…) Markov chains…

Concurrent

Functional (untimed)

Product automata Petri nets Process algebras (CCS, CSP…)

Timed

Queueing networks Conjunctive/disjunctive graphs (PERT, GERT…) Max-plus algebras Timed Petri nets (deterministic, stochastic, fuzzy…) Timed process algebras (deterministic, stochastic, fuzzy…)


15

Formal models Examples of problems Nederland intercity train network Minimum periods Used periods, flexibility Efect of mutual waitings between trains (synchronizations) Critical lines Fleet and distribution to guarantee minimum period Optimum lines structure Dynamics after specific perturbations Variability of service under stochastic hypothesis


16

Formal models Main basic modelling approaches (M. Bunge) Descriptive / analytic (what is?) Internal representation: System: objects + relations States, events producing changes “Process” is not a primitive concept Automata, Petri nets, Markov chains, Queueing networks

Constructive / processes-based (how is observed?) External representation (I/O) “Process” is a primitive concept System: set of processes + synchronization constraints Structured processes Regular expressions, Process algebras


17

Formal models Petri nets (vector addition systems) Duality states and events

Place: state variable Transition: state transformer Marking: value of state

State equation (but…) Dependency (sequentialization) and independency (parallelism) of events. Causal structure True concurrency (versus interleaved sequential observations) Temporal realism (performance, scheduling) Locality (states and actions) Æ design methodologies (top-down, bottom-up)


18

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 2. Petri nets: definitions, modelling and examples


Outline Basic concepts Definition State equation Modelling features and examples Bibliography

Javier Campos. Petri nets and performance modelling: 2. Petri nets

20

Basic concepts Petri nets: A formal, graphical, executable technique for the specification and analysis of concurrent, discrete-event dynamic systems; a technique undergoing standardisation. http://www.petrinets.info/


21

Basic concepts Formal: The technique is mathematically defined. Many static and dynamic properties of a PN (and hence a system specified using the technique) may be mathematically proven.


22

Basic concepts Graphical: The technique belongs to a branch of mathematics called graph theory. A PN may be represented graphically as well as mathematically. The ability to visualise structure and behaviour of a PN promotes understanding of the modelled system. Software tools exist which support graphical construction and visualisation.


23

Basic concepts Executable: A PN may be executed and the dynamic behaviour observed graphically. PN practitioners regard this as a key strength of the PN technique, both as a rich feedback mechanism during model construction and as an aid in communicating the behaviour of the model to other practioners and lay-persons. Software tools exist which automate execution.


24

Basic concepts Specification: System requirements expressed and verified (by formal analysis) using the technique constitute a formal system specification.


25

Basic concepts Analysis: A specification in the form of a PN model may be formally analysed, to verify that static and dynamic system requirements are met. Methods available are based on Occurrence graphs (state spaces), Invariants and Timed PN. The inclusion of timing enables performance analysis. Modelling is an iterative process. At each iteration analysis may uncover errors in the model or shortcomings in the specification. In response the PN is modified and reanalysed. Eventually a mathematically correct and consistent model and specification is achieved. Software tools exist which support and automate analysis.


26

Basic concepts Concurrent: The representation of multiple independent dynamic entities within a system is supported naturally by the technique, making it highly suitable for capturing systems which exhibit concurrency, e.g., multi-agent systems, distributed databases, client-server networks and modern telecommunications systems. Javier Campos. Petri nets and performance modelling: 2. Petri nets

27

Basic concepts Discrete-event dynamic system: A system which may change state over time, based on current state and state-transition rules, and where each state is separated from its neighbour by a step rather than a continuum of intermediate infinitesimal states. Often falling into this classification are information systems, operating systems, networking protocols, banking systems, business processes and telecommunications systems.


28

Basic concepts Standardisation: 2004-12-02 Achieved Published Standard status: ISO/IEC 15909-1:2004 Software and system engineering - High-level Petri nets - Part 1: Concepts, definitions and graphical notation. Available from ISO, SAI Global and others. 2005-06-23 New Working Draft of ISO/IEC 15909-2 Software and Systems Engineering - High-level Petri Nets Part 2: Transfer Format submitted for a combined ISO/IEC SC7 WD/CD registration and CD ballot. Comments welcomed - formal or otherwise. [ Editor's Announcement | ISO/IEC 15909-2 WD (Version 0.9.0) ]


29



30

Definition Graphical representations Useful to inform about model structure a picture is better than a thousand words

Continuous systems: Circuits diagrams Block diagrams Bond graphs …

Discrete event systems: State diagrams Algorithmic state machines PERTs QNs …


31

Definition In Petri Nets: two basic concepts (→ graphical objects) states/data (PLACES) actions/algorithms (TRANSITIONS)

+ weight (labeling) of the arcs


32

Definition Autonomous Petri nets (place/transition nets or P/T nets) Petri Nets is a bipartite valued graph

Places: states/data (P) Transitions: actions/algorithms (T) Arcs: connecting places and transitions (F) Weights: labeling the arcs (W) (“ordinary nets” Æ weights = 1)

N = < P, T, F, W >

inscriptions in the arcs PRE

POST


33

Definition Net Î Static part

Places : State variables (names) Transitions: Changes in the state (conditions)

Marking Î Dynamic part

Marking : State variables (values)

Event/Firing

Enabling: the pre-condition is verified Firing: change in the marking

the pre-condition “consumes” tokens the post-condition “produces” tokens

3

2


4

⇒

3

2

4

34

Definition PN syntactic subclasses State machines Subclass of ordinary PN (arc weights = 1) Neither synchronizations nor structural parallelism allowed Model systems with a finite number of states Their analysis and synthesis theory is wellknown


1 a

f 6

4 c

e 5

d

35

Definition PN syntactic subclasses (cont.) Marked Graphs

1

Subclass of ordinary PN (arc weights = 1)

Allow synchronizations and parallelism but not allow decisions No conflicts present Allow the modeling of infinite number of states Their analysis and synthesis theory is well-known


a 2

4 c

b 3

5 d

36

Definition PN syntactic subclasses (cont.) Free-Choice nets

Subclass of ordinary PN (arc weights = 1) Allow synchronizations, parallelism and choices Choices and synchronizations cannot be present in the same transition Their analysis and synthesis theory is well-known

1 a

f

2

6

4 c

b 3

e 5

d

Every outgoing arc from a place is either unique or is a unique incoming arc to a transition.


37

Definition PN syntactic subclasses (cont.) Extended free-choice If two places have some common output transition, then they have all their output transitions in common.

Simple (or asymmetric choice) If two places have some common output transition, then one of them has all the output transitions of the other (and possibly more).

And other… (modular subclasses)


38



39

State equation PN and its algebraic representation based on state equation Linear representation of PNs, the structure:

N =< P,T , Pre, Post > Pre-incidence matrix Pre( p,t ): PxT → N

(Æ{0,1} for ordinary nets)

+

Post-incidence matrix Post ( p,t ): PxT → N

+

(Æ{0,1} for ordinary nets)

Incidence matrix, C = Post – Pre (marked) Petri Net is finally defined by:


Σ = N ,m0

40

State equation 1 a

f

2

6

4 c

b 3

p1 p2 Pre = p3 p4 p5 p6

a ⎡1 ⎢0 ⎢0 ⎢ ⎢0 ⎢0 ⎢0 ⎣

b 0 1 0 0 0 0

c 0 0 0 1 0 0

d 0 0 1 0 1 0

e 0 0 0 1 0 0

f 0⎤ 0⎥ 0⎥ ⎥ 0⎥ 0⎥ 1⎥⎦

p1 p2 Post = p3 p4 p5 p6

a ⎡0 ⎢1 ⎢0 ⎢ ⎢1 ⎢0 ⎢0 ⎣

b 0 0 1 0 0 0

c 0 0 0 0 1 0

d 1 0 0 0 0 0

e 0 0 0 0 0 1

f 0⎤ 0⎥ 0⎥ ⎥ 1⎥ 0⎥ 0⎥⎦

e 5

d

Incidence matrix C (= Post – Pre) cannot ”see” self loops


41

State equation State equation definition m( k ) [t > m( k + 1) ⇔

m( k + 1) = m( k ) + C(t ) = = m( k ) + Post (t ) − Pre(t ) ≥ 0

Integrating in one execution (sequence of firing)

m0 [ σ > m( k ) ⇒ m( k ) = m 0 + C ⋅ σ where σ (bold) is the firing counting vector of σ


42

State equation Very important: unfortunately… m( k ) = m0 + C ⋅ σ ≥ 0, σ ≥ 0 ⇒ / m0 [ σ > m ( k )


43

State equation Example (of problems): place marking bound

max m[ p ] s.t. m ∈ R(N, m0 )

≤

max m[ p ] s.t. m = m0 + C ⋅ σ ( m, σ) ∈ Nn + m

Problem: spureous solutions ⇒ semidecision


44



45

Modelling features and examples Modelling expressivity Sequences Conflicts (decisions, iterations) Concurrency and synchronizations Duality places versus transitions


46

Modelling features and examples Design methodologies:

1. Parallel composition by… synchronization

and

fusion

+ bottom-up methodology


47

Modelling features and examples Design methodologies (cont):

2. Sequential composition by refinement

+ top-down methodology


48

Modelling features and examples Design methodologies (cont): typical synchronization schemes Π1

Π2

i

S RV j 5. Fork-Joint

1. Rendezvous, RV

Π1 S1

Π2

6. Sub programa (p i ,pj están en mutex)

2. Semáforo, S

Π1

Π2 S1 ℜ

S2 S2

3. RV/Semáforo simétrico

8. Guarda (condición de lectura)

4. RV/Semáforo asimétrico (master/slave)


7. Recurso compartido ( ℜ )

49

Modelling features and examples Modelling example 1: Basic manufacturing cell producer/consumer with buffer and mutual exclusion


50

Modelling features and examples Modelling example 2: Shared memory multiprocessor two processors with similar behaviour two local memories and one shared common memory


51

Modelling features and examples Modelling example 3: Token ring LAN


52



53

Bibliography E. Teruel, G. Franceschinis, M. Silva: Untimed Petri nets. In Performance Models for Discrete

Event Systems with Synchronizations: Formalisms and Analysis Techniques, G. Balbo & M. Silva (ed.),

Chapter 2, pp. 27-75, Zaragoza, Spain, Editorial KRONOS, September 1998. Download here. Website: The Petri Nets World. http://www.informatik.uni-hamburg.de/TGI/PetriNets/

Website: The Petri Nets Bibliography.

http://www.informatik.uni-hamburg.de/TGI/pnbib/


54

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 3. Functional properties and analysis techniques


Outline Basic properties Analysis techniques Reachability graph Net transformations Convex geometry and PNs Bibliography

Javier Campos. Petri nets and performance modelling: 3. Functional analysis

56

Basic properties Concurrent/parallel systems are difficult to understand

It is easy to make mistakes Need for easy express properties and proof techniques


57

Basic properties Behavioural properties (for m0)

Boundedness: finiteness of the state space, i.e. the marking of all places is bounded

∀p ∈ P

∃ k ∈ N such that

m ( p) ≤ k

Safeness = 1-boundedness (binary marking) Mutual Exclusion: two or more places cannot be marked simultaneously (problem of shared resources) Deadlock: situation where there is no transition enabled Liveness: infinite potential activity of all transitions

∀t ∈ T , ∀m reachable, ∃m' , m [σ > m ' such that m ' [t > Home state: a marking that can be recovered from every reachable marking Reversibility: recovering of the initial marking

∀m reachable, ∃σ such that m [σ > m 0 Javier Campos. Petri nets and performance modelling: 3. Functional analysis

58

Basic properties Boundedness, deadlock, liveness…

Mutual exclusion m(p2) + m(p4) + m(p5) = 1 ⇒ mutex (p2, p4, p5)

p1 t1

t4 t2 p2

p3

(i.e., m(p2) . m(p4) = 0)

p4

3

1 t3

5 2


4

59

Basic properties Structural basic properties: (“there exists m0 …” or “for all m0 …”) They are abstractions of behavioural properties N is structurally bounded if for all m0, is bounded N is structurally live if there exists a m0 for which is live


60

Basic properties Independence of Liveness Boundedness Reversibility


61



62

Analysis techniques Analysis techniques for the computation of functional properties Enumerative Exahustive exploration of the state space, thus based on reachability graph Only valid for bounded systems Conclusions are valid only for a given m0 For unbounded systems: coverability graph Lost of part of information of state space thus we cannot conclude about some of the properties


63

Analysis techniques Analysis techniques for the computation of functional properties (cont.) Reduction/transformation of the model

→ Rules that preserve the property under study and simplify the model for the analysis of such property

Structural Based on the structure of the model, considering m0 as a parameter Make use of relation between structure and behaviour using techniques coming from… Convex geometry / linear programming (invariants) Graph theory (siphons, traps, handles, bridges…)


64



65

Reachability graph Enumerative analysis: exhaustive sequential enumeration of reachable states Problem 1: state explosion problem Problem 2: sequential enumeration ⇒ lost of information about concurrent behaviour 1

1(6)

Adding place 6 does not modify reachability graph but b and c cannot fire simultaneously.

a

a

24(6) 4

2

b

6 b

c 3

5 d

d

c

34(6)

25(6) b

c

reachability graph

35(6)


66

Reachability graph Example of “easy” solution of a conflict with a regulation net


67

Reachability graph Bounded system Ù finite reachability graph M0

1 t1

M1 0010 2

t4

3

4 t5

M2 0011

1000 M6

t5

M4 1001

M3 t1

t3

t4

t4

t3

t2

0100

t2

t1 0101

M5 1010 t5

t1

M7

t4

0110

unbounded system


68

Reachability graph Deadlock exists Ù There exists a terminal node in the RG M0

1 t2

t1

0100

M1 0010 2

t4

3

M2 0011

M3 1000

t1

t4

t4 t3

t2

t3

M4 1001

4

M3 is a deadlock Javier Campos. Petri nets and performance modelling: 3. Functional analysis

69

Reachability graph Live net Ù in all the strongly connected components of the RG all transitions can be fired Reversible net Ù there is only one strongly connected component in the RG a

M0 10103

p1

d c

p5

p4

p3

p2

d

d

01013

10101 a

b

c

a M 1 01102 b M2

c

10012

01100 b

a C1

01011

live and non-reversible system

c 10010


C2

70



71

Net transformations Kit(s) of reduction rules Rule:

Preconditions on the structure Preconditions on the marking Change of structure Change of marking

Application of the rule:

If preconditions hold then apply changes

Problems:

For a given kit of rules, there exist irreducible systems Trade-off: kit reduction power versus kit application complexity

Observation:

for some net subclasses (for instance live and bounded free choice nets) there exist complete kits of reduction rules


72

Net transformations A basic kit of reduction rules


73

Net transformations Example: a manufacturing cell


74

Net transformations Implicit places:

A place is implicit in if never is the unique constraint for the firing of its output transitions Therefore: elimination of an implicit place does not change the set of firable sequences Then: elimination of implicit places preserves liveness and synchronic properties (distance, fairness…)


75

Net transformations Implicit places (cont.): 8 5 2 p1

p2

1 4 7

3 6 9

p1 and p2 are implicit for m0 p2 is not structurally implicit Javier Campos. Petri nets and performance modelling: 3. Functional analysis

76

Net transformations Implicit places (cont.):

Place p is structurally implicit in N if for all initial marking of the other places, an initial marking of p can be defined such that p is implicit An struct. implicit place may be implicit or not 3

1

k

3

2

4

5

5 2

1

4

2

4

k=1 Javier Campos. Petri nets and performance modelling: 3. Functional analysis

k ≥2 77

Net transformations Implicit places (cont.): Property: a place p is structurally implicit if and only if ∃ y ≥ 0, y(p)=0 such that yTC ≤ C(p). Property: if p is structurally implicit and m0(p) ≥ yTm0, then p is implicit.


78



79

Convex geometry and PNs Structural analysis: Based either on convex geometry (linear algebra and linear programming), or Based on graph theory

ÆWe concentrate on first approach. Definitions: P-semiflow: y ≥ 0, yT.C = 0 T-semiflow: x ≥ 0, C.x = 0


80

Convex geometry and PNs Properties: 1.

If y is a P-semiflow, then the next token conservation law holds (or P-invariant): for all m ∈ RS(N, m0) and for all m0 ⇒ ⇒ yT. m = yT. m0. Proof: if m∈RS(N, m0) then m = m0 + C.σ, and premultiplying by yT: yT. m = yT. m0 + yT.C.σ = yT.m0

P-semiflows Î Conservation of tokens


81

Convex geometry and PNs Properties (cont.):

2. If m is a reachable marking in N, σ a fireable sequence with σ = x, and x a T-semiflow, the next property follows (or T-invariant): m [σ > m Proof: if x is a T-semiflow, m = m0+C.x = m0

T-semiflows Î Repetitivity of the marking

P and T-semiflows can be computed using algorithms based in Convex Geometry (linear algebra and linear programming)


82

Convex geometry and PNs Definitions: N is conservative ⇔ ∃ y > 0, yT.C = 0 N is structurally bounded ⇔ ∃ y ≥ 1, yT.C ≤ 0 (computable in polynomial time) Properties: pre-multiplying by y the state equation N conservative ⇒ yT. m = yT. m0 (token conservation) N structurally bounded ⇒ yT. m ≤ yT. m0 (tokens limitation)


83

Convex geometry and PNs Definitions: N is consistent ⇔ ∃ x > 0, C.x = 0 N is structurally repetitive ⇔ ∃ x ≥ 1, C.x ≥ 0 Properties: repetitive ⇒ N structurally repetitive N structurally live ⇒ N structurally repetitive N structurally live and structurally bounded ⇒ structurally repetitive and structurally bounded ⇔ consistent and conservative


84

Convex geometry and PNs Example: Producer/consumer with buffer in mutex mwait_raw + mload + mop1 + mwait_dep + mdeposit = 1 mdeposit + mobject+ mwithdrawal + mempty = 7 mop2 +mwait_free +munload +mwait_with +mwithdrawal = 1 mR +mload + mdeposit + munload + mwithdrawal = 1

[1] [2] [3] [4]

For instance, from [1]: mwait_raw ≤ 1 ⇔ pwait_raw is 1-bounded (mwait_raw = 0) OR (mload = 0) ⇒ pwait_raw and pload are in MUTEX

Non-negative invariants ⇒ ⇒ provide a decomposed view of the original model


85

Convex geometry and PNs Applications of decomposed view of the model Partial analysis Implementation of the model


86

Convex geometry and PNs Absence of deadlock if mload + mop1 + mdeposit + mop2 +munload +mwithdrawal ≥ 1 then (t2 + t3 + t5 + t6 + t8 + t10 ) is firable else if mwait_raw+ mwait_free ≥ 1 then (t1 + t7 ) is firable else (t4 + t9 ) is firable


87

Convex geometry and PNs Reversibility (with m0(empty)=7 and m0(object)=0): (Lyapunov-like proof technique potential function:V(m) = WT.m with W(p)=0 ⇔ m0(p)>0 ) if mload + mop1 + mdeposit + mop2 + + munload + mwithdrawal ≥ 1 then V(m) may decrease else if mwait_raw+ mwait_free ≥ 1 then V(m) may decrease else V(m) may decrease OR t1 is the unique firable transition (⇔ m0)


88

Convex geometry and PNs Liveness σ = t1,t2,t3,t4,t5,t9,t10,t6,t7,t8 is firable The net is reversible Then it is live

Fairness C has a unique left annuller x = (1,1,1,1,1,1,1,1,1,1)T for all scheduling: all components work!


89

Convex geometry and PNs Linear programming and PNs Example: structural marking bound of a place [LPP]

max m[ p ] s.t. m = m0 + C ⋅ σ ( m, σ) ∈ Nn + m

Polinomial time (on the net struct. size) computation Other properties can be analyzed: synchronic properties, dead transitions, mutex, etc.


90

Convex geometry and PNs General comments Advantages: Efficient computation Analysis independent of initial marking (m0 is only a parameter)

Problems: Only necessary or sufficient conditions are obtained (in general) The heart of the matter is that σ (vector) does not exactly represent σ (sequence)


91



92

Bibliography J.M. Colom, E. Teruel, M. Silva: Logical properties of P/T systems and their analysis. In

Performance Models for Discrete Event Systems with Synchronizations: Formalisms and Analysis Techniques, G. Balbo & M. Silva (ed.), Chapter 6,

pp. 185-232, Zaragoza, Spain, Editorial KRONOS, September 1998. Download here. M. Silva, E. Teruel, J.M. Colom: Linear algebraic and linear programming techniques for the analysis of net systems. Lecture Notes in

Computer Science, Lectures in Petri Nets. I: Basic Models, G. Rozenberg and W. Reisig (ed.), vol. 1491, pp. 309-373, Berlin, Springer-Verlag, 1998. Download here.


93

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 4. Time augmented Petri nets


Outline Introduction Interpreted graphs Interpreted Petri nets Bibliography

Javier Campos. Petri nets and performance modelling: 4. Time augmented PNs

95

Introduction Formalism: conceptual framework suited for a given purpose Life cycle: all phases, from preliminary design, detailed design, implementation, tuning… Different goals in each phase → → different formalisms Family of formalisms: PARADIGM


96

Introduction Why time augmenting the formalism? Autonomous Petri nets Non-determinism with respect to Which enabled transition will fire? When will it fire?

duration of activities and routing Not valid for performance evaluation (quantitative analysis: throughput, response time, average marking)


p1 t1 p2 t2

t3

p3

p4

t4

t5

97

Introduction Formalism suitable for system life cycle. Two characteristics:

Obj. PN Pr/T, CPN P/T

Timed


Ext. I/O

Fuzzy

Interv.

Det.

Stoch.

EN

Interpretations

Space Of formalisms

Auton.

HLPN

Different and interrelated abstraction levels Different interpretations

Abstraction levels

98



99

Interpreted graphs Interpreted graphs as formalisms for Discrete-Event Dynamic Systems Basic initial idea: Formalism = graph (precedence relations…) + + interpretation (meaning, control…)


100

Interpreted graphs Graphs as sequential formalisms (Valued) binary relations over a finite set (states, locations…) are represented as (valued) directed graphs Vertices (entities) Arcs (relations)

Matricial representations Adjacency (vertex-vertex) Incidence (vertex-arc) Graph Javier Campos. Petri nets and performance modelling: 4. Time augmented PNs

101

Interpreted graphs Interpretation Just the “meaning” of mathematical entities Example: locations and connections (static) typical problem: traveling salesman

Wider sense: meaning and external control of evolution Meaning of entities Connection of the model with the outside (the effect of the “rest of the world”) events and external conditions what happened? When did it happen?


102

Interpreted graphs Example (interpretation 1): state diagram

Vertices: global states (possible values of unique state variable) Arcs: transitions between states Sequentiel system (Moore like) l1 T1

A

M C

T2

2 B r2

3

4

D

A

r1

B 5

l2

r1 , r2 D

D

6

A

MAC

B r2

l2

1

C

r1

l1 , l2 C l1

7

conditions & input events → transitions output → states System evolution depends on the outside world through events and conditions represented with the input variables. Javier Campos. Petri nets and performance modelling: 4. Time augmented PNs

103

Interpreted graphs Other example (interpretation 2): Continuous Time Markov Chain State diagrams + “speed” of transitions Vertices: global states (= state diagrams) Arcs: transition rates between states l1

M

T2

2

β

B

δ

3

r2

l2 C

μ

r1 T1

A

1

D

system evolution depends on “outside” time events depend on time


4

δ

γ 6

β

5

α

γ

α 7

104

Interpreted graphs Examples of formalisms for parallel behaviour PERT (Program Evaluation and Review Technique) Vertices = events Arcs = activities (labelled with durations) Special characteristics: AND/AND logic (different from state diagrams or Markov chains) Acyclic Only one execution each time Evolution depends on “outside” time (min, max, or average) Distributed state of the system

Typical problem: Critical Path Method computation of shortest time to complete the project


105

Interpreted graphs Gordon-Newell queueing networks Vertices = stations+queues Arcs = routing of jobs

μ1

Special characteristics:

μ2

No synchronizations Parallel evolution of jobs OR/OR logic (identity of job is preserved) Distributed state of the system

μ3

μ6

π2

1−π2

π5

μ5 1−π5 μ7

μ4

Typical problems: performance queries (mean queue lengths, throughput, etc)


106

Interpreted graphs Fork-Join queueing networks

μ1

Vertices = stations Arcs = queues

μ2

Special characteristics: No decisions Only forks and joins AND/AND logic (jobs are created and destroyed) Distributed state of the system

μ4

μ3

μ6

μ5 μ7

Typical problems: performance queries (mean queue lengths, throughput, etc)


107



108

Interpreted Petri nets Abstract formalism ↔ Reality Generic meaning:

Place = state variable Marking = value of variable Transition = transformation of state Firing = event that produces transformation

Particular meanings (annotations): Place (and marking)

State of subsystem Si Condition Cj is true Resource Rk is available Stock of parts in a store…

Transition (and firing)

Subsystem Si evolves End of activity Aj A customer arrives A fail occurs…


109

Interpreted Petri nets Interpretation (relation with the environment) ⇓ Constraints over the evolution (imposed by the environment) ⇓ Reduction of non-determinism Synchronization with signals (from the environment) Time constraints

Typical interpretations: Marking diagrams (and Grafcet) Timed interpretations (time augmented Petri nets)


110

Interpreted Petri nets Timed interpretations Specification of activities and servers sensibilization → start of activity delay firing → end of activity transition → service station (# servers) Specification of: delay # servers (multi-sensibilization: single, multiple, or infinite) k servers

=

MEGAFILLING Stations Ltd. …

p

…

t

p

s

t

∞ server k


111

Interpreted Petri nets Specification of resolution of conflicts race policy (race between timed enabled transitions) preselection (random or deterministic choice)

p1 μ

t1 p2 t2

ρ1 ρ2

p3 t4

t3 p4

λ1 λ2

t5

Immediate transitions Modelling of synchronizations or routing Zero delay ⇒ p higher priority μ t in case of conflict

1

α 2

1

p2

t2

α

3

β

p3 t4


4

β

1

t3

γ

p4 λ1 λ2

t5

112

Interpreted Petri nets Reduction of the non-determinism

Define duration of activities (elapsed time from enabling to firing of a transitions) Constant Æ Timed Petri nets (TPN, Ramchandani, 1974) Interval ÆTime Petri nets (TPN, Merlin and Faber, 1976) Random (exponentially distrib.) Æ Stochastic Petri nets

(SPN, Symons, 1978; Natkin, 1980; Molloy, 1981) Random or immediate Æ Generalized Stochastic Petri nets (GSPN, Ajmone Marsan, Balbo, Conte, 1984)

Define server semantics (single/multiple/infinite) Define routing at conflicts

Race between stochastically timed transitions Preselection (probabilistic or deterministic choice)


113

Interpreted Petri nets Interpretation and logic properties

An interpretation restricts possible behaviour

Some reachable markings are not reachable anymore Analysis of qualitative properties of the autonomous model can be non conclusive t t

t'

unbounded?

t' 2

t

total deadlock?

t"

t'

live?

In general, a marking does not define a state In a SPN:

The same reachable makings than autonomous model (support of r.v. = [0,∞) and race policy gives positive probabilities to all possible outcomes of conflicts) A marking does define a state (memoryless property)


114



115

Bibliography M. Silva, E. Teruel: A systems theory perspective of discrete event dynamic systems: the Petri net paradigm. Procs. of the Symposium on

Discrete Events and Manufacturing Systems, CESA '96 IMACS Multiconference, P.Borne, J.C.

Gentina, E.Craye, S.El Khattabi (ed.), pp. 1-12, Lille, France, July 1996. Download here. M. Silva, E. Teruel: DEDS along their life-cycle: interpreted extension of Petri nets. Procs. of

IEEE International Conference on Systems, Man and Cybernetics (SMC'98), San Diego, USA, 1998. Download here.


116

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 5. Performance evaluation with PNs: classic technique


Outline Continuous time Markov chains Stochastic Petri nets CTMC-based exact analysis Bibliography

Javier Campos. Petri nets and performance modelling: 5. Performance evaluation

118

Continuous time Markov chains Stochastic process

discrete state space continuous time i

qij

j

qik k

qij is the transition rate from state i to state j Javier Campos. Petri nets and performance modelling: 5. Performance evaluation

119

Continuous time Markov chains Formally:

A CTMC is a stochastic process {X(t) | t ≥0, t ∈ lR} s.t. for all t0,...,tn-1,tn,t ∈ lR, 0≤t0 0 is removed because y·m0 = 1 implies 1·y > 0):

Γ[t1] ≥ maximum y ⋅ Pre⋅ D subject to y ⋅C = 0 y ⋅ m0 = 1 y ≥0

again, a linear programming problem (polynomial complexity on the net size)

Javier Campos. Petri nets and performance modelling: 6.1. Structure based techniques: Bounds

163

Generalization: use of visit ratios Interpretation: slowest subsystem generated by P–semiflows, in isolation

p2

p1 t2

t1 p4

p3 p 12

t5

N4

t3

N1

p5

N2

t6

t5

t4

t6

t7 p8

p7 t8

t8

p9

p9

t 10

p6

t 10

p 11

N3

t9

t9

p 10

p 10

t 11

t 11

minimal P–semiflows y1 = (1,0,1,1,0,0,1,0,1,0,0,0) y2 = (0,1,0,0,1,1,0,1,0.1,0,0) y3 = (0,0,0,0,0,0,0,0,1,1,1,0) y4 = (0,0,0,0,0,0,0,0,0,0,0,1) Γ[t1] ≥ max { (s[t5 ]+ s[t6] + s[t10])/ 3, (s[t6 ]+ s[t7] + s[t11])/ 2, s[t10] + s[t11], s[t5] }


164

Generalization: use of visit ratios Upper bound for the average interfiring time Γ[t1] ≤ ∑ v[t] s[t] = ∑ D[t] t∈T

t∈T

remember the marked graphs case (v = 1): Γ ≤ ∑ s[t] t∈T


165

Outline Preliminary comments Introducing the ideas: Marked Graphs case Generalization: use of visit ratios Improvements of the bounds A general linear programming statement Bibliography


166

Improvements of the bounds Structural improvements bounds still based only on the mean values (not on higher moments of r.v., insensitive bounds) lower bound for the average interfiring time: use of implicit places to increase the number of minimal P–semiflows upper bound for the average interfiring time: use of liveness bound of transitions to improve the bound for some net subclasses


167

Improvements of the bounds Use of implicit places Γ[t5] = qs[t3 ]+ (1− q)s[t4]

p1 q 1-q

t1

t2 p

p2

3

t3

t4 p4


p5 t5

Γ[t5] ≥ max{qs[t3],(1− q)s[t4 ]}


168

Improvements of the bounds

p1 q 1-q

t1 p2 t3 p4

p

p1 t2

t1

p

3

p2

t4

t3

q 1-q

p3

p4

5

t5

t2

p6

t4


p5 t5

Γ[t5] = qs[t3 ]+ (1− q)s[t4]

Γ[t5] ≥ max{ qs[t3 ], (1− q)s[t4 ], qs[t3] + (1− q)s[t4 ] }

in this case, we get the exact value!


169

Improvements of the bounds in general… p1 q 1-q

t1

t2

p2

p3

t3

t4 p4

p5

t5

t6

p6

p7 t7


Γ[t7] ≥ max { qs[t3] + s[t6 ] + s[t7], (1− q)s[t4 ] + s[t5 ]+ s[t 7] }


170

Improvements of the bounds in general, the bound is non-reachable Γ[t7] ≥ max { qs[t3] + s[t6 ] + s[t7],

p1 q 1-q

t1 p2

p3

t3

t4 p4

p5

t5

t6 p8 p7

p6

(1− q)s[t4 ] + s[t5 ]+ s[t7],

t2

qs[t3] + (1− q)s[t4 ]+ s[t7] } Γ[t7] = qmax{s[t5],s[t3] + s[t6 ]}+ (1− q)max{s[t 4] + s[t5 ],s[t6 ]}+ s[t7] = max { qs[t3] + s[t6 ]+ s[t7], (1− q)s[t4 ] + s[t5] + s[t7],

t7

(deterministic timing)

qs[t3] + (1− q)s[t4] + (1− q)s[t5 ] + qs[t6] + s[t7 ], qs[t5] + (1− q)s[t6] + s[t7] }


171

Improvements of the bounds Use of liveness bounds upper bound for the average interfiring time:

p1

t1

p2

t2

p4 t4

t3 p3

p5

Γ ≤ ∑ s[t] t∈T

reachable for 1-live marked graphs, but…


172

Improvements of the bounds it can be improved for k–live marked graphs

p1

t1

p2

t2

p4 t4 Γ ≤ s[t1] +

t3 p3

p5

s[t2 ] + s[t3] + s[t4 ] 2

liveness bound of t2


173

Improvements of the bounds Definitions of enabling degree, enabling bound, structural enabling bound, and liveness bound instantaneous enabling degree of a transition at a given marking

{

}

e[t](m) =sup k ∈Ν : ∀p ∈ •t, m[ p] ≥ k Pre[p, t]

2 t

e[t](m) = 2


174

Improvements of the bounds enabling bound of a transition in a given system: maximum among the instantaneous enabling degree at all reachable markings

σ eb[t] = sup⎧⎨k ∈Ν : ∃m 0 ⎯⎯→m, ∀p∈• t, m[p] ≥ k Pre[p, t]⎫⎬ ⎩ ⎭

p1

t1

p2

t2

p4 t4

t3 p3

eb[t2] = 2

p5


175

Improvements of the bounds liveness bound of a transition in a given system: number of servers available in t in steady state

σ σ′ lb[t] = sup⎧⎨k ∈Ν : ∀m ′, m 0 ⎯⎯→m ′, ∃m, m ′ ⎯⎯→m∧ ∀p∈• t, m[p] ≥ k Pre[p, t]⎫⎬ ⎩ ⎭ p1

p

2

t2

t1

p3

lb[t1] = 1 < 2 = eb[t1]

2

t3


176

Improvements of the bounds structural enabling bound of a transition in a given system: structural counterpart of the enabling bound (substitute reachability condition by m = m0 + C · σ; m,σ ≥ 0) seb [t] = maximum k subject to m 0 [p] +C[p,T]⋅σ ≥ k Pre[p, t], ∀p ∈P σ≥0

Property: For any net system seb[t] ≥ eb[t] ≥ lb[t], ∀ t. Property: For live and bounded free choice systems, seb[t] = eb[t] = lb[t], ∀t.


177

Improvements of the bounds improvement of the bound for live and bounded free choice systems: v[t] s[t] D[t] = ∑ t∈T seb[t] t∈T seb[t]

Γ[t1] ≤ ∑

this bound cannot be improved for marked graphs (using only the mean values of service times)


178



179

A general linear programming statement The idea a linear function maximize [or minimize] f (μ , χ ) subject to

any linear constraint that we are able to state for μ , χ, and other needed additional variables

linear operational laws


180

A general linear programming statement A set of linear constraints: μ = m 0 + C⋅σ

(state equation)

∑χ[t] Post[p, t] ≥ ∑ χ[t] Pre[p, t],

∀p ∈P

∑χ[t] Post[p, t] = ∑χ [t] Pre[ p, t],

∀p ∈P bounded

χ[ti ] χ[t j ]

∀ti, t j ∈T : behavioural free choice

t∈• p

t∈p•

t∈• p

ri

…

(flow balance equation)

t∈p•

=

rj

,

(e.g. Pre[P, t i ] = Pre[P, t j ])

…


181

A general linear programming statement

χ[t] s[t] ≤ χ[t] s[t] ≥

μ [p] Pre[ p, t]

,

μ [p]− Pre[ p, t] +1

…

Pre[p, t]

∀t ∈T, ∀p∈• t

(maximum throughput law)

, ∀t ∈T persistent,age memory or immediate: •t = {p} (minimum throughput law) …

μ, χ , σ ≥ 0


182

A general linear programming statement It can be improved using second order moments It can be extended to well-formed coloured nets It has been recently extended to Time Petri Nets (timing based on intervals, usefull for the modelling and analysis of real-time systems)


183

A general linear programming statement It is implemented in GreatSPN select place (transition) object ( ) click right mouse button and select “show” click again right mouse button and select “Average M.B.” (“LP Throughput Bounds”) click left mouse button for upper bound click middle mouse button for lower bound


184

A general linear programming statement Example: a shared-memory multiprocessor set of processing modules (with local memory) interconnected by a common bus called the “external bus” a processor can access its own memory module directly from its private bus through one port, or it can access non-local shared-memory modules by means of the external bus priority is given to external access through the external bus with respect to the accesses from the local processor M1

P1

M2

P2

M3

P3

M4


P4

185

A general linear programming statement Timed Well-Formed Coloured Net (TWN) model of the shared-memory multiprocessor

Average service time of timed transitions equal to 0.5 Javier Campos. Petri nets and performance modelling: 6.1. Structure based techniques: Bounds

186

A general linear programming statement The linear constraints for the LPP


187

A general linear programming statement The “automatic” results: 8 ≤ χ [e _ e _ a ] ≤ 2 11 The exact solution with exponential distribution would be

χ [e _ e _ a] = 1.71999 Improving of lower bound with more “ad hoc” constraints:

μ[Choice] = 0; b[Choice] = 0; b[Queue] = 3

The improved bound:

1 ≤ χ [e _ e _ a ] ≤ 2 Javier Campos. Petri nets and performance modelling: 6.1. Structure based techniques: Bounds

188



189

Bibliography

J. Campos, G. Chiola, J. Colom, M. Silva: Properties and Performance Bounds for Timed Marked Graphs. IEEE Transactions on Circuits and Systems I: Fundamental Theory and Applications, vol. 39, no. 5, pp. 386-401, May 1992. Download here. J. Campos, G. Chiola, M. Silva: Ergodicity and Throughput Bounds of Petri Nets with Unique Consistent Firing Count Vector. IEEE Transactions on Software Engineering, vol. 17, no. 2, pp. 117-125, February 1991. Download here. J. Campos, G. Chiola, M. Silva: Properties and Performance Bounds for Closed Free Choice Synchronized Monoclass Queueing Networks. IEEE Transactions on Automatic Control, vol. 36, no. 12, pp. 1368-1382, December 1991. Download here. J. Campos, M. Silva: Structural Techniques and Performance Bounds of Stochastic Petri Net Models. Lecture Notes in Computer Science, Advances in Petri Nets 1992, G. Rozenberg (ed.), vol. 609, pp. 352-391, Berlin, Springer-Verlag, 1992. Download here. G. Chiola, C. Anglano, J. Campos, J. Colom, M. Silva: Operational Analysis of Timed Petri Nets and Application to the Computation of Performance Bounds. Proceedings of the 5th International Workshop on Petri Nets and Performance Models, pp. 128137, Toulouse, France, IEEE-Computer Society Press, October 1993. Download here. J. Campos: Performance Bounds. In Performance Models for Discrete Event Systems with Synchronizations: Formalisms and Analysis Techniques, G. Balbo & M. Silva (ed.), Chapter 17, pp. 587-635, Zaragoza, Spain, Editorial KRONOS, September 1998. Download here.


190

Modelling and analysis of concurrent systems with Petri nets. Performance evaluation 6.2. Structure based performance analysis techniques: Approximations Javier Campos Departamento de Informática e Ingeniería de Sistemas Universidad de Zaragoza, Spain [email protected]

Outline Decomposition of models Flow equivalent aggregation Iterative algorithm: marked graphs case Iterative algorithm: general case Bibliography

Javier Campos. Petri nets and performance modelling: 6.2. Structure based techniques: Approximations

192

Decomposition of models Interest of approximation techniques

exact solution approx.

accuracy

bounds complexity


193

Decomposition of models Basic idea: reduce the complexity of the analysis of a complex system when the system is too complex/big to be solved by any exact analytical technique a simulation is too long (essentially if many different configurations must be tested or it must be included in some optimization procedure) some insights about the internal behaviour of subsystems are wanted (writing equations might help)


194

Decomposition of models Principle:

decompose the system into some subsystems original system state space size: n two subsystems state space size of each: n/10 (for example) (i.e., one order of magnitud less)

reduce the analysis of the whole system by those of the subsystems in isolation if the solution technique was, e.g., O(n3) on the state space size n, the cost of solving the isolated subsystems would be O(n3/1000), i.e. three orders of magnitud less…


195

Decomposition of models Advantages:

drastical reduction of complexity and computational requirements enables to extend the class of system that can be solved by analytical techniques

Problems and limitations

Decomposition is not easy!

“net-driven” means to use structural information of the net model to assure that “good” qualitative properties are preserved in the isolated subsystems (e.g., liveness, boundedness…)

Approximation is not exact!

problem of error estimation or at least bounding the error

Accurate techniques are usually very especific to particular problems Î need of expertise to select the adequate technique…


196

Decomposition of models Steps in an approximation technique based on decomposition: Partition of the system into subsystems: definition of rules for decomposition consideration of functional properties that must/can be preserved Characterization of subsystems in isolation: definition of unknowns and variables decisions related with consideration of mean variables or higher order moments of involved random variables consideration or not of the “outside world” need of a skeleton (high level view of the model) and characteristics considered in it Estimation of the unknown parameters: writing equations among unknowns direct or iterative technique (in this case, definition of fixed point equations) considerations on existence and uniqueness of solution computational algorithm for solving the fixed point equation (implementation aspects, convergence aspects) Javier Campos. Petri nets and performance modelling: 6.2. Structure based techniques: Approximations

197

Outline Decomposition of models Flow equivalent aggregation Iterative algorithm: marked graphs case Iterative algorithm: general case Bibliography


198

Flow equivalent aggregation The system:

Partition: p1 1 t 5

t3 p1 1 t5

t3 p1

t2

p2

p1 p6

t7

p8

t4

p7

t9

t10

t8

p10

t6

p4 t4

p9

t9

t6

p4

p3

t11

p3 t13

t2 p2

t10 p5

t12 p6

t7

p8

t11

p5 p9

t13

p7

t8


p10

t12 199

Flow equivalent aggregation Characterization of subsystems. Behaviour is characterized by: path a token takes in the PN (what percetage leave through t5 and t6) time it takes a token to be discharged p11 t5

t3

•way-in places:

p1

•sink transitions:

t5, t6

p1

t2

p2

p3 t6

p4 t4 t9

t10 p5


200

Flow equivalent aggregation Reduction of the subsystem: p11 t5

t3 p1

t2

pin p2

p3

td(n)

p

tout1(n)

t6

p4

tout2(n)

t4 t9

t10 p5

•routing rates of tout1(n) and tout2(n)? •service rate of td(n)? (marking dependent: n=M(pin)


201

Flow equivalent aggregation Aggregated system: p11 t5

t3 p1

t2

p2

p6

t7

t11

p8

p3 t13

p9

t6

p4 t4

p7

t9

t8

p10

t12

t10 p5

tout1(n)

p6

pin td(n) p

t7

t13

tout2(n) p7

t11

p8

p9

t8

p10

t12


202

Flow equivalent aggregation Estimation of the unknown parameters:

p11

Analyze the subnet in isolation with constant number of tokens delay and routing are dependent on the number of tokens in the system compute delay and routing for all possible populations

t5

t3 t2

p2

p3

p1

t6

p4 t4 t9

Parameters of the subsystem in isolation # tokens v5 thrput v6 1 2 3 4 5

0.500 0.431 0.403 0.389 0.382

0.500 0.569 0.597 0.611 0.618

t10 p5

0.400 0.640 0.780 0.863 0.914


203

Flow equivalent aggregation When the subnet is substituted back, routing and delay are going to be state dependent (n=M(pin)) tout1(n) p6 pin td(n) p

p8

t7

t13

tout2(n) p7

t11

p9

p10

t8

t12

Comparison of State Spaces & throughput #tokens # states throughput %error aggregat original

1 2 3 4 5

5 12 22 35 51

9 41 131 336 742

aggregat original

0.232 0.381 0.470 0.521 0.548

0.232 0.384 0.474 0.523 0.547

0.00 0.78 0.84 0.38

WAIT

ûser.observe_GUI_catalog(ci) {100K}

{0.1} {1K} [ ûser satisfied]select_sw(name) [not

{1sec}

Do:create_GUI(c )

{0.9} {1K} ûser.satisfied]refine_catalog(refinement)

^browser.select_sw(name) {1K} {1sec}

{1sec}

Do:add_info3

Do:add_info2 {1K} ^browser.refine_catalog(refinement_plus)

Javier Campos. Petri nets and performance modelling: 7. Software performance

334

Real example Simplified version of the LGSPN component corresponding to Alfred {1sec}

Do:add_info1 {1K} select_sw_service(info)

{1K} ^SwManager.get_catalog(info_plus) {100K} show_catalog_GUI(ci)

WAIT {0.1} {1K} [ûser satisfied]select_sw(name)

ûser.observe_GUI_catalog(ci) {100K}

{1sec}

Do:create_GUI(c)

{0.9} {1K} [not ûser.satisfied]refine_catalog(refinement)

^browser.select_sw(name) {1K}

Sw_manager. get_catalog

{1sec}

{1sec}

Do:add_info3

create_GUI

add_info1

Do:add_info2

user. observe_GUI_catalog

{1K} ^browser.refine_catalog(refinement_plus)

Alfred agent

select_sw_service select_software

browser. select_sw_browser add_info3


wait_Alfred

show_GUI_catalog refine_catalog

browser. refine_catalog add_info2

335

Real example Simplified version of the LGSPN component corresponding to the software manager agent {0.5sec..50sec}

Do:get_info {1K..100K} more_information(refinement2,ci)

{1min}

Do:create_catalog

{100K} ^browser.reply(catalog)

{1K} get_catalog(info_plus)

{1K} ^catalog.create_catalog(info_plus)

WAIT {1sec} {1K} request(info_sale)

Do:create_browser {1K} ^browser.create_browser(ci)

add_info4

Do:add_info4 {1sec} ^salesman.reply(info_sale_plus) {1K}

browser.reply_local

salesman.reply

Software manager agent browser.reply_remote

get_info

wait

request get_catalog

more_information_remote browser. create_browser more_information_local


create_catalog

336

Real example The other agents

Browser agent

Salesman Javier Campos. Petri nets and performance modelling: 7. Software performance

337

Real example Simplified version of composition between statechart LGSPN models and sequence diagram model Alfred

{1K}

Sw manager

get_catalog (info_plus) {1K}

select_sw_ service(info)

add_info4 browser.reply_local

salesman.reply

browser.reply_remote

Sw_manager. get_catalog

user. observe_GUI_catalog

request

Channel get_info

create_GUI

add_info1

wait get_catalog

show_GUI_catalog wait_Alfred refine_catalog

select_sw_service select_software

more_information_remote browser. create_browser more_information_local

create_catalog

browser. select_sw_browser

browser. refine_catalog add_info2

add_info3

Software Manager Javier Campos. Petri nets and performance modelling: 7. Software performance

Alfred 338

Real example Mobile agent-based approach: performance model


339

Real example Comparison of both approaches slow network 40

90

35

80

TUCOWS ANTARCTICA

30

TUCOWS ANTARCTICA

70

60

50

minutos

minutos

25

20

40

15 30 10

20

fast user

10 refinamientos

refinamientos 0

5

10

20

30

40

0

50

5

10

20

30

40

50

TUCOWS

4,28779693

7,891414141

15,09661836

22,16312057

29,55082742

37,28560776

TUCOWS

9,331840239

17,1998624

32,93807642

48,30917874

64,35006435

81,30081301

ANTARCTICA

5,062778453

7,208765859

11,49425287

15,69365976

20,08032129

24,72799209

ANTARCTICA

10,10713564

16,51800463

29,29115407

41,8760469

55,00550055

68,87052342

18

60

TUCOWS ANTARCTICA

16 14

40 minutos

12 minutos

TUCOWS ANTARCTICA

50

slow user

5

10

30

8 20

6 4

10

2

refinamientos refinamientos

0

5

10

TUCOWS

1,782912566

ANTARCTICA

1,868041545

0

20

30

40

50

3,242542153

6,191183754

9,082652134

12,10360687

16,35590448

3,06710833

5,462689828

7,813720894

10,26904909

12,85016705

5

6,811061163 TUCOWS ANTARCTICA 8,304268394

10

20

30

40

50

12,5502008 12,37317496

24,01536984 23,24500232

35,23608175 39,40110323

49,75124378 52,24660397

56,88282139 59,31198102

fast network Javier Campos. Petri nets and performance modelling: 7. Software performance

340

Outline Software Performance Engineering: basics A Software Performance Process Annotated UML Diagrams Integrating with Petri nets: case study Performance analysis Automation of the approach Real example Conclusions Bibliography Javier Campos. Petri nets and performance modelling: 7. Software performance

341

Conclusions Importance of integrated approach for SPE Integration of (pragmatic) software models and (formal) performance models

Integration of performance analysis in the software life cycle Methodology suitable for automation (tool)


342

Conclusions In usual software industry practice we are still close to the “fix-it-later” approach concerning non-functional requirements “make it run, make it run right, make it run fast” Important research effort on the SPE field The role of the WOSP conference series Sit together software engineers, performance modellers and analysts, and software developers

So, we are in the good direction...


343

Outline Software Performance Engineering: basics A Software Performance Process Annotated UML Diagrams Integrating with Petri nets: case study Performance analysis Automation of the approach Real example Conclusions Bibliography Javier Campos. Petri nets and performance modelling: 7. Software performance

344

Bibliography J. Campos, J. Merseguer: On the integration of UML and Petri nets in software development. Lecture Notes in Computer Science, vol. 4024, pp. 19-36, 2006. (Invited talk in 27th International

Conference on Applications and Theory of Petri Nets and Other Models of Concurrency, ICATPN 2006.)

Download here. J. Merseguer: Software Performance Engineering based on UML and Petri nets. PhD Thesis. Dpto. Informática e Ingeniería de Sistemas, Universidad de Zaragoza. March 2003. Download here.


345