B 3654

2/2007

Automation Technology
in Practice

International

November

Programming PLCs with an

Object-Oriented Approach

Reprint

Engineering Embedded Systems

Programming PLCs with an

Object-Oriented Approach
Ph.D. (MUN, Can.), Ulf Schnemann, 3S Smart Software Solutions GmbH,
Memminger Str. 151, 87439 Kempten, Germany
While in the field of desktop applications object-oriented programming has become an integral part of
mainstream languages it is very rarely used in industrial controller applications. Those who believe this is
due to the sometimes conservative approach of PLC programmers are only partly right. Main reason for this
development is the lack of suitable tools. Even if almost every controller platform offers a C++ compiler this
compiler only covers the programming aspect. The debugging and commissioning features are completely
useless for industrial controller applications. The workshop shows the extension of the wide spread IEC
61131-3 programming system CoDeSys by real object oriented programming methods and discusses the
advantages for the user.
Object-oriented programming / SPS / IEC 61131-1 / CoDeSys

1. Introduction
In desktop application development and in university education, object-oriented programming (OOP) in languages
like C++ or Java is now common place. OOP has demonstrated its capability for handling complex software development problems in an elegant way and for producing flexible, reusable software components. It has reduced the
development time of new software and simplified the solution of complex software tasks.
Industrial controllers (PLC), on the other hand, are mostly
programmed in the languages of the IEC 61131-3 standard.
While some developers cannot wait to use OOP for PLCprogramming, others may be sceptical about the adequacy
of OOP for their PLC-projects. In order to address both parties, an object-oriented programming tool should satisfy the
following requirements:
 Integration in a PLC development environment: Integrated
with the object-oriented programming itself, one should
have integrated configuration of I/Os, direct access to I/Osignals, and online-debugging functionality with variable
forcing and online change. Advantage: PLC-application
development has many specifics, which exiting C++
development tools available for many target-CPUs do not
address.
 Multi-paradigm programming: Object-orientation should
be optional. Code programmed in the classical, procedural way should be mixable with object-oriented code.
Advantage: This offers the sceptics a stepwise and reversible transition.
 OOP by extension of the IEC: Object-oriented PLC-programming should be supported by extending IEC programming with a small set of standard object-oriented features. Advantage: Not having to learn a completely new
www.atp-international.de atp international 2.2007

language avoids a steep learning curve for PLC-programmers.

 Multi-lingual: Object-oriented programming should be
supported in all languages of the IEC 61131-3, not just in
the textual IEC-language ST most similar to C++ and
other known object-oriented languages. Advantage: Textual languages cannot represent clearly certain important
aspects of PLC applications, like state machines and complex Boolean connection networks.
Such an object-oriented programming tool is available on
the market in the form of the IEC-development environment
CoDeSys V3 developed by 3S Smart Software Solutions. As
opposed to other object-oriented languages, this objectoriented extension is not based on the generalization of the
data record construct to a class construct (C++ generalized
Cs struct, Ada95 generalized Pascals record). The IEC includes
something much better than its STRUCT construct: Functionblocks.
CoDeSys extends the FUNCTION_BLOCK-construct to a
class construct by the addition of methods, properties
and subclassing.

Table 1: OOP statistics.

SysLibs, I/O-driver

Functionblocks with methods

Interfaces
(# extensions implementing
Not
among them) an interface implementing
(# extensions) an interface
(# extensions)
10
7 (2)
2

Visualization

11 (1)

24

21

Data server

19 (4)

16 (3)

38 (21)

Others

13 (1)

19 (1)

8 (7)

59

Engineering Embedded Systems

objects. Each object is a small procedural system with its
own state and behaviour (implemented through methods).
An objects method can operate on its state and call the
methods of other objects, to which it is connected by object
references.
Advantage: Assume a real object (e.g. a PUMP) or a virtual
object (e.g. a SCROLLBAR) shall be managed by your system.
Is it natural to think of this as an additional data structure,
whose handle you have to pass into a Devices-API or a Windows-API? Or is it more natural to think of it as a new object
that brings its behaviour with it and that you invoke directly
on that object?
WindowsAPI.SetFocusTo(handleToMyScrollbar);
// procedural myScrollbarObject.GrabFocus();
// object-oriented
Fig. 1: Method calls. Fig. 1: Method calls.

And CoDeSys introduces the INTERFACE-construct for the

declaration of abstract functionblock-types with polymorphic reference semantics.
The new object-oriented features have already proved
their practicality and usefulness in 3Ss advanced libraries
(see table 1), where they were employed heavily with over
50 interfaces and over 130 object-oriented functionblocks.
In the following we will consider what defines object-oriented programming and look at the language extensions
supported it.

2. The Elements of Object-Oriented Programming

Object-oriented programming (OOP) is best explained not in
terms of programming language features but by its specific
approach to organizing the software. A language can be
called object-oriented if its linguistic elements allow the
programmer to express such an organization.
These are the three accepted elements of the object-oriented organization:
1. Objects organize the computational system into components
2. Classes organize objects by similarity
3. Subclassing organizes classes by degrees of similarity

2.1 The Object (Computational System =

Composition of Objects)
The fundamental characteristic of OOP, as opposed to classical procedural programming (C, IEC), is a new way of thinking about the computational system: The procedural view
separates the representation of the systems state through
data components (variables) from the implementation of
the systems behaviour through procedures. In the objectoriented view, the system is composed of interconnected

60

Language feature: Dot-notation

In CoDeSys V3, instances of functionblocks with methods
(see below) are objects. Through the standard dot-notation
for invoking a method, the notion is support that the method
is a part of the functionblock instance.
The following code shows a program invoking the Start
method on a Pump object and on a MonitoredPump object:
Note: In CoDeSys, as in most object-oriented programming languages, besides objects there are still other entities
in the computational system, like global or static variables
and global or static procedures.

2.2 The Class (Object = Instance of a Class)

Objects with the same data and behaviour belong to the
same type, called class. All objects are instances of a class
(even if no other object has the same data and behaviour).
While objects are the components of the computational
system, the definitions of their classes are the modules of the
program code.
Compare this to procedural programming: Here, typing is
based solely on data. Data components (variables) with the
same structure and value range are instances of the same
data type, while each procedure is unique. Where one needs
to type procedures, one can only use the combination of the
data types of their inputs and outputs.
Advantage: Instead of implementing a single PUMP object
(and maybe later having to implement another one), we
directly implement with the languages class construct
PUMP objects in general and then create as many PUMP
instances as we want.
Language feature: Variables
IECs functionblock construct is a good basis for a class construct since the variables declared therein define the representation of the instances state. These variables are protected by the IEC visibility rules:
 The functionblocks internal variables (VAR) can only be
accessed within that same functionblock and its methods.
 The functionblocks input variables (VAR_INPUT) can be
written from outside and read from within the functionblock and its methods.
atp international 2.2007 www.atp-international.de

Engineering Embedded Systems

The functionblocks output variables
(VAR_OUTPUT) can be written from
within the functionblock and its
methods and can be read from the
outside.
This means, only internal variables
can properly be used for the objects
state representation. It follows, first,
that the objects state is under the sole
control of the objects methods (encapsulation). Advantage: No interference
from somewhere else in the system can
then unexpectedly destroy the consistency of the state representation maintained by the methods. Moreover, it
follows that the state representation is
not visible to the outside at all (information hiding). Advantage: The implementation decision how to represent
an objects state is localized in its own
methods. It can be revised invisibly to
the rest of the system (provided the
methods are adapted correctly).

Fig. 2: Functionblock with methods.

Language feature: Methods

What is still missing to make a class construct out of IECs functionblocks is of course a method construct for the implementation of the objects behaviour. Methods in CoDeSys V3 may be
seen as a hybrid of an IEC-action inside a functionblock and of
an IEC-FUNCTION with result type, parameters and local variables. All IEC languages allowed for functions can be used for the
implementation of methods (although in the following code
samples, the implementation language is always ST).
The screenshot (fig. 2) shows
 a program with two PUMP instances and the call of the Start
method on them
 the PUMP functionblock declaring its
instances internal variables
 the definition of the two PUMP-methods Start and GetState

classes (superclasses). The commonality of two different specialized classes like CANDRIVE and ANALOGDRIVE can be
factored out into a new common superclass DRIVE.
Advantage: By declaring a classs superclasses, the multitude of the types of different objects in the system is brought
to order. For general superclasses like DRIVE, without
instances by themselves (abstract superclasses), the states
representation and the behaviours implementation does
not need to be defined; it suffices to declare the objects
state and behaviour interface.

2.3 Subclassing
(Class = Specialisation and/
or Generalisation)
Subclassing finally is the highlight of
object-oriented programming. It is an
original, new feature without comparison in procedural programming. There
are three aspects to it:
 class hierarchy
 class inheritance
 subclass polymorphism

2.3.1 Class hierarchy

Classes can be arranged into a hierarchy by subordinating more special
classes (subclasses) under more general

Fig. 3: Implementation of an interface.

www.atp-international.de atp international 2.2007

61

Engineering Embedded Systems

Language feature: Interfaces
For the declaration of abstract superclasses, the interface construct was
introduced as a new variant of the POU
construct. An interface is similar to a
functionblock, with subordinate methods and properties. The difference is:
the functionblock, the methods and
the properties have no implementation part and declare no local variables.
Language feature: Extends and
Implements
Subclass relationships are declared by
the keywords EXTENDS and IMPLEMENTS in a functionblock or interface
declaration part:
 EXTENDS in a functionblock makes it
the subclass of one other functionblock.
 EXTENDS in an interface makes it the Fig. 4: Inheritance.
subclass of one or more other interfaces.
 IMPLEMENTS in a functionblock makes it the subclass of
one or more interfaces.
An IMPLEMENTS declaration requires that the functionblock has at least all the methods and properties which the
named interfaces have (with the same parameter and result
types). The new thing is that in the functionsblock, the methods and properties now must also have an implementation
part!
The following screenshot shows the CANDrive implementation of the IDRIVE interface. It implements the IDRIVEs Homemethod by CAN-messages. Note the CAN-specific variables
declared the CANDrive functionblock and the additional, CANspecific methods MoveAbsolute and SetCANId. An AnlogDriveimplementation of IDRIVE, with the specifics of analog drives,
could similarly be defined (not shown).

2.3.2 Class inheritance

A subclass inherits the interface, state representation and
behaviour implementation from its superclasses and can
complete or selectively adapt it.
Advantage: Reuse of declarations and code.
Language feature: Inheritance
If a functionblock is declared to extend another one, this
implies that it inherits the all variables and methods from
that one. On top of these, the sub-functionblock can of
course define its own, additional variables and methods.
The following screenshot shows a MonitoredPump subclass
derived from the PUMP superclass
 by inheriting its variables (Enabled and Dir) and method
(Start, GetState), and
 by extending it with a MonitoredPump-specific HasError
method.

62

2.3.3 Subclass polymorphism

Instances of subclasses like CANDRIVE and ANALOGDRIVE
are also instances of their superclass IDRIVE. This means,
CANDRIVE and ANALOGDRIVE instances can be assigned to
variables and parameters of type IDRIVE. When a method
Start is called on a CANDRIVE object through the IDRIVE
variable, the notion of methods as part of the object then
ensures that it is still the CANDRIVE version of Start which
will be executed (dynamic binding).
Advantage: One can write code against the interface the
general class DRIVE that works uniformly for instances of all
its subclasses (CANDRIVE, ANALOGDRIVE, etc.). Where different behaviour is necessary for different cases of drives, the
differences can now be defined as a method in the different
ICASE implementations. This allows to get rid of a typical
procedural programming maintenance problem: A program
with CASE statements over all possible types of drives scattered throughout the code.
Language feature: Reference semantics for interface
types
Polymorphism in CoDeSys V3 works only with interface.
(Assignment to a variable of a functionblock supertype cannot create a polymorphic superclass access to subclass
object, since each variable of a functionblock type is a new
functionblock instance):
Like a functionblock name, the name of an interface can
be used as a type name in the declaration of variables
(directly or as the basetype of an array). These declarations
have reference semantics. That means, by this declaration we
do not get a new object but only a new reference to a functionblock-instance declared elsewhere (initially NULL). The
assignment of a functionblock instance to an interface variable makes that variable refer to the functionblock instance.
atp international 2.2007 www.atp-international.de

Engineering Embedded Systems

Tab. 2: Comparsion of languages.
Language feature
Multi-lingual
Multi-paradigm
Classes

IEC

CoDeSys v3

C++

Java

C#

~ (FBs)

Methods

~ (actions)

Interfaces

Dynamic binding

+/-

+/-

Implicit reference semantics

+ (Interfaces)

Constructor / destructor

Properties

Dynamic allocation (new)

~ (variables)

~ (variables)

Access control
Partially abstract classes





Fig. 5: Polymorphic
function.

3. Conclusion
C

Eve the small examples above

Even
should have been able to demonsho
+
+
stra
strate some of the advantages of
object-oriented programming:
obj
Better structured program code with separation of concerns and information hiding
flexible extensibility by new types of objects (e.g. software representations of new types of drives),
reuse of code for defining specialized subclasses (inheritance)
reuse of code operating on different implementations of
an interface (polymorphism)
+

T screenshots show
The
t
 the
declaration of an array of
i
instances
of the interface IDRIVE
t
 the
arrays initialization with
i
instances
of different functionblocks
implementing IDRIVE (see
b
next
n feature)
 the
t uniform processing of all these
functionblock
instances by a FORf
loop
over the array
l

It has been shown that all the essential features of standard object-oriented programming are included in CoDeSys
V3. A summary comparison with C++, Java and C# is given in
table 2.
Three more auxiliary features are included in CoDeSys V3,
that we were not able to discuss here for space reasons:
 constructor and destructor methods (FB_Init, FB_Exit)
 THIS and SUPER in methods
 properties (as in C#)
Four common features of object-oriented languages were
not included in CoDeSys V3 in order to keep the OOP extension small and simple:
 dynamic allocation (keyword new)
 fine-grained access control for variables and methods
(private, protected, internal, public)
 partially abstract classes with abstract methods (abstract)
 optional dynamic binding (virtual)

Fig. 6: Polymorphic array loop.

The screenshot shows a classical functionblock with an

IDRIVE input D that uses the methods Home and MoveAbsolute of the IDRIVE interface. It can be called with instances
of both the CANDrive and the AnalogDrive functionblock
and will do the same on both of them. Of course, the code
executed when Home and MoveAbsolute are called, will
depend on what functionblock instance the input D refers
to.
www.atp-international.de atp international 2.2007

Dr. Ulf Schnemann (Ph. D. Computer Science, 37)

continued his studies at the St. Johns University
New Foundland / Canada after his degree in Computer Sciences at the Munich Technical University. Postdoctoral 2005 he started working in the product
development at 3S-Smart Software Solutions GmbH.
Today he responsibly develops programming software for safety controllers.
Address: 3S-Smart Software Solutions GmbH, Memminger Str. 151, DE-87439 Kempten, phone +49-83154031-17, fax -50, e-mail: u.schuenemann@3s-software.com

63