Die Realisierung von immer mehr Maschinen- und Anlagen-Funktionen erfolgt heute durch Software. Als Folge werden Steuerungsapplikationen immer komplexer und effiziente Entwurfsmethoden sowie Maßnahmen zur Qualitätssicherung gewinnen enorm an Bedeutung. Mit der nächsten Version der IEC 61131-3 zur Steuerungsprogrammierung, deren endgültige Verabschiedung zum Beginn des Jahres 2012 geplant ist, halten dort objektorientierte Programmier-Elemente Einzug, die aus der Anwendungsentwicklung in anderen Bereichen schon heute nicht mehr wegzudenken sind. Damit stellt sich die Frage, wie diese Techniken effizient eingesetzt werden können, um die gewünschten Vorteile einer schnelleren Software-Erstellung, einer höheren Software-Qualität und einer besseren Wiederverwendbarkeit Realität werden zu lassen.

Dieser Fragestellung haben sich der Lehrstuhl für Automatisierung und Informationssysteme der TU-München und die Firma 3S-Smart-Software-Solutions  zusammen mit Steuerungsanbietern und Endanwendern aus dem Maschinen- und Anlagenbau im Rahmen eines Forschungsprojektes angenommen. Entstanden ist dabei eine auf die besonderen Anforderungen der Automatisierungstechnik abgestimmte und in die aktuelle Version V3 des Programmierwerkzeuges Codesys direkt integrierte Version der Unified Modeling Language (UML). Mit Hilfe dieser angepassten UML lässt sich objektorientierte Steuerungssoftware nach IEC 61131-3 modellbasiert und grafisch konstruieren. Dies unterstützt bei der interdisziplinären Kommunikation während des Entwicklungsprozesses und hilft komplexe Software-Projekte zu strukturieren sowie effizient zu dokumentieren. Durch integrierte Code-Generatoren können die Modelle zudem direkt auf der Steuerung ausgeführt werden. Ebenso stehen die gewohnten Mechanismen wie Online-Betrieb, Breakpoints oder auch die Versionsverwaltung praxis­tauglich zur Verfügung.

Heute wird die UML für die Systemmodellierung beziehungsweise -analyse eingesetzt. Hierbei sind die resultierenden Modelle dadurch gekennzeichnet, dass diese unvollständig, mehrdeutig und oft skizzenhaft ausgeführt sind. Sie dienen demnach in erster Linie als Diskussionsbasis und für die Dokumenta­tion bestimmter Teilaspekte oder zur Spezifikation der Systemanforderungen. Eine andere Möglichkeit der Nutzung der UML sind ausführbare Modelle. Hierbei werden die Modelle soweit ausformuliert, dass diese eine abstrakte Programmiersprache darstellen, aus der sich direkt der Anwendungscode generieren lässt.

Augenmerk auf die Software-Strukturen

Mit Hilfe von Klassendiagrammen kann die Projektstruktur von Steuerungs­applikationen grafisch entworfen beziehungsweise visualisiert werden. Zustands- und Aktivitätsdiagramme stehen als neue Programmiersprachen neben den üblichen zur Verfügung.

© TU München

Neben der Modellierung des Verhaltens an der Schnittstelle zwischen Technologie und Programmierer wurde bei der Integration von UML in Codesys ein großes Augenmerk auf die Unterstützung bei der Modellierung von Software-Strukturen gelegt. Die integrierten Klassendiagramme können objektorientierte Design-Aspekte in der Programmierumgebung grafisch darstellen. Für die Modellierung von Verhalten stehen Zustandsautomaten und Aktivitätsdiagramme zur Verfügung. Die UML-Diagramme lassen sich analog zu den existierenden IEC-61131-3-Sprachen zur grafischen Programmierung verwenden.

Diese starke Integration ermöglicht zum Beispiel das Debugging in den Diagrammen, eine unmittelbare Abbildung zwischen Code und Diagramm und die Verwendung der UML in der für den Steuerungsprogrammierer gewohnten Umgebung. Die UML-Diagramme können einerseits als reine Modellierung dienen oder sind andererseits direkt zur Code-Erzeugung im Sinne einer ausführbaren UML einsetzbar. Nicht zuletzt eignen sie sich als stets aktuelle (!) Software-Dokumentation. Nachfolgend werden die einzelnen Editoren und deren Einsatzgebiete dargestellt:

Die Klassendiagramme

Klassendiagramme stellen strukturelle Informationen und Abhängigkeiten (Referenzierung, Instanziierung, Implementierung, Vererbung, Abhängigkeit) unter anderem von Funktionsbausteinen (die in der objektorientierten IEC 61131-3 die Rolle von Klassen einnehmen) aggregiert dar.

© TU München

Ein Klassendiagramm stellt die Elemente eines objektorientierten Software-Systems mit den jeweiligen Beziehungen kompakt dar. Das heißt: Die Darstellung als Klasse stellt die ansonsten über die Projektstruktur und Textfenster verteilten Klasseninformationen in einer aggregierten Form dar und sorgt so für höhere Übersichtlichkeit. Um die Beziehungen zwischen Klassen auszudrücken, bietet das Klassendiagramm verschiedene Relationstypen an, die in Form unterschiedlicher Pfeile zwischen zwei Elementen dargestellt werden.

Ein Klassendiagramm kann automatisch synchron zur IEC-61131-3-Struktur gehalten werden. Alle Änderungen, die grafisch im Diagramm vorgenommen werden, haben einen unmittelbaren Effekt in der Programmierumgebung. Andersherum sind Änderungen in der Software-Struktur zu beliebigen Zeitpunkten mit der grafischen Darstellung synchronisierbar.

Außerdem ist das Klassendiagramm in der Lage, vorhandene Projektstrukturen (mit/ohne Objektorientierung) automatisch einzulesen und grafisch darzustellen. Damit lassen sich existierende Projekte leicht analysieren und hinsichtlich der Software-Struktur überarbeiten. Auch für die Erstellung einer Dokumentation oder für die Einarbeitung in eine fremde Steuerungsapplikation ist diese Funktion hilfreich. Nach dem Einlesen des Klassendiagramms kann der Anwender das Klassendiagramm wie gewohnt weiterverwenden.

Die Zustandsdiagramme

Beispiel für ein Zustandsdiagramm in Codesys V3: Durch Hierarchien, Zustands­gruppen und parallele Abläufe sind Steuerungsprogramme kompakt und übersichtlich strukturierbar

© TU München

Zustandsdiagramme beziehungsweise Statecharts sind im Bereich der Spezifika­tion und Programmierung von reaktiven Systemen weit verbreitet. Die in Codesys V3 verfügbaren Zustandsdiagramme sind wie jede andere IEC-61131-3-Programmiersprache verwendbar, das heißt, innerhalb des Zustandsdiagramms kann auf beliebige andere IEC-61131-3-Programmteile verwiesen werden und belie­bige IEC-61131-3-Programmteile können auf das Zustandsdiagramm verweisen.

Gegenüber der IEC-61131-3-Ablaufsprache bieten Zustandsdiagramme neben der flexibleren und kompakteren Darstellung einen erweiterten Funktionsumfang, der insbesondere die effi­ziente grafische Programmierung von Fehlerbehandlungsroutinen in Steuerungsapplikationen vereinfacht. Zustandsdiagramme erlauben die volle Kontrolle über den SPS-Zyklus und unterstützen beliebige Hierarchie-Ebenen, Gruppentransitionen und sogenannte Historienzustände, die einen einfachen Rücksprung in den Normalablauf nach einer Ausnahmebehandlung ermöglichen. Mit Zustandsdiagrammen lassen sich selbst komplexe Steuerungsanwendungen gut verständlich und kompakt programmieren.

Die Aktivitätsdiagramme

Beispielhaftes Aktivitätsdiagramm in Codesys V3: Abläufe sind für alle verständlich und eindeutig abbildbar. Mit der integrierten Code-Generierung lassen sich Aktivitätsdiagramme ausführen und direkt beobachten.

© TU München

Aktivitätsdiagramme wurden zur Unterstützung der Kommunikation zwischen Steuerungsprogrammierern und Technologieträgern konzipiert, deren Prozess-Know-how oftmals die Grundlage für Steuerungsapplikationen darstellt. Sie stellen sequenzielle und parallele Abläufe auf einfache Weise dar und bieten eine intuitive Modellierung, die von der dahinterliegenden Steuerungssoftware abstrahiert. So enthalten Aktivitätsdiagramme gegenüber der IEC-61131-3-Ablaufsprache und den Zustandsdiagrammen nur sehr wenige verschiedene Sprachelemente und ausschließlich Text, der frei von programmiersprachlichen Konstrukten ist. Dabei sind Aktivitätsdiagramme wie eine Programmiersprache verwendbar und direkt auf der Steuerung ausführbar.

Kernelement der Aktivitätsdiagramme sind Aktivitäten, die einem Prozessschritt in der Maschine/Anlage entsprechen. Typische Aktivitäten in einem Spritzgussverfahren wären zum Beispiel „Werkzeug schließen“, „Düse anfahren“, „einspritzen“, „nachdrücken“, „dosieren“, „abkühlen“. Darüber hinaus können zur Fehlerüberwachung Erwartungswerte hinsichtlich einer maximalen und minimalen Dauer der Aktivität angegeben werden sowie Reaktionen, falls diese Erwartungswerte über- beziehungsweise unterschritten werden. Aktivitätsdiagramme bieten neben dem Kontrollfluss die Möglichkeit, den Datenfluss grafisch zu modellieren. Durch so genannte „Swimlanes“ (vertikale Spalten) in Aktivitätsdiagrammen ist die Zugehörigkeit von Aktivitäten zu Instanzen der Software-Struktur darstellbar. Alle Aktivitäten, die sich innerhalb einer Swimlane befinden, beziehen sich auf die Instanz, die im Kopf der Swimlane benannt ist. Swimlanes können beliebig geschachtelt werden, um komplexe Objekt-Hierarchien zu berücksichtigen.

Das Entwicklungskonzept für Aktivitätsdiagramme sieht zwei unterschiedliche Nutzergruppen vor: Programmierer und Technologen. Der Programmierer entwickelt Bibliotheken mit Klassen und Methoden, die die steuerungstechnischen Grundfunktionen realisieren. Zusätzlich definiert er um diese Methoden der Klassen Aktivitäten, die Technologen anschließend einfach verwenden können. Der Technologe greift dabei auf die vom Programmierer definierten Aktivitätsbibliotheken zu. Er kann diese aus einer Bibliothek in das aktuelle Diagramm einfügen und durch die Verkettung und Parametrierung der einzelnen Aktivitäten den technologischen Ablauf festlegen.

Integriert statt separat – die Vorteile

Die nahtlose Integration der beschriebenen UML-Diagramme direkt in die Programmierumgebung bietet viele Vorteile gegenüber der Verwendung separater UML-Werkzeuge. Speziell das Klassendiagramm gibt eine völlig neuartige Sicht auf die Steuerungssoftware. Mit ihm können komplexe, objektorientierte Software-Strukturen kompakt und verständlich dargestellt, interaktiv entworfen und direkt dokumentiert werden.

Informationen, die ansonsten durch mühsames Durchsuchen der Projektstruktur und der jeweiligen Deklarationsteile zusammengetragen werden müssten, stellt das Klassendiagramm automatisch aggregiert und verständlich bereit. Dies steigert die Wiederverwendbarkeit, die Effizienz und letztendlich die Qualität im Software-Entwurf. Durch die Möglichkeit, vorhandene Software-Strukturen (auch solche ohne Objektorientierung) grafisch darzustellen, können vorhandene Projekte strukturiert analysiert, restrukturiert und wiederverwendet werden.
Mit Zustandsdiagrammen, die sich nahtlos in die Struktur der IEC 61131-3 einfügen, eine volle Kontrolle über das zyklische Verhalten ermöglichen und eine übersichtliche Implementierung komplexer Fehlerbehandlungsroutinen erlauben, steht dem Steuerungsprogrammierer eine weitere attraktive Programmiersprache für Steuerungen zur Verfügung.

Während Zustandsdiagramme vermehrt dafür zum Einsatz kommen, komplexes und gekapseltes Verhalten von wiederverwendbaren Klassen zu beschreiben und zu programmieren, stellen Aktivitätsdiagramme das Zusammenspiel mehrerer Klassen auf eine intuitiv verständliche Weise dar. Abläufe werden aus einer äußeren Sichtweise auf die beteiligten Klassen heraus dargestellt. Daher haben Aktivitätsdiagramme viele objektübergreifende Querbezüge in einer Software-Struktur und lassen sich auf vielfältige Weise in den Software-Engineering-Ablauf integrieren. Letztlich sind Aktivitätsdiagramme in ihrer Gestaltung und ihrem Funktionsumfang darauf ausgelegt, die disziplinübergreifende Diskussion zwischen Technologen und Programmierern zu unterstützen, ohne jedoch die Präzision einer Programmiersprache einzubüßen. Alle UML-Diagramme sind unabhängig von den objektorientierten Erweiterungen der IEC 61131-3 nutzbar. Die in Codesys V3 integrierten UML-Diagramme bieten Programmiersprachen und Darstellungsformen, die komplementär zu denen der IEC 61131-3 zu sehen sind. Auch mit Hinblick auf die kommenden Generationen von Steuerungsprogrammierern, für die UML und objektorientierte Programmierung seit langem auf dem Lehrplan steht, stellt die Integration von UML in Kombination mit Objekt­orientierung in die Steuerungsprogrammierung eine wichtige Weiterentwicklung dar.

Derzeit befinden sich die beschriebenen UML-Erweiterungen für Codesys V3 im Beta-Stadium. Die Markteinführung ist für Ende des Jahres geplant. Pa­rallel zur Weiterentwicklung der vorhandenen Editoren wird an der Integration weiterer UML-Editoren geforscht. Auch hier besteht die Motivation darin, die Entwicklungszeiten für Steuerungsprogramme zu verkürzen und deren Qualität nachhaltig zu verbessern. Konkret soll dies durch eine effiziente und intuitive Testfall-Beschreibungssprache auf Basis von UML-Sequenzdiagrammen erfolgen. Diese speziell auf die Beschreibung von Testfällen ausgerichteten UML-Sequenzdiagramme sollen sich wie das Zustands- und Aktivitätsdiagramm unmittelbar ausführen lassen. Darüber hinaus ist die Integration in eine Testfall-Ausführungsumgebung geplant, wodurch automatisierte Regressionstests auf Applikationsebene sehr einfach umsetzbar werden.

Autoren: Dieter Hess ist Mitinhaber und Geschäftsführer von 3S-Smart Software Solutions

Daniel Witsch ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Automatisierung und Informationssysteme der Technischen Universität München