Monika Heiner, Peter Deussen Petri Net Based … Technical University of Cottbus ... 5.3 Special...

Monika Heiner, Peter Deussen

Petri Net Based Qualitative Analysis- a Case Study

Reihe Informatik I-08/1995

December 1995

BTU Report I-08/1995

Petri Net Based Qualitative Analysis- a Case Study

Monika Heiner, Peter Deussen

Brandenburg Technical University of CottbusDepartment of Computer Science

Postbox 101344D-03013 Cottbus

[email protected], [email protected]

phone: (+ 49 - 355) 69 - 3885fax: (+ 49 - 355) 69 - 3830

abstract: The development of provably error-free concurrent systems is still achallenge of system engineering. Modelling and analysis of concurrent systems by meansof Petri nets is one of the well-known approaches using formal methods. To evaluate thereached practicability degree of available methods and tools to at least medium-sizedsystems, we demonstrate the Petri net based step-wise development and validation of thecontrol software of a reactive system. The validation of qualitative properties comprisestwo steps. At first, the context checking of general semantic properties is done by asuitable combination of static and dynamic analysis techniques, mainly of “classical” Petrinet theory. Afterwards, the verification of well-defined special semantic properties,especially safety properties, given by a separate specification of the required functionalityis performed by model checking. Strong emphasis has been laid on automation of theanalyses to be done.This case study has been already investigated by a lot of different formal methods. Thispaper provides the possibility to take into account also a strongly Petri net-orientedapproach to compare advantages and drawbacks inherent to different formal methods.

keywords: Parallel software/system engineering, validation, static analysis, formalmethods, Petri nets, temporal logics, control software, production cell.

December 1995 i

Contents

1 Introduction............................................................................................................. 1

2 Petri Net Based Framework of Software Validation............................................... 2

3 A Brief Introduction into Temporal Logics ............................................................ 53.1 Computational Tree Logic .................................................................................................. 5

3.2 Linear Time Temporal Logic .............................................................................................. 7

4 Case Study - Task Description................................................................................ 84.1 Model of the Production Cell.............................................................................................. 8

4.2 Requirements .....................................................................................................................11

5 Cooperation Model ............................................................................................... 135.1 Modelling.......................................................................................................................... 13

5.2 General Analysis............................................................................................................... 20

5.3 Special Analysis................................................................................................................ 235.3.1 Expressibility of system properties .................................................................... 235.3.2 Requirements Related to Design Consistency.................................................... 245.3.3 Requirements Related to Illegal Combinations of States ................................... 265.3.4 Requirements Related to Illegal Sequences of actions....................................... 26

5.4 Summary of the Main Analysis Results............................................................................ 27

6 Control Model....................................................................................................... 286.1 Modelling.......................................................................................................................... 28

6.2 General Analysis............................................................................................................... 33

6.3 Special Analysis................................................................................................................ 336.3.1 Requirements Related to Design Consistency.................................................... 346.3.2 Requirements Related to Illegal Combinations of States ................................... 346.3.3 Requirements Related to Illegal Sequences of Actions...................................... 35

6.4 Summary of the Main Analysis Results............................................................................ 37

7 Final Remarks ....................................................................................................... 37

ii BTU Report I-08/1995

List of Figures

Figure 1: Software Engineering & Petri Nets..............................................................2Figure 2: The tool kit used...........................................................................................4Figure 3: Semantics of the CTL operators ..................................................................6Figure 4: Top view of the production cell ...................................................................9Figure 5: Producer consumer relation. ......................................................................15Figure 6: Three types of cooperation pattern. ...........................................................16Figure 7: Source text examples: ................................................................................17Figure 8: Three arm versions.....................................................................................18Figure 9: Coarse structures of step-wise composition:..............................................19Figure 10: Coarse structure of the closed system........................................................20Figure 11: Petri net pattern for communication with the environment: ......................28Figure 12: Elementary motion control. .......................................................................31Figure 13: Composition of elementary motion control procedures.............................32

List of Tables

Table 1: Sensors .......................................................................................................10Table 2: Size of analysed nets and analysis efforts done (cooperation model). ......22Table 3: Comparison of PROD and INA: Time effort done to generate the

reachability graphs................................................................................ .....23Table 4: Sensor environment model ........................................................................30Table 5: Analysis effort of on-the-fly verification ...................................................36

December 1995 1

1 IntroductionThe development of provably error-free concurrent systems is still a challenge of systemengineering. Modelling and analysis of concurrent systems by means of Petri nets is oneof the well-known approaches using formal methods. To evaluate the reachedpracticability degree of available methods and tools to at least medium-sized systems, wedemonstrate the Petri net based step-wise development and validation of the controlsoftware of a reactive system - a (really existing) production cell in a metal-processingplant [Lewerentz 95].

The validation of qualitative properties comprises two steps. At first, the context checkingof general semantic properties is done by a suitable combination of static and dynamicanalysis techniques, mainly of “classical” Petri net theory. Afterwards, the verification ofwell-defined special semantic properties, especially safety properties, given by a separatespecification of the required functionality is performed by model checking. Strongemphasis has been lead on automation of the analyses to be done.

The case study has been designed as a basis for the evaluation of different kinds ofsoftware development methods. The objective is to develop verified control software,taking into account various safety conditions and performance constraints. This case studyhas been already investigated by a lot of different formal methods [Lewerentz 95], but upto now Petri nets have been used only as supplementing description. This paper providesthe possibility to consider also a strongly Petri net-oriented approach to compare advan-tages and drawbacks inherent to different formal methods.

This paper is organized as follows.

The sections of this paper can be divided into two parts. The first part comprises the nextthree sections, which have been included to make this paper self-contained. Only thosereaders, interested in more details or formal definitions, are referred to further literature.Section 2 gives a short overview of the Petri net based framework of software validationand introduces some basic terminology. After that, an informal introduction into (the usedversions of) temporal logics is provided in section 3. The essential points of the taskdescription of the discussed case study are summarized in section 4. Obviously, thesesections can be skipped by readers familiar with the quoted references.

The second part, which comprises the sections 5-7, deals with the actually new investiga-tions, we want to present. The Petri net model of the control software is developed andanalysed in two abstraction steps. Section 5 presents the more abstract cooperation modelof the machine controllers, while in section 6 the control model is developed as refinementof the cooperation model by adding the interactions with the physical devices. Section 5 aswell as section 6 follow basically the same inner structure: at first the way of modelling isoutlined and the model itself is introduced. After that, the model is analysed step-wisewith respect to general and special qualitative properties. The main results gained aresummarized at the end of these sections. Finally, section 7 comprises an outlook on furtherwork intended and open questions, which have to be solved in order to improve the Petrinet based validation.

2 BTU Report I-08/1995

2 Petri Net Based Framework of Software Validation

The (almost) complete Petri net model of the developed control software together withsamples of analysis protocol can be found in the appendix.

2 Petri Net Based Framework of Software ValidationPetri net based software engineering has been a well-know approach for more than 15years [Heiner 80]. Basically, there are two different possibilities of the role Petri nets areable to play during the software development process (see Figure 1).

When used right from the beginning, Petri nets are constructed a priori to model andprototype the concurrent aspects of the system under development, and the developer isable to predict, at the chosen abstraction level, the possible behaviour of the system. Afterbeing satisfied with the analysis result obtained, the program code (of the communicationskeleton) in the usually given implementation language can be generated.

The second approach to the use of Petri nets in concurrent software development relies onthe a posteriori generation of Petri nets from an high-level language description of thesoftware under development (interpreted as specification, implementation, or anything inbetween), see e. g. [Heiner 92, 94a].

Independent of its place within the software development cycle1), validation tries tominimize the presence of faults in the operation phase by analytical and (as far aspossible) computer-aided methods in the pre-operation phase.

1) The investigations presented in this paper are actually a mixture of both approaches. We startedwith the second one by following the Eiffel solution presented in [Casais 94a, 94b]. Encouragedby the clear net structures and the analysis results gained, we were optimistic that also a completePetri net-based development of the control software should be possible. So we changed to theapproach mentioned firstly.

problem

Petri net program

Petri netprogram

modellingimplementing

validation

validation

Figure 1: Software Engineering & Petri Nets.

December 1995 3

Concerning the type of properties to be validated, two classes of qualitative validationtechniques can be distinguished:

• Context checking deals with general qualitative properties like freedom from data orcontrol flow anomalies which must be valid in any system independent of its specialsemantics (for that reason, it is called in the following general analysis). Theseproperties are generally accepted or project-oriented consistency conditions of thestatic semantics of any program structure like boundedness and liveness.

• Verification aims at special qualitative properties like safety or robustness which aredetermined by the intended special semantics (functionality) of the system underdevelopment (to underline this fact, it is called in the following special analysis).

Both general and special analysis aim at time-less properties which should be validindependent of time. Unfortunately, that is not always obvious in the case of concurrentsystems.

Evidently, a successful general analysis is a prerequisite to prove that some special quali-tative properties will be fulfilled under any circumstances. So, the validation of qualitativeproperties can be divided into two consecutive steps, which supplement each other.

First, the context checking of general semantic properties (general analysis) has to be doneby a suitable combination of static and dynamic analysis techniques of Petri net theory, e.g.

• animation by playing the token game,

• static analyses by net reduction, structural analysis or net invariant analysis,

• dynamic analyses by complete/reduced construction of the system’s state space(reachability graph),

• model checking of temporal formulae.

Afterwards, the verification of well-defined special semantic properties (special analysis)given by a separate specification of the required functionality has to be performed.Especially for the second step it is very useful to supplement the power of “classical” Petrinet theory by the model checking approach, using temporal logic as a flexible querylanguage for asking questions about the (complete/reduced) set of reachable states.

Net-based animation aims at functional behaviour simulation by playing the token game.The results gained depend on the abstraction level of the underlying net model. But in anycase, this special version of prototyping is only a confidence-building approach unable toreplace exhaustive analysis methods.

All static analysis techniques have in common that they avoid the construction of thereachability graph. Reduction and structural analysis (e.g. deadlock trap property) corre-spond mainly to general analysis (of (un-) boundedness or (un-) liveness). The invariantanalysis supports general analysis (if the net is covered with semipositive place invariants)as well as special analysis. In the latter case, program invariants are proven by showingthe existence of related net invariants. So first, suitable program invariants have to behypothesized, and second, the related net invariants have to be found from the (in generalnon-minimal) basis of invariants provided by a net analysis tool. Generally, this is hardlymanageable for larger systems (larger concerning the size of states).


2 Petri Net Based Framework of Software Validation

Dynamic analysis techniques have to be used if the static analysis efforts were notsuccessful or if properties are wanted which cannot be analysed statically at all (e.g.freedom of dynamic conflicts, especially of those conflicts, where communication placesare involved, reversibility, firing of facts etc.).

In model checking, the reachability graph of a Petri net is interpreted as database, andtemporal logic is used as query language for asking questions about it. Therefore, allproperties can be checked which are expressible in those versions of temporal logicswhich are provided by the tool(s) used (see next section). In this way, even very largereachability graphs become manageable.

The tool kit used in this case study is sketched in Figure 2. It is available on UNIX/LINUX computers. The graphical Petri net editor PED is based on [Czichy 93] and is stillunder development to be adapted to current wishes. It supports basically the constructionof hierarchical place/transition nets. Complementary, all necessary attributes of those nettypes can be assigned, which are unsaleable by INA. The analysis tools in use1) INA

1) We had like to exploit also the promised analysis power of PEP [Best 95], but up to now we didnot succeed in installing the tool which has been become available lately.

qualitative Petri net analyzers

Petri net EDitorPED*.ped

*.net*.mif *.pnt

PRODINA

graphic and DTP programs

PostScript FrameMakerutilities

hardcopy

with filters

*.ps

hierarchical

analysisprotocols

qualitative

Figure 2: The tool kit used.

3.1 Computational Tree Logic

December 1995 5

[Starke 92] and PROD [Varpaaniemi 95] have to be understood as implementations ofwell-proven theorems of Petri net theory. As a consequence, the results obtained by thesetools can only be in terms of Petri net theory independent of any underlying specialsemantics of the net or software under test.

3 A Brief Introduction into Temporal LogicsBefore we start to develop and analyse our Petri net model, we give an informal intro-duction into temporal logics. In defining a system of temporal logic, there are two possibleviews regarding the underlying nature of time.1) One time view is that the course of timeis linear, the other one is that time has a tree-like branching structure. Branching timetemporal logic is discussed in section 3.1, while section 3.2 deals with linear temporallogic.

3.1 Computational Tree LogicIn this section we give a brief and informal introduction to computational tree logic(CTL). For a formal definition of its syntax and semantics the reader is referred to e. g.[Ben-Ari 83].

The semantic domain of CTL, a so-called Kripke structure, is some finite set of statestogether with a binary relation on states. A path in such a structure is a sequence of statessuch that each two consecutive states are related. We assume the existence of an initialstate such that each state is reachable from . Usually the state space of some formalsystem can be viewed as a Kripke structure. The Kripke structure associated with a Petrinet is given by its reachability graph. In particular,

1. the set of states is given by the reachable markings,

2. markings are related by the firing rule.

CTL formulae are constructed from a set of atomic propositions, the logical connectives¬ , ∧ , ∨ , →, ↔, and the temporal operators G (read “henceforth”), F (read “eventually”),X (read “nexttime”), U (read “until”). Additionally, each of these operators is equippedwith a quantification on paths: A stands for “on all paths” and E for “on some path”. Thesemantics of the temporal operators is given as follows:

1. Throughout this paper we use directly place names p as atomic propositions: p issatisfied at a state (marking) γ iff p contains (at least) one token at γ, otherwise issatisfied.2)

2. holds for γ iff there is some path departing from γ such that ϕ holds at all nodeson this path.

1) Another classification is given by distinguishing interleaving and true concurrency semantics,which is not discussed in this paper.

2) To avoid theoretical problems we assume (and will prove) the nets under consideration to be 1-bounded.

γ0 γ0

p¬

ϕGE


3 A Brief Introduction into Temporal Logics

3. holds at γ iff there is some path departing from γ such there is some state on thispath at which ϕ holds.

4. holds at γ iff ϕ holds at some immediate successor of γ.5. holds at γ iff for some path departing from γ there is some state at which χ

holds and ϕ holds on every state preceding (including γ).

6. holds at a state γ, iff ϕ holds at each state reachable from γ.

7. holds at γ, iff on every path departing from γ there is some state at which ϕ holds.

8. holds at γ, iff ϕ holds at every immediate successor of γ.

9. holds at γ, iff on every path departing from γ there is some state at which χholds and ϕ holds on every state preceding (including γ).

Figure 3 illustrates the semantics of the temporal CTL operators, excepted the nexttime

ϕFE

ϕXE

ϕ χUE γ'γ'

ϕGA

ϕFA

ϕXA

ϕ χUA γ'γ'

χ

ϕ

ϕ

ϕ

ϕ

ϕ

•

•

ϕχ

ϕGA

ϕFA

ϕ χUA

ϕGE

ϕFE

ϕ χUE

Figure 3: Semantics of the CTL operators

3.2 Linear Time Temporal Logic

December 1995 7

operators and .

We say that a system (a Petri net) satisfies a CTL formula ϕ iff ϕ holds at the initial state(initial marking) of the Kripke structure associated with the system.

If the state space of some formal system is finite, the validity of a CTL formula for thatsystem can be checked by constructing its state space, i. e. to check whether the statespace is a model of this formula or not. As we will see later, the Petri nets under devel-opment are (1-) bounded which implies the finiteness of their reachability graphs.

The reachability graph analysis tool PROD [Varpaaniemi 95] supports an efficient gener-ation of the state space of a place/transition net1). PROD consists of four separate programcomponents controlled by a make-like batch program prod. A compiler, prpp, translatesthe net description in the C-language source code of a reachability graph generator. Aftercompiling, the generator is invoked to obtain the state space of the net. A program strongis used to compute the strongly connected components of the reachability graph. Forfurther analysis the query language interpreter probe has to be applied. probe’s querylanguage implements search strategies for paths which enjoy certain properties given byconditions on states located on those paths. The CTL operators described above can beimplemented in that language.

3.2 Linear Time Temporal LogicAs outlined in the previous section, CTL supports a general quantification on computationpaths of a formal system. In linear temporal logic (LTL) there is no such quantification: ALTL formula holds for a system iff it holds for every computation path. Again we give abrief introduction in LTL. For more information see e. g. [Emerson 90].

LTL formulae are constructed from a set of atomic propositions representing systemstates, the logical primitives ¬ , ∧ , ∨ , →, ↔, and the temporal operators G, F, U, and X.The temporal operators are not equipped, in difference to CTL, with path quantifiers. Thesemantic domain of LTL formulae is one single infinite execution path

in a Kripke structure. Note that this definition requires the absenceof dead states (terminal nodes) in the reachability graph of a Petri net under consideration.

1. A LTL formula without a temporal operator holds for a point of time i of Γ iff it holdsfor .

2. Xϕ holds for a point i of Γ iff ϕ holds for the point of Γ.

3. Gϕ holds for a point i of Γ iff the formula ϕ holds for every point of Γ.4. Fϕ holds for a point i of Γ iff the formula ϕ holds for some point of Γ.

5. ϕ U χ holds for a point i of Γ iff there is some point of Γ such that χ holds at pointj and ϕ holds at every point of time k with .

With the exception of X, the operators above are implemented in PROD. We further add

1) PROD has been designed for the analysis of a class of high-level nets, so-called Predicate/Transi-tion Nets (Pr/T-Nets). But of course it is possible to express the elementary place/transition nets,used in this paper only, in the richer formalism of Pr/T-Nets.

ϕXE ϕXA

Γ γ0 γ1 … γi …, , , ,=

γi

i 1+

j i≥j i≥

j i≥i k j<≤


4 Case Study - Task Description

the operator W as an abbreviation:

6. ϕ W χ (read “ϕ while χ”) holds for a point i of Γ iff there is some point such thatboth ϕ and χ are true for every point between i and j but ϕ does not hold further at pointj + 1. ϕ W χ abbreviates the formula .

A system satisfies a LTL formula ϕ iff ϕ holds for the point of time 0 for every infinitecomputation path Γ departing from the initial state of the associated Kripke structure.

PROD supports the evaluation of a restricted class of LTL formulae, namely those whichdoes not contain the nexttime operator X. The reason for that restriction is that nexttime-free LTL formulae can by checked on-the-fly by constructing a reduced CFFD-equivalentreachability graph using the stubborn set method. For more information on this approachthe reader is referred to [Courcoubetis 92], [Gerth 95], [Valmari 92a], [Valmari 92b], and[Varpaaniemi 94].

4 Case Study - Task DescriptionThis section provides the basic knowledge necessary to understand the case study. Readersfamiliar with the task description included in [Lewerentz 95] may skip it.

4.1 Model of the Production CellWe are now going to describe the model of an (really existing) industrial facility whichbuilds the focus of our investigations. The production cell comprises six physical compo-nents: two conveyor belts, a rotatable robot equipped with two extendable arms, anelevating rotary table, a press, and a travelling crane (see Figure 4). The machines areorganized in a (closed) pipeline. Their common goal is the transport and transformation ofmetal plates.

The production cycle of each blank is as follows: The feed belt conveys the blank to anelevating rotary table. The table rotates and lifts to put the blank in a position where thefirst robot arm is able to grasp it. The robot fetches the blank from the table and placesthem into the press. After it is processed, the second robot arm places the blank on thedeposit belt. A travelling crane is added to the model to ensure a permanent supply bytransporting the blank back to the feed belt and making the model self-contained. We nowdescribe the devices in more detail.

Feed Belt and Deposit Belt. Both belts are powered by an electric motor which can bestarted or stopped by a control program. A photoelectric cell installed at the end of eachbelt indicates whether a blank has entered the final part of the belt. In both cases a blankmust leave the photo cell’s control area: in that position the blank drops from the feed belton the table, while the crane is able to pick up a similar located blank from the depositbelt.

Elevating rotary table. Both vertical movement and the rotation of the table arenecessary: The first robot arm is located at a different level than the feed belt and is unableto perform a vertical translation. Furthermore the arms grippers (electromagnets) are not

j i≥

ϕ χ∧( ) ϕ¬( )U

4.1 Model of the Production Cell

December 1995 9

rotary and not able to place a blank in an appropriate angle into the press by itself.

Robot. The robot consist of two extendable arms, mounted orthogonally on differentlevels, and a swivel for rotation. To grasp some blank from the table and the press, respec-tively, the arms must expand. In order to meet various safety requirements, each arm haveto be retracted while the robot rotates or the other arm performs loading or unloading ablank.

Press. The press forges metal plates by pressing its lower plate against the upper plate.Because of the placement of the robot arms on different horizontal levels, the lower plateof the press is movable into another two positions: a middle position for loading by thefirst arm and a lower position for unloading by the second arm. In the upper position ablank is forged.

Crane. The task of the crane consists of transporting metal plates from the deposit beltback to the feed belt to ensure a permanent supply of blanks without involving any furtherexternal components. Its gripper (an electromagnet) is movable in horizontal and verticaldirection. After the gripper has picked up a blank, it lifts, performs a horizontal movementback to above the feed belt, and lowers to release the blank.

Actuators and Sensors. Table 1 explains the sensors and their values that are involved inthe model. The values received from switches and light barriers is either 0 or 1: If a blankintercepts the ray of a light barrier, a value 1 is received, a value 0 otherwise. Switches areactivated if the corresponding device is in a specific position, i. e. a value 1 is received,otherwise they are deactivated and a value 0 is received. Potentiometers send a value froma certain range associated which each of them.

feed belt (belt 1)

deposit belt (belt 2)

elevating rotary table

robot

arm 1

arm 2

press

travelling crane

Figure 4: Top view of the production cell



The control protocol of the actuators is given in terms of commands summarized below:

Belt Commands: belt1_start starts the feed belt to move rightbelt1_stop stops the feed beltbelt2_start starts the deposit belt to move leftbelt2_stop stops the deposit belt

Table Commands: table_left starts rotation to the lefttable_right starts rotation to the rightstable_stop_h stops the rotationtable_upward starts upward movingtable_downward starts downward movingtable_stop_v stops the vertical moving

Robot Commands: arm1_foreward starts extension of arm 1arm1_backward starts retraction of arm 1arm1_stop stops extension/retraction of arm 1arm1_mag_on activates magnet of arm 1arm1_mag_off deactivates magnet of arm 1

a) Value 1 means that the arm is fully extended.b) Value 0 means that the magnet is in top position.

No. TypeCorresponding

deviceDescription Value

1 switch press Press in bottom position? 0, 1

2 switch Press in middle position? 0, 1

3 switch Press in top position? 0, 1

4 potentiometer robot Extension of arm 1 0..1a)

5 potentiometer Extension of arm 2 0..1a)

6 potentiometer Angle of robot rotation -100..70

7 switch table Table in bottom position? 0, 1

8 switch Table in top position? 0, 1

9 potentiometer Angle of table rotation -5..90

10 switch crane Crane above the deposit belt? 0, 1

11 switch Crane above the feed belt? 0, 1

12 potentiometer Height of the crane’s magnet 0..1b)

13 light barrier feed belt Blank inside the light barrier? 0, 1

14 light barrier deposit belt Blank inside the light barrier? 0, 1

Table 1: Sensors

4.2 Requirements

December 1995 11

arm2_foreward starts extension of arm 2arm2_backward starts retraction of arm 2arm2_stop stops extension/retraction of arm 2arm2_mag_on activates magnet of arm 2arm2_mag_off deactivates magnet of arm 2robot_left starts rotation to the leftrobot_right starts rotation to the rightrobot_stop stops rotation

Press Commands: press_upward starts press to move upwardpress_downward starts press to move downwardpress_stop stops vertical movement

Crane Commands: crane_to_belt2 starts horizontal movement towards the deposit beltcrane_to_belt1 starts horizontal movement towards the feed beltcrane_stop_h stops horizontal movementcrane_lift starts the crane’s magnet to move upwardcrane_lower starts the crane’s magnet to move downwardcrane_stop stops the movement of the crane’s magnetcrane_mag_on activates cranes’s magnetcrane_mag_off deactivates cranes’s magnet

4.2 RequirementsBasically, safety and liveness requirements are distinguished in a requirement-style speci-fication of a reactive system. Obviously, safety requirements are most important in thissetting: if a safety requirement is violated, this might result in damage of machines orinjury of people. In this section we discuss various safety requirements which are to obeyby an implementation of controllers for the production cell as given in [Lewerentz 95].These requirements are consequences of one of the following physical conditions:

1. The machine’s mobility is restricted: The robot, for instance, would destroy itself ifrotated too far; the press would damage itself if opened too far.

2. Machines would be damaged if they collide: The robot, for instance, would collide withthe press if arm 1 would extend too far while pointing towards the press.

3. Metal blanks may not be dropped outside safe areas. For instance, the control programhave to make sure that the table is in the right position before the feed belt transports ablank to the table.

4. It is necessary to keep metal plates sufficiently separate. Light barriers, for instance,can distinguish two consecutive blanks only if they have a sufficient distance.

1. Restrictions of machine mobility. The electric motors associated with the actuators 1-3 and 6-10 may not be used to move the corresponding devices further than necessary. Indetail:

Requirement 1. The robot must not be rotated clockwise, if arm 1 points towardsthe elevating rotary table, and it must not be rotated counterclockwise, if arm 1points towards the press.



Requirement 2. Both arms of the robot must not retracted less than necessary forpassing the press, and they must not extended more than necessary for picking up ablank from the press.

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

Requirement 4. The elevating rotary table must not be moved downward, if sensor7 is true, and it must not be moved upward, if sensor 8 is true.

Requirement 5. The elevating rotary table must not be rotated clockwise, if it is inthe position required for transferring blanks to the robot, and it must not be rotatedcounterclockwise, if it is in the position to receive blanks from the feed belt.

Requirement 6. If the crane is positioned above the feed belt, it may only movetowards the deposit belt, and if it is positioned above the deposit belt, it may onlymove towards the feed belt.

Requirement 7. The gripper of the crane must not be moved downward, if it is inthe position required for picking up a blank from the deposit belt, and it must not bemoved upward beyond a certain limit.

2. Avoidance of machine collisions. Collisions are possible between the press and therobot, and between the crane and the conveyor belts.

Requirement 8. The press may only close when no robot arm is positioned insideit.

Requirement 9. A robot arm may only rotate in the proximity of the press if the armis retracted or if the press is in its upper or lower position.

Requirement 10. The travelling crane is not allowed to knock against a beltlaterally (this would happen if the travelling crane is moved from the deposit belt tothe feed belt without a simultaneous vertical translation.

Requirement 11. The travelling crane must not knock against a belt from above.

3. Blanks are not dropped outside safe areas. Metal blanks can be dropped for tworeasons:

1. The electromagnets of the robot arms or the crane are deactivated.

2. A belt transports a blank to far.

To avoid these situations, it suffices to obey the following rules:

Requirement 12. The magnet of arm 1 may only be deactivated, if the arm pointstowards the press, and the arm is extended such that its gripper is within the press.

Requirement 13. The magnet of arm 2 may only be deactivated, if its magnet isabove the deposit belt.

5.1 Modelling

December 1995 13

Requirement 14. The magnet of the crane may only be deactivated, if the crane’sgripper is above the feed belt and sufficiently close to it.

Note that the requirements above are stronger than it would be necessary to guarantee thatblanks are not dropped unwanted. For the control model described in section 5 we willreformulate these requirements later.

Requirement 15. The feed belt may only convey a blank through its light barrier, ifthe table is in loading position.

Requirement 16. The deposit belt must be stopped after a blank has passed thelight barrier at its end and may only be started again after the crane has picked upthe blank.

4. Insurance of a sufficient distance between consecutively processed blanks. Errorsoccur if blanks are piled on each other, overlap, or even if they are to close for beingdistinguishable by the light barriers. To avoid these errors, it suffices to obey the followingrules:

Requirement 17. A new blank may only be put on the feed belt if sensor 14confirms that the former one has arrived at the end of the feed belt.

Requirement 18. A new blank may only be put on the deposit belt if sensor 13confirms that the former one has arrived the end of the deposit belt.

Requirement 19. Blanks may not be put on the table if it is already loaded.

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

Requirement 21. If the table is loaded, the robot arm 1 may not be moved abovethe table if it is also loaded (otherwise the two blanks collide).

5 Cooperation ModelWe are now going to develop and analyze the control software in two abstraction levels. Inthis section the more abstract cooperation model of the machine controllers is introducedand analyzed step-wise. This cooperation model has been influenced essentially by[Casais 94a, 94b].

5.1 ModellingThe production cell considered consists of seven loosely coupled machine controllers (twobelts, two robot arms, table press, crane) acting to a high degree independently of eachother. The machine controllers are organized in a (closed) pipeline. Their common goal isthe transport/transformation of metal plates through the established pipeline. For thatpurpose, neighbouring machine controllers communicate with each other according asynchronous producer/consumer pattern. There is neither a central controller of theproduction cell responsible for activating and deactivating the machines nor a global


5 Cooperation Model

observer with full knowledge of the state of the production cell and of the metal plates.

Each machine follows a similar operation pattern: fetch a metal blank from the inputregion, process it, and deposit the plate on the output region. In order to do that, eachmachine performs cyclically a certain sequence of motions (of course synchronizedaccording the states of its neighbours).

If two machines are connected, the output region of the predecessor and the input regionof the successor merge to a cooperation region between two consecutive machines.

Obviously, such a cooperation region has to be organized as a mutual exclusion region, i.e. either the predecessor is allowed to put a plate into the region or the successor has theaccess rights to take a plate from the region. But the concurrent access to the cooperationregion by the adjacent machines is forbidden.

Furthermore, due to the given machine equipment, a cooperation region does not have anybuffering capabilities. So the predecessor is allowed only to put a plate into the region, ifthe region is free, and the successor can only take a plate from the region, if it is full (seeFigure 5).

Additionally, there are two kinds of mutually exclusive shared resources.

The robot arms are organized separately to enlarge the possible degree of parallelismwithin the cell (which results maybe into an higher throughput). Doing so, the robotswivel (the engine to rotate both arms), becomes a shared resource of both arms, whichcan be used exclusively only.

There exist shared physical regions (intersection of trajectories of different machines). Toavoid machine collisions, such shared physical regions have to be used exclusively. Mostof the trouble disappears in a constructive way by the requirement that the robot arms andthe crane are only allowed to move if they are retracted and lifted, respectively.

There are three basic types of cooperation pattern according the order, in which input andoutput regions are acquired and released (see Figure 6):

A. Independent input/output:For the next operation step, the controller has to synchronize with only one of itsadjacent controllers. E. g. to take a plate from the input area, a free output area is notrequired et vice versa. This pattern is applied to arms and crane.

inputregion

outputregionmachine

machine 1 machine 2cooperationregion

mutual exclusion region

5.1 Modelling

December 1995 15

B. Dependent input/output:For the next operation cycle, the controller needs simultaneous control of input andoutput regions. This pattern is very useful to control the belts in such a way that theplates remain distinguishable. A belt is only switched on, if a new plate has beenarrived (input available) and the output area is free. So at any time, maximal two platescan be on the belt - one at each end of the belt.

C. Mutually exclusive input/output:At any time, the controller must hold a lock on one of its cooperation regions, i.e. theoutput region can only be released while having locked the input region and vice versa.This pattern is used for machines like table and press, which cannot be - at the sametime - in a position suitable for loading as well as unloading.

Now let’s consider the arms in more detail. They follow the independent input/outputcooperation pattern. But additionally, both arms have to be synchronized in order to usethe swivel only in a mutual exclusive manner. The two basic synchronization patternshave to be combined in an interleaving way.

CONSUMERPRODUCER

input area free

input available

output area free

output available

feed/deposit belt

input area free

input available

output area free

output available

arms/crane

input area free

input available

output area free

output available

table/press

controller

ready to consume

ready for processing

output available

output area free

processingconsumeproduce

input available

input area free

ready for processing

ready to produce

Figure 5: Producer consumer relation.


5 Cooperation Model

arm

s / c

rane

(ind

epen

dent

inpu

t / o

utpu

t)fe

ed /

depo

sit

belt

(dep

ende

nt in

put /

out

put)

tabl

e / p

ress

(mut

ually

exc

lusi

ve in

put /

out

put)

inpu

t are

a fr

ee

unlo

ck o

utpu

t are

a

belt

empt

y outp

ut a

vaila

ble

unlo

ck in

put a

rea

inpu

t ava

ilabl

e

outp

ut a

rea

free

tran

spor

ting

lock

out

put a

rea

belt

occu

pied

lock

inpu

t are

a

idle

inpu

t are

a fr

ee

unlo

ck in

put a

rea

go lo

ad p

osoutp

ut a

rea

free

lock

out

put a

rea

inpu

t ava

ilabl

e

outp

ut a

vaila

ble

read

y fo

r un

load

ing

unlo

ck o

utpu

t are

a

go u

nloa

d po

s

lock

inpu

t are

a

read

y fo

r lo

adin

g(a

nd h

avin

g co

ntro

l o

ver

outp

ut a

rea)

outp

ut a

vaila

ble

unlo

ck o

utpu

t are

a

unlo

adin

g

outp

ut a

rea

free

lock

out

put a

rea

stor

ing

inpu

t are

a fr

ee

unlo

ck in

put a

rea

inpu

t ava

ilabl

e

load

ing

lock

inpu

t are

a

stor

e fr

ee

Figure 6: Three types of cooperation pattern.

5.2 General Analysis

December 1995 17

Three possible arm versions are shown in Figure 8. In version 1, the preconditions to starta motion step are acquired simultaneously. To implement this behaviour, correspondingcompact language primitives are required which are usually not available in implemen-tation languages. In opposite to that, arm version 2 and 3 correspond in a straightforwardmanner to the program sketches in Figure 7 (taken from [Casais 94a, 94b]).

Now we are ready to compose step by step the production cell’s system built from themachine components just introduced (see Figure 9). The coarse structure given inFigure 10 provides an overview of the whole (closed) process system. It shows the toplevel of an hierarchically structured Petri net which we get as the result of the linking step.During linking, all (private) nodes of one process are uniquely prefixed to preserve nodename uniqueness within the total system. Each of the macro transitions (represented asnested double boxes) includes the behaviour of one controller on the next lower level (i.e.the net structures of Figure 6 or Figure 7, but with prefixed node names).

Please note the following drawing convention. Shaded nodes are so-called fusion nodes.They serve as connectors: all fusion nodes with the same name are logically identical.Therefore, they will be merged physically for the analysis data structures. Usually,communication objects are represented by such fusion nodes to avoid immoderate edgecrossing.

5.2 General AnalysisIn order to save time by discovering any faults as early as possible, the analysis is donealso step-by-step1).

So we start with proving that each machine controller behaves well in a stand-aloneenvironment, i.e. there is some producer putting for ever plates into the controller’s input

1) Actually, model design and analysis of the general and special properties have been done in aninterleaving manner.

arm: procedure to take a plate

Take /* version2 */acquire lock on swivel;acquire lock on input area;

move_arm_to_grasppos;do_grasp;go_in;

release lock on input area;release lock on swivel;

Take /* version3 */acquire lock on input area;acquire lock on swivel;

move_arm_to_grasppos;do_grasp;go_in;

release lock on input area;release lock on swivel;

Figure 7: Source text examples:


5 Cooperation Model

lock

sw

ivel

wai

ting

for

swiv

el

havi

ng s

wiv

el

unlo

ck in

put a

rea

outp

ut a

vaila

ble

swiv

el

unlo

ck s

wiv

el

havi

ng s

wiv

el

unlo

ck o

utpu

t are

a

unlo

adin

g

outp

ut a

rea

free

swiv

el

swiv

el

swiv

el

lock

out

put a

rea

stor

ing

inpu

t are

a fr

ee

unlo

ck s

wiv

el

inpu

t ava

ilabl

e

load

ing

lock

sw

ivel

wai

ting

for

swiv

el

lock

inpu

t are

a

stor

e fr

ee

lock

out

put a

rea

havi

ng s

wiv

el

havi

ng s

wiv

el

unlo

ck in

put a

rea

outp

ut a

vaila

ble

swiv

el

unlo

ck s

wiv

el

havi

ng s

wiv

el

unlo

ck o

utpu

t are

a

unlo

adin

g

outp

ut a

rea

free

swiv

el

swiv

el

swiv

el

lock

sw

ivel

stor

ing

inpu

t are

a fr

ee

unlo

ck s

wiv

el

inpu

t ava

ilabl

e

load

ing

lock

inpu

t are

a

havi

ng s

wiv

el

lock

sw

ivel

stor

e fr

ee

outp

ut a

vaila

ble

swiv

el

unlo

ck o

utpu

t res

ourc

es

unlo

adin

g

swiv

el

swiv

el

swiv

el

lock

out

put r

esou

rces

stor

ing

inpu

t are

a fr

ee

unlo

ck in

put r

esou

rces

inpu

t ava

ilabl

e

load

ing

lock

inpu

t res

ourc

es

stor

e fr

ee

vers

ion1

vers

ion2

vers

ion3

Figure 8: Three arm versions.

outp

ut a

rea

free


December 1995 19

subsystem: arm1 - press - arm2

arm1

arm2consumer

producer

input area free

output area free

input available

press

ch.A1P.free

ch.PA2.free

ch.A1P.full

ch.PA2.full

Figure 9: Coarse structures of step-wise composition:

producer

consumer

arm1

arm2

feed belt ch.FT.full

ch.FT.free

ch.A2D.free

ch.A2D.full

deposit belt

table

ch.TA1.free

ch.TA1.full

press

ch.A1P.free

ch.PA2.free

ch.A1P.full

ch.PA2.full

ch.CF.fullch.CF.free

ch.DC.freech.DC.full

open system

swivel

swivel


5 Cooperation Model

area, and there is some consumer taking away for ever the plates from the controller’soutput area (see figure 5). Satisfied with the controllers’ behaviour, we are going toanalyse the pipelined controllers building in each step a larger subsystem until we willhave built the closed system.

Above all, we are interested in proving the general properties boundedness and liveness.Concerning our case study, we succeeded in proving boundedness (for all net models)very fast by showing the sufficient condition that the net is covered with semipositiveplace invariants (which took in the worst case several seconds).

Due to the simple net structures of all (sub-) models (marked graph or extended simplenet), it makes sense to try the liveness prove by showing the sufficient condition ofdeadlock trap property. This structural property, which allows conclusions on behaviouralproperties, is valid for all models with one exception - the subsystem with arm version 2.For that model we find deadlocks1) (i.e. dead states) by construction of the (surprisinglysmall) stubborn set reduced reachability graph. Evaluating some paths to dead states werealize that the deadlocks can be traced back to an inappropriate interleaving order ofacquiring resources. The swivel may only be acquired, if the input area is already full.

1) Be aware of the different meanings of the term deadlock speaking of concurrent software engi-neering or of a special Petri net property, respectively.

crane

arm1

ch.PA2.fullch.PA2.free

arm2

feed belt

ch.FT.full

ch.FT.free

ch.A2D.free

ch.A2D.full

deposit belt

table

ch.TA1.free

ch.TA1.full

press

ch.A1P.free ch.A1P.fullch.CF.full ch.CF.free

ch.DC.freech.DC.full

Figure 10: Coarse structure of the closed system.

swivel


December 1995 21

Therefore, we will apply the arm version 3 in the following.

If it is interesting whether a net is reversible or dynamically conflict free, the completereachability graph has to be constructed which is still possible for the composed larger(sub-) systems.

For samples of (almost) complete analysis session protocols produced by INA seeappendix B. Here we restrict ourselves to a summary of the final analysis results1):

table/press with initialization part:ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ESY Y N Y N N Y N N N Y N N N N N YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&SVN N N N ? N Y ? N N N N Y N N N

table/press without initialization part, crane, belts:ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ESY Y Y Y N Y Y Y N N N N Y N Y Y YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&SVY Y Y Y Y Y Y Y Y N N N Y Y Y Y

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

subsystem, arm version2:ORD HOM NBM PUR CSV SCF CON SC Ft0 tF0 Fp0 pF0 MG SM FC EFC ESY Y Y Y N N Y Y N N N N N N N N YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&SVN Y Y N Y ? Y Y N Y N N N N N N

subsystem, arm version1,subsystem, arm version3,open system,closed system:

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

1) See appendix C for explanation of the abbreviations used in the result vectors.


5 Cooperation Model

In Table 2 you find more details on the size of the analysed nets and the analysis effortsdone. To gather experience in the reduction effect, the sizes of the stubborn set reducedand of the complete reachability graph have been compared.

Please note that it is very advisable to prove boundedness before constructing a reacha-bility graph with INA. In that case, the coverability test is switched off (saving a lot oftime) which would be done otherwise to avoid any possibly unlimited graph construction(which could actually happen with PROD). Table 3 compares the time efforts done toconstruct the complete state space of the nets under consideration using INA and PROD.

Table 2: Size of analysed nets and analysis efforts done (cooperation model).

a) processed candidates to check the Deadlock Trap Propertyb) number of states generatedc) after about 1 h computing time on SUN sparc station 20

places/transitions DTPa) Rstub

b) Rb)

table / presswith init partwithout init part

13 / 912 / 8

(N)28

128

2824

crane 12 / 8 31 11 48

armsversion 1version 2version 3

13 / 817 / 1217 / 12

3810988

111515

4811296

belts 12 / 8 26 8 36

subsystem witharm version 1arm version 2arm version 3

25 / 1633 / 2433 / 24

1753.851 (N)725

4775140

6401.9841.800

open system 51 / 36 1.145 29977.760c)

closed systemwith 1 platewith 2 plateswith 3 plateswith 4 plateswith 5 plates

51 / 36 1.14036729498121

8644.77612.10216.36212.144

5.3 Special Analysis

December 1995 23


5.3.1 Expressibility of system properties

Basically, two different types of system properties can be distinguished:

Propositions related to design consistency: This class of properties consists of proposi-tions on the construction of a system. For instance, mutual exclusion of the communi-cation places which link the device controller models is demanded by the system design.Since those properties are given in terms (of a formal description) of the system itself,they can be expressed without reference to the influence of the system on its environment.

Propositions related to the influence of a system on its environment: For systems,which maintain an ongoing interaction with its environment, properties of this class areusually given by a list of safety and/or liveness requirements in terms of the system’sinfluence on the environment. If the system is specified by some formal description, theexpressibility of these properties depends on the existence of appropriate termsconcerning the environment in the description. These terms can be given

Table 3: Comparison of PROD and INA: Time effort done to generate the reachability graphs

INA (withcoverability test)

INA (withoutcoverability test)

PROD

table / presswith init pathwithout init path

1.5’1.46’

1.54’2.16’

7.96’7.41’

crane 1.62’ 2.12’ 7.39’

armsversion 1version 2version 3

1.5’1.73’1.77’

3.12’1.65’1.88’

14.78’24.92’24.19’

belts 1.58’ 2.23’ 7.38’

subsystem witharm version 1arm version 2arm version 3

7.81’53.23’57.07’

3.64’7.78’8.12’

14.78’24.92’24.19’

open System 86132.6’ 3653.6’ 1073.35’

closed systemwith 1 platewith 2 plateswith 3 plateswith 4 plateswith 5 plates

18.58’365.53’2401.28’4167.93’2373.1’

6.07’18.77’87.1’150.85’78.6’

25.93’56.21’125.71’169.15’123.8’


5 Cooperation Model

1. implicitly by means of assumptions on the relations between internal system states andexternal states of the environment, or

2. explicitly by incorporating a reasonable description of the environment itself into thesystem model.

For the logical analysis of the cooperation model we use the former technique. The controlmodel described in section 5.1 includes a formalization of certain assumptions on thebehaviour of the physical machines of the production cell.

Concerning our control program, properties of the latter type can be classified into thefollowing types of unwanted system behaviour:

A. Illegal states of a single component (Requirements 1-7, 11): For instance, both robotarms must not be extended to far. Requirements of this type are hard to express withoutan environment model containing explicit error states. Indeed, we are not able to proveany of those propositions in both the cooperation and the control model presented inthis paper.

B. Illegal combinations of legal states of single components (Requirements 8-10). Forinstance, some combinations of states of the devices yield to a machine collision. Sincethe behaviour of the controllers and their cooperation are described by the compositionof certain subsystems which consist of the legal controller states, there is a good chanceto express these properties.

C. Illegal (sequences of) actions (Requirements 12-21). For instance, if the travellingcrane transports a blank, its electromagnet may not deactivated before the transport iscompleted. Properties expressible in CTL or LTL are based on propositions on states,not on (firing sequences of) transitions. Therefore requirements of this type can beexpressed only indirectly in terms of the system states where such unwanted transitionswould be enabled.

5.3.2 Requirements Related to Design Consistency

In view of the intended use of the communication places, which connect the nets for theseveral controllers, the mutual exclusion property for these places must be fulfilled by thesystem:

Requirement 22. Mutual exclusion for communication places. For any machine, itsinput and output area is never free or locked at the same time:

However, requirement 22 does not fully describe the communication behaviour of thecontrollers because, for instance, the following assumption is not expressed: If a blank

ch_CF_free ch_CF_full∧( )¬GAch_DC_free ch_DC_full∧( )¬GAch_FT_free ch_FT_full∧( )¬GAch_TA1_free ch_TA1_full∧( )¬GAch_A1P_free ch_A1P_full∧( )¬GAch_PA2_free ch_PA2_full∧( )¬GAch_A2D_free ch_A2D_full∧( )¬GA

∧∧∧∧∧∧


December 1995 25

reaches the input area of a machine, the blank will be actually processed by that machine.To fill this gap, we can check additionally e. g. the following formula for the crane and thefeed belt:

The time effort to check a formula of this type is not acceptable (about 10 hours on a sparcstation 20), because of the second temporal operator. Therefore, we restrict ourselves ofexamples of properties expressible with only one temporal operator at the outermost level.Fortunately, this restriction still allows to express safety requirements, which are of thelogical form (or , in LTL).

The input/output behaviour of the controllers’ net components are formalized in thefollowing requirements:

Requirement 23. Independent input/output behaviour of both the robot arms andthe crane:

23.a) Crane:

23.b) Arm 1:

23.c) Arm 2:

Requirement 24. Dependent input/output behaviour for the conveyor belts:

24.a) Feed belt:

24.b) Deposit belt:

Requirement 25. Mutual exclusive input/output behaviour

25.a) Table:

ch_CF_full ch_CF_freeFA→( )GA

ϕ¬( )GA G ϕ¬( )

ch_DC_free ch_DC_full∧( )¬ ch_CF_free ch_CF_full∧( )¬∨( )GA

ch_TA1_free ch_TA1_full∧( )¬ ch_A1P_free ch_A1P_full∧( )¬∨( )GA

ch_PA2_free ch_PA2_full∧( )¬ ch_A2D_free ch_A2D_full∧( )¬∨( )GA

feed_belt_transporting

ch_CF_free ch_CF_full ch_FT_free ch_FT_full∨ ∨ ∨( )¬→(

)GA

deposit_belt_transporting

ch_A2D_free ch_A2D_full ch_DC_free ch_DC_full∨ ∨ ∨( )¬→(

)GA

ch_FT_full ch_FT_free∨( )¬ ch_TA1_full ch_TA1_free∨( )¬∧( )GA


5 Cooperation Model

25.b) Press:

5.3.3 Requirements Related to Illegal Combinations of States

Requirement 8. The press may only close when no robot arm is positioned insideit. Since a robot arm can only be inside the press if it is extended, i. e. if it picks up ablank or releases one, by contraposition it is sufficiently to prove that the press is notin its upper position if an arm is loading or unloading.

8.a) Arm 1:

8.b) Arm 2:

5.3.4 Requirements Related to Illegal Sequences of actions

It is interesting that these properties can be expressed in a very intuitive way on the levelof the cooperation model, i. e. using only terms of internal system states: At the currentlevel of refinement action sequences related to device controlling are represented by singleplaces. We will see in section 6.3.3 that the formulation of requirements of this type ismore difficult (but more accurate) using only a state description of an environment model.

Requirement 15. The feed belt may only convey a blank through its light barrier, ifthe table is in loading position. We check the contraposition of the requirement, i. e.if the table is not in loading position, the feed belt does not transport a blank:

Requirement 16. The deposit belt must be stopped after a blank has passed the lightbarrier at its end and may only be started again after the crane has picked up theblank. The first part of the requirement cannot be formulated on the current level ofrefinement, but the second:

Requirement 17. A new blank may only be put on the feed belt, if the former onehas arrived at the end of the feed belt. This requirement and the next one cannot beexpressed in the cooperation model because of the lack of an appropriate term for

ch_A1P_full ch_A1P_free∨( )¬ ch_PA2_full ch_PA2_free∨( )¬∧( )GA

arm1_loading arm1_unloading

press_go_loadpos press_go_unloadpos¬∨¬→∨(

)GA

arm2_loading arm2_unloading

press_go_loadpos press_go_unloadpos¬∨¬→∨(

)GA

table_ready_for_loading¬ feed_belt_transporting¬→( )GA

crane_loading deposit_belt_transporting∧( )¬GA

5.4 Summary of the Main Analysis Results

December 1995 27

the crane’s unloading action. But we can show a somewhat weaker requirement: Ifthe feed belt is active, the crane does not perform an unload action.

Requirement 18. A new blank may only be put on the deposit belt, if the former onehas arrived at the end of the deposit belt. Similar to the previous requirement wecheck that if the deposit belt is active, the second robot arm does not perform anunload action.

Requirements which contain explicitly references to certain sensor values cannot beexpressed at the current level of refinement. This includes the requirements 9, 10, 12-14,and 19-21.

The time effort to check the formulae above was between three and eight minutes on asparc station 20.

5.4 Summary of the Main Analysis ResultsFor the cooperation model, boundedness and liveness can be decided efficiently byshowing that the net is covered by semipositive place invariants and by proving thedeadlock trap property, respectively. Dead states in one discussed controller version havebeen found very fast by the stubborn set reduced method.

The reachability graph analyser PROD has been successfully applied to prove certainsafety properties of the cooperation model given by CTL formulae. Two different types ofrequirements of a system can be distinguished: Design dependent requirements, whichdemand properties related to the consistence of the construction of a system, and require-ments which demand properties on the interaction of a system with its environment. In thecooperation model, the requirements of the former type are expressible in a straight-forward way. Requirements of the latter type are expressible only in an indirect manner interms of internal system states.

In the analysis of the control model two major problems have been arisen:

1. The expressibility of certain properties. Requirements which are given explicitly interms of the system’s interaction with the environment (like sensor values) cannot beexpressed only in terms of internal system states.

2. The time effort for model checking. Although safety properties of the general logicalform can be checked within an acceptable amount of time for systems with amedium sized state space, the time effort to validate more complex formulae likeprogress properties of the form is extraordinary large (about tenhours).

feed_belt_transporting crane_unloading¬→( )GA

deposit_belt_transporting arm2_unloading¬→( )GA

ϕ¬( )GA

ϕ χFA→( )GA


6 Control Model

6 Control ModelIn this section, the control model is developed as a refinement of the cooperation model byadding the interactions with the physical devices. After that, the model is analyzed.

6.1 ModellingIn this section we describe the refinement of the cooperation model to a control model bymodelling the interactions with the interface (actuators, sensors) as described in section4.1. Furthermore, the model will comprise a net description of the environment whichallows to express assumptions on the behaviour of physical devices.

The environment model for each physical device is divided into two parts: an actuatormodel, which describes the states of a device (e. g. running, stopped, etc.) and a sensormodel, which expresses the sensor values which must be received by the controller.Actuators are effected by the commands listed in section 4.1. We can identify the states ofeach device with the commands to control them. A net description of the actuator states isobtained by adding a place PA for each command A. A marking of PA with one tokenmeans that the corresponding device has received the command A and is in an associatedstate.

A controller performs an action in response to a specific value of some sensor. Toconstruct an environment model which describes the relations between sensors andactuators it is enough to represent only those sensor values in the model which may causea reaction of controllers. Table 4 (see page 30) compiles these relevant sensor values V. Anet description of the sensor states of the cell is obtained by adding a place PV for each ofthese values V. PV is marked with one token if the value V may be currently received bythe control program. Figure 11 shows the Petri net pattern for sending a command andreceiving a sensor state by the controller.

We now describe the model of the relation between control actions and the environment.We decompose every complex control action into elementary steps which consist of the

send action ofcommand A by thecontroller;

associated placePA of theenvironment;

receive action of asensor value V bythe controller;

associated placePV of theenvironment;

Figure 11:Petri net pattern forcommunication with theenvironment:

Send a command A (above)and receive a sensor valueV (below)

6.1 Modelling

December 1995 29

following steps:

1. Activation of an actuator to start a specific device motion.

2. Waiting for the occurrence of a sensor value which indicates that the motion has beencompleted.

3. Deactivation of the actuator.

Figure 12 (a) (page 31) shows the controller part of such a control step. The followingassumptions are made about the effect of the elementary control procedure on theenvironment.

A. A send action of a start command will force the associated device to change from aninactive to an active state. On the other hand, sending a stop command is assumed toforce the device to change in an inactive state. Figure 12 (b) shows the modelling ofthese assumptions by a Petri net. The places stop_cmd and start_cmd represent theactuator states corresponding to the deactivation and activation of the actuator,respectively.

B. Each elementary motion step is performed in the context of an initial sensor valueindicating the current position of the corresponding device. We assume that theperformed motion will cause eventually the occurrence of a final sensor value. Theplaces start_con and stop_con (see figure 12 (c)) represent the initial and final value inthe sensor state model. The transition css (change sensor state) implements thisassumption.

C. The control procedure may only influence those part of the environment model whichconsists of the places stop_cmd, start_cmd, start_con, and stop_con, respectively. Notethe pre/postplace run of the transition ccs (change sensor state). Omitting both arcsyields an environment model which does not correctly represent the assumption. Forinstance, consider the robot’s angle, where the first robot arm is in a position to pick upa blank from the table, i. e. the place arm1_pick_up_angle is marked. This position canoccur in several situations, for instance, if the robot is going to rotate to an angle wherearm 1 is able to reach the press, and also if the robot is going to rotate to an angle wherearm 2 is able to fetch a blank from the press. Since the start command for both actionsis robot_right, the preconditions of both instances of css would be satisfied.

For simplicity we collect both the control procedure and the environment descriptions in acoarse structure shown in figure 12 (d). An instantiation of the structure consists ofrenaming the shown places (indeed every node should be renamed because PRODrequires unique node names).


6 Control Model

Based on these elementary processing steps, more complex ones can be built as illustratedin the figures 13 (a) and (b). Figure 13 (a) shows the modelling of the rotation and thelowering of the table. The initial position is completely determined by the previous actionsof that device. Because of modelling the robot arms by separate net components, the initial

Device Place name Sensor Value Initial marked

Press press_at lower_pos 1 1

press_at_middle_pos 2 1 Y

press_at_upper_pos 3 1

Robot arm1_retract_ext 4 0.0 Y

arm1_pick_up_ext 0.5208

arm1_release_ext 0.6459

arm2_retract_ext 5 0.0 Y

arm2_pick_up_ext 0.7971

arm2_release_ext 0.5707

arm1_pick_up_angle 6 50.0

arm1_release_angle -90

arm2_pick_up_angle 35.0

arm2_release_angle -90 ... -45 Y

Table table_bottom_pos 7 1 Y

table_top_pos 8 1

table_load_angle 9 0.0 Y

table_unload_angle 50.0

Crane crane_above_deposit_belt 10 1 Y

crane_above_feed_belt 11 1

crane_transport_height 12 0.5208 Y

crane_pick_up_height 0.5707

crane_release_height 0.6593

Feed belt belt1_light_barrier_false 13 0 Y

belt1_light_barrier_true 1

Deposit belt belt2_light_barrier_false 14 0 Y

belt2_light_barrier_true 14 1

Table 4: Sensor environment model

6.1 Modelling

December 1995 31

sensor states for a robot’s rotation cannot be uniquely determined from previous motionsteps. Before a rotation can be initiated, the robot’s angle must be determined by receivingthe value of sensor 6 (see figure 13 (b)).

A detailed discussion of the construction of the other components of the control model isnot necessary to understand the analysis of it (recall that the requirements to prove insection 6.3 are given in terms of the environment model which is described in thissection). The reader is invited to have a look on the Petri nets pictured in appendix A.

start_con

cssstart_cmd

Pstop

Cstop

Pstart

rs

run

stop_con

start_cmd

stop_cmd

in

out

run

Pstart

Cstop

Pstop

(a) Control procedure (b) Actuator state model

(c) Sensor state model

stop_con

start_con

start_cmd

stop_cmd

in

out

devicecontrol

(d) Combined control procedure and environmentmodel (coarse structure)

Figure 12: Elementary motioncontrol.

(a) shows the control procedurefor an elementary motion: Weassume the following actions tobe associated with transitions:

26. Pstart: Send a start commandto the device to control.

27. Cstop: receive the stop con-dition.

28. Pstop: Send a stop command.

Fig. (b) and (c) show theactuator state model and thesensor state model, respectively.Note the side condition run of thetransition ccs.

Fig. (d) pictures the coarsestructure of a subnet containingthe control procedure and boththe actuator and the sensor statemodel. Only the places shownare global and can be used forcommunication with other netcomponents.


6 Control Model

A1L_out

A1L_in

arm2_release_angle

arm2_pick_up_angle

robot_stop

robot_left

arm1_pick_up_angle

robot_stop

robot_left

arm1_pick_up_angle

robot_stop

robot_left

arm1_release_angle

arm1_pick_up_angle

Figure 13: Composition of elementarymotion control procedures

(a) Composed motion control procedure tomove the table from its loading to its unloadingposition. A rotation of the table followed by avertical translation is performed. The precondi-tions of the operation are determined by theprevious motion of the table.

(b) Composed motioncontrol procedure torotate the robot to aposition where thefirst robot arm cangather a blank fromthe table. In this casethe preconditions ofthe operation are notuniquely determinedby previous actions.

table_unload_angle

table_load_angle

table_right

table_stop_h

table_at_unload_angle

table_top_pos

table_bottom_pos

table_upward

table_stop_v

TU_out

TU_in

rotate

lift


December 1995 33

6.2 General AnalysisAgain, we try the validation step-wise. At first the refined stand-alone controllers areevaluated, and after that the composition takes place.

Boundedness is still decidable by showing that the net is covered with semipositive placeinvariants. Due to the added environment behaviour, all net models exhibit a net structurebeyond the extend simple one. So, the deadlock trap property could only show thefreedom of dead states1). But this can be proven more efficiently by constructing thestubborn set reduced reachability graph - even for the completely refined open or closedsystem, which sizes of the state space we don’t know. For more details see also sample 4of INA session protocols in appendix B.

Another interesting property is the liveness of transitions. Unfortunately, INA is unable toprove this property because of the lack of suitable structural properties and the size of thestate space of the control model. A derivation using PROD cannot be done, too: Theliveness of a transition t is expressible in CTL by the formula

where en(t) denotes the conjunction of the (propositions associated with the) preplaces oft. In LTL only a stronger liveness property of transitions can be expressed, which is relatedto the livelock freedom of the transition:

Obviously, every transition t which enjoys this property is live. But, the formula does nothold for those transitions which are located in the rotation procedure for the robot armspictured at figure 13 (b). We have checked this formula for every transition in the controlmodel using a batch program.

For completeness we quote another system property, the 1-boundness of places. Thisproperty is expressed in PROD’s version of LTL by

for every place p. Here card(p) denotes the number of tokens located at p at the point oftime where the expression is evaluated. Again, a batch program was used to check theformula for every place.

6.3 Special AnalysisAfter using CTL to prove properties of the cooperation model, in this section we turn tothe validation of propositions on the control model. Because of its size it is not reasonableto construct the complete reachability graph for that model2). Therefore, the on-the-fly

1) By the way, the deadlock trap property is, as far as we were patient enough for generating candi-dates, not valid for the nets of the control model.

en t( ) ,FEGA

GF en t( ) .

G card p( ) 1≤( )


6 Control Model

verification method for LTL formulae supported by PROD is used throughout this section.

It should be noted that there is no general methodology for a compositional approach oflogical analysis which allows to deal with our tasks. The propositions listed in section 5.3do not necessary hold for the further refinement of the cooperation model. Especially therequirements related to the design consistency must be shown again for the control model(after suitable reformulation). In favour of further interesting types of properties we omitthe repetition of requirements 22 to 25.

6.3.1 Requirements Related to Design Consistency

In section 5.1 we described an environment model of the effect of control actions by thecontroller program. Obviously, the places associated with the states of anactuator must enjoy the following invariance property,

i. e. any device is at every point of time in exactly one state (‘ ’ denotes the exclusivedisjunction). The same property must hold for the places associated with the values of asensor. We give two examples:

Requirement 29. The robot swivel is either stopped or moves in exactly onedirection:

Requirement 30. The robot swivel is always positioned at exactly one angle:

6.3.2 Requirements Related to Illegal Combinations of States

We start with a proposition which was already shown in section 5.3.3 for the cooperationmodel. Two other propositions show that safety requirements of this type can be expressedin an intuitive manner.

Requirement 8. The press may only be closed, if no robot arm is positioned insideit.

8.a) Arm 1:

2) We stopped the state space construction after about two days, having generated about 700 000states filling about 1.5 GigaBytes.

p1 p2 … pn, , ,

G p1 p2 … pn.∨ .∨ .∨

,

.∨

G robot_stop robot_left robot_right.∨ .∨( )

G arm1_pick_up_angle arm1_release_angle.∨arm2_pick_up_angle arm2_release_angle.∨.∨

()

G arm1_release_angle arm1_release_ext∧( )press_stop press_at_upper_pos¬∧( )→

()


December 1995 35

8.b) Arm 2:

Requirement 9. A robot arm may only rotate, if the arm is retracted.

Requirement 10. The travelling crane is not allowed to knock against a beltlaterally, i. e. it must be ensured that the crane does not move from the deposit beltto the feed belt without performing a vertically translation.

6.3.3 Requirements Related to Illegal Sequences of Actions

In [Lewerentz 95] several sufficient conditions are given to ensure that a blank will not bedropped outside a save area. In particular it is required that the electromagnets of the robotarms and the crane’s gripper may only be deactivated if the corresponding machineperforms an unloading action. The controllers modelled by our nets do not obey thissomewhat to strong requirement. The two propositions below express weaker demandswhich also ensure that blanks are only dropped inside suitable areas by the robot arms andthe travelling crane.

Requirement 31. If the crane transports a blank, it’s electromagnet must not bedeactivated. We prove this property in three parts, one for each moving stepassociated with the transport of a blank.

31.a) Lifting the electromagnet to the cranes transport height:

31.b) Perform the horizontally movement to the feed belt:

31.c) Lower the cranes electromagnet:

For the robot, a similar property cannot be expressed in that way because of the fact thatfor each state where the magnet of a robot arm must be deactivated there is another statewhich differs from the former only by the magnet’s activation. Hence, a differentexpression of that property is needed:

Requirement 32. If a robot arm is loaded, its magnet is not deactivated until thearm is in its unloading position.

G arm2_pick_up_angle arm2_pick_up_ext∧( )press_stop press_at_upper_pos¬∧( )→

()

G robot_left robot_right∨( ) arm1_retract_ext arm2_retract_ext∧( )→( )

G crane_to_belt1 crane_to_belt2∨( ) crane_at_transport_height→( )

G crane_above_deposit_belt crane_lift crane_mag_onW∧( )

G crane_to_belt1 crane_mag_onW( )

G crane_above_feed_belt crane_lower crane_mag_onW∧( )


6 Control Model

32.a) Arm 1:

32.b) Arm 2:

Requirement 15. The feed belt may only convey a blank through its light barrier, ifthe table is in its loading position.

Note that a similar property for the deposit belt and the crane does not hold because of thedifferent input/output behaviour: To perform a horizontal movement back to the depositbelt, the crane does not need to control its input area. Therefore, the crane may not be in itsloading position if a blank intersects the ray of the deposit belt’s light barrier.

Table 5 shows the sizes of the reachability graphs constructed while checking the LTLformulae throughout this section by PROD’s on-the-fly verification, and the time effortused, respectively.

G arm1_pick_up_angle arm1_pick_up_ext arm1_mag_on∧ ∧( )arm1_mag_on arm1_release_angle arm1_release_ext∧( )U( )

→()

G arm2_pick_up_angle arm2_pick_up_ext arm2_mag_on∧ ∧( )arm2_mag_on arm2_release_angle arm2_release_ext∧( )U( )

→()

G belt1_light_barrier_true table_load_angle table_bottom_pos∧( )→( )

Requirementformula

Number ofstates generated

Time effort

8 a 2259 4.16’

8 b 1775 3.76’

9 2305 4.34’

10 1879 3.10’

15 1184 2.55’

29 704 2.16’

30 703 2.46’

31 a 27104 23.80’

31 b 6433 4.02’

31 c 28285 24.30’

32 a 3940 10.26’

32 b 3113 9.21’

Table 5: Analysis effort of on-the-fly verification

6.4 Summary of the Main Analysis Results

December 1995 37

6.4 Summary of the Main Analysis ResultsIn spite of the size of the control model, boundedness is still decidable very efficiently.Moreover, the construction of the stubborn set reduced reachability graph is manageableeven for larger systems with unknown size of the complete state space. So, the prove ofthe deadlock freedom seems to be practicable in any case.

Several required safety properties of the control model have been proven successfullyusing PROD’s stubborn set based on-the-fly verification method. The following resultswhere obtained:

1. The existence of an environment model allows to express both assumptions on thebehaviour of physical machines and system properties in terms of the influence of asystem on its environment. The validity of requirements is comprehensible without adeeper knowledge of the internal structure of a system.

2. Because of the structure of the environment model it is impossible to express propertiesrelated to illegal states of single devices. A more improved model must contain expliciterror states.

3. The stubborn set based on-the-fly verification method has been proven to be applicableeven for systems with a larger state space. However, certain properties like the livenessof transitions cannot be expressed in LTL because of the lack of a quantification oncomputation paths.

7 Final RemarksUp to now, a Petri net model to control the given production cell has been developedwhich enjoys provably a lot of valuable qualitative properties - general as well as specialones. Beyond that, the following investigations should be done:

• Quantitative analysis by different types of time-dependent Petri Nets:by Duration Interval Nets [Popova 95] based on Interval Nets [Popova 91] to prove themeeting of given deadlines by worst-case evaluation, andby Stochastic Nets [Wikarski 95] to estimate throughput or average processing time.

• The synthesis of the actual control software based on [Schwidder 95] is in preparation.

• Incorporation of fault tolerance aspects (blowing up the net sizes significantly).

Throughout this paper, (the rarely available and rather restrictive) compositionalapproaches of Petri net analysis have not been discussed yet. They have been skipped inorder to get a feeling for the borders of those net/state space sizes, which are actuallymanageable by available analysis tools.

Appendix

December 1995

Appendix

A The Petri Net Model ................................................................ 1

B Analysis Protocols - Samples................................................... 18

C General Petri Net Properties - Overview ................................ 38

D References ............................................................................... 39

Appendix A

December 1995 A - 1

A The Petri Net ModelThis section compiles the subnets comprising the completely refined control model. Fig-ure 1 shows the hierarchy of the refined coarse nodes given on the following pages. Toavoid boring repetitions of similar net structures the (37) instances of the elementarymotion control procedure are omitted here. The total net consists of 231 places and 202transitions structured into 65 nodes of the hierarchy tree.

top level

(1) feed belt

(2) table

(3) arm1

(4) press

(5) arm2

(6) deposit_belt

(7) crane

(1.1) feed_belt_transporting

(2.1) table_go_unload_pos

(2.2) table_go_load_pos

(3.1) arm1_loading (3.1.1) A1L_rotate

(3.1.2) A1L_grasp

(4.1) press_go_unload_pos

(3.2) arm1_unloading (3.2.1) A1U_rotate

(3.2.2) A1U_ungrasp

(4.2) press_go_load_pos

(5.1) arm2_loading (5.1.1) A2L_rotate

(5.1.2) A2L_grasp

(5.2) arm2_unloading (5.2.1) A2U_rotate

(5.2.2) A2U_ungrasp

(6.1) deposit_belt_transporting

(7.1) crane_loading

(7.2) crane_unloading

Figure 1: Net Hierarchy

A - 2 BTU Report I-08/1995

Appendix

swivel

ch_PA2_fullch_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_fullch_CF_full ch_CF_free

ch_DC_freech_DC_full

crane (7)

arm1 (3)

arm2 (5)

feed_belt (1)

deposit_belt (6)

table (2)

press (4)

Top Level

Appendix A

December 1995 A - 3

FB_out

belt1_stop

belt1_start

belt1_light_barrier_true

belt1_light_barrier_false

FB_at_end

FB_in

belt1_stop

belt1_start



feed_belt_unlock_input_area

feed_belt_lock_output_area

deliver

trans

ch_CF_free

ch_CF_full

ch_FT_free

ch_FT_full

feed_belt_unlock_output_area

feed_belt_empty

feed_belt_unlock_input_area

feed_belt_lock_output_area

feed_belt_occupied

feed_belt_lock_input_area

feed_belt_idle

feed_belt_transporting (1.1)

(1) feed_belt

(1.1) feed_belt_transporting


Appendix

ch_TA1_full

ch_TA1_free

ch_FT_free

ch_FT_full

table_unlock_input_area

table_lock_output_area

table_ready_for_unloading

table_unlock_output_area

table_lock_input_area

table_ready_for_loading

table_go_load_pos (2.2)

table_go_unload_pos (2.1)

table_unload_angle

table_load_angle

table_right

table_stop_h

table_at_unload_angle

table_top_pos

table_bottom_pos

table_upward

table_stop_v

TU_out

TU_in

table_unlock_output_area

table_lock_input_area

rotate

lift

table_stop_v

table_downward

table_top_pos

table_bottom_pos

table_at_load_angle

table_stop_h

table_left

table_unload_angle

table_load_angle

TL_in

TL_out

table_unlock_input_area

table_lock_output_area

lower

rotate

(2) table (left)

(2.1) table_go_unload_pos (leftbelow)

(2.2) table_go_load_pos

(right below)

Appendix A

December 1995 A - 5

ch_TA1_free

ch_TA1_full

ch_A1P_free

ch_A1P_full

arm1_lock_swivel_2

arm1_waiting_for_swivel_2

arm1_having_swivel_1

arm1_unlock_input_area

swivel

arm1_unlock_swivel_2


arm1_unlock_output_area

swivel

swivel

swivel

arm1_lock_output_area

arm1_storing


arm1_lock_swivel_1


arm1_lock_input_area

arm1_store_free

arm1_unloading (3.2)

arm1_loading (3.1)

A1U_out

A1U_in

A1U_rotated

arm1_unlock_outputt_area

arm1_lock_swivel_2

A1U_ungrasp (3.2.2)

A1U_rotate (3.2.1)

A1L_out

A1L_in

A1L_rotated


arm1_lock_swivel_1

A1L_grasp (3.1.2)

A1L_rotate (3.1.1)

(3) arm1 (left)

(3.1) arm1_loading (right above)

(3.2) arm1_unloading (right below)


Appendix

A1L_in

arm2_release_angle

arm2_pick_up_angle

A1L_c3

A1L_c2

A1L_c1

A1L_rot3_in

robot_stop

robot_left

arm1_pick_up_angle

A1L_rot2_in

robot_stop

robot_left

arm1_pick_up_angle

A1L_rot1_in

robot_stop

robot_left

arm1_release_angle

arm1_pick_up_angle

rot3

rot2

rot1

A1U_rotated

(3.1.1) A1L_rotate

Appendix A

December 1995 A - 7

A1U_in

arm2_release_angle

arm2_pick_up_angle

A1U_c3

A1U_c2

A1U_c1

A1U_rot3_in

robot_stop

robot_left

arm1_release_angle

A1U_rot2_in

robot_stop

robot_right

arm1_release_angle

A1U_rot1_in

robot_stop

robot_right

arm1_pick_up_angle

arm1_release_angle

rot3

rot2

rot1

(3.2.1) A1U_rotate


Appendix

A1L_out

A1L_rotated

arm1_magnet_off

arm1_magnet_onA1L_grasp

A1L_loaded

arm1_stop

arm1_backward

arm1_pick_up_ext

arm1_retract_ext

A1_extended

arm1_stop

arm1_forward

arm1_retract_ext

arm1_pick_up_ext

A1L_ret

A1L_ext

A1U_out

A1U_rotated

arm1_magnet_off

arm1_magnet_onA1U_ungrasp

A1U_unloaded

arm1_stop

arm1_backward

arm1_release_ext

arm1_retract_ext

A1U_extended

arm1_stop

arm1_forward

arm1_retract_ext

arm1_release_ext

A1U_ret

A1U_ext

(3.1.2) A1L_grasp

(3.2.2) A1U_ungrasp

Appendix A

December 1995 A - 9

ch_PA2_full

ch_PA2_free

ch_A1P_free

ch_A1P_full

press_unlock_input_area

press_lock_output_area

press_ready_for_unloading

press_unlock_output_area

press_lock_input_area

press_ready_for_loading

press_go_load_pos (4.2)

press_go_unload_pos (4.1)

press_at_upper_pos

press_at_middle_pos

press_upward

press_stop

PU_in

blank_forged

press_at_lower_pos

press_at_upper_pos

press_down

press_stop

PU_out

press_unlock_output_area

press_lock_input_area

forge

lowerPL_out

press_stop

press_up

press_at_lower_pos

press_at_middle_pos

PL_in

press_unlock_input_area

press_lock_output_area

lift

(4) press

(4.1) press_go_unload_pos (leftbelow)

(4.2) press_go_load_pos (rightbelow)


Appendix

ch_PA1_free

ch_PA1_full

ch_A2D_free

ch_A2D_full

arm2_lock_swivel_2




swivel




swivel

swivel

swivel

arm2_lock_output_area

arm2_storing


arm2_lock_swivel_1


arm2_lock_input_area

arm2_store_free

arm2_unloading (5.2)

arm2_loading (5.1) A2L_out

A2L_in

A2L_rotated


arm2_lock_swivel_1

A2L_grasp (5.1.2)

A2L_rotate (5.1.1)

A2U_out

A2U_in

A2U_rotated


arm2_lock_swivel_2

A2U_grasp (5.1.2)

A2U_rotate (5.2.1)

(5) arm2 (left)

(5.1) arm2_loading (right above)

(5.2) arm2_unloading (right below)

Appendix A

December 1995 A - 11

A2L_in

arm2_release_angle

arm1_release_angle

A2L_c3

A2L_c2

A2L_c1

A2L_rot3_in

robot_stop

robot_left

arm2_pick_up_angle

A2L_rot2_in

robot_stop

robot_left

arm2_pick_up_angle

A2L_rot1_in

robot_stop

robot_left

arm1_pick_up_angle

arm2_pick_up_angle

rot3

rot2

rot1

A2L_rotated

(5.1.1) A2L_rotate


Appendix

A2U_in

arm2_pick_up__angle

arm1_release_angle

A2U_c3

A2U_c2

A2U_c1

A2U_rot3_in

robot_stop

robot_right

arm2_release_angle

A2U_rot2_in

robot_stop

robot_left

arm2_release_angle

A2U_rot1_in

robot_stop

robot_right

arm1_pick_up_angle

arm2_release_angle

rot3

rot2

rot1

A2U_rotated

(5.2.1) A2U_rotate

Appendix A


A2L_out

A2L_rotated

arm2_magnet_off

arm2_magnet_onA2L_grasp

A2L_loaded

arm2_stop

arm2_backward

arm2_pick_up_ext

arm2_retract_ext

A2_extended

arm2_stop

arm2_forward

arm2_retract_ext

arm2_pick_up_ext

A2L_ret

A2L_ext

A2U_out

A2U_rotated

arm2_magnet_off

arm2_magnet_onA2U_ungrasp

A2U_unloaded

arm2_stop

arm2_backward

arm2_release_ext

arm2_retract_ext

A2U_extended

arm2_stop

arm2_forward

arm2_retract_ext

arm2_release_ext

A2U_ret

A2U_ext

(5.1.2) A2L_grasp

(5.5.2) A2U_ungrasp


Appendix

DB_out

belt2_stop

belt2_start



DB_at_end

DB_in

belt2_stop

belt2_start



deposit_belt_unlock_input_area

deposit_belt_lock_output_area

deliver

trans

ch_A2D_free

ch_A2D_full

ch_DC_free

ch_DC_full

deposit_belt_unlock_output_area

deposit_belt_empty

deposit_belt_unlock_input_area

deposit_belt_lock_output_area

deposit_belt_occupied

deposit_belt_lock_input_area

deposit_belt_idle

deposit_belt_transporting (6.1)

(6) deposit_belt

(6.1) deposit_belt_transporting

Appendix A


ch_CF_full

ch_CF_free

ch_DC_free

ch_DC_full

crane_unlock_input_area

crane_unlock_output_area

crane_lock_output_area

crane_storing

crane_lock_input_area

crane_store_free

crane_loading (7.1)

crane_unloading (7.2)

(7) crane


Appendix

crane_mag_on

crane_mag_off

CL_grasp

crane_transport_height

crane_pick_up_height

crane_lift

crane_stop_v

CL_loaded

CL_ready_to_transport

crane_above_feed_belt

crane_above_deposit_belt

crane_to_belt1

crane_stop_h

CL_out

CL_ready_to_grasp

CL_in

crane_stop_v

crane_lower


crane_pick_up_height

crane_unlock_input_area

crane_lock_input_area

lift

transport

lower

(7.1) crane_loading

Appendix A


crane_release_height


crane_lower

crane_stop_v

CU_in

CU_ready_to_ungrasp

CU_out

crane_stop_h

crane_to_belt2

crane_above_feed_belt

crane_above_deposit_belt

CU_ready_to_transport

CU_unloaded

crane_stop_v

crane_lift

crane_release_height


CU_ungrasp

crane_mag_on

crane_mag_off

crane_unlock_output_area

crane_lock_output_area

lower

transport

lift

(7.2) crane_unloading

B - 18 BTU Report I-08/1995

Appendix

B Analysis Protocols - Samples

B.1 INA Protocols

INA Session Protocol 1:

Integrated Net Analyzer session report:Current net options are: token type: black (for Place/Transition nets) time option: no times firing rule: normal priorities : not to be used strategy : single transitions line length: 80

Net read from arm3.pntInformation on elementary structural properties:The net has no bad reachable states.The net is not statically conflict-free.The net is pure.The net is ordinary.The net is homogenous.The net is not conservative.The net is not subconservative.The net is not a state machine.The net is not free choice.The net is not extended free choice.The net is extended simple.The net is marked.The net is not marked with exactly one token.The net is not a marked graph.The net has a non-blocking multiplicity.The net has no nonempty clean trap.The net has no transitions without pre-place.The net has no transitions without post-place.The net has no places without pre-transition.The net has no places without post-transition.Maximal in/out-degree: 2The net is connected.The net is strongly connected.

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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S ? ? ? ? ? ? ? ? ? ? N ? ? ? ? ?

place invariants base of net 0.arm3 :================= 1 | 1.ready_to_gather : 1, | 2.ready_to_consume: 1 + 2 | 4.ready_to_produce: 1, | 5.ready_to_deliver: 1 +

Appendix B

December 1995 B - 19

3 | 0.input_area_free : 1, | 7.input_available : 1, | 9.waiting_for_swiv: 1, | 10.loading : 1 + 4 | 3.output_area_free: 1, | 6.output_available: 1, | 8.store_free : -1, | 9.waiting_for_swiv: -1, | 11.storing : -1, | 12.swivel : 1, | 15.unloading : 1 5 | 0.input_area_free : 1, | 3.output_area_free: 1, | 6.output_available: 1, | 7.input_available : 1, | 8.store_free : -1, | 11.storing : -1, | 16.having_swivel_2 : -1, | 18.having_swivel_1 : -1 6 | 8.store_free : 1, | 9.waiting_for_swiv: 1, | 11.storing : 1, | 12.swivel : -1, | 19.waiting_for_swiv: 1

At least the following places are covered by semipositive invariants: 0.input_area_free, 1.ready_to_gather, 2.ready_to_consume, 4.ready_to_produce, 5.ready_to_deliver, 7.input_available, 9.waiting_for_swiv, 10.loading,

The net is covered by semipositive P-invariants.The net is structurally bounded.The net is bounded.There are no proper semipositive T-surinvariants.

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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S ? ? ? ? Y ? Y Y ? ? N ? ? ? ? ?

Structural liveness properties of net nr. 0.arm3 :processed candidates: 88There are 6 minimal deadlocks:------------------------------- 1: 10.loading, 12.swivel, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, 2: 8.store_free, 9.waiting_for_swiv, 10.loading, 11.storing, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, 19.waiting_for_swiv, 3: 4.ready_to_produce, 5.ready_to_deliver, 4: 3.output_area_free, 6.output_available, 15.unloading, 19.waiting_for_swiv, 5: 1.ready_to_gather, 2.ready_to_consume, 6: 0.input_area_free, 7.input_available, 9.waiting_for_swiv,


Appendix

10.loading,

Corresponding maximal traps:---------------------------- 1: 10.loading, 12.swivel, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, 2: 8.store_free, 9.waiting_for_swiv, 10.loading, 11.storing, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, 19.waiting_for_swiv, 3: 4.ready_to_produce, 5.ready_to_deliver, 4: 3.output_area_free, 6.output_available, 15.unloading, 19.waiting_for_swiv, 5: 1.ready_to_gather, 2.ready_to_consume, 6: 0.input_area_free, 7.input_available, 9.waiting_for_swiv, 10.loading,

The deadlock-trap-property is valid.The net has no dead reachable states.The net is live.The net has no dead transitions at the initial marking.The net is live, if dead transitions are ignored.The net is covered by semipositive T-invariants.

SM-allocatability of net nr. 0:********************************Some minimal place sets Q with QF=FQ, but all SCSM’s:

1: 10.loading, 12.swivel, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, SCSM 2: 8.store_free, 9.waiting_for_swiv, 10.loading, 11.storing, 15.unloading, 16.having_swivel_2, 18.having_swivel_1, 19.waiting_for_swiv, SCSM 3: 4.ready_to_produce, 5.ready_to_deliver, SCSM 4: 3.output_area_free, 6.output_available, 15.unloading, 19.waiting_for_swiv, SCSM 5: 1.ready_to_gather, 2.ready_to_consume, SCSM 6: 0.input_area_free, 7.input_available, 9.waiting_for_swiv, 10.loading, SCSM 6 minimal component(s) found.

The net is state-machine decomposable (SMD).The net is coverable by state-machines (SMC).The net is not state-machine allocatable (SMA).A pre-place allocation allocating no SCSM: 0==> 2, 1==> 6, 2==> 0, 3==> 4, 4==> 8, 5==> 9, 6==> 18, 7==> 3, 8==> 15, 9==> 16, 10==> 10, 11==> 12,The net is covered by 1-token SCSM’s.

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 YDTP 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 N N ? Y Y ?

Appendix B


Computation of the Reachability graph.States generated: 96

Capacities needed:Places 0 1 2 3 4 5 6 7 8 9 10 11 12 15 16 18 19 0: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1The net is safe.The net is live and safe.

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 YDTP 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 N N ? Y Y Y

Graph analysis:The initial state is reproducible.The net is dynamically conflict-free.maximal outdegree of a reachability-graph-node = 3Computation of the terminal SC-componentsThe net is reversible (resetable).

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 YDTP 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

End of Analyser session.



Net read from subsystem2.pntInformation on elementary structural properties:The net has no bad reachable states.The net is not statically conflict-free.The net is pure.The net is ordinary.The net is homogenous.The net is not conservative.The net is not subconservative.The net is not a state machine.The net is not free choice.The net is not extended free choice.The net is extended simple.The net is marked.The net is not marked with exactly one token.

Appendix B


| 9.output_area_free: 1, | 34.arm2v2_unloading: 1 + 10 | 4.press_ready_for_: 1, | 8.output_available: -1, | 9.output_area_free: -1, | 10.ch_PA2_free : -1, | 11.ch_PA2_full : -1, | 28.arm2v2_store_fre: 1, | 30.arm2v2_storing : 1, | 35.arm2v2_having_sw: 1, | 37.arm2v2_having_sw: 1, | 38.arm2v2_waiting_f: 1, | 39.arm2v2_waiting_f: 1

At least the following places are covered by semipositive invariants: 2.press_ready_for_, 3.press_go_unload_, 4.press_ready_for_, 5.press_go_load_po, 6.input_available, 7.input_area_free, 8.output_available, 9.output_area_free, 12.ready_to_deliver, 13.ready_to_produce, 14.ready_to_consume, 15.ready_to_gather, 17.arm1v2_loading, 34.arm2v2_unloading,



Structural liveness properties of net nr. 0.subsystem2 :processed candidates: 3851There are 13 minimal deadlocks:The deadlock-trap-property is not valid.

SM-allocatability of net nr. 0:********************************The net is state-machine decomposable (SMD).The net is coverable by state-machines (SMC).The net is not state-machine allocatable (SMA).The net is covered by 1-token SCSM’s.

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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S N Y Y N Y ? Y Y ? ? N ? ? ? ? ?

Computation of stubborn reduced reachability graph.States generated: 75

Capacities needed:Places 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 23 25 26 : 27 28 29 30 31 34 35 37 38 39


Appendix

0: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1The net has dead reachable states.The net is not live.The net is not live and safe.The net is not reversible (resetable).The net has no dead transitions at the initial marking.The net is not live, if dead transitions are ignored.

States of net 0:State nr: 23 generated from 22 by 15 PL: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 23 25 26 : 27 28 29 30 31 34 35 37 38 39 MA: 0 0 0 0 1 0 1 0 0 1 0 1 1 0 0 1 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 0

State nr: 42 generated from 41 by 15 PL: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 23 25 26 : 27 28 29 30 31 34 35 37 38 39 MA: 0 0 0 0 1 0 1 0 0 1 0 1 1 0 0 1 0 0 0 0 0 0 1 : 0 0 0 1 0 0 0 0 0 0



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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S N Y Y N Y ? Y Y N Y N N ? N N N

[The following has been done just for comparison.]Computation of the Reachability graph.States generated: 1984

Capacities needed:Places 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 23 25 26 : 27 28 29 30 31 34 35 37 38 39 0: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1The net is safe.

States of net 0:State nr: 23 generated from 22 by 15 PL: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 22 23 25 26 : 27 28 29 30 31 34 35 37 38 39

Appendix B


MA: 0 0 0 0 1 0 1 0 0 1 0 1 1 0 0 1 0 0 0 0 0 0 1 : 0 1 0 0 0 0 0 0 0 0




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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S N Y Y N Y ? Y Y N Y N N ? N N N

Graph analysis:Dead states: 23, 42, 478, 632,The initial state is reproducible.Computation of the dynamic conflicts:The net is not dynamically conflict-free.maximal outdegree of a reachability-graph-node = 5Computation of the terminal SC-componentsList of terminal strongly connected components: 1: [23..23] 2: [42..42] 3: [478..478] 4: [632..632]Livenesstest:There are dead transitions at the following nodes:[It follows a list filling several pages.]There is no live transition.

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 YDTP SMC SMD SMA CPI CTI B SB REV DSt BSt DTr DCF L LV L&S N Y Y N Y ? Y Y N Y N N N N N N



Integrated Net Analyzer session report:


Appendix

Current net options are: token type: black (for Place/Transition nets) time option: no times firing rule: normal priorities : not to be used strategy : single transitions line length: 80

Net read from subsystem3.pntInformation on elementary structural properties:The net has no bad reachable states.The net is not statically conflict-free.The net is pure.The net is ordinary.The net is homogenous.The net is not conservative.The net is not subconservative.The net is not a state machine.The net is not free choice.The net is not extended free choice.The net is extended simple.The net is marked.The net is not marked with exactly one token.The net is not a marked graph.The net has a non-blocking multiplicity.The net has no nonempty clean trap.The net has no transitions without pre-place.The net has no transitions without post-place.The net has no places without pre-transition.The net has no places without post-transition.Maximal in/out-degree: 4The net is connected.The net is strongly connected.


place invariants base of net 0.subsystem3 :================= 1 | 4.press_ready_for_: 1, | 5.press_go_unload_: 1, | 6.press_ready_for_: 1, | 7.press_go_load_po: 1 + 2 | 10.output_available: 1, | 11.output_area_free: 1, | 12.arm2_store_free : -1, | 13.arm2_waiting_for: -1, | 14.arm2_loading : -1, | 15.arm2_storing : -1, | 20.arm2_having_swiv: -1, | 22.arm2_having_swiv: -1 3 | 10.output_available: 1,


Appendix

10.output_available, 11.output_area_free, 19.arm2_unloading, 23.arm2_waiting_for, 27.arm1_waiting_for, 28.arm1_loading, 38.ready_to_deliver, 39.ready_to_produce, 40.ready_to_consume, 41.ready_to_gather,



Structural liveness properties of net nr. 0.subsystem3 :processed candidates: 725The deadlock-trap-property is valid.The net has no dead reachable states.The net is live.The net has no dead transitions at the initial marking.The net is live, if dead transitions are ignored.The net is covered by semipositive T-invariants.

SM-allocatability of net nr. 0:********************************The net is state-machine decomposable (SMD).The net is coverable by state-machines (SMC).The net is not state-machine allocatable (SMA).The net is covered by 1-token SCSM’s.

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 YDTP 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 N N ? Y Y ?

Computation of the Reachability graph.States generated: 1800

Capacities needed:Places 2 3 4 5 6 7 8 9 10 11 12 13 14 15 19 20 22 23 24 25 26 27 28 : 29 30 33 34 36 37 38 39 40 41 0: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1The net is safe.The net is live and safe.

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 YDTP 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 N N ? Y Y Y

Graph analysis:The initial state is reproducible.

Appendix B


The net is not dynamically conflict-free.maximal outdegree of a reachability-graph-node = 5Computation of the terminal SC-componentsThe net is reversible (resetable).

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 YDTP 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




Net read from fullsysAll.pntInformation on elementary structural properties:The net has no bad reachable states.The net is not statically conflict-free.The net is not pure.The net is ordinary.The net is homogenous.The net is not conservative.The net is not subconservative.The net is not a state machine.The net is not free choice.The net is not extended free choice.The net is not extended simple.The net is marked.The net is not marked with exactly one token.The net is not a marked graph.The net has a non-blocking multiplicity.The net has no nonempty clean trap.The net has no transitions without pre-place.The net has no transitions without post-place.The net has no places without pre-transition.The net has no places without post-transition.Maximal in/out-degree: 16The net is connected.The net is strongly connected.

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


Appendix

place invariants base of net 0.fullsysAll :=================

[There are 59 place invariants filling several pages.]

At least the following places are covered by semipositive invariants: 12.deposit_belt_idl, 13.deposit_belt_occ, 14.deposit_belt_emp, 44.crane_store_free, 48.A2U_rot1_rs, 49.A2U_rot1_run, 61.A2U_rot3_rs, 62.A2U_rot3_run, 72.arm2_release_ext, 73.arm2_retract_ext, 74.arm2_forward, 75.arm2_stop, 77.A2U_ret_rs, 78.A2U_ret_run, 81.arm2_backward,84.arm2_magnet_off, 85.arm2_magnet_on, 112.arm2_pick_up_ext, 117.A2L_ret_rs, 118.A2L_ret_run, 130.arm1_pick_up_ang, 131.arm1_release_ang, 132.robot_left, 133.robot_stop, 147.arm2_pick_up_ang,148.arm2_release_ang, 152.arm1_pick_up_ext, 153.arm1_retract_ext, 154.arm1_forward, 155.arm1_stop, 157.A1L_ret_rs, 158.A1L_ret_run, 161.arm1_backward, 164.arm1_magnet_on, 165.arm1_magnet_off, 167.A1U_rot1_rs, 168.A1U_rot1_run, 171.robot_right, 174.A1U_rot2_rs,175.A1U_rot2_run, 190.arm1_release_ext, 195.A1U_ret_rs, 196.A1U_ret_run, 207.PL_lower_rs, 208.PL_lower_run, 209.press_at_middle_, 210.press_at_lower_p, 212.press_stop, 216.press_down,217.press_at_upper_p, 224.press_upward, 227.forge_rs, 228.forge_run, 233.TL_lower_rs, 234.TL_lower_run, 246.table_stop_v, 247.table_upward,248.table_bottom_pos, 249.table_top_pos, 253.table_load_angle, 254.table_unload_ang, 255.TU_lift_rs, 256.TU_lift_run, 259.FB_trans_rs,260.FB_trans_run, 261.FB_deliver_rs, 262.FB_deliver_run, 263.belt1_light_barr, 264.belt1_light_barr, 266.belt1_stop, 274.DB_trans_rs, 275.DB_trans_run, 276.DB_deliver_rs, 277.DB_deliver_run, 278.belt2_light_barr, 279.belt2_light_barr, 281.belt2_stop, 282.DB_in, 283.DB_at_end, 288.DB_out, 292.crane_release_he, 295.CU_unloaded, 296.CU_ready_to_tran, 299.crane_to_belt2, 301.CU_out, 308.CU_lift_rs, 309.CU_lift_run, 314.CL_lower_rs, 315.CL_lower_run, 316.CL_trans_rs, 317.CL_trans_run,320.crane_pick_up_he, 321.crane_transport_, 324.CL_in, 325.CL_ready_to_gras, 327.crane_stop_h, 329.crane_above_depo, 330.crane_above_feed, 338.crane_mag_on,


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

Appendix B


Computation of stubborn reduced reachability graph.States generated: 528

Capacities needed:Places 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 : 23 24 28 30 31 32 33 34 35 36 37 40 42 43 44 45 46 47 48 49 54 5556 : 60 61 62 66 69 70 71 72 73 74 75 76 77 78 81 83 84 85 86 87 88 8994 : 95 96 100 101 102 106 109 110 111 112 116 117 118 123 126 127 128129 130 131 132 133 134 : 135 136 140 141 142 146 147 148 149 150 151 152 153 154 155 156 157158 161 163 164 165 166 : 167 168 171 173 174 175 179 180 181 185 188 189 190 194 195 196 201204 205 206 207 208 209 : 210 211 212 213 214 216 217 219 220 221 222 224 227 228 229 230 231232 233 234 239 244 245 : 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262263 264 265 266 267 268 : 273 274 275 276 277 278 279 280 281 282 283 288 292 295 296 299 301302 303 308 309 310 311 : 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328329 330 331 332 334 337 : 338 0: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1The net has no dead transitions at the initial marking.The net has no dead reachable states.

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



Appendix

B.2 PROD Protocols

PROD Include Files:

Definition File for the CTL Operators (ctl.prb)

/* The original CTL implementation by PROBE: */#define Not(f) (not (f))#define And(f1, f2) (not not ((f1) and (f2)))#define Or(f1, f2) (not ((not (f1)) and not (f2)))#define IfThen(f1, f2) (not ((f1) and not (f2)))#define NextOnSomeBranch(f) (not not step (f))#define NextOnAllBranches(f) (not step not (f))#define UntilOnSomeBranch(f1, f2) (not not dspan(f1, false) (f2))#define UntilOnAllBranches(f1, f2) (not dspan(not (f2), true) \

((not ((step true) and (f1))) and not (f2)))#define EventuallyOnSomeBranch(f) (not not dspan(true, false) (f))#define EventuallyOnAllBranches(f) (not dspan(not (f), true) \

((not step true) and not (f)))#define HenceforthOnSomeBranch(f) (not not dspan(not not (f), true) \

((not step true) and not not (f)))#define HenceforthOnAllBranches(f) (not dspan(true, false) (not (f)))

/* Shortcuts: */#define If(f1, f2) (not ((f1) and not (f2)))#define XE(f) (not not step (f))#define XA(f) (not step not (f))#define UE(f1, f2) (not not dspan(f1, false) (f2))#define UA(f1, f2) (not dspan(not (f2), true) \

((not ((step true) and (f1))) and not (f2)))#define FE(f) (not not dspan(true, false) (f))#define FA(f) (not dspan(not (f), true) \

((not step true) and not (f)))#define GE(f) (not not dspan(not not (f), true) \

((not step true) and not not (f)))#define GA(f) (not dspan(true, false) (not (f)))

/* For save nets only: */#define _(p) (p != empty)

Definition File for the LTL Operators (ltl.prb)/* Shortcuts */#define _(p) (p != empty)#define G henceforth#define F eventually#define U until

/* Additional operators: */#define xor(f1, f2) ((not (f1) and (f2)) or ((f1) and not (f2)))#define xor3(f1, f2, f3) (xor(f1, xor(f2, f3)))#define xor4(f1, f2, f3, f4) (xor(f1, xor3(f2, f3, f4)))

Appendix B


#define xor5(f1, f2, f3, f4, f5) (xor(f1, xor4(f2, f3, f4, f5)))#define W(f1, f2) (((f1) and (f2)) until (not (f1)))

PROD Querries

Batch File for the Analysis Using CTL

load ctl.prb

statistics

/* Requirement 22 */query GA(Not(And(_(ch_CF_free), _(ch_CF_full))))query GA(Not(And(_(ch_FT_free), _(ch_FT_full))))query GA(Not(And(_(ch_TA1_free), _(ch_TA1_full))))query GA(Not(And(_(ch_A1P_free), _(ch_A1P_full))))query GA(Not(And(_(ch_PA2_free), _(ch_PA2_full))))query GA(Not(And(_(ch_A2D_free), _(ch_A2D_full))))query GA(Not(And(_(ch_DC_free), _(ch_DC_full))))

/* Requirement 23 */query GA(Or(Not(And(_(ch_DC_free), _(ch_DC_full))), \

Not(And(_(ch_CF_free), _(ch_CF_full)))))query GA(Or(Not(And(_(ch_TA1_free),_(ch_TA1_full))), \

Not(And(_(ch_A1P_free), _(ch_A1P_full)))))query GA(Or(Not(And(_(ch_PA2_free), _(ch_PA2_full))), \

Not(And(_(ch_A2D_free), _(ch_A2D_full)))))

/* Requirement 24 */query GA(If(_(deposit_belt_transporting), \

Not(Or(_(ch_DC_free), \Or(_(ch_DC_full), \

Or(_(ch_A2D_free), _(ch_A2D_full)))))))query GA(If(_(feed_belt_transporting), \

Not(Or(_(ch_CF_free), \Or(_(ch_CF_full), \

Or(_(ch_FT_free),_(ch_FT_full)))))))

/* Requirement 25 */query GA(Not(And(Or(_(ch_FT_full), _(ch_FT_free)), \

Or(_(ch_TA1_full), _(ch_TA1_free))))))query GA(Not(And(Or(_(ch_PA2_full), _(ch_PA2_free)), \

Or(_(ch_A1P_full), _(ch_A1P_free))))))

/* Requirement 8 */query GA(If(Or(_(arm1_loading), _(arm1_unloading)), \

Or(Not(_(press_go_load_pos)), \Not(_(press_go_unload_pos)))))

query GA(If(Or(_(arm2_loading), _(arm2_unloading)), \Or(Not(_(press_go_load_pos)), \

Not(_(press_go_unload_pos)))))

/* Requirement 15 */


Appendix

query GA(If(Not(_(table_ready_for_loading)), \Not(_(feed_belt_transporting))))

/* Requirement 16 */query GA(Not(And(_(crane_loading), _(deposit_belt_transporting))))

/* Requirement 17 */query GA(If(_(feed_belt_transporting), Not(_(crane_unloading))))

/* Requirement 18 */query GA(If(_(deposit_belt_transporting), Not(_(arm2_unloading))))

quit

probe output:

#0Number of nodes: 12144Number of arrows: 45362Number of terminal nodes: 0Number of nodes that have been completely processed: 12144Number of strongly connected components: 1Number of nontrivial terminal strongly connected components: 0

#0 01 pathsBuilt set %1------------------------------------------------#0 01 pathsBuilt set %2------------------------------------------------

[The remaining output has been omitted.]

Examples of LTL Formulae in PROD

To check the validity of the formulae below it is neccessary to construct a separate reach-ability graph for each of them. Hence each formula must be included into the net descrip-tion file. Since the reduced reachability graph generated for the on-the-fly verification ofsome formula is useful for further analysis only in the case where a system does not satisfythis formula, we did not invoke PROD’s program components strong and probe. As aconsequence, prod terminates without any further output if the net under considerationsatisfies the formula to verify. Otherwise, the reachability graph generator component out-puts the first infinite path for which this formula does not hold.

Invariant properties:

#verify G(xor3(_(robot_stop), _(robot_left), _(robot_right)));#verify G(xor4(_(arm1_pick_up_angle), \

_(arm1_release_angle), \_(arm2_pick_up_angle), \_(arm2_release_angle));

Appendix B


Requirement 32.b:

#verify G((_(arm2_pick_up_angle) and \_(arm2_pick_up_ext) and \_(arm2_magnet_on)) implies \(_(arm2_magnet_on) U \

(_(arm2_release_ext) and _(arm2_release_angle))));

Requirement 31:

#verify G(W(_(crane_to_belt1), _(crane_mag_on)));#verify G(W(_(crane_above_deposit_belt) and_(crane_lift),

_(crane_mag_on))); \#verify G(W(_(crane_above_feed_belt) and _(crane_lower), \

_(crane_mag_on)));

Requirement 8:

#verify G((_(arm2_pick_up_angle) and _(arm2_pick_up_ext)) implies \ (_(press_stop) and not _(press_at_upper_pos)));

We now demonstrate what happens if a formula does not hold for a system. We ask for thevalidity of the formula

for the net description of the control model:> prod fullsysAll.net-n Compiling...-n Generating reachability graph.....................................Illegal infinite path foundLoop 258 [0> 343 [0> 344 [0> 345 [0> 346 [0> 347 [0> 348 [0> 349 [0> 350[0> 351 [0> 352 [0> 353 [0> 354 [0> 355 [0> 356 [0> 357 [0> 358 [0> 359[0> 360 [0> 361 [0> 362 [0> 363 [0> 364 [0> 365 [0> 366 [0> 367 [0> 368[0> 369 [0> 370 [0> 371 [0> 372 [0> 373 [0> 374 [0> 375 [0> 376 [0> 377[0> 378 [0> 379 [0> 380 [0> 381 [0> 382 [0> 383 [0> 131 [0> 132 [0> 134[0> 135 [0> 136 [0> 137 [0> 138 [0> 139 [0> 140 [0> 141 [0> 142 [0> 143[0> 144 [0> 145 [0> 146 [0> 147 [0> 148 [0> 149 [0> 150 [0> 151 [0> 152[0> 154 [0> 155 [0> 156 [0> 157 [0> 158 [0> 159 [0> 160 [0> 161 [0> 162[0> 163 [0> 164 [0> 165 [0> 166 [0> 167 [0> 168 [0> 169 [0> 170 [0> 171[0> 172 [0> 173 [0> 174 [0> 175 [0> 176 [0> 177 [0> 178 [0> 179 [0> 180[0> 181 [0> 182 [0> 183 [0> 184 [0> 185 [0> 186 [0> 187 [0> 188 [0> 189[0> 190 [0> 191 [0> 192 [0> 193 [0> 194 [0> 195 [0> 196 [0> 197 [0> 198[0> 201 [0> 202 [0> 203 [0> 204 [0> 205 [0> 206 [0> 207 [0> 208 [0> 209[0> 210 [0> 211 [0> 212 [0> 213 [0> 214 [0> 215 [0> 216 [0> 217 [0> 218[0> 219 [0> 220 [0> 221 [0> 222 [0> 223 [0> 224 [0> 225 [0> 226 [0> 227[0> 228 [0> 231 [0> 232 [0> 233 [0> 234 [0> 235 [0> 236 [0> 237 [0> 238[0> 239 [0> 240 [0> 241 [0> 242 [0> 243 [0> 244 [0> 245 [0> 246 [0> 247[0> 248 [0> 249 [0> 250 [0> 251 [0> 252 [0> 253 [0> 254 [0> 255 [0> 256[1> 258For more information, start “probe fullsysAll” and look at the set %1>

G feed_belt_idle( )


Appendix

> probe fullsysAll0#statisticsNumber of nodes: 384Number of arrows: 384Number of terminal nodes: 1Number of nodes that have been completely processed: 376Strongly connected components have not been computed0#verbose build %1PATHNode 258 arm1_retract_ext: <.1.> arm1_stop: <.1.> arm1_magnet_off: <.1.> arm1_release_angle: <.1.> robot_stop: <.1.> table_ready_for_loading: <.1.> table_stop_v: <.1.> table_bottom_pos: <.1.> table_stop_h: <.1.> table_load_angle: <.1.> deposit_belt_occupied: <.1.> belt2_light_barrier_false: <.1.> belt2_stop: <.1.> press_at_lower_pos: <.1.> press_stop: <.1.> crane_storing: <.1.> arm1_store_free: <.1.> swivel: <.1.> arm2_storing: <.1.> feed_belt_idle: <.1.> press_ready_for_unloading: <.1.> arm2_retract_ext: <.1.> arm2_stop: <.1.> arm2_magnet_on: <.1.> belt1_light_barrier_false: <.1.> belt1_stop: <.1.> crane_transport_height: <.1.> crane_stop_v: <.1.> crane_stop_h: <.1.> crane_above_feed_belt: <.1.> crane_mag_on: <.1.> ch_DC_full: <.1.> ch_CF_free: <.1.> ch_FT_free: <.1.> ch_PA2_full: <.1.> t_e_s_t_e_r: <.4.>Arrow 0: transition crane_lock_output_area, precedence class 0 d = 1Node 343 arm1_retract_ext: <.1.> arm1_stop: <.1.> arm1_magnet_off: <.1.> arm1_release_angle: <.1.> robot_stop: <.1.>

Appendix B


table_ready_for_loading: <.1.> table_stop_v: <.1.> table_bottom_pos: <.1.> table_stop_h: <.1.> table_load_angle: <.1.> deposit_belt_occupied: <.1.> belt2_light_barrier_false: <.1.> belt2_stop: <.1.> press_at_lower_pos: <.1.> press_stop: <.1.> arm1_store_free: <.1.> swivel: <.1.> arm2_storing: <.1.> feed_belt_idle: <.1.> press_ready_for_unloading: <.1.> arm2_retract_ext: <.1.> arm2_stop: <.1.> arm2_magnet_on: <.1.> belt1_light_barrier_false: <.1.> belt1_stop: <.1.> crane_transport_height: <.1.> crane_stop_v: <.1.> crane_stop_h: <.1.> crane_above_feed_belt: <.1.> crane_mag_on: <.1.> CU_in: <.1.> ch_DC_full: <.1.> ch_FT_free: <.1.> ch_PA2_full: <.1.> t_e_s_t_e_r: <.5.>

[The remaining output (161 states 110 pages) has been omitted.]

1 pathsBuilt set %2------------------------------------------------0#quit>

≈

C - 38 BTU Report I-08/1995

Appendix

C General Petri Net Properties - OverviewThe analysis tool INA summarizes the main results gained during an analysis sessionwithin a 2-row result vector. The used abbreviations together with a very short explanationare given below. For more details or formal definitions of listed Petri net terms see [Starke90, 92].

Simple Structure Properties

ORD ordinary (1-multiplicity of all arcs)HOM homogeneous (all output arcs of a given place have the same multiplicity)NBM non-blocking multiplicity (for each place applies:

MIN multiplicity of input arcs MAX multiplicity of output arcs)

PUR pure (no side conditions)CSV conservative (any firing preserves token amount)SCF static conflict freeCON connectedSC strongly connectedFt0 there is a transition without pre-placetF0 there is a transition without post-placeFp0 there is a place without pre-transitionpF0 there is a place without post-transitionMG marked graph (synchronization graph)SM state machineFC free choice netEFC extended free choice netES extended simple net

More Expensive Structure Properties

DTP deadlock trap propertySMC state machine coverable (covered with SM components)SMD state machine decomposable (covered with SCSM components)SMA state machine allocatableCPI covered with place invariantsCTI covered with transition invariantsSB structurally bounded

Behaviour Properties

B boundedREV reversible (the initial state can be reached again

from all reachable states)DSt dead states (a state where no transition can fire)BSt bad states (a state where a fact can fire)DTr dead transitions (at the initial state)DCF dynamically conflict freeL liveLV live, excepted transitions dead at the initial marking

(live, excepted implicit facts)L&S live & safe (1-bounded)

≥

Appendix D

December 1995 D - 39

D References[Ben-Ari 83]

Ben-Ari, M.; Pnueli, A; Manna, Z:The Temporal Logic of Branching Time;Acta Informatica 20 (1983), pp. 207-226.

[Best 95]Best, E.; Grahlmann, B.:PEP - Programming Environment Based on Petri Nets, Documentation and User Guide:Univ. Hildesheim, Institut für Informatik, Nov. 1995.

[Casais 94a]Casais, E.:Eiffel; A Reusable Framework for Production Cells Developed with an Object-oriented Programming Language;in: Lewerentz, C.; Lindner, T. (eds.): Case Study “Production Cell” A Comparative Study in Formal Software Development, FZI-Publication 1/94, Forschungszentrum Informatik, Karlsruhe 1994, pp. 241-256.

[Casais 94b]Casais, E.:An Experiment in Framework Development;in Lewerentz, C.; Lindner, T. (eds.): Case Study “Production Cell” A Comparative Study in Formal Software Development, FZI-Publication 1/94, Forschungszentrum Informatik, Karlsruhe 1994, pp. 95-124.

[Clarke 86]Clarke, E. M.; Emerson, E. A.; Sistla, A. P.:Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications;ACM Trans. on Programming Languages and Systems 8(86)2, pp. 244-263.

[Czichy 93]Czichy, G.:Design and Implementation of a Graphical Editor for Hierarch/ical Petri Net Models (in German);Diploma Thesis, TU Dresden - GMD/FIRST, 6/1993.

[Courcoubetis 92]Courcoubetis, C.; Vardi, M. Y.; Wolper, P.; Yannakakis, M.:Memory Efficient Algorithms for the Verification of Temporal Properties;Formal Methods in System Design 1, 2/3 (1992), pp. 275-288.

[Emerson 90]Emerson, E. A.:Temporal and Modal Logic;in: J. v. Leeuwen ed.: Handbook of Theoretical Computer Science, Vol. B, Elsivier Science Publishers B. V., Amsterdam 1990, pp.995-1072.

[Gerth 95]Gerth, R.; Peled, D.; Vardi, M. Y.; Wolper, P.:Simple On-the-fly Automatic Verification of Linear Temporal Logic;in: Proceedings of the 15th International Symposium on Protocol Specification, Testing and Verification (PSTV’95), Warsaw, June1995, pp. 3-18.

[Heiner 80]Heiner, M.:A Contribution to Deadlock Analysis Based on a Language-guided Programming Methodology (in German);Ph. D. Thesis, TU Dresden, 9/1980.

[Heiner 92]Heiner, M.:Petri Net Based Software Validation, Prospects and Limitations;ICSI-TR-92-022, Berkeley/CA, 3/1992.

[Heiner 94a]Heiner, M.; Ventre, G.; Wikarski, D.:A Petri Net Based Methodology to Integrate Qualitative and Quantitative Analysis;Information and Software Technology 36(94)7, 435-441.

D - 40 BTU Report I-08/1995

Appendix

[Heiner 94b]Heiner, M.; Wikarski, D.:An Approach to Petri Net Based Integration of Qualitative and Quantitative Analysis of Parallel Systems;Techn. Report BTU Cottbus, I-09/1994.

[Heiner 95]Heiner, M.:Petri Net Based Software Dependability Engineering;Tutorial Notes, Int. Symposium on Software Reliability Engineering, Toulouse, Oct. 1995, 100 p.

[Josko 93]Josko, B.:Modular Specification and Verification of Reactive Systems;Ph. D. Thesis, Universität Oldenburg, 1993.

[Kroeger 87]Kröger, F.:Temporal Logic of Programs;EATCS 8, Springer Verlag, Berlin 1987.

[Lewerentz 95]Lewerentz, C.; Lindner, T.:Formal Development of Reactive Systems - Case Study Production Cell;LNCS 891, 1995.

[Manna 92]Manna, Z.; Pnueli, A.:The Temporal Logic of Reactive and Concurrent Systems - Specifications;Springer Verlag, Berlin 1992.

[Michaelis 93]Michaelis, M.:Objektorientierte Modellierung einer Fertigungszelle mit Eiffel (in German);Diplomarbeit Univ. Karlsruhe, Fakultät für Informatik, June 1993.

[Popova 91]Popova, L.:On Time Petri Nets;J. Information Processing and Cybernetics EIK 27(91)4, 227-244.

[Popova 95]Popova, L.:An Algorithm for Computing the Shortest and the Largest Path in Time Petri Nets;Informatik-Bericht, Humboldt University at Berlin, 1995 (to appear).

[Schwidder 95]Schwidder, K.:Programming by Petri nets;unpublished notes.

[Starke 90]Starke, P. H.:Analysis of Petri Net Models (in German);B.G.Teubner 1990.

[Starke 92]Starke, P. H.:INA - Integrated Net Analyzer, Manual (in German);Berlin 1992.

[Valmari 92a]Valmari, A.:A Stubborn Attack on State Explosion;Formal Methods in System Design 1, (1992) 4, pp. 297-322.

Appendix D

December 1995 D - 41

[Valmari 92b]Valmari, A.:Alleviating State Explosion during Verification of Behavioral Equivalence;Univ. of Helsinki, Department of Computer Science, Report A-1992-4, Helsinki 1992.

[Varpaaniemi 94]Varpaaniemi, K.:On Computing Symmetries and Stubborn Sets;Helsinki Univ. of Technology, Digital Systems Laboratory Report B 12, Espoo 1994.

[Varpaaniemi 95]Varpaaniemi, K.; Halme, J.; Hiekkanen, K.; Pyssysalo, T.:PROD Reference Manual;Helsinki Univ. of Technology, Digital Systems Laboratory, Series B: Techn. Report No. 13, August 1995.

[Wikarski 95]Wikarski, D.; Heiner, M.:On the Application of Markovian Object Nets to Integrated Qualitative and Quantitative Software Analysis;Fraunhofer ISST, Berlin, ISST-Berichte No. 29/95, Oct. 1995, 33p.

Monika Heiner, Peter Deussen Petri Net Based … Technical University of Cottbus ... 5.3 Special...

Documents

Transcript of Monika Heiner, Peter Deussen Petri Net Based … Technical University of Cottbus ... 5.3 Special...