OO Model based programming of PLCs

Transcription

1 OO Model based programming of PLCs Albert Zündorf, Leif Geiger, Jörg Siedhof University of Kassel, Software Engineering Research Group, Department of Computer Science and Electrical Engineering, Wilhelmshöher Allee 73, Kassel, Germany {leif.geiger, 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

2 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.

3 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.

4 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.

5 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

6 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 <= this AND this <= noofpushsensors THEN PushSensorIsPushed := pushsensors[this].pushed; ELSE PushSensorIsPushed := FALSE; END_IF END_FUNCTION Note, for safety reasons, our method implementations always check pointer validity before use. Actually, we just check whether the corresponding index number is in a correct range. This provides save use of pointers and thus it addresses one of the major objections against object oriented concepts. Note, through sound encapsulation of field accesses, we are even able to provide bidirectional associations, where the pair of field update methods in the corresponding classes call each other, mutually.

7 Inheritance: Inheritance relationships may always be replaced by usual one-to-one associations. If this is done, the method implementations have to take care of problems like accessing super class attributes, etc. For example, the struct for the PushSensor class contains a field named sensor, cf. above. This is the reference to the object storing the super class fields of a given PushSensor. Accordingly, the struct for type sensor has field for each possible subclass. At runtime only one of these is employed: TYPE Sensor : STRUCT pin : INT; pushsensor : INT := -1; # pointer to subclass (null) rotsensor : INT := -1; # " " " " listeners : ARRAY [0..maxNoOfListeners] OF INT; mynooflisteners : INT := 0; END_STRUCT END_TYPE Method overriding: Our example uses method overriding e.g. to implement the Observer design pattern. This means, the method evaluate is called on some sensor. This sensor may either be a rotation sensor or a push sensor. Both classes provide their own implementation for method evaluate. Depending on the runtime type, the correct implementation has to be invoked. This is achieved by a special dispatcher method implementation in the super class: FUNCTION SensorEvaluate : INT VAR_INPUT this : INT; END_VAR VAR subobj: INT; END_VAR subobj := SensorGetPushSensor (this); IF subobj >= 0 THEN PushSensorEvaluate(subObj); ELSE subobj := SensorGetRotSensor (this); IF subobj >= 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.

8 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] [DGZ02] [EGSW04] [Fu02] [GSZ04] [KNNZ00] [Zü01] I. Diethelm, L. Geiger, T. Maier, A. Zündorf: Turning Collaboration Diagram Strips into Storycharts; Workshop on Scenarios and state machines: models, algorithms, and tools; ICSE 2002, Orlando, Florida, USA, I. Diethelm, L. Geiger, A. Zündorf: UML im Unterricht: Systematische objektorientierte Problemlösung mit Hilfe von Szenarien am Beispiel der Türme von Hanoi; in Forschungsbeiträge zur Didaktik der Informatik - Theorie, Praxis und Evaluation; GI-Lecture Notes, pp (2002) R. Eckes, J. Gausemeier, W. Schäfer, 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ämper, eds.), vol of Lecture Notes in Computer Science (LNCS), Springer Verlag, September (to appear). Fujaba Homepage, Universität Paderborn, L. Geiger, J. Siedhof, A. Zündorf: µfup: A Software Development Process for Embedded Systems; submitted to Dagstuhl Seminar MBEES, 2004 H. Köhler, U. Nickel, J. Niere, A. Zündorf: Integrating UML Diagrams for Production Control Systems; in Proc. of ICSE The 22nd International Conference on Software Engineering, June 4-11th, Limerick, Ireland, acm press, pp (2000) A. Zündorf: Rigorous Object Oriented Software Development, Habilitation Thesis, University of Paderborn, 2001.