monitoring programmable logic controllers - autenticação · thesis to obtain the master of...

Monitoring Programmable Logic Controllers

Henrique de Almeida Gonçalves

Thesis to obtain the Master of Science Degree in

Electrical and Computer Engineering

Supervisor: Professor José António da Cruz Pinto Gaspar

Examination Committee

Chairperson: Professor João Fernando Cardoso Silva Sequeira

Supervisor: Professor José António da Cruz Pinto Gaspar

Member of the Committee: Professor Paulo Jorge Coelho Ramalho Oliveira

November 2015

Agradecimentos

Gostaria de agradecer ao meu orientador Professor José António Gaspar toda a disponibilidade

e apoio prestados no decorrer desta dissertação. Agradeço também ao Ricardo Nunes a disponi-

bilidade e ajuda que deu.

Quero agradecer aos meus pais por me terem possibilitado a realização do Mestrado em

Engenharia Electrotécnica e de Computadores e pelo apoio incondicional que sempre me deram.

Agradeço também o apoio da minha restante família e amigos. Atodos eles um muito obrigado.

Resumo

Os Sistemas de Eventos Discretos (DES) estão omnipresentesem aplicações industriais. Os

Controladores Lógicos Programáveis (PLC) são os dispositivos normalmente utilizados para

implementar DES em ambiente industrial. O desenho de um DES ea implementação em PLC

é um processo moroso que requer tipicamente múltiplas verificações e uma validação final.

A nossa abordagem de desenho de um DES envolve a utilização deredes de Petri (PN).

Como forma de agilizar a implementação do DES propomos converter automaticamente a PN

em código Structured Text (ST), i.e. uma linguagem standardde programação de PLCs. Desen-

volvemos um sistema de monitorização de PLC com o objectivo de verificar que um programa

PLC cumpre os requisitos desejados.

Neste relatório detalhamos a construção de hardware de monitorização de inputs e outputs

de um PLC. O custo do hardware é mantido baixo pela utilização de uma placa de microcon-

trolador Arduino Mega. Detalhamos também o desenvolvimento de hardware adicional para

interconectar o monitor ao PLC e a um processo que desejamos controlar.

O hardware desenvolvido e o DES implementado permitem observar o funcionamento do

PLC, por exemplo a variabilidade do tempo de um Scan Cycle, e validar a implementação de

um caso de estudo, nomeadamente um DES associado à leitura deum teclado.

Palavras chave:Monitor de Sinais, Sistemas de Eventos Discretos, Controlador Lógico Pro-

gramável, Arduino, Rede de Petri, Structured Text.

Abstract

Discrete Event Systems (DES) are ubiquitous in industrial applications. Programmable Logic

Controllers (PLC) are commonly used to implement DES. Designing a DES and implementing

in a PLC is a lengthy process typically requiring multiple verifications and an end process

validation.

Our approach to design a DES involves using Petri Nets (PN). Then we propose an automatic

conversion of the PN to Structured Text (ST) code, a standardPLC programming language.

With the objective of verifying that the PLC program fulfillsdesign specifications we develop a

PLC monitoring system.

Construction of a hardware PLC Signal Acquirer, able to monitor PLC inputs and outputs,

is detailed in this work. Cost is kept low by using the affordable microcontroller board Arduino

Mega. Development of additional hardware is also detailed,having the purpose of intercon-

necting the monitor with the PLC and the controlled plant.

With our hardware developed and DES implemented we show characteristics of the PLC

behavior, as the variability of the scan cycle time, and validate the DES implementation of a

keyboard reading case study.

Keywords: Signal Acquirer, Discrete Event Systems, Programmable Logic Controllers, Ar-

duino, Petri Net, Structured Text.

Contents

Agradecimentos i

Resumo iii

Abstract v

1 Introduction 1

1.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objectives and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . .. . 4

1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4

2 Discrete Event Systems 7

2.1 Petri Net Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Incidence Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Supervision based on Linear Constraints . . . . . . . . . . . .. . . . . 11

2.2.2 Generalized Linear Constraints . . . . . . . . . . . . . . . . . . .. . . 12

3 PLC Data Acquisition 19

3.1 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 PLC Input and Output Connections . . . . . . . . . . . . . . . . . . . . .. . . 21

3.3 PLC Input and Output Monitor . . . . . . . . . . . . . . . . . . . . . . . .. . 22

3.4 Data Acquisition Software . . . . . . . . . . . . . . . . . . . . . . . . .. . . 26

3.4.1 Arduino Monitoring Program . . . . . . . . . . . . . . . . . . . . . .26

3.4.2 PC Monitoring Program . . . . . . . . . . . . . . . . . . . . . . . . . 27

viii CONTENTS

4 PLC Program Development and Monitoring 29

4.1 DES Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

4.2 Petri net Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 30

4.3 Petri net to PLC Conversion . . . . . . . . . . . . . . . . . . . . . . . . . .. 31

4.3.1 Petri net to Structured Text Compiler . . . . . . . . . . . . . . .. . . 31

5 Case study: Keyboard Reading 35

5.1 Proposed Petri Net Model . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 36

5.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

6 Experiments 49

6.1 PLC Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49

6.2 Key detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Initial Marking Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 56

6.4 Supervisory Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59

7 Conclusion and Future Work 65

A Arduino Shield for IO Monitoring 67

B PN to PLC Compiler Usage 71

C PLC Program 75

D Arduino program 85

List of Figures

2.1 Example of a Petri net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

2.2 Example of a Petri net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 10

2.3 Example of a reachability tree and its Petri net . . . . . . . .. . . . . . . . . . 11

2.4 Consumer-Producer situation with underflow buffer . . . . .. . . . . . . . . . 14

2.5 Petri net for a producer-consumer type situation . . . . . .. . . . . . . . . . . 14

2.6 Petri net with consumer-producer supervisor . . . . . . . . .. . . . . . . . . . 16

2.7 Consumer-Producer situation with underflow and overflow buffer . . . . . . . . 16

2.8 Petri net for a producer-consumer system . . . . . . . . . . . . .. . . . . . . 17

3.1 Generic setup block diagram. . . . . . . . . . . . . . . . . . . . . . . .. . . . 20

3.2 24 volt DC power supply (a). Modicon PLC (b). Terminal with twelve key

numbered keyboard (c). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Printed circuit board prototype designed for keyboard terminal, front (b), back

(d). Printed circuit board prototype designed for monitoring alternative PLC,

front (a), back (c). Assembled printed circuit boards, for PLC (e), and for ter-

minal (f). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 PLC to terminal connections using final PCBs manufactured at Eurocircuits [6]. 22

3.5 Arduino based pass through logic observer and referencegenerator . . . . . . . 23

3.6 Arduino Mega, part of the signal monitor (a). Designed Arduino Mega shield

PCB (b). Assembled signal monitor shield for Arduino Mega (c). Signal moni-

tor composed by Arduino Mega and Arduino shield (d). . . . . . . .. . . . . . 25

3.7 Generic setup with signal monitor assembled. . . . . . . . . .. . . . . . . . . 26

3.8 Simplified code for Matlab serial communication with Arduino. . . . . . . . . 28

5.1 Plc and terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

5.2 Incidence Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

x LIST OF FIGURES

5.3 Table with pre and post conditions for Petri net evolution (a). Developed Petri

net (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4 Petri net column scanning evolution. . . . . . . . . . . . . . . . .. . . . . . . 39

5.5 Petri net one key pressed evolution. . . . . . . . . . . . . . . . . .. . . . . . 39

5.6 Reachability Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

5.7 Flag Petri net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.8 Flag Petri net method of operation. . . . . . . . . . . . . . . . . . . . . . . . 42

5.9 Flag Petri net incidence matrix. . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.10 Supervised system incidence matrix. . . . . . . . . . . . . . . .. . . . . . . . 45

5.11 Petri net developed for keyboard control, with supervisor. . . . . . . . . . . . . 46

6.1 Experimental setup for PLC characterization (a). Closeup view of developed

monitor (b). Closeup view of developed monitor (c). Signal flow diagram for

the first experiment (d). PLC square wave generation program(e). . . . . . . . 50

6.2 PLC output captured by the Arduino based monitor, multiple experiments, 5

scan cycles window, first rising edge in each window shifted to t = 0 (a). All

rising edges shifted tot = 0 (b). Observed scan cycle times along 8 seconds

(c). Histogram of observed scan cycle times (d). . . . . . . . . . .. . . . . . . 51

6.3 Observing the time from a signal input (rising edge%i0.3.0) to a signal out-

put (rising edge%q0.3.16). PLC input delay test code. (a). Connections

diagram (b). Observed PLC input to output delays along 8 seconds (c) and

histogram of the delays (d). . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52

6.4 Observing the time for 100ms period square signal detection. Connections dia-

gram (a). Observed PLC time of signal detection along 8 seconds (b). . . . . . 53

6.5 Varying scan cycle time. Minimum scan cycle time observed experimentally

(a). Maximum scan cycle time observed experimentally (b). .. . . . . . . . . 54

6.6 Setup used for experiments. Setup for monitoring PLC (a). Keyboard terminal

(b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.7 PLC output captured by the Arduino based monitor, input data key sequence

(a). Input data, sequence of keys (b). Expected output, MatLab Simulation (c).

PLC output observed with the developed monitor (d). . . . . . . .. . . . . . . 56

6.8 PLC output captured by the Arduino based monitor, input data key sequence

(a). Initial marking of Petri net (b). Expected output, MatLab Simulation (c).


LIST OF FIGURES xi

6.9 PLC output captured by the Arduino based monitor, initial marking of Petri net

(a). Expected output, MatLab Simulation (b). PLC output observed with the

developed monitor (c). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.10 PLC output captured by the Arduino based monitor, initial marking of Petri net

(a). Expected output, MatLab Simulation (b). PLC output observed with the

developed monitor (c). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.11 PLC output captured by the Arduino based monitor, inputdata key sequence

(a). Input data, sequence of keys (b). Expected output, MatLab Simulation (c).


6.12 PLC output captured by the Arduino based monitor, multiple experiments, in-

put data key sequence (a). Input data, sequence of keys (b). Expected output,

MatLab Simulation (c). PLC output observed with the developed monitor (d). . 62

A.1 Arduino shield electronic schematic. . . . . . . . . . . . . . . .. . . . . . . . 68

A.2 Arduino shield PCB schematic. . . . . . . . . . . . . . . . . . . . . . . .. . . 69

A.3 Arduino shield physical PCB, front. . . . . . . . . . . . . . . . . . . .. . . . 69

A.4 Arduino shield physical PCB, back. . . . . . . . . . . . . . . . . . . . .. . . 70

B.1 Create a PLC program from a Petri Net and IO mapping. . . . . . . .. . . . . 72

B.2 Load a Petri Net from file. . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

B.3 Define the mapping of PLC inputs to PN transitions. . . . . . . .. . . . . . . 73

B.4 Define the mapping of PN places to PLC outputs. . . . . . . . . . . .. . . . . 73

xii LIST OF FIGURES

List of Tables

4.1 plc_map_inputs ST compiler function description. . . . . . . . . . . . . . 32

4.2 plc_timed_transitions ST compiler function description. . . . . . . . 32

4.3 plc_encode_petri_net ST compiler function description. . . . . . . . . 33

4.4 plc_output_if_any_place ST compiler function description. . . . . . . 34

4.5 plc_encode_places ST compiler function description. . . . . . . . . . . . 34

5.1 DES events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 DES conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

xiv LIST OF TABLES

Chapter 1

Introduction

Major automation companies offer modular digital computers that allow using a large variety,

and number, of electrical input and/or output interfaces, the so called Programmable Logic

Controllers (the term, and its abbreviation PLC, are registered trademarks of the Allen-Bradley

Company, although nowadays they are widely used as a generic description1 ). Together with

the hardware, the automation companies also offer, or sell,monitoring software. The software

interfaces are however usually closed. Whenever one wants todebug a PLC program, develop-

ing fast monitors of the physical inputs and outputs of a PLC is normally challenging or even

impossible with the tools provided by default by the automation companies.

A PLC cyclically performs (i) signals input reading, (ii) program execution, and (iii) signal

output writing. This is comparable to the definition of a Discrete Event System (DES), in which

the event of receiving a digital input generates digital output.

In this work we propose a methodology for developing and debugging PLC programs based

in formalized Discrete Event Systems (DES). DES are systemswith dynamics driven by event

occurrences, at possibly unknown irregular intervals, of physical events. Such systems are used

in a variety of contexts, from computer operating systems tothe control of complex processes.

Each event occurs at a particular instant in time and marks a change of state in the system.

Petri nets (PNs) are one of the most suitable and used forms ofmathematical representation

of event driven systems (DESs, PLC programs handling digital I/O). A Petri net can usually

be designed by analyzing the structure and dynamic behaviorof a system to be modeled. This

information is essential to implement DESs with stability and robustness specifications.

In order to minimize the usually lengthy process of design toimplementation, we propose

converting automatically PN to Structured Text (ST), a standard programming language of a

1http://www.machine-information-systems.com/PLC.html

http://www.machine-information-systems.com/PLC.html

2 Introduction

PLC. The necessary design verifications and final validation are helped by an external hardware

device inserted between the PLC and the plant to control, monitoring the inputs and outputs of

the PLC.

1.1 Related Work

Petri net theory was continually developed since its beginnings with Dr. Petri’s 1962 Ph.D.

Dissertation[22]. But it was not until 1981, that Peterson [21] wrote the book that presented all

the development work scattered among many sources in a coherent and consistent manner.

In 1967 Naylor and Finger [18], proposed a multistage process of validation. This validation

method consists of (1) developing the model on theory, observations, and general knowledge;

(2) validating the model assumptions where possible by empirically testing them; and (3) com-

paring (testing) the input-output relationships of the model to the real system.

In 1979 Schlesinger [25], defined Model validation to mean substantiation that a computer-

ized model within its domain of applicability possesses a satisfactory range of accuracy consis-

tent with the intended application of the model.

In 1992 [3], Cutts and Rattigan addressed the fact that most PLCprogrammers develop

programs using Ladder Logic, that makes a situation with a very large number of logical inputs

and logical combinations, very hard to control. In particular, in these systems are very hard to

predict the results of illegal inputs such as damaged input switches or sensors, causing stable

systems to be unpredictable and the control plant to have an unwanted behavior due to jumped

sequences, deadlock and lost components. As a solution to this problem, Cutts and Rattigan [3],

proposed to use software based on Petri nets for as a practical approach to modeling systems

before being implemented on PLCs.

In 1996 Roussel and Lesage state [23] : "‘The verification is theproof that the internal se-

mantics 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."’

In 2002, Mertke and Frey [15], proposed a verification of PLC programs based on Petri nets.

Minas and Frey in 2002 [16], presented a graphical programming approach for PLCs based on

Petri nets. From their research and experience, they concluded that there was a need for a

PLC programing language 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." To implement this

1.1 Related Work 3

approach they have usedDiagen, an environment capable of developing diagrams based in

a formal specification of the diagram language. The created Petri nets can then be translated

to equivalent PLC programing language Instruction List (IL). In [24] Klein, Frey and Minas,

described a methodology used by their software to generatedIL code from a Petri net. First a

Boolean variable is declared for each place of the Petri net, its value depends on the presence

of a token in the place. For the transitions, they are tested for firing and for being enabled,

returning 1 if all conditions are fulfilled. If a place is marked then the corresponding output

function is executed, if not a conditional jump to the next place is performed. In [24] there

is reference to implementation of a process to visualize themachine state within the Petri net

editor while the machine is running. Making the editor able to find out failures or deadlocks.

In 2004 conformance test, testing a PLC system seen as a black-box (its internal structure

is unknown) with observable inputs/outputs, is advocated by certification bodies and standards

[8].

In 2005 [2], develops method for the automatic generation oftest scenarios from the behav-

ioral requirements of a DES, that generates a suite of test scenarios applicable for black box

testing.

In 2011 Sargent [14], made a study of the several validation techniques and tests commonly

used in model validation, and purposed a model for several steps for validation of simulation

models, in which it is necessary to make comparisons betweenthe simulation model and system

behavior data for at least a few sets of experimental conditions, and preferably for several sets.

In 2013, Pereira and Gomes [20], developed an Automatic Petri net to VHDL software2,

that can also be used to transform Petri nets into other typesof programming languages.

Also 2013 Vargas, Mellado and Lesage [5] [4], developed a software tool for building auto-

matically interpreted Petri net models from an observed system input/output sequence.

Moody and Antsaklis [17] wrote the book in the subject of supervisory theory of DES using

Petri nets, and later Iordache, Antsaklis and Marian [10, 11, 12], and then Iordache, Antsaklis,

Marian and Panos [9, 13] published many works on further development of the subject of su-

pervisory control. Most of the work done by Antsaklis was developed in the context of the ISIS

group3, in which he is the director.

2http://gres.uninova.pt/3http://www3.nd.edu/~isis/index.html

http://gres.uninova.pt/

http://www3.nd.edu/~isis/index.html

4 Introduction

1.2 Objectives and Challenges

Programmable logic controllers (PLCs) are the main integration equipment used in automation

today. The most commonly used PLC programming language is ladder diagram. The anima-

tion of the ladder diagram is usually the only form of code validation. Automation companies

available monitoring software is usually closed, making the development of fast monitors of the

physical inputs and outputs of a PLC, challenging or even impossible with the tools provided.

In this thesis we develop PLC monitoring with the objective of verifying that a PLC pro-

gram fulfills the design specifications. In other words, we want a design validation procedure

applicable to a discrete event system (DES) implemented in aPLC. We assume that the input

and output events during a finite amount of time are enough to characterize the DES. Hence, our

validation procedure will be based in observing input and output signals (events) of the DES.

Our approach for building and debugging a DES implemented with a PLC is the following:

(i) Design one PN solving the same problem that the DES will solve. In this step we avoid

some problems by design, e.g. not using unobservable transitions, preventing deadlocks, etc.

(ii) Simulating the PN and saving input and output signals. (iii) Encode the PN into a PLC

language. (iv) Compare simulation with real run.

Observing input and output events can be done to some extent using the PLC memory.

This is however limited by the free memory available in the PCLafter implementing the DES.

Alternatively, we propose logging input and output signalsusing external hardware, with a

sampling time shorter than the PLC scan cycle.

There are many publications focusing on process modeling, analysis and validation [3, 15,

16, 24, 26]. The common approach is modeling the system with aPetri net, and then generating

the ladder diagram from it. Petri nets deliver correct and dependable PLC programs.

In this work is proposed the construction of an hardware PLC Signal Acquirer, able to

monitor analyze and validate PLC programs. A hardware interface has the advantage of a much

higher operating frequency compared to a monitoring software. In addition, being an external

hardware interface, one has the guarantee that monitoring does not increase the memory/time

complexity of the PLC software.

1.3 Thesis Structure

Chapter 1 identifies the problem to approach in the thesis and proposes a path with theoretical

support. It also presents a short discussion on the state of the art of Petri nets and its application

in PLCs. Chapter 2 presents a theoretical introduction to Petri nets, its properties and methods

1.3 Thesis Structure 5

of analysis. Chapter 3 presents developed hardware for PLC monitoring. Chapter 4 presents

an approach to hardware PLC program development and monitoring based in Petri net theory.

Chapter 5 provides a theoretical analysis of our case study, base on Petri net theory and using

supervision control. Chapter 5 presents the experiments andrespective results obtained. Chap-

ter 6 summarizes the work performed, its achievements, and proposes further work to extend

the activities described in this document.

6 Introduction

Chapter 2

Discrete Event Systems

In this chapter we introduce Discrete Event Systems (DES). The structure of the introduction

is based in the course Industrial Processes Automation by Professor Paulo Oliveira [19]1 and in

books [21, 17, 1].

A DES can be characterized by a discrete state space whose state transitions happen at dis-

crete points in time due to events [1]. More in detail, the DESevolution, or state transition, is

a result of combining asynchronous and concurrent event processes. An event occurs instan-

taneously and causes transitions from one discrete state toanother. An event can be a specific

action taken (e.g. button pressed), a spontaneous occurrence dictated by nature (hardware fail-

ures), a sudden fulfillment of some conditions (e.g. buffer full).

DESs are usually implemented using Programmable Logic Controllers (PLCs). In generic

terms one PLC is composed of tree major parts, namely inputs,outputs and a control processor.

When an input changes, the control processor responds by changing an output. This can be

compared to the the state change that leads to an event occurrence in a DES.

2.1 Petri Net Language

Petri nets allow representing general DES, whose operationdepends on potentially complex

control schemes. In Petri nets, events change in accordanceto a set of rules. Graphically repre-

sentation of Petri nets, result in Petri net graphs that are intuitive and capture a lot of structural

information about the system. Analysis techniques have been developed for the studying of

Petri nets. These techniques include reachability analysis, well as linear-algebraic techniques.

Petri nets as representations of Discrete Event Systems have high degree of generality,

1https://fenix.tecnico.ulisboa.pt/disciplinas/APInd/2010-2011/1-semestre

https://fenix.tecnico.ulisboa.pt/disciplinas/APInd/2010-2011/1-semestre

8 Discrete Event Systems

specially when compared with used PLC programming languages, GRAFCET and Sequential

Function Chart (SFC). SFC and GRAFCET are both inspired from Petri nets and have compa-

rable structures. A live, safe, and reversible Petri net which has mutually exclusive transitions

can be implemented directly in SFC and GRAFCET.

A Petri net is represented graphically by:

• Transitions, events that can or not happen, graphically represented by bars.

• Places, conditions represented by circles.

• Oriented Arcs joining the circles and bars, conditions thatlead to events.

An arc can only connect transitions to places and vice-verse, there are no arcs connecting transi-

tions to transitions or places to places. Each place is associated with a natural number of marks.

The initial state representation, evolves according to a labeling transition function. The formal

definition of a Petri net is done in the next section.

2.1.1 Definition

A Petri net is a quintuplet, defined by parameters the parameters(P, T,A,W, x), where:

P = {p1, p2, ...pn}, n ≥ 0 P is a finite set of places;

(2.1)

T = {t1, t2, ...tm}, m ≥ 0 T is a finite set of transitions;

(2.2)

A ⊆ (P × T ) ∪ (T × P ) arcs that connect places to transitions and transitions to places;

(2.3)

W : A → {1, 2, 3, ...} is the weight function of the arches;

(2.4)

x = [x(p1), x(p2), ..., x(pn)] ∈ Nn represents the marking of places.

(2.5)

In describing Petri nets, places that are connected to the input of the transitiontj are represented

by I(tj). O(tj) represents places that are connected to the output of the transitiontj, i.e.:

I(tj) = {pi ∈ P : (pi, tj) ∈ A} (2.6)

2.1 Petri Net Language 9

O(tj) = {pi ∈ P : (tj, pi) ∈ A} (2.7)

In function (2.8),µ(k) represents the present marking,µ(k + 1) is the marking we want to

achieve,q(k) represents the triggering vector needed to go from the markingµ(k) to µ(k + 1)

andD is the incidence matrix that accounts the balance of tokens (giving the transitions fired).

The state evolution of a Petri net can be described as the following matrix function,

µ(k + 1) = µ(k) +D ∗ q(k) (2.8)

Figure 2.1 shows an exemple of a Petri net.

Figure 2.1: Example of a Petri net

2.1.2 Transition

The transitiontj ∈ T is active ifx(pi) ≥ w(pi, tj) for all pi ∈ I(tj). That is,tj transition is

enabled when the number of marks onpi is at least as great as the weight arc connectingpi to

tj for all pathspi that are inputs to the transitiontj.

The implementation of a transitiont is accomplished by removing each place of assembly

L, I(L, t) marks. After this,O(P, t) marks are set in each place of assembly P.

2.1.3 Incidence Matrix

DefiningD as the incidence matrix of a Petri net, a matrixm × n whose entry(j, i) comes in

the form,

Dji = w(tj, pi)− w(pi, tj) (2.9)


We can write the state equation,

x′ = X + µD. (2.10)

This equation describes the state transition process, as a result of inputµ . Considering the Petri

Figure 2.2: Example of a Petri net

net in Figure 2.2, we obtain the following incidence matrix,

D =

−1 1 1 0

0 0 −1 1

−1 0 −1 −1

(2.11)

2.2 Properties

In this chapter we describe Petri net properties. These properties provide us a way to character-

ize study systems.

Property 1. Reachability, a configuration of the marks over places M (marking), given aPetri

netN , is reachable ifM ∈ R(N), whereR(N) is the group of all the possible markings of N.

Property 2. Boundness, it is the property that verifies if the number of marks for allthe places

is limited. A place in a Petri net isk−bounded if it does not contain more thank marks in all

reachable markings.

Property 3. Safeness, a Petri net is safe if for every possible marking, there isn’t more then one

mark for each place. A Safe Petri net is 1-bounded.

Property 4. Conservation. A Petri net is strictly conservative, when for every markingthe total

number of marks remains the same. A Petri net is strictly conservative if for everyµ ∈ R(C, µ):

∑

pi∈P

µ′(pi) =∑

pi∈P

µ(pi)

2.2 Properties 11

Property 5. Liveness. This property is associated, with the possibility that a Petri net has of

running continuously without reaching a deadlock. A Petri net is alive if for all the possible

markings, there’s a trigger for another marking.

Property 6. Coverability. Given a Petri net with initial markingu0, the stateu′ ∈ R(C, u) is

covered ifu′(i) ≤ u(i), for all placespi ∈ P .

The set of all markings reachable from the initial stateu is the is called reachable set. The

graphic representation of a PN’s reachable set is called a reachability tree. An exemple of a

reachability tree and its PN is showned in Figure 2.3.

Figure 2.3: Example of a reachability tree and its Petri net

In a particular Petri netN , with initial statex0 , the statey coversx0 if there is ax ∈ R(N)

wherex(pi) ≥ y(pi) for all i = 1, ..., n.

In a give Petri netC = (P, T, I, O, u0), a placepi ∈ P is k-bounded ifu′

i ≥ k for u′ =

(u′

1, ..., u′

i, ..., uN′) ∈ R(C, u0)

If the Petri net of interest is bounded, then safety and blocking properties can be determined

algorithmically. A placepi ∈ P of the Petri netC = (P, T, I, O, u0) is safe if for allu′ ∈

R(C, u0) : ui′ ≥ 1 A Petri net is safe if all its places are safe.

Petri net N with initial statex0 is said to be live if there always exists some sample path such

that any transition can eventually fire from any state reached fromx0.

2.2.1 Supervision based on Linear Constraints

The goal of this chapter is to introduce the supervision of Petri nets. A supervisor is a discrete

event system that is used to monitor and control another discrete event system, satisfying a

specification. In a Petri net, a supervisor restricts transitions that may trigger at a given state of

the Petri net, so that the specification is satisfied. The specification may consist of requirements


concerning the reachable markings or permissible triggering sequences. The main supervision

approach referred is the supervision based on place invariants. We desire a supervisor to prevent

the system from reaching markings which do not satisfy,

Lµp ≤ b (2.12)

WhereL is an integernc × n matrix (nc is the number of constraints, n is the number of places

of the given Petri net),b is an integer column vector, andµ is the Petri net marking.

µc is a vector ofnc non-negative slack variables, defined as,

µc = b− Lµ (2.13)

After introduction of slack variables, (2.12) becomes,

Lµp + µc ≤ b (2.14)

With µc0 as the initial marking of the Petri net supervisor,

µc0 = b− Lµ0 . (2.15)

Let Dp be the Petri net incidence matrix, the supervisor with incidence matrix beDc =

−LDp,

D = [DTp, D

Tc]T , (2.16)

If,

Lµp0 − b ≤ 0, (2.17)

Then a Petri net supervisor enforces the constraint (2.12) when included in the closed-loop

system. If (2.17) is not true, the constraints cannot be enforced.

2.2.2 Generalized Linear Constraints

In order to develop Petri net systems to implement in PLC code, one has to assure that desired

properties are taken into account. In order to be able to impose desirable system attributes,

we have to use supervisors. In Chapter 2.2.1, we already introduce the concept and theory of

supervision. In this section we use this theory to implementsome desirable properties. Ior-

dache, Marian, Antsaklis and Panos [10], already have developed and made avilableMatlab

toolboxes that can be used for supervision control. Some of the most relevant for our work

2.2 Properties 13

areMRO_ADM (used for transformation of marking constraints to admissible constraints using

matrix row operations) andDP (used for deadlock prevention and liveness enforcement).

In this Section it is showed that the method for the supervision of Petri nets is extended for

more general specifications, for Petri nets in which all transitions are controllable and observ-

able. The type of constraints considered in 2.12 is extendedto

Lµp + Fqp + Cνp ≤ b, (2.18)

whereqp is the firing vector and describes the transitions that can occur at a certain instance,qpiis set to 1 if the transitionti is to be fired next, or elseqpi = 0. νp is the Parikh vector, a state

variable that indicates how many times each transition has been fired since the initial marking

µ0. µp is the marking vector for system.

As proven by Iordache and Antsaklis [13], a generalized linear constraint 2.18, is enforced

by a optimal supervisor with incidence matrices,

D−

C = max(0, LDp + C,F ), (2.19)

D+

C = max(0, F −max(0, LDp + C))−min(0, LDp + C), (2.20)

And initial marking of the supervisor,

µC0= b− LµP0

− CνP0. (2.21)

This is useful in systems that can be modeled as a producer-consumer, where there is a resource

allocation problem with a variable number of resources thatare limited to a maximum number.

Producer and consumer are two asynchronous processes. The producer generates new units

and makes them available to the consumer. The consumer takesone unit of the resource at

a time. Two synchronization constraints must be created. First an underflow constraint must

be implemented, so that the consumer cannot take a unit unless there is at least one available.

Second, an overflow constraint must be implemented, to assure that the producer cannot produce

a new unit unless the number of units is below the maximum number allowed. In Figure 2.4, a

solution to implement a buffer for a underflow constraint is shown. A producer keeps producing

and sending the production to a buffer. The consumer in orderto consume has to check the

buffer for product availability. If the buffer is empty, theconsumer waits. To implement the

buffer to a Petri net lets consider the Petri nets of Figure 2.5, where∀s ∈ N0, ∀t ∈ N0, ∀n ∈ N0.

Let p2 be the number machines working,t2 the product produced,p3 the number of consumers


��

��

��

��

��

Figure 2.4: Consumer-Producer situation with underflow buffer

Figure 2.5: Petri net for a producer-consumer type situation

andt3 the request to consume. The underflow constraint can be represented byν3 6 ν2. Taking

into account,Cνp 6 b andL = 0, F = 0 we can represent the constraint by the following

matrix form,

[

0 −1 1 0]

ν1

ν2

ν3

ν4

6 0 (2.22)

Using the knowledge described in chapter 2, we obtain the initial marking and incidence matrix

2.2 Properties 15

for the Figure 2.5 Petri net,

DP =

−1 1 0 0

1 −1 0 0

0 0 −1 1

0 0 1 −1

µP0=

s

0

t

0

(2.23)

Fromb − LµP0= 0 − 0 > 0, and from 2.19, 2.20 and 2.21 we can define a supervisor which

can be represented as a Petri net of incidence matricesD+

C , D−

C , and with initial markingµC0.

We call the places of the supervisor control places.

D−

C = max(0, [ 0 −1 1 0 ], 0) = [ 0 0 1 0 ] (2.24)

D+

C = max(0,−[ 0 0 1 0 ])−min(0, [ 0 −1 1 0 ])

= [ 0 0 0 0 ]− [ 0 −1 0 0 ] = [ 0 1 0 0 ] (2.25)

µC0= b− LµP0

= 0− 0 = 0 (2.26)

With these results we can obtain the incidence matrix and initial marking, for the new supervised

Petri net showed in Figure 2.6.

D =

−1 1 0 0

1 −1 0 0

0 0 −1 1

0 0 1 −1

0 1 −1 0

µC0=

s

0

t

0

0

(2.27)

In Figure 2.7, a solution to implement a buffer for underflow and overflow constraints is

shown. A producer sends the result of production to a buffer,but only keeps producing in case

the buffer is not full, if it is it waits. The consumer in orderto consume has to check the buffer

for product availability. If the buffer is empty, the consumer waits. Again, considering the Petri

net from Figure 2.5, the underflow and overflow can be represented by the linear constraint,

{

ν3 ≤ ν2

ν2 ≤ ν3 + n⇔

{

ν3 − ν2 ≤ 0

ν2 − ν3 ≤ +n(2.28)

Taking into account,Cνp 6 b andL = 0, F = 0 we can represent the constraint by the


Figure 2.6: Petri net with consumer-producer supervisor

��

��

��

��

�� !��

Figure 2.7: Consumer-Producer situation with underflow and overflow buffer

following matrix form,

[

0 −1 1 0

0 1 −1 0

]

ν1

ν2

ν3

ν4

≤

[

0

n

]

(2.29)

The initial marking and incidence matrix are still the ones in 2.23. Fromb − LµP0= b =

[

0

n

]

> 0 , and from 2.19, 2.20 and 2.21 we can define the supervisor incidence matricesD+

C ,

2.2 Properties 17

D−

C , and the initial markingµC0.

D−

C = max(0,

[

0 −1 1 0

0 1 −1 0

]

, 0) =

[

0 0 1 0

0 1 0 0

]

(2.30)

D+

C = max

(

0, 0−max

(

0,

[

0 −1 1 0

0 1 −1 0

]))

−min,

(

0,

[

0 −1 1 0

0 1 −1 0

])

=

[

0 0 0 0

0 0 0 0

]

−

[

0 −1 0 0

0 0 −1 0

]

=

[

0 1 0 0

0 0 1 0

]

(2.31)

µC0= b− LµP0

=

[

0

n

]

(2.32)

With these results we can obtain the incidence matrix and initial marking, for the new supervised

Petri net showed in Figure 2.8.

D =

−1 1 0 0

−1 −1 0 0

0 0 −1 1

0 0 1 −1

0 1 −1 0

0 −1 1 0

µ0 =

s

0

t

0

0

n

(2.33)

Figure 2.8: Petri net for a producer-consumer system

The Petri net shown in Figure 2.8 is a model of a producer-consumer system where the

maximum number of units is limited toPc1 + Pc2 = n. In this model, there are two places


that are used to represent the number of units produced but not yet consumed and the number

of additional units that can be produced. The number of buffer entries inPc1 contain produced

units that are available to the consumer and the number of buffer entries inPc2 contain spaces

available to the producer to store new units. Then in Pc2 represents the markings in initial state

of the system. The absence of markings inPc1 represents the initial state of the system where

there are no buffer elements with information. The produceris modeled as a subsystem with

two places.P1 represents the producer generating the next unit of information to transmit to the

consumer.P2 represents the condition where the producer is ready to insert the newly generated

information into the buffer where it is will be available to the consumer.T2 is only triggered

when the producer is Ready and there is at least one marking inPc2 (denoting a currently empty

buffer element into which the new information can be placed). The consumer is modeled as a

subsystem with two places.P3 represents the condition where the consumer is ready to receive

the next unit of new information that was generated by the producer.T3 is only triggered when

Pc1 has at least one marking (denoting a buffer element containing new information which can

be retrieved).P4 represents the condition of the consumer when it is processing the new infor-

mation most recently retrieved from the buffer. It can be observed that the producer-consumer

system in Figure 2.8 satisfies the two primary synchronization constraints noted above. The

overflow constraint is satisfied because the producer cannottriggerT2 unless there is at least

one marking inPc2. Thus, it is not possible forT2 to trigger more thenn times in a row without

T3 triggering one or more times. The underflow constraint is satisfied because the consumer

cannot triggerT3 unless there is at least one marking inPc1. Thus, it is not possible forT3 to

trigger more thenn times in a row without theT2 triggering one or more times.

Comment The producer-consumer paradigm allows separating a globalDES into simple

components, easier to module with PN, and that are combined later using generalized linear

constraints.

Chapter 3

PLC Data Acquisition

This thesis proposes logging input and output signals of a Programmable Logic Controller

(PLC) using external hardware. This chapter describes the hardware required and developed

to achieve this objective. This section details first the hardware already available for PLC inter-

action, and then the hardware used and developed for signal acquisition.

3.1 Hardware Setup

Figure 3.1 shows the system architecture in which we based ourselves to fulfill this thesis,

composed of four elements: the controlled plant, the programmable logic controller (PLC), the

signal acquirer and a personal computer (PC). The signal acquirer and PC form the monitoring

hardware. The PLC provides all the information necessary for the plant to operate, the monitor-

ing hardware is responsible for monitoring the system, while it is also able to control the plant

(reference generator).

The PLC is a programmable device which uses an instruction set of logical commands. It

is divided into three sections, (a) digital inputs connected to an internal address each (analogue

inputs to be used have to first be converted to digital); (b) internal memory consisting of timers,

counters, registers and relays; (c) digital outputs made upof relays, transistors, triacs, and digital

to analog converters to provide analogue outputs.

The PLC used in this thesis is composed by three different modules. The main module,

Modicon TSX-57-1634, this is the core of the PLC, containing all the internal memory, it is

where all the processing is done, it provides connections toan external computer for program-

ing, and also has integrated Ethernet port. A power supply module, Modicon TSX-PSY-2600,

which provides power to the entire PLC (twenty six watts). And finally, input and output ana-

20 PLC Data Acquisition

PC

Signal

Acquirer

PLC Plant

Figure 3.1: Generic setup block diagram.

log connections modules. We have at our disposal two different configurations of modules to

achieve input and output connections. We can use the TSX-DMY-28FK module, that provides

external connection using two twenty pins insulation-displacement connectors (IDC) for input

and output signal. Or we can use the TSX-DEY-16D2 and TSX-DSY-16T2 modules, one pro-

vides input connections and the other output connections, both use single cables fixed to the

models by screws for input and output signals. For both configurations we have sixteen isolated

signal inputs, and twelve isolated signal outputs. The IO modules needs its connections to be

powered externally. This is due to the fact that this connections power is isolated from the PLC’s

modules power supply, in order to prevent damage to the modules from wrong handling of the

IO connections. Figure 3.2 (a) shows the twenty four volt power supply used for powering IO

connections. Figure 3.2 (b) the refered PLC.

(a) Power supply. (b) PLC. (c) Terminal.

Figure 3.2: 24 volt DC power supply (a). Modicon PLC (b). Terminal with twelve key num-bered keyboard (c).

3.2 PLC Input and Output Connections 21

3.2 PLC Input and Output Connections

The used controlled plant, our terminal, is a twelve key keyboard. The keyboard has seven

input or output connections. Each connection represents a column or a line of keys from the

keyboard. The columns and lines are short circuited to each other when a specific keys is press,

per example, if key number one is pressed, the connection to column one and line one is short

circuited. The terminal can be seen in Figure 3.2 (c).

(a) PLC PCB front side. (b) Terminal PCB front.

(c) PLC PCB back side. (d) Terminal PCB back.

(e) Final PLC PCB. (f) Final terminal PCB.

Figure 3.3: Printed circuit board prototype designed for keyboard terminal, front (b), back (d).Printed circuit board prototype designed for monitoring alternative PLC, front (a), back (c).Assembled printed circuit boards, for PLC (e), and for terminal (f).

To facilitate connections between the difference hardwarecomponents, several printed cir-

cuit boards were degined (PCBs), that would allows us to forty pin IDC cables and cables that

have a forty pin IDC connection on one end and two twenty pin IDC connection connections


on the other.

The Terminal, it was not prepared to be used with a forty pin IDC cable, so we designed PCB

where the keyboard’s cables are soldered and connected to a female forty pin IDC connector, it

can be seen in Figure3.3 (a), (b) and (f).

The other designed PCB, in Figure3.3 (c), (d) and (e), has the purpose of being used with

PLC’s that use the TSX-DEY-16D2 and TSX-DSY-16T2 input and output modules that don’t

have IDC connection, and have different signal logic for each of the pins. This way the signal

monitor can be used in different PLC configurations. Notice that all the developed PCBs have

power connections, that can be used in the case where no monitoring is done.

Figure 3.4 shows the full hardware setup with the developed input and output connections

PCBs already assembled.

Figure 3.4: PLC to terminal connections using final PCBs manufactured at Eurocircuits [6].

3.3 PLC Input and Output Monitor

Observing input and output events can be done to some extent using the PLC memory, however

this is not viable considering that the PLC does not have enough memory to run a program that

operates the controlled plant detailed in the previous section, and still have enough memory to

keep a log of all input and output events. Monitoring the PLC will provide a way to keep a log

3.3 PLC Input and Output Monitor 23

of all signals that go from/to the PLC to/from the terminal, as well as communicate with the

PLC (acting as a if it was the terminal), and communicate the acquired data with a PC.

I O

PLC

Arduino IO Shield

��

��

��3 U

1 2 3

4 5 6

7 8 9

0 #*Arduino Mega

INOUT

USB Connection

24V

OUT

ArduinoIn

ArduinoOut

TerminalIO

IN

Terminal

Power Supply

PC

Figure 3.5: Arduino based pass through logic observer and reference generator

In figure 3.5 a design for an Arduino based monitoring hardware is shown. The signal ac-

quirer/monitor, composed by the Arduino and Arduino shield, is the center piece of the system,

everything connects to it.

The design of our signal acquirer was done with an Arduino Mega as it main processing

unit, because of its characteristics, ease of use, and low cost. The Arduino Mega is a board

based on the ATmega1280 single-chip microcontroller. It has fifty four configurable digital

input/output pins, a USB connection for communication and powering, one hundred and twenty

eight kilo bytes (KB) of flash memory (for storing code), eightKB of static random access

memory (SRAM, for local variables), among other specifications not relevant to our needs.

It contains everything needed to support the microcontroller. An advantage of the proposed


monitoring alternative is that we can obtain more detailed system time diagrams, since a typical

PLC has a scan cycle period in the order of a few milliseconds while an Arduino can work with

sampling (input and output) rates in the order of microseconds.

Using an Arduino Mega as our signal acquirer raised some challenges. The Arduino does

not have IDC connectivity, there is no way to have hardwired connections from the PLC’s

outputs/input to the Terminal’s inputs/outputs while the signals are connected to the Arduino,

and the Arduino digital pins work with voltages from zero volts (digital value zero) and five volts

(digital value one), while the PLC works with voltages from zero volts (digital value zero) and

twenty four volts (digital value one). To solve these problems a Arduino shield was designed.

An Arduino shield is an expansion printed circuit board, which plugs into the supplied Arduino

pin headers.

The shield has a fifty pin header connection to the Arduino, twenty eight of the connections

are configured as Arduino digital inputs, sixteen of the connections are configured as Arduino

digital outputs, two connections are provide five volts fromthe Arduino, two connections are

used as ground connections between the hardware, and the rest are unused.

The designed shield provides three forty pin IDC cable connection, there are to possible

connection configurations that can the used. The first one, using the two rightmost IDC con-

nections (the left female IDC is for PLC connection and the right female IDC is for Terminal

connection) the monitor is solely used as a data logger, the PLC connection is hardwired to

the terminal connection, the Arduino only receives the the PLC’s and terminal’s input and out-

put signals. The other possible configuration is using the leftmost IDC for connecting to the

PLC, and the rightmost connection for connecting to the terminal. In this last configuration the

PLC’s and terminal’s connections are not hardwired, but the Arduino can be configured so that

its inputs/outputs mimics an hardwired connection and also, and this is the advantage of this

connection configuration, this way we can configure the arduino to act as a terminal, sending

desired signals to the PLC.

The last problem that our Arduino shield solves is the problem of the Arduino and the

PLC’s inputs/outputs working in different potential differences. To reduce the voltage from

twenty four volts to five volts, before the signal reaches theArduino, one voltage divider is used

for every input in the shield. The voltage divider uses a forty seven kilo-ohm resistor in series

with a ten kilo-ohm resistor. To increase the voltage from the Arduino’s output signals, an hex

buffer/driver integrated circuit (IC) was used. Each of the three ICs used has six drivers with

open-collector outputs. Connecting the output of each driver to a voltage source will raise the

input signal to the same voltage of the voltage source, in ourcase twenty four volts. For this

to work we added an twenty four volt connection to our shield,supplied by the power source

3.3 PLC Input and Output Monitor 25

mention in the previous section.

(a) Arduino Mega. (b) Shield PCB, front and back.

IDC connections to/from Terminal

IDC connection to PLC

USB connection

to PC

Generate andmonitor signalsto/from the PLC

Arduidoto PLC adapter

Arduino Mega

(c) Arduino shield. (d) Signal Acquirer.

Figure 3.6: Arduino Mega, part of the signal monitor (a). Designed Arduino Mega shield PCB(b). Assembled signal monitor shield for Arduino Mega (c). Signal monitor composed byArduino Mega and Arduino shield (d).

The circuit diagram and PCB schematic for the developed Arduino shield can the seen in

Appendix A. Figure 3.6 (a) shows the assembled signal monitor, Arduino plus shield, and (b)

shows the developed Arduino Mega shield. Figure 3.7 shows the complete monitored system is

shown, this is the same system as shown in the block diagram inFigure 3.5, except the PC is

not visible.

There are a few aspects that should be mentioned. The first oneis that there is only need

for one twenty four volt connection for the whole setup, since the IDC cables provide voltage

and ground connections. The second one, is that we tried to use the five volts that the Arduino

provides (from the USB connection) as a power source, by connecting them to a step up circuit.


Figure 3.7: Generic setup with signal monitor assembled.

This proved to be ineffective, since the USB connection doesnot provide enough electrical

current, when all the setup parts are connected, to allow thestep up circuit to increase the

voltage from five volts to twenty four.

3.4 Data Acquisition Software

In order to be able to do any processing, signal logging, and input/output signal receiving/send-

ing, a program has to be implemented into the Arduino. The analysis of the data can then be

done in a PC.

3.4.1 Arduino Monitoring Program

The Arduino program follows a two part step sequence, (i) definition of the program’s global

variables, initialization of serial communication at ninethousand and six hundred bits per sec-

ond, initialization of digital pins as inputs and outputs, and (ii) running of a main function

program in loop. Note that the initialization of digital pins has to be programmed and is a

crucial factor for the proper functioning of our signal monitor.

The main function program that runs constantly in loop workswith FLAG system. The

different start with aFALSE value. Inside the main function there is a switch statement that, if

there is any serial communication done with the Ardunio, changes theFLAGS value toTRUE,

3.4 Data Acquisition Software 27

depending on serial communication received. The fact that aFLAGS hasTRUE value, makes

the program run extra functions in the next program loop, each one of this functions represents

a command given by serial communication.

A concise description of the main Arduino program can be doneby introducing some of the

called functions (see their coding in Appendix D):

• serial_read_str(char *buf, int buflen), this function checks if there is

any data available in the serial connection, if any data is received, the function returns1

and the program enters the switch statement, that dependingon the data received changes

the value of the program’sFLAGS.

• main_send_end_cmd(), this function is called when any other function if termi-

nated, to communicate by serial connection, that a command received by serial commu-

nication has been executed.

• store_inputs(), if this function’sFLAG value isTRUE, all the digital values, one or

zero, of the Arduino’s pins being used as inputs are read, their value is saved in an array.

While this function’sFLAG value isTRUE, if the the input values change in any of the

program’s loop iteration, the values are saved to a new position of the same array.

• tfire(), this function is used to simulate the terminal, turning to digital value one

Arduino’s outputs. It takes into account the time since the function is turned on, and with

that sends different keyboard key combinations during a time period. The key triggering

sequences and time instances to be sent are defined has array variables in the program.

3.4.2 PC Monitoring Program

On the side of the PC the USB connection allows serial communication. A Matlab script was

developed to do this communication. The script allows a serial connection to be established with

the Arduino, commands to be send to the Arduino, storage of log data sent from the Arduino,

ending the serial connection, and drawing different type ofgraphs depending on the information

received from the Arduino. Figure 3.8 shows a simple Matlab program that establishes a serial

connection with the Arduino, sends the command ’r’ (the Arduino interprets this command as

start of recording input signal changes), and finally the connection is closed. Matlab function

send_recv_str(sp1,arg1) is used to send a command to the Arduino, and to wait for

the Arduino to respond, which the Arduino does using its functionmain_send_end_cmd().


12 % i n i t i a l i z e c o n n e c t i o n t o t h e ardu ino3 sp1 = s e r i a l ( ’COM6’ ) ;4 s e t ( sp1 , ’ BaudRate ’ , 9 6 0 0 ) ;5 fopen ( sp1 ) ;6 r e t = s e n d _ r e c v _ s t r ( sp1 , a rg1 ) ;7 % send commands and r e c e i v e answer from t h e ardu ino8 command = ’ r ’ ;9 r e t = s e n d _ r e c v _ s t r ( sp1 , a rg1 ) ;

10 % end c o n n e c t i o n t o t h e ardu ino11 f c l o s e( sp1 )

Figure 3.8: Simplified code for Matlab serial communicationwith Arduino.

Chapter 4

PLC Program Development and

Monitoring

In this chapter we explain our approach to designing a discrete event system (DES) problem

solution and implementation based in Petri net theory. First we start by detailing our approach

for DES simulation and implementation in a PLC. We present a designed PN to structured text

(ST) converter, as well as Matlab PN simulator.

4.1 DES Implementation

In our DES implementation approach we start by designing a DES with the help of Petri net

based modeling and then convert the Petri net model to a PLC program. Validation of the

PLC program by comparing simulations of the Petri net with the output signals generated by

the PLC and monitored with external hardware. Modeling a system or specification by a Petri

net is performed by assigning conditions to places and events to transitions. The marking of a

place indicates an active condition, the absence marking indicates that the condition is inactive,

with the total marking of all places representing the systemstate. In a Petri net, like in a real

system where conditions and events dictate the evolution ofthe system, the evolution is based

on the transition of markings from the network places, beingthe mechanism previously defined

responsible for this.

Petri net modeling will be done in the graphical design tool PM Editeur[7], that creates a

RDP type file which can be used to import the matrix representation of the PN intoMatlab,

using the function rdp.m available inMatlab toolbox for Petri nets [27]. This function creates

three matrices, one for the input transitions of each place of the Petri net, one for the output

30 PLC Program Development and Monitoring

transitions of each place of the Petri Net, and one for the initial marking of places in the Petri

net. Formal validation of a designed Petri net system can be obtain again usingMatlab toolbox

for Petri Nets [27]. This can be done using the functions,

[A,B] = graph(Pre, Post,M0)

[X] = disp_gr(A,B)

Pre, Post andM0 respectively represent the matrices for input transitionsof each place of the

Petri net, output transitions of each place of the Petri net,and initial marking of places in the

Petri net. The functionGraph.m finds all the reachable markings from the given PN. A and

B represent adjacency matrix and the reachable markings matrix, respectively. The result of

Disp_gr.m is a display of the graph of reachable markings, from which wecan verify the

properties described in Chapter 2.2. Another important result that can be obtain usingMatlab

toolbox for Petri Nets [27], is the event time diagram, that will be used to compare simulation

results with experimental results.

4.2 Petri net Simulation

With a 3x4 keyboard in mind, a Petri net, describing the events and the state evolution of the

key reading system, was developed to model the process of reading one keyboard key as a DES,

this subject is focus of chapter 5. Its analysis is done resorting to the Petri net simulator PM

Editeur[7] and the Matlab Petri Net toolbox[27], that allows us to generate Petri net’s incidence

matrix and initial marking matrix. Using Matlab functions,combined with the tools mentioned

above, we are able to simulate the Petri net’s behavior.

The Matlab simulator works by receiving a structure for Petri net’s characteristics and run-

ning a loop, for which each iteration corresponds to ten milliseconds. The loop’s functions

receive as inputs the Petri net’s characteristics, and has the following sequence:

• PN_s2act, for each loop iteration, this function returns an array with the active key-

board column for that iteration, it takes into account the initial marking of the Petri net.

• PN_tfire, this function returns the Petri net’s transitions that canbe activated at the

current time that the function is called, this time is definedby the function’s loop iteration.

The function’s return result is achieved by comparing thePN_s2act result, the keyboard

keys pressed in the time instance it is called and the supervisor for multiple key detection

result.

4.3 Petri net to PLC Conversion 31

• filter_possible_firings, this function compares the result fromPN_tfire

with the marked places from the previous loop iteration or from initial marking, taking

into consideration the Petri net’s incidence matrix. The function returns an array with the

possible transition to be triggered. With this result, the program can now reassign the

marked places array with the marked places result for this loop iteration.

• PN_s2yout, this function checks the marked places array and returns the key pressed

for this loop iteration.

4.3 Petri net to PLC Conversion

Most PLC programmers develop programs using Ladder Logic. In a complex control situation

with a very large number of logical inputs and logical combinations it is difficult to predict the

results of illegal inputs such as damaged input switches or sensors. This lack of control causes

normally stable systems to behave unpredictably.

The approach chosen is however another one, namely using Structured Text (ST), as the

pure text content allows an easier transfer from the Petri net to the PLC integrated development

environment. ST allows to describe the behavior of a controlfunction according to the infor-

mation it receives. Its understanding is simple for users familiar with high-level programming

languages.

4.3.1 Petri net to Structured Text Compiler

The method chosen to transcribe Petri net to ST, creating a PLC program from a Petri Net

and IO mapping, uses three auxiliary functions to that prepare a problem’s specific data, like

timed transitions and physical inputs or outputs, to be usedstraightforward by the main script.

The auxiliary functions enable the following: (1) Load a Petri Net from file, that contains the

incidence matrix and the Petri net’s initial marking; (2) Define the mapping of PLC inputs to PN

transitions, creating a structure with the PLC’s inputs and the selected corresponding transitions,

and with the conflicts between transitions; (3) Define the mapping of PN places to PLC outputs,

creating a structure with the outputs that should change value when the places are marked.

The auxiliary functions, and the main script, used for this method can be seen in Ap-

pendix B.

After having the information provided by our auxiliary functions, we are able to create a

PLC program from a Petri Net and IO mapping using the functions briefly described in the


following tables.

Functionplc_map_inputs(inp_bits_lst, trans_lst,options)

Input List of mapped transitions.

Output ST code with list of transitions and their respective input.

Description

Allocates one memory position for each transition. Each transition isrepresented by memory position that is the sum of%MW100 plus itstransition number (transition four is%MW104). Establishes causal effectrelation between PLC inputs and memory positions that definetransi-tions.

Table 4.1:plc_map_inputs ST compiler function description.

Function plc_timed_transitions(t_trans_place_lst)

Input List of timed transitions, time out time, list of places.

Output ST code with one timer for each timed transition.

Description

Creates one timer for each timed transition. The activation of the timeris controlled by a place being marked, after the timer reaches timeouttime the transition is triggered. Each of this timed transitions are allo-cated to one memory position.

Table 4.2:plc_timed_transitions ST compiler function description.

4.3 Petri net to PLC Conversion 33

Functionplc_encode_petri_net(pre, pos, mu0, tprio,options)

Input Loaded Petri net.

OutputST code for memory initialization and logical conditions between mem-ory positions

Description

To set the initial condition of the program (initial markingin the Petrinet) it is necessary to create a statement that will be executed only onceby the PLC. The program represents each place by a memory posi-tion that is the sum of%MW200 plus its place number (place four is%MW204). It verifies if initialization command is received, and if so, allthe variables associated to places are set to their initial marking value.Defines cause and effect relations between memory positionsthat de-fine places and memory positions that define transitions, by usingifstatements that check if the memory position for a transition has a valuedifferent than one, and that the memory positions for the places thatneed to be marked for the transition’s firing are marked, if these twoconditions are met, the memory position values are decremented andthe memory positions for the places that receive a mark from the re-ferred transition are incremented.

Table 4.3:plc_encode_petri_net ST compiler function description.


Functionplc_output_if_any_place(places_lst_main,outp_bit_main)

Input List of mapped places.

Output ST code with list of places and their respective output.

DescriptionThe value of auxiliary variable associated with each place is assigned toits respective output variable, usingif statements. Various places canbe associated with the same PLC output, usingor statements.

Table 4.4:plc_output_if_any_place ST compiler function description.

Function plc_encode_places(places_lst, outp_bits_lst)

Input List of places.

Output ST code to output debug/monitor info.

Description

Create PLC code to output debug / monitor info. Receives a list ofplaces. Usingif, establishes relation between those places beingmarked and a variable (output). It also creates aflag to check ifmore then on of the places in the list e marked. Using bit logicbit logic,and the value from the variableoutput, a bit signal representing themarked place is sent using four outputs.

Table 4.5:plc_encode_places ST compiler function description.

Chapter 5

Case study: Keyboard Reading

Figure 5.1 shows the physical system used in the thesis. The process consists of reading one

keyboard key with a PLC implementing the DES. This section describes the synthesis of the

DES for keyboard reading, taking into account modeling and analysis properties. Synthesis

will be based on supervised control.

Figure 5.1: Plc and terminal.

36 Case study: Keyboard Reading

5.1 Proposed Petri Net Model

Modeling the process of reading one keyboard key as a DES, is done by developing a Petri

Net that describes the events and the state evolution of the key reading system. The developed

system can be divided into tree main blocks. Each block represents one of the tree keyboard

columns. In each of the three blocks there is a wait state, waiting for a key in their column to be

pressed. If a key is pressed the system evolves to a state waiting for the key to be released, and

then the system evolves to the first state, of waiting for a keyto be pressed (same column). The

wait for a key to be pressed state is timed (fifty milliseconds), if a key is not pressed the system

evolves to a wait state for keys from the second column. If again a key is not pressed, after fifty

milliseconds the system evolves to a state of waiting for a key to be pressed on the third column,

if another fifty milliseconds go by, the system evolves againto the first state. A timed transition

(T1, T11 and T2) is used for each of the tree wait states. The activation of different columns is

represented by the marking of one place connected that connect to one of these transitions (P1,

P2 ad P3). If a key is pressed transitions are activated, depending on the key, that pass the mark

to a new place representing the pressed key. A transition connected to each place representing

a pressed key, sends the mark to the wait timed place when a keyis released.

Event Identifier Description

T1Timer controlled transition from actua-tion in keyboard column 1 to column 2



T4, T12, T20 Keyboard key in row 1 pressedT5, T13, T21 Keyboard key in row 2 pressedT6, T14, T22 Keyboard key in row 3 pressedT3, T15, T23 Keyboard key in row 4 pressedT9, T16, T24 Keyboard key in row 1 releasedT10, T17, T25 Keyboard key in row 2 releasedT7, T18, T26 Keyboard key in row 3 releasedT8, T19, T27 Keyboard key in row 4 released

Table 5.1: DES events.

Table 5.1 describes the Petri net events, Table 5.2 shows theconditions for event evolution,

and Table in Figure 5.3 (a) lists the conditions for transition triggering taking into to account the

event evolution. From the event evolution described by the referred tables the incident matrix

on Figure 5.2 is obtained.

5.1 Proposed Petri Net Model 37

Condition Identifier DescriptionP1 column 1 is active, no row is activeP2 column 2 is active, no row is activeP3 column 3 is active, no row is activeP4 column 1 is active, row 4 is activeP5 column 1 is active, row 3 is activeP6 column 1 is active, row 1 is activeP7 column 1 is active, row 2 is activeP8 column 2 is active, row 2 is activeP9 column 2 is active, row 1 is activeP10 column 2 is active, row 3 is activeP11 column 2 is active, row 4 is activeP12 column 3 is active, row 2 is activeP13 column 3 is active, row 1 is activeP14 column 3 is active, row 3 is activeP15 column 3 is active, row 4 is active

Table 5.2: DES conditions.

D =

−1 1 −1 −1 −1 −1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 01 0 0 0 0 0 0 0 0 0 −1 −1 −1 −1 −1 1 1 1 1 0 0 0 0 0 0 0 00 −1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 −1 −1 −1 −1 1 1 1 10 0 1 0 0 0 0 −1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 1 −1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 1 0 0 0 0 −1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 1 0 0 0 0 −1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 −1

Figure 5.2: Incidence Matrix

µ0 = [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0]T (5.1)

In 5.1 we can see the initial marking for the Petri net places,where the system begins by

waiting for a key to be pressed on column one. The Petri net in Figure 5.3 (b) is the result from

modeling the system of reading a keyboard key. Figure 5.4 is arepresentation of the sequence

of places traversed during the column scanning, when no key is pressed. Thus the columns are

activated in sequence each for fifty milliseconds. In Figure5.5 the Petri net evolution for detec-

tion of a key is shown. The evolution is shown for keyboard keyone, but it would follow similar

sequence of events for all twelve keys for the other keys. These two sequences represent the


Event Pre-Conditions Post-ConditionsT1 P1 P2

T11 P2 P3T2 P3 P1T4 P1 P6T5 P1 P7T6 P1 P5T3 P1 P4T9 P6 P1

T10 P7 P1T7 P5 P1T8 P4 P1

T12 P2 P9T13 P2 P8T14 P2 P10T15 P2 P11T16 P9 P2T17 P8 P2T18 P10 P2T19 P11 P2T20 P3 P13T21 P3 P12T22 P3 P14T23 P3 P15T24 P13 P3T25 P12 P3T26 P14 P3T27 P15 P3

P1

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2

T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

(a) Conditions Table (b) Petri net

Figure 5.3: Table with pre and post conditions for Petri net evolution (a). Developed Petri net(b).

basic operation of the developed Petri net, which correspond to scanning the columns, repeated

during time, and key detection, which will be followed by thescanning state after validation.

5.2 Properties 39

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

50ms 50ms

50ms

P1

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

P1

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

Figure 5.4: Petri net column scanning evolution.

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

Key 1 Pressed

P1

P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

P6 P7

T9

T1

P5 P4

T10 T7 T8

T4 T5 T6 T3

P2

P9 P8

T16

T2 T11

T17 T18 T19

T12 T13 T14 T15

P10 P11

P3

P13 P12

T24 T25 T26 T27

T20 T21 T22 T23

P14 P15

Key 1 Released

Figure 5.5: Petri net one key pressed evolution.

5.2 Properties

In Section 2.2 properties that provide us a way to characterize Petri Net systems were defined.

These properties are related to the developed Petri net system the following way:


• Reachability, every keyboard key might be pressed.

• Liveness, there are no deadlocks and the continued use of the keyboardis secured.

• Temporal Invariance, the keyboard operation is not degraded with elapsed time.

• Boundedness, the number of possible markings for each place is always thesame.

• Conservation, the number of markings of the entire system stays the same.

• Safeness, only one key is validated at a time.

• Coverability, every system state can be reach from another state, this means there is no

combination of keys that makes another combination of keys unable to be detected.

From equation 2.8, it is known that for in order there needs toexist a triggering vectorq(k)

to go from the markingµ(k) to µ(k + 1), in orderµ(k + 1) be reacheble. The Reachability

Tree, shown in Figure 5.6 has all the reachable markings, andall the transitions that have to be

activated to achieve a certain marking. By analyzing the Reachability Tree, with initial state

µ0 = (1, 0, ..., 0) (corresponding to the beginning column scanning in column 1), it is verified

that the reachability setR(N) is finite and that all other system states are reachable.

From the Reachability Tree, showed if Figure 5.6, we can observe that there are sixteen

different possible markings. From a direct analysis, we observe that for each marking, it is

always possible to define a triggering sequence that will enable any other transition. From this

we can conclude all transitions are live, and from every state you can reach every state, no

deadlock occurs. All the transitions are live of level four.

The conceptual modeling of the keyboard assures temporal invariance to our Petri net. By

sequential scanning and timed column, waiting for a key is pressed, and then returning to the

same column.

A Petri net is k-bounded if all its places are k-bounded. A place is k-bounded if for all

possible states, the number of marks is less than or equal to ainteger k. The developed Petri

net is conservative, the total number of marks remains constant, which ensures that all states

have the same number of marks that the initial state. As the initial state has a mark in place

one (scanning starts in column one), and zero marks in the other places, after each transition,

only one of the places will have a mark and all other places will have zero marks. Therefore, all

places are one bounded and as such, the Petri net is one bounded. It is observable that the Petri

net is safe, since by definition, a Petri net is safe if all its places are one bounded.

5.3 Supervisor 41

t1

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

t2

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

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

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

t3

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

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

t13

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

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

t14

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

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

t15

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

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

t16

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

t4

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

t9

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

t21

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

t10

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

t22

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

t11

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

t23

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

t12

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

t24

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

t5

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

t17

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

t6

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

t18

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

t7

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

t19

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

t8

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

t20

Figure 5.6: Reachability Tree

5.3 Supervisor

In order to eliminate failure in the designed system, due to more than one key being pressed

simultaneously, designing and implementation of a supervisor, that detects the multiple keys

pressed error and resumes the normal operation of the system, is done by applying Supervisory

Control theory.

The Petri net in Figure 5.7, using only two transitions and two places, is used to inform the

system of triggering of multiple keys at the same time, taking the system to a error state. Place

seventeen is used as aflag, that when marked indicates multiple keys are being triggered. In

order to trigger transition twenty eight, the triggering ofmultiple keys must be detected, leading

to the marking of place seventeen. When a non-error state is again reached transition twenty

nine is triggered and place sixteen is marked. On Figure 5.8 the Petri net way of working is

shown. Figure 5.9 shows the incidence matrix for theFlag Petri Net.

To integrate theflag Petri net in Figure5.7, with the Petri net described in section 5.1,

and this way creating a controller to handle the multiple keys pressed error, linear constraints


P16 P17

T28

T29

Figure 5.7:Flag Petri net.

P17

T28

T29

P16

T28

T29Multiple

keys Pressed

Figure 5.8:Flag Petri net method of operation.

D =

[

−1 11 −1

]

Figure 5.9:Flag Petri net incidence matrix.

must be implemented. The linear constraints imposed are related to key validation places and

the place that is used as a errorflag not being able to be marked simultaneously. This is

represented by, ifµk is the number of marks in placek:

µ17 + µk ≤ 1, k ∈ {4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} (5.2)

From the linear constraints and using controller synthesisdescribed in section 2.2.1, the

relation 5.3 shows the matrices forL andb.

5.3 Supervisor 43

Lµp ≤ b ⇔

⇔

0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1

0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1

0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1

0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1

0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1

0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1

0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1

0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1

0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1

0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1

0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1

µ1

µ2

µ3

µ4

µ5

µ6

µ7

µ8

µ9

µ10

µ11

µ12

µ13

µ14

µ15

µ16

µ17

6 1(5.3)

The next step in controller synthesis based on linear constraints is verifyingb − Lµp0 ≥ 0,

which is true given that the result ofb − Lµp0 is b. It is relevant to note thatµp0 represents the

initial markings of the combined Petri nets, it is an one column matrix with one row per Petri

net place, seventeen in total, with all values zero except for the first and sixteenth values, which

are one. The first value represents the first state of the keyboard Petri net, waiting for a key

to be pressed for fifty milliseconds, and sixteenth value represents theFlag Petri net state of

multiple keys not being pressed at the same time. The supervisor incidence matrix (Dc) and

initial markings (µc0) are determined by the relations 5.4 and 5.5, respectively.Dp represents

the incidence matrix of the combined Petri nets, it is the result of adding two transitions and

places, rows and columns, to 5.2 with the values of 5.9.


Dc = −LDp =

0 0 0 −1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 −1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 −1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 −1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 0 0 0 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 0 −1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 0 1 −1 1

(5.4)

µc0 = b− Lµp0 = [1 1 1 1 1 1 1 1 1 1 1 1]T (5.5)

The finale incidence matrix of the supervised system (D) is shown in Figure 5.10, the differ-

ent square colors represent the different Petri nets constituting the supervised system. The blue

square outlines the incidence matrix for the Petri net used for key detection from section 5.1, the

green square outlines the incidence matrix for the Petri netused to detect pressing of multiple

keys, the purple square outlines the incidence matrix for the system that combines the last two

referred Petri nets (Dp), and the red square outlines the supervisor controller incidence matrix

synthesized based on linear constraints (Dc). As expected, the application of linear constraints

leads to the appearance of a place (marked on initial state) that links the two Petri nets, ensuring

mutual exclusion for each place in which a key is validated. Thus, there are 12 new places,

initially marked. In 5.6 we can see the final initial marking for the Petri net places, composed of

the initial marking for the original Petri net, the initial marking for the Petri net used to detect

multiple keys, and the initial marking for the supervisor.

The supervised system resulting Petri net is shown in Figure5.11.

µ0 = [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1]T (5.6)

5.3 Supervisor 45

Figure 5.10: Supervised system incidence matrix.


Figure 5.11: Petri net developed for keyboard control, withsupervisor.

5.4 Implementation 47

5.4 Implementation

Using the ST compiler detailed in 4.3.1 and shown in AppendixB, we are able to implement

the Petri net for our case study in the PLC as ST code.

Using the auxiliary functions for the ST compiler we can: (1)load our Petri Net from

file, containing the incidence matrix, the Petri net’s initial marking, priority transitions (for

our supervisor transitions) and timed transitions; (2) define the mapping of PLC inputs to PN

transitions; (3) Define the mapping of PN places to PLC outputs.

With the results from the auxiliary functions, our compileris then able to create ST code

to run in loop in the PLC, that simulates the work-flow of the developed Petri Net, taking into

account the inputs and outputs received by the PLC. The ST program generate is comprised of

five cyclic operations: (i) Petri net initialization, (ii) PLC input mapping, (iii) controlling timed

transitions, (iv) Petri net loop, (v) setting PLC output, depending of a (vi) encoding of places.

These functions are briefly described in the following paragraphs.

Petri net initialization To set the initial condition of the program (initial markingin our

Petri net) it is necessary to create a statement that will be executed only when an specific input

is received by the PLC. If this condition is met, the valueHIGH must be assigned to all the

auxiliary variables corresponding to the places initiallymarked, and the valueLOW must be

assigned to all the auxiliary variables corresponding to the places with no initial marking. This

correlates to our case study keyboard being in the state of nokeys pressed and with the column

one being the first one to be checked.

To map PLC inputs For each input (that represents a transition) there are two variables, one

to represent theHIGH state of the input and one to represent theLOW state. The variables also

takes into consideration if the output that allows the change of state of an input isHIGH orLOW.

This part of the program checks for keys being pressed or released, and sets the appropriate

value to a variable that represents those actions transition.

Controlling of timed transitions is done with three timers which consecutively, for fifty

milliseconds, set the value of one variable corresponding to a Petri net place toHIGH state.

This are the same transitions used in our Petri net to wait fora key to be pressed for fifty

milliseconds for each column.

The Petri net loop does PLC variables verification. For each scancycle, checkswhich

places should be marked or unmarked. For this, a logical combination (AND) of two conditions

must be performed: (a) input variables associated with the transition are satisfied (HIGH); (b)

existence of tokens in places (auxiliary variables areHIGH). If a transition to another PN state

is possible, the value of place variables is decreased, and the value of the variable representing


the next Place is increased.

Setting PLC outputs is done by checking the values of the created variables and variables

that represent PN Places directly dependent on the first referred variables. It then sets one of

three PLC outputs to aHIGH or LOW level, making possible the interaction of the terminal with

the PLC.

Encoding of placeschecks the value of the PLC variables that represent PN Places are

marked depending on the PLC input, and then outputs a four bitsignal depending on which PN

Place is marked or if more then one Place is marked (error case).

Chapter 6

Experiments

This chapter describes the experiments performed to validate the methodologies presented and

introduced in previous chapters. First, in order to determine various PLC properties, tests are

done, results are explained and illustrated. Next, a simulation of the keyboard reading case

study is done, both by the Petri net simulation program developed for MatLab and by the PLC

receiving key triggering simulation from the monitoring system. In the following section ex-

periments that show the effect of different initial markingto the system Petri net are shown and

discussed. Finally, we present results of the overall system explaining and analyzing results for

cases that involve supervisor control and compare them results obtain by MatLab simulation of

the Petri net.

6.1 PLC Characterization

In a PLC the response to the input from an output is not immediate. PLC’s operate by contin-

ually scanning programs and reading inputs and outputs. Oneiteration of this process is called

scan cycle. The scan cycle consists of three steps: determine status of inputs, interpret logic of

programs, and update output status. Knowing the PLC’s scan cycle is crucial in order to know if

it is going to be fast enough for a particular application. Inthe our particular case, knowing the

scan cycle allows us to know smallest time period possible for the PLC to detect two consec-

utive key triggers. In our experiments the PLC’s scan cycle was fixed to ten milliseconds, this

value was chosen to have a more stable scan cycle, as experiments will show, and because in

the implemented Petri net the minimum value of scan cycle needed for correct operation is fifty

milliseconds. It is also a unrealistic to experiment terminal key pressing for time differences so

low.

50 Experiments

(a) PLC, power supply and Monitor. (b) IO module 28FK.

USB connection

to PC

Generate andmonitor signalsto/from the PLC

Arduidoto PLC adapter

Arduino Mega

I O

PLC

Arduino based

monitor

(c) Monitor. (d) Monitored signal%q0.3.16.

1 %q0 . 3 . 1 6 := NOT(%q0 . 3 . 1 6 ) ;

(e) PLC program

Figure 6.1: Experimental setup for PLC characterization (a). Closeup view of developed mon-itor (b). Closeup view of developed monitor (c). Signal flow diagram for the first experiment(d). PLC square wave generation program (e).

The used experimental setup for this section is shown in Figure 6.1 (a). The setup is com-

posed by the Modicon 28FK PLC (b), the developed signal monitor (c), and a power supply. No

terminal is used for this sections experiments, this is due to the fact that objective in this section

is to be able to acquire PLC characteristics information. Figure 6.1 (d) shows the block diagram

representation of the system used for the PLC’s scan cycle characterization. The PLC’s output

is sends a signal, and the monitor records any changes in the PLC’s output. The structured text

program implemented in the PLC in order to monitor the scan cycle is shown in Figure 6.1

6.1 PLC Characterization 51

(e). By running this program the PLC is setting its first output(%q0.3.16) to zero volts or

twenty four volts, its output is a square wave. This operation takes the same time as a scan cycle

because the each time the PLC is interpreting the program it negates the previous value of its

first output, and program interpretation is only done once each scan cycle. This way, the scan

cycle’s time is equal to half of the square wave’s period. In order to determine the scan cycle

value, our monitoring system is continuously reading the first output from the PLC, detecting

any logical value change, as well as saving the time of the occurrence.

0 0.02 0.04 0.06 0.08 0.1

0

5

10

15

20

25

time [s]

PLC

out

[V]

0 0.005 0.01 0.015 0.02

0

5

10

15

20

25

time [s]

PLC

out

[V]

(a) 5 scan cycles window (b) 1 scan cycle window

1 2 3 4 5 6 7 8

9.2

9.4

9.6

9.8

10

10.2

10.4

10.6

10.8

time [s]

half

perio

d [m

s]

9.5 10 10.50

10

20

30

40

50

60

70

80

half period [ms]

(c) Observed scan cycle times (d) Histogram of observed scancycles

Figure 6.2: PLC output captured by the Arduino based monitor, multiple experiments, 5 scancycles window, first rising edge in each window shifted tot = 0 (a). All rising edges shifted tot = 0 (b). Observed scan cycle times along 8 seconds (c). Histogram of observed scan cycletimes (d).

Figure 6.2 shows the results of monitoring the PLC’s square wave for eight seconds. In (a)

and (b) we overlap the results of the monitored scan cycles rising edge’s shifted totime = 0s.

In (a) the overlapping is done in groups of five scan cycles, and in (b) all the monitored scan

cycles are overlapped. In (c)Each of the blue circles represents the time difference between

a monitoring a digitalTRUE value and a digitalFALSE value PLC output (half the period of

the square wave the PLC sending as output) along the eight seconds of monitoring, each value

52 Experiments

represents a different time of scan cycle. (d) is a graphicalrepresentation of the distribution of

the scan cycle time value, histogram.

From the results shown in Figure 6.2 it is observable that themonitoring system detected that

the PLC output change, does not have an exact time value between occurrences, this time varies

roughly between nine point five milliseconds and ten point five milliseconds. In the context of

our case study, keyboard reading, the interpretation of these results leads us to acknowledge that

a key should not be pressed for less then ten point five milliseconds, or it might not be detected

by the PLC. This is of course also valid for any input we wish thePLC to read.

1 %q0 . 3 . 1 6 := %i 0 . 3 . 0 ;

(a) PLC program.

I O

PLC

Arduino based

monitor

1 2 3 4 5 6 7 89.4

9.6

9.8

10

10.2

10.4

10.6

time[s]

dela

y[m

s]

1 2 3 4 5 6 7 89.4

9.6

9.8

10

10.2

10.4

10.6

time[s]

dela

y[m

s]

9.5 9.6 9.7 9.8 9.9 10 10.1 10.2 10.3 10.4 10.50

20

40

60

80

100

120

140

160

180

half period [ms]

(b) IO signals. (c) Observed delays. (d) Histogram of observed delays.

Figure 6.3: Observing the time from a signal input (rising edge%i0.3.0) to a signal output(rising edge%q0.3.16). PLC input delay test code. (a). Connections diagram (b). ObservedPLC input to output delays along 8 seconds (c) and histogram of the delays (d).

The next PLC characterization test done is for the PLC input delay. We want to be able to

determine the time it takes the PLC to read an input and act on it, input delay. Figure 6.3 (a)

shows the structured text program implemented in the PLC in order to monitor the input delay.

By running this program the PLC is reads one input and attributes the same value from that

input to an output, this is done in loop until the program is told to stop. The monitoring system,

besides monitoring the PLC, starts by sending digitalTRUE value to the PLC’s input, and as

soon as the PLC sets the output to the value of the received input, the monitor starts sending a

digitalFALSE value to the PLC’s input. Again, when the the PLC sets the output to the value of

the received input, the monitoring system starts sending a digital TRUE value to the PLC, this

is done in loop for eight seconds. Representation of this experiment’s connections is shown in

Figure 6.3 (b).

Figure 6.3 (c) and (d) shows the results of monitoring the PLC’s output while the monitoring

system is changing its input for eight seconds. In (a) each ofthe blue circles represents a time

6.1 PLC Characterization 53

delay, the time difference between a monitoring a digitalTRUE value and a digitalFALSE value

from the PLC output along the eight seconds of monitoring. In(d) a graphical representation of

the distribution of the delay time values is shown, histogram.

From Figure 6.3 results we can see that the PLC input delay time is not exact, but in fact

varies roughly between nine point five milliseconds and ten point five milliseconds. The delay

input results are similar to the scan cycle results. This is in fact expected, since the monitoring

is actually changing its output after the PLC runs a full scancycle. With this results we are

able to verify that the fact that the PLC is in fact receiving input information does not change

significantly the scan cycle time. This results reinforce the fact that in our case study, keyboard

reading, a key should not be pressed for less then ten point five milliseconds, or it might not be

detected by the PLC.

I O

PLC

50ms

100ms

10Hz

Time difference of

rising and falling edges

0 1 2 3 4 5 6 7 8

40

42

44

46

48

50

52

54

56

58

60

time [s]

half

perio

d [m

s]

(a)IO signals. (b) Input Detection

Figure 6.4: Observing the time for 100ms period square signal detection. Connections diagram(a). Observed PLC time of signal detection along 8 seconds (b).

One more characterization experiment was done running the same PLC structured text pro-

gram implemented in the previous experiment. But in this case, the monitoring system is not

only monitoring the PLC’s inputs and outputs, but it is also generating a square wave signal with

a period of one hundred milliseconds. The PLC should set its output according to the value it is

receiving in its input (digitalTRUE or FALSE), the received square wave value. In Figure 6.4

(a) a block diagram for this experiment is shown.

From the results shown in Figure 6.4 (b) we observe that the monitoring system detected

the PLC output change in the expected time instances, fifty milliseconds apart (half the period

time). We can also observe that time of input detection is notexact, this is justifiable by the

previous experiments, where it was shown that the scan cycletime is not exact and has values

54 Experiments

with differences of up to one millisecond from each other. The results also show some increase

in input detection, of almost ten milliseconds. This can be seen in Figure 6.4 (b) around the

time mark of four and a half seconds. This happens when the PLCfails to detect an input

change, and only detects it in its next scan cycle, thus the increase of ten milliseconds. The

forty milliseconds time change shown in the results, happens because an input was detected late

by the PLC, so the time difference of the next correctly detected input should be detected ten

milliseconds earlier. The fact that there are two input detections at sixty milliseconds since the

last inputs, but only one forty milliseconds input detection since the last input, can be attributed

to two straight input detection delays by the PLC.

0 1 2 3 4

x 10−3

0

5

10

15

20

25

time [s]

PLC

out

[V]

0 1 2 3 4

x 10−3

0

5

10

15

20

25

time [s]

PLC

out

[V]

(a) Minimum time observed. (b) Maximum time observed.

Figure 6.5: Varying scan cycle time. Minimum scan cycle timeobserved experimentally (a).Maximum scan cycle time observed experimentally (b).

In the context of our case study, keyboard reading, the interpretation of previous results leads

us to acknowledge that the PLC set to a ten millisecond time ofscan cycle has an accuracy with

an error of plus and minus ten milliseconds. Figure 6.5 showsthe minimum (a) and maximum

(b), time difference between rising edges, of monitoring time of scan cycle, as it was done in

the first experiment (results shown in Figure 6.2), but with the difference that this results were

obtained without a PLC fixed scan cycle time of ten milliseconds. As shown in Figure 6.5, the

PLC can have a scan cycle of less then one millisecond, but thevariation of time of scan cycle

increases greatly, leading to detected change in scan cycletime of around three milliseconds.

Since there is no need in our case study, to have a scan cycle lower than ten milliseconds, and

since not assigning a fixed value to the PLC’s time of scan cycleleads to a more unstable scan

cycle time, the ten milliseconds time of scan cycle was sustained in experiments done in the

next sections.

6.2 Key detection 55

IDC connectionto Monitor

(a) Generic setup. (b) Terminal.

Figure 6.6: Setup used for experiments. Setup for monitoring PLC (a). Keyboard terminal (b).

6.2 Key detection

This experiment carried out a sequential triggering and release of all the keys, without conflicts.

The used experimental setup for this section is shown in Figure 6.6 (a). The setup is composed

by the Modicon 28FK PLC (with the developed Petri net implementation code detailed in sec-

tion 5.4), the developed signal monitor, a power supply, andthe twelve key keyboard terminal.

The terminal and PLC are directly connected to the monitor each thru a insulation-displacement

connector cable. The monitor records all the inputs it receives. The key triggering is actually

done by signals sent by the monitor, the terminal is only usedfor the confirmation that the cor-

rect column is activated, was explained in section 5.4. Thisway we can trigger keys at the exact

time, and during the exact duration of time we want, conditions which are essential in order for

us to be able to compare experimental results to Matlab simulation results.

The key sequence used, during a time period of eighteen seconds (input data), is shown in

Figure 6.7 (a). In Table (b), besides the key sequence used, also includes the period of time

in which the keys are triggered and the expected results the PLC should output. Figure 6.7

(c) shows the Matlab simulation (that simulates the complete Petri net that reads keys) results

using the input data for this experiment. Figure 6.7 (d) shows the PLC monitoring results for

the same input data. We can also observe that in the monitoring results the PLC does not output

any error bit sequence (error sequence for multiple key detection). The experimental results are

consistent with the Matlab simulation results, as well as with the expected results.

This experiment, by input and output monitoring, shows thatthe correct validation of key

triggering and release of all the keys, without conflicts, iscorrectly done by the the Petri net

implemented in the PLC.

56 Experiments

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]

Time Key Inputs Expected Result0 - -1 1 12 - -3 2 24 2 25 3 36 - -7 4 48 5 59 6 610 7 711 - -12 8 813 9 914 10 1015 11 1116 - -17 12 12

(a) Input data, pressed keys. (b) Expected results given theinput data.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Errors

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Errors

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]

(c) Expected output, MatLab simulation. (d) Monitoring experiment results.

Figure 6.7: PLC output captured by the Arduino based monitor, input data key sequence (a).Input data, sequence of keys (b). Expected output, MatLab Simulation (c). PLC output observedwith the developed monitor (d).

6.3 Initial Marking Effect

The experiments done in this section carried out a sequential triggering and release of all the

keys. For each experiment, a different Petri net initial marking was used. The experimental

setup used in this section’s experiments is connected the same way as in the previous section,

as well as follows the same operation method, and again is composed by the Modicon 28FK

PLC, the developed signal monitor, a twenty four volts DC power supply, and the twelve key

keyboard terminal.

Initial marking of the implemented Petri net is expected to have an effect to our system in

the way it validates one of multiple keys triggered at the same time from difference terminal

keyboard columns. When initialized, the Petri net has a mark in one of the three places that

6.3 Initial Marking Effect 57

represent column activation, if fifty milliseconds go by andno key is pressed, a timed transition

transfers the marking to the next column activation place. This way, if multiple keys from

different columns are pressed, the key validated will be theone belonging to column which has

its Petri net place marked.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]

(a) Input data, multiple keys pressed at the same time.µ0 =

[

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1]T

(b) Initial marking.

(c) Expected output, MatLab Simulation. (d) PLC output observed with the developed monitor.

Figure 6.8: PLC output captured by the Arduino based monitor, input data key sequence (a).Initial marking of Petri net (b). Expected output, MatLab Simulation (c). PLC output observedwith the developed monitor (d).

The key sequence used for all the experiments in this section, during a time period of eigh-

teen seconds (input data), is shown in Figure 6.8 (a). Three keys from different columns are

pressed at the same time, in different time instances (zero,three, seven and thirteen seconds). In

(b) is shown the first used initial marking matrix. With this initial marking, when the Petri net is

initialized, the place in which the the system waits for a keyto be pressed on the first column for

58 Experiments

fifty milliseconds is marked. The supervisor configuration of places that indicate that no multi-

ple from the same column are also marked. Figure 6.8(c) showsthe Matlab simulation results

using the input data for this experiment. Figure 6.8(d) shows the PLC monitoring results for the

same input data. The experimental results are consistent with the Matlab simulation results. As

expected, the results show that in the first time instance of pressed keys, the key validated is the

one that belongs to the initial marked column (first column),key one.

µ0 =[

0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1]T

(a) Initial marking.

(b) Expected output, MatLab Simulation. (c) PLC output observed with the developed monitor.

Figure 6.9: PLC output captured by the Arduino based monitor, initial marking of Petri net (a).Expected output, MatLab Simulation (b). PLC output observed with the developed monitor (c).

In Figure 6.9(a) is shown the initial marking matrix used forthis section’s second exper-

iment. With this initial marking, when the Petri net is initialized, the place in which the the

system waits for a key to be pressed on the third column for fifty milliseconds is marked. The

supervisor configuration of places that indicate that no multiple from the same column are also

marked. Figure 6.9(c) shows the Matlab simulation results using the input data for this experi-

ment. Figure 6.9(d) shows the PLC monitoring results for thesame input data. The experimental

results are consistent with the Matlab simulation results.As expected, the results show that in

the first time instance of pressed keys, the key validated is the one that belongs to the initial

marked column (third column), key three. Comparing these results with the ones on the last

experiment we also observe that the rest of the validated keys don’t match, this is also expect,

since the fact that the initialization is done in different columns, with the passage of time, the

column activation for each column will be done in different time instances.

In Figure 6.10(a) is shown the initial marking matrix used for this section’s third experiment.

With this initial marking, when the Petri net is initialized, the place that represents the trigering

6.4 Supervisory Control 59

µ0 =[

0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 1]T

(a) Initial marking.

(b) Expected output, MatLab Simulation. (c) PLC output observed with the developed monitor.

Figure 6.10: PLC output captured by the Arduino based monitor, initial marking of Petri net(a). Expected output, MatLab Simulation (b). PLC output observed with the developed monitor(c).

and validation of keyboard key number ten is marked. The supervisor configuration of places

that indicate that no multiple from the same column are also marked. Figure 6.10(c) shows

the Matlab simulation results using the input data for this experiment. Figure 6.10(d) shows the

PLC monitoring results for the same input data. The experimental results are consistent with the

Matlab simulation results. This experiment differs from the previous two, because the Petri net

is initialized with a key already validated. This however does will take an extra scan cycle until

the system learn that in fact no key is pressed, going back to waiting for a key to be pressed,

this time in column two, since this is the column the validation of key eight must be active.

Knowing this, as expected, the results show that in the first time instance of pressed keys, the

key validated belongs to the second column, key two. Comparing these results with the ones

on the last experiments we also observe that the rest of the validated keys don’t match, this is

also expect, since the fact that the initialization is done in different columns, with the passage

of time, the column activation for each column will be done indifferent time instances.

6.4 Supervisory Control

In this section we present the results concerning the implementation, to the design Petri net, of

a supervisor based in linear constraints, done in section 5.3, in order to prevent failure in the

designed system, due to more than one key being pressed simultaneously. It is our objective to

60 Experiments

successfully test various keyboard inputs, leading to situations where the supervisor is crucial

for proper operation of the implemented Petri net system. Inorder to simulate keyboard key

pressing and release, and to monitor PLC results, the developed monitoring system (powered by

a DC power supply) connected to a PC was used, as well the system terminal. The experimental

setup is the same used in section 6.2.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]

Time Key Inputs Expected Result0 1 11 - -2 - -3 - -4 - -5 - -6 - -7 - -8 2, 8 Error9 - -10 - -11 - -12 - -13 5 514 - -15 - -16 - -17 - -

(a) Input data, pressed keys. (b) Expected results given theinput data.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Errors

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Errors

key 1

key 2

key 3

key 4

key 5

key 6

key 7

key 8

key 9

key 10

key 11

key 12

time[s]

(c) Expected output for supervisor experiments,MatLab simulation.

(d) Monitoring supervisor experiment results.

Figure 6.11: PLC output captured by the Arduino based monitor, input data key sequence (a).Input data, sequence of keys (b). Expected output, MatLab Simulation (c). PLC output observedwith the developed monitor (d).

The first experiment in this section, is done to verify if the supervisor implementation is

working properly, preventing system failure due to multiple keys from the same column being

pressed at the same time. Taking this into consideration, itis not expected that any key is

validated, on the contrary, an error state should be monitored by the system implemented in the

PLC.


Figure 6.11 (a) shows the key combinations being pressed andreleased by the developed

monitoring system, during a time period of eighteen seconds(input data). The table (b) in

the same Figure shows the expected results for each time instant. Figure 6.11 (c) shows the

Matlab simulation results from the input data mentioned above. Figure 6.11 (d) shows the PLC

monitoring results for the same input data. Both results are consistent with the expected results,

and with each other. The supervisor detects triggering of multiple keys and does not validate any

of them. In the Matlab simulation that single keys being pressed during the time of experiment

are validated, but when the system receives multiple keys from the same column, eight seconds

time mark, no key is validated. In the monitoring results, nokey validated in the eight seconds

time instance, and we can also observe that the PLC outputs the error bit sequence as mentioned

in section 5.4. This error sequence is received multiple times during the referred time instance,

this is due to the fact that the PLC keeps receiving, from the monitoring system, the same key

triggering information for every scan cycle it does during the said time period.

To further experiment the supervisor implantation severaltest were conceived. The key-

board inputs done in order to test the supervisor implementation were the following:

i) Three keys from the same keyboard column are pressed at theinstant of time, and are

released after one second.

ii) Two keys from the different keyboard columns are pressedat the same instant of time.

After one second, one key is released and the other stays pressed for one more second.

iii) One key is pressed, after one second two more keys, from the same column of the first key,

are pressed (the first key remains pressed). The three keys remain pressed for two seconds,

except for the first pressed key which remains pressed for onemore second after the others

have been released.

iv) Two keys from the same keyboard column are pressed at the same instant of time. After

one second, one key is released and the other stays pressed for one more second.

Figure 6.12 (a) shows the key combinations being pressed andreleased by the developed

monitoring system, during a time period of eighteen seconds(input data). The supervisor tests

referred above are outlined by green rectangles, with the test specific identifying letter beneath

them. The table from Figure 6.12 (b) shows the expected results for each time instant.

The first test, i), is done to check if the main reason for supervisor implementation is working

properly, prevention of system failure due to multiple keysfrom the same column being pressed

at the same time. Taking this into consideration, it is not expected that any key is validated, on

the contrary, an error state should be monitored by the system implemented in the PLC.

62 Experiments

a)

b)

c)

d)

Time Key Inputs Expected Result0 - -1 5 52 - -3 2 24 1, 4, 7 Error5 - -6 2, 6 2 or 67 6 68 2 29 2 210 9 911 3, 9, 12 Error12 3, 9, 12 Error13 9 914 - -15 2, 11 Error16 11 1117 - -

(a) Input data, pressed keys, including variouscases of simultaneous keys (green rectangles).

(b) Expected results given the input data.

a)

b)

c)

d)

a)

b)

c)

d)

(c) Expected output for supervisor experiments,MatLab simulation.

(d) Monitoring supervisor experiment results.

Figure 6.12: PLC output captured by the Arduino based monitor, multiple experiments, inputdata key sequence (a). Input data, sequence of keys (b). Expected output, MatLab Simulation(c). PLC output observed with the developed monitor (d).

In test ii) although multiple keys are being pressed, since they are not in the same keyboard

column, it is expected that one of the two keys is validated, taking into account the fact the im-

plemented Petri net cyclically checks for key triggering for each column, and that the supervisor

only checks for key triggering conflicts for in the active column.

Test iii) serves the purpose of proving that in a case where a key is already validated, the

fact that in a future time instance keys from the same column are pressed, does not make the

enter a error state. In fact the supervisor keeps the previous key validated until said key is not

being pressed.

On test iv) the opposite of test iii) is being checked. Two keys from the same column are


triggered, making the supervisor take the system to error state, and in the next instance of time

one of the two keys is released. The proper response from the system should be leaving the

error state and validating the key that remains pressed.

Figure 6.12 (c) shows the Matlab simulation results from theinput data mentioned above.

Figure 6.12 (d) shows the PLC monitoring results for the sameinput data. The results from

tests done to detect supervisor behavior are outlined by green rectangles, with the test specific

identifying letter beneath them. Both results are consistent with the expected results, and with

each other.

Test i) result is consistent with expected results. The supervisor in fact detects triggering of

multiple keys and does not validate any of them. In the Matlabsimulation this is represented

by no key being ON in the time instance from four to five seconds. In the monitoring results,

not only is no key ON in the four to five seconds time instance, but we can also observe that

the PLC outputs the error bit sequence as mentioned in section 5.4. This error sequence is

received multiple times during the referred time instance,this is due to the fact that the PLC

keeps receiving, from the monitoring system, the same key triggering information for every

scan cycle it does during the said time period.

In test ii), as intended, the supervisor does not interfere with key validation. This is ob-

servable in both the Matlab simulation and the PLC monitoring results. As said, since the keys

pressed are not the same column the key validated is the one that is part of the column the Petri

net implemented system is scanning, or from the next column to be scanned that contains a

pressed key, in case none of the keys pressed are from the currently being scanned column.

Test iii) is also consistent with expected results, for boththe Matlab simulation and the PLC

implementation. At time equals ten seconds key nine is triggered, and as it can be observed

in both the result Figures, it stays validated until it is released in time equals fourteen seconds.

Although more keys from the same column as key nine are triggered in the instance of time

from eleven to thirteen, since a key is already validated, and is not released, the system doesn’t

go into error state. This is actually proven by the fact that the PLC does not output any error bit

sequence for the entire period of time from ten to fourteen seconds.

The last test, test iv), was again a success in terms of agreement between expected, simu-

lation and experimental results. In the Matlab simulation results it is observable that no keys

are validated for the time period keys from the same column are pressed, fifteen to sixteen sec-

onds, and in the exact next time instance when a one of the keysis released, the one that stays

pressed is validated until it is released one second after, meaning that the supervisor detected

the problem while it lasted. This is also observable for the PLC monitoring results, with the

added result that the PLC outputs the error state bit sequence numerous time during the fifteen

64 Experiments

to sixteen time period, each one of those time representing ascan cycle done by the PLC that

continues to detect the same key configuration.

The experimental results obtained in this section prove that the implemented supervisor

works as it was designed to. It is worth mentioning that inputdata for single keys is sent

between the supervisor tests, as it can the seen in Figure 6.12 (a), in order to observe that keys

triggered before or after the events leading to the discussed tests do not interfere with the correct

behavior of the implemented supervisor.

Chapter 7

Conclusion and Future Work

The work described in this thesis is focused in the implementation and implementation-validation

of a discrete event system (DES). The validation is based in adeveloped signal acquirer for PLC

signal inputs and outputs.

We first presented a form of DES representation, Petri nets, aintuitive method that captures

structural information about the system and has mathematical analysis techniques well devel-

oped. This proved to be an effective way to represent our casestudy. We were able to create

the intended system as a Petri net and, using supervising methodologies, we were able to avoid

accepting multiple same-column keys at the same time.

We have developed a signal acquirer, based in the low-cost microcontroller board Arduino

Mega, that can observe and save in memory signals going from and to a PLC connected to a

terminal, and at the same time is able to connect to a PC for further data processing or logging.

More in detail, the signal acquirer is able to act as the terminal, mimicking its behavior by

sending signals to the PLC. In order to achieve this we developed an Arduino shield that is able

to ensure the connections between the Arduino, the PLC and the terminal.

To implement a DES in a PLC, in the form of Petri net representation, we chose to create

a program that produces structured text code. Implementinga Petri net in a device usually re-

quires discrete events, but may also require timed events. To develop the conversion program

we add to take into consideration not only the Petri net relationships between places and tran-

sitions, but we had to take into consideration the assuranceof having a way to initialize the

implemented Petri net in the desired configuration. In addition, we had to define connections

between signal inputs and outputs with the various PLC memory positions attributed to the Petri

net places and transitions.

In summary, besides the central function converting code from a Petri net structure to struc-

66 Conclusion and Future Work

tured text, four other functions had to be created. These points are also valid for the Petri net

simulator used to obtain results about the Petri net development along a time period.

The case studied in chapter 5 showed that, although a Petri net being a good way to represent

a DES, its standard form does not take into consideration some aspects. One of those aspects

is that a PLC is based in scan cycles which constrain the activation speed of transitions. We

also observed in the experiments that a PLC is also subject todelay of signal change detection,

which is another aspect that a Petri net does not take into consideration.

Concluding, the Petri net modeling proved to be effective. Wewere able to obtain a working

system for the proposed case study. The supervisor implementation was also successful, in the

sense that applied the desired constraints. However, even thought we were able to predict to a

large extent the experimental results, the experiment consisting of changing the initial marking

of a Petri net, proved that a DES implementation into a real world situation has more details

that have to be taken into consideration than those presented by a Petri net.

Future work should focus on further development of the Arduino based shield. Ways to not

bind each of the Arduino’s inputs and outputs to one signal can be implemented using integrated

circuits that can send send signals to multiple lines at the same time, by only receiving signal

from one source. This would make it possible to use a even lower-cost version of the Arduino

board.

Another aspect that should be developed, is the DES representation. The use of a more

advanced Petri net representation, I/O Petri net, can lead to a more detailed DES representation,

with fewer aspects that affect its implementation.

Appendix A

Arduino Shield for IO Monitoring

This appendix presents the circuit diagram and PCB schematicfor an Arduino Mega shield,

developed as part of this thesis signal acquirer. Section 3.3 details the development of the

referred signal acquirer.

68 Arduino Shield for IO Monitoring

Figure A.1: Arduino shield electronic schematic.

69

Figure A.2: Arduino shield PCB schematic.

Figure A.3: Arduino shield physical PCB, front.

70 Arduino Shield for IO Monitoring

Figure A.4: Arduino shield physical PCB, back.

Appendix B

PN to PLC Compiler Usage

This Appendix shows the usage of PN to PLC compiler functions, introduced in section 5.4,

applied to the case study detailed in chapter 5.

The compiler functions are called in the main script shown infig. B.1.

In this appendix are also listed the auxiliary functions that prepare all problem specific data,

like timed transitions and physical inputs or outputs, to beused straightforward by the main

script. More in detail, the auxiliary functions do: (i) loadthe Petri net, including priority and

timed transitions, see fig. B.2, (ii) define the mapping of PLC inputs to PN transitions, see

fig. B.3 and (iii) define the mapping of PN state to PLC outputs, see fig. B.4.

In order to help observing the state of the PN running in the PLC, 13 places of the PN are en-

coded as 4 output bits of the PLC. See the call ofplc_encode_places in the main script and

the definition ofplaces_to_show in the auxiliary functiondefine_output_mapping.

The result of the main script, the complete ST program created, is listed in appendix C.

72 PN to PLC Compiler Usage

1 f unc t i on make_PLC_program23 % load t h e P e t r i Net f rom f i l e4 [ pre , pos , mu0 , t p r i o , t t i m e d ]= l o a d _ P e t r i _ N e t ;56 % Create PLC code t o map PLC i n p u t s t o PN t r a n s i s t i o n s7 inp_map= d e f i n e _ i n p u t _ m a p p i n g ;8 p r g _ t f i r e = p l c_map_ inpu ts ( inp_map ) ;9

10 % Create PLC code t o make t imed t r a n s i t i o n s ( f i r e a f t e r t i m e ou t s )11 p r g _ t t r a n s = p l c _ t i m e d _ t r a n s i t i o n s ( t t i m e d ) ;1213 % Create PLC code t o run t h e P e t r i Net14 [ p rg_pn_ in i , prg_pn ]= p l c _ e n c o d e _ p e t r i _ n e t ( pre , pos ,mu0 , t p r i o ) ;1516 % Create PLC code t o map PN p l a c e s t o PLC o u t p u t s17 [ output_map , p laces_ to_show ]= de f i ne_ou tpu t_mapp ing;18 p r g _ a c t = p l c _ o u t p u t _ i f _ a n y _ p l a c e ( output_map ) ;1920 % Create PLC code t o o u t p u t debug / mon i to r i n f o21 prg_you t = p l c _ e n c o d e _ p l a c e s ( p laces_ to_show {1} , p laces_ to_show { 2 } ) ;2223 % Save a l l code t o a t e x t f i l e24 ofname= ’ t s t_mk_prog ram_res . t x t ’ ;25 f p r i n t f ( 1 , ’−− Wr i t i ng "%s " . . . ’ , ofname ) ;26 t e x t _ w r i t e ( ofname , . . .27 p rg_pn_ in i , . . .28 p r g _ t f i r e , . . .29 p r g _ t t r a n s , . . .30 prg_pn , . . .31 p rg_ac t , . . .32 p rg_you t )33 f p r i n t f ( 1 , ’ done . \ n ’ ) ;3435 re turn

Figure B.1: Create a PLC program from a Petri Net and IO mapping.

1 f unc t i on [ pre , pos , mu0 , t p r i o , t t i m e d ]= l o a d _ P e t r i _ N e t23 [D, mu0 ] = g e n e r a t e _ c o n t r o l l e d _ p e t r i ( ’ p l a n t _ s u p e r v i s or . mat ’ ) ;4 [ pre , pos ] = PN_decomp (D) ;% s p l i t D i n t o D+ ( pos ) and D− ( pre )5 t p r i o = [28 2 9 ] ; % t r a n s i t i o n s 28 and 29 have p r i o r i t y6 T= 50e−3; % 50 m i l i s e c o n d s t i m e o u t7 t t i m e d = [T 1 1 ; T 11 2 ; T 2 3 ] ;89 re turn

Figure B.2: Load a Petri Net from file.

73

1 f unc t i on inp_map= d e f i n e _ i n p u t _ m a p p i n g23 % d e f i n e r e c e p t i v i t y f u n c t i o n s4 % ( f i r s t d e f i n e a u x i l i a r y f u n c t i o n s )5 neg_mk = @( x)(−x−100);6 inp_and = @( a , b ) [ a ; 0∗a+b ] ;78 inp_map= { . . .9 inp_and ( 0 : 3 , 4 ) , [4 5 6 3 ] ; . . .

10 inp_and ( neg_mk ( 0 : 3 ) , 4 ) , [9 10 7 8 ] ; . . .11 inp_and ( 0 : 3 , 5 ) , 1 2 : 1 5 ; . . .12 inp_and ( neg_mk ( 0 : 3 ) , 5 ) , 1 6 : 1 9 ; . . .13 inp_and ( 0 : 3 , 6 ) , 2 0 : 2 3 ; . . .14 inp_and ( neg_mk ( 0 : 3 ) , 6 ) , 2 4 : 2 7 ; . . .15 neg_mk ( 7 ) , 0 } ; % i n p u t 7 => PN/ PLC r e s e t1617 mul t iKeyTrue= s t r u c t ( ’ op ’ , ’OR_of_ANDs ’ , ’ t r a n s I d ’ ,28 , . . .18 ’ l s t ’ , { { [0 1 ] , [0 2 ] , [0 3 ] , [1 2 ] , [1 3 ] , [2 3 ] } } ) ;19 inp_map {end+1 ,1}= mul t iKeyTrue ;2021 mu l t iKeyFa l se = s t r u c t ( ’ op ’ , ’NOR_of_ANDs ’ , ’ t r a n s I d ’,29 , . . .22 ’ l s t ’ , { { [0 1 ] , [0 2 ] , [0 3 ] , [1 2 ] , [1 3 ] , [2 3 ] } } ) ;23 inp_map {end+1 ,1}= mu l t iKeyFa l se ;2425 re turn

Figure B.3: Define the mapping of PLC inputs to PN transitions.

1 f unc t i on [ output_map , p laces_ to_show ]= de f i ne_ou tpu t_mapp ing23 % d e f i n e o u t p u t b i t s e s s e n t i a l f o r t h e sys tem t o work4 % PN p l a c e s 1 , 2 , 3 , 4 : 7 , 8 : 1 1 , 1 2 : 1 5 imp ly PLC o u t p u t s 16 ,17 ,185 %6 col1_ON= [ 1 , 4 : 7 ] ;7 col2_ON= [ 2 , 8 : 1 1 ] ;8 col3_ON= [ 3 , 1 2 : 1 5 ] ;9 output_map= {col1_ON , 16 ; col2_ON , 17 ; col3_ON , 18} ;

1011 % d e f i n e o u t p u t b i t s f o r sys tem s t a t e o b s e r v a t i o n / debug purposes12 % i n t h e f o l l o w i n g example t h e r e are 13 PN p l a c e s (−1 v a l u e s are igno red )13 % t o be mapped as 4 o u t p u t b i t s 24:2714 %15 p laces_ to_show {1}= [6 9 13 7 8 12 5 10 14 4 11 15−1 −1 1 7 ] ;16 p laces_ to_show {2}= [ 2 4 : 2 7 ] ;1718 re turn

Figure B.4: Define the mapping of PN places to PLC outputs.

74 PN to PLC Compiler Usage

Appendix C

PLC Program

The PLC Structured Text program listed in this appendix is the implementation of the solution

of the case study presented in chapter 5. The program was generated by the main script listed

in appendix B.

1

2 (∗ −−− PNC: P e t r i n e t i n i t i a l i z a t i o n −−− ∗ )

3

4 IF %MW100=0 THEN

5 %MW201: = 1 ; %MW202: = 0 ; %MW203: = 0 ; %MW204: = 0 ; %MW205: = 0 ;%MW206: = 0 ;

6 %MW207: = 0 ; %MW208: = 0 ; %MW209: = 0 ; %MW210: = 0 ; %MW211: = 0 ;%MW212: = 0 ;

7 %MW213: = 0 ; %MW214: = 0 ; %MW215: = 0 ; %MW216: = 1 ; %MW217: = 0 ;%MW218: = 1 ;

8 %MW219: = 1 ; %MW220: = 1 ; %MW221: = 1 ; %MW222: = 1 ; %MW223: = 1 ;%MW224: = 1 ;

9 %MW225: = 1 ; %MW226: = 1 ; %MW227: = 1 ; %MW228: = 1 ; %MW229: = 1 ;

10 %MW100: = 1 ;

11 END_IF ;

12

13 (∗ −−− PNC: Map i n p u t s−−− ∗ )

14

15 %MW104 := BOOL_TO_INT( %i 0 . 3 . 0AND %i 0 . 3 . 4 ) ;




19 %MW109 := BOOL_TO_INT( NOT(% i 0 . 3 . 0 ) AND %i 0 . 3 . 4 ) ;






76 PLC Program















39 %MW100 := BOOL_TO_INT( NOT(% i 0 . 3 . 7 ) ) ;

40 %MW128 := BOOL_TO_INT( (% i 0 . 3 . 0AND %i 0 . 3 . 1 )

41 OR (% i 0 . 3 . 0 AND %i 0 . 3 . 2 ) OR (% i 0 . 3 . 0 AND %i 0 . 3 . 3 )

42 OR (% i 0 . 3 . 1 AND %i 0 . 3 . 2 ) OR (% i 0 . 3 . 1 AND %i 0 . 3 . 3 )

43 OR (% i 0 . 3 . 2 AND %i 0 . 3 . 3 ) ) ;

44 %MW129 := BOOL_TO_INT( NOT( (% i 0 . 3 . 0 AND %i 0 . 3 . 1 )

45 OR (% i 0 . 3 . 0 AND %i 0 . 3 . 2 ) OR (% i 0 . 3 . 0 AND %i 0 . 3 . 3 )

46 OR (% i 0 . 3 . 1 AND %i 0 . 3 . 2 ) OR (% i 0 . 3 . 1 AND %i 0 . 3 . 3 )

47 OR (% i 0 . 3 . 2 AND %i 0 . 3 . 3 ) ) ) ;

48

49 (∗ −−− PNC: Timed t r a n s i t i o n s−−− ∗ )

50

51 MY_TON_1(IN := INT_TO_BOOL(%MW201) (∗BOOL∗ ) ,

52 PT := t #50ms (∗TIME∗ ) ,

53 Q => t i m e r _ o u t p u t _ f l a g (∗BOOL∗ ) ,

54 ET => my_time_1 (∗TIME∗ ) ) ;

55 %MW101:= BOOL_TO_INT( t i m e r _ o u t p u t _ f l a g ) ;


57 PT := t #50ms (∗TIME∗ ) ,


59 ET => my_time_2 (∗TIME∗ ) ) ;



62 PT := t #50ms (∗TIME∗ ) ,


64 ET => my_time_3 (∗TIME∗ ) ) ;


66

77

67 (∗ −−− PNC: P e t r i n e t loop code−−− ∗ )

68

69 IF %MW128>0 AND %MW216>=1 AND %MW218>=1 AND %MW219>=1 AND %MW220>=1

70 AND %MW221>=1 AND %MW222>=1 AND %MW223>=1 AND %MW224>=1 AND %MW225>=1

71 AND %MW226>=1 AND %MW227>=1 AND %MW228>=1 AND %MW229>=1

72 THEN

73 %MW216:=%MW216−1; %MW218:=%MW218−1; %MW219:=%MW219−1;

74 %MW220:=%MW220−1; %MW221:=%MW221−1; %MW222:=%MW222−1; %MW223:=%MW223−1;

75 %MW224:=%MW224−1; %MW225:=%MW225−1; %MW226:=%MW226−1; %MW227:=%MW227−1;

76 %MW228:=%MW228−1; %MW229:=%MW229−1;

77 %MW217:=%MW217+1;

78 END_IF ;

79

80 IF %MW129>0 AND %MW217>=1

81 THEN

82 %MW217:=%MW217−1;

83 %MW216:=%MW216+1; %MW218:=%MW218+1; %MW219:=%MW219+1; %MW220:=%MW220+1;



86 %MW229:=%MW229+1;

87 END_IF ;

88

89 IF %MW101>0 AND %MW201>=1

90 THEN

91 %MW201:=%MW201−1;

92 %MW202:=%MW202+1;

93 END_IF ;

94

95 IF %MW102>0 AND %MW203>=1

96 THEN

97 %MW203:=%MW203−1;

98 %MW201:=%MW201+1;

99 END_IF ;

100

101 IF %MW103>0 AND %MW201>=1 AND %MW221>=1

102 THEN

103 %MW201:=%MW201−1; %MW221:=%MW221−1;

104 %MW204:=%MW204+1;

105 END_IF ;

106

107 IF %MW104>0 AND %MW201>=1 AND %MW218>=1

108 THEN

78 PLC Program

109 %MW201:=%MW201−1; %MW218:=%MW218−1;

110 %MW206:=%MW206+1;

111 END_IF ;

112

113 IF %MW105>0 AND %MW201>=1 AND %MW219>=1

114 THEN

115 %MW201:=%MW201−1; %MW219:=%MW219−1;

116 %MW207:=%MW207+1;

117 END_IF ;

118

119 IF %MW106>0 AND %MW201>=1 AND %MW220>=1

120 THEN

121 %MW201:=%MW201−1; %MW220:=%MW220−1;

122 %MW205:=%MW205+1;

123 END_IF ;

124

125 IF %MW107>0 AND %MW205>=1

126 THEN

127 %MW205:=%MW205−1;

128 %MW201:=%MW201+1; %MW220:=%MW220+1;

129 END_IF ;

130

131 IF %MW108>0 AND %MW204>=1

132 THEN

133 %MW204:=%MW204−1;

134 %MW201:=%MW201+1; %MW221:=%MW221+1;

135 END_IF ;

136

137 IF %MW109>0 AND %MW206>=1

138 THEN

139 %MW206:=%MW206−1;

140 %MW201:=%MW201+1; %MW218:=%MW218+1;

141 END_IF ;

142

143 IF %MW110>0 AND %MW207>=1

144 THEN

145 %MW207:=%MW207−1;

146 %MW201:=%MW201+1; %MW219:=%MW219+1;

147 END_IF ;

148

149 IF %MW111>0 AND %MW202>=1

150 THEN

79

151 %MW202:=%MW202−1;

152 %MW203:=%MW203+1;

153 END_IF ;

154

155 IF %MW112>0 AND %MW202>=1 AND %MW222>=1

156 THEN

157 %MW202:=%MW202−1; %MW222:=%MW222−1;

158 %MW209:=%MW209+1;

159 END_IF ;

160

161 IF %MW113>0 AND %MW202>=1 AND %MW223>=1

162 THEN

163 %MW202:=%MW202−1; %MW223:=%MW223−1;

164 %MW208:=%MW208+1;

165 END_IF ;

166

167 IF %MW114>0 AND %MW202>=1 AND %MW224>=1

168 THEN

169 %MW202:=%MW202−1; %MW224:=%MW224−1;

170 %MW210:=%MW210+1;

171 END_IF ;

172

173 IF %MW115>0 AND %MW202>=1 AND %MW225>=1

174 THEN

175 %MW202:=%MW202−1; %MW225:=%MW225−1;

176 %MW211:=%MW211+1;

177 END_IF ;

178

179 IF %MW116>0 AND %MW209>=1

180 THEN

181 %MW209:=%MW209−1;

182 %MW202:=%MW202+1; %MW222:=%MW222+1;

183 END_IF ;

184

185 IF %MW117>0 AND %MW208>=1

186 THEN

187 %MW208:=%MW208−1;

188 %MW202:=%MW202+1; %MW223:=%MW223+1;

189 END_IF ;

190

191 IF %MW118>0 AND %MW210>=1

192 THEN

80 PLC Program

193 %MW210:=%MW210−1;

194 %MW202:=%MW202+1; %MW224:=%MW224+1;

195 END_IF ;

196

197 IF %MW119>0 AND %MW211>=1

198 THEN

199 %MW211:=%MW211−1;

200 %MW202:=%MW202+1; %MW225:=%MW225+1;

201 END_IF ;

202

203 IF %MW120>0 AND %MW203>=1 AND %MW226>=1

204 THEN

205 %MW203:=%MW203−1; %MW226:=%MW226−1;

206 %MW213:=%MW213+1;

207 END_IF ;

208

209 IF %MW121>0 AND %MW203>=1 AND %MW227>=1

210 THEN

211 %MW203:=%MW203−1; %MW227:=%MW227−1;

212 %MW212:=%MW212+1;

213 END_IF ;

214

215 IF %MW122>0 AND %MW203>=1 AND %MW228>=1

216 THEN

217 %MW203:=%MW203−1; %MW228:=%MW228−1;

218 %MW214:=%MW214+1;

219 END_IF ;

220

221 IF %MW123>0 AND %MW203>=1 AND %MW229>=1

222 THEN

223 %MW203:=%MW203−1; %MW229:=%MW229−1;

224 %MW215:=%MW215+1;

225 END_IF ;

226

227 IF %MW124>0 AND %MW213>=1

228 THEN

229 %MW213:=%MW213−1;

230 %MW203:=%MW203+1; %MW226:=%MW226+1;

231 END_IF ;

232

233 IF %MW125>0 AND %MW212>=1

234 THEN

81

235 %MW212:=%MW212−1;

236 %MW203:=%MW203+1; %MW227:=%MW227+1;

237 END_IF ;

238

239 IF %MW126>0 AND %MW214>=1

240 THEN

241 %MW214:=%MW214−1;

242 %MW203:=%MW203+1; %MW228:=%MW228+1;

243 END_IF ;

244

245 IF %MW127>0 AND %MW215>=1

246 THEN

247 %MW215:=%MW215−1;

248 %MW203:=%MW203+1; %MW229:=%MW229+1;

249 END_IF ;

250

251 (∗ −−− PNC: Output b i t s−−− ∗ )

252

253 IF INT_TO_BOOL(%MW201) OR INT_TO_BOOL(%MW204)

254 OR INT_TO_BOOL(%MW205) OR INT_TO_BOOL(%MW206)

255 OR INT_TO_BOOL(%MW207)

256 THEN SET(%q0 . 3 . 1 6 ) ;

257 ELSE RESET(%q0 . 3 . 1 6 ) ;

258 END_IF ;




262 THEN SET(%q0 . 3 . 1 7 ) ;

263 ELSE RESET(%q0 . 3 . 1 7 ) ;

264 END_IF ;




268 THEN SET(%q0 . 3 . 1 8 ) ;

269 ELSE RESET(%q0 . 3 . 1 8 ) ;

270 END_IF ;

271

272 (∗ −−− PNC: Encode p l a c e s−−− ∗ )

273

274 o u t p u t _ f l a g := Fa lse;

275 o u t p u t := 0 ;

276 IF %MW206>0 THEN

82 PLC Program

277 IF o u t p u t _ f l a g THEN o u t p u t : = 1 5 ;

278 ELSE o u t p u t : = 1 ; o u t p u t _ f l a g :=True ;

279 END_IF ;

280 END_IF ;




284 END_IF ;

285 END_IF ;




289 END_IF ;

290 END_IF ;




294 END_IF ;

295 END_IF ;




299 END_IF ;

300 END_IF ;




304 END_IF ;

305 END_IF ;




309 END_IF ;

310 END_IF ;




314 END_IF ;

315 END_IF ;




83

319 END_IF ;

320 END_IF ;



323 ELSE o u t p u t : = 1 0 ; o u t p u t _ f l a g :=True ;

324 END_IF ;

325 END_IF ;




329 END_IF ;

330 END_IF ;




334 END_IF ;

335 END_IF ;




339 END_IF ;

340 END_IF ;

341 %q0 . 3 . 2 4 := ( o u t p u t & 1 ) < >0;

342 %q0 . 3 . 2 5 := ( o u t p u t & 2 ) < >0;

343 %q0 . 3 . 2 6 := ( o u t p u t & 4 ) < >0;

344 %q0 . 3 . 2 7 := ( o u t p u t & 8 ) < >0;

84 PLC Program

Appendix D

Arduino program

The Arduino main program functions are listed in this appendix. The program way of working

and functions are explain in section 3.4.1.

1

2 i n t s e r i a l _ r e a d _ s t r (char ∗buf , i n t b u f l e n ) {

3 / / read t i l l t h e end o f t h e b u f f e r or a t e r m i n a t i n g char

4 i n t i , c ;

5 i f ( S e r i a l . a v a i l a b l e ( ) <= 0) {

6 re turn 0 ;

7 }

8 f o r ( i =0; i < bu f l en−1; i ++) {

9 c= S e r i a l . r ead ( ) ;

10 i f ( c==0 | | c==0x0A ) break ;

11 ∗buf ++= c ;

12 i f ( S e r i a l . a v a i l a b l e ( ) <= 0) {

13 de l ay ( 1 0 ) ; / / 10 m i l l i s e c o n d s = 96 b i t s / 9600 b i t s / sec

14 i f ( S e r i a l . a v a i l a b l e ( ) <= 0)break ;

15 }

16 }

17 ∗buf= ’ \ 0 ’ ;

18 re turn 1 ;

19 }

20

21 void main_send_end_cmd ( ) {

22 S e r i a l . p r i n t l n ( "> " ) ;

23 }

24

25 void s t o r e _ i n p u t s ( ) {

26 boo l change = f a l s e ;

86 Arduino program

27 f o r ( by te i = 0 ; i < IN_PINS ; i ++) {

28 boo l l a s t S t a t e = b i tRead ( l a s t R e a d i n g , i ) ;

29 boo l p i n S t a t e ;

30 p i n S t a t e = d i g i t a l R e a d ( i _ p i n s [ i ] ) ;

31 t ime = m i l l i s ( ) ;

32 i f ( p i n S t a t e != l a s t S t a t e ) {

33 change = t r u e ;

34 b i t W r i t e ( l a s t R e a d i n g , i , p i n S t a t e ) ;

35 }

36 }

37 / / i f change i s t r u e a t l e a s t one p in s t a t e changed

38 / / and l a s t R e a d i n g w i l l c o n t a i n p i n s s t a t e s

39 i f ( change ) {

40 d a t a [ chgs ] = l a s t R e a d i n g ;

41 t i m e _ d a t a [ chgs ] = t ime− t i m e _ i n i ;

42 chgs ++;

43 }

44 }

45

46 void t f i r e ( ) {

47 t ime = t ime − t i m e _ i n i ;

48 t ime = t ime / 1 0 0 0 ;

49 i f ( p l c _ i n i t == f a l s e ) {

50 d i g i t a l W r i t e ( o_p ins [ 7 ] , t r u e ) ;

51 de layM ic roseconds ( 1 0 0 0 ) ;

52 d i g i t a l W r i t e ( o_p ins [ 7 ] , f a l s e ) ;

53 p l c _ i n i t = t r u e ;

54 }

55 i f ( t ime > 20) {

56 r e c o r d = f a l s e ;

57 f i r e = f a l s e ;

58 r e c o r d _ i n i = f a l s e ;

59 p l c _ i n i t = f a l s e ;

60 f o r ( i n t i =0 ; i <= 3 ; i ++) { d i g i t a l W r i t e ( o_p ins [ i ] , f a l s e ) ; }

61 main_send_end_cmd ( ) ;

62 }

63 / / Sends d e f i n e d key s i g n a l depend ing on t ime s i n c e t f i r e ( ) has began .

64 e l s e { k e y s _ p r e s s e d _ a t _ t i m e ( ) ; }

65 }

Bibliography

[1] Christos G. Cassandras and Stéphane Lafortune.Introduction to discrete event systems.

Springer Science+Business Media, New York, N.Y, 2008.

[2] Steven J. Cunning and Jerzy W. Rozenblit. Automating test generation for discrete event

oriented embedded systems.Journal of Intelligent and Robotic Systems, 41(2-3):87–112,

2005.

[3] Geoff Cutts and Shaun Rattigan. Using Petri nets to developprograms for PLC systems.

In Application and Theory of Petri Nets 1992, pages 368–372. Springer, 1992.

[4] Ana Paula Estrada-Vargas, Ernesto Lopez-Mellado, and Jean-Jacques Lesage. Automated

modelling of reactive discrete event systems from externalbehavioural data. InElectron-

ics, Communications and Computing (CONIELECOMP), 2013 International Conference

on, pages 120–125. IEEE, 2013.

[5] Ana Paula Estrada-Vargas, Ernesto Lopez-Mellado, and Jean-Jacques Lesage. Identifica-

tion of partially observable discrete event manufacturingsystems. InEmerging Technolo-

gies & Factory Automation (ETFA), 2013 IEEE 18th Conference on, pages 1–7. IEEE,

2013.

[6] Eurocircuits. Online pcb prototype and small series specialist.

http://www.eurocircuits.com/, 2015.

[7] A. Gordon, F. Bousseau, and N. Dangoumau. PM Editor.

[8] Tao Huang and Anthony Chung. Communication networks and systems in substations.

2004.

[9] M. V. Iordache and P. J. Antsaklis. Supervision Based on Place Invariants: A Survey.

Discrete Event Dynamic Systems, 16(4):451–492, December 2006.

88 BIBLIOGRAPHY

[10] Marian V. Iordache and Panos J. Antsaklis. Software tools for the supervisory control of

Petri nets based on place invariants.ISIS, page 003, 2002.

[11] Marian V. Iordache and Panos J. Antsaklis. Synthesis ofsupervisors enforcing firing vector

constraints in petri nets.ISIS, page 002, 2002.

[12] Marian V. Iordache and Panos J. Antsaklis. Decentralized control of Petri nets with con-

straint transformations. InAmerican Control Conference, 2003. Proceedings of the 2003,

volume 1, pages 314–319. IEEE, 2003.

[13] Marian Valentin. Iordache and Panos J. Antsaklis.Supervisory control of concurrent sys-

tems a Petri net structural approach. Birkhäuser, Boston, 2004.

[14] S. Jain, R. R. Creasey, J. Himmelspach, K. P. White, and M. Fu.VERIFICATION AND

VALIDATION OF SIMULATION MODELS.

[15] Thomas Mertke and Georg Frey. Formal Verification Of PLC-Progams Generated From

Signal Interpreted Petri Nets. InIEEE Systems, Man, and Cybernetics Conference. IEEE,

2001.

[16] Mark Minas and Georg Frey. Visual PLC-Programming usingSignal Interpreted Petri

Nets. InAmerican Control Conference, 2003, 2002.

[17] John O. Moody and Panos J. Antsaklis.Supervisory Theory of DES Using Petri Nets.

Kluwer Academic Publishers, Notre Dame, 1998.

[18] Thomas H. Naylor, J. M. Finger, James L. McKenney, William E. Schrank, and Charles C.

Holt. Verification of computer simulation models.Management Science, 14(2):pp. B92–

B106, 1967.

[19] Paulo Oliveira. Industrial processes automation (course IST/MEEC). https:

//fenix.tecnico.ulisboa.pt /disciplinas /APInd /2010-2011 /1-semestre, 2010.

[20] Fernando Pereira and Luís Gomes. Automatic synthesis of VHDL Hardware Components

from IOPT Petri Net models. InIEEE, 2013.

[21] James L. Peterson.Petri Net Theory and the Modeling of Systems. Pretice-Hall, Austin,

Texas, 1981.

[22] Carl Petri.Communication With Automata. PhD thesis, Darmstadt University of Technol-

ogy, 1962.

BIBLIOGRAPHY 89

[23] Jean-Marc Roussel and Jean-Jacques Lesage. Validationand verification of grafcets using

state machine. InIMACS-IEEE" CESA’96", pages pp–758, 1996.

[24] Klein S, Georg Frey, and Mark Minas. PLC Programming with Signal Interpreted Petri

Nets. InICATPN, LNCS, 2003.

[25] S. Schlesinger.Terminology for model credibility. 1979.

[26] Tamas Schne and Tibor Holczinger. Coloured Petri Net based PLC program validation

with a fast simulation method. InProcess Control (PC), 2013 International Conference

on, pages 179–184. IEEE, 2013.

[27] Martina Svádová and Zdenek Hanzálek. Matlab toolbox for petri nets. In22nd Interna-

tional conference ICATPN 2001, pages 32–36, 2001.

monitoring programmable logic controllers - autenticação · thesis to obtain the master of...

Documents