PLCopen

for efficiency in automation

PLCopen - Promotional Committee 2

–

Training

Guidelines for usage of Object-Oriented Programming

Version 0.99 – Release for Comments till August 14, 2021

DISCLAIMER OF WARANTIES

THIS DOCUMENT IS PROVIDED ON AN “AS IS” BASIS AND MAY BE SUBJECT TO FUTURE ADDITIONS,
MODIFICATIONS, OR CORRECTIONS. PLCOPEN HEREBY DISCLAIMS ALL WARRANTIES OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE, FOR THIS DOCUMENT. IN NO EVENT WILL PLCOPEN BE RESPONSIBLE
FOR ANY LOSS OR DAMAGE ARISING OUT OR RESULTING FROM ANY DEFECT, ERROR OR
OMISSION IN THIS DOCUMENT OR FROM ANYONE’S USE OF OR RELIANCE ON THIS DOCUMENT.

Copyright © 2021 by PLCopen. All rights reserved.

Date: May 27, 2021

Total number of pages: 29

 PLCopen
®

for efficiency in automation

PLCopen Guidelines for usage of Object-Oriented Programming

The following paper is a document created within the PLCopen Promotional Committee 2 – Training.
It summarizes the results of the PLCopen Promotional Committee meetings, containing contributions of its
members as well as external sources:

Name Company
Rene Simon Hochschule Harz
Wolfgang Doll Codesys
Yves de la Broise Interval Zero
Anders Lekve Brandseth Framo
Daniel Wall Eaton
Filippo Venturi SACMI
Georg Rempfler Wyon
John Dixon ABB
Dominik Franz ABB
Ralf Dreesen Beckhoff
Saele Beltrani SACMI
Yo Takahashi Mitsubishi Electric
Juliane Fischer TUM

Eelco van der Wal PLCopen

Change Status List:

Version Date Change comment
number
V 0.1 May 28, 2019 Document created by EvdW as input for the webmeeting
V 0.2 June 19, 2019 As result of the webmeeting June 11
V 0.3 July 2, 2019 As result of the webmeeting on July 2
V 0.4 July 30,2019 As result of the webmeeting on July 30
V 0.5 Oct. 30, 2019 As a result of the discussions upfront and webmeeting
V 0.6 Feb. 2, 2021 Conversion to boiler demo example
V0.6c March 5, 2021 Added examples and text in Ch. 3
V0.7 April 22, 2021 After feedback and webmeeting
V0.8 May 6, 2021 After feedback and webmeeting
V0.9 May 20, 2021 After additional feedback and decisions at webmeeting
V0.99 May 27, 2021 Published as Release for Comments to the public

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 2/29
 PLCopen
®

for efficiency in automation

Contents
1 INTRODUCTION TO THIS DOCUMENT ............................................................................. 5
1.1. GOALS OF THIS WORKING GROUP ......................................................................................... 5
2 INTRODUCTION IN THE OOP FEATURES OF THE 3RD EDITION OF THE IEC 61131-3
STANDARD. ...................................................................................................................................... 6
2.1. THE 3RD EDITION OF IEC 61131-3......................................................................................... 6
2.2. DEFINITIONS IN THE IEC 61131-3 STANDARD ...................................................................... 6
2.3. DIFFERENCES IN OOP LANGUAGES ...................................................................................... 8
3 GENERIC APPROACH ............................................................................................................ 9
3.1. GENERAL ............................................................................................................................. 9
3.2. MODULES AND COMMANDS ................................................................................................. 9
4 THE BASIC EXAMPLE: BOILER DEMO ........................................................................... 12
4.1. OVERVIEW OF THE DIFFERENT PHASES ............................................................................... 12
4.2. APPLICATION DESCRIPTION ................................................................................................ 12
4.3. THE EXAMPLE IN A CLASSICAL PROGRAM STYLE ................................................................ 13
4.4. CONVERTING THE PROGRAM TO A PLCOPEN COMPLIANT VERSION .................................... 14
4.5. ADDING ERROR BEHAVIOUR .............................................................................................. 17
4.6. ADDING A SYSTEM ALARM LIST .......................................................................................... 25
5 ADDITONAL CONSIDERATIONS ....................................................................................... 28
5.1. FUNDAMENTALS FOR OOP GUIDELINES – CONSIDERATIONS.............................................. 28
5.2. NOTES ON PERFORMANCE CONSIDERATIONS ...................................................................... 28
5.3. NOTES FOR FURTHER INVESTIGATIONS ............................................................................... 29

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 3/29
 PLCopen
®

for efficiency in automation

List of figures
Figure 1: Representation of IModules and ICommands............................................................................. 10
Figure 2: Implementation of LConC .......................................................................................................... 11
Figure 3: State Machine of LConC ............................................................................................................ 11
Figure 4: The boiler demo. ......................................................................................................................... 12
Figure 5: Layout of the POUs .................................................................................................................... 13
Figure 6: Function block interface and state diagram of LConC ............................................................... 15
Figure 7: Same interfaces for different devices .......................................................................................... 16
Figure 8: Overview of the states in a simulation ........................................................................................ 17
Figure 9: The AttachDevice Method of the Error handler ......................................................................... 18
Figure 10: The Error Handler FB with the list of the devices (FBs)......................................................... 19
Figure 11: Initialization from the Error Handler in FB_Boiler ................................................................. 19
Figure 12: The structure for Error Handler ............................................................................................... 20
Figure 13: Main program with error handling .......................................................................................... 20
Figure 14: Example of the error message for one FB ............................................................................... 21
Figure 15: Overview of the architecture ................................................................................................... 21
Figure 16: Example of a cyclic action linked to the IActionControl ........................................................ 22
Figure 17: Implementation of the Set action of the Behaviour Model ..................................................... 23
Figure 18: The needed changes in the Device FB..................................................................................... 23
Figure 19: Corresponding changes to the attached devices ...................................................................... 24
Figure 20: UML Diagram of the new design ............................................................................................ 24
Figure 21: Implementation of the GetName in the Base Class ................................................................. 25
Figure 22: Implementation of the delegation of the GetModelState......................................................... 25
Figure 23: String array for the error handler ............................................................................................. 26
Figure 24: Example of an error string ....................................................................................................... 26
Figure 25: Example of creating the string in the error message ............................................................... 26
Figure 26: The function FC_ErrorCode .................................................................................................... 27

List of abbreviations:
FB Function Block conform IEC 61131-3
FC flow control
LC level control
OOP Object-Oriented Programming
OT Operation Technology
PID Proportional, Integral Derivative control algorithm
PLC Programmable Logic Controller

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 4/29
 PLCopen
®

for efficiency in automation

1 Introduction to this document

The 3rd edition of the IEC 61131-3 standard makes the usage of Object-Oriented Programming, OOP,
possible. Parallel to this, PLCopen has defined the concept of function block libraries including OOP and
the PLCopen Common Behaviour Model (see on the PLCopen Website “Creating PLCopen Compliant
Libraries V1_0” dated May 4, 2017), as well as sets of function blocks for motion control, safety, and
communication.
Starting with OOP, several choices need to be made right from the beginning: are all function blocks in one
Class? Think about the PLCopen Motion Control function blocks as an example, do we need then the
AxisRef as the reference to the axis or even the MC_ as part of the FB name? How do they contain the
methods? And will we use only methods, or also direct access to variables? Is the state machine for the axis
controlled by the methods? Are all axes’ objects with methods, and we access them only via these methods?
How about interfaces? And do we prefer composition above inheritance?
All these choices give a different look & feel to the users across the different systems, different training
guidelines and differences in maintenance. And this is where PLCopen wants to help and give guidance to
create a more homogeneous programming methodology.

1.1. Goals of this working group

Overall, there is little information on how to use OOP for industrial control or the operation technology
(OT). The goal of this group is to help here with the following recommendations:
• Guidance to using OOP in addition to the “classical” way.
• Provide the same look & feel in using OOP across the different platforms and implementations.
• Create generic design patterns for industrial control programming.
• The classical programming way should be possible to be used in addition to the OOP way (e.g. this
can mean that we have to extend the classical FBs with interfaces, methods, properties, and maybe
input and outputs).

As example, a boiler demo will be used to represent the different forms of programming.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 5/29
 PLCopen
®

for efficiency in automation

2 Introduction in the OOP features of the 3rd edition of the IEC 61131-3
standard.
2.1. The 3rd edition of IEC 61131-3
Modern programming environments refer in many cases to OOP which is included in Python, C++,
Objective-C, Smalltalk, Delphi, Java, Swift, C#, Perl, Ruby and PHP.
Important aspects of the 3rd Edition of the IEC 61131-3 standard are the integration of object-oriented
features. This includes Classes, including Methods and Interfaces, OOP features for Function blocks, and
Namespaces.
The 3rd edition of standard IEC 61131-3 – Programming Languages is approved as International Standard.
This means that this edition is now official and is available as International Standard at www.IEC.ch . This
standard is fully upwards compatible to IEC 61131-3, 2003 (2nd edition).
The 3rd edition has a long list of changes and enhancements. Important aspects are the integration of OOP
features. These include Classes, Methods and Interfaces, OOP features for Function Blocks, and
Namespaces.
The main reason to include these extensions is to link better to the scarce resources of engineers in the
future. With preferences to writing apps for the mobile world, we should better adapt to them than vice
versa.
Note that references are made to the IEC 61131-3 standard itself as is available at www.IEC.ch. These used
references are for explanation only and for completeness the standard itself should be bought.
2.2. Definitions in the IEC 61131-3 standard
With these OOP extensions, there are several changes or new definitions in comparison to the 2nd edition.
For instance, a program organization unit, originally defined as function, function block, or program, is
extended to include a category “class”.
Function blocks and classes may contain methods. This means that also a class and a derived class must be
defined, similar to derived data types and derived function blocks, as well as methods.
The most important new definitions are listed here:
Name Description
base type data type, function block type or class from which further types are
inherited/derived.
call language construct causing the execution of a function, function block, or
method.
class program organization unit consisting of:
• the definition of a data structure,
• a set of methods (like subroutines) to be performed upon the data structure
A class is an implementation— a concrete data structure and collection of
subroutines— while a type is an interface.
derived class class created by inheritance from another class.
Note 1 to entry: Derived class is also named extended class or child class.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 6/29
 PLCopen
®

for efficiency in automation

Note 2: this is of course very much in line with derived data type and derived
function block type as defined in the IEC 61131-3-2003.
dynamic situation in which the instance of a method call is retrieved during runtime
binding according to the actual type of an instance or interface.
inheritance creation of a new class, function block type or interface based on an existing
class, function block type or interface, respectively.
input variable variable which is used to supply a value to a program organization unit except
for class.
instance individual, named copy of the data structure associated with a function block
type, class, or program type, which keeps its values from one call of the
associated operations to the next.
interface language element in the context of OOP containing a set of method prototypes.
Example: it is similar to a motor flange: it describes holes diameter, distance,
shaft size, but it is not a motor.
method language element similar to a function that can only be defined in the scope of
a function block type and with implicit access to static variables of the function
block instance or class instance.
Example: a boiler can have a Fill method, a HeatUp method, each one
performing a specific task.
override keyword used with a method in a derived class or function block type for a
method with the same signature as a method of the base class or function block
type using a new method body
output variable variable which is used to return a value from the program organization unit
except for classes.
program function, function block, class, or program.
organization
unit
signature set of information defining unambiguously the identity of the parameter
interface of a METHOD consisting of its name and the names, types, and order
of all its parameters (i.e., inputs, outputs, in-out variables, and result type).

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 7/29
 PLCopen
®

for efficiency in automation

2.3. Differences in OOP languages

There are other OOP languages, and the table hereunder gives a short overview of the commonalities and
differences.

Language Properties IEC 3rd Edition C++ Java C#

Multi languages + + - - -

OOP/procedural mixed - + + - -

Classes ~ (FB) + + + +

Methods ~ (Actions) + + + +

Interfaces - + - + +

Polymorphism - + +/- + +

Semantic Reference - + (Interfaces) - + +

Constructor/Destructor -/+ -/+ + + +

Properties - - - - +

Dyn. Memory („new“) - - + + +

Access control ~ (Variables) ~ (Variables) + + +

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 8/29
 PLCopen
®

for efficiency in automation

3 Generic Approach
3.1. General
The PLCopen document "Guidelines for usage of Object Orientation" defines the currently generally
accepted rules for good OOP design in the context of the IEC61131-3 3rd Edition.

It is advised to read the document PLCopen Software Creation Guidelines: Creating PLCopen Compliant
Libraries, Version 1.0 of May 4, 2017, which is downloadable from the PLCopen website. As part of this,
we will use the SOLID principles in the automation technology environment. SOLID stands for:

- SRP — Single Responsibility Principle

- OCP — Open/Close Principle
- LSP — Liskov Substitution Principle
- IPS — Interface Segregation Principle
- DIP — Dependency Inversion Principle

3.2. Modules and Commands

When designing applications and libraries in an OOP way, we differentiate between modules and
commands.

• A module represents a part of an automation application including their software function and can
also be nested hierarchically as required. These kinds of objects are implemented with the keyword
CLASS.
• A command represents a concrete action of a module. It is assigned to one module or to a group of
modules they implement the same interface. These kinds of objects are implemented with the
keyword FUNCTION_BLOCK.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 9/29
 PLCopen
®

for efficiency in automation

Figure 1: Representation of IModules and ICommands

Every module is implementing a generic IModule interface.
Some modules implement additionally a more specialized interface. For example, the modules that provide
the functionality of an axis, are implementing an IAxis interface.

Every command will implement a generic ICommand interface and will follow the design guidelines for
PLCopen conforming function blocks.
The axis related commands provide an input of type IAxis to get the reference to a related axis instance they
will act upon.

With this construction it is possible to bring two worlds reconcilable together.

For example, the classic PLCopen Motion function blocks can be reused in their traditional form. At the
same time, these function blocks can also be controlled via their modern interface. This opens new
possibilities for innovative solutions such as reconfiguring applications at runtime.

Example of LConC from the document “Creating PLCopen compliant libraries”. LConC stands for Level
Controlled, not time limited and with a continuous behaviour.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 10/29
 PLCopen
®

for efficiency in automation

Figure 2: Implementation of LConC

Figure 3: State Machine of LConC

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 11/29
 PLCopen
®

for efficiency in automation

4 The basic example: boiler demo

4.1. Overview of the different phases
The original example was used for a demonstration at the Hanover Fair in cooperation with the OPC
Foundation.
This original code is transferred into a format that is compliant with the PLCopen Guidelines, so based on
the harmonized function block interfaces.
The next step is to convert this to Object Orientation, which is followed by the addition of an error handler
and alarm management.
The program is written in Structured Text and the code can be found on the PLCopen website as a Codesys
project.

4.2. Application description

The application of the example “Boiler Demo” consists of a simulated boiler as shown in figure Figure 4:
The boiler demo.

Figure 4: The boiler demo.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 12/29
 PLCopen
®

for efficiency in automation

4.3. The example in a classical program style

The application simulates a boiler process with a basic PID controller supported by flow control (FC) and
level control (LC) including a random generator for disturbances in the feeds.
There are two programs, 4 user derived functions and 17 user derived function blocks.

PROGRAM - MAIN & P_Initialisation

Defined FUNCTIONS
F_FeedwaterEstimator
F_AlignValues
F_IntToReal
F_RealToInt

Defined FUNCTION BLOCKS

FB_AutomaticMode
FB_InputParameter
FB_DRAND
FB_BasicPIDCtrl
FB_Boiler
FB_OutputPipe
FB_SteamFlow
FB_InputPipe
FB_Valve
FB_FeedwaterRate
FB_Drum
FB_FillLevel
FB_Potentiometer
FB_Motor
FB_LevelController
FB_FlowController
FB_ControlComputation

Figure 5: Layout of the POUs

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 13/29
 PLCopen
®

for efficiency in automation

4.4. Converting the program to a PLCopen compliant version

The design is already well structured with regards to the first SOLID rule "Single Responsibility Principle".
There is a separate FB for every hardware element, as well as for every new task.
Unfortunately, this application has not yet been designed according to an OOP approach, so the other rules
are not adhered to.
There is no interface and there is no abstraction. All FBs were programmed and used directly on the detail
level.
There are two possible approaches to adapting this application:
1. A complete redesign of the application according to OOP approaches and rules. An exceptionally good
architecture can be achieved in this way.
Unfortunately, this solution is very time-consuming and expensive, which makes it difficult for a machine
builder to get a completely new software generation approved by the management.
2. Therefore, we try to present a second possibility to partially restore the application. Due to the good
starting point, this step can be considered. For (brownfield) applications that have grown over many years
and are too nested, it is better to rely on a new generation.
The original building blocks were programmed on the lowest level of detail. The first step is to achieve
standardization and abstraction of the building blocks. The PLCopen guidelines for function block libraries
offer a clear interface and standardized behaviour for this purpose. The essence of the guidelines is the so-
called "behaviour model". So, the first step was to convert the original program including the defined
function and function blocks into the applicable behaviour model, including the state machine and the error
behaviour. The OOP structure of the PLCopen Common Behaviour Model offers us excellent opportunities
to implement this in just a few steps and changes.
Also, we try to use the rules Open / Close Principle and Dependency Inversion Principle. In addition, a first
interface is defined which can be used for future extensions.
Because the building blocks can be extended by the defined behaviour models, in this case the LConC is
used, they get an abstract higher level that does not depend on the details of the lower level. The LConC
also defines an interface which must now be implemented by the old FB’s. In the first step, however, only
the code from the body of the old FB’s have to be copied into the Cyclic Action method.
As a result, the open / close principle is adhered to, the block retains its functionality, and the existing
software code does not have to be changed. This also gives classic style software developers the opportunity
to slowly get used to the changeover. Since the FB’s are still 1-to-1 identical, and the implementation has
not been changed significantly either. But the modules are now open for expansion. Also, incorrect user
entries and parameterization can now be monitored in the StartAction (as used in the edge triggered function
blocks as defined in the PLCopen library document), in order to increase the stability. In addition, the
modules now have an abstract and uniform interface with which further extensions can be made that follow
the rule “Interface Segregation Principle”.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 14/29
 PLCopen
®

for efficiency in automation

Figure 6: Function block interface and state diagram of LConC

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 15/29
 PLCopen
®

for efficiency in automation

Figure 7: Same interfaces for different devices

The consistent design of the Common Behaviour Model enables us to create an abstraction that is even
independent of the state machine chosen. As all state machines, it is derived from an abstract class with a
general defined interface.
This now offers the possibility to manage the FBs in a uniform way at a higher level in the same way. For
example, to implement an error handler that can manage all FBs regardless of their implementation
(Interface Segregation Principle).

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 16/29
 PLCopen
®

for efficiency in automation

Figure 8: Overview of the states in a simulation

Be aware that the main program here is not usable in real applications as it is missing a start-up sequence, a
shutdown sequence, and error handling. This is the part that is customized for every application. These
additions will show further benefits of the OOP due to the re-use.

4.5. Adding Error Behaviour

As an example of this, the error behaviour is added as a central error handling function block, which traces
all the used function blocks. This is shown in 2 ways: via inheritance and via composition.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 17/29
 PLCopen
®

for efficiency in automation

We will not use the different detailed FBs directly, but we will use our abstract Interface IBehaviourModel
(see Figure 7:Same interfaces for different devices). This interface gives access to the Outputs from the
function blocks which include xDone, xBusy, xError, xAborted, iErrorID. This is the idea from the Interface
Segregation Principle, and with this, all the FBs from the Common Model Library can now be connected.
This is not corresponding to only one FB-type, nor to one Behaviour Model. All described Behaviours and
types can be connected without any adaptation to this ErrorHandler.
The idea is to map all the function blocks to an array which is included in the error handler, to enable an
iteration through all the function blocks. In this Array we will not have a Pointer to the different FBs on
detail level, but we will have the basic interface IBehaviour Model only. With the Method GetModelState
we can monitor the required information from all FB. See Figure 10:The Error Handler FB with the list of
the devices (FBs).
The Error Handler has two methods to link it to the devices (FBs): AttachDevice and DetachDevice. The
error handler has these two methods for attach and detach, reflecting it in the device list. The error handler
references to this list (see Figure 12:The structure for Error Handler).
We can now monitor all FBs with the same Method GetModelState and build a structure with Status
Information so that one can see the status from all the function blocks.

Figure 9: The AttachDevice Method of the Error handler

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 18/29
 PLCopen
®

for efficiency in automation

Figure 10: The Error Handler FB with the list of the devices (FBs)
The definition of the Attach and Detach Methods is done in an Interface which is implemented from the
Error Handler. This interface can now be used by the Boiler to attach all the instances to the Error Handler.

Figure 11: Initialization from the Error Handler in FB_Boiler

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 19/29
 PLCopen
®

for efficiency in automation

Figure 12: The structure for Error Handler

In the main program we can now build an instance from the Error Handler and connect the Error Handler to
the Boiler instance:

Figure 13: Main program with error handling

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 20/29
 PLCopen
®

for efficiency in automation

Figure 14: Example of the error message for one FB

The error handler is now a standard component of all FBs. It handles all the devices centrally without
separately calling all the instances of the used FBs, while being able to centrally read all the relevant
information of the FBs.
This concept makes it easier to control all the function blocks with one list only. In an alternative way, one
must connect to all the FBs and point to all the different available function blocks. Now you have only one
interface with one list from which you can control all listed function blocks.

Figure 15: Overview of the architecture

The model in Figure 15: Overview of the architecture shows that LConC (and its interface) inherits from the
BehaviourModelIBase and so the interface IBehaviourModel.
The I_ErrorHandler interface is linked to all the FBs which are used in the demo as well as to the
FB_ErrorHandler. In this way, the ErrorHandler can connect to all applicable FBs.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 21/29
 PLCopen
®

for efficiency in automation

Using inheritance as a base design for FBs gives a nice abstract control option but shows some limitations.
We are no longer able to extend the detailed device FB on an abstract Level. The reason for this limitation is
that one cannot use inheritance on the abstract Level BehaviourModelBase as it uses inheritance already.
This is the point to check, if we can optimize this design by using composition instead of inheritance for the
Behaviour Model. For this, we must show how we can define the Behaviour Modell as a member of our FBs
but define the Method for the different states in the same way as before. (Open / Close Principle).
A feature from the Common Behaviour Model can help us to implement this design. The FBs in the Library
support the connection of an Action Controller, which allows a FB which implements the IActionController
to do a Method call instead of the methods which come from the Behaviour Model.
The idea is now to create a new Abstract Device Base Class, which has as a new feature ‘Name’ from the
FB as a complete Path. To support now the Composition from Behaviour Model, our Base Class implements
the IActionController. To follow the Open/Close Principle it is recommended to implement the
IActionProvider Interface also. This allows the detailed Device FB to work with the behaviour
implementation on the same way as before.
In the Method from the Action Controller, one calls a Method, which comes from the Action Provider.
The following example shows the cyclic action.

Figure 16: Example of a cyclic action linked to the IActionControl

The Base Class will also get a Property to ‘get’ and ‘set’ the IBehaviourModel. In the Setter the
IActionController will directly link to the instance of the created Behaviour Model.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 22/29
 PLCopen
®

for efficiency in automation

Figure 17: Implementation of the Set action of the Behaviour Model

The detailed FB can now decide, which Behaviour Model it will use. The only applicable changes are the
following:
• Change the inheritance from the LConC to our own Base Class.
• Create an Input variable for xEnable or xExecute based on your decided Behaviour.
• Create an instance from the Behaviour you want to use.
• Change the Execution from the Model in the Body and give the member Behaviour instance to the
Property.
See the following example:

Figure 18: The needed changes in the Device FB

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 23/29
 PLCopen
®

for efficiency in automation

To attach our FBs to the Error Handler we use our property so that the interface to the Error Handler can
still be the same.

Figure 19: Corresponding changes to the attached devices

The architecture is shown in Figure 20:UML Diagram of the new design. It has now the advantage, that we
can use the new abstract FB to add new features which are related to all FBs in a consistent way. Code
redundance is also avoided in every FB. Furthermore, it provides the possibility to inject the Behaviour
Model from outside with the Property BehaviourModel.

Figure 20: UML Diagram of the new design

Based on this, it is easy to create additional functionalities, like an alarm list, as done in 4.6 Adding a system
alarm list.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 24/29
 PLCopen
®

for efficiency in automation

4.6. Adding a system alarm list

One can differentiate between process alarms and system alarms, to filter them for different users (e.g. tank
operator and system administrator). This example deals with system alarms, but the process alarms can be
created in a similar way. One can even extend the FBs with an output like ProcessAlarm and handle these
separately.
To create an error list it may be useful, to know in which FB the Error is happening or even the complete
instance path.
For that, we have implemented the name and a Method to have access to the Name in our Abstract Base
class. The name is generated here by a feature of the Codesys Development System, but it can also be set
via a Property, for example during the Init Routine in the Boiler FB. Using an Interface which describes the
Method directly follows the Interface Segregation Principle.

Figure 21: Implementation of the GetName in the Base Class

To get access to this method, we need a new or extended Interface for the Error Handler. Changing the
interface is normally not the best style but, in this case, we can directly implement the interface in such a
way, so that it includes only the necessary information. In this sample these are the GetModuleState and the
GetName Methods. So, it makes sense to adapt the Interface in the Attach / Detach Method and the Array of
Interfaces in a way that they do not use the IBehaviourModel but the new Interface IBasicElement. The
Method GetModelState will delegate the request to the internal set State Machine, as shown hereunder:

Figure 22: Implementation of the delegation of the GetModelState

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)
V0.99 - RfC May 27, 2021 page 25/29
 PLCopen
®

for efficiency in automation

This is implemented in a way that all errors which happen are presented in a string array, which users can
read.

Figure 23: String array for the error handler

Figure 24: Example of an error string

Figure 25:Example of creating the string in the error message, shows a small function as part of the error
handling which converts the Error into a clear string, only on the rising and falling edge of the xError
Output.
Combined with a function FC_ErrorCode which converts the iErrorID to a string (see Figure 26:The
function FC_ErrorCode).

Figure 25: Example of creating the string in the error message

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 26/29
 PLCopen
®

for efficiency in automation

Figure 26: The function FC_ErrorCode

A possible improvement in the design can be to change the way the ErrorHandler checks all the FBs in a
cyclic way. One idea can be to use here the Observer Pattern in this way that the ErrorHandler is connected
to the Devices as an Observer and the Devices will send out a notification if the Status is changed.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 27/29
 PLCopen
®

for efficiency in automation

5 Additonal considerations
On the following pages some information from previous discussions are listed. Currently they have not the
right quality to be included in the main text.
5.1. Fundamentals for OOP Guidelines – considerations

Within this document, some key aspects shall be taken into consideration:

• Good design but bad performance -- Which details should be considered in order not to influence the
performance too much?

• Inheritance and composition -- How inheritance weakens encapsulation

Many respected OO designers1 have stated that composition should be given preference over
inheritance whenever possible and that inheritance should only be used when necessary.
However, this statement is somewhat shortened. The call that composition should be used whenever
possible obscures the actual problem.
Experience shows that composition is in most cases more appropriate than the use of inheritance.
The fact that composition seems more appropriate in most cases does not mean that the use of
inheritance is to be avoided.
Both methods, inheritance, and composition, have their justification, but in the right context.

• Avoidance of dependencies
The introduction of dependencies at runtime (Dependency injection) plays a central role in the
discussion whether the composition should be given a priority over inheritance.
It is very important to note that this is only a discussion.
The purpose of this discussion is not necessarily to find the "optimal" way to design a class, but to
provide food for thought on how to deal adequately with the decision for or against the use of
inheritance or composition.

• Catalogue of relevant Design Patterns

A library of PLCopen promoted interfaces, abstract classes, ...
that will help us writing OOP libraries and applications.

5.2. Notes on performance considerations

With the change in the architecture, it is very important not to lose sight of the special situation of a PLC
compared to a PC/server system.
Overall, there are three actors who could still do a little more for the application of OOP:
▪ Hardware design
Currently we can see a big difference in the measurements of the runtime. Depending on the hardware, a
virtual method call takes drastically more time or is of little importance compared to a normal subroutine
call. Of course, a small runtime extension in a cyclic executed PLC operation is often of great importance.
The decisive factor here is the connection of the data/code memory to address and data buses and the
possibilities of proper cache mechanisms. Especially the cache can help us to save time in cyclic operation.

1Like: Design Patterns: Elements of Reusable Object-Oriented Software by ErichGamma, RichardHelm,

RalphJohnson, and JohnVlissides (the GangOfFour).
TC2 Training – Guidelines for usage of OOP © PLCopen (2021)
V0.99 - RfC May 27, 2021 page 28/29
 PLCopen
®

for efficiency in automation

When designing a controller today, it is no longer just a question of how much time 1024 IL instructions
require!
▪ Compiler design
The code generator for a PLC must ensure that the code parts of an application are in relation to the cache
structure in the neighborhood. So, code and data which are used cyclically can be processed very fast
without a new transfer from the main memory. The implementation of interfaces, methods, and properties
but also references must be adapted to the needs of a PLC. So, use cases like OnlineChange and
Debugging must be considered early and well. The allocation of memory on the stack (local variables)
must not create a problem when using methods. The initialization of extensive data structures can become
a problem (e.g., when cyclically called) and should be accordingly controllable by the user.
▪ Software design
The keywords ABSTRACT, FINAL, PRIVATE, ... must be used consciously.
This allows the developer to influence essential aspects of the runtime of his software at a very early stage.
The developer must keep an eye on whether and when the initialization of his local variables must take
place. The PLC development environment should provide a way to prevent the initialization of a set of
specific variables so that "much" time can be saved here.

5.3. Notes for further investigations

• Synchronous versus a-synchronous communication / run-time environments
• Should we introduce dynamic memory allocation to the classical control world?
• Show no preferences for already existing implementations and programming styles.
• It can be that a programming paradigm shift is unavoidable.

TC2 Training – Guidelines for usage of OOP © PLCopen (2021)

V0.99 - RfC May 27, 2021 page 29/29