THE 8th INTERNATIONAL SYMPOSIUM ON ADVANCED TOPICS IN ELECTRICAL ENGINEERING May 23-25, 2013

Bucharest, Romania

Petri Net versus Ladder Diagram for Controlling a Process Automation

Valentin NĂVRĂPESCU1, Member IEEE, Ioan-Dragoş DEACONU1, Member IEEE, Aurel-Ionuţ CHIRILĂ1, Member IEEE,

Anca-Simona DEACONU 1PLC Laboratory - Facultatea de Inginerie Electrică, Universitatea Politehnica din Bucureşti

valentin.navrapescu@gmail.com, dragos.deaconu@gmail.com, aurel.chirila@gmail.com, anca.s.deaconu@gmail.com

Abstract- Industrial automation is constantly expanding, and, regarding their control more and more solutions are presently developing on the market. These include older methods like Petri nets (1966), and standardized languages, which arecommonly used in the field of programmable logic controllers (PLCs). The paper presents the Ladder Diagram programming language, that is one of the standardized languages, and one of the most widely used for industrial automation systems. In these circumstances, it is useful to make a comparison between the two methods, drawing out the advantages and the disadvantages of each solution separately. Petri nets benefit from the existence of a highly developed mathematical support and high flexibility in analyzing all elements that can influence the conduct of an event, which is a major advantage. On the other hand, the Ladder Diagram language, which corresponds to the standard IEC 61131, is easy to use and implement, regardless of the hardware structure used by the manufacturer. Also, this method allows both ON-line and OFF-line simulations of the automation process operation. Finally, an educational platform is also presented.

Keywords: PLC, Petri net, Ladder Diagram

I. INTRODUCTION

The paper aims to analyze two solutions for the control design of a process. Due to general applicability of the both methods to any industrial process automation, as an example application a freight elevator has been considered. Automating the process involves actually implementing the command and the control operation of a freight elevator that operates between three levels. The application implementation based on the Ladder Diagram programming language for a programmable logic controller can be achieved in two ways [1]. The first method, which is simpler, it is not necessarily the one that offers the best overall performance. This consists in the development of the application program directly into the programming environment. A second solution is to design and simulate the application operation using Petri nets [2]. This solution is a very flexible because it allows for subsequent implementation also using a software environment in accordance to IEC 61131 standard, being this either Ladder Diagram, or in some cases Functional Block Diagram, Instruction List or Structured Text.

II. PROCESS AUTOMATION

For comparison, be it not a throughout comparison, a freight elevator control has been considered as an automation process example. The implementation has been performed for

a predetermined operating program of the elevator. Depending on the application, the program may be different for sure. Examples of usages of such an elevator are the operation within a library (take from or put back on the shelves the requested books), a restaurant or a hotel (food and drink orders and/or laundry transportation), a manufacturing unit or a warehouse (for logistic purposes to receive or send various parts or packages). A detailed comparison should take into account not only the advantages offered by each of the two methods, but also should consider the time required for the program development, testing and implementation and not lastly the total running time of the program. In the case of an industrial application, whatever the size of the application large or small, it is important to evaluate how difficult it is to achieve a maintenance program and hence the operation of the entire process, the cost generated by this operation, the total service time, which in fact it is a delay without revenue.

The application represents the development of the control for a freight elevator that has to operate on three levels. The designed and manufactured educational platform is shown in Fig. 1.

Fig. 1. The educational platform for the process automation of an elevator.

At each level there is provided an operator panel consisting in push buttons and indicator lamps. On the panel there are

978-1-4673-5980-1/13/$31.00 ©2013 IEEE

four push buttons, one for each level and a fourth for stopping the elevator at any given time moment whatever its current position. The three signaling lamps are two (white color) for each of the moving directions (up or down) and the third one (red color) it is for signaling that the elevator is in resting state at the exact level where it was supposed to arrive and waiting for a new command.

Fig. 2. Reed relay for detecting elevator presence.

The detection of the elevator position at one of the three levels is achieved using proximity detectors, which are reed relay type. One of such devices found on the actual educational platform is shown in Fig. 2.

Similar to any freight elevators that have been previously mentioned, the command can only come outside of the car by using the momentary push buttons.

In the cases of malfunction, when the car end-position sensors (highest and lowest levels) are not operating, end-track sensors are also provided that activate under fault conditions. Once activated such a sensor, the elevator is stopped and signaled both visually and acoustically so that a mechanical maintenance intervention is required. After this information is collected, the signaling can be canceled but the error signal can be canceled only after the fault has been remedied, and so, an acknowledgment to the systems has been given.

In order to fulfill the described operation mode, there are required a series of inputs for the control system as shown in Table I. The required outputs for the command system are described in Table II.

TABLE I

INPUTS FOR THE CONTROL SYSTEM IN 01 Level Sensor 1 IN 02 Level Sensor 2 IN 03 Level Sensor 3 IN 04 STOP button IN 05 First level button IN 06 Second level button IN 07 Third level button IN 08 Upper end-track IN 09 Lower end-track IN 10 Cancel acoustic/optic signal IN 11 Cancel error signal

TABLE II THE REQUIRED OUTPUTS FOR THE COMMAND SYSTEM

OUT 01 Elevator UP OUT 02 Elevator DOWN OUT 03 Error acoustic/optic signal OUT 04 Elevator is going UP OUT 05 Elevator is going DOWN OUT 06 Elevator STOPPED

III. LADDER DIAGRAM

This programming language has been derived from the RLL (Relay Ladder Logic) language. It makes part of the user-friendly programming languages because it does not require writing instruction statements or building logic blocks. It is mainly based on drag-and-drop operation. The items that are placed represent various specific logic functions to each programmable logic controllers. In such a manner, the program for an industrial automation, a manipulator or for other sequential and/or repetitive operation of a system it is simply achieved and in little time.

In Fig. 3 it is presented the first step of the implementation, which is the selection of the device (the programmable logic controller) that will be used for physically implementation of the control. The hardware implementation of the control part is depicted in Fig. 4.

Fig. 3. PLC selection for Ladder Diagram implementation.

Fig. 4. PLC implementation – hardware view.

Fig. 5 shows a part of the application program. It can be noticed that some lines are colored in red. The red color means that the program is running in OFF-line mode. The major advantage of this method (developing the application program directly in the Ladder Diagram language) is that it allows for quick and easy visual debugging of all possible malfunctions of the program while this runs in simulation mode and thus protecting the real world application from programming damages.

Fig. 5. Ladder Diagram implementation.

IV. PETRI NETS

The operational description of a sequential or not automation process, or of any industrial application, it can be achieved in several ways. The approach applied depends directly on the accessible information about and from the given process. If the process can provide a large amount of information, then there are the prerequisites to develop a well-designed and well adapted control schematic that suffices the recipient demands. Surely this aspect depends on the designer skills [3].

The control implementation procedure of the automation process, either hardware or software part, is a very important task.

Initially, the complete description of a process operation was performed by a simple written text. A closer approach for the final objective is to say an engineering approach. Thus, the description of the process operation is presently achieved in form of flow charts. One flow chart type is by phase flow chart. This method is very similar to Sequential Flow Chart (SFC) language stated in IEC 61131, which is a standard for programmable logic controllers. Other flow chart types are Petri networks or mathematical description.

While the flow chart is a solution to represent the operation of an automation process throughout some independent activities, the phase flow chart is a similar graphical

representation but with the possibility to group together more activities that will form a stage of the application process.

The Petri network is an oriented graphical representation. This type of representation of the industrial processes has been developed by the German mathematician Carl Adam PETRI and it has been presented for the first time in his PhD thesis held at the Technische Universität Darmstadt - Germany [4].

The nodes of a Petri network represent the stages/states of the process. The arcs that link the nodes represent the transitions, and they model the conditions that must be met by the process in order to move from one stage to another. Such a network is exemplified in Fig. 6.

Fig. 6. Typical structure of a Petri net.

In Fig. 7 it is depicted the main structure of the application program. Each rectangle represents the set of conditions that must be met in order for the system to change its state and make a transition from one state to another (in the application given, the elevator will go from one level to another).

Fig. 7. Program structure using Petri net.

It must not be forgotten that the time, which is a key parameter for many industrial applications, is replaced here by the existing causal dependencies between the various states of the system during operation.

The description of all the possible combinations for the adjacent control signals leads to the generation of a table called the truth table [5].

The resulting function is minimized and only then it is implemented and attached to each state of the system. Finally, the program is run using a control panel like the one depicted in Fig. 8, and so the simulation of the system real operation can be observed.

Fig. 8. Control panel of the Petri net simulation.

V. CONCLUSIONS

The application program described in the paper was firstly developed using the Ladder Diagram language. Then, the same program was described using Petri nets. After performing the simulation of the application operation using Petri nets, the obtained program was also converted to Ladder Diagram. Thus, some conclusions regarding the best suited method to be applied for the freight elevator application were drawn.

Using the first method the following aspects are concluded. The total implementation time is quite short, including here all the time required by the OFF-line simulation; the effective download of the program from the programming computer into the physical device, i.e. EASY 719 DC-RC, and the running of the application required about 1-2 seconds. The changes performed into the program in order to optimize some issues that were detected only when the real operation was performed, the retesting procedure in simulation and the rebuilding, the downloading and the running of the new version of the program took about a few minutes.

It can be concluded that this first method for solving the control part of an automation application is simple and does not require a large amount of time, that is, it can take from one half a day to only a few days. Talking in percents, this difference is a major one and it mainly depends on the clarity of the process operation description and the programmer skills and experience.

The disadvantage of the method consists in that the unforeseen errors or malfunctions of the system components (position sensors, end-track sensors) must be treated separately and only then included into the application program.

Regarding the second method, the drawn conclusions are the following. The total developing time of the program is considerably much larger, one of the reasons being that the environments used for Petri nets implementation are not so

user-friendly. In fact, when compared to the first method, here the expertise of the programmer plays a key role, while for the Ladder Diagram the programmer is not required to have environment usage skills. The time required to convert the Petri net into the Ladder Diagram is short. The possible changes of the Petri net can lead to serious malfunctions of the entire net so an important amount of time must be spent to reanalyze the net operation and so the new command implementation requires a lot of time.

The main advantage of Petri nets is that although they are less user-friendly, it allows for a complete and exact description of the entire process, so that the designers knows each time what is the current state of the entire system [6], [7]. For example, when the cabin is at a specific level and it is required by pressing a push button for the elevator to move to another level, the first method takes into account only the state of all the sensors while the second, additionally takes into account all the possible combinations of all the input signals (buttons and sensors).

Hence, after the tests and analyses performed it can be stated that the first method is well suited for simpler automation processes where the behavior is known and predictable, while for complex systems (this was not the case of the considered application) the Petri nets have the advantage of providing an increased safety because it takes into account all possible events and routes.

Ultimately, an educational platform has been manufactured.

ACKNOWLEDGMENT

The work has been supported by Eaton Electric which delivered the necessary software packages EASY-Soft, PLC devices (EASY 719 DC-RC and EASY 400-POW) and technical support as well. Also it has been co-funded by the Sectoral Operational Program Human Resources Development 2007-2013 of the Romanian Ministry of Labour, Family and Social Protection through the Financial Agreement POSDRU/107/1.5/S/76903 and POSDRU/89/1.5/S/62557.

REFERENCES [1] I. Margineanu, Automate Programabile, Editura Albastra, 2005. [2] M.A. Drighiciu, Gh. Manolea, “Aspecte ale modelarii sistemelor cu

evenimente discrete cu Retele Petri hibride,” Simpozion Stiintific International Universitaria ROPET 2001, Petrosani, 18-19 octombrie 2001.

[3] R. David, H. Alla, Discrete, continuous and hybrid Petri Nets, Springer, 2005.

[4] C.A. Petri, Communication with automata, DTIC Research Report AD0630125, 1966.

[5] V. Năvrăpescu, M. Popescu, I.–D. Deaconu and A.–I. Chirilă, “Designing the Control of an Electrical Drive using Petri Nets,” The 7TH International Symposium On Advanced Topics in Electrical Engineering (ATEE 2011), Bucureşti, România, Ed. Politehnica Press, IEEE Catalog Number CFP1114P-CDR, ISSN 2068-7966, pg. 441-444, Paper P1-15, May 12-14, 2011.

[6] M.A. Drighiciu, Tehnici de analiză a acţionărilor electromecanice cu reţele Petri, Editura Universitaria Craiova, 2004.

[7] M.A. Drighiciu, Gh. Manolea, “Tehnici utilizate in modelarea sistemelor flexibile de fabricatie,” A Doua Conferinta Internationala de Sisteme Electromecanice, SIELMEC 99, Chisinau, 8-9 octombrie 1999.