A Measure for Transparency in Net Based Control Algorithms

Transcription

1 A Measure for Transparency in Net Based Control Algorithms Georg Frey and Lothar Litz Institute of Process Automation Department of Electrical Engineering University of Kaiserslautern PO 3049, D Kaiserslautern, Germany ABSTACT In contrast to other areas of software design, in control applications the concepts of software quality following ISO/IEC 9126 standard are not very common. However, a primary goal in applying formal methods to controller design is the transparency of the resulting algorithm. A (graphically described) algorithm is said to be transparent if it is easy and clear to see what the controller does in the moment and what it will do in the next steps. In this contribution the relation of this transparency concept to software quality is shown. Yet, the definition of transparency is vague and depends mainly on the subjective opinion on what easy and clear to see means. There are several aspects of a control algorithm that can be compared on an objective basis. In this paper the ability of different graphical controller design methods finite automata, Switching Interpreted Petri Nets (SIPN) and Sequential Function Chart (SFC) according to IEC1131 standard to describe an algorithm in a transparent way is compared. Furthermore, a number of criteria for transparency are given. 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. The results of the presented method are twofold: First a set of rules for transparent controller design in the framework of SIPN and SFC is derived and secondly a metric which allows the comparison of the transparency of different control algorithms (realizing the same task of course) is achieved. The first result is interesting for the industrial application of the graphical design methods whereas the second result can be used for educational purposes and for optimization. 1 INTODUCTION In general, the realization of a logic controller includes hard- and software. With the assumption of standard hardware with well-defined functionality, the realization is the program of the control algorithm i.e. software. Hence the quality of the controller depends mainly on the software quality. Quality is defined in ISO 8402 standard [1] as: The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs. According to ANSI/IEEE 610 standard [2] application software is defined as: Software designed to fulfill specific needs of a user; for example, software for navigation, payroll, or process control. Contrast with: support software, system software. Hence software for process control is application software. For application software, The ISO/IEC 9126 [3] standard defines software quality characteristics as: A set of attributes of software product by which its quality is described and evaluated. A software quality characteristic may be refined into multiple levels of subcharacteristics. The paper aims to relate the concepts of software quality, as presented in Chapter 2, to the concept of transparency described in Chapter 3. In Chapter 4 three graphical controller programming languages are described: finite automata, Switching Interpreted Petri Nets and Sequential Function Charts. The criteria for transparency are presented and exemplified at the three different languages in Chapter 5. The contribution closes with a summary and an outlook on further work. Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp

2 2 SOFTWAE QUALITY ISO/IEC 9126 defines six main characteristics of software that can be used as criteria for quality (cf. Table 1). Table 1 Software Characteristics of ISO/IEC 9126 Software Characteristic Functionality eliability Usability Efficiency Maintainability Portability Explanation existence of a set of functions and their specified properties. The functions are those that satisfy a stated or implied need. A set of attributes, that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. effort needed for use, and on the individual evaluation of such use, by stated or implied set of users. relationship between the level of the performance of the software and the amount of resources used, under stated conditions effort needed to make specified modifications ability of software to be transformed from one environment to another. The field of metrics to measure these software characteristics is maturing, see e.g. [4] for an overview. However, to our best knowledge, metrics are only defined for textual programming languages. Some of the best known metrics date back to the late 70s [5], [6]. Experience with those metrics in the area of controller programming is not published. In the following table the six characteristics are set in the framework of controller design. Table 2 Software Characteristics applied to Controllers Software Characteristic Functionality eliability Usability Efficiency Maintainability Portability elevance / Criterion Very important / Correctness of the control algorithm Very important / Correctness and robustness of the control algorithm Important / Facility of Graphical User Interface (GUI) and transparency of the algorithm Not important for unique applications (e.g. chemical plant) Very important for applications with multiple realizations (e.g. washing machine controller) Very important for applications with unique realizations / Transparency Main goal of IEC 1131 to enable the use of the same software on different PLC hardware / Transparency As indicated in Table 2 some of the criteria rely on the correctness of the algorithm. There are many defined correctness criteria and algorithms to prove them, see e.g. [7] and [8] for SIPN. Transparency is a means to achieve maintainability, usability and portability. It also helps to achieve functionality and reliability during the design process. 3 TANSPAENCY In contrast to known software quality metrics the concept of transparency originates from the area of controller design. Primary goals in applying formal methods to controller design are the correctness and the transparency of the resulting algorithm. Correctness and transparency are independent properties. An algorithm can be correct or not; and it can be more or less transparent Transparency of an algorithm is defined as follows [9]: At any time it must be easy and clear to see what the controller does in the moment and what it will do in the next step. Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp

3 At any time there must be the possibility to reinterpret the algorithm. This means the aim of the control algorithm must be recognizable. The main motivation for transparency are increasing costs for software maintenance. To assure a good maintainability the software should have good analyzability if failures occur, E = (e 1, e 2, e 3, e 4 ) A = (a 1, a 2, a 3, a 4 ) Z 1 /A 1 E 5 E 1 E 4 Z 2 /A 2 E 2 E 1 = (0, -, -, -) A 1 = (0, 0, 0, 0) E 2 = (-, 1, -, -) A 2 = (1, 0, 1, 0) E 3 = (-, -, 1, -) A 3 = (0, 0, 1, 1) E 4 = (-, -, -, 1) A 4 = (0, 1, 1, 0) E 5 = (-, 1, 1, -) E 1 /A 1 Z 1 E 4 /A 2 E 5 /A 4 Z 2 E 2 /A 3 easy changeability to remove detected design faults or to modify the software, Z 4 /A 4 Z 3 /A 3 E 3 Z 4 Z E 3 3 /A 4 high stability, i.e. low risk of unexpected effects due to changes, good testability to proof the success of changes with lowest expense. 4 GAPHICAL CONTOLLE DESIGN In the following, a short description of three graphical controller design methods is given: Finite automata, Switching Interpreted Petri Nets (SIPN) [10] and Sequential Function Chart (SFC) according to IEC 1131 standard [11], [12]. The methods are illustrated using the control algorithm for a heating tank [13]: After pressing the start button (e 4 = 1) the empty tank (e 1 = 0) tank is filled by opening Valve 1 (a 1 = 1). The filled tank (e 2 = 1) is heated (a 4 = 1) until the temperature sensor signals that the temperature limit is reached (e 3 = 1). The heated tank is emptied until under the minimal level (e 1 = 0) by opening Valve 2 (a 2 = 1). During the whole process the contents are stirred (a 3 = 1). Fig. 1 Moore and Mealy automaton SIPN Switching Interpreted Petri Nets (For example Netmate [14]) Interpreted Petri Nets (IPN) [15], [16] are an extension of the basic Petri Net framework. IPNs have additional components for the modeling of information flow to and from the PN. For the formal specification of control algorithms a specialized type of IPN is used, the Switching IPN (SIPN) [7], [8]. An SIPN is a condition/event net with the following extensions for the information flow: Every transition is associated with a Boolean function of the input signals, the firing condition. A transition is fired when it is enabled by the marking and the firing condition is fulfilled. Every place is associated with an action, that assigns a subset of output signals while it is marked. P 1 P 1 : Stand By A(P 1 ) = (0, 0, 0, 0) T 1: Start Button pressed C(T 1 ) = e 4 e 1 e 2 Note that the solutions given by Figures one to four meet this informal specification but they are not completely equivalent regarding their input output relation. P 5 P 5 : Stirring A(P 5 ) = (-, -, 1, -) P 2 P 2 : Filling A(P 2 ) = (1, 0, -, 0) T 2 :Filled & Temp. low C(T 2 ) = e 2 e 3 Finite Automata (For example Siemens s HiGraph tool) Basically there is a distinction between Moore and Mealy automaton. In the definition of automata according to Moore (cf. Fig. 1 left) the output function depends on the state of the automaton whereas according to Mealy (cf. Fig. 1 right) it depends on the state transition. In Fig. 1 both types of automata describing the heating tank controller are shown. T 5 : Filled & Temp. OK C(T 5 ) = e 2 e 3 P 4 P 3 P 3: Heating A(P 3) = (0, 0, -, 1) P 4 : Emptying A(P 4) = (0, 1, -, 0) T 4 : Tank is empty C(T 4) = e 1 e 4 Fig. 2 SIPN-Model of heating tank T 3 : Temperature OK C(T 3 ) = e 3 Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp

4 SFC Sequential Function Chart (several commercial controller design tools) With the elements of SFC a Program-Organization-Unit of a PLC program is arranged into a set of steps and transitions. These are linked through directed connectors. Associated to every step is a set of actions and a condition is attached to every transition (IEC ) [11]. In a step the behavior of a SFC follows a set of rules, that are defined by the actions that are attached to the step. A step is either active or inactive. At any time the state of the POU is given (defined) by the set of activated steps and the values of the internal variables and the output variables. Several actions could be attached to one step. A step without any actions has a waiting function. This means the step waits, until a following transition is fulfilled. An action may be defined as: a Boolean variable, a sequence of instructions in Instruction List (IL), a sequence of instructions in Structured Text (ST), a collection of current paths in Ladder Diagram (LD), a collection of frameworks in Function Block Diagram (FBD) or another SFC. A transition declares the condition that passes control from one or several steps above the transition to one or more following steps along the referring directional connection. According to IEC the conditions may be given in four different controller languages: Structured Text (ST), Ladder Diagram (LD), FBD-framework, or Instruction List (IL). The initial step is the step which is active at the beginning of the program (Note that IEC allows only one initial step in an SFC). A transition is enabled if all its pre-steps are active and its associated firing condition is fulfilled. The firing of a transition deactivates its presteps and activates its post-steps. Fig. 3 shows the heating tank controller in SFClanguage. It is easy to see that an SFC can be built up in the same way as an SIPN if only a subset of SFClanguage is used (cf. [17]). Σ 1 S N a 5 3 ε 4 Ù Øe Ù Øe e 2 Ù e 3 ε 1 Ù Øe Σ 2 Σ 3 a 1 a 2 a 3 a 4 ε 3 N e 2 Ù Øe 3 N a 1 a 4 S N a 4 2 Fig. 3 SFC-model of heating tank 5 CITEIA FO TANSPAENCY Transparency is based on two main effects: transparent representation of information flow [18] to and from the controller and transparent representation of the control flow inside the algorithm. Concurrency is a common element in most control algorithms. However, automata offer no means for the transparent description of the control flow if concurrency is present. Hence, A transparent control algorithm using automata can only be achieved if the algorithm is purely sequential. In this case, the Moore-automaton is more transparent. Because for the decision process of a human observer it is easier to realize which output is given by the automata if the outputs are attached to states than to the paths that are leading to the actual state. It is only one step to recognize the presently activated state and its output but two steps to recognize the actual state and then the path leading from the preceding state to the actual, to see what output is given by the automata. If the algorithm has concurrent elements, SIPN and SFC can be used for a transparent description. Since this is the common case, the criteria for transparency are defined for these languages. In Table 1 some criteria for transparency in SIPN and SFC algorithms are given. The list is not exhaustive and may be adapted to the special needs of the project under consideration. The criteria are normalized to one (one is high transparency, zero is no transparency at all). The overall transparency value is calculated as a weighted sum of the single criteria. Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp

5 Criterion Explanation Measure Comments No trivial input No trivial output No redundant output There should be a comment at every place/step and at every transition A defined input signal that does not influence the controller An output signal that is set to the same value all the time. If several activated places set an output signal to the same value then there is redundant information. Number of Comments t 1 = Total number of Places and Transitions t = 1 2 Number of trivial Input - Signals Total number of Input - Signals Number of trivial Output - Signals t3 = 1 Total number of Output - Signals t 4= 1 Number of redundant Output Settings Total number of Output Settings Safety If the net is safe, the post-places of a transition need not to be checked to determine if the transition fires. t 5 1 = 0 if net is safe if net is not safe Directionality No weak Dynamic Synchronization (wds, see [7] or [8]) No internal variables (for SFC) No indirect Output (for SFC) The control flow should follow one preferred direction. The preferred direction is that one the most arrows show. wds leads to transient states under specific combinations of input signals and to hidden synchronization (see [7] or [8] for an deeper discussion of this effect). This introduces shortcuts (additional arcs) in the reachability graph (G) of the SIPN that are not part of the underlying PN s G. The use of internal variables can lead to dependencies in the control flow that are additional to the graphical flow. An output that is set to a constant value is called direct (e.g. a 2 = 1). With indirect outputs (e.g. a 1 = e 1 e 3 ) the state information is not sufficient to determine the output. t Number of arcs in preferred direction = 2 Total number of arcs 6 t7 = 1 Number of arcs due to wds in G Total number of arcs in G Number of internal variables t8 = 1 Total number variables t9 = 1 Number of indirect Output Settings Total number of Output Settings 1 Table 3 Criteria for transparency In the following the result of applying the measure is illustrated with an example: The SIPN in Fig. 2 and in Fig. 4 (following page) describe the same algorithm and they are both formally correct. However, the net in Fig. 2 has a transparency value of T = whereas the net in Fig. 4 reaches only T = 0.576: Transparency of the net in Fig. 2: t 1 = 1; comments everywhere t 2 = 1; no trivial input signal. t 3 = 1; no trivial output signal. t 4 = 1; no redundant output t 5 = 1; the net is safe. t 6 = 2 * 11/12 1 = 0.833; eleven of twelve arcs. t 7 = 1; no weak Dynamic Synchronization. T = (Σ w i t i ) / (Σ w i ) = 0.976; with w i = 1 i Transparency of the net in Fig. 4: t 1 = 0; no comments at all t 2 = 1 1/5 = 0.80; e 5 is a trivial input signal. t 3 = 1 1/5 = 0.80; a 5 is a trivial output signal. Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp

6 t 4 = 1-3/22 = 0.864; a 3 is redundant at M=(0,1,0,0,1), M=(0,0,1,0,1), M=(0,0,0,1,1) t 5 = 1; The net is safe. t 6 = 2 * 5/10 1 = 0; five of ten arcs t 7 = 1 4/8 = 0.5 T = (Σ w i t i ) / (Σ w i ) = 0.566; with w i = 1 i P 5 P 5 A(P 5) = (-, -, 1, -, 0) P 2 P 3 A(P 3) = (0, 0, 1, 1, 0) P3 T 4 C(T 4) = e 1 e 4 P 1 P 1 A(P 1) = (0, 0, 0, 0, 0) T 1 C(T 1) = e 4 P 4 A(P 4) = (0, 1, 1, 0, 0) P4 P 2 A(P 2) = (1, 0, 1, 0, 0) T 3 C(T 3) = e 3 T 2 C(T 2) = e 2 e 5 e 5 Fig. 4 Intransparent SIPN for the heating tank. 6 CONCLUSION AND OUTLOOK It is shown that the concept of transparency is an important means to achieve software quality in the area of logic control design. Transparency could be sub-divided in several measurable criteria. One advantage of the presented approach is that these criteria can be computed by algorithms. The implementation of the algorithms into a control design tool and the evaluation at examples of practical dimensions is a current research task. It is expected that during this evaluation further criteria will be added to the list. 7 EFEENCES [1] International Standard 8402 Quality Management and Quality Assurance-Vocabulary, ISO, [2] ANSI/IEEE Standard , IEEE Glossary of Software Engineering Terminology, The Institute of Electrical and Electronic Engineers Inc, [3] International Standard 9126, Information Technology - Software Evaluation. Quality Characteristics and Guidelines for their Use, ISO, December [4] P. Jalote, An Integrated Approach to Software Engineering, 2 nd Ed., Springer Verlag, New York, [5] M. H. Halstead, Elements of Software Science. Elsevier: North Holland Publishing Co., 1977 [6] T. McCabe, A Complexity Measure, IEEE Transactions of Software Engineering, SE2 (1976), Nr.4, pp [7] G. Frey and H.-G. Schettler, Algebraic Analysis of Petri Net based Control Algorithms, Proceedings of the IEEE 4th Workshop on Discrete Event Systems WODES 98, 1998, pp [8] G. Frey, Analysis of Petri-Net based Control Algorithms, appears in Proceedings of the SDPS Forth World Conference on Integrated Design and Process Technologies, [9] L. Litz, Entwurf industrieller Prozeßsteuerungen auf der Basis geeigneter Petri-Netz-Interpretationen, Schnieder (Ed): Entwurf komplexer Automatisierungssysteme, Brunswick, 1995, pp [10] G. Frey and L. Litz, Verification and Validation of Control Algorithms by Coupling of Interpreted Petri Nets, Proceedings of the IEEE SMC'98, San Diego, 1998, Volume 1, pp [11] International Electrotechnical Commission (IEC), International Standard 1131 A: Programmable Logic Controllers, Part 3: Languages, [12]. W. Lewis, Programming industrial control systems using IEC IEE Publishing, London, United Kingdom [13] G. Frey and L. Litz, Entwurf und formale Verifikation von Steuerungen mit interpretierten Petri- Netzen, Proceedings of the GMA-Kongreß 98, VDI- Verlag, Düsseldorf, 1998, pp [14] Institute for Process Automation (G. Frey), Control Design Tool Netmate, [15]. David and H. Alla, Petri Nets and Grafcet - Tools for Modelling Discrete Event Systems, Prentice Hall, New York, London, [16]. König and L. Quäck, Petri-Netze in der Steuerungs- und Digitaltechnik, Oldenbourg Verlag, München, Wien., [17] G. Frey and L. Litz, Transparenter Steuerungsentwurf mit SFC nach IEC Proceedings SPS/IPC/DIVES'97 Nuremberg, Hüthig Verlag, 1997, pp [18] C. Jörns, Transparent epresentation of Information Flow in Automatic Control Systems for Verification Purposes, Proceedings of IEE WODES 96, London: IEE 1996, pp Proceedings of the IEEE SMC 99 Tokyo (J), October 12-15, 1999, Vol. III pp