Internet-based development of logic controllers using Signal Interpreted Petri Nets and IEC 61131

Transcription

1 Internet-based development of logic controllers using Signal Interpreted Petri Nets and IEC Georg Frey Lehrstuhl für Automatisierungstechnik Universität Kaiserslautern Postfach 3049, Kaiserslautern, Germany and Mark Minas Lehrstuhl für Programmiersprachen Universität Erlangen-Nürnberg Martensstr. 3, Erlangen, Germany ABSTRACT In this contribution we present a graphical programming approach for Programmable Logic Controllers (PLCs) based on a special type of Petri net, the Signal Interpreted Petri Net (SIPN). We give an introduction to PLCs and the languages designed to program them. From this overview we conclude that in this application area a language is missing that is capable of the simple graphical description of sequential and concurrent behavior. SIPN are such a language. We present the SIPN approach and some corresponding analysis methods. Since programming a controller without tool-support is nearly impossible we present a tool for graphical editing, animation, and compilation of SIPN. In the development of the tool, not only the implementation of the SIPN as it is defined in theory played a role, but the projected application area and user interest was also considered. The tool was implemented using DiaGen, an innovative workbench for generating graphics editors. Due to the fact that a new method is best promoted if it is freely available and furthermore not very demanding in resources and administrative efforts, the tool was realized as a Java-Applet that can be executed from a standard web browser on virtually any PC. Keywords: Petri Net, PLC, de-centralized Engineering, Logic Control, XML, PNML. 1. INTRODUCTION Today, a lot of modern engineering methods are seldom applied in practice. The reasons for this are two-fold. On the one side there is the lack of acceptance with the user (partially due to lacking know-how). But on the other side there are also strong practical problems. The problem of acceptance can only be resolved by the successful application of new methods. Yet to do so the application has to be made easy by resolving the practical problems first. These problems are: Engineering software, using modern methods, is in most cases optimized on special tasks (for example the analysis of a controller of a special kind). Hence, the problem results that several tools have to be used in order to completely solve an engineering problem. The proprietary file formats of the different tools lead to a considerable amount of extra work spent on (error-prone) data converting. A high financial expense for the purchase of a new software contrasts with an unknown reward, because most software can not be fully tested in demo versions. The installation and the use of complex software on a PC uses resources (CPU-time, storage capacity). The installation, the maintenance, and the regular update of the software results in additional administrative and financial effort. These problems arise in all parts of the engineering cycle: planning, startup, operation. To avoid these problems webbased engineering is proposed. Figure 1 shows the generic model of web based engineering. Engineering-PC Engineering-PC Engineering-PC (Client) Service Provision Service-Provider (Server) Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 297 local data Service Request WWW central data processing Figure 1: Generic model of web based engineering. To model logic controllers we use Signal Interpreted Petri Nets (SIPNs). This approach is one of the above mentioned modern approaches with all the problems arising for them in practical application.

2 SIPNs add means for the description of I/O-behavior to the standard PN. In SIPNs the firing of a transition depends on (functions of) input signals from the environment, and the SIPN influences the environment via output signals. With this model logic controllers can be specified, simulated, analyzed [1], [2], and implemented [3]. However, to bring the method into practical applications strong tool support is needed. For the industrial realization of a controller, standard PLC programming languages according to IEC are used. Properties of the SIPN can only be guaranteed for the implemented controller if the generation of PLC code from SIPN preserves the dynamic behavior of the latter. To avoid errors the transformation should be done automatically. This contribution presents a method for automatically compiling an SIPN to Instruction List (IL). A prototypical tool for editing, visualizing, analyzing, and translating SIPNs (see Fig. 1) has been implemented using DIAGEN (Diagen Editor Generator), an environment for rapidly developing diagram editors. The tool consists of an graphics editor which allows for easily editing SIPNs. Edited SIPNs are translated by the tool into equivalent IL programs which implement the SIPNs on logic controllers. Currently, the tool allows to specify the behavior of places and transitions by associating IL code with each place and transition. These code segments are simply transferred into the generated program code without any syntax check. To allow easy access, the tool is realized as a Java applet that resides on a web server and can be started from any webbrowser. To design an algorithm, a browser is used to load the applet. after the design, the result is saved to the local disk or to storage space on the web. Then, IL code can be generated by the tool and transferred to a target platform, for example a PLC (cf. Figure 2). Client Download Save Generate Code (e.g. IL) Server Run on target platform (e.g. PLC) Figure 2: PLC programming using the web based editor. Furthermore, the tool offers an XML based interface to other programs which perform additional tests (e.g., liveness tests) on the edited SIPN. For this purpose we plan to use the emerging Petri Net Markup Language in the future The Petri Net Markup Language (PNML) is currently under definition (see [5] for the most recent information). Figure 3 shows a small Petri net and the corresponding PNML description. Other tools that can read PNML files may be used to process the SIPN designed with the presented editor. The rest of this paper is organized as follows: The next section introduces SIPNs in the context of standard PLC languages and the process of translating them into one of those languages (IL). In Section 3 the methods for analyzing of SIPN are described. Section 4 describes the SIPN Editor and the implementation using the DiaGen tool. Section 5 concludes the paper. Init Start Editor for Signal Interpreted Petri Nets <place id= p1 > <name>init</name> </place> <transition id= t1 > <name>start</name> </transition> <arc id= a1 source= p1 target= t1 > </arc> Simulator ASP Code Generator Figure 3: Application of the PNML interchange format. 2. SIPN AND PLC LANGUAGES Standard PLC Languages Since the first PLCs reached the market in the early 70 s, graphical programming methods are used to develop the control algorithms. These are Ladder Diagram (LD) and later Function Block Diagram (FBD). The implementation of LD on the very first PLC (the Modicon 084) was intended to allow an easy access for the people doing hard-wired relay-logic until then. LD, at least in its early forms, is basically the graphical representation of its hard-wired fore-father, The name ladder comes from the fact that on both sides of the drawing, there is a power rail and horizontally between those rails, like rungs on a ladder, sequences of logical element are drawn. The basic of these elements are relays (switches), depending on input-signals or internal variables, and coils (memories to store variables and set output signals). The ladder is processed in a top-down and left-right fashion. To understand the dynamic behavior of such an algorithm it has to be known that PLCs work in a cyclic manner. They read in the input signals, process the algorithm, set the output signals, and then start all over again. Figure 4 shows an example of an LD. All the rungs can be read as an IF THEN statement. The first rung of the ladder means IF (Var1 == 1 AND Var2 == 1) THEN (Var3:=1; Var4:=0). The second rung is IF (Var3 == 1 OR Var4 == 0) THEN (Var1:=1). Var1 Var3 Var4 Var2 Var3 Var1 Var4 Figure 4: Example of a PLC-program written in Ladder Diagram (LD). Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 298

3 While LD resembles relay-logic, FBD is a graphical mimicking of the wiring of simple logic gates, like AND, OR, NOT, or FLIP-FLOP. Both languages (LD as well as FBD) are still part of the IEC the current international standard for PLC programming languages [4], [6]. However, they are not well suited for the description of sequential and concurrent algorithms because they have no means for the visual description of the control-flow in a program. The IEC standard also contains a language that is intended for the graphical description of sequential and concurrent control algorithms, the Sequential Function Chart (SFC). The SFC is based on Grafcet [7] and represents a form of high level Petri net (with very special dynamics and functionality). Due to its high functionality, SFC can be easily applied for the structuring of a PLC program on a high level. However, it is cumbersome to use for the specification of a lowlevel sequential algorithm, as for example the alternative switching between two motors. Furthermore, the inherent complexity of an SFC prohibits its use in the lower, functional levels of an algorithm because the resulting programs would be to slow. 1 From the discussion above, we conclude that in the PLC area a language is missing that is capable of graphically describing sequential and concurrent algorithms, gives visual feedback of the control-flow in these algorithm (current state, following state etc.), is easy to apply, and is easy to implement i.e. results in fast code. With Signal Interpreted Petri Nets (SIPN), such a language is at hand. SIPN An SIPN is an ordinary Petri net with binary marking and the following extensions for the information flow: Every transition is associated with a Boolean function of the input signals, the firing condition. Every place is associated with an output function, that assigns a subset of output signals while it is marked. The dynamic behavior of an SIPN is given by the flow of tokens through the net, i.e., the change of its marking. This flow is realized by the firing of transitions. Firing of a transition removes a token from each of its pre-places and puts a token on each of its post-places. For the firing process there are four rules: 1. A transition is enabled if all its pre-places are marked and all its post-places are unmarked. 2. A transition fires immediately if it is enabled and its firing condition is fulfilled. 3. All transitions that can fire and are not in conflict with other transitions fire simultaneously. 4. The firing process is iterated until a stable marking is reached (i.e. until no transition can fire anymore). Iterated firing is interpreted as simultaneous. This also means that a 1 There are also two textual languages in the standard: the assembler-like Instruction List (IL) and the Pascal-like Structured Text (ST). change of input signal values can not occur during the firing process. After a new stable marking is reached, the output signals are computed by evaluating the output functions of the marked places. Example Figure 5 shows an example of a controller designed using SIPN. The controller is used to fill a tank with a liquid, heat it until a specified temperature is reached, and then empty it again. P5: Stirring ω(p5): o3 = 1 T5: Filled & Temp. OK ϕ(t5) = i2 i3 P1: Stand By ω(p1) = (0, 0, 0, 0) T1: Start Button pressed ϕ(t 1 ) = i4 i1 i2 P2: Filling ω(p2) = (1, 0, -, 0) T2:Filled & Temp. low ϕ(t2) = i2 i3 P3: Heating ω(p3) = (0, 0, -, 1) T3: Filled & Temp. OK ϕ(t3) = i3 P4: Emptying ω(p4) = (0, 1, -, 0) Figure 5: SIPN Example. T4: Tank is empty ϕ(t4) = i1 i2 i4 In the initial state only P1 is marked and hence the output of the net is (0, 0, 0, 0). If the start-button is pressed (i4 = 1) and the tank is empty (i1 = 0 and i2 = 0), then transition T1 fires. The token is removed from P1 and two tokens on P2 and P5 are generated. The new output of the net results in (1, 0, 1, 0), where o3 = 1 means stirring and o1 = 1 filling. After the filling level is reached (i2 = 1) the further processing depends on the temperature in the tank. If the temperature is already above the desired level (i3 = 1) then T5 fires, removing the token from P3 and putting a token in P4. If otherwise, the temperature is below the level (i3 = 0) then T3 fires, also removing the token from P2 but putting it in P3. There the tank is heated (o4 = 1) until the temperature is OK (i3 = 1) and T4 can fire putting the token from P3 to P4. In P4 the tank is emptied (o2 = 1). When the tank is empty, the firing of T6 finally removes the tokens from P5 and P4 and puts a token in P1, hence resulting in the initial state again. Code-Generation To use SIPN as a PLC language on a large variety of PLC hardware it is best to translate the resulting algorithm into one of the standardized PLC languages as for example Instruction List (IL). The direct implementation of an SIPN compiler would only work for one special PLC, but an IL according to the specifications of IEC61131 can be executed on nearly any PLC. For a structure-conserving conversion the token play of the SIPN has to be transferred to the PLC program. Therefore, for each place pi of the SIPN a Boolean variable Pi is defined that shows if the corresponding place is marked (Pi = true) or unmarked (Pi = false). Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 299

4 Besides the differences in the specific Petri net type considered, the presented code generation differs from other approaches (see e.g. [8], [9], [10]) in one main aspect. This is the one-toone correspondence of net elements to code segments that is used. This correspondence allows to easily reinterpret produced code. This reinterpretation is of special importance if a user wants to understand and change the implemented code, which is commonplace in industrial applications. Based on this premise the net elements can be translated to PLC code step by step: Transitions: The compilation of a transition has to test whether the transition is enabled and whether the firing condition is fulfilled. If after the processing of this calculation the accumulator is set to 1, i.e. all conditions are fulfilled, then the transition fires. If not, a conditional jump to the next transition avoids firing. The firing unmarks all pre-places and marks all post-places. To optimize the code, the firing conditions are not evaluated if a transition is not enabled. Places: If a place is marked then the corresponding output function is executed (setting or resetting of variables). If it is not marked a conditional jump to the next place label is performed and the code segment of the output function is not executed. Note, that the implementation of the output functions results in an output of zero or one (true or false) for all output variables according to the output of the SIPN. In case of an incorrect output setting in the SIPN the output of the code differs from the SIPN since undefined and contradictory output settings are not possible in the realization. For an undefined output, the PLC code remains at the last defined value for this output. For a contradictory output it depends on the ordering of the involved place code segments if the variable is set to one or to zero. Both cases should be avoided using SIPN analysis prior to code generation. 3. ANALYSIS OF SIPN Formal Correctness Formal Correctness is the main aim of SIPN analysis. In the following, criteria for formal correctness are presented. Common to all those criteria is, that they are essential for the correct functioning of an implemented controller. Since no process model is used in the determination of the criteria the derived results hold for arbitrary sequences of input signals. It is clear, that the formal correctness of the algorithm cannot guarantee that the controller does what it should do. The answer to this question can only be found by model based verification and validation (cf. [11]). To draw an analogy form everyday life, to check the correctness of an algorithm is like spellchecking a text, there again the correctness of the spelling allows no conclusions about the correct sense of the text. There are three criteria for formal correctness: Unambiguity, Liveness, and Reversibility. Unambiguity: Every control algorithm has to be defined unambiguously. This criterion can be subdivided into four subcriteria: 1. Determinism: A control algorithm has to be deterministic. If it were not, its behavior in a given situation would depend on implementation aspects. This of course could not be the aim of a correct design. 2. Termination: In a cycle of a logic control algorithm, at least one marking must be stable. A cycle without stable marking leads to an algorithm that does not terminate. This in turn could lead to a hang-up of the implemented controller or to non-deterministic behavior, in the case when the implementation breaks up the endless loop at some unknown point. 3. Defined output: If there were no specification for the value of an output signal at a reachable marking, again the behavior of the controller would depend on its implementation: In an implemented controller, there is no don t care. 4. Unambiguous output: If two places marked at the same time assign different values to an output signal, a contradictory output setting results. This is a clear design error. Liveness: When a transition or a set of transitions is no longer fireable then part of the control algorithm doesn t work anymore. In this case, there is in general an error in the design of the control algorithm. There are however special controllers that should get stuck in defined states due to safety regularities. In these cases, the liveness criterion does not apply. To do the analysis for the rest of the controller, the respective states have to be removed prior to analysis or they have to be connected to the initial state via a reset transition. Reversibility of an SIPN guarantees that the described controller reaches its initial state again. As with liveness, there are special cases where reversibility is not desired. All the criteria for formal correctness can be checked using the reachability graph of the SIPN. In [1] the criteria are shown together with an appropriate analysis method. If the algorithm is unambiguous in the presented sense then the controller will behave unambiguously to whatever process it is connected. If the algorithm is not live or reversible in this sense then the controller cannot be live or reversible regardless to what process it is connected. Transparency Where formal correctness is a pre-condition for a functioning algorithm, transparency is a measure for the quality of the design. An algorithm is said to be transparent if it is easy and clear to see what the controller does at the moment and what it will do in the next steps. A number of criteria for transparency are given in [2]. These criteria cover different aspects such as number of comments, directionality, and I/O-behavior. They are combined in a weighted sum to an automatically computable metric. An experiment with student groups showed a strong correlation between the transparency metric computed for an algorithm and the time needed by the students to answer questions on this algorithm and the correctness of these answers. 4. IMPLEMENTATION A prototypical tool for editing, visualizing, animating, analyzing, and translating SIPNs has been implemented using DiaGen (Diagram Editor Generator) 2, an environment for rapidly developing diagram editors from a formal specification of the diagram language based on hypergraph grammars and hypergraph transformation [12], [13], [14].The generated SIPN tool consists of a graphics editor that allows for easily editing SIPNs in a direct manipulation manner. As the SIPN tool has mainly been prototyped as a programming tool, created SIPNs are translated by the tool into equivalent IL programs which implement the SIPNs on logic controllers [15]. 2 DiaGen is free software and is available from Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 300

5 The code segments which specify the behavior of places and transitions are simply transferred into the generated program code without any syntax check. Generated code is transferred into conventional IL compilers which finally produce code for real PLCs. With DiaGen as a rapid prototyping tool, merely the graphical representation of diagram components, i.e., places, transitions, and arrows, and IL code generation, driven by the syntactic analysis of the diagram, had to be programmed manually; the rest of the SIPN tool has been generated from a specification which primarily describes the SIPN language syntax. Figure 6 shows a screenshot of the SIPN tool. The editing tool consists of a drawing canvas which contains the SIPN diagram and the usual control widgets. The generated editor is a direct manipulation editor, i.e., any diagram component (place, transition, arrow, or initial token) can be created and moved anywhere on the canvas by choosing the component on the toolbar and specifying its position with the mouse, or by selecting an existing component with the mouse and changing its position by means of drag handles which appear for selected components. A parser checks the syntactic correctness of the diagram [12], [13], [14] and provides visual feedback (by special coloring of the erroneous components) in the case of diagram errors. A diagram layouter adjusts arrows when places and/or transitions are moved; places, transitions, and arrows stay connected. The layouter, moreover, takes care of diagram beautification [16] as of snapping places, transitions, and arrow bends to a grid. which will be executed when this place is activated. The code fragment shown sets output o1 (S o1) and resets output o2 (R o2). So far and as defined above, SIPN diagrams are flat, i.e., each place and transition has the same visibility in the SIPN. However, for real-world programs, SIPN controllers tend to be large and difficult to handle like for most visual languages. However in most cases, certain subnets can be identified which realize certain subtasks which are active as long as one of the subnet's places is activated (i.e., has a token.) The complete SIPN can, therefore, be replaced by an abstract SIPN where single places are used instead of these subnets; the subnets are subordinated to these super -places. These subnets can in turn contain super -places and so on, hence the resulting SIPN is a hierarchical one. But hierarchy does not only enhance the readability of SIPNs. It is also a valuable means for top-down design of SIPN controllers: Instead of trying to create a single, large one, a programmer can start with an abstract SIPN which is then refined step by step. The SIPN tool allows to edit and visualize such hierarchical SIPNs. Figure 7 shows a screenshot of the tool, when programming a drilling station where a workpiece can be fixed in the drilling station, drilled, and then released. This task can be described by the SIPN on the left where fixing and drilling are parallel subtasks. Drilling is represented as a super -place, indicated by a thick, dotted borderline. Its subordinated SIPN is shown on the right (please note the window title which corresponds to the name of the higher-level Drill place): An initial and a terminal place are indicated by loose arrows: The Begin place is activated as soon as the Drill place of the higher-level SIPN on the left gets activated, and activating the End place is a requirement of the Drill place of getting deactivated. The tree view on the left of Figure 7 gives an overview of the simple hierarchy of this example. From a semantic point of view, hierarchical SIPNs are just a special visual representation of flat SIPNs. But the IL-codegenerator of the SIPN tool creates code which reflects the hierarchical structure: Instead of creating a flat IL program, each subordinated SIPN is translated into a functionblock, a kind of PLC subroutine. The IL code, therefore, remains more readable than an unstructured one. 5. CONCLUSIONS Figure 6: Editing the PLC behavior when a place is activated. A tool for editing, visualizing, animating, and translating SIPNs, was presented. The current prototype, which has been generated with DiaGen, a rapid prototyping tool for diagram editors based on hypergraph transformations, provides a tailored graphics editor for SIPNs that translates such SIPNs to equivalent IL programs implementing the SIPN behavior on a logic controller and an animator that allows the simulation of the specified algorithm. The tool moreover provides interfaces for further analyzing and accessing SIPNs, e.g. for exporting SIPNs in an XML (PNML) format. The tool can be accessed via a web-browser at (Note you need the Java2 Runtime Environment and the Java Plug-in installed) Further work will also integrate the SIPN tool with existing development tools for logic controller software in order to advertise SIPNs as a high level language for logic controllers. In the SIPN diagram of Figure 6 the place P2 is selected and its property editor is popped up. Here, the user can type in IL code Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 301

6 6. REFERENCES [1] G. Frey and L. Litz. Correctness analysis of Petri net based logic controllers. In Proc. of the American Control Conference (ACC 2000), [2] G. Frey and L. Litz. Transparency analysis of Petri net based logic controllers-a measure for software quality in automation. In Proc. of the American Control Conference (ACC 2000), [3] G. Frey. Automatic implementation of Petri net based control algorithms on PLC. In Proc. American Control Conference [4] IEC. International Standard 1131: Programmable Logic Controllers, Part 3: Languages. [5] PNML homepage at the Humboldt University Berlin [6] R. W. Lewis. Programming industrial control systems using IEC IEE Publishing, London, [7] R. David and H. Alla. Petri Nets and Grafcet - Tools for Modeling Discrete Event Systems. Prentice Hall, New York, London, [8] G. Cutts and S. Rattigan. Using Petri nets to develop programs for PLC systems. In Proc. of Application and Theory of Petri Nets 1992, LNCS 616, pages , [9] M. J. Stanton, W. F. Arnold, and A. A. Buck. Modelling and control of manufacturing systems using Petri nets. In Proc. of the 13th IFAC World Congress, pp , [10] K. Venkatesh, M. Zhou, and R. J. Caudill. Discrete event control design for manufacturing systems via ladder logicdiagrams and petri nets: A comparative study. In M. Zhou, editor, Petri Nets in Flexible and Agile Automation, pp Kluwer Academic Publish., [11] G. Frey and L. Litz. Formal methods in PLC programming. Proc. of the IEEE Conference on Systems Man and Cybernetics (SMC2000), [12] M. Minas. Diagram editing with hypergraph parser support. In Proc Symp. on Visual Languages (VL 97), pages , [13] M. Minas. Creating semantic representations of diagrams. In M. Nagl and A. Schürr, editors, Int. Workshop on Applications of Graph Transformations with Industrial Relevance (AGTIVE 99), Selected Papers, LNCS 1779, pages Springer, Mar [14] M. Minas. Concepts and realization of a diagram editor generator based on hypergraph transformation. Appears in Journal of Science of Computer Programming (SCP), [15] G. Frey and M. Minas. Editing, Visualizing, and Implementing Signal Interpreted Petri Nets. Proceedings of the AWPN 2000, pp 57-62, [16] S. S. Chok, K. Marriott, and T. Paton. Constraint-based diagram beautification. In Proc Symp. on Visual Languages (VL 99), [17] L. Litz and G. Frey: A Graduate Course on Logic Process Control based on Petri Nets Proceedings of the IEEE SMC'98, San Diego, Vol. 1, pp , Figure 7: Hierarchical SIPN for a drilling station. Proceedings of the SCI 2001, Volume 3, pp , Orlando (FL) USA, July 22-25, 2001 (ISBN ) 302