concurrency patterns November 2002 dependability engineering & Petri nets November2002 BrandenburgTechnical H IGHLY C OMPETITIVE C OMPETITION University at Cottbus, Computer Science Institute ❑ my new car ! MSR ASR C ONCURRENCY P ATTERNS ABS EBV - ESP USC A P ETRI N ET P ERSPECTIVE -- WORK IN PROGRESS -- ❑ my new software toolkit ? BOOP ASPECT M ONIKA H EINER CORE ADT OOP VDM++ TL SADT HOL JSD LOTOS VDM MASCOT RBD DFD CCS CSP OBJ Z FTA CTL/LTL SA NVP RBS MTBF MTTF MTTR mh@informatik.tu-cottbus.de http://www.informatik.tu-cottbus.de -> IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems D:\home\mh\docs\slides\dagstuhl.fm 1 / 29 mh@informatik.tu-cottbus.de 2 / 29
concurrency patterns November 2002 concurrency patterns November 2002 S OFTWARE E NGINEERING & M ODELS , F AULT P REVENTION T WO A PPROACHES ❑ Gamma, E. et al.: Design Patterns: Elements of Reusable Object-Oriented Software; Addison Wesley 1994. Problem problem ❑ Fowler, M.: Analysis Patterns, Reusable Object Models; Addison-Wesley 1997. ❑ Grand, M.: Petrinetz Petrinetz program model validation Patterns in Java, Vol. 1, A Catalog of Reusable Design Patterns Illustrated with UML; Wiley 1998. ❑ . . . modelling implementation ❑ Rising, L. (ed): Petrinetz Petrinetz model program Design Patterns in Communication Software; Cambridge Univ. Press 2001. ❑ Pont, M. J.: Patterns for Time-Triggered Embedded Systems; validation Addison-Wesley 2001. mh@informatik.tu-cottbus.de 3 / 29 mh@informatik.tu-cottbus.de 4 / 29
concurrency patterns November 2002 concurrency patterns November 2002 C ASE S TUDIES : ACADEMIC : 34 commands 14 sensors press ❑ low-level mutex algorithms ❑ Dijkstra’s philosophers arm 2 ❑ Milner’s schedulers arm 1 ❑ solitaire elevating rotary table ❑ . . . deposit belt (belt 2) robot MORE REALISTIC ❑ production cell, Karlsruhe P RODUCTION C ELL : ❑ production cell, Cottbus travelling crane feed belt (belt 1) ❑ concurrent pushers ❑ 2-hand switch ❑ plc press controller ❑ . . . mh@informatik.tu-cottbus.de 5 / 29 mh@informatik.tu-cottbus.de 6 / 29
concurrency patterns November 2002 concurrency patterns November 2002 N ET H IERARCHY : Σ I NFORMAL S AFETY R EQUIREMENTS ( 21): Top 1 press 1.1 press_go_unload_pos (PU) ❑ The press must not be moved downward, 1.1.1 lower 1.1.2 forge 1.2 press_go_load_pos (PL) if sensor 1 is true, and 1.2.1 lower 2 table t must not be moved upward, if sensor 3 is true. 2.1 table_go_load_pos 2.1.1 rotate -> Restrictions of machine mobility. 2.1.2 lower 2.2 table_go_unload_pos 2.2.1 lift 2.2.2 rotate ❑ 3 deposit_belt The press may only be closed, 3.1 deposit_belt_transporting 3.1.1 trans when no robot arm is positioned inside it. 3.1.2 deliver 4 feed_belt -> Avoidance of machine collisions. 4.1 feed_belt_transporting 4.1.1 trans 4.1.2 deliver 5 arm2 ❑ 5.1 A2U (arm2 unloading) The feed belt may only convey a blank through its light 5.1.1 A2U_rotate 5.1.1.1 barrier, if the table is in loading position. 5.1.1.2 5.1.1.3 -> Blanks are not dropped outside safe areas. 5.1.2 A2U_ungrasp 5.1.2.1 A2U_ext 5.1.2.2 A2U_ret 5.2 A2L (arm2 loading) 5.2.1 A2L_rotate ❑ Blanks may not be put into the press, if it is already 5.2.1.1 5.2.1.2 loaded. 5.2.1.3 5.2.2 A2L_grasp -> Insurance of a sufficient distance 5.2.2.1 A2L_ext 5.2.2.2 A2L_ret 6 arm1 between consecutively processed blanks. 6.1 A1L (arm1 loaded) 6.1.1 A1L_rotate 6.1.1.1 6.1.1.2 6.1.1.3 6.1.2 A1L_grasp 6.1.2.1 A1L_ext additional 6.1.2.2 A1L_ret 6.2 A1U (arm1 unloading) requirements related to design consistency: 6.2.1 A1U_rotate 6.2.1.1 6.2.1.2 6.2.1.3 6.2.2 A1U_ungrasp ❑ The robot swivel is either stopped or 6.2.2.1 A1U_ext 6.2.2.2 A1U_ret moves in exactly one direction. 7 crane 7.1 crane_unloading 7.1.1 lift 7.1.2 transport ❑ ... 7.1.3 lower 7.2 crane_loading 7.2.1 lower 7.2.2 transport 7.2.3 lift mh@informatik.tu-cottbus.de 7 / 29 mh@informatik.tu-cottbus.de 8 / 29
concurrency patterns November 2002 concurrency patterns November 2002 C OOPERATION M ODEL , B OUNDED P RODUCER C ONSUMER P ATTERN : B ASIC D ESIGN P RINCIPLES : ❑ production cell = pipeline of machines PRODUCER CONSUMER ❑ each machine ready_for_processing ready_to_produce output_area_free takes plates from some input places; input_area_free processes them; puts plates on some output places; controller processing produce processing consume input_available output_available input machine output ready_for_processing ready_to_consume region controller region THREE TYPES OF COOPERATION PATTERN ❑ cooperation region between two consecutive machines input_area_free output_area_free cooperation machine1 machine2 region table/press input_available output_available input_area_free output_area_free mutual exclusion region arms/crane ❑ mutual exclusive shared resources input_available output_available robot swivel input_area_free output_area_free (to rotate both arms) physical regions (intersection of trajectories belts of different machines) input_available output_available mh@informatik.tu-cottbus.de 9 / 29 mh@informatik.tu-cottbus.de 10 / 29
concurrency patterns November 2002 concurrency patterns November 2002 (A) I NDEPENDENT I NPUT /O UTPUT (B) D EPENDENT I NPUT /O UTPUT ❑ arms/crane: ❑ belts: step-wise synchronization with only one of the adjacent simultaneous control of input and output region controllers, necessary, ❑ pattern property, e.g. ❑ pattern property ( ¬ ( ) ) → ∨ → G A step1 input_available input_area_free ( G A step2 ¬ ∨ ∨ ( input _ available input _ area _free ∨ ∨ output _ available )) output _ area _free ❑ idle ❑ idle lock_input_area input_available input_available lock_input_area step1 -> loading step1 unlock_input_area output_area_free lock_output_area input_area_free step2 -> transporting step2 -> transporting output_area_free lock_output_area unlock_input_area step3 -> unloading input area free step3 unlock_output_area output_available unlock output area output available mh@informatik.tu-cottbus.de 11 / 29 mh@informatik.tu-cottbus.de 12 / 29
concurrency patterns November 2002 concurrency patterns November 2002 (C) M UTUALLY E XCLUSIVE I NPUT /O UTPUT A RM V ERSION 2: ❑ table/press: store free the controller must always hold a lock on one of its swivel cooperation regions; lock swivel ❑ pattern property having swivel ( ¬ ( ∨ ) ∨ G A input _ available input_area_free lock input area input_available ¬ ( ∨ )) output _ available output_area_free loading ❑ idle (and having control unlock input area over output area) input_area_free having swivel lock input area input available unlock swivel swivel step1 -> go to unload position storing swivel unlock output area lock swivel output available having swivel step2 -> ready for unloading output_area_free output area free lock output area lock output area unloading unlock output area step3 -> go to load position output_available having swivel unlock input area unlock swivel input area free swivel mh@informatik.tu-cottbus.de 13 / 29 mh@informatik.tu-cottbus.de 14 / 29
concurrency patterns November 2002 concurrency patterns November 2002 C ONTROLLER A NALYSIS : A RM V ERSION 3 store free PRODUCER CONSUMER ready for processing input_available lock input area ready to produce input_area_free output_area_free waiting for swivel swivel processing consume lock swivel produce controller processing input_available output_available loading ready to consume ready for processing unlock input area input_area_free having swivel ARMS unlock swivel ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ES swivel Y Y Y Y N N Y Y N N N N N N N N Y storing 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 output_area_free lock output area waiting for swivel swivel ELSE lock swivel 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 unloading 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 unlock output area output_available having swivel unlock swivel swivel mh@informatik.tu-cottbus.de 15 / 29 mh@informatik.tu-cottbus.de 16 / 29
Recommend
More recommend
