EBV - ESP USC A P ETRI N ET P ERSPECTIVE -- WORK IN PROGRESS -- - - PowerPoint PPT Presentation

dependability engineering & Petri nets November2002 D:\home\mh\docs\slides\dagstuhl.fm 1 / 29

BrandenburgTechnical University at Cottbus, Computer Science Institute

CONCURRENCY PATTERNS

• A PETRI NET PERSPECTIVE
• - WORK IN PROGRESS --

MONIKA HEINER mh@informatik.tu-cottbus.de http://www.informatik.tu-cottbus.de

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 2 / 29

HIGHLY COMPETITIVE COMPETITION

❑ my new car ! ❑ my new software toolkit ?

• >

IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems

ABS

ESP

USC

ASR

MSR

EBV

FTA

SA

CTL/LTL

NVP RBS

RBD

MTBF MTTF MTTR

SADT

JSD

MASCOT

DFD CCSCSP

HOL

OBJ

LOTOS

VDM Z

CORE

ADT TL

VDM++

OOP

BOOP ASPECT

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 3 / 29

FAULT PREVENTION

❑ Gamma, E. et al.: Design Patterns: Elements of Reusable Object-Oriented Software; Addison Wesley 1994. ❑ Fowler, M.: Analysis Patterns, Reusable Object Models; Addison-Wesley 1997. ❑ Grand, M.: Patterns in Java, Vol. 1, A Catalog of Reusable Design Patterns Illustrated with UML; Wiley 1998. ❑ . . . ❑ Rising, L. (ed): Design Patterns in Communication Software; Cambridge Univ. Press 2001. ❑ Pont, M. J.: Patterns for Time-Triggered Embedded Systems; Addison-Wesley 2001.

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 4 / 29

SOFTWARE ENGINEERING & MODELS, TWO APPROACHES

Petrinetz Problem problem model implementation validation modelling validation Petrinetz model Petrinetz program Petrinetz program

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 5 / 29

CASE STUDIES:

ACADEMIC: ❑ low-level mutex algorithms ❑ Dijkstra’s philosophers ❑ Milner’s schedulers ❑ solitaire ❑ . . . MORE REALISTIC ❑ production cell, Karlsruhe ❑ production cell, Cottbus ❑ concurrent pushers ❑ 2-hand switch ❑ plc press controller ❑ . . .

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 6 / 29

feed belt (belt 1) deposit belt (belt 2) elevating rotary table robot arm 1 arm 2 press travelling crane

PRODUCTION CELL:

14 sensors 34 commands

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 7 / 29

INFORMAL SAFETY REQUIREMENTS ( 21):

❑ The press must not be moved downward, if sensor 1 is true, and t must not be moved upward, if sensor 3 is true.

• > Restrictions of machine mobility.

❑ The press may only be closed, when no robot arm is positioned inside it.

• > Avoidance of machine collisions.

❑ The feed belt may only convey a blank through its light barrier, if the table is in loading position.

• > Blanks are not dropped outside safe areas.

❑ Blanks may not be put into the press, if it is already loaded.

• > Insurance of a sufficient distance

between consecutively processed blanks.

additional requirements related to design consistency:

❑ The robot swivel is either stopped or moves in exactly one direction. ❑ ...

Σ

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 8 / 29

NET HIERARCHY:

Top A2U (arm2 unloading) 5.1 A2L (arm2 loading) 5.2 feed_belt_transporting 4.1 deposit_belt_transporting 3.1 table_go_load_pos 2.1 table_go_unload_pos 2.2 press_go_unload_pos (PU) 1.1 press_go_load_pos (PL) 1.2 A2U_ext 5.1.2.1 A2U_ret 5.1.2.2 5.1.1.1 5.1.1.2 5.1.1.3 A2L_ext 5.2.2.1 A2L_ret 5.2.2.2 5.2.1.1 5.2.1.2 5.2.1.3 lower 1.2.1 lower 1.1.1 forge 1.1.2 lift 2.2.1 rotate 2.2.2 rotate 2.1.1 lower 2.1.2 trans 3.1.1 deliver 3.1.2 trans 4.1.1 deliver 4.1.2 A2L_rotate 5.2.1 A2L_grasp 5.2.2 A2U_rotate 5.1.1 A2U_ungrasp 5.1.2 press 1 table 2 deposit_belt 3 feed_belt 4 arm2 5 crane_unloading 7.1 crane_loading 7.2 A1L (arm1 loaded) 6.1 A1U (arm1 unloading) 6.2 A1L_ext 6.1.2.1 A1L_ret 6.1.2.2 6.1.1.1 6.1.1.2 6.1.1.3 A1U_ext 6.2.2.1 A1U_ret 6.2.2.2 6.2.1.1 6.2.1.2 6.2.1.3 A1U_rotate 6.2.1 A1U_ungrasp 6.2.2 A1L_rotate 6.1.1 A1L_grasp 6.1.2 lower 7.2.1 transport 7.2.2 lift 7.2.3 lift 7.1.1 transport 7.1.2 lower 7.1.3 arm1 6 crane 7

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 9 / 29

COOPERATION MODEL, BASIC DESIGN PRINCIPLES:

❑ production cell = pipeline of machines ❑ each machine takes plates from some input places; processes them; puts plates on some output places; ❑ cooperation region between two consecutive machines ❑ mutual exclusive shared resources robot swivel (to rotate both arms) physical regions (intersection of trajectories

• f different machines)

input region

• utput

region machine controller machine1 machine2 cooperation region

mutual exclusion region

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 10 / 29

BOUNDED PRODUCER CONSUMER PATTERN:

CONSUMER PRODUCER

input_area_free input_available

• utput_area_free
• utput_available

belts input_area_free input_available

• utput_area_free
• utput_available

arms/crane input_area_free input_available

• utput_area_free
• utput_available

table/press controller ready_to_consume ready_for_processing

• utput_available
• utput_area_free

processing consume produce processing input_available input_area_free ready_for_processing ready_to_produce

THREE TYPES OF COOPERATION PATTERN

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 11 / 29

(A) INDEPENDENT INPUT/OUTPUT

❑ arms/crane: step-wise synchronization with only one of the adjacent controllers, ❑ pattern property, e.g. ❑

step1 input_available input_area_free

∨

( ) ¬

→

( ) GA

• utput_available

unlock_output_area step3 -> unloading

• utput_area_free

lock_output_area step2 -> transporting input_area_free unlock_input_area input_available step1 -> loading lock_input_area idle

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 12 / 29

(B) DEPENDENT INPUT/OUTPUT

❑ belts: simultaneous control of input and output region necessary, ❑ pattern property ❑

step2 input_available input_area_free ∨ ∨

(

¬ →

(

GA

• utput_area_free
• utput_available ))

∨ ∨ input area free unlock output area step3

• utput available

unlock_input_area input_available

• utput_area_free

step2 -> transporting lock_output_area step1 lock_input_area idle

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 13 / 29

(C) MUTUALLY EXCLUSIVE INPUT/OUTPUT

❑ table/press: the controller must always hold a lock on one of its cooperation regions; ❑ pattern property ❑

input_available input_area_free ∨ ( ) ¬

∨

( GA

• utput_available
• utput_area_free

∨ ( )) ¬ input area free unlock input area step3 -> go to load position

• utput area free

lock output area input available

• utput available

step2 -> ready for unloading unlock output area step1 -> go to unload position lock input area idle (and having control

• ver output area)

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 14 / 29

ARM VERSION2:

lock output area having swivel having swivel unlock input area

• utput_available

swivel unlock swivel having swivel unlock output area unloading

• utput_area_free

swivel swivel swivel lock swivel storing input_area_free unlock swivel input_available loading lock input area having swivel lock swivel store free

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 15 / 29

ARM VERSION3

lock swivel waiting for swivel having swivel unlock input area

• utput_available

swivel unlock swivel having swivel unlock output area unloading

• utput_area_free

swivel swivel swivel lock output area storing input_area_free unlock swivel input_available loading lock swivel waiting for swivel lock input area store free

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 16 / 29

CONTROLLER ANALYSIS:

ready to produce ready for processing input_area_free input_available processing produce consume processing

• utput_area_free

ready for processing ready to consume PRODUCER CONSUMER controller

• utput_available

ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N Y Y Y N N N N Y N Y Y Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y Y Y Y Y Y Y N N N Y Y Y Y ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N N Y Y N N N N N N N N Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y N Y Y Y Y Y N N N Y Y Y Y

ARMS ELSE

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 17 / 29

STEP-WISE COMPOSITION:

E.G. SUBSYSTEM: ARM1 - PRESS - ARM2

(ARMS: VERSION2)

ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N N Y Y N N N N N N N N Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y N Y Y Y Y N Y N N ? N N N input_available input_area_free producer consumer swivel ch_PA2_full ch_PA2_free

• utput_area_free
• utput_available

ch_A1P_free ch_A1P_full arm1 arm2 press

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 18 / 29

STEP-WISE COMPOSITION:

E.G. SUBSYSTEM: ARM1 - PRESS - ARM2

(ARMS: VERSION3):

ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N N Y Y N N N N N N N N Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y N Y Y Y Y Y N N N N Y Y Y input_available input_area_free producer consumer swivel ch_PA2_full ch_PA2_free

• utput_area_free
• utput_available

ch_A1P_free ch_A1P_full arm1 arm2 press

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 19 / 29

OPEN SYSTEM COARSE STRUCTURE:

ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N N Y Y N N N N N N N N Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y N Y Y Y Y Y N N N N Y Y Y producer consumer swivel ch_PA2_full ch_PA2_free ch_FT_full ch_FT_free ch_A2D_free ch_A2D_full ch_TA1_free ch_TA1_full ch_A1P_free ch_A1P_full ch_CF_full ch_CF_free ch_DC_free ch_DC_full arm1 arm2 feed_belt deposit_belt table press

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 20 / 29

CLOSED SYSTEM COARSE STRUCTURE:

ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES Y Y Y Y N N Y Y N N N N N N N N Y DTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S Y Y Y N Y Y Y Y Y N N N N Y Y Y swivel ch_PA2_full ch_PA2_free ch_FT_full ch_FT_free ch_A2D_free ch_A2D_full ch_TA1_free ch_TA1_full ch_A1P_free ch_A1P_full ch_CF_full ch_CF_free ch_DC_free ch_DC_full crane arm1 arm2 feed_belt deposit_belt table press

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 21 / 29

BASIC MOTION STEP + ENVIRONMENT:

css - change sensor state css stop_ wait_ start_ stop_ start_ stop_con start_con

• ut

ready_ running in command command fusion nodes: interface actuator states sensor states command command stop_con to_stop

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 22 / 29

MACRO NET OF BASIC MOTION STEP:

basic in

• ut

start_con stop_con start_command stop_command press_forge press_lift press_at_middle_pos press_upward press_stop press_at_upper_pos press_at_lower_pos press_up press_stop press_at_middle_pos

actual parameters, e.g.:

motion step formal parameters

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 23 / 29

MAIN LESSONS LEARNT

❑ management of medium-sized Petri nets

• > hierarchical structure + fusion nodes;

❑ the whole model is composed of a few patterns

• > bounded producer/consumer pattern
• > communication patterns

for producer/consumer pipeline

• independent input/output
• dependent input/output
• mutually exclusive input/output
• > mutex pattern
• > basic motion step pattern
• sequence
• alternative

❑ new editor feature: parameter substitution

• > library of reusable Petri net components;

❑ interleaving rule of communication and mutex synchronisation

• > lock a mutex resource always as late as possible

❑ pattern properties

• > model consistency criteria
• > to be generated for each instance

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 24 / 29

OTHER CONCURRENCY PATTERNS

❑ n mutex resource pattern

• > n=2: dining philosophers
• > pattern property (deadlock freedom):

acyclic access structure, hierarchical resource organisation [Brinch Hansen] ❑ unbounded producer/consumer pattern ❑ client/server communication pattern ❑ n layered client/server pattern

• > pattern property (deadlock freedom):

acyclic communication structure ❑ fault-tolerant basic structures ?

• > n version programming
• > recovery block scheme

event consumer producer service ack client server

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 25 / 29

N VERSION PROGRAMMING

• > parallel execution of n program versions,

followed by majority test

two equal all unequal all equal warning v3 v2 ko

• k

voting v1 fork success v3_end v3_start v2_start fail voting result v2_end v1_end v1_start start

voter

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 26 / 29

RECOVERY BLOCK SCHEME

• > alternative execution of n program versions,

each followed by acceptance test

i > 3 last i= 3 i = 2 success v3 v2 i = 1

• k

ko reset to checkpoint; acceptance test v1 set checkpoint i := 1 fail test result vi_end checkpoint start will i++

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 27 / 29

CONCLUSIONS

❑ catalogue of concurrency patterns ❑ step-wise system development + step-wise specification of system properties ❑ properties taxonomy taxonomy I general properties boundedness liveness special properties safety properties progress properties model consistency properties taxonomy II “must” properties

• >

fatal errors “maybe” properties -> warnings “fun” properties

• >

insights required -> granted

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 28 / 29

PROPERTY TAXONOMY II

❑

FATAL ERRORS

e.g. safety properties If a robot arm is loaded, its magnet is not deactivated until the robot is in its unloading position. , where ❑

WARNINGS

e.g. liveness AG( EF en( t ) ) for each transition t ❑

INSIGHTS

Is it possible, that both robot arms carry a plate at the same time? G ϕ χUψ ¬ → ( ) ϕ arm1_mag_on arm1_pickup_angle arm1_pickup_ext χ ∧ ∧ arm1_mag_off ψ arm1_release_angle arm1_release_ext ∧ = = = EF arm1_mag_on arm2_mag_on ∧ ( )

concurrency patterns November 2002 mh@informatik.tu-cottbus.de 29 / 29

CHALLENGES

❑ structured (sequential) programming [Dijkstra]

• > to avoid uncontrolled use of goto’s

STRUCTURED CONCURRENT PROGRAMMING

• > to avoid uncontrolled use of

synchronisation / communication ❑ problem frames architecture styles design patterns idioms architecture patterns