Serie Objektorientiertes Programmieren Teil 1

Go to OOP
Der logische Weg vom funktionalen zum
objektorientierten Programmieren - Teil 1
Die Beschreibung von Ablufen mit Hilfe von Programmen ist nichts Neues. Schon Grabinschriften der alten
gypter enthielten einen Programmcode, z.B. fr die Fortbewegung einer Statue. Zugegeben: Deren Pro-
grammiersprache ist weder standardisiert, noch leicht zu verstehen. Im Vergleich dazu ist es fr Program-
mierer von Industriesteuerungen ein Leichtes, ihr Anliegen zu kodieren - die funktionale Programmierung
in grafischen bzw. textuellen Sprachen der IEC61131-3 ist sauber standardisiert.

D
ennoch findet eine stetige
Weiterentwicklung der Pro-
grammierung statt - meist in
logischen Schritten, die den Workflow
bei der Applikationsprogrammierung
optimieren. Im Rahmen dieser Be-
trachtung wird Ihnen am Beispiel
einer einfachen Timer-Applikation er-
lutert, wie dabei der natrliche dann beginnen SPS-Programmierer
Weg von der funktionalen zur objekt-
orientierten Programmierung fhrt.
Der Einstieg - oder Wie wir
(fast) alle mal begonnen haben
Alle Daten in einer groen globalen
Variablen-Liste deklarieren, im Pro-
grammcode munter darauf zugreifen,
vielleicht sogar aus einem einzigen
Programmbaustein - das ist ein Pro-
grammierstil, der pragmatisch zum
Ziel fhrt und deswegen auch heute
nicht vollstndig ausgestorben ist.
Dafr spricht: Viele SPS-Applikationen
wurden so erfolgreich realisiert. Pro-
blematisch wird es, wenn Fehler in
einem solchen Programmcode ge-
sucht werden mssen, oder wenn die
Applikation angepasst werden soll.
Auch ist es mhsam, Teile des Pro-
grammcodes fr andere Applikatio-
nen wiederzuverwenden. Sptestens
schiedene Timer als Instanz einer
darber nachzudenken, wie sie Ihre
Applikation verbessern knnen.
1. Verbesserungsschritt:
Strukturierung der Daten
und deren Verwendung
Die IEC61131-3 definiert mchtige
Hilfsmittel zur Strukturierung: z.B.
Funktionen (Fun), die der Program-
mierer fr abgegrenzte Aufgaben mit
einem Rckgabe-Wert von Hauptrou-
tinen beliebig aufrufen kann. Oder
Strukturen (Struct) zum Zusammen-
fassen von Variablen. Diese Mittel
setzen erste Forderungen zur struk-
turierten Programmierung um, wie
sie der niederlndische Informatiker
Edsger Dijkstra (1930-2002) aufge-
stellt hat (Go To Statement Conside-
red Harmfulm, 1968 sowie Structu-
red Programming, 1972). Im Beispiel
unserer Aufgabe werden dazu ver-
Struktur deklariert. Darber hinaus
erfolgt die Bearbeitung mit Hilfe von
speziellen Funktionen, wie z.B. My-
ClockGetTime, MyClockSetTime, My-
ClockStartTime, MyClockStopTime.
Damit wird die Verwendung unter-
schiedlicher Timer bereits deutlich
vereinfacht, weil jeder Funktionsauf-
ruf seine eigenen Daten bergeben
bekommt bzw. zurckliefert. Aller-
dings muss die Datenbergabe mit
dem exakten Datentyp erfolgen.
Auch ist es nicht mglich, alternati-
ven Code whrend der Ausfhrung
zu verwenden.

30 SPS-Magazin Ausgabe 9/2012

 Serie Objektorientiertes Programmieren Teil 1

Bild 2: Quick-and-Dirty: Unstrukturierte Programmierung mit einer globa-

len Variablenliste, auf die der Programmcode munter zugreift.

2. Verbesserungsschritt:
Zusammenfassung von Daten und Code in
Funktionsbausteinen (FB)

Im ersten Schritt waren Daten und Code noch ohne erkennbaren

Bezug zueinander strukturiert. Mit Funktionsbausteinen nach
IEC61131-3 kann der Applikationsprogrammierer seine Daten-
struktur zusammen mit deren Ausfhrung erstellen. Die eigentli-
che Datenallokation erfolgt bei der Instanziierung eines FBs. Mit
jeder Instanz wird somit ein unabhngiger Datensatz angelegt, der
vom identischen Programmcode bearbeitet wird. Durch die De-
klaration von Eingangs- (VAR_Input) und Ausgangsvariablen
(VAR_Output) ist es mglich, auf die Daten innerhalb der Instanz
zuzugreifen. Instanzen knnen einzeln, aber auch als Arrays an-
gelegt und somit weiter strukturiert werden. Nachteil vom FB: Um
die Abarbeitung flexibel durchfhren zu knnen, sind mitunter
zahlreiche VAR_Inputs erforderlich, die wiederum dem exakten Typ
der VAR_Input-Variablen entsprechen mssen. Sollen innerhalb des
FBs alternative Programm-Sequenzen durchlaufen werden, so ist
zustzlicher Programmcode zur Verzweigung erforderlich, der
nicht zur eigentlichen Funktion gehrt.

3. Verbesserungsschritt: FBs mit Aktionen

Aktionen von FBs beseitigen einen Teil dieser Nachteile. Sie wurden
von den Vtern der IEC61131-3 zwar eigentlich fr Objekte vorge-
sehen, die in Ablaufsprache erstellt werden. Deren Erweiterung auf
alle FBs hat sich im IEC61131-3 Programmiersystem CoDeSys aber
seit vielen Jahren bewhrt: Zustzlich zu den oben beschriebenen
Standard-Eigenschaften von FBs kann die Applikation diese Aktionen
vom FB oder aber bergeordneten Bausteinen direkt aufrufen. Das
heit: Der Aktions-code wird auf den Daten der FB-Instanz ausge-
fhrt, allerdings unabhngig von anderen Aktionen oder dem Code
im Rumpf des FB. Mit den verfgbaren Aktionen knnen somit un-
terschiedliche Ausfhrungsvarianten eines Objekts definiert werden.
Mit dem Aufruf wird somit entschieden, welche Aktion und damit
welche Variante ausgefhrt werden soll. Verzweigungen fr unter-
schiedliche Aufgaben sind in der Aktion nicht mehr erforderlich. Al-
lerdings ermglichen Aktionen keine Eingangsdaten (VAR_Input).
Auch ist es nicht mglich, identischen Code innerhalb von Aktionen
fr unterschiedliche FBs zu verwenden.

4. Verbesserungsschritt: FBs mit Methoden

Methoden sind Bausteine, die so in der IEC61131-3 ursprnglich

nicht definiert waren. Wie auch Aktionen, sind Methoden nichts
anderes als Funktionen, die einem FB zugeordnet sind. Sie knnen
allerdings jetzt eigene Parameter haben, um deren Ausfhrung
noch flexibler und unabhngiger voneinander zu gestalten.

Bild 4: Das Interface IClock
wird vom FB implemen-
tiert, die Methoden des In-
terfaces werden im FB aus-
programmiert.
32
Serie Objektorientiertes Programmieren Teil 1
Bild 3: Aktionen als Kinder eines FB knnen vom Rumpf des FB sowie von auen aufge-
rufen und arbeiten auf den Daten des FB.
5. Verbesserungsschritt: FB
implementiert Interface(s)
Schon Methoden sind neue Objekte
in der IEC61131-3, deren Nutzen sich
recht einfach erschliet. Mit dem
nchsten neuen Objekt Interface be-
geben wir uns nun endgltig in die
objektorientierte Programmierung. Im
Gegensatz zu den Programmen,
Funktionsbausteinen, Funktionen, Ak-
tionen und Methoden enthalten In-
terfaces keinen Code. Wofr bentigt
man sie dann? Wie der Name schon
sagt, handelt es sich dabei um die Be-
schreibung einer Schnittstelle fr den
Aufruf von Methoden. Diese Be-
schreibung ist an einer Stelle einheit-
lich festlegt. Das bedeutet: Ein Inter-
face definiert einen Satz von Metho-
den und deren Aufrufparameter.
Dabei sind die Methoden im Interface
selbst leer - es soll ja kein Code, son-
dern nur die Schnittstelle definiert
werden. Implementiert nun ein FB ein
oder mehrere Interfaces, so mssen
alle im Interface definierten Metho-
den fr diesen FB ausprogrammiert
werden. Das hat mehrere Vorteile: Ei-
nerseits kann man durch Definition
des Interfaces die Aufrufschnittstelle
fr einen FB an einer Stelle einheitlich
definieren. Das ist insbesondere dann
interessant, wenn es mehrere unter-
schiedliche Einheiten in einer Appli-
kation gibt, die aber identisch aufge-
SPS-Magazin Ausgabe 9/2012
rufen werden. Beispiele dafr gibt es
in der Automatisierung zur Genge:
Alle Antriebe (unabhngig von Hersteller,
Busanbindung, Leistungsklasse) unterstt-
zen Funktionen wie Homing, Reset oder
Fahren auf Zielposition.
Jeder Feldbus hat Funktionen zum
Datenversand und -empfang.
Die meisten mechatronischen Einheiten
mssen per Software eingeschaltet (enab-
led) werden und liefern ein Diagnosesignal
zurck.
Mit der zentralen Definition eines In-
terfaces kann der Programmierer si-
cherstellen, dass keine Funktion fr
den FB vergessen wird. Sollte das In-
terface verndert oder erweitert wer-
den mssen, so geschieht das an
einer zentralen Stelle. Auch ber-
wacht der Compiler, dass die Imple-
mentierung z.B. einer hinzugefgten
Methode wirklich vorgenommen
wurde. Ein noch grerer Vorteil:
Durch die Implementierung von Inter-
faces in unterschiedlichen Einheiten
knnen natrlich die Implementierun-
gen der Methoden ganz individuell
erfolgen. Dennoch bleibt der Aufruf
der Methoden identisch. Moment
mal!, mag der fachkundige Leser
dieser Zeilen jetzt einwenden, Ich
muss ja die Methode als Teil einer FB-
Instanz aufrufen! Dadurch ndert sich
zwar der Methodenaufruf nicht, er
enthlt aber den Instanznamen! Die-
ser Einwand ist natrlich berechtigt.
Aber anders als beim normalen FB
kann der Zugriff nun z.B. in Arrays
auch ber die implementierte Schnitt-
stelle erfolgen. Das heit: Beim ei-
gentlichen Aufruf der Methode spielt
es keine Rolle mehr, von welcher In-
stanz und mit welcher konkreten Im-
plementierung er vorgenommen wird.
Diese Zuordnung erfolgt mit dem
Auffllen des Arrays als Feld vom Da-
tentyp Interface. Und das ist natrlich
eine extreme Vereinfachung, wenn
eine grere Menge von Methoden
hnlichen Typs, aber unterschiedlicher
konkreter Umsetzung aufgerufen
werden soll.
Weitere Schritte
Mit Interfaces und Methoden hat
man die OOP aber bei Weitem nicht
ausgereizt. Warum sollte man Metho-
den nicht in anderen FBs wiederver-
wenden? Was ist mit Eigenschaften
(Properties) von FBs? Welche weiteren
Mglichkeiten lassen sich aus dieser
Denkweise ableiten? Fortsetzung
folgt...
Fazit
Der logische Weg, der bei der Opti-
mierung des Programmierstils einge-
schlagen wurde, fhrt zur OOP - und
er lsst sich noch weitergehen, ohne
die vertraute Oberflche der
IEC61131-3 verlassen zu mssen!
Schlielich werden alle beschriebenen
Eigenschaften in der dritten Revision
der Norm bereits enthalten sein.
www.3s-software.com
Autor: Dipl. Ing. (FH) Ro-
land Wagner ist Marketing
Manager bei 3S-Smart
Software Solutions GmbH
Autor: Igor Petrov ist
Technischer Leiter bei Pro-
log in Smolesnk