design and formal analysis of petri net based logic ... · design and formal analysis of petri net...

Design and formal Analysis of Petri Net based Logic Control Algorithms

Entwurf und formale Analyse Petrinetz-basierter Steuerungsalgorithmen

vom

Fachbereich Elektro- und Informationstechnik der Universität Kaiserslautern

zur Erlangung des akademischen Grades eines

Doktor der Ingenieurwissenschaften (Dr.-Ing.)

genehmigte Dissertation

von

Dipl.-Ing. Georg Frey

geb. in Mosbach

D386

Eingereicht am: 23. Januar 2002

Tag der mündlichen Prüfung: 15. Februar 2002

Dekan des Fachbereichs: Prof. Dr.-Ing. Ralph Urbansky

Promotionskommission

Vorsitzender: Prof. Dr.-Ing. habil. Norbert Wehn

Berichterstattende: Prof. Dr.-Ing. habil. Lothar Litz

Prof. Dr. Habil. Jean-Jacques Lesage

Acknowledgements

The work that has resulted in this thesis could not be performed without the support from several people.

First of all, I would like to thank, Prof. Dr.-Ing. habil. Lothar Litz for the opportunity to be a mem-

ber of his research group at the Institute of Automatic Control at the University of Kaiserslautern, and for all encouragement and guidance he has given to me. Prof. Litz not only knows Logic Con-

trol, but also how to provide a working atmosphere of intellectual freedom and fruitful co-operation and to work in his team is certainly a privilege.

Being a member of a group like the Institute of Automatic Control in Kaiserslautern has given me

memories I will never forget: Joint excursions and festivities, interesting discussions on a variety of topics (not necessarily related to our research), and much more. Working in an inspiring and warm atmosphere like this makes this group special: Many thanks to all of you.

I would like to thank the advisors of this thesis, Prof. Dr.-Ing. habil. Lothar Litz and Prof. Dr. Habil. Jean-Jacques Lesage from the Ecole Normale Supérieure de Cachan (France) for the interest they took in my work and the time and effort they invested in reviewing this thesis. I would also like to thank Prof. Dr.-Ing. habil. Norbert Wehn for acting as Chair of the Evaluation Committee.

This work was supported financially by the „Deutsche Forschungsgemeinschaft“ (German Research Council, DFG) and the „Stiftung Rheinland-Pfalz für Innovation“ (Innovation Foundation of Rhine-land-Palatinate).

I would like to thank all the people involved in the successful implementation of our SIPN-Editor at infoteam GmbH. Especially Karl-Heinz John for giving me the opportunity to see a part of the con-

cepts presented in this thesis entering the area of practical applications.

To Dr. Mark Minas at the University of Erlangen-Nürnberg: Thank you Mark for the discussions on JAVA and the implementation of the SIPN-Editor.

Thanks to Prof. Dr.-Ing. habil. Jörg Raisch at the MPI in Magdeburg for countless inspiring discus-sions about this work and other even more important topics.

To Stéphane Klein for the help with the French references and for proof reading of this thesis and to Sandra Zilles and Anja Wiesen for proof reading essential parts of the manuscript: Without you there would be considerably more errors in this work. The remaining flaws are all my fault.

To my parents: Thank you for your love and support despite the fact that I am often not capable of explaining to you what I am actually doing. I hope to improve on this matter.

Finally, I give my greatest gratitude to my wife, Nora, for her love, support, patience, and encour-agement: This thesis is to you and because of you. I love you so much.

Kaiserslautern, January 2002 Georg Frey

I

Abstract

The development of logic control algorithms lies outside the realm of classical continuous Control Theory with its strong mathematical foundations and purely formal design approaches. Logic con-troller development is closer to software development, in the sense that a special algorithm has to be developed for every new problem. However, Computer Science offers a variety of formal methods that help to avoid errors in the software development process and allow checking and evaluating the resulting algorithms. In this thesis, concepts from Discrete Event Control Theory and Software En-gineering are combined to a formal development approach for logic controllers. Based on Petri Nets the complete controller development process from an informal specification to the final implemen-

tation on a programmable logic controller is discussed. This process includes the steps of design, verification, validation, evaluation (measurement of quality), and implementation. Special emphasis

is put on the evaluation step that is new to logic controller development.

Der Entwurf von Steuerungsalgorithmen liegt außerhalb der klassischen, kontinuierlichen Rege-

lungstheorie mit ihrem gesicherten mathematischen Fundament und ihren strikt formalen Ent-

wurfsmethoden. Der Steuerungsentwurf ist eher mit der Softwareentwicklung verwandt, da für jedes

neue Steuerungsproblem ein spezifischer Algorithmus entwickelt werden muss. Die Informatik bie-

tet jedoch eine Reihe formaler Methoden, die helfen, Fehler in diesem Softwareentwicklungsprozess

zu vermeiden und die resultierenden Algorithmen zu prüfen und zu bewerten. Im vorliegenden Band

werden Konzepte aus den Bereichen der ereignisdiskreten Systemtheorie und des Software-

Engineering kombiniert. Basierend auf Petrinetzen wird der vollständige Steuerungsentwicklungs-

prozess ausgehend von der informellen Spezifikation über Entwurf, Verifikation, Validierung und

Bewertung (Messung der Qualität) bis zur abschließenden Implementierung auf einer speicherpro-grammierbaren Steuerung betrachtet. Besonderes Gewicht wird dabei dem im Steuerungsbereich

noch neuen Bereich der Bewertung beigemessen.

III

Contents

1. Introduction 1 1.1 Motivation ...............................................................................................................................1

1.2 Organization of the Thesis......................................................................................................1

1.3 New and Important Approaches.............................................................................................2

2. Development of Logic Controllers 5 2.1 Introductory Overview............................................................................................................5

2.2 The Control Engineering Point of View ................................................................................5

2.2.1 The Standard Approach ..............................................................................................5 2.2.2 Application of Formal Methods .................................................................................8 2.2.3 Verification and Validation ......................................................................................10 2.2.4 Summary....................................................................................................................13

2.3 The Software Engineering Point of View............................................................................14

2.3.1 Software Quality in General .....................................................................................14 2.3.2 Software Quality in Logic Controller Development ...............................................16 2.3.3 Summary....................................................................................................................17

2.4 The Combined Point of View...............................................................................................18

3. Theory of Signal Interpreted Petri Nets (SIPN) 19 3.1 SIPN as a new PLC Programming Language......................................................................19

3.2 Definition and Meaning of SIPN..........................................................................................22

3.2.1 Basic Definitions and Notations ...............................................................................22 3.2.2 SIPN Definition.........................................................................................................24 3.2.3 Graphical Representation..........................................................................................29 3.2.4 Logic Control Semantics...........................................................................................30 3.2.5 Principles of SIPN.....................................................................................................30

3.3 SIPN Analysis .......................................................................................................................31

3.3.1 Reachability in SIPN.................................................................................................31 3.3.2 Dynamic Synchronization (DS)................................................................................36 3.3.3 Basic Petri Net Properties and their Adaptation to SIPN........................................37 3.3.4 Analysis based on the Reachability Graph of the underlying Petri Net .................40 3.3.5 Additional SIPN Properties ......................................................................................42 3.3.6 Analysis based on the Reachability Graph of the SIPN ..........................................42 3.3.7 A Note on Algebraic Analysis..................................................................................43

3.4 Hierarchical SIPN .................................................................................................................43

3.4.1 The Concept of Hierarchy.........................................................................................43 3.4.2 Formal Definition of Hierarchical SIPN ..................................................................45 3.4.3 Analysis of Hierarchical SIPN by Unfolding ..........................................................47 3.4.4 Analysis of Hierarchical SIPN by Extension ...........................................................48

3.5 Relation to other Formalisms ...............................................................................................51

3.5.1 Relation to other Petri Net Models...........................................................................51 3.5.2 Relation to Grafcet according to IEC 60848............................................................53 3.5.3 Relation to SFC according to IEC 61131.................................................................55

3.6 Discussion .............................................................................................................................57

IV

4. Verification 59 4.1 The Verification Process.......................................................................................................59

4.2 Informal Specification of Standard Functional Properties ..................................................60

4.3 Formalization: Criteria for Formal Correctness ..................................................................61

4.4 Summary................................................................................................................................63

5. Evaluation 65 5.1 The Evaluation Process.........................................................................................................65

5.2 Informal Specification of non-functional Properties ...........................................................66

5.3 Formalization: Transparency Metrics ..................................................................................66

5.3.1 Overview and Introductory Example .......................................................................66 5.3.2 Documentation (P1) ..................................................................................................68 5.3.3 Graphical Representation (P2)..................................................................................68 5.3.4 Redundant Information (P3) .....................................................................................69 5.3.5 Visible Dynamics (P4)..............................................................................................71 5.3.6 Complexity (P5) ........................................................................................................72 5.3.7 Combination to one Transparency Metric................................................................76

5.4 Conclusions ...........................................................................................................................79

6. Experimental Validation of the Transparency Metrics 81 6.1 Design of Software Engineering Experiments.....................................................................81

6.2 Definition Phase ....................................................................................................................82

6.3 Planning Phase ......................................................................................................................83

6.3.1 Formulation of the Aim of the Experiment..............................................................83 6.3.2 Assignment of Test Candidates to Groups...............................................................85 6.3.3 Assignment of Projects to Groups............................................................................87

6.4 Operation Phase ....................................................................................................................88

6.4.1 Aspects of an Experiment’s Operation.....................................................................88 6.4.2 Identification and Treatment of Outliers..................................................................89 6.4.3 Preliminary Analysis: Correlation Analysis ............................................................90 6.4.4 Primary Analysis: Hypotheses Testing ....................................................................93

6.4.4.1 Selection of Tests ............................................................................................... 93 6.4.4.2 t-Test................................................................................................................... 95 6.4.4.3 Sign-Test ............................................................................................................ 95

6.4.5 Results of the Analysis..............................................................................................97 6.5 Interpretation .........................................................................................................................97

6.5.1 The Interpretation Phase ...........................................................................................97 6.5.2 Scalability ..................................................................................................................98 6.5.3 Reproducibility..........................................................................................................98 6.5.4 Validity of Experimental Results .............................................................................99

6.5.4.1 Types of Validity................................................................................................ 99 6.5.4.2 Construct Validity .............................................................................................. 99 6.5.4.3 Internal Validity ............................................................................................... 100 6.5.4.4 External Validity .............................................................................................. 101

6.6 Summary..............................................................................................................................102

V

7. Implementation 103 7.1 Introductory Overview........................................................................................................103

7.2 Transformation of Net Elements ........................................................................................103

7.3 Concurrency ........................................................................................................................104

7.4 Iteration................................................................................................................................105

7.4.1 Implementation of Iteration in the PLC Code........................................................105 7.4.2 Simulative Determination of a Transition Sequence .............................................105 7.4.3 Analytical Determination of a Transition Sequence..............................................106 7.4.4 Comparison of the presented Iteration Methods....................................................108

7.5 Implementation of Hierarchical SIPN using the IEC 61131 POU-Concept ....................109

7.6 Summary..............................................................................................................................110

8. Validation 111 8.1 Introductory Overview........................................................................................................111

8.2 Compressed Air Accumulator Example ............................................................................112

8.3 Validation based on SIPN...................................................................................................113

8.4 Validation using the Generated Code ................................................................................114

8.5 Comparison and Concluding Remarks on Validation .......................................................118

9. Summary 119 9.1 Summary in English............................................................................................................119

9.2 Kurzfassung in deutscher Sprache .....................................................................................120

10. Bibliography and Indices 125 10.1 Bibliography........................................................................................................................125

10.2 Index of Definitions ............................................................................................................135

10.3 Index of Tables....................................................................................................................136

10.4 Index of Figures ..................................................................................................................136

10.5 List of often used Symbols and Abbreviations..................................................................138

1

1. Introduction

1.1 Motivation

In today’s flexible, customer-oriented, automated production the creation of control software for the machines and plants is an essential time and cost factor. The increasing complexity of modern soft-ware and the rising user-defined safety and functionality requirements cause the urge for new for-mal methods to develop the control algorithms. This means, not merely to test the algorithms but to prove their correctness.

Furthermore, control algorithms often have to be adapted to new production scenarios. In most cases, the original developer does not perform this adaptation. Therefore, it is important, that a con-troller is well documented and easy to understand. Hence, a method is required that allows the evaluation of the quality of a controller in the light of understandability.

One way to achieve an improvement of the controller development process is the use of Petri Nets, e.g. [Desrochers and Al-Jaar 1994]. There are two main Petri Net based approaches:

• Petri Nets as a modeling tool (design) and

• Petri Nets as an analyzing tool (verification and validation).

In this contribution both approaches are combined and completed by a third, new approach:

• Petri Nets as a visual documentation tool (quality evaluation).

1.2 Organization of the Thesis

In the next Chapter, following this introduction, the logic controller development process is investi-gated from two different points of view, namely Control Theory and Software Engineering. A com-

bined point of view is derived which serves as a foundation for the thesis. This combined point of view results in the structure for the controller development process illustrated in Figure 1-11.

Based on the informal specification of a controller, the development process starts with the synthe-

sis step (initial design) of the controller using the presented formal model or programming ap-proach, the Signal Interpreted Petri Net (SIPN). In Chapter 3 this model is introduced and methods

for its analysis are presented.

Given the formal description of the control algorithm, standard functional properties (like for exam-ple deterministic behavior) can be verified. Those standard properties, as the name indicates, can be

formally specified, independently of the control problem at hand. However, the formalization de-pends on the formal model of the algorithm and the verification methods used. In Chapter 4, stan-

dard functional properties for control algorithms are defined. A part of those properties has to be fulfilled by every logic control algorithm whereas others are optional. For SIPN, a formalization for

all the standard properties is derived, and graph-based methods are given to verify them. The only

1 This figure as well as many that follow are based on the formalism of Channel-Agency-Net [Reisig 1982].

1 Introduction

2

task remaining for the user of the SIPN approach in order to verify a controller is to select which of the optional criteria should be verified. The verification may have to be iterated with corrections of the SIPN until all the properties are fulfilled.

In Chapter 5 properties are specified that allow the evaluation of a controller in the light of program understandability. The informal specification of these non-functional properties is formalized for

SIPN in ten transparency criteria. Those criteria are combined to a transparency metric and methods for the evaluation of this metric are presented. As with verification the criteria to be evaluated are formalized independently of the control problem. However, in contrary to functional criteria, that have to be fulfilled or not, quality criteria have to be fulfilled more or less depending on the applica-tion at hand. Therefore, in the evaluation step the user cannot only include or exclude certain prop-erties but weight them in order to get the intended result. If the controller does not fulfill the non-functional criteria to the required amount, the design has to be improved.

Since the concept of the transparency metric is a completely new approach, an experiment was per-formed to validate it. In Chapter 6 this experiment is described in detail in the context of the theory developed for experiments like this in Software Engineering.

The controller development process ends with the implementation of the SIPN on controller hard-ware. Chapter 7 describes a method to do this by automatic translation of SIPN into Instruction List (IL) according to the IEC 61131-3 standard [IEC 61131-3, John and Tiegelkamp 2001].

The development process would be incomplete without a method for formal validation, i.e. the proof of problem specific functional properties. Therefore, in Chapter 8 two validation approaches for SIPN are discussed. One of them starting directly from the SIPN [Weng and Litz 2001] and a second one based on the generated IL code [Mertke and Frey 2001].

The thesis is concluded by a summary in English and an extended summary in German.

1.3 New and Important Approaches

The general approach presented here differs from other formal development approaches for logic controllers because it includes not only concepts from Control Theory but also quality concepts

from Software Engineering.

The Definition of Signal Interpreted Petri Nets (SIPN) is made more formal to overcome inconsis-

tencies in previous publications. Especially the formal definition of an algebra for the calculation of output signals is a new concept. Furthermore, the formal definition of hierarchical SIPN (SIPNH) is new to the presented work. These formal definitions allow the definitions of corresponding reach-

ability graphs and the specification of algorithms to compute them.

An in-deep investigation of the dynamic behavior of the SIPN reveals the substantial differences to

ordinary Petri Nets. In order to describe these differences, the notion of Dynamic Synchronization (DS) is introduced. With DS, it is possible to describe the relation of SIPN properties to the proper-ties of the underlying ordinary Petri Net concisely.

1.3 New and Important Approaches

3

The definition and formalization of standard functional properties for formal correctness of an SIPN is an adaptation of known criteria. Whereas, the definition of non-functional properties and their formalization in a transparency metric to measure the quality of an algorithm is a completely new concept. The validity of the proposed metric is proved in an empirical study.

Finally, the revised definition of SIPN allows for an improved code generation using Instruction

List according to IEC 61131-3.

Informal Specification

Synthesis(Initial Design)

Control Algorithm

(SIPN)

Verification(Formal Correctness)

Evaluation(Transparency)

SIPN + Verification

Results

Correction(Re-Design)

SIPN + Evaluation

Results

Implementation(Code Generation)

Realization(PLC-Program)

Design Improvement

Standard Functional Properties

Non-Functional Properties

Selection of Standard

Functional Properties

Pre-Formalized Standard


Selection and Weighting of Non-


Pre-Formalized


Validation

Validation


Synthesis(Initial Design)

Control Algorithm

(SIPN)

Verification(Formal Correctness)

Evaluation(Transparency)

SIPN + Verification

Results


SIPN + Evaluation

Results

Implementation(Code Generation)

Realization(PLC-Program)

Design Improvement

Standard Functional Properties


Selection of Standard


Pre-Formalized Standard


Selection and Weighting of Non-


Pre-Formalized


Validation

Validation

Figure 1-1: Logic Controller Development Process also Structure of the Thesis.

5

2. Development of Logic Controllers

2.1 Introductory Overview

In this Section, the development of logic controllers is presented from two different points of view. First, the point of view of conventional control design is taken and the current state of the art in ap-plication of formal methods in this area is reviewed (Section 2.2). In Section 2.3 some ideas from Software Engineering, with a focus on software quality, are presented and their relation to controller development is discussed. A combination of those two completely different points of view is pre-sented in Section 2.4.

2.2 The Control Engineering Point of View

2.2.1 The Standard Approach

Since the 1970s, Programmable Logic Controllers (PLCs) have been the primary workhorse of in-dustrial automation. For a long time the area has provided a distinct field of research, development, and application, mainly for Control Engineering. It has produced its own design methods and pro-

gramming languages. Due to its importance for industrial application, many of these methods have been standardized internationally. Figure 2-1 (adapted from [Christensen 1998]) shows an overview

of the standardization. Currently the most influential standards are IEC 61131 [IEC 61131-3, John and Tiegelkamp 2001] and the upcoming IEC 61499 [IEC 61499-1, Christensen 2000].

77 78 79 81 80 99 70 82 83 84 85 87 86 88 89 90 91 92

NEMA Programmable Controllers Committee formed (USA) GRAFCET (France)

IEC 60848, Function Charts (Grafcet)

DIN 40719, Function Charts (Germany) NEMA ICS-3-304, Programmable Controllers (USA)

IEC SC65A/WG6 formed DIN 19 239, Programmable Controller (Germany)

MIL-STD-1815 Ada (USA)

IEC SC65A(Sec)67

IEC 65A(Sec)38, Programmable Controllers

IEC 61131-3

IEC SC65A(Sec)49, PC Languages

IEC 64A(Sec)90

IEC 61499 CD

Figure 2-1: Standardization in PLC programming.

Although being a rather intuitive discipline for a long time, industrial PLC programming is increas-ingly supported by formal methods. There are several reasons for the application of formal methods in the domain of PLC programming:

• The increasing complexity of the control problems, the demand for reduced development time, and the possible reuse of existing software modules result in the need for a formal approach in PLC programming.

2 Development of Logic Controllers

6

• The demand for high quality solutions and especially the application of PLCs in safety-critical processes necessitates verification and validation procedures, i.e. formal methods to prove spe-cific static and dynamic properties of the programs, as for example liveness, unambiguity or re-

sponse times of a controller prior to its implementation on a PLC.

In Figure 2-2 a very coarse generic model of the logic controller development process is given [Frey and Litz 1998]. Without the use of formal methods, the controller development process only con-

sists of the outer ring: The realization of the controller is derived from the informal specification by direct implementation and afterwards it is informally validated against the informal specification. In

the following, we will discuss the different elements and steps of this process in detail.

informal Specifi- cation

formal Specifi- cation

Reali- zation

Forma- lization

Implem-entation

Validation

Direct Implementation

Figure 2-2: Development process for logic control systems.


In almost all cases, the developer of a logic control system starts with a given informal specification of the control problem. The term „informal“ refers to everything that is not based on a strictly com-posed, syntactically and semantically well-defined form. In addition to an „easy to understand“ ver-bal description, this includes for instance timing diagrams, sketches, P&ID (piping and instrumenta-tion diagram) according to ISA S5.1 [ISA S5.1, Murrill 2000] or the combination of a set of equa-tions describing the behavior of the uncontrolled plant with a set of verbal requirements for the con-

trolled process. In general, the informal specification consists of a description of the uncontrolled process and requirements for the controlled system. Explicit requirements for the control algorithm

are also possible. However, the different parts of the specification are not always clearly separated. The main problem with informal specifications is that they do not facilitate tests for completeness,

unambiguity, and consistency.

Direct Implementation and Realization

The industrial standard approach to get the realization from the informal specification is the direct

implementation of the controller using a PLC programming language. Of course, the realization in-cludes hard- and software. However, with standard hardware and well-defined PLC functionality,

the realization consists of the programmed control algorithm, i.e. the software.


7

Informal Validation

The informal method of validation is the test of the implemented controller against the informal specification. Testing methods can be subdivided into white box testing and black box testing.

White box testing is a method based on the internal structure of the program or algorithm under in-vestigation. Black box testing, in contrary, does not look inside the system (it sees it as a black box)

but uses only the external interface.

Inspections and Walkthroughs are manual white box testing methods that involve teams of people reading the code of an algorithm. The difference between code inspections and walkthroughs is that

in code inspection the code is read and discussed by the team line by line, whereas in walkthroughs the team simulates the behavior of the algorithm following previously defined test cases. There are

several coverage criteria that make white box testing a more rigorous approach and tools that auto-matically generate test cases based on these criteria. Some of these tools can also perform the tests automatically.

In black box testing the algorithm is executed, inputs are provided according to previously defined test cases and the reaction of the system (output or performance) is checked against the expected

behavior. In control design the term simulation is often used for black box testing. As with white box testing, black box testing can be made more rigorous by generating the test cases in a formal way according to some coverage criteria. One way to do so is to model the possible execution paths as an automaton and then generate test cases that cover all edges of the automatons state space graph.

The problem with informal validation is that it is never complete and it takes quite a lot of time and person-power. For more information on testing see [Peled 2001, Chapter 9].

In recent years, the PLC community realized the need for formal methods in programming and vali-dation. A lot of interdisciplinary work has been done with the aim of applying formal methods. There are formal programming methods from Software Engineering as well as formal verification methods originally developed for the design of VLSI1 and communication protocols. Including formal methods, the middle path in Figure 2-2 is added to the design process.

Formalization and Implementation

The formalization is the conversion of an informal into a formal specification. This conversion can be done with the aid of computers but not automatically. It is a human core capability, since it in-

volves informal information.

Deriving the realization from the formal specification is called implementation. This process de-pends on the special target-system. The ideal is automatic code generation by the design tool.

The different parts of the formal specification and the new formal methods based on it are discussed in the following Sub-Section.

1 VLSI, Very Large Scale Integration, the current level of computer microchip miniaturization, refers to microchips containing in the hundreds of thousands of transistors.


8

2.2.2 Application of Formal Methods

Figure 2-3 shows a more detailed view of the formal specification and the possible applications of new formal methods in logic controller development based on it.

informal Specifi- cation

formal Specification of the control

algorithm

Realization

Implementation

Validation (non-model-based)

Direct Implementation

Formalization of specific Properties

Direct formal modeling

of the Control Algorithm (Synthesis)

Formal Modeling of the

uncontrolled Process

Reinterpretation

formal description of standard properties

formal description of

specific properties

formal model of the

uncontrolledprocess

Automatic Synthesis

Verification (Non-model-based)

Composition

formal model of the

controlled process

model-based Verification

model-based Validation

Validation

Formalization

Verification

Formal Specification

Figure 2-3: Formal Specification and the methods based on it [Frey and Litz 2000 (c)].

Formalization

The formalization consists of three different tasks:

• Formalization of problem specific properties, resulting in a set of properties to be fulfilled by the controller or the controlled process. These control objectives are formalized using temporal

logic [Thistle and Wonham 1986], algebraic conditions [Gunnarson 1996], or automata [Dierks 1997].

• Formal modeling of the uncontrolled process, resulting in a process model that is needed in model-based approaches. This model may be discrete or hybrid, depending on the properties to check.

• Formal modeling of the control algorithm, resulting in a formal description of the control al-gorithm. This step is often called design. Here the developer has to specify the data structures of

the controller and the algorithms that work on the data. The big difference to direct implementa-tion is that this is not done with a programming language but with some kind of formal descrip-tion.


9

As Figure 2-3 shows, depending on the formal methods applied, not all of these tasks have to be done. Furthermore, there are specification methods that combine several parts of the formalization in one step, resulting in a combined model. For instance, the Process Interpreted Petri Net (PIPN) presented in [Jörns 1996] contains the model of the plant and the properties to be fulfilled.

Reinterpretation

Sometimes the formal description of the control algorithm is build via a reinterpretation procedure

from the already implemented PLC code (also called translation, e.g. in [Lampérière-Couffin et al. 1999]). There are two reasons for the reinterpretation of an existing PLC program into a formal de-

scription:

• Most PLC programmers have no formal background and hence, they stay with their program-ming techniques.

• There are millions of already existing PLC programs, which cannot be formally treated in any other way.

Several approaches for the reinterpretation of PLC programs written in IEC 61131-3 Languages (IL = Instruction List, SFC = Sequential Function Chart, LD = Ladder Diagram, FBD = Function Block Diagram, ST = Structured Text) are published. A recent overview of different approaches to trans-

late LD into various kinds of Petri Nets can be found in [Peng and Zhou 2001]. In the following some examples of other approaches are listed:

• [Mertke and Menzel 2000] translate IL into Petri Nets.

• [Canet et al. 2000] use a transition system to reinterpret IL.

• [Hassapis et al. 1998] translate SFC into hybrid automata.

• [Rausch and Krogh 1998] translate LD into a modular transition system.

• [Kowalewski and Preußig 1996] reinterpret SFC with Condition/Event-Systems.

• N. Völker developed a method to represent ST, SFC and FBD by higher order logic, the latter two by representing them in ST first [Völker 1998, Völker and Krämer 1999, Völker 2000].

• [Jiménez-Fraustro and Rutten 1999] use the synchronous language SIGNAL to reinterpret ST.

Automatic Synthesis

The automatic synthesis of the control algorithm uses the formal description of the process and the formal properties, to generate the formal model of the control algorithm. Methods for automatic controller synthesis based on Petri Nets are described e.g. in [Holloway and Krogh 1990]. [Rausch et al. 1996] and [Hanisch et al. 1998] use Condition/Event systems whereas [Moor et al. 1998, Klein and Raisch 1998] use automata. [Dierks 1999] developed a synthesis method based on Dura-tion Calculus. For formal approaches to synthesis, see also the works of Ramadge [Ramadge and Wonham 1989] and Li [Li and Wonham 1993] both with Wonham. The problem with automatic synthesis is that it demands for a detailed formal model of the process to be controlled and a com-plete specification of the properties to be fulfilled.


10

Implementation

The implementation of the formal description of the control algorithm using one of the standardized PLC languages is done directly (using a compiler) or indirectly (using an interpreter implemented

on the PLC). The advantage of interpreter-based approaches is that the control algorithm has not to be translated. However, there is a main drawback, the user of the implemented controller often is

ignorant of formal methods and therefore he wants to see and sometimes even change the algorithm in one of the standard PLC languages he knows. In the following papers direct implementation methods are described:

• Methods for the direct implementation of Signal Interpreted Petri Nets are proposed in [Frey 2000 (c)] using SFC and in [Frey 2000 (a)] using IL, this approach is presented in detail in Chapter 7.

• The implementation of Grafcet using SFC is discussed in [Roussel et al. 1999].

• In [Dierks 1997] a method for the direct implementation of automata using ST is described.

• Different approaches for the implementation of special types of Petri Nets in LD are presented

in [Cutts and Rattigan 1992, Stanton et al. 1996, Uzam 1998, Uzam and Jones 1998]. See also [Twiss and Zhou 1998] and [Peng and Zhou 2001] for surveys on approaches using LD and

Petri Nets.

2.2.3 Verification and Validation

Verification and Validation (V&V) are the main areas of formal methods application in PLC pro-gramming. Nevertheless, they are often confused. They answer, in fact, different questions. The dif-ference is summarized by Boehm [Boehm 1979] as follows:

• Verification: „Am I building the product right?“

• Validation: „Am I building the right product?“

Based on a definition of [Patankar and Adiga 1995], [Roussel and Lesage 1996] point out:

• The verification is the proof that the internal semantics of a model is correct, independently from the modeled system. The searched properties of the models are stability, deadlock existence...

• The validation determines if the model agrees with the designer’s purpose.

Verification and Validation use the same formal methods but the properties investigated in verifica-tion are standard and hence, can be assumed as already formalized. Therefore, verification can be fully automated. In validation, specific properties of the controller have to be formalized. To do so, the investigation of the informal specification is necessary. Hence, validation cannot be fully formal

and not be fully automated. It remains a human core capability and one of the most challenging en-gineering tasks in logic controller development.


11

A classification scheme for formal V&V using the three categories Approach, Formalism, and Method is introduced in [Frey and Litz 2000 (c)]. The three categories are explained in the follow-ing and some examples are given.

Approach

The general approach to V&V can be model-based, constraint-based or non-model-based depending on the amount of information on the plant under control that is used in the process:

M Model-based: In model-based approaches a model of the process under control is included in the analysis. The properties checked are statements on the controlled system.

N Non-model-based: Non-model-based approaches analyze the formal description of the control algorithm without taking the process into account. Connections of the controller to its envi-ronment are treated either as if they were not present or as if anything could happen. The properties checked are statements on the controller.

C Constraint-based: Constraint-based approaches are typically non-model-based with the inclu-sion of some very restricted knowledge about the process, for instance that two binary input signals are always disjoint.

Formalism

Since formal V&V cannot be performed directly on the code of a controller, a formal description of the algorithm has to be generated first. The following formalisms are (among others) used for the

formal description of PLC programs:

P Petri Nets: For an introduction on different Petri Net models see [David and Alla 1992].

G Grafcet: Grafcet is a formalism based on Petri Nets that is widely used in France and interna-

tionally standardized as a specification language for sequential controllers [IEC 60848, David and Alla 1992, David 1995]

C Condition/Event-Systems (C/E-Systems): C/E-Systems are introduced in [Sreenivas and Krogh 1991]. With C/E-Systems, controllers can be specified textually in different modules communicating over condition and event signals.

A Automata: Especially hybrid automata are used in V&V of logic controllers, see [Henzinger 1996] for an introduction to this formalism.

L (Higher Order) Logic: For an introduction to Higher Order Logic see [Gordon and Melham 1993].

S Synchronous Languages: the synchronous approach is presented in [Halbwachs 1993, Benveniste and Berry 1991]. A synchronous language used in control applications is „Signal“

[Benveniste and Le Guernic 1990].

T (General) Transition Systems: See [Ostroff 1986] and [Canet et al. 2000] for examples.

E (Algebraic) Equations: [Gunnarson 1996] presents an approach using algebraic equations over finite fields. (Max,+) algebra [Baccelli et al. 1992] approaches also fall into this category.


12

Method

The choice of the method to be used to check the properties of the system under investigation de-pends in part on the formalism used to describe the model. However, often translations between dif-

ferent formalisms are available. Therefore, in most cases one of the following three V&V methods or a combination thereof can be used:

R Reachability Analysis: Methods based on reachability analysis build the complete state-space

of the modeled system and check properties by investigating the structure and/or the compo-nents of this state-space. Examples for reachability based analysis of Petri Nets are given in

Section 3.3. A problem with reachability analysis is the state-explosion in discrete systems: The number of possible states in the system grows exponentially with the number of discrete

variables.

M (Symbolic) Model checking: In model checking specifications of the behavior of a system are checked automatically on the state-space of the system. In contrary to reachability analysis, in

symbolic model checking the state space of the system is not built explicitly. The specifications are formulated using temporal logic (TL). See [Clarke et al. 1999, Chapter 3] for an introduc-

tion to TL and [Henzinger 1998] for an overview on timed TL. The model is formalized using for example automata or Petri Nets. Model checking does not avoid the problem of state-explosion. A recent overview on model checking techniques and tools is [Berard et al. 2001], other introductions can be found in [McMillan 1993] and [Clarke et al. 1999].

T Theorem Proving: In theorem proving methods the system and its expected properties are formalized using some mathematical logic. Then the property formulas have to be proofed from the axioms of the system description using some interference rules. Therefore, the name deductive V&V is also used frequently for theorem proving approaches. A Theorem Prover as-sists the user in formulating the proof. The necessity of a highly qualified user can be partly avoided by intelligent approaches using machine reasoning. A great advantage of theorem proving is the avoidance of the state-explosion problem [Peled 2001, Chapter 7].

Examples

In the following, some examples of verification and validation approaches are listed. For further ap-

proaches including V&V for Grafcet see [Lampérière-Couffin et al. 1999]. A three-letter-code A-F-M indicating the used Approach, the Formalism to build the formal specification, and the Method

for analysis according to the lists discussed above is assigned to the presented examples1.

N-G-M: [Lampérière-Couffin and Lesage 2000] use Grafcet for the specification of a controller and perform non-model-based V&V by symbolic model checking.

N-P-M: [Weng and Litz 2000] present a non-model-based V&V approach using model checking as method and Petri Nets as formal description. This approach is illustrated at a benchmark example in Section 8.3.

1 The author maintains a web-site where a web-form can be used to submit further examples [V&V Web Form].


13

M-P-R: [Frey and Litz 1998] use a special Petri Net as process model and another one as model of the controller. V&V is done using reachability analysis of the combined model.

M-P-M: [Mertke and Menzel 2000] present a model-based verification and validation approach.

Their process model is build as Petri Net and the PLC code is translated into another Petri Net. The aggregation of both nets is used as the basis for model checking. They also propose the specifica-

tion of properties in semi-formal natural language with an automatic generation of the formal de-scription. This approach is illustrated in Section 8.4.

M-A-M: [Hassapis et al. 1998] translate an SFC into a hybrid automaton. The process under control

is also modeled with a hybrid automaton. With the aggregated model of the controlled process, model checking is performed using CTL (Computational Tree Logic, a form of Temporal Logic).

M-C-R: [Kowalewski and Preußig 1996] translate SFC programs into C/E-Systems. Another C/E-

System is used to model the uncontrolled plant. The composition of these C/E_Systems results in a model of the controlled plant. Reachability analysis shows if the specifications (formalized in terms

of forbidden states) are fulfilled.

N-T-M: The Carnegie Mellon research group around G. J. Powers developed a method for V&V of given LD programs [Moon et al. 1992, Moon 1994, Probst 1996]. The LD is reinterpreted using a

transition system and the properties to check are formalized using CTL. The model-checker Sym-bolic Model Verifier (SMV) [CMU SMV] takes the model and the properties, implicitly builds the

state-automaton of the system, and checks whether the properties hold. If this is not the case, a state-sequence leading to the contradiction is produced.

N/C-T-M: [Canet et al. 2000] present an approach for the verification and validation of existing PLC programs written in Instruction List. The PLC code is translated into a transition system. For this system specific properties are investigated using model checking with LTL (Linear Temporal Logic, another form of Temporal Logic). The example presented in [Canet et al. 2000] shows that with the inclusion of additional process knowledge (constraints) the results are of more practical value.

N-L-T: [Völker and Krämer 1999] use higher order logic to represent ST programs. The require-ments are specified in LTL. The model and the requirements are used in a theorem prover.

M-C/P-R/M: Hanisch et al. [Hanisch et al. 1998, Hanisch et al. 1999] propose a model that com-bines C/E-Systems with Petri Nets, the Net Condition/Event System (NCES). NCES is a block-

based approach where the different blocks or modules communicate via condition and event signals as in C/E-Systems and the inner structure of the blocks, the algorithms, are described using a type

of Petri Net. This approach is model-based and the controller as well as the plant are modeled with NCES. For verification and validation, Reachability analysis and model checking are used. The ap-proach is illustrated at a parcel-turning machine in [Both et al. 2001]

2.2.4 Summary

This Section gives an overview of formal methods application in PLC design. In this sense, it is re-

stricted to present examples and can in no way be complete. The presented generic model of the


14

control design process and the definition of related terms allows the categorization of different ap-proaches in the fast growing area of research and application. A three-letter-code for verification and validation methods based on the describing triple approach-formalism-method is introduced and explained using some examples.

The current view on logic controller development in the area of Control Engineering can be summa-

rized in the following two points:

• To develop a logic controller, formal methods are needed that allow formal verification and validation. There is a variety of formalisms used to describe logic control algorithms and sev-eral methods are used for V&V.

• A controller described by some formalism has eventually to be translated into an implementa-tion language, nowadays mostly one of the languages defined in IEC 61131-3. Therefore, a de-

scription of a controller using some formalism as for example Petri Nets is not considered a controller but merely a formal description of the controller.

2.3 The Software Engineering Point of View

2.3.1 Software Quality in General

In general, the realization of a logic controller includes hard- and software of several layers. With

the assumption of standard hardware with well-defined functionality, the application is realized by the program of the control algorithm, i.e. software of the application layer. Therefore, it is worth-

while to study the viewpoint of Software Engineering in the controller development process. In the ANSI/IEEE 610 standard [ANSI/IEEE 610] Software Engineering is defined as

the application of a systematic, disciplined, quantifiable approach to the development, operation,

and maintenance of software; that is the application of engineering to software.

The word quantifiable in this definition indicates that measurement is an integral part of software

engineering. Measurement in this area is mainly directed at the determination of quality of the soft-ware and the processes involved in its life cycle.

The benefits of software measurement are summoned in [Rombach 1991]:

Software measurement is an essential component of mature software technology. It supports quality

as well as project management. As far as quality management is concerned, measurement can help

to investigate software related phenomena and thus contribute to building better software product,

process, and quality models. As far as project management is concerned, measurement can help

state software requirements unambiguously, assess their proper implementation throughout the

software project and achieve convincing product certification.

Mostly, the software for logic controllers is not developed by the user, but by another company. Therefore, both of the above points are of interest in this area. The developer of the control algo-

rithms requires tools to improve the quality of his product and ways to document this quality. The


15

user or contractor of the software needs tools to check the quality of the product and its accordance to the specification.

Quality is defined in ISO 8402 standard [ISO 8402] as:

The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs.

According to ANSI/IEEE 610 standard [ANSI/IEEE 610] software for process control is application software. For application software, the ISO/IEC 9126 standard [ISO 9126] defines software quality characteristics as:

A set of attributes of a software product by which its quality is described and evaluated. A software

quality characteristic may be refined into multiple levels of sub-characteristics.

Figure 2-4 shows the software quality model according to ISO/IEC 9126. The standard defines six

quality characteristics, each associated with a number of sub-characteristics. The definitions of these characteristics are summoned in Table 2-1.

Efficiency

Usability

Portability

ISO 9126

Reliability

Maintainability

Functionality

Adaptability Installability Conformance Replaceability

Analyzability Changeability

Stability Testability

Understandability Learnability Operability

Suitability Accurateness

Interoperability Compliance

Security

Maturity Fault Tolerance Recoverability

Time Behavior Resource Behavior

Figure 2-4: Software quality model of ISO 9126 with quality characteristics and sub- characteristics.

Software Quality is a field of mayor interest for researchers and practitioners today. However, in the

area of Control Engineering it is rarely studied. The field of metrics to measure software character-istics is maturing, see [Höcker et al. 1994, Jalote 1997, Zuse 1998] for overviews. Some of the best-


16

known metrics date back to the late seventies [Halstead 1977, McCabe 1976]. However, experi-ences with those metrics in the area of controller programming are not published.

Criterion Definition

Functionality Attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy a stated or implied need.

Reliability Set of attributes, that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.

Usability Attributes that bear on the effort needed for use, and on the individual evalua-tion of such use, by a stated or implied set of users.

Efficiency Attributes that bear on the relationship between the level of the performance of the software and the amount of resources used, under stated conditions

Portability Attributes that bear on the ability of software to be transformed from one envi-ronment to another.

Maintainability Attributes that bear on the effort needed to make specified modifications

Table 2-1: Software Characteristics of ISO/IEC 9126.

2.3.2 Software Quality in Logic Controller Development

A closer look at Table 2-1 reveals that besides the fact that the term is rarely used, quality concepts are already an integral part of logic controller development.

To prove the functionality of a controller is the main aim of formal verification and validation methods presented in Sub-Section 2.2.3.

Verification and validation can also be used to check the reliability of a controller. Especially non-model-based V&V shows the controller’s reaction to unexpected behavior in its environment.

The user of a controller in most cases does not directly interact with the algorithm, but with a spe-cially designed human machine interface (HMI). In controller development the control algorithm it-self and the HMI are generally developed independently and often even run on different machines. For example, in industrial automation systems, a PLC is used to control the plant and the user inter-face resides on a PC that is connected to that PLC via some network. For the usability of a control-ler, the design of the HMI is the most important aspect. HMI design is a distinct field of research

and is not discussed here.

The efficiency of a controller is determined by its implementation. The importance of efficient im-plemented code in the sense of resource and time requirements depends on the application. For a controller developed for a unique implementation, as for example the control of a chemical reactor, efficiency is of minor interest. However, for controllers with multiple implementations, especially

embedded controllers in consumer products, efficiency may become the most important aspect.


17

Portability of a controller depends mainly on the formalism used to design it. If a proprietary pro-gramming language of a special PLC manufacturer is used, portability cannot be achieved. For the programming languages defined in IEC 61131-3 the PLCopen tries to describe portability stan-dards, see [PLCopen]. Meanwhile, the best way to reach portability is to use a formal description language that can be implemented with different code generators on special hardware platforms.

Since portability also includes the changeability of the controller, it is important that the used for-malism is easy to understand and to interpret, i.e. that the formal description of the controller re-veals its functionality. The same holds for maintainability. The best way to reach an easy under-standing is to use a visual programming language, which allows the programmer to see the control and information flow in the algorithm [Scanlam 1989]. However, even with the best description method it is possible to describe algorithms that are not understandable or build programs that are hard to read. To describe this aspect of a control algorithm, the concept of transparency was intro-duced into Control Engineering.

Transparency of an algorithm is defined as follows [Litz 1995, Frey and Litz 1999]. For a controller to be transparent:

• At any time it must be easy and clear to see what the controller should do at the moment, what it

does at the moment and what it will do in the near future (in the next step).

• It must be possible to reinterpret the algorithm, i.e. the aim of the algorithm must be recognizable in the algorithm itself.

2.3.3 Summary

The discussion about software engineering shows that the quality concepts defined in ISO 9126 are directly applicable to logic control software. Various methods already in use in logic controller de-velopment can be seen as tools to improve software quality as the summary in Table 2-2 shows.

Characteristic Corresponding Methods in Control Engineering

Functionality Correctness of the control algorithm proved by verification and validation

Reliability Correctness and robustness of the control algorithm proved by verification and validation under minimal assumptions about the controller’s environment (i.e. inclusion of possible errors in the environment model)

Usability Design of the Human Machine Interface

Efficiency Efficient method of automatic implementation

Portability

Maintainability

• Properties of the programming language or formalism used in the design

• Methods of automatic implementation

• Evaluation of transparency

Table 2-2: Software Characteristics applied to Logic Controller Design.


18

In addition to the methods for verification, validation and implementation discussed in the area of Control Engineering (cf. Section 2.2), the evaluation of transparency using a suitable metric and the use of a graphical formalism are appropriate means to achieve software quality in the area of logic control.

2.4 The Combined Point of View

Under the assumption that the controller is implemented on a programmable hardware with well-defined functionality and that the transition from the formal description of the control algorithm to its implementation is done in a way that guarantees that the implementation behaves as specified (at best with automatic code generation), the two viewpoints can be combined. Because then, the be-havior of the implementation equals that described in the formal description. If this assumption holds, we can summon up the two ideas presented in the previous sections:

In logic controller development, we need a formal specification method with the following proper-ties:

• The formalism should provide all the means needed to fully describe a controller, i.e. it has all

the functionality of a PLC programming language.

• We need a graphical formalism that is formally defined and therefore can be used as formal de-

scription of a controller.

• The formalism should allow formal verification, validation, and evaluation.

• It should be possible to automatically compile the formal description into an implementation

language according to IEC 61131-3.

In the next chapter, Signal Interpreted Petri Nets (SIPN) are introduced as an answer to the demands in the list above. First, it may be seen as a new PLC programming language, showing some interest-

ing properties missing in the existing ones. Furthermore, SIPN are defined in a strictly mathematical way. Therefore, they provide a sound basis for the analysis of a variety of properties. In further

chapters, it will be shown that SIPN allow for the application of formal verification, and evaluation. Methods for the automatic generation of readable and fast code in Instruction List according to IEC

61131-3 from SIPN are introduced. The code generation transfers the dynamics and the I/O-behavior of the SIPN to the implemented code. Therefore, the above assumption is valid in this case. Finally, two methods for the formal validation of SIPN are presented, one of them based di-rectly on the SIPN and the other one based on the generated code.

19

3. Theory of Signal Interpreted Petri Nets (SIPN)

3.1 SIPN as a new PLC Programming Language

Today PLCs are the main workhorse of automation in all areas from single, even very small, ma-chines to discrete manufacturing plants (assembling) and continuous processes (especially chemical batch processes). The original idea that led to the development of the first Programmable Logic Controller (PLC) in 1968 was to replace hard-wired control equipment at machines. Back then, the controllers of machines, for example lathes or grinders, typically resembled a cabinet of intercon-nected relays. The size of such a controller could be considerable and its failure-rate was high due to mechanical defects of single relays. Furthermore, the initial setup was very time-consuming and error-prone, because the relays (often hundreds of them) had to be wired by hand. The biggest

drawback of this technology however was the problems arising if a controller had to be changed, employing a new function or adjusting to a new production task. Then the hard-wired structure had

at least partially to be disassembled and rewired. Here was the main advantage of a controller that could be adjusted by changing software instead of hardware.

Since the first PLCs in the early seventies reached the market, graphical programming methods are

used to develop the control algorithms. These are Ladder Diagram (LD) and later Function Block Diagram (FBD). The implementation of LD on the very first PLC (the Modicon 084) was intended

to allow an easy access for the people doing hard-wired relay-logic until then. (More on the history of PLCs can be found on the web-site of Dick Morley, commonly known as the father of the PLC

[PLC History].)

LD, at least in its early forms, is basically the graphical representation of its hard-wired forefather. The name ladder comes from the fact that on both sides of the drawing, there is a power rail and horizontally between those rails, like rungs on a ladder, sequences of logical element are drawn. The basic of these elements are relays (switches), depending on input-signals or internal variables, and coils (memories to store variables and set output signals). The ladder is processed in a top-down and left-right fashion. To understand the dynamic behavior of such an algorithm it has to be known that PLCs work in a cyclic manner. They read in the input signals, process the algorithm, set the output signals, and then start all over again. Figure 3-1 shows an example of an LD. Every rung can be read as an IF THEN ELSE statement. The first rung of the ladder means IF (Var1=1 AND Var2=1)

THEN (Var3:=1; Var4:=0) ELSE (Var3:=0; Var4:=1). The second rung is IF (Var3=1 OR Var4=0) THEN

(Var1:=1) ELSE (Var1:=0).

Var1 Var2

Var3

Var4

Var3 Var4

Var1

Figure 3-1: Example of a PLC-program written in Ladder Diagram (LD).

3 Theory of Signal Interpreted Petri Nets (SIPN)

20

While LD resembles relay-logic, FBD is a graphical mimicking of the wiring of simple logic gates, like AND, OR, NOT, or FLIP-FLOP. Both languages (LD as well as FBD) are still part of the IEC 61131-3 the current international standard for PLC programming languages. However, they are not well suited for the description of sequential and concurrent algorithms because they have no means for the visual description of the control-flow in a program.

The IEC 61131-3 standard also contains a language that is intended for the graphical description of sequential and concurrent behavior, the Sequential Function Chart (SFC). The SFC is based on Grafcet [David 1995] and represents a form of Petri Net (with very special dynamics and function-ality). Due to its high functionality, SFC can be easily applied for the structuring of a PLC program on a high level. However, it is cumbersome (and by the standard also not intended) to use for the specification of a low-level sequential algorithm, as for example the alternative switching between two motors. Furthermore, the inherent complexity of an SFC prohibits its use in the lower, func-tional levels of an algorithm because the resulting programs would be too slow.1

Hence, we conclude that in the PLC area a language is missing that

• is capable of graphically describing sequential and concurrent algorithms,

• gives visual feedback of the control-flow in these algorithm (current state, following state etc.),

• is easy to apply, and

• is easy to implement i.e. results in fast code.

With Signal Interpreted Petri Nets (SIPN), such a language is at hand. Before a formal definition is given, the SIPN is illustrated using the controller for a heating tank [Frey and Litz 1999]. Figure 3-2 shows the P&ID of a heating tank and tables of its input and output signals.

LIS+02

LIS+01

M

US 1

Heating Vapor

Product In

Product Out

US 1UV1.3

US 1

US 1UV1.1

US 1UV1.2

TIS+01

US 1

Valve 1

Valve 2

Valve 3

US 1

Figure 3-2: P&ID of a heating tank with tables of input and output signals.

1 There are also two textual languages in the standard: the assembler-like Instruction List (IL) and the Pascal-like Struc-tured Text (ST).

O ID Meaning of „One“ o1 UV 1.1 open Valve 1 o2 UV 1.2 open Valve 2 o3 M motor on (stirring) o4 UV 1.3 open Valve 3 (heating) o5 -- -- o6 -- --

I ID Meaning of „One“ i1 LIS+ 02 tank is NOT empty i2 LIS+ 01 tank is full i3 TIS+ 01 temperature is above limit i4 -- start button is pressed i5 -- -- i6 -- --

3.1 SIPN as a new PLC Programming Language

21

The informal specification to be fulfilled by the heating tank controller is as follows:

After pressing the start button (i4 = 1) the empty tank (i1 = 0) is filled by opening Valve1 (o1 = 1).

The filled tank (i2 = 1) is heated (o4 = 1) until the temperature sensor signals that the temperature

limit is reached (i3 = 1). The heated tank is emptied below the minimal level (i1 = 0) by opening

Valve2 (o2 = 1). During the whole process the contents are stirred (o3 = 1).

With SIPN, places (circles) are used to describe a controllers state. Those places can be marked (in-

dicated by a token in the place) or non-marked. While a place is marked, it can influence its envi-ronment by setting an output function. The state of the controller is given at any time by the set of

marked places. The dynamic of the model is described by the flow of tokens through the net. To de-scribe this flow, transitions (bars) that are connected to the places via directed arcs are used. The fir-

ing of a transition removes the tokens from its input places and puts tokens in its output places. The firing of transitions depends on the input signals.

The algorithm in Figure 3-3 works as follows: In the initial state only p1 is marked, indicated by a

token in p1 and hence the output of the net is (o1, o2, o3, o4) = (0, 0, 0, 0). Transition t1 fires when the start button is pressed (i4 = 1) and the tank is empty (i1 = 0 and i2 = 0). The token from p1 is re-

moved and in p2 and p5 tokens are generated. The new output of the net results in (1, 0, 1, 0), where o3 = 1 means stirring and o1 = 1 filling. After the filling level is reached (i2 = 1), the further process-ing depends on the temperature in the tank. If the temperature is already above the desired level (i3 = 1) then t5 fires, removing the token from p2 and putting a token in p4. If otherwise, the tempera-ture is below the level (i3 = 0) then t2 fires, also removing the token from p2 but putting it in p3. There, the tank is heated (o4 = 1) until the temperature is OK (i3 = 1) and t3 can fire moving the to-

ken from p3 to p4. In p4 the tank is emptied (o2 = 1). When the tank is empty and the start button is released, the firing of t4 removes the tokens from p4 and p5 and puts a token in p1, resulting in the

initial state again.

t1: Start Button pressedϕ(t1) = i4 ∧ ¬i1 ∧ ¬i2

p1: Stand Byω(p1) = (0, 0, 0, 0)

p2: Fillingω(p2) = (1, 0, -, 0)

p3: Heatingω(p3) = (0, 0, -, 1)

p5: Stirringω(p5): o3 = 1

p4: Emptyingω(p4) = (0, 1, -, 0)

t4: Tank is emptyϕ(t4) = ¬i1 ∧ ¬i2 ∧ ¬i4

t5: Filled & Temp. OKϕ(t5) = i2 ∧ i3

t2:Filled & Temp. lowϕ(t2) = i2 ∧ ¬i3


Figure 3-3: SIPN example (heating tank controller).


22

3.2 Definition and Meaning of SIPN

3.2.1 Basic Definitions and Notations

Before the formal definition of the SIPN is given, some definitions and notations from standard Petri Net (PN) theory are summarized. The starting point for Petri Net theory was the Ph.D. disser-tation of the contemporary German mathematician Carl Adam Petri in 1962 [Petri 1962].

The definitions and notations presented in this sub-section can be found in any elementary textbook

on Petri Nets [Reisig 1982, David and Alla 1992] and are given here only to the extend in which they are needed in the consecutive text.

The most elementary Petri Net definition can be given for the ordinary Petri Net.

Definition 3-1: Ordinary Petri Net

An ordinary Petri Net is a triple PN = (P, T, F) with

P P = p1, …, p|P| a non-empty, finite set of places,

T T = t1, …, t|T| a non-empty, finite set of transitions with P ∩ T = ∅,

F F ⊆ P × T ∪ T × P a non-empty finite set of arcs connecting places to transitions or transi-

tions to places but never two places or two transitions (the F stands for flow-relation).

Note: Throughout this text all Petri Nets are ordinary and connected. Connected means that there

exists at least one path between any two nodes. A Petri Net that is not connected is a set of at least two connected Petri Nets. Ordinary means that the multiplicity of arcs is always one.

The ordinary Petri Net given in Definition 3-1 contains only structural elements. To define dynamic Petri Nets and their firing rules, we need some terminology to identify special sets of places and transitions and the concept of markings.

Definition 3-2: Pre- and Post-Sets

The pre-set •ti of a transition ti ∈ T contains all places that are connected to ti via a directed arc

from the place to the transition: •ti = p ∈ P: (p, ti) ∈ F. The elements of •ti are often called pre-places or input-places.

The post-set ti• of a transition ti ∈ T contains all places that are connected to ti via a directed arc

from the transition to the place: ti• = p ∈ P: (ti, p) ∈ F. The elements of ti• are often called

post-places or output-places.

The pre-set •pi and post-set pi• of a place pi ∈ P are defined in the same way:

•pi = t ∈ T: (t, pi) ∈ F,

pi• = t ∈ T: (pi, t) ∈ F.


23

Definition 3-3: Marking

A marking of a Petri Net is a mapping m: P → 0, 1, 2, …|P|, that assigns a finite non-negative

integer number of tokens to each place of the net. The marking is described by a vector m, which

has a dimension that equals the cardinality of the set of places P. A place pi ∈ P is called un-

marked under the marking m if the corresponding element of this vector, denoted by m(pi) is zero, otherwise it is called marked with m(pi) tokens. For a given marking ma the set of marked

places Pm is given by Pm(ma) = p ∈ P: ma(p) > 0.

The most basic way to add a marking to a Petri Net is to have places either marked or unmarked. With this binary marking and a set of rules for the dynamic behavior, we get the definition of a Condition/Event-Net (C/E-Net).

Definition 3-4: Condition/Event-Net (C/E-Net)

Structure

A Condition/Event-Net (C/E-Net) is a quadruple PN = (P, T, F, m0) with (P, T, F) an ordinary

Petri Net, and m0: P → 0, 1|P|, the binary initial marking of the net.

Dynamics

A transition t in a C/E-Net is enabled under a marking m, En(t, m) = True, if and only if all places in its pre-set are marked (with one token) and all places in its post-set are unmarked:

En(t, m) = True ⇔ (∀ p ∈ •t: m(p) = 1) ∧ (∀ p ∈ t•: m(p) = 0)

An enabled transition can fire. The firing removes the tokens from all places in the pre-set of the

transition and puts a token in all places in the post-set of the transition.

If more than one token is allowed in a place, a Place/Transition-Net (P/T-Net) results. Note that the firing rules for P/T-Nets are not the same as for C/E-Nets. In a P/T-Net the post-places of a transi-

tion are not checked in the test for enabling.

Definition 3-5: Place/Transition-Net (P/T-Net)

Structure

A Place/Transition-Net (P/T-Net) is a quadruple PN = (P, T, F, m0) with (P, T, F) an ordinary

Petri Net, and m0: P → 0, 1, 2, …|P|, the initial marking of the net.

Dynamics

A transition in a P/T-Net is enabled if all its pre-places are marked with at least one token:

En(t, m) = True ⇔ ∀ p ∈ •t: m(p) > 0.

An enabled transition can fire. The firing of a transition removes one token from all of its pre-

places and adds one token in all of its post-places.

If the firing of an enabled transition t under a marking m in a PN generates a new marking m’, then it is said that m’ is directly reachable from m. If under m’ a transition t’ fires resulting in m’’ then


24

m’’ is said to be reachable from m via the firing sequence <t, t’>. In general, a marking m2 is said to be reachable from a marking m1 if there exists a firing sequence starting from m1 that has m2 as final marking.

Definition 3-6: Reachability Set RS and Reachability Graph RG

The reachability set RS of a Petri Net PN = (P, T, F, m0) is the set of markings consisting of m0

and all markings reachable from m0. The reachability graph RG is a graph RG = (RS, E ⊆ RS ×

RS) with the reachable markings as vertices. An edge e ∈ E with e = (mi, mk) indicates that the

marking mk is directly reachable from mi. The vertices of the graph are labeled with the corre-

sponding marking m and the edges are labeled with the corresponding transitions.

The only difference in the definition between a Condition/Event-Net and a Place/Transition-Net with binary initial marking is their enabling rule. However, the enabling rule has severe conse-quences on the behavior of the net as the following example shows. Therefore, names for these ena-bling rules have been introduced. The enabling rule used in C/E-Nets is called the strong enabling rule whereas the one used in P/T-Nets is called weak enabling rule. This is because all transitions enabled under the strong enabling rule are also enabled under the weak enabling rule but not vice versa.

Figure 3-4 shows a PN with binary initial marking m0 = (0, 1, 1). If the PN is seen as a P/T-Net, the reachability graph in the middle of the figure is derived. Whereas for the same net seen as C/E-Net, the reachability graph on the right of the figure results. The reachability graph of the C/E-Net is contained in the one of the P/T-Net; it can be shown that this is always the case.

p1

m3=(2, 0, 0)

m0=(0, 1, 1)

m1=(1, 0, 1) m2=(1, 1, 0)m4=(0, 0, 2) m5=(0, 2, 0)

m0=(0, 1, 1)

m1=(1, 0, 1) m2=(1, 1, 0)

p2 p3

t2 t4

t1 t3

t2 t4t1 t3

t2t4

t1t3

t2t4 t1t3

t2 t4t1 t3

Figure 3-4: PN with binary initial marking and its reachability graph as P/T-Net and as C/E-Net.

3.2.2 SIPN Definition

The Petri Nets defined so far are autonomous, i.e. they do not interact with their environment. In SIPN binary output signals are manipulated. An output signal o in an SIPN can have the values zero

or one or may be left undefined o ∈ 0, 1, -. During the work with these signals the following

points are of interest:

1. A signal may be influenced by several places of the SIPN at the same time and we are interested in the resulting effect, i.e. the product or the conjunction of these influences.


25

2. We are interested in summarizing the influence of an SIPN on a signal at different times. This leads to the sum or disjunction of the single influences.

To do these calculations a product operation and a sum operation over the set 0, 1, - have to be

defined.

We start by defining the product. To do so, we assume that two places are influencing an output signal at the same time. The product of the two values specified by those two places, gives the re-

sulting value assigned to the output signal. For this result the symbols according to Table 3-1 are used.

Symbol Meaning at one state (one time)

0 The signal is set to zero.

1 The signal is set to one.

- The signal is left undefined.

c The signal is specified contradictory (at least one place sets it to one while at least one other place set it to zero).

Table 3-1: Meaning of the symbols assigned to output signals in a single state.

With this meaning of the output symbols we get the multiplication table shown in Table 3-2.

a⋅b 0 1 - c

0 0 c 0 c

1 c 1 1 c

- 0 1 - c

c c c c c

Table 3-2: Product of output signals over the set 0, 1, -, c.

The sum of output signals is used to summarize different setting of those signals over time. For ex-

ample to answer questions like „Is an output signal set to one for all states of the system under con-sideration“. To specify the sum we first have to define the possible values of the result and the cor-

responding meaning. This is done in Table 3-3.


26

Symbol Meaning at several state (several times)

0 The signal is set to 0 in all considered states.

1 The signal is set to 1 in all considered states.

- The value of the signal is specified in none of the considered states (i.e. set to - in all of the considered states).

c The signal is a contradiction (assigned different values at the same time) at least in one of the considered states but it is undefined (-) in none of the considered states.

c- The signal is undefined at least in one of the considered states and contradictory at least in one of the considered states.

d The value of the signal is always defined either 0 or 1 (0 at least in one of the consid-ered states and 1 at least in one of the considered states).

d- The value of the signal is undefined (-) in at least one of the considered states but is

contradictory in none of the considered states.

Table 3-3: Meaning of the values of output signals in an SIPN summoned over several states.

Using these symbols we can define the sum according to Table 3-4.

a+b 0 1 - c c- d d-

0 0 d d- c c- d d-

1 d 1 d- c c- d d-

- d- d- - c- c- d- d-

c c c c- c c- c c-

c- c- c- c- c- c- c- c-

d d d d- c c- d d-

d- d- d- d- c- c- u d-

Table 3-4: Sum of output signals over the set 0, 1, -, c, c-, d, d-.

The question is whether the multiplication has to be extended by the additional symbols introduced as results for the sum. This is in fact the case for the application of the defined algebra in hierarchi-cal SIPN (cf. Section 3.4). There, for the purpose of analysis, a subnet may be abstracted as a single place with an output-function that describes all possible outputs of the subnet. Hence, this output-function can contain values like for example c- or d. The calculation of the resulting outputs of states where such an abstracted place is marked necessitates the extension of the product.


27

In doing this extension another problem arises: There are combinations of signals that can no longer

be assigned one of the existing symbols. One example for this is the question what the result of d⋅d

should be. The symbol d in the output function of a place means that this state is an abstraction of a set of states and in all those states the value of the output is defined (either 0 or 1). If two such

places are marked at the same time, we know that we have two sets of partial states, in each of which the output is defined. However we cannot know if the resulting combination is a defined or a

contradictory value. Therefore, an additional symbol x is introduced and the product and sum are extended to include this symbol (cf. Definition 3-7). Table 3-5 summons the eight symbols used in the signal algebra.

Symbol Meaning at one state (one time) Meaning for several states (several times)

0 The signal is set to zero. The signal is set to 0 in all considered states.

1 The signal is set to one. The signal is set to 1 in all considered states.

- The signal is left undefined. The value of the signal is specified in none of the considered states (i.e. set to - in all of the considered states).

c The signal is specified contradic-

tory (at least one place sets it to one while at least one other place

set it to zero).

The signal is a contradiction (assigned different val-

ues at the same time) at least in one of the considered states but it is undefined (-) in none of the considered

states.

c- The signal is undefined at least in one of the consid-ered states and contradictory at least in one of the considered states.

d The value of the signal is always defined either 0 or 1 (0 at least in one of the considered states and 1 at least in one of the considered states).

d- The value of the signal is undefined (-) in at least one of the considered states but is contradictory in none

of the considered states.

x The value of the signal is unknown in at least one of the considered states. It may be contradictory or un-defined but it may also be 1 or 0.

Table 3-5: Meaning of the symbols used in the signal algebra.


28

Definition 3-7: Signal-Algebra

The Signal-Algebra (0, 1, -, c, c-, d, d-, x, ⋅, +) is defined over the set 0, 1, -, c, c-, d, d-, x

with product and sum operators according to Table 3-6 and Table 3-7. The product as well as the sum is defined component-wise for vectorial operands:

(a1, …, an) ⋅ (b1, …, bn) = (a1 ⋅ b1, …, an ⋅ bn); (a1, …, an) + (b1, …, bn) = (a1+ b1, …, an+ bn)

a⋅b 0 1 - c c- d d- x a+b 0 1 - c c- d d- x

0 0 c 0 c c c x x 0 0 d d- c c- d d- x

1 c 1 1 c c c x x 1 d 1 d- c c- d d- x

- 0 1 - c c- d d- x - d- d- - c- c- d- d- x

c c c c c c c c c c c c c- c c- c c- x

c- c c c- c x c x x c- c- c- c- c- c- c- c- c-

d c c d c c x x x d d d d- c c- d d- x

d- x x d- c x x x x d- d- d- d- c- c- u d- x

x x x x c x x x x x x x x x c- x x x

Table 3-6: Complete multiplication table for output signals.

Table 3-7: Complete summation table for output signals.

With the definition of the signal algebra, the SIPN can be defined. The definition of SIPN is a direct extension to binary marked PN. This binary marked PN which is called the SIPNs underlying Petri Net and denoted by PN(SIPN) may be seen as C/E-Net or as binary marked P/T-Net, depending on

the questions to be answered.


29

Definition 3-8: Signal Interpreted Petri Net SIPN and underlying Petri Net PN(SIPN)

Structure

A Signal Interpreted Petri Net is described by a 9-tuple SIPN = (P, T, F, m0, I, O, 3 & ZLWK

(P, T, F, m0) an ordinary, binary marked PN, also called the underlying Petri Net PN(SIPN),

I I = i1, …, i|I| a non-empty, finite set of logical input signals,

O O = o1, …, o|O| a non-empty, finite set of logical output signals with I ∩ O = ∅,

3 a mapping associating every transition ti ∈ T ZLWK D ILULQJ FRQGLWLRQ 3ti) = f(i1, …, i|I|), the

firing condition is a Boolean function in I, f: 0, 1|I| → 0, ` ZLWK 3ti) not constant False,

& a mapping associating every place pi ∈ P ZLWK DQ RXWSXW &pi) ∈ 0, 1, -, c, c-, d, d-, x|O| 1RWH 7KH GHILQLWLRQ RI & JLYHQ KHUH LV WKH PRVW JHQHUDO RQH $V ORQJ DV WKHUH DUH QR KLHUDr-

FKLFDO VWUXFWXUHV &pi) ∈ 1, 0, - |O| is sufficient for the assignment of outputs.),

Ω the output function Ω FRPELQLQJ WKH RXWSXW & RI DOO PDUNHG SODFHV ^ 1|P| → 1, 0, -, c,

c-, d, d-, x|O|. To calculate Ω(ma) for a given marking ma the product according to

Definition 3-7 over the outputs of all marked places p ∈ Pm(ma LV EXLOW ma) = ∏∈ )(

)(&amPp

pm

.

Dynamics

1. A transition t is enabled under a marking m, if and only if its pre-places are marked and its

post-places are unmarked: En(t, m) = True ⇔ (∀ p ∈ •t: m(p) = 1) ∧ (∀ p∈ t•: m(p) = 0).

2. A transition t fires immediately, if and only if it is enabled (En(t, m) = True) and its firing

FRQGLWLRQ LV IXOILOOHG 3t) = True). The firing removes the tokens from all places in the pre-set of the transition and puts a token in all places in the post-set of the transition.

3. All transitions that can fire and are not in conflict with other transitions fire simultaneously (two transitions are in conflict if the firing of one of them disables the other).

4. The firing process is iterated until a stable marking is reached (i.e. until no transition can fire anymore). Since firing of a transition is supposed to take no time, iterated firing is inter-preted as simultaneous. This also means that a change of input signal values cannot occur (and hence is not considered) during the firing process.

5. After a new stable marking is reached, thH RXWSXW VLJQDOV DUH UHFDOFXODWHG E\ DSSO\LQJ WR

the marking.

3.2.3 Graphical Representation

As with PN, places of SIPN are represented by circles, transitions by bars, the flow relation by arcs,

and the tokens by dots in the circle of the corresponding place. In addition, the transitions of SIPN are labeled with their firing condition and the places are labeled with their output. Given larger

numbers of output signals it is convenient to represent the output not in the vectorial form but by


30

explicitly specifying the influence on variables instead, if for example O = o1, ..., o100 then &pi): o1 = 1; o3 = LV EHWWHU WKDQ &pi) = (1, -, 0, -, ..., -). Figure 3-3 shows an example of an SIPN where both representations are used. Places and Transitions may be labeled with an additional comment.

3.2.4 Logic Control Semantics

The demands in SIPN analysis and the design of SIPN controllers get more intuitive if the seman-

tics of the model is clear. Hence, in the following places and transitions get a meaning:

Places in an SIPN mean situations. A situation is a partial state of the controller. A situation can be active or non-active, indicated by the marking. While it is active, it can influence the controller’s

environment, i.e. setting actuator signals in the process or input signals in other control algorithms, via the corresponding output. The state of an SIPN is given by the marking, i.e. the combination of

active situations. The output and hence the influence of an SIPN on its environment at a certain time —that is at a certain state of the SIPN—is given by the product of the outputs of all marked places. The influence of an SIPN on an output at different times—that is at different states—is given by the sum of the outputs of those states.

Transitions specify under what circumstances a situation ends and a new situation gets active. The

firing condition of the transition specifies when the change of situations is allowed to happen.

With this semantics, it is clear that the firing of transitions can take no time. If the switch from one

set of situations to another would take time, then there would be an intermediate situation. Further-more, the correspondence of places to situations that can be active or not, leaves a binary marking as single meaningful marking concept for SIPN.

3.2.5 Principles of SIPN

With the semantics given in the previous Sub-Section and the definition of SIPN in mind, we can

formulate four principles of SIPN that may be used to distinguish them from other formalisms: Lo-cality, Marking-State-Equality, State-Output-Mapping, and Feedback-Freeness.

Locality

In SIPN the principle of locality from Petri Net theory holds. This principle means that local changes in the marking of the net have only local influence on the future behavior of the net. This means that the change of marking of a place can only influence the transitions directly connected to this place. In SIPN, all causal dependencies are made visible by arcs. The change of the marking in a place can only influence the enabling of transitions that are directly connected to that place. The

marking of a place cannot be used in form of a variable in the firing condition of a transition that is not connected to that place. This principle brings some profound advantages in testing an SIPN al-

gorithm, since problems usually can be confined to a small region of the net.

Marking-State-Equality

An SIPNs reaction on input signals depends uniquely on the current marking. In SIPN there are no

internal variables, this means that all information stored in the SIPN is stored in its marking. From a

3.3 SIPN Analysis

31

system theoretic point of view the marking-state-equality means that the marking of the SIPN uniquely defines its state.

State-Output-Mapping (Moore-Property)

In SIPN, there are no action qualifiers, as for example in Grafcet or SFC, that lead to a delayed, lim-ited, pulsed, or stored assignment of values to an output signal. Conditional outputs, i.e. setting of an output signal as a function of input signals, are also not allowed in SIPN. However, all this

elaborate functionality can be modeled in an SIPN by additional net elements. An SIPN that is used to model such functions looks more complex than a model using action qualifiers or conditional

outputs. The advantages are that the inherent complexity of such functions hidden in other formal-isms is directly visible in the SIPN structure and that in SIPN, like in a Moore automaton, the cur-

rent output is a direct function of the state. As a consequence we have a direct mapping from mark-ing to state and on to output.

Feedback-Freeness

In SIPN no direct feedback of the outputs to the inputs is allowed. There is a clear distinction be-tween variables that bring information into the SIPN and variables that bring information from the SIPN to its environment, i.e. the same variable must not be used as an output and an input. A viola-

tion of this principle leads to causal dependencies that are not visible in the structure of the net. Of course, if the SIPN is connected to a process with a by-pass then a direct feedback may result.

3.3 SIPN Analysis

3.3.1 Reachability in SIPN

Reachability in SIPN not only involves the marking of the net but also the input signal settings. If

the concurrent and/or iterated firing of one or more transitions under a marking m and a possible combination of input signal settings in an SIPN generates a new stable marking m’, then m’ is di-

rectly reachable from m. If m’’ is directly reachable from m’ then m’’ is reachable from m.

Definition 3-9: Reachability Set RSSIPN and Reachability Graph RGSIPN of an SIPN

The reachability set RSSIPN of an SIPN = (P, T, F, m0, I, O, 3 & LV WKH VHW RI DOO PDUNLQJV

reachable from m0, including m0. The reachability graph RGSIPN is a graph RGSIPN = (RSSIPN, E

⊆ RSSIPN × RSSIPN) with the reachable markings as vertices. An edge e ∈ E with e = (mi, mk) in-

dicates that the marking mk is directly reachable from mi. The vertices of the graph are labeled with the marking m DQG WKH RXWSXW m). The edges are labeled with the corresponding input

signal settings and the firing transitions. (Example: For the firing of ti and tk under the input set-

ting im = 1 and in = 0 the shorthand ti→tk : im ∧¬ in is used.)

Based on the reachability graph, the possible output settings activated by an SIPN during its evolu-tion can be calculated.


32

Definition 3-10: Possible Output ΩN of an SIPN

The possible output produced by an SIPN during its evolution is denoted by ΩN. ΩN is the sum

over the output of all markings reachable in the SIPN:

ΩN(SIPN) = ∑∈

ΩSIPN

)(RSm

m ; ΩN(SIPN)(oi) gives the possible output produced for the signal oi.

As an example, Figure 3-5 shows an SIPN together with its reachability graph RGSIPN. The possible

outputs of this SIPN are given by ΩN = Ω(m0) + Ω(m1) + Ω(m2) = (-, 0, 1) + (1, 0, 1) + (c, 0, 1) =

(c-, 0, 1) this means that during the evolution of the net, the output signal o1 is contradictory at least once and undefined at least once, o2 is always zero, and o3 is always one.

3(t2) = i3 ∨ i4

&p2)= (0, 1, 0)

&(p3): o3 = 1 &p5)=(1,0,-)

3t3) = i1 3t4) = i1

&p4)=(0,0,-) &p6)=(1,0,1)

3(t5) = ¬i1 ∧ i2 ∧¬i3

3t1) = i3

&p1)= (-,0,1)

m0=(1,0,0,0,0,0) m0) = (-,0,1)

m1=(0,0,1,0,1,0) m1) = (1,0,1)

t1→t2: i3 ∧¬i1

t5: ¬i1∧i2∧¬i3

t3→t4: i1 m2=(0,0,0,0,1,1) m2) = (c,0,1)

t1→t2→t3→t4: i3∧i1

SIPN RGSIPN

N = (c-,0,1)

Figure 3-5: SIPN with its Reachability graph.

For the calculation of the reachability graph in Petri Nets, many algorithms are published and tools

are available. The basic idea of those algorithms is that the net is simulated from the initial marking and the generated states are recorded. This can be done using a branch-and-bound algorithm that stops if no more new markings can be generated from the markings already found. For C/E-Nets this algorithm always terminates because the number of reachable markings is finite. In P/T-Nets special care has to be taken because their reachability graph can be infinite. Since SIPN use the same enabling rule as C/E-Nets the reachability graph is finite. As a basis for the construction of RGSIPN the reachability graph of the underlying PN is generated using known standard algorithms.

Definition 3-11: Reachability Graph RGPN(SIPN) and Reachability Set RSPN(SIPN) of PN(SIPN)

For an SIPN = (P, T, F, m0, I, O, 3 & WKH XQGHUO\LQJ 31 LV JLYHQ E\ 316,31

(P, T, F, m0). The reachability graph, RGPN(SIPN), and reachability set, RSPN(SIPN), of the underly-

ing net are derived by taking the underlying net as C/E-Net (with the strong enabling rule) and

using Definition 3-6.

For the analysis and implementation of the SIPN it is of interest whether the net, seen as P/T-Net, would contain non-binary markings (unsafe states). Therefore, an augmented reachability graph is

3.3 SIPN Analysis

33

defined that includes unsafe states directly reachable from safe states, under the weak enabling rule. The calculation of further states reachable from these directly reachable unsafe states is not neces-sary. Therefore the augmented reachability graph is finite.

Definition 3-12: Augmented Reachability Graph aRGPN(SIPN) and Set aRSPN(SIPN) of PN(SIPN)

For an SIPN = (P, T, F, m0, I, O, 3 & WKH DXJPHQWHG UHDFKDELOLW\ JUDSK RI WKH XQGHUO\Ln Petri Net PN(SIPN) = (P, T, F, m0) is given by aRGPN(SIPN) = (aRSPN(SIPN), aE). The set of verti-

ces aRSPN(SIPN) contains two subsets: aRSPN(SIPN) = RSPN(SIPN) ∪ RSU with the reachability set

RSPN(SIPN) of the underlying Petri Net according Definition 3-11 and the set RSU of unsafe states

directly reachable from states in RSPN(SIPN) under the weak enabling rule. Likewise, the set of

edges consists two subsets: aE = E ∪ EU with the edges between two reachable markings E and

the edges leading to unsafe markings EU.

Figure 3-6 shows an example for the calculation of aRGPN(SIPN). RGPN(SIPN) is derived if the unsafe states and the arcs leading to them (indicated by dashed lines) are removed.

p1 (1, 1, 0, 0)

(0, 1, 1, 0) (0, 0, 2, 0) (1, 0, 1, 0)

(0, 1, 0, 1)

(0, 2, 0, 0)

(0, 0, 0, 2)

(1, 0, 0, 1) (2, 0, 0, 0)

(0, 0, 1, 1)

p2

p3

p4

t4

t5

t3

t2 t1

t4

t3

t2 t4

t5

t3

t2 t1

t3 t5

t1

t1

t5

t3

Figure 3-6: Augmented reachability graph of the underlying PN.

The augmented reachability graph of an SIPN is defined analogously:

Definition 3-13: Augmented Reachability Graph aRGSIPN and Set aRSSIPN of an SIPN

Analogous to aRGPN(SIPN), the augmented reachability graph of an SIPN is given aRGSIPN =

(aRSSIPN, aESIPN) where the set of vertices aRSSIPN contains two subsets: aRSSIPN = RSSIPN ∪

RSU with the reachability set RSSIPN of the SIPN according to Definition 3-9 and RSU: the un-safe states directly reachable from states in RSSIPN under the weak enabling rule. Likewise, the

set of edges consists of two subsets: aESIPN = ESIPN ∪ EU with the edges between two reachable

markings ESIPN and the edges leading to unsafe states EU.

Based on aRGPN(SIPN) and the SIPN firing conditions aRGSIPN and RGSIPN can be built. A first algo-

rithm to derive RGSIPN from RGPN(SIPN) is given in [Frey 2000 (b)]. In the following an improved al-gorithm, that is easier to follow and to implement, is presented (cf. Figure 3-8). The algorithm is based on two main ideas.


34

First, if a marking is reached via the firing of a transition ti with firing condition ϕi, the algorithm

stays in the reached state if it is stable under the input signal setting that corresponds to ϕi = True. A

marking is stable under an input signal setting if no transition can fire in this marking under this in-put signal setting. The stability condition for a marking is derived as the logical conjunction of all negated firing conditions inscribed at the leaving arcs (excluding those leading to unsafe states, be-cause they cannot fire in the SIPN). Therefore, the firing condition of every arc in the reachability graph is extended by the term describing the stability condition of the marking it leads to.

The second idea is that two transitions can only fire in the same calculation cycle if they are con-nected via a marking (the first one leads to the marking and the second one fires under this marking) and their firing conditions are not disjoint. Hence, for every marking it has to be checked if incom-ing arcs and outgoing arcs have disjoint firing conditions. If not, new arcs are introduced that by-pass the marking.

Figure 3-7 shows an example for the application of these two ideas. It can be seen, that after the generation of the new arcs some of them can have a firing condition that is constant False. These arcs are removed from the graph. This removal in turn can lead to states that have no input arc. These states (together with their outgoing arcs) are also removed from the graph.

m0

m1

t1: ϕ1

m2

t2: ϕ2

t1*: ϕ1 ∧ ¬ϕ2

t1→t2: ϕ1 ∧ ϕ2 m0

m1

m2

t2: ϕ2

t1*: ϕ1

m0

m1

m2

t2: ϕ2

t1→t2: ϕ1 ∧ ϕ2 m0

m2

RGPN(SIPN) RGSIPN RGSIPN for (ϕ1 ∧ ϕ2) = 0 RGSIPN for (ϕ1 ∧ ¬ϕ2) = 0

Figure 3-7: Generating RGSIPN from RGPN(SIPN).

3.3 SIPN Analysis

35

Given aRGPN(SIPN) = (aRS = RS ∪ RSU, aE = E ∪ EU ), repeat until all vertices are processed:

1. Starting with the initial marking, take a vertex vi ∈ RS.

2. Get the pre- and post-arcs of vi: •vi = ek = (va, vi)| va ∈ aRS and vi• = ek = (vi, vb)| vb ∈ aRS.

3. Get the safe post-arcs vi•S = vi• ∩ E.

4. If •vi and vi• are not empty:

(4a) Generate new edges for all combinations „ei→ek“ = (va, vb) with ei = (va, vi) ∈ •vi and

ek = (vi, vb) ∈ vi•. These edges are the merger of the two original edges and their firing

conditions are the Boolean conjunction of the two original firing conditions

3ei→ek) = 3(ei) ∧ 3ek).

(4b) For all edges ei ∈ •vi generate new edges ei ZLWK 3ei*) = 3ei) ∧ Sike •∈

∧ν

¬3ek).

(4c) Remove all edges ei ∈ •vi.

(4d) Include the edges newly generated in steps (4a) and (4b) if their firing condition is not constant False.

(4e) Steps (4c) and (4d) can result in a vertex without edges directed to it. This vertex corre-

sponds to a state that is not reachable in the SIPN and can be removed together with all its outgoing edges and of course all vertices that can only be reached from the removed one together with their outgoing edges in a recursive manner.

To account for special cases, the following additions to the algorithm have to be made.

1. The vertex corresponding to the initial marking is not removed even if there are no edges di-

rected to it, because the initial marking is always reachable.

2. Edges that are self-loops are not used in the process.

3. The removal of vertices includes those that are only reachable by themselves (excluding m0).

The algorithm generates aRGSIPN which contains unsafe markings that are used in the analysis.

To get RGSIPN the unsafe markings together with the arcs leading to them have to be removed.

Figure 3-8: Algorithm for the calculation of aRGSIPN and RGSIPN based on aRGPN(SIPN).

Figure 3-9 shows an example of an SIPN together with the reachability graph of the underlying PN and the reachability graph of the SIPN derived following the algorithm presented above.


36

3(t1) = i1 ∧ i2

&p1)= (0, 1)

&p2)=(-, 0)

&(p3): o1 = 1

3t2) = ¬i1

3t3) = i1

3t4) = ¬i2

&p4)=(1, 0)

m0 = (1,0,0,0)

m1 = (0,1,1,0)

mx = (0,0,2,0)

m2 = (0,0,0,1) t1

t2

t4

t3

t1→t3: i1 ∧ i2

t4: ¬i2

a) SIPN b) aRGPN(SIPN) c) RGSIPN = aRGSIPN

m2 = (0,0,0,1) m2) = (1, 0)

m0 = (1,0,0,0) m0) = (0, 1)

N(SIPN) = (d, d)

Figure 3-9: Example of SIPN with aRGPN(SIPN) and RGSIPN.

3.3.2 Dynamic Synchronization (DS)

The examples in the previous sub-sections show that there is an effect in SIPN not known in ordi-

nary PN: several transitions fire simultaneously. This effect, defined in [Frey 2000 (b)] as dynamic synchronization (DS), is so far studied only in the context of SIPN, but can be found in other non-

autonomous models too.

Definition 3-14: Dynamic Synchronization (DS)

Two transitions t1 and t2 form a strong / weak dynamic synchronization if a reachable marking exists such that the firing of t1 implies the simultaneous firing of t2 for all / at least one combina-

tions of input signals. Based on the enabling of the involved transitions sequential and concur-

rent dynamic synchronization are distinguished.

Figure 3-10 shows an example of strong concurrent DS and Figure 3-11 an example of strong se-

quential DS.

With strong DS, the SIPN algorithm can „jump“ from a state to another state without „passing“ through the intermediate states. Hence, states reachable in the underlying PN may not be part of the reachability set (RSSIPN) of the SIPN. With weak DS, the algorithm „jumps“ for some combinations of input signals and markings but proceeds „normally“ for others. This introduces „shortcuts“ (addi-tional arcs) in the reachability graph of the SIPN that are not part of the RG of the underlying PN. From this definition the following conclusions for RSSIPN and RGSIPN can be drawn:

SIPN with strong DS: RSSIPN ⊆ RSPN(SIPN) and E(RGSIPN) ≠ E(RGPN(SIPN)) SIPN with weak DS: RSSIPN = RSPN(SIPN) and E(RGSIPN) ⊇ E(RGPN(SIPN)) SIPN without DS: RSSIPN = RSPN(SIPN) and E(RGSIPN) = E(RGPN(SIPN))

3.3 SIPN Analysis

37

t1

t2

t3

(1, 0, 1, 0)

(0, 1, 1, 0)

(0, 1, 0, 1)

SIPN RGPN(SIPN) RGSIPN

(1, 0, 0, 1)

t2

t3

t1: ¬i1

Ω = (0, 1)

t2→t3: i1

Ω = (1, 0)

(1, 0, 1, 0)

(0, 1, 0, 1)

ϕ(t1) = ¬i1

ω(p1) = (0, -)

ϕ(t2) = i1

ω(p2) = (-, 0)

ω(p3) = (-, 1)

ϕ(t3) = i1

ω(p4) = (1, -)

Figure 3-10: Strong Concurrent DS.

ϕ(t1) = i1

ω(p1)= (0, 0)

ω(p2) = (1, 1)

ϕ(t2) = i1

ϕ(t3) = ¬i1

ω(p3) = (0, 0)

t1

t2

t3

(1, 0, 0) (1, 0, 0)

(0, 1, 0)

(0, 0, 1)

t1→t2: i1

Ω = ( 0, 0)

t3: ¬i1

Ω = (0, 0)

(1, 0, 0) (1, 0, 0)

(0, 0, 1)

SIPN RGPN(SIPN) RGSIPN

Figure 3-11: Strong Sequential DS.

3.3.3 Basic Petri Net Properties and their Adaptation to SIPN

Some basic properties defined in PN theory are of special interest in SIPN. In the following, these properties are presented, and their adaptation to SIPN is described if necessary.

Conflict

A conflict in a PN is given if two transitions are enabled under the same marking, and the firing of one of them disables the other. A PN is called conflict-free if under no reachable marking a conflict exists. Figure 3-12 shows two examples of conflicts in PN. In P/T-Nets only transitions that have a pre-place in common can be in conflict. The basic structure for this case is shown in the PN on the left: t1 and t2 are enabled and the firing of either transition disables the other. In addition to this form


38

of conflict, in C/E-Nets a conflict can also be caused by a shared post-place. The PN on the right il-lustrates this case. Again, t1 and t2 are enabled, and the firing of one of them disables the other.

t1 t2 t1 t2

Figure 3-12: Examples of conflicts in Petri Nets.

Contact

A contact in a C/E-Net is given if all pre-places of a transition are marked and at least one of its post-places is marked. A C/E-Net is said to be contact-free if under no reachable marking a contact exists. In P/T-Nets there are no contacts because the marking of post-places is not considered in the enabling rule. Figure 3-13 shows three C/E-Nets, the nets to the left and in the middle show a con-tact, whereas in the net on the right there is no contact, because not all pre-places of t1 are marked.

t1 t1 t1

Figure 3-13: Examples for the illustration of contacts in C/E-Nets and safety in P/T-Nets.

Safety

A place in a PN is said to be safe, if in all reachable markings, the number of tokens in the place does not exceed one. A PN is safe if all of its places are safe. C/E-Nets are safe by definition be-cause of their enabling rule. If we look at the nets in Figure 3-13 as P/T-Nets then the nets to the left and in the middle are not safe, because in both cases t1 could fire resulting in places marked with

more than one token. We can see that contacts and conflicts caused by shared output-places in C/E-Nets lead to unsafe markings if the same net is seen as P/T-Net.

Deadlock

A marking of a PN is called deadlock if no transition can fire under this marking. A PN is deadlock-

free if it contains no deadlock.

Liveness

A transition is called live, if it can always be enabled again. A PN is called live if all of its transi-

tions are live. Note, every live PN is deadlock-free, but a deadlock-free PN is not always live.

Reversibility

A PN is said to be reversible, if the initial marking can always be reached again. As with liveness, every reversible PN is deadlock-free, but a deadlock-free PN is not always reversible.

Liveness and reversibility are independent properties. To illustrate the connection between liveness, reversibility, and deadlock-freeness, Figure 3-14 shows four deadlock-free PN. The leftmost PN is

3.3 SIPN Analysis

39

live and reversible, the second PN from the left is neither live nor reversible, the third one is live but not reversible, and the rightmost is reversible but not live.

t1 t1

t1

t1

t2 t2

t2

t2

t3

t3

t3

t4

t5

t6

t4

Figure 3-14: Four deadlock-free PN.

For SIPN, the properties defined for PN have to be adapted because the dynamic behavior depends not only on the marking but also on the setting of the input signals.

The SIPN enabling rule is the same as in C/E-Nets, hence both types of conflicts are possible in

SIPN. However, two transitions that are in conflict in the underlying C/E-Net of an SIPN are in conflict in the SIPN only if their firing conditions are not disjoint. As an example take again the

nets in Figure 3-12, for ϕ(t1) = i1 and ϕ(t2) = ¬i1 there are no conflicts. For ϕ(t1) = ϕ(t2) = i1 there is

a conflict whereas for ϕ(t1) = i1 and ϕ(t2) = i2 there is a conflict depending on the input signal set-ting.

Liveness, reversibility, and deadlock-freeness of an SIPN are defined analogous to the respective properties in PN.

Safety means that the number of tokens in a place does not exceed one. In this sense, an SIPN is a priori safe due to its enabling rule. However, it is worthwhile to check the behavior of the net using the weak enabling rule (i.e. checking only the pre-places of a transition). Therefore, safety for SIPN is defined as being safe if the weak enabling rule of P/T-Net is used. With the given semantics, a non-safe SIPN implies non-causal behavior: The transition from an actual situation to the next situa-tion depends not only on the actual situation and the actual values of the input signals but also on the next (future) situation. In addition to this somewhat philosophical demand for safety there is also a very practical reason: The implementation of SIPN on a PLC using standard PLC program-

ming languages results in shorter and faster code if the SIPN is safe [Frey 2000 (a)].

The following definition summons the adaptation of basic PN properties to SIPN


40

Definition 3-15: Petri Net Properties of SIPN

(a) An SIPN is conflict-free if there is no reachable marking such that under any possible setting of input signals two transitions are in conflict, i.e. both transitions can fire but after the firing of one of them the other is no longer enabled.

(b) An SIPN is contact-free if there is no reachable marking such that under any possible setting of input signals a contact exists, i.e. a transition whose firing condition is fulfilled and pre-places are marked but at least one post-place is also marked.

(c) An SIPN is deadlock-free if it contains no deadlocks, i.e. a marking in that no transition can fire for all possible input signal settings.

(d) An SIPN is live if all its transitions are live. A transition in an SIPN is live if it can always fire again.

(e) An SIPN is reversible if for every reachable marking, there exists a sequence of input signal

settings such that the initial marking is reached again.

(f) An SIPN is called safe if it is safe under the weak enabling rule; this implies that it is free of

contacts and conflicts caused by a shared post-place.

3.3.4 Analysis based on the Reachability Graph of the underlying Petri Net

For ordinary PN many tools exist that allow the calculation of the reachability graph and the deter-

mination of properties. The question is whether the results derived by checking a property in the underlying PN are valid for the SIPN. With the results on DS presented in Sub-Section 3.3.2 and the definition of SIPN properties above (Definition 3-15), this question can be answered. Table 3-8 gives an overview on the relation between properties of the underlying PN of an SIPN and the SIPN’s properties for the two cases of SIPN with and without strong DS. In the consecutive text, the results are discussed in more detail.

Property of the underlying PN SIPN without strong DS SIPN with strong DS

Conflict-freeness sufficient but not necessary sufficient but not necessary

Contact-freeness necessary and sufficient sufficient but not necessary

Deadlock-freeness necessary and sufficient sufficient but not necessary

Liveness necessary and sufficient necessary but not sufficient

Reversibility necessary and sufficient neither necessary nor sufficient

Safety necessary and sufficient sufficient but not necessary

Table 3-8: Relation of properties in the SIPN and the underlying PN.

SIPN without strong DS (weak DS is allowed)

A conflict in the underlying PN can always be resolved by the firing conditions in the SIPN. On the other side, additional conflicts cannot be introduced. Therefore, the conflict-freeness of the underly-

ing PN is sufficient but not necessary for the conflict-freeness of an SIPN.

3.3 SIPN Analysis

41

Contacts depend on an unsafe marking in the reachability set and a path leading to it. Since without strong DS the reachability sets of the SIPN and the underlying PN are identical (RSSIPN = RSPN(SIPN)), the SIPN is contact-free if and only if the PN is contact-free.

For SIPN without strong DS deadlock-freeness, liveness, and reversibility of the underlying PN are necessary and sufficient for the corresponding properties in the SIPN. Deadlock-freeness, liveness,

and reversibility are properties that rely on the existence of path’ between markings in the reach-ability graph. Weak DS does not remove arcs from the reachability graph and the added arcs are only combinations of existing ones. Therefore, a path between two markings in RGSIPN exists if and only if there is also a path connecting those markings in RGPN(SIPN).

Safety depends on the existence of unsafe markings in the augmented reachability set. Since with-

out strong DS the augmented reachability sets of the SIPN and the underlying PN are identical (aRSSIPN = aRSPN(SIPN)), the SIPN is safe if and only if the underlying PN is safe.

SIPN with strong DS

For an SIPN with strong DS conflict-freeness of the underlying PN is sufficient but not necessary for the conflict-freeness of the SIPN (the reason is the same as for SIPN without strong DS).

Contact-freeness of the underlying PN is sufficient but not necessary for the conflict-freeness of an SIPN with strong DS. It is sufficient because no new markings are introduced in SIPN. It is not necessary because a contact reachable in the PN may not be reached in the SIPN.

Deadlock-Freeness of the underlying PN is sufficient but not necessary for the deadlock-freeness of an SIPN with strong DS. The reasons are the same as for contact-freeness.

Liveness of the underlying PN is necessary but not sufficient for the liveness of an SIPN with strong DS. It is necessary since DS may introduce additional arcs in the RG but these arcs are al-ways combinations of existing ones. Therefore, a transition that is not part of a cycle in the PN can-not be part of an SIPN cycle. It is not sufficient because arcs originating in an unstable marking in a strong DS are deleted in RGSIPN and this can result in the death of the corresponding transition. In the SIPN depicted in Figure 3-15 the transitions t3 and t4 are dead whereas the underlying PN is live.

Reversibility of the underlying PN is neither necessary nor sufficient for the reversibility of an

SIPN with strong DS. It is not necessary since a marking m ∈ RSPN(SIPN) with no path back to m0

may not be part of RSSIPN. It is not sufficient in the special case that m0 is never reached again in the SIPN because of strong DS (cf. Figure 3-15 for an example).

Safety of the underlying PN (seen as a P/T-Net) is sufficient but not necessary for the safety of an

SIPN with strong DS. The sufficiency is clear because aRSSIPN ⊆ aRSPN(SIPN). It is not necessary as

the counter example in Figure 3-9 shows: The underlying PN is not safe whereas the SIPN is safe.


42

3(t1) = i1

&p1)= (0)

&p2)=(0)

&p3)=(1)

3(t2) = ¬i1 ∧ i2

3(t3) = i3 ∧ i1

3(t4) = ¬i2

&p4)=(0)

m0 = (1,0,0,0,0)

m1 = (0,1,0,0,0)

m2 = (0,0,1,0,0)

m4 = (0,0,0,0,1) t1

t2

t6

t5

t6→t1: i1

t2→t5: ¬i1 ∧ i2

) SIPN b) RGPN(SIPN) c) RGSIPN

t4 m3 = (0,0,0,1,0)

&p5)=(1)

t1*: i1

m0 = (1,0,0,0,0) m0) = (0)

m1 = (0,1,0,0,0) m1) = (0)

m4 = (0,0,0,0,1) m4) = (1)

t3 3(t5) = ¬i1

3(t6) = i1

Figure 3-15: SIPN that is neither live nor reversible though the underlying PN is live and reversible.

3.3.5 Additional SIPN Properties

For SIPN some additional properties are defined that are unknown to PN. First, dynamic synchroni-zation can lead to a cycle in the SIPN that contains no stable marking. In this case, the SIPN does

not terminate. Three other properties describe the correctness of the output signals in an SIPN.

Definition 3-16: SIPN-Properties (Termination; specified, non-contradictory, formally correct Output) (a) An SIPN terminates if there is no cycle without a stable marking.

(b) An output signal is said to be specified if in all states of the SIPN at least one place assigns a

value to it.

(c) An output signal is said to be non-contradictory if in no state of the SIPN it is assigned con-tradictory values (1 from one place and 0 from another place)

(d) An output signal is called formally correct if it is always specified and non-contradictory.

3.3.6 Analysis based on the Reachability Graph of the SIPN

Using the SIPN reachability graph all the properties defined so far for SIPN can be analyzed.

Graph-based analysis methods for properties known in PN can be applied to SIPN, if RGSIPN is used instead of RGPN. Moreover, for special SIPN properties additional analysis methods can be given based on RGSIPN.

Conflict-freeness: An SIPN is conflict-free if and only if the input signal settings at every branch-ing in RGSIPN are disjoint.

Contact-Freeness: An SIPN is contact-free if and only if there is no single arc from a safe to an unsafe marking in aRGSIPN. In the case of a conflict caused by a shared output place the construc-

3.4 Hierarchical SIPN

43

tion of aRGSIPN leads to two arcs from the same marking to the unsafe marking that would result if both transitions would fire in a C/E-Net.

Deadlock-freeness: An SIPN is deadlock-free if and only if there is no node in RGSIPN without

outgoing arcs.

Liveness: An SIPN is live if and only if from every node in RGSIPN a sequence of arcs originates that contains all transitions as labels.

Reversibility: An SIPN is reversible if and only if from every node in RGSIPN a sequence of arcs leads to m0. A necessary and sufficient condition for reversibility is that RGSIPN is strongly con-nected.

Safety: An SIPN is safe if and only if there is no node in aRGSIPN with a component greater one.

Termination: An SIPN terminates if there is no a self-loop, i.e. an arc starting and ending at the same node, in RGSIPN.

Specified output: The output of an SIPN is specified if and only if ΩN(SIPN) ∈ 1, 0, c, d|O |

Non-contradictory output: The output of an SIPN non-contradictory if and only if ΩN(SIPN) ∈

1, 0, -, d, d-|O|

Formally correct output: The output of an SIPN is formally correct if it is specified and non-

contradictory, i.e. if and only if ΩN(SIPN) ∈ 1, 0, d|O|

3.3.7 A Note on Algebraic Analysis

In addition to graph-based methods, there are also algebraic methods for PN analysis. (Transition and Place Invariants). The main advantage of algebraic analysis is that the problem of state space

explosion is avoided. Hence, algebraic conditions are often easier to check for large systems. In [Frey and Schettler 1998] an algebraic criterion for the correctness of SIPN output signals is given.

However, with DS the validity of the condition, based on the underlying PN, is neither necessary nor sufficient for the SIPN.


3.4.1 The Concept of Hierarchy

For real-world programs, SIPN controllers tend to be large and difficult to handle like for most vis-ual languages. Furthermore, methods of analysis are no longer applicable because of the exponen-tial growth of the systems state-space. Last but not least, the code for large SIPN gets very slow on the target system (PLC or other control hardware). However, in most cases subnets can be identified which realize certain subtasks. Therefore, the complete SIPN can be replaced by an abstract SIPN where single places are used instead of these subnets; the subnets are subordinated to these hierar-chical places. Subnets can in turn contain hierarchical places and so on, hence the resulting SIPN is a hierarchical one. Hierarchy does not only enhance the readability, the analyzability, and the result-ing code of an SIPN. It is also a valuable means for the structured design. With a hierarchical struc-


44

ture bottom-up as well as top-down and mixed approaches to design and analysis are possible. Top-down design and analysis is done by refining components in a given net, whereas in bottom-up de-sign, tested components are connected via a common SIPN on a higher level. Experience shows that in practical applications a combination of both techniques is the most appropriate: The general structure of an algorithm is designed top-down and at some level down the hierarchy pre-programmed and tested modules, often containing hierarchical structures themselves, are included.

Petri Nets can be refined hierarchically by putting a subnet in places and/or transitions [Reisig 1982]. Those subnets are Petri Nets that contain an input and an output place in the case of place re-finement and an input and an output transition in the case of transition refinement (cf. Figure 3-16).

p1

„flat“ Petri Net hierarchical Petri Netwith place refinement

hierarchical Petri Netwith transition refinement

p1 p1

p2

p2 p2

p23

p3

p3 p3

t3t3t3

t2

t2 t2

t1

t1 t1 t12

Figure 3-16: Hierarchical refinement of Petri Nets

The three Petri Nets in Figure 3-16 show the same dynamic behavior. In the hierarchical PN with place refinement place p2 receives a token whenever place p23 receives one and transition t3 can only fire if place p3 is marked. In the case with transition refinement, transition t1 can fire if the pre-set of t12 is marked, i.e. it can fire if p1 is marked and removes a token from p1; the firing of t2 puts tokens in the post-set of t12, p3 in this net.

In SIPN only the refinement of places is used, because places describe a partial state or process in the controller that can take some time whereas transitions by definition take no time. The refine-ment of transitions by a subnet containing places would violate the logic control semantics intro-duced for SIPN in Sub-Section 3.2.4.

[Jörns 1997] gives a purely graphical definition for hierarchical nets; stating that net containing a refined place is derived by folding a part of a net that is delimitated by two places into a hierarchical place. The dynamic behavior of the hierarchical net derived by this folding operation is identical to that of the original net. Furthermore, it is implied that a subnet should only be active while the hier-archical place is marked.


45

For the definition given here, the following considerations have been essential:

• To allow an effective implementation of the hierarchical SIPN, a subnet should be passive in the sense that it does not influence the outputs of the hierarchical SIPN and its transitions cannot fire while it is not activated by the corresponding hierarchical place. Note, passivity does not

mean that a subnet cannot store information, i.e. contains no tokens, while the corresponding hi-erarchical place is not marked (for an example see the following Sub-Section).

• To allow the application of analysis methods defined for „flat“ SIPN, the behavior (dynamics and output) of an unfolded, i.e. „flatted“, hierarchical SIPN should be identical to the behavior

of the hierarchical SIPN. Unfolding is done by replacing hierarchical places with a structure putting the corresponding subnet in parallel to the hierarchical place (cf. Figure 3-17). In con-

trary to the unfolding for Petri Nets shown in Figure 3-16, this method avoids problems with ac-tions associated with hierarchical places and timers associated with arcs in timed SIPN.

• A subnet definition should be self-contained in the sense that an analysis of its properties is possible without taking the other elements of the hierarchical SIPN into account.

unfolded SIPN hierarchical SIPN

p1

&(p1)

t1

3t1)

p2

&(p2)

p3

&(p3)

p23

&(p23)

t2

3t2)

t3

3t3)

p1

&(p1)

t1

3t1) p2

&(p2)

p3

&(p3)

p23

&(p23) t2

3t2)

t3

3t3)

subnet associated with p23

Figure 3-17: Unfolding of a hierarchical SIPN.

Note on the graphical representation: A hierarchical place is drawn using a dashed line, to distin-guish it graphically from normal places. The input place of a subnet is made visible by a short arc

ending at the place but without a starting transition. In the same way, the output place has a short arc originating from it but leading to no transition.

3.4.2 Formal Definition of Hierarchical SIPN

A hierarchical SIPN, called SIPNH, is an SIPN extended by a mapping η associating the places of

the net with subnets.


46

Definition 3-17: Hierarchical SIPN (SIPNH)

A hierarchical SIPN is given by a 10-tuple SIPNH = (P, T, F, m0, I, O, 3 & η) with

• the sub-tuple (P, T, F, m0, I, O, 3 & LV DQ 6,31 DFFRUGLQJ WR Definition 3-8 and

• η is a mapping associating places pi ∈ P with subnets η(pi), η is not defined (η(pi) = nil) for

places containing no subnet.

A subnet associated with a place pi in an SIPNH denoted by SIPNSub = η(pi) is itself an SIPNH with

the following restrictions:

• There exists exactly one input-place pin and exactly one output-place pout.

• The subnet is passive, i.e. while the hierarchical place associated with the subnet is not marked,

no transition inside the subnet is enabled and the subnet does not influence any output signals.

• The sets of input and output signals of the subnet are subsets of the respective sets in the SIPNH.

Definition 3-18: Subnet in a hierarchical SIPN

A subnet SIPNSub associated with a hierarchical place pi ∈ P in a hierarchical SIPN

SIPNH = (P, T, F, m0, I, O, 3 & η) is given by

η(pi) = SIPNSub = (Ps, Ts, Fs, m0s, Is, Os, 3s, &s, s, ηs, pin, pout) with the following properties:

• ∃ pin ∈ Ps with •pin = ∅ (input-place)

• ∃ pout ∈ Ps with pout• = ∅ (output-place)

• m(pi) = 0 ⇒ ∀ t ∈ Ts: (∃ p ∈ •t: m(p) = 0 ∨ ∃ p ∈ t•: m(p) = 1) (passivity, transitions)

• m(pi) = 0 ⇒ s = (-)_ s | (passivity, outputs)

• Is ⊆ I, Os ⊆ O

• Ps ∩ P = ∅, Ts ∩ T = ∅

The definition of passivity (the third and forth point in Definition 3-18) may seem a bit compli-cated, where the simple demand that a subnet should not have any initial tokens produces the same effect. However, with the given definition, a subnet may hold initial tokens if it is still passive. It is

even possible to produce subnets with memory, i.e. nets that store information between two activa-tions. This gives SIPNH more modeling power and flexibility. As an example for a subnet with

memory consider the following control problem. In a given situation a controller should turn on a motor. However, there are two motors to be used alternately. The passive subnet given in Figure

3-18 solves the problem. The first time it is called, it is in its initial state „Wait1“ and proceeds to „Motor1“, where M1 is turned on. After the signal „Motor_Stop“ is received by the subnet, it reaches its final state, where the output-place and the place „Wait2“ are marked. After deactivation, „Wait2“ stays marked. Hence, the next time the subnet is activated, Motor M2 is turned on.


47

End (M1, M2) := (0; 0)

Start (M1, M2) := (0; 0)

Motor2 (M1, M2) := (0; 1) Motor1

(M1, M2) := (1; 0)

Wait1(M1, M2) := (-; -)

Wait2 (M1, M2) := (-; -)

Motor_Stop Motor_Stop

Figure 3-18: A subnet that is passive though it contains a token.

3.4.3 Analysis of Hierarchical SIPN by Unfolding

In general, the analysis of an SIPNH can be done on the corresponding unfolded SIPN, called (SIPNH)U. The unfolded SIPN corresponding to a SIPNH is derived by putting the unfolded subnets in parallel to their corresponding hierarchical places in the main SIPN. Unfolding can be done using the algorithm given in Figure 3-19. Note: To identify the elements of a hierarchical SIPN a notation commonly used in object oriented languages can be used. The elements of an object are referred to by object.element. For example, a place p1 in a net Net1 is referred to by Net1.p1.


48

Given a SIPNH = (P, T, F, m0, I, O, 3 & η), repeat:

Select a hierarchical place pi ∈ P: η(pi) ≠ nil.

Define auxiliary variables: P* := P ∪ η(pi).P; T* := T ∪ η(pi).T; F* := F ∪ η(pi).F.

m0(p) , if p ∈ P Generate the combined initial marking:∀ p ∈ P*: m0

*(p) :=

η(pi).m0(p) , if p ∈ η(pi).P

&p) , if p ∈ P Associate the outputs with P*: ∀ p ∈ P*: &*(p) :=

η(pi&p) , if p ∈ η(pi).P

3(t) , if t ∈ T Associate the firing conditions with T*: ∀ t ∈ T*: 3*(t) :=

η(pi).3(t) , if t ∈ η(pi).T

For every arc from a transition to the hierarchical place generate an additional arc from the same transition to the input place of the subnet: ∀ t ∈ •pi: F

* := F* ∪ (t, η(pi).pin).

For every arc from the hierarchical place to a transition generate an additional arc from the output place of the subnet to the same transition: ∀ t ∈ pi•: F* := F* ∪ ( η(pi).pout, t).

Remove the subnet: η(pi) := nil.

Replace the elements of the SIPNH by the values of the corresponding auxiliary variables: P := P*; T := T*; F := F*; m0 := m0

*;∀ p ∈ P &p &*(p); ∀ t ∈ T 3t 3*(t).

Until ∀ pi ∈ P: η(pi) = nil, i.e. there are no more hierarchical places.

Remove η from the describing tuple to get the unfolded SIPNH:

(SIPNH)U = SIPN = (P, T, F, m0, I, O, 3 &

Figure 3-19: Algorithm for unfolding an SIPNH into a flat SIPN with the same behavior.

3.4.4 Analysis of Hierarchical SIPN by Extension

The problem with unfolding is that the resulting unfolded net can get very large. Fortunately, sev-

eral conditions for the formal correctness of the SIPNH can be derived based on all the single nets contained in the hierarchical structure.

To allow an analysis on these nets they have to be converted into SIPN that do not depend on the other nets in the structure. These nets are called extended SIPN. With the extended SIPN a test for

passivity can be given and finally criteria for the correctness of the hierarchical SIPN based on the properties of all the extended nets corresponding to the nets contained in the hierarchical structure are given.

The extended net corresponding to the main, i.e. highest level, net in an SIPNH is derived by remov-LQJ WKH XQGHUO\LQJ VXEQHWV DQG DGGLQJ WKHLU SRVVLEOH RXWSXW N to the corresponding hierarchical

place.


49

Definition 3-19: Extended Net of the top-level SIPN in an SIPNH

Let SIPNH =(P, T, F, m0, I, O, 3 & η) be the top level SIPN in an SIPNH. Then the extended

Net SIPNExt(SIPNH) denotes the tuple (P, T, F, m0, I, O, 3 &Ext, ZKHUH

&p) , if η(p) = nil ∀ p ∈ P: &Ext(p) =

&p) ⋅ N

*(η(pi)) , otherwise with

N(η(p))(ok) , if ok ∈ η(p).O N

*(η(p))(ok)=

- , otherwise ∀ ok ∈ O

The extended net corresponding to a subnet in an SIPNH is also derived by removing the underlying subnets and adding their output to the corresponding hierarchical place. However, in addition to that the output place of a subnet is connected to its input place via a reset transition, a marked idle place,

and a set transition. The firing condition for the set and reset transitions are defined in a way that avoids dynamic synchronization.

Definition 3-20 Extended Net of a subnet in an SIPNH

Let SIPNSub = (P, T, F, m0, I, O, 3 & η, pin, pout) be a subnet in an SIPNH. Then the extended

subnet SIPNExt(SIPNSub) is given by (PEx, TExt, FExt, m0Ext, IExt, O, 3Ext, &Ext,

TExt = T ∪ treset, tset

PExt = P ∪ pidle

FExt = F ∪ (pout, treset), (treset, pidle), (pidle, tset), (tset, pin)

IExt = I ∪ Reset

&p) , if η(p) = nil ∀ p ∈ P: &Ext(p) =

&p) ⋅ N

*(η(pi)) , otherwise with

N(η(p))(ok) , if ok ∈ η(p).O N

*(η(p))(ok)=

- , otherwise ∀ ok ∈ O

&Ext(pidle) = (-, -, -,…,-)

3Ext(treset 5HVHW 3Ext(tset) = ¬Reset, ∀ ti ∈ T 3Ext(ti 3ti)

m0Ext(pidle) = 1, ∀ pi ∈ P: m0Ext(pi) = m0(pi)

The definition of a subnet demands its passivity. With the definition of the extended SIPN a simple

test for passivity can be given:

A subnet SIPNSub of a hierarchical SIPN is passive if all its own subnets are passive and for the reachability graph RGExt of its extended net SIPNExt(SIPNSub) the following conditions hold:

1. The output of all states of containing pidle is undefined for all output variables. The idle state is marked if and only if the subnet is not activated

2. All arc notations in RGExt originating from states containing pidle are a logical conjunction with

the term ¬Reset.


50

Definition 3-21: Extended Set ES(SIPNH)

The set of all extended nets derived from an SIPNH: The extended net of the main net, the ex-

tended nets of all its subnets, there subnets.... is called Extended Set ES(SIPNH).

In the following, conditions for the validity of formal correctness criteria in an hierarchical SIPN based on properties of the SIPN and its extended set are given. For most criteria there is a distinc-tion between live and non-life SIPNH. This is because if the SIPNH is not live, a certain subnet that violates a property may never be activated.

Conflicts, Contacts, and Deadlocks are local properties of an SIPN therefore an SIPNH is conflict-

free, contact-free or deadlock-free if all SIPN ∈ ES(SIPNH) fulfill the respective properties. In the general case, this is a sufficient condition, for live SIPNH the condition is necessary and sufficient.

Liveness: An SIPNH is live if and only if all SIPN ∈ ES(SIPNH) are live.

Reversibility: An SIPNH is reversible if all SIPN ∈ ES(SIPNH) are reversible. In the general case,

this is a sufficient condition, for live SIPNH the condition is necessary and sufficient.

Termination: An SIPNH terminates if all SIPN ∈ ES(SIPNH) terminate. In the general case, this is

a sufficient condition, for live SIPNH the condition is necessary and sufficient.

Specified output: If the outputs are specified in the Extended Net of the top-level SIPN in an SIPNH then the outputs are specified in the SIPNH. This does not necessarily mean that the outputs

are specified in all SIPN ∈ ES(SIPNH). Specified outputs in all nets of a hierarchical SIPN are suf-

ficient but not necessary for the specified output in the SIPNH.

Non-contradictory output: If the outputs are non-contradictory in the Extended Net of the top-level SIPN in an SIPNH then the outputs are non-contradictory in the SIPNH. This does not neces-

sarily mean that the outputs are specified in all SIPN ∈ ES(SIPNH). Non-contradictory outputs in

all nets of a hierarchical SIPN are in the general case neither necessary nor sufficient for the non-contradictory output in the SIPNH. It is not sufficient, because even if the output of all subnets is non-contradictory, the combination of the nets may lead to a contradiction. It is not necessary be-cause a subnet containing contradictions may not be activated. For live SIPNH, non-contradictory outputs in all subnets are necessary but not sufficient for non-contradictory outputs of SIPNH, whereas for an SIPNH that is not live it is neither necessary nor sufficient.

Formally correct output: Formally correct means specified and non-contradictory. From the dis-cussion on specified and non-contradictory outputs above it follows that the outputs of an SIPNH are formally correct if the outputs of the extended net of the main net are formally correct. The for-

mal correctness of the outputs of all SIPN ∈ ES(SIPNH) is neither necessary nor sufficient for this.

3.5 Relation to other Formalisms

51


3.5.1 Relation to other Petri Net Models

PN models closely related to the presented SIPN are the models presented by Moalla, König and Quäck, David and Alla, and Jörns. Some of those models contain timing functions. For the com-parison of the models we can safely ignore these because every PN formalism can be extended to include timers in a variety of ways (for SIPN such an extension is discussed in [Frey 2000 (c), Frey 2001 (d)]). More important are the differences in the marking concepts defined for the various mod-els and most important the definition of their connection to the environment, notably made up of the process to be controlled and the operator. This connection is the property that distinguishes all the models discussed here from standard Petri Nets.

Petri Nets provide no means for modeling the connection between an algorithm and its environ-ment. To overcome this problem, different extensions of the basic PN model have been introduced since the late seventies. The synchronized PN and its further extension to the interpreted PN are the most common ones. The short description of Synchronized and Interpreted Petri Nets given in the following is based on [David and Alla 1992].

Synchronized and Interpreted Petri Nets

Synchronized Petri Nets have been introduced by M. Moalla, J. Polou, and J. Sifakis in the seven-ties. Transitions in synchronized PN are associated with external events. A transition fires if it is en-

abled and when the corresponding event occurs. By definition, two external events can never occur simultaneously. In addition to a set of external events, the always-occurrent event e is introduced. A transition associated with e fires as soon as it is enabled. Synchronized PN have a strictly defined means for the input of events. However, there is no definition for outputs.

Later, M. Moalla extended the Synchronized PN to the Interpreted PN (IPN). An IPN is a (timed)

Synchronized PN that has a data procession unit containing variables and operations. The data processing unit determines the value of conditions, which are associated with the transitions. A marked place can activate operations on the variables in the data processing part. A transition in an IPN fires if it is enabled and its associated firing condition is true and when the associated event oc-curs. Variables may be used as output to the environment as well as internally in the firing condi-tions. The input to the net is still based on events only. The connection to the environment of PN,

Synchronized PN, and IPN is illustrated in Figure 3-20.

Environment

Synchronized Petri Net

(Moalla, Pulou, Sifakis)

Events

Environment

Petri Net

Environment

Interpreted Petri Net (Moalla)

Events

Data Processing

Unit

Net

Variables (Signals)

Conditions

Operations

Figure 3-20: Connection to the environment for PN, Synchronized PN, and Interpreted PN.


52

Synchronized as well as Interpreted PN are not restricted to binary markings. The underlying Petri Net is in both cases a Place/Transition-Net. (The extension of SIPN to include non-binary markings, i.e. to replace the underlying C/E-Net by a P/T-Net is discussed in [Frey 2001 (d)].)

„Steuerungstechnisch interpretierte Petri-Netze“ according to [König and Quäck 1988]

To model logic controllers König proposed „steuerungstechnisch interpretierte Petri-Netze“ (Logic Control Interpreted Petri Nets, LCIPN) in his Ph.D. dissertation (1980). This model is described in

[König and Quäck 1988]. As in SIPN, the connection to the environment is realized with binary in-put and output signals. There are two main differences to the presented SIPN:

1. The underlying Petri Net in the model of König and Quäck is a Place/Transition-Net in con-trary to the Condition/Event-Net in SIPN. However, all nets presented as examples in [König and Quäck 1988] are binary marked and safe.

2. In the actions associated with the places, output variables cannot only be assigned a constant value out of the set 0, 1, - but also functions of the input variables. In SIPN this facility is not provided because it leads to a behavior that is not consistent with the Logic Control Semantics presented for SIPN in Sub-Section 3.2.4, i.e. the output of the net may change without the fir-ing of a transition. A further argument against output settings depending on input signals are

the problems that arise in analysis: The marking of the net is no longer sufficient to describe the state of the system. Therefore, analysis results may depend on input signal settings in a given

marking. In LCIPN this is the case for the analysis of correct output signals.

Besides the differences noted above, the connection to the environment in the LCIPN according to

König and Quäck is identical to the one in SIPN. Figure 3-21 shows this connection that is re-stricted to the use of binary input and output signals.

Environment

Signal Interpreted Petri Net (Frey)

Logic Control Interpreted Petri Net

(König and Quäck)

Conditions (Binary Signals)

Actions (Binary Signals)

Figure 3-21: Connection to the environment for the LCIPN according to König and Quäck and for SIPN.

„Steuerungstechnisch interpretierte Petri-Netze“ following [Jörns 1997]

The model proposed by Jörns is a combination of the Synchronized PN and the signal-based ap-proach introduced by König. From the synchronized PN the input of events is used but not the data processing. From König and Quäck the input and output of signals is used. However, conditional outputs are not used by Jörns. In this model a transition fires if it is enabled and its firing condition is fulfilled and when the associated event occurs. Like in SIPN, the underlying Petri Net in the


53

model according to Jörns is a Condition/Event-Net. Figure 3-22 shows the connection to the envi-ronment.

Environment

Logic ControlInterpreted Petri Net

(Jörns)

Events

Conditions (Binary Signals)

Actions (Binary Signals)

Figure 3-22: Connection to the environment for the LCIPN model according to Jörns.

Control Interpreted Petri Net as defined in [David and Alla 1992]

The Control Interpreted Petri Net (CIPN) defined in [David and Alla 1992] is based on the defini-tion of interpreted Petri Nets given above. In the definition of CIPN, it is stated that a CIPN is an un-timed IPN that is safe, deterministic (this means correct outputs, no conflicts, and no unstable

cycles), and has input and output possibilities extended to be homogeneous with those of Grafcet.

The last condition means that the output can contain level actions and impulse actions. A level ac-tion is the output of a value for a signal as long as the action is activated, i.e. the corresponding place is marked. Hence, a level action corresponds to the outputs described in the other models above. An impulse action is carried out once, at the moment the corresponding place is marked. It resembles the generation of output events by the CIPN. This definition results in the complicated communication structure shown in Figure 3-23. Note that signals in CIPN are not necessary binary.

Environment

Control Interpreted Petri Net (David, Alla)

Events

Data Processing

Unit

Net

Variables (Signals)

Conditions

Operations

Conditions (Signals)

Actions (Signals)

Impulse Actions (‘Events’)

Figure 3-23: Connection to the environment for PN, Synchronized PN, and Interpreted PN.

3.5.2 Relation to Grafcet according to IEC 60848

Around 1972-1973 several French researchers started to describe logic controllers with Petri Nets. This work had a great influence on the further development in France. In 1975, a working group of AFCET (Association Française pour la Cybernétique Economique et Technique) set up a commis-sion entitled „Normalization of the Representation of the Specifications of Logic Controllers“. The aim of this working group was to find a common description model for logic controllers. The result of this effort was the proposal of the specification language Grafcet in a final report dated August


54

1977. Today in France, Grafcet is widely used in industry and academics. Grafcet became an inter-national standard in 1988 [IEC 60848]. Comparing Grafcet to SIPN shows four main differences:

1. Firing conditions used in Grafcet can depend on the marking, which is not the case in SIPN. The

use of marking information in firing conditions violates the locality principle because the influ-ence of a marked place is no longer restricted to the transitions directly connected to it. It is also

a threat to formal analysis.

2. As the CIPN presented in the previous Sub-Section, the Grafcet model is connected to its envi-ronment via signals and events. This is in contrary to SIPN where only signals are used. How-

ever, the signals used in Grafcet are Boolean like in SIPN.

3. A Grafcet contains a processing section with internal variables and operations like the CIPN.

4. The firing rules in Grafcet are specified to guarantee a deterministic behavior. Though the mark-ing in Grafcet is binary, conflicts and contacts are not possible.

While the first three differences may be interpreted as an extension to the SIPN, the forth one is very interesting because it leads to another dynamic behavior. The firing rules of Grafcet state that a transition is enabled if all the input places are marked. It is fireable if the associated condition is true and an associated event occurs. Now there are three rules for the firing of fireable transitions:

Rule 1: All fireable transitions are fired immediately.

Rule 2: Several simultaneously fireable transitions are simultaneously fired.

Rule 3: When a step must be simultaneously activated and inactivated, it remains activated.

The first rule is identical to SIPN. The third rule is only of interest if impulse actions are associated with the step or timers are used. The second rule however makes the big difference to Petri Nets in

general and to SIPN. This difference is visible in the case of contacts and conflicts (caused by out-put places as well as caused by input places) in an SIPN. Figure 3-24 shows these cases using small

Grafcet examples. Note that in the standardized form a step in Grafcet is drawn as a box instead of a circle and the arrowheads are left out, because the direction is top-down by definition.


55

11

10

i1

11

10

i1

13

11 12

i1 i2

13

11 12

i1 i2

i1ANDi2 = 1

10

11 12

i1 i2

10

11 12

i1 i2

Figure 3-24: Situations where the evolution in Grafcet differs from that in SIPN.

A Grafcet where none of the situations presented in Figure 3-24 can occur is defined as a sound

Grafcet in [David and Alla 1992]. A sound Grafcet is equivalent to the Control Interpreted Petri Net presented in the previous Sub-Section. Furthermore, a sound Grafcet is equivalent to an SIPN if only those mechanisms for inputs and outputs are used that are also defined for SIPN. On the other side, an SIPN that is deterministic and safe is equivalent to a Grafcet.

Note: The hierarchy concept defined for Grafcet in the form of Macrosteps is equivalent to the hier-archy concept using hierarchical places in SIPN.

3.5.3 Relation to SFC according to IEC 61131

There is a close relation of SIPN to Sequential Function Chart (SFC) according to the IEC 61131-3 standard. This is not surprising taking into account that SFC is based on Grafcet and the close rela-tion of SIPN to Grafcet established in the previous Sub-Section. The relation to SFC is of special interest because SFC is an implementation language that can be used to build a realization of an SIPN on a PLC. However, besides the similarities, six main differences have to be considered:

1. Actions in SFC can contain complete programs in any of the IEC 61131-3 languages. Fur-thermore, they may contain an Action Qualifier resulting for example in stored or delayed output.

2. There is a structural restriction in SFC allowing only one initial step.

3. In SFC post-steps of a transition are not checked in the firing rule. A step that is already acti-

vated can be activated again.

4. In SFC there are, by definition, no transient states. The activity of a step is always held up for at least one PLC cycle.

5. Variables in SFC, like in all implementation languages, always have a defined value.


56

6. There are no conflicts between transitions in SFC. Several transitions are either prioritized by the user or the priority is forced in a left to right manner.

Due to the first difference, a transformation of an SFC into an SIPN is only possible if restrictions

to the SFC design are applied [Frey and Litz 1997].

The fifth and the sixth point in the list are of no interest if a formally correct SIPN is implemented as an SFC because then all the variables in the SIPN are defined and conflicts are not possible. If an

SFC is transferred into an SIPN then additional variable settings may have to be included and the priority of the transitions has to be modeled into the firing conditions. A transition t1 with firing

condition ϕ1 is prioritized over another transition t2 with firing condition ϕ2 by extending the firing

condition of t2 to ϕ2* = ϕ2 ∧ ¬ϕ1.

SIPN that are safe, free of sequential dynamic synchronization, and contain only one initially marked place, can be transformed one-to-one into an SFC.

For SIPN with several initially marked places an additional init-step has to be added in the SFC that activates the corresponding steps right after start-up.

For unsafe SIPN, the firing conditions of transitions leading to unsafe markings have to be extended in the SFC such that the unsafe state is not reached. This is done using the variable StepName.X de-fined in IEC 61131-3 for each step. StepName.X is true if the step is marked and false otherwise. Therefore, if the transition ti results in an unsafe marking in place pj the corresponding firing condi-

tion ϕ(ti) has to be replaced by ϕSFC(ti) = ϕ(ti) ∧ ¬pj.X in the SFC (cf. Figure 3-25).

a) unsafe SIPN b) RGSIPN*

3(t1) = i1 ∧ i2

p3 3t2) = ¬i1

3(t3) = i1∧¬i2

p2

p1

M1 = (0,1,1)

M0 = (1,0,0)

t3 : i1∧¬i2 t1 : i1 ∧ i2

Mu = (0,0,2)

t2 : ¬i1

c) SFC

i1 & i2

NOT i1 & NOT S3.X

i1& NOT i2

S1

S2

S3

Figure 3-25: SFC implementation of an unsafe SIPN.

If the SIPN contains sequential dynamic synchronization, additional transitions have to be specified in the SFC to account for the sequential firing (cf. Figure 3-26).

3.6 Discussion

57

a) SIPN with sequential DS b) RGSIPN

3(t1) = i1∧i2

p3

3t2) = ¬i1

3t3) = ¬i2

p2

p1

M1 = (0,1,0)

M0 = (1,0,0)

t2→t3: ¬i1∧¬i2 t1 : i1 ∧ i2

M2 = (0,0,1)

t2* : ¬i1∧i2

t3 : ¬i2

c) SFC

i1 & i2

NOT i1 & i2

NOT i2

S1

S2

S3 NOT i1 & NOT i2

Figure 3-26: Implementation of SIPN with sequential dynamic synchronization.

As noted above, in a step of an SFC a complete sub-routine written in any of the IEC 61131-3 lan-guages may be activated. This property can be used to translate a hierarchical SIPN into a similar

structured SFC. If an SFC is put into the action block of a step in another SFC, the SFC on the lower level is executed as long as the step is active. In this sense, it is identical to the behavior in an SIPNH. However, the deactivation of the calling step in SFC can happen independent of the state of the SFC on the lower level. If the calling step is deactivated, the execution of the called SFC is sim-ply stopped. To ensure that the whole sub-SFC is processed before the deactivation of the calling step a variable has to be set in the last step. This variable is then included in the firing condition of

transitions that can deactivate the calling step. Figure 3-27 shows a hierarchical SIPN and a func-tionally identical SFC, in this example the variable EL is used to force the complete processing of

the subnet.

p1

&(p1) = (0,0)

p2

&(p2) = (0,-)

p3

&(p3) = (1,-)

p23

&(p23) = (-,1)

subnet associated

with p23

S1

SecondLevelP23 N

S23

S2

S3 A1 S

EL S

A2 S

A2 R

A1 R

A1 R

t1

3t1) = ¬i1

t23t2) = i2

t33(t3) = i1

i1 AND EL

NOT i1

i2

Figure 3-27: SIPNH and corresponding SFC with SFC substructure.

3.6 Discussion

In this Chapter Signal Interpreted Petri Net (SIPN) are introduced. It is shown that the adaptation of results from standard PN analysis to SIPN is only possible in restricted cases. The reason for this problem, dynamic synchronization (DS), is identified and its impact on analysis is studied. The de-scribed problems lead to the description of graph-based analysis methods using the newly defined


58

reachability graph of an SIPN instead of the reachability graph of the underlying PN. The presenta-tion of an example from algebraic analysis shows where the open questions with DS lie. Currently the only method to find DS is the construction of the reachability graph. Future work may be di-rected on algorithms that find DS on a structural basis. One algorithm to do so is presented in Chap-ter 7 on code-generation. However, this algorithm gives no necessary conditions and may be too re-strictive for formal analysis.

The comparison to other Petri Net based approaches shows that the SIPN has a simpler structure than those methods. This may seem to be a drawback at first. However, for safety related control al-gorithms that have to be verified according to [IEC 61508-1] it is a pre-requisite as [Halang 2000] puts it: „The requirements and objectives to be fulfilled by safety related automation systems can only be achieved if simplicity is selected as the fundamental design principle, and if (mainly artifi-cial complexity) is fought. At the present state of the art, simplicity is a key pre-requisite to enable the licensing authorities to formally approve the utilization of computer based systems for purposes of safety related control, since a simple system is easy to understand and its behavior is easy to fol-low up.“

The close relations of SIPN to the specification language Grafcet and the implementation language SFC allow the adaptation of the methods presented in the consecutive text to those formalisms.

59

4. Verification

4.1 The Verification Process

Figure 4-1 shows a detailed view of the verification process. Verification should answer the ques-tion whether the formal specification of the control algorithm is correctly built. This means if it ful-fils standard functional properties that are independent of the control problem, like for example de-terminism.

To apply formal verification methods these informal properties have to be formalized. This formal-ization is still independent of the control problem at hand but it depends of course on the method used to verify the properties and on the model chosen to describe the controller.

In the next Section an informal specification of standard functional properties for control algorithms is given. These properties are formalized for SIPN to be verified using reachability graph based methods in Section 4.3. With these pre-formalized properties, the process of verification is reduced to the respective part of Figure 1-1, namely the selection of pre-formalized properties.

Informal Specificationof Problem

Specific Functional Properties

Informal Specification of StandardFunctionalProperties


of the Control

Algorithm

Formalized Standard

FunctionalProperties

Verification

Formalization

Formalism used for the Specification

of the Control

Algorithm

Method used for

Verification

Formalization (Design)

Correction

Verification Result:

Properties are either fulfilled or

not fulfilled





of the Control

Algorithm

Formalized Standard


Verification

Formalization


of the Control

Algorithm

Method used for

Verification



CorrectionCorrection

Verification Result:


not fulfilled

Figure 4-1: Detailed description of verification.

4 Verification

60

4.2 Informal Specification of Standard Functional Properties

In this section, we present an informal specification of standard functional properties for control al-gorithms. Common to all the presented properties is that they are essential for the correct function-ing of an implemented controller and that they are independent of the control problem.

First of all a controller has to be specified syntactically correct according to the definitions of the formalism used. This property is often not considered during verification because most tools used

for the specification of controllers provide automatic syntax checks or even avoid syntax errors.

In contrary to syntactical correctness, the following properties deal with the formal correctness [Frey and Litz 2000 (b)] of the algorithm. The first property, is the deterministic behavior of the

controller:

(P1) (mandatory) Every control algorithm must have deterministically defined dynamics and I/O-behavior. If it had not, its behavior in a given situation would depend on implementation as-

pects. This of course cannot be the aim of a correct design. In detail, this means that in every state of the controller

(a) the reaction on possible input signals is defined and (b) a non-contradictory value for each output signal is specified.

Properties formulated similar to P1 are widely accepted as mandatory and can be found in many

works on formal methods in control. [König and Quäck 1988] use a type of Logic Control Inter-preted Petri Net and define an algorithm fulfilling P1 as „implementation-worthy“. The concept of a

„sound Grafcet“ defined in [David and Alla 1992] is also based on deterministic behavior. The Con-trol Interpreted Petri Net presented in [David and Alla 1992] contains a similar property in its defi-

nition. Further similar definitions can be found for example in [Litz 1995, Jörns 1997].

In addition to deterministic behavior further standard functional properties can be specified, that are not always necessary:

(P2) (optional) Every part of a controller should work in the sense that it is always possible that the respective code is executed again. When a part of a control algorithm does not work anymore,

there is—in general—an error in the design of the control algorithm. There are however cases, where this property is not desired.

(P3) (optional) P3 is a weakened version of P2: A controller should never get completely stuck. A

controller that should run in a cyclic fashion after a start-up phase does not fulfill the property P2, because the start-up part is never activated again. However, it should fulfill P3. Again,

there are special controllers that should get stuck in defined states due to safety regularities. In these cases, the P3 is not a desired property.

(P4) (optional) A control algorithm should be able to reach its initial state again. Following

[Desrochers and Al-Jaar 1994], this property of a controller implies that automatic error re-covery is possible. As with P2 and P3, there are cases where this property is not desired.

4.3 Formalization: Criteria for Formal Correctness

61

To formally verify these properties for a given controller they have to be formalized. As stated above, the properties presented here are independent of the specific controller. Hence, they can be pre-formalized.

4.3 Formalization: Criteria for Formal Correctness

All the properties given informally in the previous Section can be connected to SIPN properties de-fined in Chapter 3 and to verification methods based on reachability analysis.

There are various threats to the deterministic behavior specified in property P1. First, two transi-tions that are in conflict in an SIPN lead to a behavior that is not determined. Of course, an imple-mented algorithm will solve this non-determinism but it cannot be the aim of a correct controller design, to leave the decision of how to react on an input in a given situation to implementation as-pects. Another source of non-deterministic behavior is the existence of endless loops in an SIPN, i.e. an SIPN that does not terminate. An endless loop may even lead to the hang-up of the imple-mented controller. Further problems can arise due to the distributed assignment of values to the out-put signals in SIPN. On the one side, it is possible that an output signal is assigned no value at all (not specified output). On the other side, different values can be assigned in different places of the SIPN in the same reachable marking (contradictory output).

The following figures show examples of SIPN algorithms that are not deterministically defined. The algorithm in Figure 4-2 is not conflict-free: If in the initial state the input signal i1 is set to one it is not clear whether transition t1 or t2 should fire. Figure 4-3 shows an SIPN that gets into an endless loop as soon as the input signal i1 is set to one. Finally, for the net in Figure 4-4 the calculation of

possible outputs results in ΩN(SIPN) = (c, 0, d-) which means that the outputs are defined contradic-

tory for o1 and not fully specified for o3.

3t1) = i1 3t2) = i1

&p2)=(1,0,1) &p3)=(0,1,1)

3(t3) = ¬i1 ∧ i2

m0=(1,0,0)

m1=(0,1,0)

t1: i1

t4: ¬i1∧i2

t2: i1

m2=(0,0,1)

SIPN RGSIPN

3(t4) = ¬i1 ∧ i2

t3: ¬i1∧i2 &p0)=(1,0,0)

Figure 4-2: SIPN that is not conflict-free.

3t2) = i1 3t1) = i1

&p1)=(1,0,1)

&p2)=(0,1,1)

m0=(1,0)

t1 → t2: i1 SIPN RGSIPN

Figure 4-3: SIPN that does not terminate.

4 Verification

62

&p2)=(0,0,-) &p3)=(1,0,-)

3t2) = ¬i1

3t1) = i1

&p1)= (0,0,1) m0=(1,0,0)

m1=(0,1,1) c,0,-)

t1: i1 t2: ¬i1

SIPN RGSIPN

Figure 4-4: SIPN with unspecified and contradictory defined output signals.

The other three properties can be directly related to specific SIPN properties.

P2 liveness of the SIPN,

P3 deadlock-freeness of the SIPN, and

P4 reversibility of the SIPN.

For examples of SIPN that are not live, not reversible or not deadlock-free see Chapter 3. In Table 4-1 the properties are shown together with the corresponding formal SIPN properties and a method to verify them on the reachability graph.

# Informal Property

SIPN Property

Formal Criterion to Check at RG

c1 Conflict-freeness The algorithm is deterministic if and only if the firing con-ditions at every branching in RGSIPN are disjoint

c2 Termination The algorithm terminates if and only if there is no self-loop

at any state in RGSIPN

c3 Specified output

The outputs of an SIPN are speci-fied if and only if

ΩN(SIPN) ∈ 0, 1, c, d|O|

c4

P1 (mandatory)

Non-contradic-tory output

Formally correct output

The outputs of an SIPN are non-contradictory if and only if

ΩN(SIPN)∈ 0, 1, -, d, d-|O|

The outputs of an SIPN are formally correct if and only if

ΩN(SIPN) ∈ 0, 1, d|O|

c5 P2

(optional)

Liveness For liveness there has to be a path from every state in

RGSIPN containing all transition at its labels

c6 P3 (optional)

Deadlock-freeness There must be no state in RGSIPN without an outgoing arc.

c7 P4 (optional)

Reversibility Reversibility is guaranteed if and only if from every mark-ing in RGSIPN a path back to m0 exists

Table 4-1: Criteria for formal correctness.

Since the verification of the properties using the reachability graph does not include any knowledge

about the process under control, the reaction of the controller on unknown behavior like for exam-ple sensor failures is included in the calculation. If the algorithm is proved to be defined determinis-

4.4 Summary

63

tically in the presented verification, then the controller will behave deterministically whatever proc-ess it is connected to. If the algorithm is not live, deadlock-free, or reversible in this sense then the controller cannot be live, deadlock-free, or reversible regardless what process it is connected to.

The verification presented so far is non-model-based. However, it is easily extended to constraint-based verification. Static constraints on the input signals of the form „Logical function over the in-

put signals = False“ can be used to build a constrained reachability graph.

4.4 Summary

In this Chapter, informal standard functional properties for controllers have been introduced. In this informal way, the properties may be applied to every controller regardless of the formalism used to describe it and the method intended to verify the properties. For the case of SIPN as formalism and reachability analysis as verification method, the properties are formalized and criteria to verify them are presented. All the presented properties can be verified automatically by computer algorithms us-ing the SIPN’s reachability graph. Hence, the only remaining task for a user of the SIPN method in the verification process is to select the pre-formalized properties to be verified. In Figure 4-5 the re-sulting verification process for SIPN is illustrated.



Formal Correctness

Criteria(Pre-Formalized

Standard FunctionalProperties)


of the Control

Algorithm as SIPN

Correctness Analysis(Verification using the Reachability Graph)

SelectionFormalization using SIPN

(Design)

Correction

Verification Result

Properties are fulfilled

or not fulfilled




Formal Correctness

Criteria(Pre-Formalized

Standard FunctionalProperties)


of the Control

Algorithm as SIPN

Correctness Analysis(Verification using the Reachability Graph)

SelectionFormalization using SIPN

(Design)

Formalization using SIPN

(Design)

CorrectionCorrection

Verification Result


or not fulfilled


Figure 4-5: Verification of SIPN.

65

5. Evaluation

5.1 The Evaluation Process

The Evaluation of a controller deals with non-functional properties attributed to the algorithm (cf. Figure 5-1). In general, evaluation will be performed after V&V. However, the properties analyzed in evaluation are independent from those in V&V. Hence, a controller can be evaluated at every stage of its development.




of Non-FunctionalProperties


of the Control

Algorithm

Formalized Non-


Evaluation

Formalization


of the Control

Algorithm

Method used for

Evaluation


Correction(Design-

Improvement)

Evaluation Result:


more or less






of the Control

Algorithm

Formalized Non-


Evaluation

Formalization


of the Control

Algorithm

Method used for

Evaluation



Correction(Design-

Improvement)

Correction(Design-

Improvement)

Evaluation Result:


more or less

Figure 5-1: Formal evaluation process.

For formal evaluation, the informally specified non-functional properties have to be formalized. As in verification, the formalization of these properties is independent of the specific control problem. However, again as in verification, it depends on the formalism used to specify the controller and on

the method to be used in evaluation.

A main difference between evaluation and V&V is that in V&V the analysis result is always a Yes/No decision, i.e. a property is either fulfilled or not fulfilled. In evaluation a property is fulfilled

more or less. For example, a controller is either deterministic or not, but is can be more or less read-

5 Evaluation

66

able. Therefore, the formalization of non-functional properties results in metrics. The evaluation of those metrics on the formal description of the control algorithm gives a numerical value describing the fulfillment of the properties. Based on this evaluation result, the user has to decide whether the controller is good enough or has to be improved. If during this improvement changes that go be-yond documentation or beautification are made to the algorithm, then earlier verified and validated properties have to be checked again.

In the following section, we will informally specify non-functional properties for control algo-rithms. For the case of SIPN based controller development these properties are formalized in Sec-tion 5.3. This formalization yields ten transparency metrics, describing various aspects that influ-ence how easy it is to understand a controller.

5.2 Informal Specification of non-functional Properties

Non-functional properties for control algorithms can be defined for a variety of aspects. We will re-strict ourselves to the discussion of non-functional properties that are directly related to the portability and maintainability of the algorithm according to ISO 9126 (cf. Table 2-2). This means, primarily, properties that determine how easy is it for a control engineer to understand the algorithm. Further questions like the ease of corrections or changes to the algorithm primarily rely on understanding the algorithm in the first place.

For an algorithm to be understood easily, the following five properties should hold:

(P1) An algorithm should be well documented.

(P2) If graphical methods are used for the specification of the algorithm, the graphical representa-tion should be as clearly arranged as possible.

(P3) The algorithm should not contain too much redundant information.

(P4) The description of the algorithm should allow to determine its behavior as easily as possible.

(P5) The algorithm should not be more complex than necessary.

5.3 Formalization: Transparency Metrics

5.3.1 Overview and Introductory Example

In the following five Sub-Sections the five informal properties given in the previous section for control algorithms in general, are formalized for SIPN. The formalization is carried out by the defi-nition of transparency metrics. As a conclusion to this Section, in Sub-Section 5.3.7 all the pre-sented metrics are combined to a single transparency metric T, and a method for the visualization of this multi-dimensional metric is proposed.

As guidelines for the formal definition of the transparency metrics the following points are used:

• High transparency corresponds to an algorithm easy to understand.

• A metric takes numerical values between zero and one.


67

• In transparency metrics zero corresponds to low and one corresponds to high transparency

• If possible, both extremes of the metric should be realizable by a control algorithm.

• The mathematical definition should be as easy as possible, i.e. linear mappings and relations are preferred to exponentials.

Throughout the definition of the metrics two SIPN controllers designed for the heating tank prob-lem, introduced in Section 3.1, are used as an illustrative example. Figure 5-2 and Figure 5-3 show the two SIPN. Both SIPN have been verified to be formally correct. Furthermore, both of them solve the control problem. However, one of them is easier to understand than the other.

t1: Start Button pressed ϕ(t1) = i4 ∧ ¬i1 ∧ ¬i2

p1: Stand By ω(p1) = (0, 0, 0, 0)

p2: Filling ω(p2) = (1, 0, -, 0)

p3: Heating ω(p3) = (0, 0, -, 1)

p5: Stirring ω(p5): o3 = 1

p4: Emptying ω(p4) = (0, 1, -, 0) t4: Tank is empty &

Start Button released ϕ(t4) = ¬i1 ∧ ¬i2 ∧ ¬i4


t2:Filled & Temp. low ϕ(t2) = i2 ∧ ¬i3

t3: Filled & Temp. OK ϕ(t3) = i2 ∧ i3

m0=(1,0,0,0,0)

m1=(0,1,0,0,1)

m2=(0,0,1,0,1)

t1: ¬i1 ∧ ¬i2 ∧ i4

t2: i2 ∧ ¬i3

t4: ¬i1 ∧ ¬i2 ∧ ¬i4

t5: i2 ∧ i3

m3=(0,0,0,1,1)

t3: i2 ∧ i3

Figure 5-2: First SIPN (SIPN1) for the heating tank with corresponding reachability graph aRGSIPN.

t1: Start button pressed ϕ(t1) = ¬i2 ∧ i4

p1: Standby ω(p1) = (0, 0, 0, 0, 0)

p2 ω(p2) = (1,0,1,0,0)

p3 ω(p3) = (0, 0, 1, 1, 0)

p5 ω(p5) = (-, -, 1, -, 0)

p4 ω(p4) = (0, 1, 1, 0, 0)

t4 ϕ(t4) = ¬i1 ∧ ¬i4

t2: Tank is full ϕ(t2) = i2 ∧ (¬i5 ∨ i5)

t3 ϕ(t3) = i3

t5 ϕ(t5) = ¬i1 ∧ ¬i4

m0=(1,0,0,0,0)

m1=(0,1,0,0,1)

m2=(0,0,1,0,1)

t1: ¬i2 ∧ i4

t2*: i2 ∧ ¬i3

t4: ¬i1 ∧ ¬i4

(t2→t3)*:

i2 ∧ i3 ∧ (i1 ∨ i4)

m3=(0,0,0,1,1)

t3*:

i3 ∧ (i1 ∨ i4)

t2→t3→t4:¬i1 ∧ i2 ∧ i3 ∧ ¬i4

t3→t4:¬i1 ∧ i3 ∧ ¬i4

mu1=(0,0,2,0,0)

t5: ¬i1 ∧ ¬i4

Figure 5-3: Second SIPN (SIPN2) for the heating tank with corresponding reachability graph aRGSIPN.

5 Evaluation

68

5.3.2 Documentation (P1)

Documentation in an SIPN means the use of comments throughout the net. The more comments are used in the net, the easier it is to understand and the nearer to one a corresponding metric should be. Comments can be associated with places and transitions. Therefore, the number of comments in an SIPN has an upper bound that equals the sum of the number of places and the number of transitions. The lower bound for the number of comments is zero. With this, a metric according to Definition

5-1 results for the number of comments in a net.1

Definition 5-1: Transparency Metric t1 (Comments)

sTransition# Places #

Comments #t1 +

=

The metric is one if there are comments at every place and every transition. It is zero if there are no comments at all in the SIPN. Since the sets of places and transitions in an SIPN are non-empty per definition, the denominator of the formula for t1 is always greater than zero.

Example:

t1(SIPN1) = 1 (every place and every transition has an associated comment) t1(SIPN2) = 0.3 (3 comments, 5 places, 5 transitions)

5.3.3 Graphical Representation (P2)

In contrary to some other net-based formalisms as for example SFC, there are no restrictions for the graphical layout of SIPN. This gives the designer many layout possibilities to choose from in draw-ing an SIPN. However, not all of these layouts are good to understand. Experience shows that SIPN that are arranged in a way that illustrates the control flow of an algorithm in one preferred direction (usually chosen as top-down) are the easiest to follow.

This graphical property is mapped on a metric by counting the arcs in an SIPN that point in the pre-ferred direction and setting them in relation to the number of all arcs in the net.

Definition 5-2: Transparency Metric t2 (Directionality)

Arcs #

DirectionPreferredinArcs #t 2 =

The metric is one if all arcs point in the preferred direction. It is zero if there are no arcs pointing in

the preferred direction. Since the set of arcs in an SIPN is non-empty by definition, the denominator of the formula for t2 is always greater than zero. There is some room for interpretation in the defini-tion of an arc’s direction. In our studies and in the example here we choose top-down as preferred direction and say that an arc points downward if the arrowhead points downward (directly down

±45°).

1 In the following formulae the symbol # is used to denote the “number of”, i.e. #Comments is the number of comments.


69

Example:

t2(SIPN1) = 1 (all arcs are pointing downward) t2(SIPN2) = 0.46 (only 5 out of a total of 12 arcs point downward)

A further graphical property that hinders understanding is the existence of intersecting arcs in the SIPN.

Definition 5-3: Transparency Metric t3 (Intersections)

SIPNin Arcs #

SIPNin Arcs dIntersecte #1t 3 −=

The metric is one if there are no intersections and zero if all arcs are crossed by at least one other arc. As in t2, the denominator of the formula for t3 is always greater than zero.

Example:

t3(SIPN1) = 1 (there are no intersections)

t3(SIPN2) = 0.75 (3 out of a total of 12 arcs are crossed by at least one other arc)

5.3.4 Redundant Information (P3)

Redundant information may be found at different elements in an SIPN. We identify it by having a

look at all SIPN elements in turn:

Places

Two places p1 and p2 that always have the same number of tokens (∀m ∈ RSSIPN: m(p1) = m(p2))

may be replaced by one single place. This replacement does not change the I/O-behavior. However, the places may not be in close proximity but in different parts of the net. In this case a merger surely

would decrease the readability. Another form of redundant place is a place that is newer marked stable. Both kinds of redundant places lead to or are caused by dynamic synchronization (DS). We will deal with DS in the metrics for visible dynamics. Therefore, places are not considered under criteria for redundant information.

Transitions

Two transitions that always fire at the same time can be replaced by one transition. This is also a

cause for redundant information. However, this is the definition for DS. Therefore, as with places we will deal with redundant transitions in the next Sub-Section.

Arcs

Since an SIPN is defined as an ordinary Petri Net there can be no redundant arcs.

Input Signals

If an input signal has no influence on the SIPN it is said to be redundant. Redundant input signals provide only redundant information.

5 Evaluation

70

Definition 5-4: Transparency Metric t4 (Redundant Input)

SignalsInput #

SignalsInput Redundant #1t 4 −=

The metric is one if there are no redundant input signals and zero if all input signals are redundant. Since the set of input signals in an SIPN is non-empty by definition, the denominator of the formula

for t4 is always greater than zero.

Example:

t4(SIPN1) = 1 (there are no redundant input signals) t4(SIPN2) = 0.8 (1 out of 5 input signals is redundant: i5)

Output Signals

An output signal is called redundant if it is set constantly to the same value. This is a clear case of misleading redundant information.

Definition 5-5: Transparency Metric t5 (Redundant Output)

SignalsOutput #SignalsOutput Redundant #

1t5 −=

The metric is one if there are no redundant output signals and zero if all output signals are redun-dant. The set of output signals in an SIPN is non-empty by definition, therefore the denominator of

the formula for t5 is always greater than zero.

Example:

t5(SIPN1) = 1 (there are no redundant output signals) t5(SIPN2) = 0.8 (1 out of 5 output signals is are redundant: o5)

Another form of redundant information in output signals results whenever several marked places set an output signal to the same value. To find these redundancies, for every setting of an output signal in a reachable state it has to be checked how many places set this signal. If it is only one place then the output is considered as non-redundant. The number of non-redundant output settings is set in re-lation to the number of output assignments in the SIPN markings.

Definition 5-6: Transparency Metric t6 (Redundant Output Settings)

( )Markings SIPNin sAssignmentOutput #1,max

RGin SettingsOutput redundant -nonCorrect Formally #t SIPN

6 =

For every formally correct non-redundant output setting in a marking in RGSIPN, there is exactly one marked place assigning a value to this output under the corresponding marking. Hence, the metric is one if there are no redundant output signal settings. If there are no non-redundant output settings the


71

metric is zero. The maximum function in the denominator of the formula for t6 is used to avoid an undefined result in the case that there are no output assignments at all in the SIPN.

Example:

t6(SIPN1) = 1 (there is no redundant output setting in the net) t6(SIPN2) = 0.54 (as shown below)

To further explain the notion of outputs in RGSIPN vs. outputs in markings, we take the marking m1 in SIPN2 (cf. Figure 5-3). In this marking all output signals are formally correct (i.e. 0 or 1). The marked places are p2 and p5. To calculate t6 we check for every output signal how often it is as-signed a value under this marking:

For o1, o2, and o4 we find one assignment (p2); o3 and o5 are assigned two values (p2, p5). In sum, we get for m1 3 formally correct defined non-redundant output signals (o1, o2, o4) but 7 assignments (1 for o1, 1 for o2, 2 for o3, 1 for o4, 2 for o5). For the other markings we get m0: 5/5; m2: 3/7; m3: 3/7. This results in t6(SIPN2) = (5 + 3 + 3 + 3) / (5 + 7 + 7 + 7) = 14/26.

5.3.5 Visible Dynamics (P4)

If an SIPN is safe, the post-places of a transition need not to be checked to determine if the transi-tion fires. For the transparency criterion t7 a completely new definition is used. The version pre-sented in [Frey and Litz 2000 (a)] allows only a binary statement. The new definition, presented here, relates the number of unsafe states reachable from states in the SIPN’s reachability graph, to

the number of reachable states plus the unsafe ones, i.e. the share of unsafe states in aRGSIPN.

Definition 5-7: Transparency Metric t7 (Safety)

SIPN

SIPN7 aRGin States #

aRGin States Unsafe#1t −=

The metric is one if there are no unsafe states in aRGSIPN. The value of zero can only be reached in

the limit because at least the initial state is by definition safe. Since the initial state is always reach-able in SIPN, the denominator of the formula for t7 is always greater than zero.

Example:

t7(SIPN1) = 1 (there are no unsafe states in aRGSIPN) t7(SIPN2) = 0.8 (1 out of 5 states in aRGSIPN is unsafe)

Dynamic Synchronization (DS) leads to transient states and hidden synchronization. Furthermore, it is caused by redundancies as discussed in Sub-Section 5.3.4. The amount of DS can be measured by the number of additional arcs introduced in RGSIPN that are not part of RGPN(SIPN).

Definition 5-8: Transparency Metric t8 (No Dynamic Synchronization)

( ) RGin Arcs #1,max

RGin DS todue Arcs #1t

SIPN

SIPN8 −=

5 Evaluation

72

The metric is one if there are no arcs due to DS and zero if all arcs in RGSIPN are caused by DS. The maximum function in the denominator of t8 is necessary because the number of arcs in an SIPN’s reachability graph may be zero.

Example:

t8(SIPN1) = 1 (there are no arcs due to DS in the reachability graph) t8(SIPN2) = 0.57 (3 of 7 arcs in RGSIPN are caused by DS; arcs caused by DS are drawn with a

dashed line in Figure 5-3)

5.3.6 Complexity (P5)

The development of complexity metrics for SIPN started with the investigation of known complex-ity metrics from Computer Science. All metrics surveyed in [Höcker et al. 1994] have been studied and the ones that seemed appropriate have been adapted to the SIPN framework. As a result, two

criteria for transparency are derived, the Net Complexity and the Expression Complexity. The met-rics are introduced here for SIPN. Yet, their application is not restricted to SIPN. The net complex-

ity can be calculated for all types of PN and even for similar formal descriptions as Sequential Function Chart according to IEC 61131-3 standard or Grafcet, because it only evaluates structural

properties of the PN and its reachability graph. The expression complexity naturally is restricted to PN with expressions as firing conditions.

[Rechenberg 1986] defined the measure Expression Complexity to evaluate the complexity of logi-cal expressions. This measure can be applied to the Boolean expressions used as firing conditions in SIPN. The expression complexity ec(ti) of a transition ti, is given by the sum of all the expression complexities of the elements of its firing condition according to Table 5-1. In addition, for each term in brackets the complexity value of the bracketed term is multiplied by 1.5.

Elements Expression Complexity Input Signal

Not

And, Or

NAND, NOR

0

1

2

3

Table 5-1: Expression complexity of firing conditions

The expression complexity ECSIPN of an SIPN is the ratio of the expression complexity ec(ti) of all

its transitions to the number of transitions

Definition 5-9: Expression Complexity ECSIPN

( )sTransition #

tecEC

T

1i i

SIPN

∑ ==

In [Frey et al. 2000] the corresponding transparency metric tEC is defined via a decreasing exponen-

tial. However, a look at common firing conditions shows that conditions with ec ≤ 3 are simple


73

whereas ec ≥ 5 requires some thinking. Thus, we choose an easier linear function: First EC is lim-

ited to the interval [3, 5] and then this interval is linearly mapped to the interval [0, 1]. The result is

of this transformation is a metric for complexity. Since high complexity results in low transparency the corresponding transparency metric is derived by subtracting the complexity metric from one

Definition 5-10: Transparency metric t9 (Low Expression Complexity)

( )( ) 2

3-3,5EC,minmax1tt EC9 −==

The metric is one if the average expression complexity of the firing conditions is smaller or equal 3, it is zero if this average is greater or equals five.

Example:

EC(SIPN1) = (ec(t1) + ec(t2) + ec(t3) + ec(t4) + ec(t5)) / 5 = (6 + 3 + 2 + 7 + 2) / 5 = 4 EC(SIPN2) = (ec(t1) + ec(t2) + ec(t3) + ec(t4) + ec(t5)) / 5 = (3 + 5.5 + 0 + 4 + 4) / 5 = 3.3 t9(SIPN1) = 0.5 t9(SIPN2) = 0.85

To get a measure for the structural complexity of an SIPN, four known complexity measures from Computer Science are adapted to SIPN and combined in a weighted sum. The measure Net Com-

plexity (NC) is composed of the measures: Structural Complexity of SIPN (SCSIPN), Hierarchical

Complexity of SiPN (HCSIPN), Unstructuredness of SIPN (MCCSIPN), and Branching of SIPN (BSIPN). These four components rate different aspects of the structure of an SIPN and their combination

gives a good coverage of the varying aspects of structural Petri Net complexity. The four compo-nents are combined in a weighted sum to give the complexity measure NC (Net Complexity).

SIPN allow the structuring of an algorithm into independent modules on different hierarchical lev-els. In [Zuse 1998] two metrics are given to measure the complexity of modular hierarchical struc-tures in flowcharts: the Structural Complexity and the Hierarchy of Complexity. These metrics are

easily adapted to SIPN. The Structural Complexity of SIPN (SCSIPN) rates the complexity of the SIPN structure. The structural complexity decreases if independent parts of the program are

grouped into modules. SCSIPN relates the number of arcs in a PN to the number of modules. In a hi-erarchical SIPN the main net and each subnet are counted as a module. For flat SIPN the number of

modules is one. test

Definition 5-11: Structural Complexity of PN

==

=SIPN in the modules ofnumber M

SIPN in the arcs ofnumber with

MSCSIPN

FF

Example:

SCSIPN(SIPN1) = 12 SCSIPN(SIPN2) = 12 (both SIPN have 12 arcs and only one module)

5 Evaluation

74

The measure Hierarchical Complexity of SIPN (HCSIPN) relates the number of modules in an SIPN to the depth of the hierarchical structure (number of levels).

Definition 5-12: Hierarchical Complexity of SIPN

==

=SIPN in the levels theofnumber L

SIPN in the modules ofnumber Mwith

L

MHCSIPN

Example:

HCSIPN(SIPN1) = HCSIPN(SIPN2) = 1 (both SIPN have only 1 module)

The measure Unstructuredness of SIPN, denoted by MCCSIPN, is based on the measure Unstruc-

turedness of Flowgraph by McCabe [McCabe 1976]. This measure evaluates the number of mod-ules, cycles, and decision places.

A cycle in an SIPN is a sequence of arcs (p0, t0), (t0, p1), (p1, t1), (t1, p2),..., (pn - 1, tn - 1), (tn – 1, pn) and pn = p0. Two cycles are equal if they contain the same arcs.

Places with two or more output arcs are called decision places. The weighted sum |DP| counts each

decision place with the number of its output arcs |pi•| minus one.

Definition 5-13: Unstructuredness of SIPN

MCCSIPN = |DP| - M + C + 1 with:

( )∑ =−•= P

1P 1Di ip the weighted number of decision places in a SIPN,

M = number of modules in an SIPN, and

C = number of cycles in an SIPN.

Example:

SIPN1 in our example (cf. Figure 5-2) contains one decision place, place P2, with two output arcs.

Hence, |DP| = 1 holds. There is only on module, the main SIPN (M = 1). The net owns three cycles: (p1, t1, p2, t2, p3, t3, p4, t4, p1), (p1, t1, p2, t5, p4, t4, p1), and (p1, t1, p5, t4, p1). The combination results in

MCCSIPN(SIPN1) = 4 for the example. For SIPN2 we get MCCSIPN(SIPN2) = 5

The measure Branching is based on the measure ε introduced in [Gong and Schmidt 1985]. It rates

the nesting degree of a graph G. The measure relates the weighted sum of decision vertices of all subgraphs of a SIPN reachability graph to the weighted sum of decision vertices in the reachability graph. If there are no decision vertices, then BSIPN is zero.


75

As with decision places in SIPN, in general a vertex of a graph is called decision vertex, if it has two or more output edges. For a graph G = (V, E) the weighted sum of decision vertices is defined

as ( ) with ,1D1V •−•= ∑ = ii i vv

Vthe number of output edges of a vertex vi.

Based on decision vertices, subgraphs in a graph can be identified. Elements of a subgraph RGU are

a decision vertex and all vertices and edges after the decision vertex. The subgraph ends if a termi-nal vertex, the vertex corresponding to the initial marking or a vertex that is already part of RGU is reached.

Definition 5-14: Branching

( )( ) ( )

( )

=

>=

∑ =

0RGD if,0

0RGD if,RGD

RGD

B

V

VV

1 UiV

SIPN

k

i

with k, the number of subgraphs RGU in RGSIPN.

Example:

The reachability graph of SIPN1 in Figure 5-2 contains one decision vertex (m1). Starting from m1 two subgraphs can be built: RGU1 = (m1, m2, m3, m0, (m1, m2), (m2, m3), (m3, m0)) and RGU2 = (m1, m3, m0, (m1, m3), (m3, m0)).

Since m1 is the only decision vertex and it is contained in the main graph as well as in both sub-graphs,

BSIPN(SIPN1) = 2 results. For SIPN2 we get BSIPN(SIPN2) = 2.33.

The combined complexity measure Net Complexity (NC) is the sum of the four measures presented above.

Definition 5-15: Net Complexity (NC)

NC = SCSIPN + HCSIPN + MCCSIPN + BSIPN

Example:

NC(SIPN1) = 12 + 1 + 4 + 2 = 19 NC(SIPN2) = 12 + 1 + 5 + 2.33 = 20.33

To derive a transparency metric from NC, the measure has to be mapped to the Interval [0, 1]. Fur-thermore it has to be considered that high complexity means low transparency. The following defi-nition was introduced in [Frey 2001 (c)]. It differs from the one initially given in [Frey et al. 2000]

5 Evaluation

76

because experience showed that the numerical values for the constants in the transformation had been chosen too small.

Definition 5-16: Transparency metric t10 (Low Net Complexity)

( )( ) 75

25-25,100NC,minmax1tt NC10 −==

The metric is one if the Net Complexity is smaller or equal 25 and zero if NC is greater or equal 100.

Example:

Both SIPN in our example are not very complex (NC < 25):

t10(SIPN1) = 1 t10(SIPN2) = 1

5.3.7 Combination to one Transparency Metric

Based on the type of property they measure, five types of transparency criteria can be distinguished. The criteria are summoned in Table 5-2 and grouped according to the corresponding informal prop-erties P1 to P5 given in Section 5.2. The overall transparency metric T is derived by calculating the weighted sum:

∑

∑

=

=⋅

= 10

1

10

1it

T

ii

ii

c

c

Using the weighting factors ci, this transparency metric can be adapted to the specific type of algo-rithm under evaluation.

Example:

For the calculation of T we choose ci = 1 for all i, this results in:

T(SIPN1) = 0.95 T(SIPN2) = 0.69


77

Type # Criterion Explanation and Metric

Comments

(P1)

t1 Comments Comments naturally lead to better understanding.

sTransition# Places #

Comments #t1 +

=

t2 Directional-ity

The control flow should follow a preferred direction.

Arcs #

DirectionPreferredinArcs #t 2 =

Graphics

(P2)

t3 No Intersec-tions

Intersecting arcs hinder understanding.

SIPNin Arcs #

SIPNin Arcs dIntersecte #1t 3 −=

t4 No Redun-

dant input signals

A defined input signal should influence the controller.

SignalsInput #

SignalsInput Redundant #1t 4 −=

t5 No Redun-dant output signals

An output signal should not be constant.

SignalsOutput #SignalsOutput Redundant #

1t5 −=

Redundancies

(P3)

t6 No Redun-dant output

settings

Outputs should only be set by one place at a time.

( )Markings SIPNin sAssignmentOutput #1,max

RGin SettingsOutput redundant -nonCorrect Formally #t SIPN

6 =

t7 Safety In a safe net, the enabling of a transition is easier to see.

SIPN

SIPN7 aRGin States #

aRGin States Unsafe#1t −=

Visible Dynamics

(P4)

t8 No Dynamic

Synchroni-zation (DS)

DS leads to transient states and hidden synchronization.

( ) RGin Arcs #1,max

RGin DS todue Arcs #1t

SIPN

SIPN8 −=

t9 Low Ex-pression Complexity

EC

EC measures the complexity of the firing conditions.

( )( ) 2

3-3,5EC,minmax1t9 −=

Complexity

(P5)

t10 Low Net Complexity NC

NC combines several complexity measures from Computer Sci-ence.

( )( ) 75

25-25,100NC,minmax1t10 −=

Table 5-2: Grouping of the transparency criteria.

5 Evaluation

78

For the visualization of the transparency metrics a diagram according to Figure 5-4 is used. The number in the center of the diagram is the overall transparency T. The single criteria are marked on a radial scale running from zero on the innermost circle to one at the outer edge. The figure result-ing from connecting these points gives a fast visual impression on where the transparency could be improved. In a colored version of this diagram there is a shading from red in the middle to green at the outer circle, this further improves the visual effect: Whenever the red background gets visible, there is a need to improve the transparency in this specific direction.

t2

T

t3

t4

t5

t6 t7

t8

t9

t10

t1

Figure 5-4: Visualization of transparency metrics: Transparency diagram.

For the two SIPN examples used throughout this Section the visualization of the transparency is shown below. We can conclude that SIPN2 is less transparent than SIPN1. Therefore, we expect that it is harder to understand. From the transparency diagram, we further see that the most im-

provement on SIPN2 could be made in the area of comments and graphics. A comparison of this re-sults with the two SIPN shows that the conclusions are in fact valid.

t1 = 1

t2 = 1

t3 = 1

t4 = 1

t5 = 1

t6 = 1

t7 = 1

t8 = 1

t9=0.5

t10 = 1

0.95

t1 = 0.3

t2 = 0.46

t3 = 0.75

t4 = 0.8

t5 = 0.8

t6 = 0.54

t7 =0.8

t8 = 0.57

t9 =0.85

t10 = 1

0.69

SIPN1 SIPN2

Figure 5-5: Transparency diagrams for the example.

5.4 Conclusions

79

5.4 Conclusions

In this Section, non-functional properties for logic control algorithms are defined. For SIPN a for-malization of these properties leads to the definition of ten transparency metrics. These metrics are combined to an overall metric. A transparency diagram for the visualization of this multi-dimensional metric is introduced and methods to evaluate the metrics are presented and illustrated at an example.

With the formally defined transparency metric, the non-functional properties are pre-formalized. Hence, the evaluation process depicted generally in Figure 5-1 is reduced to the much easier evalua-tion process for SIPN shown in Figure 5-6.

The definition of the presented metrics is in some parts based on known metrics from Computer Science and in others on experience with the SIPN approach. To prove that the presented metrics

really measure what they are intended to, namely the understandability of an algorithm, an experi-ment was performed. This experiment is discussed in detail in the following Chapter.



Transparency Metrics

(Pre-Formalized Non-Functional

Properties)


of the Control

Algorithm as SIPN

Transparency Analysis(Evaluation using the

SIPN and the Reachability Graph)

Selection and Weighting


(Design)

Correction(Design-

Improvement)

Evaluation Result:


more or less





Transparency Metrics

(Pre-Formalized Non-Functional

Properties)


of the Control

Algorithm as SIPN

Transparency Analysis(Evaluation using the

SIPN and the Reachability Graph)

Selection and Weighting


(Design)


(Design)

Correction(Design-

Improvement)

Correction(Design-

Improvement)

Evaluation Result:


more or less



Figure 5-6: Evaluation process for SIPN.

81

6. Experimental Validation of the Transparency Metrics

6.1 Design of Software Engineering Experiments

Transparency is proposed as a metric to measure the ease of understanding of an SIPN algorithm. In order to show the validity of the proposed transparency metric an experiment was performed. This experiment is a Software Engineering experiment because it involves the measurement of the per-formance of people during their work with pieces of software. In the following the acronym EVTM is used for the Experiment for the Validation of Transparency Metrics.

Experiments in Software Engineering differ considerably from experiments in other engineering disciplines. In fact, they are closely related to experiments in the social sciences. This is due to the prominent influence of human factors on the outcome of the measurements. In this Chapter basic concepts and terminology of Software Engineering experiments are reviewed and the EVTM is de-scribed in this context.

The experimental paradigm in Software Engineering is described by one of its first and mayor pro-ponents [Basili 1993] in the context of other scientific paradigms as follows: In contrary to deductive paradigms like for example the mathematical paradigm, experimental scientific paradigms are in-ductive. This means the general procedure consists of the steps: Observation of (a specific part of) the world, proposition of a model or theory of its behavior, measurement and analysis, validation of hypotheses of the model or theory, and, if possible, repetition of this procedure. Basili distinguishes two experimental methods within this paradigm, the engineering method and the empirical method. Although they are similar, they tend to emphasize different things.

• The engineering method is an approach for evolutionary improvement. It starts by observing ex-isting solutions, proposes better solutions, and evaluates the improvement by experiments. An example for the application of the engineering method in Software Engineering is the demon-stration that some tool performs better than its predecessor.

• The empirical method is an approach orientated towards revolutionary improvement. It starts by

proposing a new model, not necessarily based on an existing one, and attempts by experiment-ing to study the effects of the process or product suggested by the new model.

In the engineering as well as in the empirical method, experiments with careful measurement and analysis are crucial for the success. EVTM is an experiment following the empirical method, be-cause the improvement of controller software by transparency is a completely new concept. The de-sign of an empirical study like this consists of the four phases:

1. Definition,

2. Planning,

3. Operation, and

4. Interpretation.

The following sections explain these phases and illustrate their application in EVTM.

6 Experimental Validation of the Transparency Metrics

82

6.2 Definition Phase

An experiment is defined by six aspects: Motivation, object, purpose, perspective, domain, and scope [Basili et al. 1986]. The motivation of a study is the answer to the question „Why do we per-form the study“. It may be, for example, to understand and improve the effects of a new technology. The object is the primary entity examined in the experiment, like for example the generated soft-ware product or the process of its generation. The purpose of a study is the answer to the question „What do we want to achieve by performing the experiment“. This may be to evaluate the effec-tiveness of a new method or to motivate the application of a new theoretical concept. The interpre-tation of the results depends on the chosen perspective. While for example quality of software for a developer includes correct documentation of the code, the ease of use is more important for the user. The domains that are of interest in Software Engineering experiments are the individual pro-grammer or programming teams and programs or projects. Depending on the size of these domains

a classification of an experimental study’s scope is obtained. Table 6-1 gives an overview of the possible experimental setups depending on the number of teams and projects involved.

Number of projects

one more than one

one Single project (case-study) Multi-project variation Number of teams

more than one Replicated project Blocked subject-project

Table 6-1: Classification of Experiments depending on the number of teams and projects involved.

A team is a group of people working independently from other teams. Depending on the type of problem, experiments can also be performed with single persons instead of teams. In the following, we assume that the term team includes one-person teams. A project is a single problem that is inves-tigated by the team.

• In a single project one team works on one project. Usually this has the character of a case study. This means, that there are only small possibilities to manipulate and vary the independent vari-

ables. Such a case study often serves as preliminary study before a larger scale experiment with higher expenditure is going to be performed. Another application of case studies are experi-

ments designed to test whether results found in a study with multiple small projects scale up to projects of real-life size.

• In a multi-project variation one team works on more than one project. In this type of experi-ment, care has to be taken in comparing results from the different problems. It is rather difficult, because the people gather experience with each project performed.

• In a replicated project more than one team works on the same project independently. Reaching comparability between the teams according to their relevant abilities is rather difficult.

• In a blocked subject-project or formal experiment more than one team works on more than one project. If it is possible to manipulate and vary the independent variables in a rather high amount, the study is called controlled experiment.

6.3 Planning Phase

83

In the definition phase of an experiment the aim of the experiment has to be formulated, and one of the presented experiment types has to be chosen. As an aid to the complete definition, Table 6-2 is used. It summarizes the six main aspects of an experiment.

Motivation Object Purpose Perspective Domain Scope

Understand

Assess

Manage

Engineer

Learn

Improve

Validate

Assure

Product

Process

Model

Metric

Theory

Characterize

Evaluate

Predict

Motivate

Developer

Modifier

Maintainer

Project manager

Corporate manager

Customer

User

Researcher

Programmer

Program/project

Single Project

Multi-project

Replicate project

Blocked subject-project

Table 6-2: The six parts of an experiment definition following [Basili et al. 1986].

In Table 6-2 the terms defining EVTM have been underlined. Formulated into complete sentences we derive the following definition for the experiment:

Definition 6-1: Experiment for the Validation of Transparency Metrics (EVTM)

EVTM is designed to validate the proposed transparency metric, in order to motivate its use by

developers of logic control algorithms. The analysis should be independent of the programmer

and the program. Therefore, a blocked subject-project experiment is appropriate.

A detailed definition like this is of great value during the design of the experiment because it can serve as an aid in the multiple decisions to be made during the planning phase. It is in a way like the mission statement of a company, something you can look up if you are stuck deep in the details and need to see the great picture and your place in it.

6.3 Planning Phase

6.3.1 Formulation of the Aim of the Experiment

The first step in order to draw up a detailed experiment plan is the clear formulation of its aim. At first, this formulation is quite informal in the sense that there is no explicit definition of variables that could be set or measured:

Definition 6-2: Aim of EVTM (informal)

EVTM is designed in order to show that for a control engineer familiar with the SIPN method: 1. increasing transparency of an SIPN leads to faster and better understanding of the algorithm, 2. the theoretical concept of transparency resembles what the user of this design method quali-

tatively denotes as the „ease of understanding“ of an SIPN. This means an SIPN with high

transparency is easy to understand.


84

The aim stated above is not in a form that can be tested by an experiment. To reach a testable de-scription, explicit hypotheses have to be formulated. In formulating hypotheses, the following points have to be considered [Atteslander 2000]:

• A hypothesis is a statement, no question or command.

• The statement contains at least two semantically rich terms.

• The statement is not tautological, i.e. no term does fully, semantically cover the other.

• The statement is not contradictory, i.e. one term does not semantically exclude the other.

• The bounds of empirical validity are listed implicitly or explicitly.

• The terms can be related to phenomena in reality.

• The statement can be falsified.

Considering this, four hypotheses to be checked in EVTM are formulated:

Definition 6-3: Hypotheses to be checked in EVTM

If we ask a control engineer who is familiar with the SIPN method questions on an SIPN algo-rithm we expect the following:

H1: Higher transparency leads to more correct answers.

H2: Higher transparency results in less time to answer the questions.

H3: With higher transparency, the number of correct answers increases while the time to give those answers decreases at the same time.

H4: With higher transparency values assigned by the proposed metric, the transparency value

assigned to an algorithm by the candidates increases.

Hypotheses H1 and H2 are the reformulation of the first sentence in the informal description above (Definition 6-2), while Hypothesis H4 describes the second sentence. Hypothesis H3 seems to be

redundant because it is the combination of H1 and H2. This, however, is not the case because of the statistical nature of the hypothesis. Table 6-3 shows an example of two hypotheses that are accepted

while the combined hypothesis is rejected.

Result 1 Result 2 Result 3 Average Decision

Hα Yes Yes No 67% Yes Accept

Hβ No Yes Yes 67% Yes Accept

Hα AND Hβ simultaneously No Yes No 33% Yes Reject

Table 6-3: Example for the rejection of the combination of two accepted hypotheses.

From the formulated hypotheses, the variables of the experiment are clear to see. The independent (manipulated) variable is the (theoretical) transparency. The dependent (measured) variables are the number of correct answers, the time to give those answers, and the subjectively felt transparency.

Furthermore, we conclude that the actual study belongs to the category controlled experiment, be-cause the independent variable could be controlled to a high extend in an exact way.

6.3 Planning Phase

85

Given the definition of the experiment, the hypotheses to test and the variables involved, the follow-ing basic design for EVTM is the one, which is the most appropriate to check the hypotheses. In a first step, SIPN algorithms that differ only in their transparency value are designed. In a second step, control engineers are asked questions on these algorithms and the time they need to answer the questions as well as the number of correct answers is noted. In addition to that, the test persons are asked to assign a number between zero and one to each of the algorithms where one should mean this algorithm was very easy to understand and zero means it was hardly to understand at all. This number is noted as the subjective transparency.

6.3.2 Assignment of Test Candidates to Groups

In experiments like EVTM that use test persons it is important to have a large number of test per-sons and to devise them in several groups. At least two groups are needed in order to allow com-parative analysis. In EVTM three groups (A, B, and C) were built.

The number of test persons depends on the number of persons for which the result of the test should be valid and on how different these persons are. The more general this group is the more test per-sons are needed. If on the other hand the results should be valid only for control engineers, like in EVTM, the selection of test persons can also be restricted to control engineers.

The following methods are designed to minimize the influence of human factors on an experiment, [Fenton and Pfleeger 1996]: Randomization, blocking, and matching.

Randomization is the random assignment of participants to groups. The averaged results of the groups are comparable because the random assignment of a large number of persons results in the equal mix of abilities of those persons in the groups.

Blocking is used if factors that influence the result of the experiment are known, as for example the

age, gender, or educational background of the candidates. Similar candidates are grouped in blocks. The candidates of the different blocks are then assigned in the same numbers randomly to test groups. By this procedure it is assured, that each test group contains nearly the same number of candidates with a given important feature.

Matching is the most complicated method of assignment. Here each person of a group is associated

with a similar person of another group. The measurement of the variables at these coupled persons can be compared. Matching requires a large amount of pre-testing in order to find out which per-sons are similar in the features that are important for the experiment.

To set the number of test persons is also a complicated task. In addition to the theoretical problem, in most cases this number is limited by economical or practical constraints. For EVTM it was tried

to recruit as many test persons as possible. The number was however constrained by two factors. First, the persons have to know the SIPN method, which narrows the possible participants down to students that took a course on digital process control. In addition to this, the experiment had to be performed during one semester. Therefore, only the members of the course on digital process con-trol at the University of Kaiserslautern in the winter term 1999/2000 and the members of a Summer Courses on the same topic at the University of Bandung could be asked. Overall, 28 persons took


86

part in the experiment. The results of one subject could not be used because no times have been noted on the result sheet. This leaves us with 27 subjects divided in three groups.

In EVTM a randomized block assignment was used. The blocks were given naturally by the way

the experiment was performed. The experiment was carried out three times with different people:

• First run (pre-experiment): Three members of the Institute of Automatic Control at the Univer-

sity of Kaiserslautern experienced in the use of SIPN (Block P).

• Second run: Fifteen students of a Summer Course on digital process control held at the Univer-sity of Bandung, Indonesia (Block B).

• Third run: Twelve students of a regular course on digital process control held regularly at the University of Kaiserslautern, Germany (Block G).

A forth run of the experiment (actually the second in the timeline), done in Bandung, could not be

evaluated. Due to technical problems, this experiment was not done by single students but in groups. This led to results, which are not comparable with the other three runs of the experiment,

especially in the time needed to solve the problems.

The people who took part in the three runs of the experiment differ in their general educational background and especially in their experience with the SIPN approach. Therefore, the members of

the three runs are seen as blocks. The assignment of the candidates inside each block to one of the three groups was done randomly by the random distribution of working sheets. The members of

each block have been distributed evenly over the three evaluation groups. Figure 6-1 illustrates the randomized assignment of the members of the three blocks to the three groups.

Block I # = 13

Block P

# = 3

Block G # = 11

Group A # = 9

Group B # = 9

Group C # = 9

Random Selection

1 of 3

1 of 3

1 of 3

5 of 13

4 of 13

4 of 13

3 of 11

4 of 11

4 of 11

Figure 6-1: Randomized block assignment in EVTM

6.3 Planning Phase

87

6.3.3 Assignment of Projects to Groups

The participants received different modifications of the SIPN representation of a control algorithm, with a set of questions on the algorithm. Each problem existed in three versions (h, m, l). The dif-ference between them was the transparency of the controller (h = high, m = medium, l = low).

Five different problems have been designed for EVTM to cover different aspects of control algo-rithms and different aspects of the transparency metric (cf. Table 6-4):

The heating tank problem, the compressed air accumulator, and the dissolving tank problem repre-sent typical applications in process industry whereas the positioning table problem and the trans-porting device are examples from discrete manufacturing.

In the heating tank and the dissolving tank problem all aspects of the transparency metric are varied

while in the three remaining problems the variation is focused on special aspects.

Problem Application Area Variation in Transparency

Heating Tank Process All aspects

Compressed Air Process Dynamic aspects and Complexity

Dissolving Tank Process All aspects

Transporting Device Manufacturing Comments

Positioning Table Manufacturing Directionality

Table 6-4: The five control problems used in the experiment.

The three versions of each of the five problems result in fifteen different projects. The basic idea for the assignment of projects to the groups is to have the same problem with different transparency at the same time (cf. Figure 6-2). This allows comparing the performance of the teams depending on the transparency. A comparison between results of Group A in Project 1 to the results of Group B in Project 9 would not be valid because of the increasing experience gathered by Group B through

solving the first eight projects. A possible analysis would be to compare the results of the three groups in the first project (heating tank). This leads to a comparison of the results in the same prob-

lem with different transparency values.

The second idea guiding the assignment is to have each group working through the different ver-sions of one problem. This results in more data and allows averaging out the effects of increasing

experience in the later analysis. A possible analysis would be to compare the results reached for the different versions of a problem averaged over the three groups.

To reduce the effect of carrying over results from the first version of a problem to the second or the third the time between those problems is maximized under the given restrictions and the questions posed on the problem are given in a different order. However, two of the problems (transporting de-vice and positioning table) are so easy that even these means would not avoid that the candidates remember their earlier results. Hence, these problems are presented in only one version to each

group.


88

The two basic ideas presented above leave us with eleven problems to be assigned to the groups. Maximizing the time between different versions of one problem while assigning different versions of one problem to the three groups at the same time leads to the assignment shown in Figure 6-2. (Of course, there is a multitude of other assignments in accordance with the presented design ideas.)

A B C

1

2

3

4

5

6

7

8

9

10

11

Heating Tank

Compressed Air Accumulator

Dissolving Tank

Transporting Device

Positioning Table

High

Medium

Low

Group

#

Type of Problem

Transparency of the Problem

Assignment of Projects to Groups

Figure 6-2: Assignment of projects to groups in EVTM.

6.4 Operation Phase

6.4.1 Aspects of an Experiment’s Operation

The third phase of an experiment is the actual operation. It consists of preparation, execution, and analysis (cf. Table 6-5).

Preparation Execution Analysis

Pilot study Data collection

Data validation

Quantitative vs. Qualitative

Preliminary data analysis (plots and histograms)

Primary data analysis (model application, hypothesis testing)

Table 6-5: Aspects of the operation phase of an experiment.

6.4 Operation Phase

89

Prior to the actual study, involving a lot of test persons, a pilot study or pre-experiment can help to check the experiment’s feasibility. For example, the comprehensibility of the prepared test material or the validity of assumptions about the time needed for the experiment.

In EVTM a pre-experiment with three candidates was performed. The pre-experiment showed that it is possible to work through the problems in the proposed two hours and that the questions have

been in general understood correctly by the candidates. Since the test material was not essentially changed after the pre-experiment, the results of the three candidates could be included in the later analysis.

The execution of the experiment may include several runs in collecting data and the validation of the collected data. In EVTM three runs of the experiment were performed with different test per-

sons. The evaluation of the test-sheets was validated in several correction turns. Additionally the data was analyzed for outliers.

In general, the analysis of empirical studies is based on means of the collected data. The building of

means is used to level out the human factors in the experiment. The statistical methods used in em-pirical experiments differ in the assumptions they make about the underlying population (e.g. nor-

mal distribution) and on the kind of data they can handle.

In EVTM two types of analysis are applied. The correlation analysis serves as preliminary analysis method. It shows whether there is a statistical connection between the dependent and the independ-

ent variables and allows the graphical illustration of this connection. For the primary analysis the sign-test is used to test the hypotheses formulated in Definition 6-3. Using the t-test prior to the sign-test to filter out significant data points further adds to the statistical validity of the results. In the following Sub-Sections the different steps of analysis and the corresponding results are pre-sented in detail.

6.4.2 Identification and Treatment of Outliers

Before any statistical analysis is performed, the data has to be analyzed for outliers. For the term „outlier“ at best subjective definitions exist [Tietjen 1986], as for example „An outlier is a data point that appears to deviate markedly from other members of the sample“. An outlier is either a contaminant or a discordant observation. A discordant observation is one that appears surprising or discrepant to the investigator. A contaminant is one that does not come from the target population.

In EVTM there can be no contaminant observations. However, the data contains values that are sur-prisingly far off the other values. Hence, there are discordant observations.

The first step in dealing with outliers is to properly identify them. If the outliers are detected, they

may be treated in two ways:

1. Omission of the outliers and treatment of the reduced sample as „new“ sample.

2. Winsorization of the outliers, i.e. replacement of outliers with the value of the nearest „good“ observation. This at least preserves the direction of the measurement and the sample size.


90

To check if the treatment of outliers has a mayor effect on the experiment's outcome, the further analysis should be carried out for both sets of data (the one with the outliers and the one with the winsorized or omitted outliers). If the result of the analysis of the two data sets differs only in mag-nitude, there is no problem. If, however, the treatment of outliers changes the result of the experi-ment completely, then a new measurement should be made to clear the differences.

In EVTM we have a maximum sample size of nine. Therefore, we check only for one single outlier. If xi is the single largest suspect value, we calculate the test statistic Tn = (xi - mx)/s. For the single

smallest suspect value xi the test statistic is Tn = (mx - xi)/s. If Tn is larger that the critical value T(n,α)

tabled by Grubbs for different sample sizes n and different error probabilities α [Tietjen 1986] than

xi is not regarded as being part of the underlying normal population.

As an example from EVTM, the subjective transparency given by the members of Group A in Prob-lem 8 is taken:

TSub = (0.9, 1.0, 0.9, 0.8, 0.8, 0.6, 0.8, 0.1), with mean m = 0.74, and variance s2 = 0.08

For this sample Tn = 2.26 > T(8, 5%) = 2.03 holds. This means that the smallest value (0.1) is an out-

lier. The nearest „good“ value is 0.6. Therefore, winsorization results in the new sample

*TSub = (0.9, 1.0, 0.9, 0.8, 0.8, 0.6, 0.8, 0.6), with mean m = 0.80, and variance s2 = 0.02

The EVTM data was analyzed for outliers with 5% error probability. It shows that in the 99 data samples there are 10 containing an outlier. These outliers are winsorized before further analysis. In order to see how the outlier treatment influences the results, the rest of the analysis in EVTM was

done twice, once on the original data and once on the data with winsorized outliers.

6.4.3 Preliminary Analysis: Correlation Analysis

A standard statistical approach to measure the influence of an independent variable on dependent variables used in engineering is the analysis of correlation [Bosch 2000, Chapter 10]. The analysis of correlation works on numerical, ordinal data. The correlation coefficient between two variables is

a measure for their linear dependence. The use of correlation analysis in the strict sense is disput-able in EVTM because of the small number of samples. Nevertheless, it gives a visible result that

helps to underline the results of later hypothesis testing.

While the values for the transparency lie by definition between zero and one, the values for points and time have their maximum near thirty. To get comparable values for the different measured vari-ables and to allow the drawing of combined diagrams the data is scaled by dividing points and time by thirty. The scaling has no influence on the correlation coefficient.

To test the combined hypothesis H3 in correlation analysis a function that gives a numerical value for the statement „Points go down and Time goes up at the same time“ has to be found. Candidates are, within others:

f1(Points, Time) = Points/30 (1 – Time/30)

f2(Points, Time) = Points / Time

f3(Points, Time) = Points – Time

6.4 Operation Phase

91

We choose f1 because it resembles the nearest translation of the verbal statement into a mathemati-cal function. The results for the other two functions are similar (the results for f2 are slightly worse, while those for f3 are nearly identical).

The results of different problem types in EVTM are not comparable in their absolute values because they are influenced by other problem specific factors as for example the complexity of the posed

questions. Correlation analysis deals with ordinal data. Therefore, it can only be applied to single problems in EVTM. However, due to the design of the experiment, the results of the different ver-sions of one problem can be combined. For example the mean time needed by the candidates for the solution of the heating tank problem with low transparency is given by the mean of averaged times needed by the three groups for the problem (Problem 1 of Group C, Problem 5 of Group A, Prob-lem 9 of Group B).

The results of the correlation analysis are shown in Table 6-6. The measured data is summoned in [Frey 2001 (c), Table 15 in the Appendix]. For each problem type the correlation coefficient r be-tween the Theoretical Transparency and the dependent variables together with the corresponding number of data in the sample is listed. The last two columns of the table contain the arithmetical mean of the correlation coefficient for the respective variables and the weighted mean. The weighted mean is derived by weighting the single correlation coefficients with the number of data used to calculate them.

Heating Tank

Dissolving Tank

Compressed Air

Accumulator

Transport-ing

Device

Positioning Table

Mean

Weighted Mean

r # r # r # r # r # rm rmw

Points/30 0.96 69 0.98 72 0.97 69 0.81 23 0.93 22 0.93 0.95

Time/30 -0.99 69 -0.97 72 -0.81 69 -0.99 23 -0.91 22 -0.93 -0.93

Point/30*(1-Time/30) 0.98 69 0.93 72 0.96 69 0.94 23 0.90 22 0.94 0.95

Transparency 0.98 67 0.90 68 0.83 67 0.82 23 -0.79 20 0.55 0.76

Table 6-6: Correlation Coefficients in EVTM (boldface for values |r| ≥ 0.9, italics for „surprising“ values).

Figure 6-3 shows graphs of the measured variables (and the auxiliary variable) over the Theoretical Transparency for all five problem types. A comparison of Table 6-6 and Figure 6-3 illustrates the concept of correlation analysis: The correlation coefficient is high (near one or near minus one for Time) if the data can be approximated by a linear function. There is a very high correlation between Theoretical Transparency and Points, Theoretical Transparency and Time (negative), and between Theoretical Transparency and the combination of Points and Time. The Correlation between Theo-retical and Subjective Transparency is not that high but in the (weighted) mean still in accordance with what was expected. There is only one correlation coefficient that is not in accordance with what was expected: The correlation between theoretical and subjective transparency for the posi-tioning table problem is negative. However a look at the sample sizes and the original data shows,

that one of the means used in this calculation is based on only five values, which makes it the statis-tically least reliable in the whole experiment.


92

Compressed Air Accumulator (Dynamics)

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.70 0.75 0.80 0.85 0.90Transparency (Theory)

Points/30

Time/30

Points/30*(1-Time/30)

Transparency (Subjective)

Dissolving Tank (General)

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.50 0.70 0.90 1.10

Transparency (Theory)

Transporting Device (Comments)

0.30

0.40

0.50

0.60

0.70

0.80

0.75 0.80 0.85 0.90


Heating Tank (General)

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

0.50 0.70 0.90


Positioning Table (Directionality)

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

0.65 0.70 0.75 0.80


Figure 6-3: Graphs showing the obvious correlation between the measured variables and Transparency.

6.4 Operation Phase

93

To check the influence of the outlier treatment, the same analysis was done with the original data. The overall result of both analyses is the same. The only significant difference occurs in the correla-tion coefficient between theoretical and subjective transparency in the positioning table problem. It changes from -0.79 to 0.20. As already mentioned above, this value is the one with the smallest sample sizes supporting it and hence it is not surprising that here the treatment of outliers has a mayor effect on the result. The value changes from high anti-correlation to a low correlation. Hence in the only case, where the outlier-treatment has a major influence it is in accordance with what was expected. Therefore, we can conclude that the treatment of outliers does not question our result and it is not necessary to study the outliers in detail. For the detailed results of correlation analysis with-out outlier treatment see [Frey 2001 (c), Table 16 in the Appendix].

6.4.4 Primary Analysis: Hypotheses Testing

6.4.4.1 Selection of Tests

In statistical analysis, hypotheses are subjected to statistical tests. A statistical test is a rule by which, based on a random sample, a choice between two mutually exclusive hypotheses can be made. It has to be emphasized that the result of a statistical test is never a statement about the truth of a hypothesis. This is because it is impossible to derive a general statement like this about the un-derlying population based on a random sample.

The hypothesis tested in hypothesis testing is called null hypothesis H0. The statistical test leads to the acceptance or rejection of this null hypothesis. Both, the acceptance and the rejection of a hy-pothesis can be correct or an error. The aim of statistical tests is to keep the probability of these er-rors reasonably small. For every null hypothesis, there exists at least one alternative hypothesis HA. Both hypotheses have to be mutually exclusive. The rejection of the null hypothesis leads to the ac-ceptance of a suitably chosen alternative hypothesis.

The probability of wrongly rejecting the null hypothesis can be controlled by the test in an easy manner. Therefore, the hypothesis formulated for an experiment is in general taken as alternative hypothesis HA. The complementary hypothesis, the null hypothesis H0 is tested. The rejection of the null hypothesis leads to the acceptance of the alternative hypothesis. With this procedure, the prob-ability of wrongly accepting the original hypothesis can be controlled.

In order to receive a large sample size in EVTM a way has to be found to combine the results of the

different problems. In the preliminary analysis the results could only be derived for the single prob-lems and a combination to the overall result was done by averaging over these single results. In the primary analysis a different approach is used: The transition from ordinal to nominal data allows the use of all problems in a single test.

Due to other factors, the absolute influence of transparency is different in different problems. This

means for example, the effect of the increase in transparency by a specific amount on the time needed in the heating tank problem is different from the effect of the same increase in transparency on the time needed in the compressed air accumulator problem. The interesting question however is, whether an increase of transparency leads to a decrease of time needed in both cases. To answer this question it is sufficient to know the sign of the difference between the times needed before and after


94

the increase of transparency in both problems. A test working on nominal data like this is the Sign-Test used for the primary analysis in EVTM. Another important advantage of the Sign-Test is that no assumptions about the underlying distribution of the sample are necessary.

In EVTM there are three different values of transparency in all problems. This allows the calcula-tion of three data points for each problem: The sign of the difference of the measured variables at

the same problem with high and low, medium and low, and high and medium transparency. Given the eleven problems a sample size of thirty-three results.

To illustrate this transition, data from the first problem in EVTM is taken. Table 6-7 shows the

measured and averaged data. In Table 6-8 the differences between the values at the different trans-parency levels are given. Using the sign of these differences, the transition to nominal values is

done. Table 6-9 shows the resulting data. The additional line in Table 6-9 is the combination of points and time needed for the test of the combined hypothesis H3.

Transparency (Theory) 0.95 ⇒ High 0.74 ⇒ Medium 0.54 ⇒ Low

Points 22.00 18.67 19.13

Time 8.56 10.67 13.25

Transparency (Subjective) 0.71 0.60 0.23

Table 6-7: Data from the first problem in EVTM (means).

High vs. Medium Medium vs. Low High vs. Low

Difference in Points 3.333 -0.458 2.875

Difference in Time -2.111 -2.583 -4.694

Difference in Transparency 0.113 0.375 0.488

Table 6-8: Differences between the means at different transparency.


Difference in Points positive Yes No Yes

Difference in Time negative Yes Yes Yes

Difference in Transparency positive Yes Yes Yes

Difference in Points positive AND Difference in Time negative

Yes No Yes

Table 6-9: Nominal data, to be used in the Sign-Test.

The Sign-Test can be used directly on this new nominal data. However, the question arises whether the difference between two values that are the means of measured data is statistically significant. To answer this question, the t-Test can be used before the Sign-Test.

6.4 Operation Phase

95

6.4.4.2 t-Test

In the transition from absolute to nominal data, the question arises, whether the difference between two means depends on the controlled variable or it is due to statistical variations. The t-Test [Rasch et al. 1999, Sub-Section 3.4.2] is designed to test the null hypothesis,

H0: „The difference between the means of two normally distributed samples are due to statistical variations, i.e. the means of the underlying populations are equal (m1 = m2).“

If the difference between two means is only statistical, this value cannot be used in the analysis of

an experiment.

In EVTM for all the combinations of means used to calculate the nominal data, a t-Test was per-formed. For several of these combinations the null hypothesis could not be rejected with an error

probability of α ≤ 0.1. Hence, it is assumed that the difference is caused by statistical variations and

that the means are equal. In these cases, the question whether the difference is positive cannot be answered and the corresponding data cannot be used in further tests.

As an example, the data from Problem 1 is taken again. Table 6-10 shows the results of the t-test. The nominal data from Table 6-9 is taken and a blank means that the respective difference is statis-tically not significantly different from zero, and is therefore eliminated prior to further analysis.


Difference in Points positive Yes Yes

Difference in Time negative Yes Yes

Difference in subjective Transparency is positive

Yes Yes

Difference in Points positive AND difference in Time negative

Yes Yes

Table 6-10: Result of the t-Test, to be used in the Sign-Test.

The t-Test can of course not be performed for the combined statement in the forth line of the table. To have a significant difference here, the difference in time as well as in points has to be significant.

6.4.4.3 Sign-Test

The general structure of the null hypothesis used in the Sign-Test [Bosch 2000, Chapter 12] is that the probability for the difference of two variables of being positive or negative is the same:

H0: P(X – Y > 0) = P(X – Y < 0)

As test statistic z, the number of elements of the sample with positive differences is chosen. De-

pending on the alternative hypothesis the Sign-Test can be single-sided or double-sided. In EVTM a single-sided test is used because the alternative hypotheses we want to establish are of the kind P(X

– Y > 0) > P(X – Y < 0) or P(X – Y > 0) < P(X – Y < 0). A double-sided test would be used for an

alternative Hypothesis of the type P(X – Y > 0) ≠ P(X – Y < 0).


96

There are three different possible results of the single-sided test. With n the total number of ele-

ments of the sample, z the number of positive differences, α the chosen error probability, and kα

the α-quantile of the binomial distribution for p = ½ we get:

a) z ≥ n – kα ⇒ reject H0 and accept the alternative hypothesis P(X – Y > 0) > P(X – Y < 0)

b) z ≤ kα ⇒ reject H0 and accept the alternative hypothesis P(X – Y > 0) < P(X – Y < 0)

c) z > kα or z < n – kα ⇒ accept H0.

If the sample contains elements with diminishing difference, the number of those has to be sub-tracted from the total number n. In doing so, the probability of an error can only become smaller.

The hypotheses formulated for EVTM are all in the form of an alternative hypothesis for the Sign-Test. Therefore, in a first step, for each hypothesis formulated in Sub-Section 6.3.1 a corresponding null hypothesis is defined that states that rising transparency does not change the measured vari-ables. If we take H1 as an example, the null hypothesis H10: „There is no difference in points for

increasing transparency values“ results.

Since we are interested in establishing the alternative hypotheses, the following easier rule for the Sign-Test in EVTM could be given: The elements in the sample that are not significant according to the t-Test are removed. The size of the new sample is denoted by n and the number of elements in the sample that support the alternative hypothesis is denoted by z. Now the alternative hypothesis is

accepted with an error probability of at most α if z ≥ n – kα.

Table 6-11 shows the relevant data and the results of the Sign-Test: In the first column the number of the original hypothesis together with a reformulation in terms of differences in values is shown

(the alternative hypotheses in the test). The second column gives the sample size for this hypothesis after the t-Test. In the third column the number of elements in the sample that are in accordance

with the alternative hypothesis is noted. The fourth column gives the value for k corresponding to

the sample size and an error probability of α = 0.005. The remaining columns show the necessary

calculation and the result of the test.

n z k0.005 n - k0.005 z ≥ n - k0.005

H1: Difference in Points positive 14 14 1 13 Yes

H2: Difference in Time negative 21 18 4 17 Yes

H3: Difference in Points positive AND difference in Time negative

11 11 0 11 Yes

H4: Difference in subjective Transparency is positive

18 18 3 15 Yes

Table 6-11: Sign-Test for the four hypotheses using only significant data.

With the results given in Table 6-11 all four null hypotheses are rejected and their alternative hy-

potheses are accepted with an error probability of α = 0.005. This means that the four original hy-

potheses of EVTM are accepted.

6.5 Interpretation

97

A further question is whether the t-Test or the treatment of outliers influences the results. In [Frey

2001 (c)] the three other possible versions of the Sign-Test (significant data without outlier treatment and all data, i.e. without the t-Test, with and without outlier treatment) are calculated and it is shown that the general outcome of the analysis is the same in all cases. However, without the t-Test

the error probability α that leads to the acceptance of all four hypotheses has to be set to 0.025.

6.4.5 Results of the Analysis

The analysis showed that all four hypotheses formulated in EVTM can be accepted based on the

gathered data with an error probability of α = 0.005. This means:

• Higher transparency leads to more answers that are correct.

• Higher transparency results in less time to answer the questions.

• With higher transparency, the number of correct answers increases while the time to give those answers decreases at the same time.

• With higher transparency values assigned by the proposed metric, the transparency value as-signed to an algorithm by the candidates increases.

This in turn means that an increase in the theoretical transparency leads to a better understanding of the algorithm and is correlated with the corresponding subjective notion.

The statistical methods applied to the data, namely the outlier treatment and the t-Test, assume that

the underlying population is normally distributed. This is an assumption that in general holds in tests involving human factors. However, the application of those methods does not considerably

change the outcome of the main analysis carried out with the Sign-Test. The Sign-Test itself re-quires no assumptions on the underlying distribution of the measured data. Hence, the results even hold if the distribution is not normal.

EVTM was not primarily designed to test the influence of the different elements of the transparency metric. However, as shown in Table 6-4, in some problems only a single element or a group of ele-ments is varied (the use of comments, dynamic properties and complexity, and the direction of arcs). Separate tests done only for the data gathered in these problems show that all these elements have a significant influence on the understanding of the algorithm (see [Frey 2001 (c)] for details).

6.5 Interpretation

6.5.1 The Interpretation Phase

During the interpretation phase of an experiment, the results have to be presented in an appropriate way. This means:

• the results have to be set into the correct experimental context in to avoid wrong interpretations,

• the validity of extrapolations has to be discussed, and

• the results have to be made visible to allow constructive criticism.


98

Interpretation context Extrapolation Impact

Statistical Framework

Study purpose

Field of research

Sample representativeness Visibility

Replication

Application

Table 6-12: Tasks in the interpretation phase of an experimental study.

The three points to be discussed in this context are the scalability, the reproducibility, and the valid-ity of the experiment.

6.5.2 Scalability

In general, the statistical significance of results increases with the number of data gathered in an ex-periment. However, it is not a good idea to start a large-scale experiment without knowing about the expenditure needed to finish the study. Hence, the experiment has to be scalable. Scalability of an experiment means that it can be done first in a rather small scale to check the initial experiment plan

and to receive first experience in the needed expenditure. Later it is possible to repeat it with more participants and/or more projects to receive results that are statistically more significant.

To reach scalability in EVTM, the single SIPN used in the experiment are reasonably small. This means, it takes not much time to understand the net in general. To scale up the experiment more of those small SIPN can be used. The design of the EVTM allows the extension to more test persons

or groups and to more problems. Furthermore, the performed experiment is scaleable in the sense that further data could be added to the evaluation. This further data could be gathered by presenting

the same test problems to different test persons or by performing a test with new problems (while measuring the same variables) with different or the same test persons.

6.5.3 Reproducibility

Even more than scalability, the reproducibility is an essential condition to be fulfilled by an empiri-cal experiment. This is, of course, a common rule for all scientific experiments. However, repro-

ducibility in empirical studies like Software Engineering experiments does not mean that the exact results of the experiment can be reproduced. Unlike in natural sciences like physics or chemistry,

not all the factors influencing the outcome of an experiment can be measured and reproduced. The human factor involved cannot be eliminated. Reproducibility in Software Engineering experiments

means that the complete setup of the experiment and all the conditions that may influence the out-come of the experiment are documented carefully in the experiment plan. This experiment plan al-lows other researchers to repeat the experiment and to compare their results. Furthermore, the raw data derived in the experiment should be archived to allow further or different statistical evaluation.

For EVTM, the complete experiment is exhaustively documented in [Frey 2001 (a)]. The original test-sheets are also available [Frey 2001 (b)] and the analysis is described in this document. The documentation is freely available for everybody on the WWW. Furthermore, the original result sheets are archived at the Institute of Automatic Control for further access if needed.

6.5 Interpretation

99

6.5.4 Validity of Experimental Results

6.5.4.1 Types of Validity

Experimental science sets high demands on the design of the experiment. The term validity is at-

tributed with the informative value of experiments. In other words, the validity of an experiment de-termines to what extend we can have confidence in its results.

In praxis, a compromise between validity and workability has to be found. Experiments are often influenced by extraneous variables that can neither be controlled nor measured in any practical way. In these cases, it is important that the scientist is aware of the threats to validity and considers them

in designing the experiment. All known factors that possibly influence the experiment and cannot be eliminated by the experiment's design have to be listed in the experiment's documentation and

their influence has to be discussed.

There is a multitude of criteria that give information on the validity of experimental studies. These

criteria fall into two categories [Ticehurst and Veal 1999, Chapter 6]:

• Internal Validity: Is the result of the experiment correct?

• External validity: Is the result of the experiment generalizable?

Other authors, e.g. [Ciolkowski et al. 1997], add a third category of validity to this list, the construct validity.

• Construct validity: Do the variables used measure the concepts they purport to measure?

In the following, the three categories of validity and their application to EVTM are discussed in turn.

6.5.4.2 Construct Validity

Construct validity is the degree to which the independent and dependent variables in the experiment accurately measure the concepts they should measure. In EVTM the independent variable (theoreti-

cal) transparency is a mathematical attribute of SIPN algorithms that can be calculated exactly. The dependent variable subjective transparency is measured by direct questioning of the candidates.

A question to be discussed in EVTM is whether the degree of understanding of the algorithms de-scribed by the time needed to answer questions on a controller and the correctness of these answers is accurately measured by our setup. The wrong formulation of the questions can lead to a wrong measurement.

There is a principal distinction between open and closed questions [Kotler 1999] or [Kotler and Bliemel 2001]. In the first category the test persons are completely free in formulating their answer, whereas in the second category several answers to choose from are given. Often the content and the differentiation of an answer are better with open questions. However, in written tests with many questions, open questions need too much time during the test and in the later analysis of the test. Since it was clear that we could not motivate the students for a test of more than two hours, closed

questions were chosen in EVTM. The candidates have to choose one of the answers „Yes“, „No“, or „?“ where „?“ means „I don’t know“. This special type of closed question is also called dichoto-


100

mic question, because the candidates have to choose between two mutually exclusive answers, in contrary to multiple choice where at least three answers are given to choose from and often the se-lection of more than one answer is allowed (the third option „?“ is no real answer).

In engineering education tests with closed questions are an established method to check the under-standing of acquired knowledge. In the actual study students were chosen as test persons. This se-

lection of test persons is quite appropriate because they are used to the technique of examinations and the degree of acceptance is rather high.

In conclusion, we see no threats to construct validity in EVTM.

6.5.4.3 Internal Validity

The internal validity asks if it is in principle possible to extract a significant relationship between

the dependent and independent variables out of the experiment. If the change of the dependent vari-ables can only be explained by the manipulation of the independent variables, then the internal va-lidity is high. If there are other plausible explanations for the results of the experiment, then the in-ternal validity is low and we will have no confidence in the results.

Several factors are a threat to the internal validity of an experiment. The most important of them are

history, maturation, measurement, selection, and mortality.

History

History means the change of external conditions or the occurrence of external events during the ex-

periment, which can influence the outcome. For example, a study that tries to establish a relation between governmental sponsoring of stock investment and the acceptance of stocks as a form of in-

vestment would be ruined by a sudden crash of the stock market during the time of the experiment.

In EVTM there is no threat from history effects because of the experiments short duration (2 hours).

Maturation

Maturation of the participants means the influence of effects like learning, fatigue, or loss of moti-vation. During an experiment participants earn an increasing experience, and learn more and more to solve problems typical for this experiment. Contrary to this effect, with increasing time the participants become more ore less tired and their interest in the test decreases.

In EVTM the candidates have to solve several problems. To avoid an influence of maturation ef-fects on the results, the performance of the candidates in problems posed early in the test have not been compared to the ones measured in later problems.

Measurement

The type of measurement can influence the outcome of the experiment considerably. First of all by measurement errors, but also by wrong approaches to measuring.

In EVTM measurement errors are no threat to validity because the measurement merely involves the counting of correct answers.

6.5 Interpretation

101

Selection

Selection describes the problems arising due to the variations in human performance. In EVTM several steps have been taken to level out human factors. The analysis is based on means of the data

gathered from groups of several people. The randomized block assignment (explained in detail in Sub-Section 6.3.2) leads to an equal distribution of one prominent human factor, the educational

background, over those groups.

Mortality

During a study it can happen that test persons leave the experiment, this effect is denoted by mortal-ity. If there are a lot of leaving subjects or the leaving ones belong to a group with a specific prop-erty that influences the experiment, then mortality can corrupt the experiment's outcome.

Mortality is a problem in test like EVTM not because participants leave the experiment, but because of the fixed time limit. Not all participants work through all problems. To avoid an error in the evaluation, care has been taken that results from problems that are presented in later stages of the experiment are not directly compared to those presented at the beginning.

6.5.4.4 External Validity

External validity refers to the degree to which the results of an experimental study can be general-ized to other settings and situations. To achieve external validity, the following questions have to be

answered positively:

• Are the test subjects representative of the intended users of the method?

• Are the test problems representative of real-life problems?

The first question can be rephrased in the context of EVTM to: Are the subjects representative of professional controller programmers? We choose engineering students that took a course in logic control. Therefore, the participants are comparable to professional controller programmers with re-spect to their educational background. Hence, the question whether the proposed theoretical trans-parency metric is significant in classification of SIPN out of the special view of a control engineer should be answered sufficiently by the experiment. However, all but three subjects are students and their lack of experience may limit the validity of the results.

The second question concerns the problems to be solved by the test candidates. All aspects of these problems, like the amount and type of given information, were chosen to be as close as possible to the application in control engineering. All problems have the same structure. The problem descrip-tion consists of five parts:

1. An image or a P&ID of the plant.

2. A short verbal description of the process to be implemented on this plant by the controller.

3. Tables of input and output signals.

4. A graphical representation of the controller.

5. A list of statements (questions) on the process.


102

This is more or less the same information an engineer receives if he has to work on a real problem. In modern engineering tools he may of course have access to an animated version of these materi-als. In addition, the type of processes used in the test problems resembles real-life processes in the way that examples from manufacturing as well as from process control are included. However, the small size of the problems may limit the validity of our results.

6.6 Summary

The experiment for the validation of the transparency metric, EVTM, showed that the proposed transparency metric is valid in the sense that it measures what it was intended to. For a given con-troller, higher transparency results in better and faster understanding of the algorithm. Furthermore, it showed that the transparency value assigned by the metric is consistent with the value people would assign intuitively.

The performed experiment is scalable and reproducible. It was taken care to assure the construct va-lidity and the internal validity of the experiment. The same holds true for the external validity. However, here the problem remains that the size of the problems is not representative of real live applications.

EVTM was not designed to check the influence of all the different parts of the combined transpar-ency metric. For some of these parts (comments, directionality, and dynamic properties and com-plexity) an influence could be shown. However, for the weighting of the single parts much more data has to be gathered and more problems with variations in only single parts of the metric have to be performed.

Further research could be done in the evaluation of the single components of the metric and in the test of the metric on a real live example.

103

7. Implementation


For the industrial realization of a controller on conventional PLCs or IPCs running a SoftPLC stan-dard PLC programming languages according to IEC 61131-3 are used. To use SIPN on a large vari-ety of PLC hardware platforms it is recommended to translate them into one of the standardized PLC languages as for example Instruction List (IL). The direct implementation of an SIPN compiler would only work for one special PLC, but an IL according to the specifications of IEC 61131-3 can be executed on nearly any PLC. The verified properties of the SIPN can only be guaranteed for the implemented controller if the generation of PLC code from SIPN preserves the dynamic behavior of the latter. To avoid errors the transformation should be done automatically.

The Chapter is organized as follows: Section 7.2 describes the transformation of SIPN elements to PLC code segments based on an approach introduced in [Jörns et al. 1995]. The core problem in PLC code generation from SIPN is the transformation of the concurrent and iterative behavior of the SIPN to the sequential behavior of PLC languages. These problems are discussed in Sections 7.3 and 7.4 respectively. The Chapter finishes with a summary.

7.2 Transformation of Net Elements

Besides the differences in the specific Petri Net type considered, the approach presented here differs from other approaches (see e.g. [Cutts and Rattigan 1992, Stanton et al. 1996, Uzam and Jones

1998, Venkatesh et al. 1995]) in one main aspect: the one-to-one correspondence of net elements to code segments used. This correspondence allows the easy reinterpretation of the produced code.

This reinterpretation is of special importance if a user wants to understand and change the imple-mented code, which is commonplace in industrial applications. For such a structure-conserving

conversion, the token play of the SIPN has to be transferred into the PLC program. Therefore, for each place pi of the SIPN a Boolean variable Pi is defined that shows whether the corresponding place is marked (Pi = TRUE) or unmarked (Pi = FALSE). Based on this premise the net elements can be translated to PLC code step by step.

Transitions

The compilation of a transition has to test whether the transition is enabled and whether the firing

condition is fulfilled. To optimize the code, the firing conditions are not evaluated if a transition is not enabled. For this optimization, a conditional jump to the code of the next transition is included in the code right after the test on enabling. If after the processing of this calculation the accumulator is set to one, i.e. all conditions are fulfilled, then the transition fires. The firing unmarks all pre-places and marks all post-places. The commands for setting or resetting variables are only executed by a PLC if the accumulator reads one. Therefore, the firing part of a transition can be written di-

rectly below the test of the firing condition without the need for a conditional jump.

Note, if the analysis yields that the SIPN is safe, than the test of the post-places can be omitted in the code, resulting in a considerably shorter and faster code.

7 Implementation

104

Places

If a place is marked then the corresponding output function is executed (setting or resetting of vari-ables). If it is not marked a conditional jump to the next place label is performed and the code seg-

ment of the output function is not executed. The conditional jump can be omitted since the instruc-

tions S and R are only executed if the accumulator of the PLC is set to logical TRUE. This imple-

mentation of the output functions results in an output of zero or one for all output variables accord-ing to the output of the SIPN. In case of an incorrect output setting in the SIPN the output of the code differs from the SIPN since undefined and contradictory output settings are not possible in the realization. For an undefined output, the PLC code remains at the last defined value for this output. For a contradictory output it depends on the ordering of the involved place code segments whether the variable is set to one or to zero. Both cases should be avoided using SIPN analysis before code

generation. As a small example, Figure 7-2 shows the IL code for the SIPN in Figure 7-1.

o1 := 1

3t1) = i1

o1 := 0 p1

p2

t1

Figure 7-1: SIPN example for code generation.

PROGRAM Figure7_1 VAR PV_1 : BOOL := TRUE; (* Place P1 initially marked *) PV_2 : BOOL := FALSE; (* Place P2*) I1 : BOOL; O1 : BOOL; END_VAR L_1: LD PV_1 (*T2: if pre-place P1 is marked*) ANDN PV_2 (*and post-place P2 is unmarked*) JMPCN L_2 (*if not enabled go to next label*) AND I1 (*and firing condition is fulfilled*) R PV_1 (*then unmark pre-place P1*) S PV_2 (*and mark post-place P2*) L_2: LD PV_1 (*P1: if place P1 is marked*) JMPCN L_3 R O1 (*reset O1*) L_3: LD PV_2 (*P2: if place P2 is marked*) JMPCN L_4 S O1 (*set O1*) L_4: RET END_PROGRAM

Figure 7-2: IL Program for the SIPN in Figure 7-1.

7.3 Concurrency

In SIPN the firing of two concurrent transitions is defined to happen simultaneously whereas in the PLC code only a sequential firing of the two transitions can be realized. However, this is not a prob-lem given the processing cycle of a PLC. It consists of the three steps: reading of the input image,

processing of the algorithm, and writing of the output image (cf. Figure 7-3).

7.4 Iteration

105

time

processingapplication code

cycle time

readinginput image

writingoutput image

readinginput image

Figure 7-3: Program processing in a PLC.

The environment of the PLC—the process and the user—sees a sequence of output images. Hence,

several transitions that fire sequentially in the algorithm are seen as simultaneous from the outside if they are processed during the same PLC cycle. An arbitrary ordering of the transition codes in the

sequential algorithm guarantees the correct representation of simultaneous firing of concurrently enabled transitions on the PLC. The calculation of the new output—which is related to the places—has to be done after the firing of all enabled transitions. Hence, the code segments for places are set after the code segments for all transitions.

7.4 Iteration

7.4.1 Implementation of Iteration in the PLC Code

More complex than the transformation of concurrency into the PLC program is the sequential repre-sentation of iteration. The firing rule of SIPN demands that the firing process is iterated until a sta-ble marking is reached, i.e. until no transition can fire anymore. Thus, the implemented algorithm has to guarantee that transitions that fire in a sequence over a transient marking are fired in the same PLC cycle. This problem can be solved by directly modeling the iterative process in the PLC Code:

1. A Boolean variable Delta is defined and set to FALSE before the procession of transition codes.

2. The transition codes are extended with an instruction that sets Delta to TRUE when the transi-

tion fires.

3. At the end of the transition codes a conditional jump to the beginning is implemented. If Delta is TRUE, there Delta is set to FALSE and all transition codes are evaluated again.

The problem with this approach is that the code becomes slow. Therefore, [Jörns et al. 1995] pro-posed a method to order the transition codes based on a simulation of the SIPN. Another approach

introduced in [Frey 2000 (a)] uses an analytical method to determine an order for the transition codes. In the following, those approaches are presented and compared.

7.4.2 Simulative Determination of a Transition Sequence

Following [Jörns et al. 1995], the SIPN is simulated starting from the initial marking in a branch and bound procedure without considering the firing conditions. The simulation is stopped after

every transition was fired once. During this simulation, the sequence of transitions is recorded. An additional jump from the last transition in the list to the beginning of the transition codes is exe-

cuted if the last transition fires. This jump should guarantee that a firing sequence that proceeds across the last transition is correctly executed. However, as the following example shows, the cor-

7 Implementation

106

rect behavior is only guaranteed if from every last transition in a branch of the algorithm a jump back to the top of the list is executed on firing of that transition.

3t2) = ¬i1 ∧ ¬i2

&p2) = (0, 1)

&p3) = (1, 0)

3t4) = i1 3t3) = ¬i1∧¬i2∧i3

3t1) = i1∧¬i2

&p1) = (0, 0) p1

p2

p3

t1

t2

t4 t3 Figure 7-4: SIPN example for Iteration.

For the SIPN given in Figure 7-4, the simulation method proceeds like this: starting from the initial

marking t1 could fire: <t1> followed by t2: <t1, t2> followed by t3 or t4. Following the first branch t3 is added to the list <t1, t2, t3>. After t3, t1 could fire. Since t1 is already in the list, a bound is reached.

Stepping back to the last branching, t4 is added to the list. After t4, again t1 could fire here again the bound is reached. All transitions are in the list and the final execution sequence is <t1, t2, t3, t4> with a jump from t4 to t1 if t4 fires: <t1, t2, t3, t4 (Æ t1)>.

Suppose now the following situation: The marking of the algorithm is given by a single token in p3, the input signal i1 is TRUE, and i2 is FALSE. The algorithm would check the transitions: t1 is not

enabled, t2 is not enabled, t3 fires resulting in the unmarking of p3 and the marking of p1, t4 is not enabled and hence the jump back to t1 is not executed. However, according to the SIPN firing rules not only t3 but also t1 should fire resulting in a token in p2 instead of p1.

As stated above, this problem can be solved, if from every last transition in a branch a jump back to the top of the list is executed on firing of the transition resulting in a sequence with two jumps in

the example: < t1, t2, t3(Æt1), t4(Æt1)>.

7.4.3 Analytical Determination of a Transition Sequence

An iterative firing is caused by sequential dynamic synchronization. Hence, to determine if a transi-tion can fire after another transition in the same cycle the relation: „ti can imply the following firing of tj without a change in the input signals“ has to be evaluated for all combinations of transitions ti, tj of T. Formally the condition for sequential firing of two transitions ti, ti over an transient marking can be given as follows:

There are markings ma, mb, mc, and a combination of input signals such that the following holds:

1. ti fires at ma under the given input and produces mb, 2. tj fires at mb under the given input and produces mc, and

3. tj cannot fire at ma under the given input.

7.4 Iteration

107

This condition is quite complicated, and to check it for all combinations of two transitions is com-putationally expensive. Dynamic synchronization can be detected by analyzing the reachability graph of the SIPN, but this is also computationally expensive. Therefore, an easy to check criterion that gives a necessary condition for the sequential firing of transitions is needed. Two transitions ti, tj can only fire in an iteration if the following two conditions are fulfilled:

1. ti and tj are connected via a place pk, i.e. there exists a place pk such that (ti, pk) and (pk, tj) are arcs of the SIPN.

2. The conjunction of the firing conditions of ti and tj LV QRW FRQVWDQW IDOVH 3ti) ∧ 3tj) ≠ FALSE.

Based on these two conditions the determination of the transition sequence is done in three steps: Contraction (Condition 1), Reduction (Condition 2) and Ordering (Selection of one of the possible solutions).

In the contraction step the SIPN is transformed into a graph G = (V, E) with the transitions of the

SIPN as vertices, V = T, and an arc (ti, tj) ∈ E if a place pk ∈ P exists such that Condition 1 is ful-filled.

In the reduction step all vertices (ti, tj) in E that do not fulfill CRQGLWLRQ LH ZLWK 3ti) ∧ 3tj) = 0,

are deleted.

The resulting directed graph represents the relation: ti has to be implemented in the list of transition codes before tj. Since there is no other criterion for the sequence, the selection of one of the possible

solutions can be done by starting from a lexicographic order and adapting it according to the de-rived relation. There are two distinct cases in the ordering step:

1. If the sequence-relation is a weak order (there are no cycles in the graph) then there is an order-ing that guarantees the correct behavior of the program with a single procession of all code segments.

2. If the sequence-relation is not a weak order then all cycles of the graph have to be broken up. At the breakpoints a jump to the beginning of the corresponding cycle is necessary if the last transi-tion of the cycle fires. It is guaranteed that a code segment is processed at most n+1 times in the worst case with n the number of cycles in the computed graph. (Several cycles must not be bro-ken at the same transition because then it is not clear where to jump.)

In the following an illustrative example for each of the two cases is given. The analytic method is depicted in Figure 7-5 for an SIPN (the same as in Figure 7-4) with partially ordered transition se-quence. The resulting graph shows that the relation „ti has to be processed before tj“ is a partial or-der in this case. Hence, the single processing of all transition codes in a PLC cycle guarantees the correct behavior of the algorithm. This is in contrary to the solution derived by simulation in sub-

Section 7.4.2 where only the double processing of the transition codes could yield the correct be-havior. The ordering step gives <t2, t3, t4, t1> as a possible solution.

7 Implementation

108

p1

¬i1 ∧ ¬i2

i1

Con

trac

tion

Ordering

< t2, t3, t4, t1>

p2

p3

t1

t4 t3

t2

Red

uctio

n

1

2

34

1

2

34

¬i1 ∧ ¬i2 ∧ i3

i1 ∧ ¬i2

Figure 7-5: Application of the analytic ordering method.

Suppose again the following situation: The marking is given by a single token in p3, the input signal i1 is TRUE, and i2 is FALSE. The algorithm would check the transitions: t2 is not enabled, t4 fires resulting in the unmarking of p3 and the marking of p1, t1 fires resulting in the unmarking of p1 and the marking of p2. The resulting marking with a token in p2 is the one expected by the SIPN.

The following example (Figure 7-6) shows an SIPN of the second type. The relation given by the graph is not reflexive. Therefore, the processing of the transition codes has to be iterated. A possible solution would be the sequence <t1, t2, t3, t4, t5> with a jump from t4 to t1 if t4 fires: <t1, t2, t3, t4

(Æt1), t5>. This example shows that it is not necessary to re-execute the whole transition sequence if there is a loop. In this case, the simulation method gives a sequence with two jumps: <t1, t2, t3, t4

(Æt1), t5 (Æt1)>.

¬i2 ∧¬i3

p1

i1

Con

trac

tion

1

2

34

Ordering

< t1, t2, t3, t4(Æt1), t5>

p2

p3

p4

t5

t3t4

t2 Red

uctio

n

¬i2 ∧ i3

i3

t1 i1 ∧ i2

5 1

2

34

5

Figure 7-6: SIPN without partially ordered sequence-relation.

7.4.4 Comparison of the presented Iteration Methods

All the presented approaches guarantee a correct representation of the iterative SIPN behavior in PLC code. The direct implementation of the iteration is the easiest one, more elaborate methods need special algorithms to be implemented in the code-generator. Another advantage of the direct implementation is that there are no restrictions to the ordering of the transition codes. Hence, they could be ordered in a way that makes reading the code easier (e.g. by name or number). The code

7.5 Implementation of Hierarchical SIPN using the IEC 61131 POU-Concept

109

produced following the simulative or analytical ordering contains jumps that are not intuitively un-derstood. However, the simulative and even more the analytic method can lead to considerably faster code. Table 7-1 summarizes the advantages and disadvantages of the tree methods.

Direct Implementation Simulation Analysis

Implementation in Code Generator + - -

Readability of Code + - -

Efficiency - o +

Table 7-1: Comparison of the Methods for Iteration.

Considering Table 7-1 the direct implementation of iteration seems to be the best method. However, SIPN describing real-world control algorithms often consist of large amounts of places and transi-

tions. In these large SIPN, the increased PLC cycle time is prohibitive to the application of the di-rect method. Therefore, only the analytic or the simulative approaches remain for practical applica-tions. The analytic determination of the transition sequence is to be preferred in these cases, because it results in faster code.

7.5 Implementation of Hierarchical SIPN using the IEC 61131 POU-Concept

Given the passivity of the subnets in hierarchical SIPN, an implementation using separate function blocks according to IEC61131-3 is possible. The hierarchical structure of the SIPNH is modeled on a hierarchical structure of Program Organization Units (POUs) according to the standard.

The IEC 61131-3 defines three different kinds of POUs: program, function block, and function. A control program according to IEC 61131-3 contains exactly one POU of type program and may contain several POUs of type function block or function. A POU of type function cannot have state information. Therefore, it cannot be used for the coding of an SIPN.

The main or highest level net in an SIPNH is translated into a POU of type program and the underly-

ing SIPN are translated into function blocks. The instantiation of a function block is done in the function block or program calling it.

The single SIPN in the hierarchical structure are coded as described in the previous Sub-Sections.

For hierarchical places and their pre- and post-transitions the code generation has to be extended. Furthermore, the instantiation of the function blocks has to be included in the variable definition.

Given a hierarchical place Pi, the corresponding subnet is implemented in a POU of type function

block and name FB_i. This POU has to be instantiated in the POU that contains the hierarchical

place. The instantiation is done in the declaration part with the code line PVi_FB : FB_i;

The function block gets an input and an output variable, that are used for the communication with

the calling net. As input to the function block, the marking of the corresponding hierarchical place

is used. The function blocks are programmed to do nothing if called with IN:=FALSE. Now, before the transition codes are processed all function blocks are called to assure that the token-play in the

subnets is done before the test of enabling in the calling net.

7 Implementation

110

The output variable Q of the function block is set to one if its output-place is marked. A transition

that has a hierarchical place as input-place has to check whether the corresponding subnet has

reached its output-place using PVi_FB.Q.

A transition that marks a hierarchical place has to call the corresponding function block right after

firing to assure that the initial output of the subnet is generated in the same PLC cycle (CAL

PVi_FB(IN:=PV_i)). Accordingly, a transition that unmarks a hierarchical place has to call the corresponding function block to assure that the output place does no longer activate any outputs.

The function blocks describing a subnet contain an additional variable FB_INIT. This variable is used to check whether the subnet is already activated or not. If not, the initial marking has to be set.

7.6 Summary

This chapter presents methods for the automatic generation of PLC code from SIPN. In a first step, places and transitions are transformed into corresponding code segments. Thereafter, the correct representation of concurrent behavior of the SIPN is realized by ordering the code sequences de-scribing places after the sequences corresponding to transitions. For the realization of iterative SIPN behavior three approaches are presented and compared. From the theoretical viewpoint, the analytic method is the most appealing. However, from the implementation viewpoint the gain in efficiency

is bought by a less readable code and a more complicated code-generator.

Because of the passivity condition in hierarchical SIPN, those nets can be implemented in a hierar-

chical structure of function blocks according to IEC 61131-3. This implementation results in con-siderably faster and more comprehensible code than the flat implementation of the hierarchical

structure.

The presented code generation methods have been prototyped and tested using a Mathematica pro-gram that takes the description of an SIPN and produces IL. The program can be called with differ-

ent options to produce optimized code (i.e. for safe SIPN).

111

8. Validation


Validation is none of the main topics of this thesis. However, a thesis on the development of logic controllers without at least some pointers on possible validation methods would be incomplete. Figure 8-1 illustrates the validation process. Validation checks whether the designed control algo-rithm fulfills the problem specific functional properties or not. If the result of the validation is False, we first have to check the control algorithm to see if it has a major failure. If there is no fail-ure in the algorithm, a second step is to look whether the informal property has been correctly for-malized, because this operation is often the most complicated of the design process. A third possible reason for a non-validated property can be an incomplete or unclear informal specification. In this

case, the informal specification has to be improved and formalized anew. Another solution could be the introduction of additional assumptions about the behavior of the plant and its environment. If,

during the validation, the control algorithm has to be modified, a step of verification must be done before a new validation step.




of the Control

Algorithm

Formalized Problem Specific


Validation

Formalization


of the Control

Algorithm

Method used for

Validation



Validation Result:


not fulfilled

Correction(Re-Formalization)

Correction(Extension, Clarification,

Re-Formulation)




of the Control

Algorithm

Formalized Problem Specific


Validation

Formalization


of the Control

Algorithm

Method used for

Validation



Correction(Re-Design)Correction

(Re-Design)

Validation Result:


not fulfilled




Re-Formulation)


Re-Formulation)

Figure 8-1: Validation process in general.

8 Validation

112

The only validation method studied for SIPN so far is symbolic model checking. Since there is no model-checker that works directly on SIPN, a specific input model for the model checker has to be derived before validation. The SIPN approach provides two possible interfaces for this generation of a model checker input file (cf. Figure 1-1): the SIPN itself and the generated PLC code. Both ap-proaches are studied and both have been applied to the same benchmark problem. This benchmark problem is introduced in Section 8.2, followed by a short overview of an approach to SIPN based validation in Section 8.3 and the presentation of an approach based on the generated PLC code in Section 8.4. A comparison of the two approaches and some general notes on validation conclude the Chapter.

8.2 Compressed Air Accumulator Example

This example originates from industrial applications, but is simplified to serve as a benchmark problem and to be used for education [Litz and Frey 1998]. Figure 8-2 shows a compressed air ac-

cumulator with tables of its I/O-signals. The main part of the setup is an air chamber that is used as a buffer to provide compressed air at a constant pressure of roughly 6.0 bar to consumers. Consum-

ers can draw off compressed air from the chamber via a valve. This valve provides no feedback to the controller, hence it is not directly known when a consumer opens or closes the valve. Two bi-

nary sensors PS1 and PS2 monitor the upper and lower acceptable pressure limits of 6.1 bar and 5.9 bar respectively in the chamber. Based on these signals the controller can activate two compressors to feed air to the chamber. The compressors give a feedback signal to the controller when they are disturbed.

AirCompressed-air

to consumer

M

M

Air-chamber

Compressor A

Compressor B

PS 1

PS 2

Meaning of the binary i=1 Meaning of the binary o=1

i1 Pressure < 6,1 bar (PS1) o1 Compressor A running

i2 Pressure < 5,9 bar (PS2) o2 Compressor B running

i3 Compressor A disturbed

i4 Compressor B disturbed

Figure 8-2: Compressed air accumulator (P&ID and I/O-Tables).

The informal specification of problem specific functional properties for the compressed air accumu-lator controller is given by the following five verbal requirements:

1. If the pressure is below 6.1 bar (PS1 switches on), one compressor should run.

2. If the pressure is above 6.1 bar (PS1 switches off), no compressor should run.

8.3 Validation based on SIPN

113

3. The two compressors should run alternately.

4. If one compressor is disturbed, the other one should substitute it.

5. If the pressure is below 5.9 bar (PS2 switches on), both compressors should run.

In addition to these five original requirements, a sixth one was introduced in [Litz and Frey 1999]:

6. If both compressors run and the pressure rises above 5.9 bar, compressor A should be stopped.

Including this requirement, a non-symmetrical solution to the compressed air accumulator problem

results.

8.3 Validation based on SIPN

In this approach studied in [Weng and Litz 2000, Weng and Litz 2001, Klein 2001] the SIPN is

translated into a form that is readable for the model checker. The tool used, Cadence SMV [Cadence SMV], requires a description of the control algorithm given in a text file and a set of

properties written in Temporal Logic. As a result of the validation, the model checker gives a ver-dict (True/False), i.e. the property is fulfilled/not fulfilled. In the case of False a counter example showing a path from the initial state of the system to a state where the property is violated is given as a trace.

To build the input code for SMV, the behavior of the SIPN has to be described. The critical point

here is the iterative firing of an SIPN until a stable marking is reached. Only after a stable marking is reached, outputs can be affected by the SIPN and new inputs can affect the SIPN.

Figure 8-3 shows the algorithm that has to be implemented in order to describe the SIPN behavior

correctly. This algorithm needs the definition of a control variable stability to characterize whether a marking in the SIPN is stable (stability = stable) or not (stability = unstable) for abbreviation in the

properties an additional flag eoc that is set to TRUE whenever stability = stable holds is used [Weng and Litz 2001].

Read input signals

Compute firingconditions

Set new marking Compute outputsignals

Stability check

Non stable

marking

Stable

marking

Figure 8-3: Coding of the control algorithm.

The approach is illustrated in [Weng and Litz 2000, Weng and Litz 2001] at the air chamber exam-ple using the extended, non-symmetrical specification and the SIPN shown in Figure 8-4.

8 Validation

114

Using this net, all but one of the problem specific properties could be validated (the alternating of the compressors could not be formulated using CTL). During this validation however, the specifica-tion had to be improved in some aspects. For example the property „If the pressure is less than 5.9

bar (PS2 switches on), both compressors should run“ could not be validated unless it was extended to include the case of compressor failure „If the pressure is less than 5.9 bar (PS2 switches on) and

both compressors are not disturbed, both compressors should run“.

The approach can also be used for verification of standard functional SIPN properties. Ways to formulate them are presented in [Weng and Litz 2000] for correct outputs and liveness, and in [Weng and Litz 2001] for termination.

P4: o1=0; o2=0

P1: o1=1; o2=0

P2: o1=0; o2=0 P3: o1=0; o2=1

~ i1 ~ i1

i4 i1

i1

i3

i2

~ i2

i2

P5: o1=1; o2=1

Figure 8-4: Non-symmetrical solution to the air chamber problem [Litz and Frey 1998].

The presented approach is non-model-based. However, it can be easily used for constraint-based validation because the SMV tool allows the optional specification of assumptions under which a property is checked. Using this option, static properties of the process under control, like the con-nection between two sensor signals that are always disjoint can be formulated.

8.4 Validation using the Generated Code

For validation approaches using the generated code, the controller is designed as an SIPN and then automatically translated into Instruction List. In principle, any approach for the verification of IL-programs can be used on the generated code (e.g. [Canet et al. 2000]). In the following, the ap-proach developed at the Brandenburg Technical University in Cottbus is presented in more detail because a joint case study showed how good this approach could be combined with the SIPN

method in an overall concept [Mertke and Frey 2001]. Figure 8-5 shows the validation cycle used in this combined approach. The cycle contains two main streams: The generation of a model of the

PLC system (controller consisting of user-program and system-program plus plant) as an ordinary, binary marked Petri Net, and the description of the requirements in temporal logic formulae.


115

modeling of the PLC system

Controller Design

Formalspecification

PLC user program (IL0)

plantinformal

requirements

description languagefor the plant

library

Petri net generatorsafety-oriented

specification language

model of theuser program (PN)

model of the environment (PN)

set of formulae(temporal logic)

combination

model of thePLC system (PN)

errors / inconsistencies

ValidatedPLC program

Validation

model ofthe PLC (PN)

SIPN Editor

SIPN Compiler

Control Algorithm (SIPN)

modeling of the PLC system

Controller Design

Formalspecification


plantinformal

requirements


library






combination




Validation


SIPN Editor

SIPN Compiler


Controller Design

Formalspecification


plantinformal

requirements


library






combination




Validation


SIPN Editor

SIPN Compiler


Figure 8-5: Design and Validation Process.

The PLC user program, i.e. the control algorithm, is automatically compiled into a Petri Net. To al-

low this automatic compilation, the program has to be written in a subset of Instruction List called IL0 [Heiner and Menzel 1997, Heiner and Menzel 1998 (a), Heiner and Menzel 1998 (b)]. The IL produced by the code generation of SIPN contains only instructions that are part of IL0 therefore a

8 Validation

116

combination of the two approaches is straightforward. The Petri Net describing the controller is combined with Petri Net models of the PLC and its environment (plant-model or stochastic). The overall model is translated into an input-file for the model-checker, CMU SMV [CMU SMV] in this case, and used for validation.

The model of the PLC describes the PLC cycle with its different steps input-reading, execution, and

output-writing, for example the variable rdy_plc is set to TRUE whenever a PLC-cycle ends and the PLC is ready for new input.

For the formulation of requirements, the safety-oriented specification language (in German: „Si-

cherheitsfachsprache“ - SFS [Meier and Mertke 1999]) is used in the presented approach. SFS is an unambiguously defined subset of natural language. It is modeled after typical formulation styles of

control engineering to allow a semi-verbal formulation of typical requirements. The SFS has for-mally defined syntax and semantics based on temporal logic, allowing for an automatic translation of the language into temporal logic formulae. The main principle of SFS is to formulate the re-quirements in a conditional, i.e. in a sentence like „If a condition is fulfilled, then a reaction has to happen“. Temporal attributes like „immediately“, „simultaneous“, „sometimes“, or „never“ are also possible.

The process of model checking produces a path to the wrong states of the system if a property is not fulfilled. A one-to-one-to-one correspondence between binary variables in the model-checker input, the IL-program, and the SIPN allows the interpretation of the results at the original design.

For the air chamber benchmark the controller with five places presented in Figure 8-4 and an SIPN controller with six places have been used. After the first validation steps the symmetrical controller with six places was selected for further validation. Because of the symmetry, it was easier to correct errors (If there is a design error it should show up on two places in the design, whereas a minor er-ror like a typo in the firing conditions shows up only once). This symmetrical controller had the same structure as the one in Figure 8-6 but much simpler firing conditions.

Two models of the PLCs environment allow for non-model-based and model-based validation. The first model is completely stochastic, allowing all possible sequences and combinations of input sig-nals (resulting in a non-model-based validation). The second model is an abstraction of the plant's behavior. It includes the simulation of the pressure in the chamber and the generation of the sensor signals. The consummation of air and the compressor disturbances are of course still stochastic. In this model, there are no sensor failures.

The problem specific functional requirements are written using the SFS and then automatically translated into temporal logic. As an example, the SFS statement

While the pressure is above 6.1 bar motor 1 should not be turned on and motor 2 should not be turned on

results in the TL formula

SPEC AG ~(rdy_plc & (~i1) & (o1 | o2)).


117

T3: i1 ~i4 (~i2 + i3)

T16: i1 i2 ~i3 ~i4

T1: i1 ~i3 (~i2 + i4)

T13: ~i1 + i3 i4

T14: ~i1 + i3 i4

T7: i1 i2 ~i3 ~i4

T5: i1 i2 ~i3 ~i4

T18: i1 ~i3 i4

T6: i1 ~i4 (~i2 + i3)

T2: ~i1 + i3 i4

T4: ~i1 + i3 i4

T12: i1 i3 ~i4

T11: i1 ~i3 i4T10: i1 ~i3 i4

T9: i1 i3 ~i4

T8: i1 ~i3 (~i2 + i4)

T17: i1 i3 ~i4

T15: i1 i2 ~i3 ~i4

P1 PV_6: both off, ->Ao1 = 0; o2 = 0

P3 PV_4: both off, ->Bo1 = 0; o2 = 0

P5 PV_4: both on, ->Ao1 = 1; o2 = 1

P6 PV_5: both on, ->Bo1 = 1; o2 = 1

P2 PV_3: A on, ->Bo1 = 1; o2 = 0

P4 PV_5: B on, ->Ao1 = 0; o2 = 1

Figure 8-6: Symmetrical solution to the air chamber problem [Mertke and Frey 2001].

It is of course also possible to formulate standard functional properties using the SFS and therefore to do verification within this approach. However, it is not possible to verify the formal correctness of the original SIPN design, because properties like dynamical conflicts or undefined outputs are not preserved in the translation from SIPN to IL.

The validation showed that the initial specification was not complete. For example, it is not speci-fied how the controller should react in case of sensor failures (Should the compressors run or not, if the sensors imply that the pressure is above 6.1 bar AND below 5.9 bar at the same time?). Natu-rally, in the non-model-based case more properties are rejected during validation. During the valida-tion process, nearly all firing conditions of the initial SIPN had to be extended to take care for spe-

cial situations.

The combination of graphical controller design (using SIPN) and a semi-verbal specification lan-guage (SFS), frees the user from the effort to learn and understand most of the complicated formal-isms used for validation. The one-to-one-to-one correspondence between places in the SIPN, vari-ables in the IL-Code and variables in the formal model of the PLC-program used for validation al-

low the easy re-interpretation of validation results at the original design and therefore also the easy adjustment of this design.

8 Validation

118

8.5 Comparison and Concluding Remarks on Validation

This Chapter shows that the SIPN approach has two interfaces for the application of formal valida-tion–or also additional formal verification–methods. Additional formal methods can be applied to the SIPN directly as well as to the generated IL code. In both cases, the results can be interpreted in the original design because of the one-to-one correspondence of SIPN places to IL variables intro-duced in our code generation method. Using the SIPN directly, allows checking SIPN criteria that are not transferred to IL as for example the formally correct setting of output signals. The approach using IL on the other side validates the final PLC program including possible changes to the algo-rithm introduced by the selected method of code generation.

The point in formal validation that makes it interesting but also very complicated is that a non-fulfilled property may be due to an error in the controller or in the specification. Often the specifica-tion is not clear enough. The supposedly wrong state gives a hint on what special situation was not considered (for example sensor failures). Hence, during the development of the final correct con-troller the specification also evolves.

This is a common fact in validation and can be seen as one of the main reasons to use approaches like the ones presented here consisting of iterated design and validation steps in contrary to formal controller synthesis. The specification derived during the validation process is finally complete and consistent. Therefore, it is in a form that is suitable for formal, i.e. automatic, synthesis approaches. However, the original specification that serves as starting point for the validation is in almost all cases neither complete nor consistent and hence not usable for automatic synthesis.

119

9. Summary

9.1 Summary in English

In automation, more and more tasks formerly assigned to special hardware are solved by software today. Therefore, the development of this software, i.e. the logic control algorithms, is an increas-ingly important area of automatic control. The rising complexity of the control problems and the in-

creasing demands on their functionality and reliability lead to the application of formal methods in design, verification, and validation. At the same time, the re-use of existing control programs and

their frequent adaptation to changed user demands necessitates easy to understand algorithms. Be-cause understandability is a pre-condition for re-usability and changability.

The development process of logic control algorithms is investigated from two different points of

view. From Control Theory, on the one side, we learn that there is a multitude of formal methods developed for the verification and validation of controllers. Software Engineering, on the other side

provides formal approaches for the evaluation of an algorithm’s quality. The quality concepts de-veloped in Software Engineering not only cover functional properties like the ones dealt with in

verification and validation but also non-functional ones like the understandability of an algorithm. The combination of the ideas from those distinct fields leads to the controller development process proposed in this thesis. Namely a formal approach that allows verification, validation, and evalua-tion of logic control algorithms based on a single formal model.

As formal model, the Signal Interpreted Petri Net (SIPN) is proposed for the design of logic con-

trollers. The advantage of this graphical formalism is that it is close enough to formalisms already in use in controller design to allow its practical application but also defined strictly enough to allow formal analysis.

The discussion of standard functional properties generally used in the verification of logic control-lers leads to the definition of formal correctness criteria for SIPN and the description of corre-sponding methods to verify them.

Based on a further investigation of the quality demands in logic control, non-functional properties

are specified that describe the understandability of a control algorithm. The formalization of these non-functional properties results in the definition of a transparency metric. The results of an ex-perimental study show that the proposed metric is appropriate for the evaluation of a controller’s quality.

The implementation of logic control algorithms is mostly based on languages according to IEC

61131-3. The presented method for the automatic implementation of SIPN using Instruction List according to this standard guarantees that the behavior of the SIPN is correctly realized on a PLC.

To check problem specific functional properties, the application of formal validation methods is

recommended. Two formal validation approaches for SIPN algorithms proposed in the literature are described and illustrated at a benchmark example.

The practical application of the presented approach is supported by a software tool and illustrated at

the model of a flexible manufacturing line.

9 Summary

120

9.2 Kurzfassung in deutscher Sprache

Motivation

In der heutigen flexiblen, variantenreichen, automatisierten Fertigung wird die Erstellung der Steue-rungssoftware für die eingesetzten Maschinen und Anlagen immer mehr zu einem entscheidenden

Zeit- und Kostenfaktor. Die zunehmende Komplexität dieser Software und die gleichzeitig steigen-den Anforderungen bezüglich Funktionalität und Zuverlässigkeit bedingen den Einsatz formaler

Methoden im Steuerungsentwurfsprozess. Der Einsatz formaler Methoden ermöglicht den Nach-weis spezifizierter Eigenschaften einer Steuerung und deckt dabei im Gegensatz zu Testverfahren (Simulation) alle möglichen Systemzustände ab.

Ein weiteres Problem bei der Steuerungsentwicklung sind die immer kürzer werdenden Produktzyk-len in der Fertigung. Diese bedingen häufige Anpassungen der Steuerungssoftware an neue Produk-

tionsszenarien. In vielen Fällen steht der Entwickler der ursprünglichen Steuerungsalgorithmen da-bei nicht mehr zur Verfügung. Um einem neuen Entwickler den Einstieg in ein bestehendes System zu ermöglichen ist es von entscheidender Bedeutung, dass die Steuerung gut dokumentiert und leicht verständlich ist. Deshalb wird eine Methode benötigt, die eine Evaluation der Qualität einer Steuerung in Bezug auf ihre Verständlichkeit erlaubt.

Eine Möglichkeit zur Verbesserung des Steuerungsentwicklungsprozesses durch formale Methoden bieten der Einsatz von Petrinetzen [Desrochers and Al-Jaar 1994]. Im Steuerungsbereich gibt es zwei Petrinetz-basierte Zugänge:

• Petrinetze als Modellierungswerkzeug (Entwurf) und

• Petrinetze als Analysewerkzeug (Verifikation and Validierung).

In der vorliegenden Arbeit werden beide Ansätze kombiniert und durch einen dritten, neuen Ansatz

ergänzt:

• Petrinetze als grafisches Dokumentationswerkzeug (Evaluation).

Struktur der Arbeit

Den Ausgangspunkt der Arbeit bildet Kapitel 2 mit der Betrachtung des Steuerungsentwicklungs-prozesses aus zwei verschiedenen Richtungen, der Sichtweise der Steuerungstheorie und der des

Software Engineering. Die Verbindung der beiden Sichtweisen resultiert in der in Abbildung 9-1 dargestellten Struktur des Steuerungsentwicklungsprozesses. Diese Struktur dient auch gleichzeitig als Grundlage für den weiteren Aufbau der Arbeit.


121

Informelle Spezifikation

Synthese(Entwurf bzw. Design)

Steuerungs-algorithmus

(SIPN)

Verifikation(Formale Korrektheit)

Evaluation(Transparenz)

SIPN + Verifikations-ergebnisse

Korrektur(Re-Design)

SIPN + Evaluations-ergebnisse

Implementierung(Code-Generierung)

Realisierung(SPS-Programm)

Entwurfs-verbesserung

funktionale Standard-

eigenschaften

nicht-funktionale

Eigenschaften

Auswahl funktionaler Standard-

eigenschaften

formalisierte funktionale Standard-

eigenschaften

Auswahl und Gewichtung nicht-

funktionaler Eigenschaften

formalisierte nicht-

funktionale Eigenschaften

Validierung

Validierung

Informelle Spezifikation

Synthese(Entwurf bzw. Design)

Steuerungs-algorithmus

(SIPN)

Verifikation(Formale Korrektheit)

Evaluation(Transparenz)

SIPN + Verifikations-ergebnisse

Korrektur(Re-Design)

SIPN + Evaluations-ergebnisse

Implementierung(Code-Generierung)

Realisierung(SPS-Programm)

Entwurfs-verbesserung

funktionale Standard-

eigenschaften

nicht-funktionale

Eigenschaften

Auswahl funktionaler Standard-

eigenschaften

formalisierte funktionale Standard-

eigenschaften

Auswahl und Gewichtung nicht-

funktionaler Eigenschaften

formalisierte nicht-

funktionale Eigenschaften

Validierung

Validierung

Abbildung 9-1: Struktur der Arbeit (zugleich Steuerungsentwicklungsprozess).

9 Summary

122

Ausgehend von einer informellen Spezifikation der Steuerungsaufgabe beginnt der Steuerungsent-wicklungsprozess mit der Synthese der Steuerung (die Begriffe Entwurf und Design sind synonym zu Synthese). Für diesen Entwurfsschritt werden in der vorliegenden Arbeit Signal interpretierte Petrinetze (SIPN) vorgeschlagen. In Kapitel 3 wird die Theorie der SIPN eingeführt und Methoden für die Analyse von SIPN werden beschrieben.

Aufbauend auf der formalen Beschreibung des Steuerungsalgorithmus können funktionale Stan-dardeigenschaften formal nachgewiesen werden. Dieser Nachweis wird als Verifikation bezeichnet. Standardeigenschaften, wie beispielsweise Determinismus, sind unabhängig vom vorliegenden Steuerungsproblem und können deshalb auch formalisieret werden ohne die konkrete Aufgabe zu kennen. In Kapitel 4, werden Standardeigenschaften für Steuerungsalgorithmen definiert und for-malisiert.

Zunächst einmal muss ein Steuerungsalgorithmus in Bezug auf den gewählten Formalismus syn-taktisch korrekt spezifiziert sein. Diese Eigenschaft wird jedoch im Allgemeinen bei der Verifika-tion als gegeben vorausgesetzt, da die meisten Werkzeuge zum Entwurf von Algorithmen bereits automatische Syntaxüberprüfungen anbieten.

Die folgenden Eigenschaften beschreiben die formale Korrektheit [Frey and Litz 2000 (b)] eines Steuerungsalgorithmus. Diese geht weit über die syntaktischen Korrektheit hinausgeht. Die erste Eigenschaft fordert das deterministische Verhalten der Steuerung (auch Eindeutigkeit):

(P1) (zwingend) Jede Steuerung muss ein eindeutig festgelegtes Ein-/Ausgabe verhalten haben. Das bedeutet, dass die Definition des Steuerungsalgorithmus für jeden Zustand der Steuerung (a) die Reaktion auf beliebige mögliche Eingangssignalbelegungen festlegt und (b) einen Wert für jedes Ausgangssignal spezifiziert.

Eigenschaften wie P1 werden weithin als zwingend für die Funktion einer Steuerung angesehen und finden sich in ähnlicher Form in verschiedenen Arbeiten. [König and Quäck 1988, David and Alla 1992, Litz 1995, Jörns 1997]. Darüber hinaus werden drei weitere Standardeigenschaften spezifi-ziert, die nicht von jeder Steuerung erfüllt sein müssen:

(P2) Jeder Teil des Steuerungsalgorithmus sollte immer wieder durchlaufen werden können.

(P3) P3 ist eine abgeschwächte Version von P2: Eine Steuerung sollte niemals in einen Zustand

geraten, der nicht mehr verlassen werden kann.

(P4) Eine Steuerung sollte in der Lage sein ihren Ausgangszustand wieder zu erreichen.

Die gegebenen informellen Eigenschaften lassen sich für SIPN unabhängig vom Steuerungsalgo-rithmus formalisieren. Dabei werden sie auf die in Kapitel 3 eingeführten SIPN-Eigenschaften zu-rückgeführt (Tabelle 9-1).

Diese Formalisierung der Eigenschaften erleichtert die Verifikation für den Anwender der SIPN-Methode erheblich, da er nur noch festlegen muss welche der optionalen Eigenschaften geprüft werden sollen.


123

# Informelle Eigenschaft SIPN Eigenschaft

c1 Konfliktfreiheit

c2 Terminismus

c3 Vollständige Ausgaben

c4

P1 (zwingend)

Widerspruchsfreie Ausgaben

c5 P2 (optional) Lebendigkeit

c6 P3 (optional) Verklemmungsfreiheit

c7 P4 (optional) Reversibilität

Tabelle 9-1: Kriterien für formale Korrektheit.

Nicht-funktionale Eigenschaften von Steuerungsalgorithmen lassen sich für verschiedenen Aspekte der Steuerung formulieren. In der vorliegenden Arbeit erfolgt eine Beschränkung auf solche Eigen-schaften, die eine Bewertung des Algorithmus in Bezug auf seine Verständlichkeit erlauben. In Ka-pitel 5 werden dazu zunächst fünf Eigenschaften informell spezifiziert:

(P1) Ein Algorithmus sollte möglichst gut dokumentiert sein.

(P2) Sofern grafische Methoden zur Spezifikation benutzt werden, sollte die grafische Darstellung

möglichst klar sein.

(P3) Der Algorithmus sollte nicht zu viel redundante Information beinhalten.

(P4) Aus der formalen Beschreibung des Algorithmus sollte seine Funktion, mithin die Steue-rungsaufgabe, möglichst einfach ableitbar sein.

(P5) Der Algorithmus sollte nicht komplexer sein als unbedingt erforderlich..

Die Formalisierung dieser Eigenschaften führt auf die Definition einer Transparenzmetrik, die ih-

rerseits aus zehn Teilmetriken aufgebaut ist.

Da das Transparenzkonzept einen vollkommen neuen Zugang in der Steuerungstechnik darstellt, wurde seine Gültigkeit durch eine empirische Studie nachgewiesen. In Kapitel 6 wird die durchge-

führte Studie im Kontext der Theorie, die für solche Experimente im Bereich des Software Enginee-ring entwickelt wurde, beschrieben.

Den Abschluss des Entwicklungsprozesses einer Steuerung bildet die Implementierung auf einer speicherprogrammierbaren Steuerung. Zu diesem Zweck wird in Kapitel 7 eine Methode zur auto-matischen Übersetzung von SIPN in Anweisungsliste (AWL) nach IEC 61131-3 vorgestellt.

Zur Vervollständigung der Arbeit werden in Kapitel 8 zwei Ansätze zur Validation, d.h. zum Nachweis aufgabenspezifischer funktionaler Eigenschaften, von SIPN-Algorithmen diskutiert. Es

9 Summary

124

handelt sich dabei um einen Ansatz der direkt auf dem SIPN aufbaut [Weng and Litz 2001] und ei-nen zweiten der vom erzeugten AWL-Code ausgeht [Mertke and Frey 2001].

Neue und wichtige Beiträge der Arbeit

Grundsätzlich unterscheidet sich der in der Arbeit vorgeschlagene Ansatz zur formalen Entwick-lung von Steuerungsalgorithmen von anderen Zugängen dadurch, dass nicht nur Konzepte aus der Steuerungstheorie sondern auch solche aus dem Bereich des Software Engineering verwendet wer-

den. Die dadurch mögliche Bewertung entwickelter Algorithmen hinsichtlich ihrer Verständlich-keit, Stichwort Transparenz, stellt eine wesentliche Ergänzung bekannter Ansätze dar.

Die Theorie der Signal interpretierten Petrinetze (SIPN) wird in der vorliegenden Arbeit streng formal entwickelt und zusammenfassend dargestellt. Besonders die formale Definition einer Algeb-ra zur Berechnung der Ausgangssignale eines SIPN unterscheidet die gewählte Beschreibung von

bekannten, semi-formalen Definitionen. Erstmals wird auch eine formale Definition für hierarchi-

sche SIPN (SIPNH) angegeben. Diese wird ergänzt von Verfahren zu deren Analyse die über das

von anderen Petrinetzansätzen bekannte entfalten der Hierarchie hinausgehen. Die vorgeschlagenen Definitionen erlauben die Definition entsprechender Erreichbarkeitsgraphen und die Beschreibung

der zu ihrer Berechnung nötigen Algorithmen. Diese Erreichbarkeitsgraphen bilden den Schlüssel für die spätere Analyse eines SIPN.

Eine eingehende Untersuchung der dynamischen Eigenschaften der SIPN zeigt die gravierenden

Unterschiede zu gewöhnlichen Petrinetzen. Diese Unterschiede sind durch die Schaltregel des SIPN bedingt, die das gleichzeitige Schalten mehrerer Transitionen erlaubt. Zur Beschreibung dieses Verhaltens wird der Begriff der dynamischen Synchronisation (DS) eingeführt. In Abhängigkeit von DS lässt sich die Beziehung eines SIPN zu dem ihm unterlagerten gewöhnlichen Petrinetz beschrei-ben. Insbesondere ist es möglich Bedingungen für die Übertragbarkeit von Netzeigenschaften wie Lebendigkeit oder Konfliktfreiheit vom einen auf das andere Modell anzugeben.

Die vorgestellte Definition und Formalisierung funktionaler Standardeigenschaften für SIPN stellt eine Anpassung bekannter Kriterien dar. Die Definition nicht-funktionaler Eigenschaften und ihre Formalisierung in einer Transparenzmetrik ist hingegen ein vollständig neuer Ansatz. Die Gültig-keit der Transparenzmetrik wurde deshalb anhand einer empirischen Studie validiert.

Schließlich erlaubt die formale Definition der SIPN und ihrer hierarchischen Erweiterung die Spezi-fikation verbesserter Methoden zur automatischen Implementierung von SIPN-Algorithmen in An-weisungsliste nach IEC 61131-3.

10. Bibliography and Indices

10.1 Bibliography [Atteslander 2000] P. Atteslander

Methoden der empirischen Sozialforschung 9th Edition, Walter de Gruyter, Berlin, New York, 2000.

[Baccelli et al. 1992] F.L. Baccelli, G. Cohen, G.J. Olsder, and J.P. Quadrat Synchronization and Linearity (An algebra for discrete event systems) John Wiley & Sons, Chichester, 1992.

[Basili 1993] V.R. Basili The experimental paradigm in software engineering H.D. Rombach, V.R. Basili, and R.W. Selby (Editors), Experimental Software Engineering Issues: A critical assessment and future directions, Springer LNCS 706, pp. 3-12, 1993.

[Basili et al. 1986] V.R. Basili, R.W. Selby, and D.H. Hutchens Experimentation in software engineering IEEE Trans. on Software Engineering, SE-12(7), pp. 733-743, July 1986.

[Benveniste and Berry 1991] A. Benveniste and G. Berry The Synchronous Approach to Reactive and Real-Time Systems Proceedings of the IEEE, Vol. 79, No. 9, pp. 1270-1282, 1991.

[Benveniste and Le Guernic 1990] A. Benveniste and P. Le Guernic Hybrid Dynamical Systems Theory and the SIGNAL Language IEEE Trans. on Automatic Control, Vol. 35, No. 5, pp. 525-546, 1990.

[Berard et al. 2001] B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, and P. Schnoebelen Systems and software verification, model-checking techniques and tools Springer, Berlin, New York, 2001.

[Boehm 1979] B.W. Boehm Guidelines for Verifying and Validation Software Requirements and De-sign Specifications P.A. Samet (Editor), Proc. EURO IFIP 79, North-Holland Publishing Company, Amsterdam/New York, pp. 711-719, Sept. 1979.

[Bosch 2000] K. Bosch Elementare Einführung in die angewandte Statistik 7th Edition, Friedrich Vieweg & Sohn, Braunschweig/Wiesbaden, 2000.

[Both et al. 2001] T. Both, H.-M. Hanisch, S. Karras Model-based Design and Code Generation for Control Proc. 5th World Multiconference on Systems, Cybernetics and Informat-ics, SCI 2001, Orlando (FL), CD-ROM paper IS0014505.pdf, July 2001.

[Canet et al. 2000] G. Canet, S. Couffin, J.-J. Lesage, A. Petit and P. Schnoebelen Towards the automatic verification of PLC programs written in instruc-tion list Proc. IEEE Conference on Systems Man and Cybernetics, SMC'2000, Nashville (TN), pp. 2449-2454, Oct. 2000.

[Christensen 1998] J.H. Christensen Figure on International Language Standardization PLCopen Standard Presentation V1.0, 1998.

10 Bibliography and Indices

126

[Christensen 2000] J.H. Christensen Basic Concepts of IEC 61499 Proc. of Fachtagung Verteilte Automatisierung, Magdeburg (Germany), pp. 55-62, 2000.

[Ciolkowski et al. 1997] M. Ciolkowski, C. Differding, O. Laitenberger, and J. Münch Empirical Investigation of Perspective-Based Reading: A Replicated Ex-periment IESE-Report 048.97/E, Dec. 1997. http://www.iese.fhg.de/pdf_files/iese-048_97.pdf

[Clarke et al. 1999] E. M. Clarke, O. Grumberg, D.A. Peled Model Checking MIT Press, Cambridge (MA), 2nd Print, 2000.

[Cutts and Rattigan 1992] G. Cutts and S. Rattigan Using Petri Nets to Develop Programs for PLC Systems Proc. Conference on Application and Theory of Petri Nets 1992, Springer LNCS 616, pp. 368-372, 1992.

[David 1995] R. David Grafcet: A Powerful Tool for Specification of Logic Controllers IEEE Trans. on Control Systems Technology, Vol. 3. No. 3, pp. 253-268, Sept. 1995.

[David and Alla 1992] R. David and H. Alla Petri Nets and Grafcet - Tools for Modeling Discrete Event Systems Prentice Hall, New York, London, 1992.

[Desrochers and Al-Jaar 1994] A.A. Desrochers and R.Y. Al-Jaar, 1994 Application of Petri Nets in Manufacturing Systems: Modelling, Control, and Performance Analysis IEEE Press, Piscataway, USA, 1994.

[Dierks 1997] H. Dierks PLC-Automata: A New Class of Implementable Real-Time Automata M. Bertran and T. Rus (Editors), Transformation-Based Reactive Systems Development, ARTS’97, Springer LNCS 1231, pp. 111-125, 1997.

[Dierks 1999] H. Dierks Synthesizing Controllers from Real-Time Specifications IEEE Trans. on Computer-Aided Design of Integrated Circuits and Sys-tems, 18(1), pp. 33-43, 1999.

[Fenton and Pfleeger 1996] N.E. Fenton and S.L. Pfleeger Software Metrics: A Rigorous & Practical Approach 2nd Edition, International Thomson Computer Press, London, 1996.

[Frey 2000 (a)] G. Frey Automatic Implementation of Petri Net based Control Algorithms on PLC Proc. American Control Conference, ACC 2000, Chicago (IL), pp. 2819-3823, June 2000.

[Frey 2000 (b)] G. Frey Analysis of Petri-Net based Control Algorithms—Basic Properties Proc. American Control Conference, ACC 2000, Chicago (IL), pp. 3172-3176, June 2000.

[Frey 2000 (c)] G. Frey PLC Programming for Hybrid Systems via Signal Interpreted Petri Nets Proc. 4th International Conference on Automation of Mixed Processes, ADPM 2000, Dortmund (Germany), pp. 189-194, Sept. 2000.

10.1 Bibliography

127

[Frey 2001 (a)] G. Frey Experiment for the Validation of Transparency Metrics, Part A: Test Problems - Formal Correctness Analysis - Solutions (EVTM-A) Revised 2nd Edition. Reports of the Institute of Automatic Control, I14/2001, University of Kaiserslautern, Germany, Oct. 2001. http://www.eit.uni-kl.de/litz/members/frey/PDF/I14.pdf

[Frey 2001 (b)] G. Frey Experiment for the Validation of Transparency Metrics, Part B: Work-Sheets and Result Tables (EVTM-B) Revised 2nd Edition. Reports of the Institute of Automatic Control, I15/2001, University of Kaiserslautern, Germany, Oct. 2001. http://www.eit.uni-kl.de/litz/members/frey/PDF/I15.pdf

[Frey 2001 (c)] G. Frey Experiment for the Validation of Transparency Metrics, Part C: Evalua-tion of the Results (EVTM-C) Reports of the Institute of Automatic Control, I16/2001, University of Kaiserslautern, Germany, Oct. 2001. http://www.eit.uni-kl.de/litz/members/frey/PDF/I16.pdf

[Frey 2001 (d)] G. Frey SIPN, hierarchical SIPN, and Extensions Reports of the Institute of Automatic Control, I19/2001, University of Kaiserslautern, Germany, Dec. 2001. http://www.eit.uni-kl.de/litz/members/frey/PDF/I19.pdf

[Frey and Litz 1997] G. Frey and L. Litz Transparenter Steuerungsentwurf mit SFC nach IEC 1131-3 Proc. SPS/IPC/Drives’97, Nürnberg (Germany), pp. 240-249, Nov. 1997.

[Frey and Litz 1998] G. Frey and L. Litz Verification and Validation of Control Algorithms by Coupling of Inter-preted Petri Nets Proc. IEEE Conf. on Systems Man and Cybernetics, SMC’98, San Diego (CA), pp. 7-12, Oct. 1998.

[Frey and Litz 1999] G. Frey and L. Litz A measure for transparency in net based control algorithms Proc. IEEE Conf. on Systems Man and Cybernetics, SMC’99, Tokyo (Ja-pan), Vol. 3, pp. 887-892, Oct. 1999.

[Frey and Litz 2000 (a)] G. Frey and L. Litz Transparency Analysis of Petri Net based Logic Controllers—A Measure for Software Quality in Automation Proc. American Control Conference, ACC 2000, Chicago (IL), pp. 3182-3186, June 2000.

[Frey and Litz 2000 (b)] G. Frey and L. Litz Correctness Analysis of Petri Net Based Logic Controllers Proc. American Control Conference, ACC 2000, Chicago (IL), pp. 3165-3166, June 2000.

[Frey and Litz 2000 (c)] G. Frey and L. Litz Formal methods in PLC programming Proc. IEEE Conf. on Systems Man and Cybernetics, SMC 2000, Nashville (TN), pp. 2431-2436, Oct. 2000.

[Frey and Schettler 1998] G. Frey and H.-G. Schettler Algebraic Analysis of Petri Net based Control Algorithms Proc. IEE 4th Workshop on Discrete Event Systems, WoDES’98, Cagliary (Italy), pp. 94-96, Aug. 1998.


128

[Frey and Schmidt 2000] G. Frey and A. Schmidt Automatische Erzeugung von SPS-Programmen aus Petrinetzen Proc. Fachtagung Verteilte Automatisierung, VA 2000, Magdeburg (Ger-many), pp. 177-184, Mar. 2000.

[Frey et al. 2000] G. Frey, L. Litz, and F. Klöckner Complexity Metrics for Petri Net Based Logic Control Algorithms Proc. IEEE Conference on Systems Man and Cybernetics, SMC 2000, Nashville (TN), pp. 1204-1209, Oct. 2000.

[Gong and Schmidt 1985] H. Gong and M. Schmidt A Complexity Measure Based on Selection and Nesting ACM SIGMETRICS-Performance Evaluation Review, V13, No. 1, pp.14-19, June 1985.

[Gordon and Melham 1993] M.J.C Gordon. and T.F. Melham Introduction to HOL Cambridge University Press, 1993.

[Gunnarson 1996] J. Gunnarson Algebraic Methods for Discrete Event Systems - A Tutorial Proc. IEE 2nd Workshop on Discrete Event Systems, WoDES’96, Edin-burgh (GB), pp. 18-24, Aug. 1996.

[Halang 2000] W.A. Halang Programmable Control on the Safety Integrity Levels 3 and 4 4th International Symposium „Programmable Electronic Systems in Safety Related Applications“, Cologne, CD-ROM paper No. 6, May 2000.

[Halbwachs 1993] N. Halbwachs Synchronous Programming of Reactive Systems Kluwer, Norwell (MA), 1993.

[Halstead 1977] M.H. Halstead Elements of Software Science Elsevier, New York, 1977.

[Hanisch et al. 1998] H.-M. Hanisch, A. Lüder, and J. Thieme A Modular Plant Modeling Technique and Related Controller Synthesis Problems Proc. IEEE International Conference on Systems Man and Cybernetics, SMC’98, San Diego (CA), pp. 686-691, Oct. 1998.

[Hanisch et al. 1999] H.-M. Hanisch, T. Pannier, D. Peter, S. Roch and P. Starke Modeling and verification of a modular level-crossing controller design Automatisierungstechnik – at, 47(1999)8, Special Issue on the Occasion of ECC’99 in Karlsruhe, Oldenbourg Verlag, pp. 366-373.

[Hassapis et al. 1998] G. Hassapis, I. Kotini, and Z. Doulgeri Validation of a SFC software specification by using hybrid automata Preprints of the 9th IFAC-Symposium on Information Control in Manufac-turing, INCOM’98, Nancy-Metz, Vol. II, pp. 65-70. June 1998.

[Heiner and Menzel 1997] M. Heiner, T. Menzel Petri-Netz-Semantik für die SPS-Anwenderprogrammiersprache Anwei-sungsliste BTU-Cottbus Technical Report I-20/1997, Cottbus, Dec. 1997.

[Heiner and Menzel 1998 (a)] M. Heiner, T. Menzel A Petri Net Semantics for the PLC Language Instruction List Proc. IEE 4th Workshop on Discrete Event Systems, WoDES’98, Cagliary (Italy), pp. 161-166, Aug. 1998.

10.1 Bibliography

129

[Heiner and Menzel 1998 (b)] M. Heiner and T. Menzel Instruction List Verification Using a Petri Net Semantics Proc. IEEE International Conference on Systems Man and Cybernetics, SMC 1998, San Diego (CA), pp. 716-721, Oct. 1998.

[Heiner et al. 1997] M. Heiner, H. Meier, T. Menzel, and T. Mertke Petri-Netz basierte Methoden zur sicherheitsorientierten Zertifizierung von SPS Anwenderprogrammen BTU-Cottbus, Technical Report I-19/1997, Cottbus, Dec. 1997.

[Henzinger 1996] T.A. Henzinger The Theory of Hybrid Automata Proc. 11th Annual IEEE Symposium on Logic in Computer Science, IEEE Computer Society Press, pp. 278-292, July 1996.

[Henzinger 1998] T.A. Henzinger It’s about time: real-time logics reviewed Proc. 9th International Conference on Concurrency Theory (CONCUR 1998), Springer LNCS 1466, pp. 439-454, 1998.

[Höcker et al. 1994] H. Höcker, W.D. Itzfeld, M. Schmidt, and M. Timm Comparative Descriptions of Software Quality Metrics GMD-Studien Nr. 81, GMD Bonn, Germany, March 1994.

[Holloway and Krogh 1990] L.E. Holloway and B.H. Krogh Synthesis of feedback control logic for a class of controlled Petri Nets IEEE Trans. on Automatic Control, Vol. 35, No. 5, pp. 514-523, May 1990.

[Jalote 1997] P. Jalote An Integrated Approach to Software Engineering 2nd Ed., Springer, Berlin, New York, 1997.

[Jiménez-Fraustro and Rutten 1999] F. Jiménez-Fraustro and E. Rutten A synchronous model of the PLC programming language ST Proceedings of the Work In Progress session, 1st Euromicro Conference on Real-Time Systems, ERTS’99, York (GB), pp. 21-24, June 1999.

[John and Tiegelkamp 2001] K.-H. John and M. Tiegelkamp IEC 61131-3: Programming Industrial Automation Systems Springer, Berlin, New York, 2001. (Also available in German under the Title „SPS- Programmierung mit IEC 61131-3“, 3rd Ed., Springer, 2000.)

[Jörns 1996] C. Jörns Transparent Representation of Information Flow in Automatic Control Systems for Verification Purposes Proc. 2nd IEE Workshop on Discrete Event Systems, WoDES’96, Edin-burgh (GB), pp. 368-373, Aug. 1996.

[Jörns 1997] C. Jörns Ein integriertes Steuerungsentwurfs- und Verifikationskonzept mit Hilfe interpretierter Petri-Netze Fortschrittsberichte VDI Reihe 8 Nr. 641, VDI Verlag, Düsseldorf, 1997.

[Jörns et al. 1995] C. Jörns, L. Litz, and S. Bergold Automatische Erzeugung von SPS-Programmen auf der Basis von Petri-Netzen Automatisierungstechnische Praxis – atp, 37(1995)3, Oldenbourg Verlag, pp. 10-14. 1995.


130

[Klein 2001] S. Klein A case study in design and formal verification of control algorithms using interpreted Petri Nets and SFC D.E.A. de Production Automatisée, Ecole Normale Supérieure Cachan, June 2001.

[Klein and Raisch 1998] E. Klein and J. Raisch Safety Enforcement in Process Control Systems – Batch Evaporator Ex-ample Proc. IEE 4th Workshop on Discrete Event Systems, WoDES’98, Cagliary (Italy), pp. 327-333, Aug. 1998.

[König and Quäck 1988] R. König and L. Quäck Petri-Netze in der Steuerungs- und Digitaltechnik Oldenbourg Verlag, München, Wien, 1988.

[Kotler 1999] P. Kotler Marketing-Management: analysis, planning, implementation, and control 10th Edition, Prentice Hall, Englewood Cliffs, 1999.

[Kotler and Bliemel 2001] P. Kotler and F. Bliemel Marketing-Management: Analyse, Planung, Umsetzung und Steuerung Adapted German Edition of [Kotler 1999] 10th Edition, Schäffer-Pöschel Verlag, Stuttgart, 2001.

[Kowalewski and Preußig 1996] S. Kowalewski and J. Preußig Verification of sequential controllers with timing functions for chemical processes Preprints of the 13th IFAC World Congress, San Francisco (CA), Vol. J, pp. 419-424, 1996.

[Lampérière-Couffin and Lesage 2000] S. Lampérière-Couffin and J.-J. Lesage Formal verification of the sequential part of PLC programs Proc. 7th IEE Workshop on Discrete Event Systems, WoDES 2000, Gent (Belgium), pp. 247-254; Aug. 2000

[Lampérière-Couffin et al. 1999] S. Lampérière-Couffin, O. Rossi, J.-M. Roussel and J.-J. Lesage Formal validation of PLC programs: A survey Proceedings of the European Control Conference, Karlsruhe (Germany), ECC’99, paper No. F741, Aug. 1999.

[Li and Wonham 1993] Y. Li and W.M. Wonham, Control of Vector Discrete-Event Systems I – The Base Model IEEE Trans. on Automatic Control, Vol. 38, No. 8, pp. 1214-1227, Aug. 1993.

[Litz 1995] L. Litz Entwurf industrieller Prozeßsteuerungen auf der Basis geeigneter Petri-Netz-Interpretationen E. Schnieder (Editor), Entwurf komplexer Automatisierungssysteme, Braunschweig, pp. 417-429, 1995.

[Litz and Frey 1998] L. Litz and G. Frey A Senior Course on Logic Process Control based on Petri Nets Proc. IEEE International Conference on Systems Man and Cybernetics, SMC’98, San Diego (CA), Vol. 1, pp. 274-277, Oct. 1998.

[Litz and Frey 1999] L. Litz and G. Frey Methoden und Werkzeuge zum industriellen Steuerungsentwurf - Historie, Stand, Ausblick. Automatisierungstechnik – at, 47(1999)4, Oldenbourg Verlag, pp. 145-156, Apr. 1999.

10.1 Bibliography

131

[McCabe 1976] T. McCabe A Complexity Measure IEEE Trans. on Software Engineering, SE-2, pp. 308-320, Dec. 1976.

[McMillan 1993] K.L. McMillan Symbolic Model Checking Kluwer, Norwell (MA), 1993.

[Meier and Mertke 1999] H. Meier and T. Mertke Eine Sicherheitsfachsprache zur Formulierung steuerungstechnischer An-forderungen Zeitschrift für wirtschaftlichen Fabrikbetrieb ZWF, 94(1999)11, Hanser Verlag, München, pp. 660-664, Nov. 1999.

[Mertke and Frey 2001] T. Mertke and G. Frey Formal Verification of PLC-programs generated from Signal Interpreted Petri Nets Proc. IEEE International Conference on Systems Man and Cybernetics, SMC 2001, Tucson (AZ), pp. 2700-2705, Oct. 2001.

[Mertke and Menzel 2000] T. Mertke and T. Menzel Methods and tools to the verification of safety-related control software Proc. IEEE International Conference on Systems Man and Cybernetics, SMC 2000, Nashville (TN), pp. 2455-2457, Oct 2000.

[Moon 1994] I. Moon Modelling Programmable Logic Controllers for Logic Verification IEEE Control Systems Magazine, pp. 53-59, Apr. 1994.

[Moon et al. 1992] I. Moon, G. Powers, J.R. Burch, and E.M. Clarke Automatic verification of sequential control systems using temporal logic AiCHE Journal, Vol. 38 (1), pp.67-75, Jan. 1992.

[Moor et al. 1998] T. Moor, J. Raisch, and S.D. O’Young Supervisory Control of Hybrid Systems via l-Complete Approximations Proc. IEE 4th Workshop on Discrete Event Systems, WoDES’98, Cagliary (Italy), pp. 426-431, Aug. 1998.

[Murrill 2000] P.W. Murrill Fundamentals of Process Control Theory ISA Press, 3rd Edition, 2000.

[Ostroff 1986] J.S. Ostroff Automated verification of timed transition models Proc. International Workshop on Automatic Verification Methods for Fi-nite State Systems, Springer LNCS 407, pp. 247-256, 1989.

[Patankar and Adiga 1995] A.K. Patankar, S. Adiga Entreprise integration modelling: a review of theory and practice Computer Integrated Manufacturing Systems Vol. 8-1, Elsevier Sience (Butterworth Heinemann), pp. 21-34, 1995

[Peled 2001] D.A. Peled Software Reliability Methods Springer, Berlin, New York, 2001.

[Peng and Zhou 2001] S.S. Peng and M.C Zhou Conversion between Ladder Diagrams and PNs in Discrete-Event Control Design - A Survey Proc. IEEE International Conference on Systems Man and Cybernetics, SMC 2001, Tucson (AZ), pp. 2682-2687, Oct. 2001.


132

[Petri 1962] C.A. Petri Kommunikation mit Automaten Dissertation, Universität Bonn, 1962.

[Probst 1996] S.T. Probst Chemical Process Safety and Operability Analysis Using Symbolic Model Checking Ph.D. Thesis, Carnegie Mellon University, 1996.

[Ramadge and Wonham 1989] P.J.G. Ramadge and W.M. Wonham The Control of Discrete Event Systems Proceedings of the IEEE, Vol. 77 No. 1, pp. 81-97, Jan. 1989.

[Rasch et al. 1999] D. Rasch, L.R. Verdooren, and J.I. Gowers Fundamentals in the Design and Analysis of Experiments and Surveys / Grundlagen und Auswertung von Versuchen und Erhebungen. Global Text (German and English), Oldenbourg Verlag, München, 1999.

[Rausch and Krogh 1998] M. Rausch and B.H. Krogh Formal Verification of PLC Programs Proc. of the American Control Conference, ACC’98, Philadelphia (PA), pp. 234-238, June 1998.

[Rausch et al. 1996] M. Rausch, A. Lüder, H.-M. Hanisch Combined Synthesis of Locking and Sequential Controllers Proc. 2nd IEE Workshop on Discrete Event Systems, WoDES’96, Edin-burgh (GB), pp. 133-138, Aug. 1996.

[Rechenberg 1986] P. Rechenberg Ein neues Maß für die Softwaretechnische Komplexität von Programmen Informatik Forschung und Entwicklung, Vol. 1. Springer, Heidelberg, pp. 26-37, 1986.

[Reisig 1982] W. Reisig A Primer in Petri Net Design Springer, Berlin, New York, 1982.

[Rombach 1991] H.D. Rombach Practical Benefits of Goal-Oriented Measurement B. Fenton and B. Littlewood (Editors), Software Reliability and Metrics. Elsevier Applied Science, pp. 217-235, 1991.

[Roussel and Lesage 1996] J.-M. Roussel and J.-J. Lesage Validation and Verification of Grafcet using finite state machine Proc. of IMACS-IEEE CESA’96, Lille (France), pp. 758-764, July 1996.

[Roussel et al. 1999] J.-M. Roussel, S. Lamperiere-Couffin, and J.-J. Lesage IEC 60848 et IEC 61131-1 : deux normes complémentaires Journée d’études Nouvelles percées dans les langages pour l’automatique SEE - Club 18, Amiens (France), Nov. 1999. ftp://ftp.lurpa.ens-cachan.fr/pub/Papers/1999/1999_see_JMR_SLC_JJL.pdf

[Scanlam 1989] D.A. Scanlam Structured flowcharts outperform pseudocode: an experimental compari-son IEEE Software, 6, pp. 28–36, September 1989.

[Sreenivas and Krogh 1991] R.S. Sreenivas and B.H. Krogh On Condition/Event Systems with Discrete State Realizations Discrete Event Dynamic Systems: Theory and Applications 1, Kluwer Academic Publishers, Boston, pp. 209-236, 1991.

10.1 Bibliography

133

[Stanton et al. 1996] M.J. Stanton, W.F. Arnold and A.A. Buck Modelling and Control of Manufacturing Systems using Petri Nets Proc. 13th IFAC World Congress, San Francisco (CA), Vol. J, pp. 329-334, 1996.

[Thistle and Wonham 1986] J.G. Thistle and W.M. Wonham Control Problems in a Temporal Logic Framework International Journal of Control, Vol. 44 (4), pp. 943-976, 1986

[Ticehurst and Veal 1999] G.W. Ticehurst and A.J. Veal Business research methods: a managerial approach Longman, London (Person Education, Australia), 1999.

[Tietjen 1986] G.L. Tietjen The Analysis and Detection of Outliers R.B. D’Agostino and M.A. Stephens (Editors), Goodness-of-Fit Tech-niques, Marcel Dekker, New York, Chapter 12, pages 497-522, 1986.

[Twiss and Zhou 1998] E. Twiss and M.C. Zhou Design of industrial automated system via relay ladder logic program-ming and Petri Nets IEEE Trans. on Systems, Man, and Cybernetics - Part C, Vol. 28, No. 1, pp. 137-150, 1998.

[Uzam 1998] M. Uzam Petri-net-based Supervisory Control of Discrete Event Systems and Their Ladder Logic Diagram Implementations Ph.D. Thesis, University of Salford, UK, 1998. http://www.muratuzam.kimdir.com/

[Uzam and Jones 1998] M. Uzam and A.H. Jones Discrete Event Control System Design using Automation Petri Nets and their Ladder Diagram Implementation Int. Journal of Advanced Manufacturing Systems, Special Issue on Petri Nets Applications in Manufacturing Systems, Vol. 14, No. 10, pp. 716-728, 1998.

[Venkatesh et al. 1995] K. Venkatesh, M.C. Zhou, and R.J. Caudill Discrete Event Control Design for Manufacturing Systems via Ladder Logic Diagrams and Petri Nets: A Comparative Study M.C. Zhou (Editor), Petri Nets in Flexible and Agile Automation, pp.265-304. Kluwer Academic Publishers, Boston, 1995.

[Völker 1998] N. Völker Ein Rahmen zur Verifikation von SPS-Funktionsbausteinen in HOL (Dissertation, FernUniversität Hagen), Shaker Verlag, Aachen, 1998.

[Völker 2000] N. Völker Towards a HOL Framework for the deductive Analysis of Hybrid Control Systems Proc. 4th International Conference on Automation of Mixed Processes, ADPM 2000, Dortmund (Germany), pp. 243-248, Sept. 2000.

[Völker and Krämer 1999] N. Völker and B.J. Krämer Modular Verification of Function Block Based Industrial Control Systems Proc. 24th IFAC/IFIP Workshop on Real-Time Programming, May 1999. http://www.fernuni-hagen.de/IT/wrtp99/papers/paper-018.html


134

[Weng and Litz 2000] X. Weng and L. Litz Verification of logic control design using SIPN and model checking—methods and case study Proc. American Control Conference, ACC2000, Chicago (IL), pp. 4072-4076, June 2000.

[Weng and Litz 2001] X. Weng and L. Litz Model Checking of Signal Interpreted Petri Nets Proc. IEEE International Conference on Systems Man and Cybernetics, SMC 2001, Tucson (AZ), pp. 2748-2752, Oct. 2001.

[Zuse 1998] H. Zuse A framework for software measurement Walter de Gruyter, Berlin, New York, 1998

Internet Resources

[Cadence SMV] K. McMillan: Homepage of the Cadence SMV–Symbolic model checker http://www-cad.eecs.berkeley.edu/~kenmcmil/

[CMU SMV] Homepage of the model checking tool SMV (Symbolic Model Verifier) at Carnegie Mellon University http://www.cs.cmu.edu/~modelcheck/code.html

[PLC History] Dick Morley: Homepage with information on the History of the PLC http://www.barn.org/FILES/historyofplc.html

[PLCopen] Website of PLCopen, a user organization that aims at establishing the IEC 61131 standard and defines additional compliance criteria and methods to certify PLC programming tools. http://www.plcopen.org

[V&V Web Form] Georg Frey: Website describing the classification scheme for V&V used in Chapter 2 with a web-form to propose further examples. http://www.eit.uni-kl.de/litz/ENGLISH/members/frey/VnVSurvey.htm

Standards

[ANSI/IEEE 610] ANSI/IEEE, Standard 610.12-1990, IEEE Glossary of Software Engineer-ing Terminology, 1991.

[IEC 60848] IEC, International Standard 60848, Preparation of Function Charts for Control Systems, 1988.

[IEC 61131-3] IEC, International Standard 61131: Programmable Logic Controllers, Part 3: Languages, 1992, Final Draft of the 2nd Edition, Apr. 2001.

[IEC 61499-1] IEC, 61499-1 (Voting Draft), Function blocks for industrial-process measurement and control systems – Part 1: Architecture, Mar. 2000.

[ISA S5.1] Instrument Society of America (ISA), ANSI/ISA-Standard S5.1: Instru-mentation Symbols and Identification, 1984, Reaffirmed 1992.

[ISO 8402] ISO, International Standard 8402 Quality Management and Quality As-surance-Vocabulary, 1994.

[ISO 9126] ISO/IEC, International Standard 9126, Information Technology - Software Evaluation. Quality Characteristics and Guidelines for their Use, 1991.

[IEC 61508-1] Draft International Standard IEC 61508-1: Functional Safety of Electri-cal/Electronic/Programmable Electronic Systems: Generic Aspects, Part 1: General Requirements, 1998.

10.2 Index of Definitions

135

10.2 Index of Definitions Definition 3-1: Ordinary Petri Net.................................................................................................................... 22

Definition 3-2: Pre- and Post-Sets .................................................................................................................... 22 Definition 3-3: Marking.................................................................................................................................... 23 Definition 3-4: Condition/Event-Net (C/E-Net)............................................................................................... 23 Definition 3-5: Place/Transition-Net (P/T-Net) ............................................................................................... 23

Definition 3-6: Reachability Set RS and Reachability Graph RG ................................................................... 24 Definition 3-7: Signal-Algebra......................................................................................................................... 28

Definition 3-8: Signal Interpreted Petri Net SIPN and underlying Petri Net PN(SIPN) ................................. 29 Definition 3-9: Reachability Set RSSIPN and Reachability Graph RGSIPN of an SIPN ..................................... 31

Definition 3-10: Possible Output ΩN of an SIPN ............................................................................................. 32

Definition 3-11: Reachability Graph RGPN(SIPN) and Reachability Set RSPN(SIPN) of PN(SIPN) ....................... 32 Definition 3-12: Augmented Reachability Graph aRGPN(SIPN) and Set aRSPN(SIPN) of PN(SIPN)..................... 33 Definition 3-13: Augmented Reachability Graph aRGSIPN and Set aRSSIPN of an SIPN.................................. 33

Definition 3-14: Dynamic Synchronization (DS)............................................................................................. 36 Definition 3-15: Petri Net Properties of SIPN.................................................................................................. 40

Definition 3-16: SIPN-Properties (Termination; specified, non-contradictory, formally correct Output) ...... 42 Definition 3-17: Hierarchical SIPN (SIPNH).................................................................................................... 46

Definition 3-18: Subnet in a hierarchical SIPN................................................................................................ 46 Definition 3-19: Extended Net of the top-level SIPN in an SIPNH.................................................................. 49 Definition 3-20 Extended Net of a subnet in an SIPNH ................................................................................... 49

Definition 3-21: Extended Set ES(SIPNH) ....................................................................................................... 50 Definition 5-1: Transparency Metric t1 (Comments) ....................................................................................... 68

Definition 5-2: Transparency Metric t2 (Directionality)................................................................................... 68 Definition 5-3: Transparency Metric t3 (Intersections) .................................................................................... 69

Definition 5-4: Transparency Metric t4 (Redundant Input) .............................................................................. 70 Definition 5-5: Transparency Metric t5 (Redundant Output) ........................................................................... 70 Definition 5-6: Transparency Metric t6 (Redundant Output Settings) ............................................................. 70 Definition 5-7: Transparency Metric t7 (Safety)............................................................................................... 71

Definition 5-8: Transparency Metric t8 (No Dynamic Synchronization) ......................................................... 71

Definition 5-9: Expression Complexity ECSIPN................................................................................................ 72 Definition 5-10: Transparency metric t9 (Low Expression Complexity) ......................................................... 73

Definition 5-11: Structural Complexity of PN ................................................................................................. 73 Definition 5-12: Hierarchical Complexity of SIPN.......................................................................................... 74 Definition 5-13: Unstructuredness of SIPN...................................................................................................... 74 Definition 5-14: Branching............................................................................................................................... 75

Definition 5-15: Net Complexity (NC) ............................................................................................................ 75 Definition 5-16: Transparency metric t10 (Low Net Complexity) .................................................................... 76

Definition 6-1: Experiment for the Validation of Transparency Metrics (EVTM).......................................... 83 Definition 6-2: Aim of EVTM (informal) ........................................................................................................ 83

Definition 6-3: Hypotheses to be checked in EVTM ....................................................................................... 84


136

10.3 Index of Tables Table 2-1: Software Characteristics of ISO/IEC 9126. .................................................................................... 16

Table 2-2: Software Characteristics applied to Logic Controller Design. ....................................................... 17 Table 3-1: Meaning of the symbols assigned to output signals in a single state.............................................. 25 Table 3-2: Product of output signals over the set 0, 1, -, c. .......................................................................... 25 Table 3-3: Meaning of the values of output signals in an SIPN summoned over several states...................... 26

Table 3-4: Sum of output signals over the set 0, 1, -, c, c-, d, d-.................................................................. 26 Table 3-5: Meaning of the symbols used in the signal algebra. ....................................................................... 27

Table 3-6: Complete multiplication table for output signals........................................................................... 28 Table 3-7: Complete summation table for output signals. ............................................................................... 28

Table 3-8: Relation of properties in the SIPN and the underlying PN............................................................. 40 Table 4-1: Criteria for formal correctness. ....................................................................................................... 62 Table 5-1: Expression complexity of firing conditions .................................................................................... 72

Table 5-2: Grouping of the transparency criteria. ............................................................................................ 77 Table 6-1: Classification of Experiments depending on the number of teams and projects involved. ............ 82

Table 6-2: The six parts of an experiment definition following [Basili et al. 1986]........................................ 83 Table 6-3: Example for the rejection of the combination of two accepted hypotheses. .................................. 84 Table 6-4: The five control problems used in the experiment.......................................................................... 87 Table 6-5: Aspects of the operation phase of an experiment. .......................................................................... 88

Table 6-6: Correlation Coefficients in EVTM (boldface for values |r| ≥ 0.9, italics for „surprising“ values). 91 Table 6-7: Data from the first problem in EVTM (means). ............................................................................. 94

Table 6-8: Differences between the means at different transparency. ............................................................. 94 Table 6-9: Nominal data, to be used in the Sign-Test. ..................................................................................... 94

Table 6-10: Result of the t-Test, to be used in the Sign-Test. .......................................................................... 95 Table 6-11: Sign-Test for the four hypotheses using only significant data...................................................... 96

Table 6-12: Tasks in the interpretation phase of an experimental study. ......................................................... 98 Table 7-1: Comparison of the Methods for Iteration...................................................................................... 109

10.4 Index of Figures Figure 1-1: Logic Controller Development Process also Structure of the Thesis.............................................. 3

Figure 2-1: Standardization in PLC programming. ............................................................................................ 5 Figure 2-2: Development process for logic control systems. ............................................................................. 6 Figure 2-3: Formal Specification and the methods based on it [Frey and Litz 2000 (c)]. ................................. 8

Figure 2-4: Software quality model of ISO 9126 with quality characteristics and sub- characteristics. ......... 15 Figure 3-1: Example of a PLC-program written in Ladder Diagram (LD)...................................................... 19

Figure 3-2: P&ID of a heating tank with tables of input and output signals.................................................... 20 Figure 3-3: SIPN example (heating tank controller). ....................................................................................... 21

Figure 3-4: PN with binary initial marking and its reachability graph as P/T-Net and as C/E-Net................. 24 Figure 3-5: SIPN with its Reachability graph. ................................................................................................. 32 Figure 3-6: Augmented reachability graph of the underlying PN. ................................................................... 33 Figure 3-7: Generating RGSIPN from RGPN(SIPN)................................................................................................ 34

Figure 3-8: Algorithm for the calculation of aRGSIPN and RGSIPN based on aRGPN(SIPN). ................................ 35 Figure 3-9: Example of SIPN with aRGPN(SIPN) and RGSIPN. ............................................................................ 36

10.4 Index of Figures

137

Figure 3-10: Strong Concurrent DS.................................................................................................................. 37

Figure 3-11: Strong Sequential DS................................................................................................................... 37 Figure 3-12: Examples of conflicts in Petri Nets. ............................................................................................ 38 Figure 3-13: Examples for the illustration of contacts in C/E-Nets and safety in P/T-Nets. ........................... 38 Figure 3-14: Four deadlock-free PN................................................................................................................. 39

Figure 3-15: SIPN that is neither live nor reversible though the underlying PN is live and reversible........... 42 Figure 3-16: Hierarchical refinement of Petri Nets .......................................................................................... 44

Figure 3-17: Unfolding of a hierarchical SIPN. ............................................................................................... 45 Figure 3-18: A subnet that is passive though it contains a token. .................................................................... 47

Figure 3-19: Algorithm for unfolding an SIPNH into a flat SIPN with the same behavior. ............................ 48 Figure 3-20: Connection to the environment for PN, Synchronized PN, and Interpreted PN. ........................ 51 Figure 3-21: Connection to the environment for the LCIPN according to König and Quäck and for SIPN. .. 52

Figure 3-22: Connection to the environment for the LCIPN model according to Jörns. ................................. 53 Figure 3-23: Connection to the environment for PN, Synchronized PN, and Interpreted PN. ........................ 53

Figure 3-24: Situations where the evolution in Grafcet differs from that in SIPN. ......................................... 55 Figure 3-25: SFC implementation of an unsafe SIPN...................................................................................... 56

Figure 3-26: Implementation of SIPN with sequential dynamic synchronization. .......................................... 57 Figure 3-27: SIPNH and corresponding SFC with SFC substructure. .............................................................. 57 Figure 4-1: Detailed description of verification. .............................................................................................. 59 Figure 4-2: SIPN that is not conflict-free. ........................................................................................................ 61

Figure 4-3: SIPN that does not terminate. ........................................................................................................ 61

Figure 4-4: SIPN with unspecified and contradictory defined output signals. ................................................ 62 Figure 4-5: Verification of SIPN. ..................................................................................................................... 63 Figure 5-1: Formal evaluation process. ............................................................................................................ 65

Figure 5-2: First SIPN (SIPN1) for the heating tank with corresponding reachability graph aRGSIPN............ 67 Figure 5-3: Second SIPN (SIPN2) for the heating tank with corresponding reachability graph aRGSIPN. ...... 67 Figure 5-4: Visualization of transparency metrics: Transparency diagram. .................................................... 78

Figure 5-5: Transparency diagrams for the example........................................................................................ 78 Figure 5-6: Evaluation process for SIPN.......................................................................................................... 79

Figure 6-1: Randomized block assignment in EVTM...................................................................................... 86 Figure 6-2: Assignment of projects to groups in EVTM.................................................................................. 88 Figure 6-3: Graphs showing the obvious correlation between the measured variables and Transparency. .... 92 Figure 7-1: SIPN example for code generation. ............................................................................................. 104

Figure 7-2: IL Program for the SIPN in Figure 7-1........................................................................................ 104

Figure 7-3: Program processing in a PLC. ..................................................................................................... 105 Figure 7-4: SIPN example for Iteration.......................................................................................................... 106

Figure 7-5: Application of the analytic ordering method. .............................................................................. 108 Figure 7-6: SIPN without partially ordered sequence-relation....................................................................... 108 Figure 8-1: Validation process in general....................................................................................................... 111 Figure 8-2: Compressed air accumulator (P&ID and I/O-Tables). ................................................................ 112

Figure 8-3: Coding of the control algorithm. ................................................................................................. 113 Figure 8-4: Non-symmetrical solution to the air chamber problem [Litz and Frey 1998]............................. 114

Figure 8-5: Design and Validation Process. ................................................................................................... 115 Figure 8-6: Symmetrical solution to the air chamber problem [Mertke and Frey 2001]. .............................. 117


138

10.5 List of often used Symbols and Abbreviations

General Notation

SETS are set in boldface italics upper-case set elements are set in italics lower-case (if they are not falling in one of the other categories) vectors are set in boldface lower-case TUPLES are set in plain upper-case scalars are set in plain lower-case

Symbols

¬, ~ Logical NOT

∧, ⋅ Logical AND

∨, + Logical OR

# Number of

Abbreviations

CTL Computational Tree Logic LTL Linear Temporal Logic C/E-Net Condition/Event-Net DS Dynamic Synchronization EVTM Experiment for the Validation of Transparency Metrics FBD Function Block Diagram IL Instruction List IPC Industrial Personal Computer

IPN Interpreted Petri Net LD Ladder Diagram

PC Personal Computer PLC Programmable Logic Controller PN Petri Net P/T-Net Place/Transition-Net SFC Sequential Function Chart SIPN Signal Interpreted Petri Net TL Temporal Logic SoftPLC Software PLC, a software running on a PC or a micro-controller emulating a PLC V&V Verification and Validation

Symbols used to describe Petri Nets

PN Petri Net m(p) Marking of a single place p mi A specific Marking of a Petri Net

10.5 List of often used Symbols and Abbreviations

139

m0 Initial marking of a Petri Net P Set of Places pi A specific Place T Set of Transitions ti A specific Transition F Set of Arcs (Flow Relation) fi A specific Arc Pm(mi) Set of marked places for a given marking mi

En(t, m) Enabling of a transition t under a marking m

•t Pre-set of a transition

t• Post-set of a transition

•p Pre-set of a place

p• Post-set of a place

Symbols used to describe Signal Interpreted Petri Nets

SIPN Signal Interpreted Petri Net PN(SIPN) Underlying Petri Net of a Signal Interpreted Petri Net O Set of Output Signal oi A specific Output Signal

I Set of Input Signals ii A specific Input Signal 3ti) Firing condition of a transition &pi) Output function of a place m) Output of an SIPN for a marking m N(SIPN) Possible Outputs of an SIPN summoned over all reachable markings

Symbols related to Hierarchical Signal Interpreted Petri Nets

SIPNH Hierarchical Signal Interpreted Petri Net

SIPNSub Underlying net in a Hierarchical Signal Interpreted Petri Net (SIPNH)U The unfolded SIPN corresponding to a SIPNH

SIPNExt Underlying net in a Hierarchical Signal Interpreted Petri Net

η Hierarchy function associationg places with underlying SIPN

pin Input-Place of an underlying SIPN pout Output-Place of an underlying SIPN

ES(SIPNH) Extended Set of an SIPNH

Symbols connected to Reachability

RS Reachability set (Set of vertices in the reachability graph) E Set of edges in the reachability graph RSU Set of unsafe states directly reachable from safe states in a Petri Net if the weak ena-

bling rule is used


140

EU Set of edges in the augmented reachability graph that lead to unsafe states RG Reachability graph aRG Augmented reachability graph RSSIPN Reachability set of an SIPN RGSIPN Reachability graph of an SIPN aRGSIPN Augmented reachability graph of an SIPN RSPN(SIPN) Reachability set of the underlying Petri Net of an SIPN RGPN(SIPN) Reachability graph of the underlying Petri Net of an SIPN aRGPN(SIPN) Augmented reachability graph of the underlying Petri Net of an SIPN

Symbols connected to the Evaluation of Transparency

T Combined Transparency Metric

ti Single Transparency Metric ec(ti) Expression Complexity of a single transitions firing condition

ECSIPN Expression Complexity of an SIPN NC Net Complexity

SCSIPN Structural Complexity of SIPN HCSIPN Hierarchical Complexity of SIPN MCCSIPN Unstructuredness of SIPN (McCabe’s number) BSIPN Branching of SIPN M Number of Modules in an SIPN C Number of Cycles in an SIPN

L Number of Levels in an SIPN |DP| Weighted number of Decision Places V Set of Vertices in a graph vi A single Vertex

|DV| Weighted number of Decision Vertices RGU Subgraph of a reachability graph

Symbols used in the Experiment Evaluation of Transparency

Hi Hypothesis Hi0 Null-Hypothesis m Mean r Correlation Coefficient rm Mean of Correlation Coefficients rmw Weighted Mean of Correlation Coefficients n Total number of elements of the sample z Number of positive differences

α Error Probability

kα α-quantile of the Binomial Distribution for p = ½

design and formal analysis of petri net based logic ... · design and formal analysis of petri net...

Documents