Relevance for PLC programmers
The classic method of programming PLCs is still common today: a few hundred lines of code, e.g. in IL, adopted from the previous machine; searching for, finding and editing the points in the code that need to be adapted according to changes to the machine; the possible addition of new application parts and then loading the complete application into the machine. Application programmers who work like that do not need object-oriented programming (OOP). If they switched to OOP, commissioning would initially take them longer. Also, they would have less of an overview of their code and changes or adaptations would be more complex than before. Object orientation can also barely unfold its advantages for small projects and teams.
OOP fließt heute zunehmend in die Ausbildung von Automatisierungstechnikern ein. Ingenieure und Informatiker, die bereits im Studium OOP gelernt haben, erstellen immer öfter den Applikationscode für modulare oder komplexe Maschinen. Für sie ist eine Zerlegung der Applikation in relevante „Objekte“ ganz natürlich, auch deren vereinheitlichte Definition durch Schnittstellen, sowie die Vererbung von Programmcode für andere Bausteine.
Today, OOP is increasingly incorporated into the training of automation technicians. Engineers and IT scientists who have already learnt OOP during their studies are increasingly creating the application code for modular or complex machines. For them, the breaking down of the application into relevant "objects" is quite natural, including its standardized definition through interfaces, as well as the inheritance of program code for other modules.
With OOP in the PLC, the attractiveness of the application development increases – it loses its reputation as a pure "rattle logic". To that extent OOP guarantees that highly trained programmers will continue in future to enjoy implementing the technological development of machine and plant engineering in application code. After all, the software is responsible for large parts of the added value – efficient tools, methods and appropriately trained programmers are indispensable for this.
Mastering complexity
More complex machines automatically lead to more complex projects. The breaking up of the application into a manageable object structure requires considerable effort at first. However, it is worthwhile if the project is under constant further development, perhaps even by various application engineers. OOP offers invaluable advantages in the mastering of complexity, in particular for the design of standard machines that are manufactured in different variants from similar modules. In this way users can predefine method sets using the language means of the interface, which are then used, i.e. "implemented", in different units of a similar type.
If, for example, a special machine manufacturer uses heating units from different manufacturers and of different types in his machine, he would have to create and call the software modules for each individual unit separately in the functional programming. A change of unit would thus inevitably led to the editing of the entire relevant software part. This, despite the fact that all units provide similar or even identical functions, such as heating on/off, follow heating profile, cooling on/off or similar. In OOP, he defines a standardised interface for such basic functions, which initially contain empty methods. If the user then encodes function blocks for the respective unit and implements the interface with the methods, he gains in two respects: on the one hand, he cannot and will not forget to code all the defined methods of the interface for this unit - the tool reminds him to do so. On the other, he only has to define at a central location which special unit is then really used on the machine. The special methods can be called directly via the interface – no matter in which FB the corresponding method was defined for the unit used. The consequence of this is: however complex the machine may be and whichever subordinate units are actually used: The call of specific parts of the software can be defined centrally and does not need to be rethought every time.
Encapsulation of data
With the different scopes VAR_INPUT, VAR_OUTPUT, VAR_INOUT and VAR for the declaration of control variables, the fathers of IEC 61131-3 have already created possibilities for meaningful data structuring. The user thus defines which of these variables can be accessed within a module. In this way he can avoid accidental access and potential sources of error.
Data encapsulation goes much further in OOP: on the one hand, data can be created in methods and then only used by them. On the other, OOP offers the object type "Property" as the child object of an FB, in which data can be neatly encapsulated and used only via associated set and get methods. References to existing objects and a data type query enable the defined handling of these data - even for more complex variables, such as structures or derived data types. The benefits of such constructs increase with the complexity of a PLC program.
Reusing existing code
IEC 61131-3 development systems such as CODESYS feature convenient library management. Hence, the user can store FBs or functions in a library for later use and integrate them into other projects. But what about code that cannot be fully outsourced to an FB and packaged into a library, for example, because it refers to specific parts of the application, but could still be reused? OOP once again offers a powerful tool for such cases: inheritance! In the above example of the different heating units, the user could, for example, code the "prototype" of a unit in the form of a function block with all the functions or methods that are available in all actually used units. He thus creates a base class. Starting from such a class, he can now define a more complex unit using the new keyword "EXTENDS" and program it with methods that extend its basic functionality. The methods created in the base class are available to him without further ado. However, if the function of individual methods is not sufficient, he can "overload" them, i.e. extend them by functions that were not implemented in this way in the base class. The original code of the basic type can additionally be called conveniently via the Super^ operator - the extended class inherits it too. Using FBs that access other FBs or interfaces ("aggregation"), the user can now construct the entire application hierarchically and continue to use already coded functions.
Efficiency in engineering
With a little practice and experience in OOP, a complex application gains clarity and becomes much more manageable. The entire project can then often be completely described by calling a few function blocks. These function blocks for their part branch into the depths and execute the coded or inherited functions. The widespread use of OOP in other areas of software development proves in impressive fashion that its advantages predominate. However, a conversion of applications must not take place by force, but in the rhythm of the natural further development of application and programmers. CODESYS meets this demand: function blocks produced by object-oriented programming are provided, but called by the user functionally without him noticing the OOP at all. Ultimately, only OOP enables a seamless, "smooth" integration of many powerful functions such as visualization, Motion Control or fieldbus support into the IEC 61131-3 interface. Many users use the possibilities of OOP themselves for more efficient engineering, while others only benefit implicitly from it. Ultimately, however, they all have added value.
Mechatronik 1-2/2018