PLC-Statecharts: An Approach to Integrate UML-Statecharts in Open-Loop Control Engineering

Daniel Witsch, Maria Ricken, Benjamin Kormann, Birgit Vogel-Heuser, Member IEEE

Technische Universität München Chair of Information Technology in Mechanical Engineering

Boltzmannstraße 15, 85748 Garching {witsch, ricken, kormann, vogel-heuser}@itm.tum.de

Abstract-This paper defines an adaptation of UML-statecharts which can be used as a visual programming language for PLCs. Those PLC-statecharts combine the advantages of UML-statecharts with a strict formal basis and dedicated features for PLC-programming. Finally an empirical study on PLC-statecharts is briefly presented.

I. INTRODUCTION AND MOTIVATION

This work constitutes one aspect of a larger work which aims to integrate a subset of the diagrams defined in the Unified Modeling Language (UML) [1] and IEC 61131-3 [2] in order to facilitate software-engineering for PLCs [3]. Our surrounding works [3] deal with the bidirectional mapping of UML-classdiagrams and the IEC 61131-3, 3rd edition [4] which is likely to come with object oriented extensions. Further UML-activity diagrams, which impose a petri-net like semantic in UML [1, p. 324] are part of the larger works and stand next to PLC-statecharts described in this paper.

As we also implement a petri-net like behavior with activity diagrams we constrain our consideration regarding existing approaches in this paper to state machines and do not look at petri-nets like [5].

Many different variants of automata models exist. Beginning with early works of Harel et. al [6] a huge set of different automata variants were defined for specific applications. Approaches which were dedicated for the use in the context of polling real-time systems such as PLCs are not so common. Von der Beeck [7] formally specifies a semantic for UML-Statecharts but not dedicated for PLCs.

Dierks developed PLC-Automata on a formal basis [8]. This approach enables the further use of formal methods such as model-checking [9] in order to verify the correctness of the modeled and by this programmed controller. As stated by [10] neither PLC-Automata defined in [8] nor time triggered automata as defined in [11] nor I/O-automata [12] are designed to deal with hierarchical state models like defined in UML. Finite State Time Machines introduced by [10] focus on a time based control programming which implies a general change of programming paradigm.

A. Problem Statement To our best knowledge, there is no approach in which

UML-statecharts are formally specified regarding their

structural and behavioral semantics in the context of the cyclic execution of PLCs and IEC 61131-3. As PLCs are necessarily highly deterministic systems, programming languages for PLCs also have to be deterministic in a way that no ambiguity can occur about the execution of a specified PLC-statechart. Therefore PLC-statecharts introduce additional concepts compared to UML-statecharts like user-defined priorities on transitions. A main difference between UML-statecharts and PLC-statecharts lies in the fact, that PLCs according to IEC 61131-3 do not support event mechanisms (like IEC 61499 [13]). Therefore PLC-statecharts are also not based on event logic but on signal logic. As a consequence no event-queues can be defined and the PLC-statechart is exposed to cyclic calls. In this context it is necessary to define very clearly how the PLC-statechart influences the cyclic execution and at which instances actions initiated by the PLC-statechart effect the output-signals to the real-world. As a contribution this paper adapts UML-statecharts for programming polling real-time systems (such as PLCs) by giving a formal definition of the behavioral semantics of the modeling elements defined by UML. By this the application of PLC-statecharts can easily support code-synthesis, but also formal methods like model-checking.

B. Structure of the paper The following section sets the formal basis of PLC-

statecharts. Starting from a classical formal definition of PLC-statecharts we relate the elements imposing the behavior (transitions) to the cyclic behavior of the PLC by using synchronized timed automata. Using this definition how transitions influence the behavior of the PLC, we specify the behavioral semantics of states (with their entry-, do-, exit-actions) and transitions in PLC-statecharts. The next section introduces a small set of arithmetical operations (sum, product, insert) on transitions. In section 0 these operations and the formal basis defined in section III are applied to specify the semantics of extended language elements of PLC-statecharts. Section V briefly summarizes our evaluation approach for PLC-statecharts. As we are interested in the benefit of the new class of statecharts from an users point of view, we conducted empirical studies. This section presents the experimental setup and gives first results. This paper is concluded by a short summary and outlook.

978-1-4244-7300-7/10/$26.00 ©2010 IEEE 915

II. FORMAL SPECIFICATION OF PLC-STATECHARTS

A PLC-statechart is a 6 tuple , , , , , , where

• , … , is a nonempty, finite set of states , with - a time information and - execution within a PLC-cycle (true, false) • , , , is a nonempty, finite set of transitions

with - conditions over the set of variables - is the priority of the transition regarding its source state, - 2 actions - execution within a PLC-cycle (true, false) • is the transition function • , … , , … , , … , , 1 is a finite set of ordered orthogonal states with: , 1, … , , with , , , , , ) • is the initial state • is the final state Let be an active state and let be all outgoing

transitions of , the transition function , fires, if and only if with .

A. Towards a Behavioral Semantics for PLC-Statecharts As a strategy to specify the semantics of PLC-statecharts,

more complex language elements will be expressed by combining well defined basic elements in a way that corresponding behavior will be obtained. This approach is similar to the definition of metamodels in order to define models. The metamodel used in this approach is (as typically for metamodels) defined in a recursive way and formed by two metamodel elements based on the definition above: State and , , , . States of the metamodel are represented by circles and transitions by arcs with rounded arrows. Complex elements of the language which are supposed to be applied by the user (elements of the model) are depicted in UML-like way (rectangles with rounded corners, edges with straight arrows etc, see Fig. 4 etc.).

The behavioral semantics of the metamodel elements will be defined in the following by specifying an environmental model and the effect of the metamodel elements on it. As states are passive elements this has only to be done for the transition elements of the metamodel.

B. Definition of the Environmental Model for PLC-Statecharts

We assume that the PLC-statechart will be executed in an environment which works according to the pattern of real-time polling systems (cyclic systems). Such systems repeat these three steps

1) reading the current value of all inputs,

2) executing the program logic and by this calculating the new value of the output and

3) writing the updated values to all outputs continuously. This sequence is called PLC-cycle

subsequently. Fig. 1 shows this behavior in a timed automata formalism [14]. We use this timed automata model to define the relation between a control program and the PLC itself. Therefore the automaton in Fig. 1 has to be seen together with the partial automata given in Fig. 2 and Fig. 3. These two automata are connected by two shared synchronization variables (channels) PLC_Cycle_Finished and Execute_PLC_Program.

Fig. 1 Model of the cyclic behavior of a PLC in timed automata formalism (UPPAAL [15]). The variables PLC_Cycle_Finished, Execute_PLC_Program are defined as channels, the variable Cycle_Timer is defined as clock. All durations are defined as constants.

Some PLC applications require complex calculations to be executed within a PLC-cycle. For example, this is the case for motion control or closed loop control applications. Often such applications also impose complex case-differentiations or control-flows. Statecharts could also be used to implement such algorithms clearly and efficiently. To use statecharts for these types of applications, they have to support the explicit specification of those algorithmic parts to be executed within the PLC-cycle (i.e. without I/O communication). From another point of view the programmer has to be enabled to decide when the current PLC-cycle ends and a new one has to be initiated (i.e. when the switch between two cycles has to occur). In terms of the model given in Fig. 1 such a cycle-switch would be equivalent to leave and reenter the location Process_Control_Program. In terms of a statechart constituting a partial implementation of a PLC program (e.g. the implementation of an instantiated function block) a cycle-switch would mean to return the execution control (equivalent to the RETURN statement in structured text of IEC 61131-3) and by this continuing the execution of the calling element (e.g. an IEC 61131-3 program).

916

C. Semantics of Transitions in PLC-Statechart We introduce two types of transitions, which are defined

initially by giving the equivalent model in terms of timed automata and the environmental PLC-model. All further elements are based on these assumptions.

A transition in the PLC-statechart, which does not cause a switch of the PLC-cycle, can be defined according to the definitions above as: , , , . Such a transition exposes exactly the same behavior as the partial automaton given in Fig. 2 running together with the environmental model.

Fig. 2 Transition without causing a PLC-cycle switch.

A transition in the PLC-statechart, which leads to a switch of the PLC-cycle can be defined according to the definitions above as: , , , . Such a transition exposes exactly the same behavior as the partial automaton given in Fig. 3 running together with the environmental model.

Fig. 3 Transition causing a PLC-cycle switch.

When the transition with the label PLC_Cycle_Finished! fires, the transition between the location Process_Control_Program and write_output in Fig. 1 fires immediately. This automaton remains in the location Wait_for_return while the other automaton (Fig. 1) continues its execution until its transition with label Execute_PLC_Program! fires. In turn the automaton in Fig. 3 reaches location sy. The priority P will be defined in greater detail in the context of states.

D. Semantics of States in PLC-Statecharts A state constitutes a stable configuration of the PLC-

statechart. States can be active or inactive (which is implicitly defined within the transition function). As formally defined, states contain a time information, more precisely a timestamp (discrete time value) which represents the moment of the state’s latest activation. Additionally the PLC knows its current system-time d. The transition condition C = after(v) with is defined to be equivalent to C = ((d – u) > v).

The state’s type attribute m is used to define if the PLC-cycle switches while remaining in the state or not. Remaining in a state means that none of the conditions C of the outgoing transitions t1 to tn of the state sx can be evaluated to true. The priorities determine the order of evaluation (smallest number to highest). The first enabled transition fires. Additionally to the transitions defined by the user, each state has an implicit self-transition with a higher priority number (less prior) than

all other transitions (Fig. 4). This implicit self-transition can fire in case no other transition can fire. Firing such a transition is equivalent to remaining in the state. The semantics of normal states and InCycle states can be defined as follows: and .

Fig. 4 Semantics of normal states (left) an InCycle states (right) in PLC-statecharts.

On a presentation level states in a PLC-statechart can optionally own entry-, do- and exit-actions (see Fig. 5). Although entry- and exit actions are visually integrated into the state elements they semantically belong to the connecting transition [16, p. 333/345]. The do-action can be seen as action on the implicit self-transition (see Fig 4).

Fig. 5 UML-states with entry-, do-,exit-actions and transitions with priorities, guards and transition-actions.

The behavior of those actions especially in relation to cyclic execution of a PLC is specified by the equivalent metamodel-automaton (Fig. 6).

Fig. 6. The equivalent automaton to the UML-model in Fig. 5.

III. OPERATIONS ON TRANSITIONS

In order to give a precise and dense formal specification of the semantics of PLC-statechart elements, some essential

szsy

txz: (Cxz , k+1, A3|A11|A7, true)

txy: (Cxy, k,A3|A10|A4, true)

sx

tzz: (true, m, A8, true)tyy: (true, l, A5, false)

…|A1, true)txx: (true, k+2 , false)

917

algebraic operators will be defined subsequently. Using the subsequently defined operations extended language elements (presented in section IV) for PLC-statecharts can be derived in a formal way.

A. The Sum-Operator Let three states sx, sy, sz be connected by two transitions txy

and tyz in a way that the transition functions , and , hold.

State sx has n outgoing transitions with priorities P=1 to P=n. Transition txy has the priority 1 . State sy has m outgoing transitions each with a priority P=1 to P=m. Transition tyz has the priority 1 . The operation is not dependent on properties of state sy, therefore it is not necessary, that txy and tyz share a common state. The state sy is introduced to clarify the treatment of priorities. Application of the sum-operation results in an additional transition: with: , · , | , .

Where | stands for the direct sequential execution of the statements in the actions Axy and Ayz in written order. The logical statement means that if one of the participating transitions is marked as to be executed without a cycle switch then the resulting transition is also marked as such. The new transition leads also to a corresponding transition function , .

Adding a new transition outgoing from state sx requires

reordered priorities over all outgoing transitions from state sx. All transitions with a higher priority than the new transition resulting from the sum-operation have to be adapted regarding their priorities according to the following definition: : P |P P with P P l 1 k , is the set of all outgoing transition of sx .

B. The Product-Operator Based on the sum-operator the product of transitions can be

defined straightforward. The product is the application of the sum-operation on two disjoint sets of transitions, as defined

in the following. Let each state within the set of states Sx = {s1,…, sm} be the source of one transition of the set of transitions Txy={t1,…,tm} with m, n . And let each state of the set Sz = {sm+1,…,sn} be the target of one transition of the set Tyz=(tm+1,…tm+n) (see Fig. 8).

Then the product of the transition sets Txy and Tyz regarding

the state sy can be defined as: | t 1 , m 1 .

C. The Insert-Operator In contrast to the operations defined before the insert-

operation needs a state as argument. The state is taken as argument in a sense of an abbreviation for the set of its outgoing transitions. Fig. 9 illustrates the insert-operation.

Let two states sy, sz be connected by a transition tyz in a way that the transition function , holds. Let another state sx have n outgoing transitions each with a priority P=1 to P=n. State sy has m outgoing transitions with priorities P=1 to P=m. Transition tyz has priority 1 .

Application of the insert-operation results in an additional transition: with: , , , , , .

Inserting the new transition outgoing from State sx requires reordering of priorities over all outgoing transitions of state sx according to the following definition: | .

Fig. 7. Application of the sum-operator . The figure on the left shows theassumed states and transitions. The right side shows the transitive closure ofthe operation . The dashed transition on the right siderepresents the resulting transition.

Fig. 8. Assumptions for the product operation . The graph on the leftshows the assumed configuration before application of the product. Thegraph on the right illustrates the new transitions which will be added due tothe multiplication.

Fig. 9. Application of the insert-operator . The figure on the left shows the assumed states and transitions. The right side shows the result of theoperation . The dashed transition on the right side represents the resulting transition.

918

IV. SEMANTICS OF EXTENDED ELEMENTS OF PLC-STATECHARTS

In this section the operations defined above are applied to specify junction states, composite states and composite transitions.

A. Semantic of Junction-States in PLC-Statecharts Let the PLC-statechart M have a junction state J. And let J

have a set of Tin = {t1,…,tn} incoming and the set of Tout = {tn+1,…,tm+n} outgoing transitions. The equivalent PLC-statechart M’ with identical behavior to M but without J would be M’ = M’’\ { Tin ,Tout} with M’’ = M (Tin Tout).

B. Semantics of Composite-States in PLC-Statecharts A composite state D constitutes a frame for an

encapsulated PLC-statechart G in a surrounding PLC-statechart M. A PLC-statechart G has an initial state with an outgoing transition , 1, , .

To be activated from the surrounding PLC-statechart M there has to be a set Tin={t1,…, tn} ingoing transitions to D. Those transitions end at the border of D. As PLC-statechart G can have a final state with incoming transitions Tf = {tf1,…, tfn}. If and only if G has a final state, it also needs exactly one outgoing transition to an element in M starting at D. This transition is called completion transition , 1, , .

Fig. 10. A composite state with a set of incoming and one outgoing transitions to/from its border D. The border D contains a PLC-statechart G.

The equivalent PLC-statechart M’ with identical behavior to M but without D would be M’ = M’’ \ {Tin ,Tf, tinit ,tcomp, D} with M’’ = M (Tin tinit , Tf tcomp). The result of this operation is shown in Fig. 11. As G is defined to be a PLC-statechart it can also contain further composite states. Therefore this operation can be applied recursively.

Fig. 11. The flattened PLC-statechart given in Fig. 10.

In addition to completion transition composite states can

have arbitrary sets of outgoing transitions t1 to tn starting from D (Fig. 12) and ending in elements of M (both defined as

above). Those transitions (composite transitions) relate to each element of G (every element inside D). These transitions are useful to model transitions which apply for a whole set of elements (those in G). As a consequence every state of G is then a source of each of the transitions t1 to tn.

Fig. 12. On the left a composite state with composite transitions is shown. The equivalent statechart without composite transitions is given on the right.

To define the semantics of composite transitions the

equivalent PLC-statechart M’ with identical behavior to M but without D can be defined as M’ = M’’ \ {t1,…,tn} with M’’ = , … , , | .

V. EVALUATION OF PLC-STATECHARTS

The definitions and assumptions given in this paper correlate with a tool realization of PLC-statecharts including syntax checking and synthesis of IEC 61131-3 code in structured text (ST). The ST code is hidden for the user. The statechart can be executed directly. This tool is integrated in a common PLC-programming tool and works in combination with other IEC 61131-3 programming languages. By this we can validate that a technical implementation is easily possible. Moreover we have to show that PLC-statecharts lead to a benefit for the user. As evaluated in [17] UML can have a positive impact in terms of the functional correctness in the frame of software maintenance. Hence we designed an empirical study where subjects had to solve a typical maintenance task to a control program.

C. Empirical Study To evaluate the quality and usefulness of PLC-statecharts,

it is helpful to compare them with actually used graphical modeling notations. The most similar language, standardized in IEC 61131-3, is Sequential Function Chart (SFC) [18].

Besides many shared concepts (e.g. nodes, edges, conditions, actions) PLC-statecharts offer alternative (e.g. orthogonal states vs. simultaneous sequences in SFC) and complementary concepts like transitions without cycle-switch (as discussed in section I.B.) or composite states/transitions. In contrast to macro mechanisms which are realized in different tools for IEC 61131-3 sequential function charts (SFC), composite states/transitions offer a behavior which can be compared to hierarchical try-catch blocks from languages like C#. Effectively, composite transitions can abort the evolution inside the composite state (i.e. they have a higher priority). SFC macros are a visual aid to structure

919

complex SFCs. Outgoing transitions from the macro state do not abort the evolution inside the macro (i.e. SFC-macros do not influence the priority of transitions).

In order to compare PLC-statecharts with SFC from a user’s point of view, a controlled experiment with altogether 30 subjects (students) was accomplished. To test experiment design a pilot study with 12 subjects was conducted before.

Object of the study is the implementation of error handling routines to a given control program. This contained both, understanding the given code in detail and expanding it. The null hypothesis assumes that there is no difference between two groups (PLC-statecharts and SFC) regarding quality and needed time for solving the problem. Based on their previous knowledge and a short intelligence test the subjects were divided in two equal groups. All subjects received the same theoretical and practical training on SFC and PLC-statecharts.

The first task was to extend basic software code for a pneumatic cylinder with a simple error handling routine (timeout for one movement of the pneumatic cylinder). Within this task only basic language elements (equivalently available in PLC-statecharts and SFC) were used. In the second task subjects had to implement a consistency check on two sensor-variables. Solving this task can potentially be eased by the application of enhanced features of PLC-statecharts such as composite states. The results of the first experiment show no significant difference between the two languages concerning the quality of solution and needed time in general. However, subjects using PLC-statecharts reached better results concerning the identification of errors, setting of the status variable and the resumption to the normal process. In contrast the SFC group gets better results by handling the error and resetting the status-variable after the error was solved. Since these differences are not significant it can be assumed that PLC-statecharts and SFC are equivalently appropriate for solving the given task. The dedicated elements for error handling in PLC-statecharts (composite states/transitions) were not used in the first experiment. Hence these results are not discouraging but expected. As a side-effect the different quality-levels of the tools (PLC-statecharts ~ prototype, SFC ~ commercial) used to draw the diagrams may have had influences on the results. Most subjects were totally novices in UML and IEC 61131-3. Like discussed in [19] experts are no better than novices when unfamiliar patterns are encountered so that this aspect makes no difference to the results.

VI. SUMMARY AND OUTLOOK

This paper presented PLC-statecharts as an adaptation of UML-statechart. PLC-statecharts enable the PLC programmer to control the cyclic behavior of the program when executed on the PLC. Furthermore PLC-statecharts are fully deterministic through priorities on transitions and allow taking advantage of powerful modeling concepts such as hierarchy. PLC-statecharts were formally derived. By this their behavioral semantics was specified. These formal definitions facilitate the implementation of code-generation

algorithms and allow the application of further formal techniques such as model-checking. As mean for the formal definition an approach to a transition calculus was sketched, which might be starting point for further specification tasks (e.g. history states, complex transitions). As a first empirical evaluation of PLC-statecharts an experimental setup and some results on their application were given. As technical evaluation this approach was realized as plugin for an industrial IEC 61131-3 programming environment including full IEC 61131-3 code synthesis, syntax checking, online debugging etc. comparable with available commercial products like Mathworks Stateflow®. However, in this context PLC-statecharts can be used transparently with other IEC 61131-3 languages.

REFERENCES

[1] Object Management Group: Unified Modeling Language (OMG UML), Superstructure, V2.2, http://www.omg.org/docs/formal/09-02-02.pdf.

[2] International Electrical Commission, IEC 61131 Programmable Controllers – Part 3 : Programming Languages.

[3] B. Vogel-Heuser (ed.), Automation & Embedded Systems- Effizienzsteigerung im Engineering, Kassel: Kassel University Press, 2009.

[4] D. Witsch, B. Vogel-Heuser, “Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions”, in Proc. of ETFA 2009 - 14th IEEE International Conference on Emerging Technologies and Factory Automation, Palma de Mallorca, Spain, 21.-26.09.2009.

[5] G. Frey “Design and formal Analysis of Petri Net based Logic Control Algorithms”, Dissertation University of Kaiserslautern, Germany, 2002.

[6] D. Harel, “Statechart: A visual formalism for complex systems”, in Science of Computer Programming, vol. 8, 1987, pp. 231-274.

[7] M. von der Beeck, “A structured operational semantics for UML-statecharts”, in Software and Systems Modeling, vol. 1, no. 2, Heidelberg/Berlin: Springer, 2002, pp. 130-141.

[8] H. Dierks, Specification and verification of polling real-time systems, PHd-Thesis University of Oldenbourg, Germany.

[9] H. Dierks “Comparing Model-Checking and logical reasoning for real-time systems”, in Formal Aspects of Computing, vol. 2, issue 2, London: Springer, 2004, pp. 104-12.

[10] S. Krzysztof, “Translatable Finite State Time Machine”, in SDL 2007: Design for Dependable Systems, vol. 4745, Heidelberg/Berlin: Springer, 2007, pp. 117-132.

[11] P. Krcal, L. Mokrushin, P.S. Thiagarajan, W. Yi, “Timed vs. Time Triggered Automata, in P. Gardner, N. Yoshida (eds.) CONCUR 2004, LNCS, vol. 3170, Heidelberg: Springer 2004, pp. 340-354.

[12] D.K. Kaynar, N.A. Lynch, R. Segala, F.W. Vaandrager, “The Theory of Timed I/O Automata”, in Synthesis Lecture on Computer Science, 2006.

[13] International Electrical Commission, IEC 61499 – Function blocks for industrial-process measurement and control systems, 2000.

[14] J. Bengtsson, W. Yi, “Timed Automata: Semantics, Algorithms and Tools”, in Lecture Notes on Concurrency and Petri Nets, W. Reisig, G. Rozenberg (eds.), vol. 3098, Heidelberg/Berlin: Springer, 2004, pp. 87-124.

[15] www.uppaal.com. [16] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language

Reference Manual, 2nd ed., Boston: Addison-Wesley, 2005. [17] W. J. Dzidek, E. Arisholm, L.C. Briand, “Realisitc Empirical

Evaluation of the Costs and Benefits of UML in Software Maintenance”, IEEE Transactions on software engineering, vol. 34, no. 3, pp. 407-431, May/June 2008.

[18] D. N. Ramos-Hernandez, P. J. Flemming, J. M. Bass, “A novel object-oriented environment for distributed process control systems”, vol. 13, no. 2, Oxford: Elsevier, 2005, pp. 213-230.

[19] G. Costain, A. Srinivasan, “A Modeling Methodology for Empirically Studying User Behavior: The Case of UML Diagram Usage” Proceedings of EMMSA, 2008.

920