Objektorientierung mit Siemens TIA

Seit den 70er Jahren hat die Informatik eine gewaltige Entwicklung durchgemacht. Für die immer grösseren und komplexeren Systeme benötigte man skalierbare Konzepte. Eine der fruchtbarsten Ideen ist die Objektorientierung (kurz OO). Die Idee ist einfach: Was in der Realität ein eigenständiges Objekt ist, wird auch in der Software als Objekt abgebildet. Jedes Objekt hat eine Aufgabe, welche es selbständig erledigt. Kann es die Aufgabe nicht alleine bewältigen, schickt es Nachrichten an andere Objekte, damit diese einen Teil der Aufgabe übernehmen. Durch die Trennung von interner Objekt-Struktur und öffentlicher Nachrichten-Schnittstelle erreicht man eine maximale Entkopplung der Teilsysteme und damit Änderbarkeit und Erweiterbarkeit der gesamten Software.

Die interne Objekt-Struktur wird in einer sogenannten Klasse definiert. Die öffentliche Nachrichten-Schnittstelle nennt man englisch Interface. Für den Benutzer des Interface ist die interne Struktur völlig egal: Hauptsache, das Objekt reagiert wie abgemacht auf die Nachricht. Dasselbe Interface kann deshalb von ganz unterschiedlichen Klassen realisiert werden (Polymorphie). Es ist sogar möglich, die Benutzung einer Schnittstelle zu programmieren, bevor die realisierende Klasse überhaupt entsteht (späte Bindung, englisch: late binding).

Sie werden sich zurecht fragen, weshalb die Objektorientierung nicht längst in die Norm IEC 1131 Einzug gehalten hat. Nun das hat sie: In der Version von 2013 sind objektorientierte Ansätze enthalten. Beckhoff und Sigmatek haben dies teilweise umgesetzt. Von Siemens gibt es offiziell noch nicht einmal einen Umsetzungsplan. Die Frage sei erlaubt, wie lange sich die Kundschaft noch veraltete Technologie verkaufen lässt.

Nun, in der Zwischenzeit müssen wir uns mit dem begnügen, was uns Siemens' Totally Integrated Automation (TIA) bietet:

• Globale Funktionen FC
• Funktionsblöcke FB (diese entsprechen Klassen mit einer einzigen Methode, welche gleich heisst wie die Klasse)
• Benutzerdefinierte Datentypen UDT (benannte Strukturen)
• keine Namensräume
• kein Zugriff auf Konstanten von FB und FC

Im Prinzip könnte man ganz auf den Funktionsbaustein FB Motor verzichten und nur mit Funktionen FC und benutzerdefinierten Datentypen UDT arbeiten. Damit würde der Unterschied zwischen öffentlichen und privaten Methoden hinfällig. Da Siemens S7-Programmierer gemäss Programmierstyleguide [3] nicht auf Instanzen von Funktionsbaustein zugreifen sollten, bietet die präsentierte Lösung aber immerhin einen psychologischen Schutz der privaten Member-Variablen.

Das Interface Machine wird in einem Datenbaustein MachineDB instanziiert, damit es für einen Benutzer UserX direkt zugreifbar ist. Alternativ kann es einem Benutzer UserY auch als Parameter-Instanz übergeben werden. Der Eigentümer Owner instanziiert ein oder mehrere Objekte von MachineTypeA als Multi-Instanz und übergibt das Interface Machine der Instanz beim Aufruf.

Man beachte, dass die beiden Methoden run() und halt() asynchron aufgerufen werden. Um dies zu verdeutlichen, wird das execute-done-Muster gemäss PLCopen Compliant Library Guideline [4] mit execute, done, aborted und error Flags implementiert. Die Gruppierung in einer (eigentlich namenlosen) Struktur MachineCmd soll zeigen, dass es sich um die Implementation einer einzigen Methode handelt. In dieser Struktur könnten natürlich auch Methoden-Parameter übergeben werden. Wer welches Flag schreiben darf, lässt sich leider nicht programmatisch abbilden und muss als Konvention festgelegt werden.

In den Mickey Mouse Beispielen von oben sieht das Ganze ziemlich überrissen aus. Den praktischen Nutzen erkennt man erst in einer echten Anwendung. Um Test Driven Development (TDD) auch auf Siemens Steuerungen zu ermöglichen, haben wir eine ans JUnit-Framework angelehnte Test-Bibliothek LibTest entwickelt.

Um die Klasse MyClass zu testen, wird eine Testklasse MyClassTest angelegt. Diese benützt eine oder mehrere Test-Methoden, um das tatsächliche Verhalten von MyClass mit der Spezifikation zu vergleichen. Genauer: Im Test Driven Development ist der Test ein Teil der Spezifikation!

Die Methode testComplexBehaviour ist als Funktions-Objekt modelliert, weil das Verhalten des getesteten Objekts in einem zyklischen System normalerweise nicht in einem Schritt überprüft werden kann. Alle Testfälle MyClass_testXY implementieren das Interface TestCase.

Da alle Tests nach demselben Muster ablaufen, ist der Grossteil der Arbeit in die Klasse TestBase ausgelagert. Ein konkreter Test MyClassTest kann aber die Methoden beforeAll(), beforeEach(), afterEach() und afterAll() überschreiben, um die Test-Umgebung vorzubereiten respektive wieder aufzuräumen. Gegen aussen ist nur das Interface Test sichtbar.

Test-Suite und Logging wurden der Übersichtlichkeit halber weggelassen.

Objektorientierte Analyse und Design sind aus der Software-Entwicklung nicht mehr wegzudenken, zu gross sind die Vorteile. Die objektbasierte Umsetzung kann mit Siemens TIA auch ohne hässliche Konstrukte wie Variants gelingen, wenn man sich auf die wesentlichen Konzepte der Objektorientierung beschränkt. Sobald Siemens die fehlenden Sprachkonstrukte (Namensräume, öffentliche Konstanten, Klassen und Methoden, Vererbung) nachliefert, kann die hier vorgestellte Lösung relativ schmerzlos angepasst werden, weil das Analyse-Modell unverändert bleibt.

Wenn Sie einen eingefleischten SPS-Programmierer zum Thema Objektorientierung befragen, wird er vermutlich immer noch sagen: «Kennen wir nicht, haben wir nicht, brauchen wir nicht.» Wir müssen uns aber bewusst sein, dass dies eine aussterbende Spezies ist. Sie sind gefragt für die Wartung bestehender Systeme, aber die jungen Leute scharen sich an Automatisierungs­messen um innovative Firmen, welche den Mut weg von klassischer SPS-Programmierung in Richtung Objektorientierung haben.