OO Model based programming of PLCs - CiteSeerX

14 downloads 618 Views 264KB Size Report
OO Model based programming of PLCs. Albert Zündorf, Leif Geiger, Jörg Siedhof. University of Kassel, Software Engineering Research Group,. Department of ...
OO Model based programming of PLCs Albert Z¨undorf, Leif Geiger, J¨org Siedhof University of Kassel, Software Engineering Research Group, Department of Computer Science and Electrical Engineering, Wilhelmsh¨oher Allee 73, 34121 Kassel, Germany {leif.geiger, albert.zuendorf}@uni-kassel.de http://www.se.eecs.uni-kassel.de/se/

1

Motivation

In usual software engineering approaches, object oriented modeling with the UML is meanwhile state of the art. In this area, object orientation has been extremely beneficial: object oriented modeling allows to structure the application data in a way that eases maintenance and that allows to distribute the responsibility for certain functionality among the participating objects or components. Finally, object oriented techniques enable the use of modern design pattern that further improve flexibility and maintainability. In the area of embedded systems, languages like VHDL are used to describe hardware circuits, directly. C is used to program micro controllers. Programable logic controllers are programmed in some kind of assembler, using function block diagrams or Pascal like structured text. Object oriented concepts are widely considered as inefficient and unsafe. Object oriented concepts usually imply some kind of pointer concept and dynamic organization of heap memory. Pointers may be null or point to already freed memory cells. The heap consumption may grow uncontrollably. Since space restrictions and safety issues are of major concern in the area of embedded systems, this area does not yet widely use object oriented concepts. This has the drawback that the tremendous benefits of object oriented concepts such as flexibility in modelling, improved maintenance, larger manageable system complexity and the usage of design pattern technology are not available for the area of embedded systems. We believe that in order to mature beyond the technology of the 80s and to catch up to the state-of-the-art in software development, embedded systems have to adapt object oriented concepts, too. To prepare the ground for object oriented concepts in the area of embedded systems, this position paper exemplifies the use of object oriented modeling for the control software of a simple carousel storage system. It showns the systematic derivation from the modeled

components to an implementation on the basis of a programmable logic controller using structured text as programming language.

2

Example

To illustrate our ideas this paper uses the same LEGO model of a carousel storage as [GSZ04]. However, while [GSZ04] uses a micro controller programmed in Java, here we control the storage system with a PLC device, cf. Figure 1.

Figure 1: A simple LEGO model of a carousel storage

3

Object oriented model

In order to develop the control software for this LEGO model, we first developed an object oriented model for the components employed to control the storage, cf. Figure 2.

Figure 2: UML Object Diagram modeling some carousel components

We have modeled the lifter, its sensors, and its motor as distinct objects. In addition, the plc object represents the control of the PLC together with arrays of input and output pins. Each sensor knows the number of its corresponding input pin. Similarly, the motor object knows the pins letting the motor turn forward or backward. Figure 3 shows the corresponding class diagram. Note, our design employs the well known observer design pattern at two places. First, the lifter subscribes at its sensors which inform the lifter when sensor values have changed. Second, the sensors subscribe at the PLC in order to be informed when new sensor pin values have been read. Figure 4 shows a statechart modeling the main loop of the PLC. The PLC first initializes its components and then it sends a evaluate commands to all subscribed sensors. This step is iterated infinitely.

Figure 3: UML class diagram for the lifter components

Figure 4: Statechart for the main PLC loop

As an example, for the evaluate method of a sensor, Figure 5 shows the method diagram modeling the behavior of a push sensor. On each call, the new sensor value is read from the input pins of the PLC. This is compared with the value from the previous call. If the value has changed, all listeners are informed.

Figure 5: Method diagram for a push sensor

4

Implementation in PLC structured text

Our model employs various objects, links between objects, inheritance and method overriding, and the observer design pattern. This now has to be implemented in a PLC structured text, supporting a simple imperative paradigm only. In this section, we will outline how this may be done. PLCs support different implementation languages. One of it is the so-called structured text which is close to a primitive Pascal dialect. Note, structured text is semantically equivalent to AWL (an assembler like dialect) and to function block diagrams (close to electronic circuit diagrams). We used a PLC programming environment that was able to show the same program in each of these notations. The following rules state, how different object-oriented concepts can be translated into structured text: Classes and Extensions: For each class we created a structured text struct declaring the fields of that class. In addition we declared a global array providing the storage for all instances of this class. We introduced a constant (labelled maxNoOf followed by the class name), limiting the maximal number of instances for that class. This constant is used to dimension the array of instances. Note, since our example employs only objects that represent physical components like sensors or motors and since we do not add such components at runtime, it is easy to provide these constants in this example. Pointers: Pointers are just index numbers referring to a certain element of the array of instances of the type of the pointer. To-many associations: If an object potentially has multiple neighbors, as e.g. a sensor may

have multiple listeners, we implement the corresponding struct field as an array of pointers, i.e. as an array of int. This again requires an array boundary. For simplicity reasons we use again the maxNoOfXY constant. Thus, in structured text a PushSensor type looks like: TYPE PushSensor : STRUCT pushed : BOOL; name : STRING; sensor : INT; END_STRUCT END_TYPE

# start of class declaration # attribute # pointer (to super class object) # end of class declaration

VAR_GLOBAL CONSTANT maxNoOfPushSensors: INT := 4; # max no. of objects noOfPushSensors: INT := 0; # no. of current objects END_VAR VAR_GLOBAL pushSensors: ARRAY [1..maxNoOfPushSensors] OF PushSensor; # to-n association noOfPushSensors: INT := 0; # no. of elements in assoc END_VAR Methods: Structured text provides functions with parameters. Unfortunately, methods must not be reentrant. This restriction has to be handled already in the OO model. Obviously, methods are mapped on functions employing an additional first this parameter. To avoid name clashes, each method name is prefixed with its class name: FUNCTION PushSensorIsPushed : BOOL VAR_INPUT this : INT; END_VAR IF 1 = 0 THEN RotSensorEvaluate(subObj); END_IF; END_IF; END_FUNCTION The sensor object is asked whether it has a PushSensor complement or a RotationSensor complement. Then, the appropriate method is called on the complement object. Note, the techniques we use to implement the object oriented concepts in imperative structured text are pretty common compiler techniques used for the translation of usual object oriented languages.

5

Summary

This paper shows an example how object oriented models may be implemented even on a PLC device. This enables us to exploit the tremendous advantages of object oriented concepts even in the field of embedded systems. Safety concerns are addressed by limiting the maximal number of objects per type and by wrapping each use of a pointer within a null pointer check. These advantages are paid by additional memory and runtime consumption. However, we claim that the development process is shortened and that time-to-market and maintenance efforts are significantly improved. Finally one gains the flexibility provided e.g. by the use of design patterns. The structured text example of this paper have been derived manually from our OO model, as a feasibility study. The code has been employed on a PLC controlling our LEGO carousel storage, successfully. The automatic generation of structured text from an OO model through our CASE tool Fujaba is current work at University of Paderborn, cf [EGSW04].

References [DGMZ02]

I. Diethelm, L. Geiger, T. Maier, A. Z¨undorf: Turning Collaboration Diagram Strips into Storycharts; Workshop on Scenarios and state machines: models, algorithms, and tools; ICSE 2002, Orlando, Florida, USA, 2002.

[DGZ02]

I. Diethelm, L. Geiger, A. Z¨undorf: UML im Unterricht: Systematische objektorientierte Probleml¨osung mit Hilfe von Szenarien am Beispiel der T¨urme von Hanoi; in Forschungsbeitr¨age zur ”Didaktik der Informatik“ - Theorie, Praxis und Evaluation; GI-Lecture Notes, pp. 33-42 (2002)

[EGSW04]

R. Eckes, J. Gausemeier, W. Sch¨afer, and R. Wagner: An Engineer’s Workstation to support Integrated Development of Flexible Production Control Systems; in Integration of Software Specification Techniques for Applications in Engineering (H. Ehrig, W. Damm, J. Desel, M. Große-Rhode, W. Reif, E. Schnieder, and E. Westk¨amper, eds.), vol. 3147 of Lecture Notes in Computer Science (LNCS), Springer Verlag, September 2004. (to appear).

[Fu02]

Fujaba Homepage, Universit¨at Paderborn, http://www.fujaba.de/.

[GSZ04]

L. Geiger, J. Siedhof, A. Z¨undorf: µFUP: A Software Development Process for Embedded Systems; submitted to Dagstuhl Seminar MBEES, 2004

[KNNZ00]

H. K¨ohler, U. Nickel, J. Niere, A. Z¨undorf: Integrating UML Diagrams for Production Control Systems; in Proc. of ICSE 2000 - The 22nd International Conference on Software Engineering, June 4-11th, Limerick, Ireland, acm press, pp. 241-251 (2000)

[Z¨u01]

A. Z¨undorf: Rigorous Object Oriented Software Development, Habilitation Thesis, University of Paderborn, 2001.