Die IEC 61499 ist bereits seit einigen Jahren als fertige Norm verfügbar. Doch erst in den letzten Monaten hat sie den Schritt vom Papier in die reale Automatisierungswelt geschafft - eine wachsende Anzahl erfolgreich umgesetzter Lösungen und Projekte von Firmen wie nxtControl, TaitControl, Western Reserve Control, Isagraf oder auch Siemens mit ihrer Profinet- CBA-Interpretation zum Thema IEC 61499 unterstreichen diesen Trend.

Die IEC 61499 beschreibt verschiedene Referenzmodelle zur Realisierung von verteilten Steuerungssystemen, wobei die Norm die folgenden Punkte erfüllt:

Portabilität: Engineering-Werkzeuge können Bibliothekselemente von verschiedenen Herstellern verwenden.

Konfigurierbarkeit: Steuerungsgeräte verschiedener Hersteller können von unterschiedlichen Engineering- Werkzeugen (verschiedener Hersteller) konfiguriert beziehungsweise programmiert werden.

Interoperabilität: Steuerungsgeräte verschiedener Hersteller können bei der Ausführung unterschiedlicher, auch verteilter Applikation zusammenarbeiten.

Um jedoch komplexe Automatisierungslösungen auf der Basis der IEC 61499 mit einer Vielzahl an intelligenten Komponenten projektieren, in Betrieb nehmen und warten zu können, sind entsprechende Werkzeuge und Tools notwendig. Diese Werkzeuge sollten so gestaltet sein, dass Steuerungstechniker beziehungsweise das Wartungspersonal in allen Aufgabenbereichen entsprechend unterstützt werden. Mit anderen Worten: Diese Werkzeuge müssen integriert, übersichtlich und intuitiv bedienbar sein.

Den aktuell erhältlichen, kommerziellen Lösungen für die IEC 61499 mangelt es bis dato allerdings an umfassenden Lösungen und Implementierungen, die das Testen von Funktionsbausteinen, das Online- Monitoring und das integrierte Debugging von verteilt laufenden Steuerungsapplikationen ermöglichen.

Mit dem Ziel, eine Lösung für diese offenen Punkte zu finden, hat das auf dem Gebiet der angewandten Produktforschung tätige Unternehmen Profactor zusammen mit dem Automatisierungstechnik-Anbieter Bachmann Electronic in den letzten beiden Jahren eine entsprechende IEC-61499-kompatible Entwicklung realisiert, die auf der Open-Source-Referenzimplementierung „4DIAC - Framework for Distributed Industrial Automation and Control" basiert (siehe Seite „Die 4DIAC-Initiative").

Die testgetriebene Funktionsbaustein-Entwicklung

Ein zentrales Augenmerk des Projektes galt der testgetriebenen Funktionsbaustein- Entwicklung („agile" Entwicklung). Grundsätzlich erstellt der Programmierer bei der testgetriebenen Software-Entwicklung die jeweiligen Tests konsequent vor den zu entwickelnden Softwarekomponenten. Diese Tests sind dabei als „Grey- Box"-Tests zu sehen und nicht vergleichbar mit den klassischen White-Box-Tests, bei denen auch Kenntnisse über die innere Funktionsweise der Softwarekomponenten für die Testzwecke herangezogen werden.

Nachteilig an White-Box-Tests ist, dass hierbei nach klassischer Vorgehensweise in der Informatik - etwa nach dem Wasserfall- oder dem V-Modell - die Entwicklung der Tests parallel zum und unabhän- gig vom zu testenden System erfolgt, oder gar erst danach. Dies führt oft dazu, dass die gewünschte und erforderliche Testabdeckung nicht erzielt wird. Hinzu kommt, dass der Entwickler das zu testende System und seine Eigenheiten selbst kennt und dadurch aus Betriebsblindheit unversehens „um Fehler herum" testet.

Die Methode der testgetriebenen Entwicklung wirkt den Gründen für eine unzureichende Testabdeckung und einigen Nachteilen der White-Box-Tests entgegen. Man unterscheidet hier zwischen mehreren Stufen von Tests: Die Modul- oder auch Unit-Tests werden für die kleinsten Komponenten verwendet - im vorliegenden Fall Funktionsblöcke -, um deren Funktionalität sicherzustellen. Die darauf aufsetzenden Integrations- und Systemtests übernehmen die Überprüfung des Verhaltens der Applikationen und der Kommunikation zwischen verschiedenen Systemen.

Beim Integrationstest wird das Zusammenspiel mehrerer Funktionsbausteine getestet, während beim Systemtest das gesamte System einem Test unterzogen wird. Diese Tests sind auch ohne das Zielsystem durchführbar, etwa über die Methode „Software in the Loop" (SiL). Hierbei wird ein erstelltes Modell auf dem Entwicklungsrechner ohne Steuerung durch Simulation getestet. Im Gegensatz dazu wird bei der Methode „Hardware in the Loop" (HiL) das Gesamtsystem mit Simulationshardware getestet.

Tests müssen einfach und intuitiv spezifizierba sein

Im Automatisierungs- und Steuerungsumfeld sind sowohl das Thema der Unit-Tests als auch der Integrations-/Systemtests noch nicht sonderlich weit verbreitet. Dieser Umstand manifestiert sich in der Tatsache, dass es nur sehr wenige Methoden und Werkzeuge gibt, die ein systematisches, testbezogenes Vorgehen in der Steuerungscode-Entwicklung erlauben. Zudem kommt der Entwickler einer verteilten Applikation eher aus der Ecke der Software-Entwicklung und ist kein Applikationsingenieur.

Die Arbeitsweise des Applikationsingenieurs basiert vielmehr auf der Wechselwirkung zwischen Programmieren und Ausprobieren, begleitet von umstrittenen Mechanismen wie Online- Change, die mehr an „trail and error" und weniger an der angestrebten Vorgangsweise der konzept- und testgetriebenen Entwicklung orientiert sind.

Ganz offenkundig wird dieser Umstand bei einer neuen Norm wie der IEC 61499. Hier existieren - insbesondere auf diesem äußerst wichtigem Gebiet - kaum Arbeiten und Lösungen. Dabei bietet die IEC 61499 auf der Grundlage des Funktionsbausteinmodells mit Event- und Daten-Ein-/Ausgängen sowie deren Assoziationen eine optimale Basis für eine testgetriebene Entwicklung von Steuerungslösungen.

Dem von Profactor und Bachmann Electronic erarbeiteten Lösungsweg für IEC-61499-Unit-Tests liegt folgender Ansatz zugrunde: Der Steuerungsprogrammierer spezifiziert als erstes das Interface eines IEC-61499-Funktionsbausteins und überlegt sich dann die verschiedenen Tests. Der Unit-Test umfasst eine Spezifikation der Eingangs- und Ausgangsdaten sowie der anzustoßenden Events und der erwarteten Ergebnisse. Eine wichtige Anforderung war, dass diese Tests so einfach wie möglich und intuitiv spezifizierbar sein sollten. Daher fiel die Wahl auf eine tabellenartige beziehungsweise listenartige Darstellung, in die der Entwickler die Tests als Input-Output-Beschreibung einträgt.

Diese Zustände werden dann im Programmiersystem 4DIAC-IDE als eigene Datei gespeichert, um später auch einen automatischen Testablauf am Zielsystem durchführen zu können. Die vorliegende Lösung ist zudem so ausgelegt, dass zukünftig ebenso noch Zusatzbedingungen - zum Beispiel zeitliche Bedingungen - zu den einzelnen Zuständen und Tests angegeben werden können.

Die Offline-Test-Funktionalität

Im Anschluss an die Spezifizierung der Tests wird der jeweilige Funktionsbaustein entsprechend den Möglichkeiten der IEC 61499 programmiert. Sobald die Implementierung abgeschlossen ist, ist der jeweilige Funktionsbaustein testbar - entweder offline auf einem Entwicklungssystem (SiL) oder direkt auf der jeweiligen SPS-Steuerungsplattform (HiL). Im Unterschied zum SiL-Test erlaubt der HiL-Test dem Entwickler, Aussagen über das Laufzeitverhalten am Zielsystem zu treffen.

Weiterhin hat er die Wahlmöglichkeit, entweder nur einen Test, eine bestimmte Auswahl oder die gesamte Testreihe entweder für den SiL- oder den HiL-Test durchzuführen. Ist die gesamte Testreihe abgewickelt, werden die Ergebnisse in einem separaten Dokument für weitere Analysezwecke gespeichert.

Ein wesentlicher Vorteil der direkten Ausführung eines Tests auf der SPSSteuerungsplattform ist, dass man unmittelbar das richtige Verhalten auf dieser Plattform überprüft und keinerlei Einflüsse von der Entwicklungsplattform mit getestet werden. Darüber hinaus ist das Thema der testgetriebenen Entwicklung über Listen mit gültigen Zuständen für viele Anwender äußerst interessant, da auf diese Weise eine Validierung von mechatronischen (Teil-)Komponenten oder sogar ganzen Anlagen komfortabel durchführbar ist.

Sind nun die einzelnen IEC-61499- Funktionsbausteine einer Bibliothek entwickelt und getestet, lassen sich diese dazu verwenden, eine Steuerungsanwen-dung applikationszentriert und hardwarebeziehungsweise plattformunabhängig zu programmieren. Das heißt: Das Steuerungsprogramm wird von einer zentralen Sichtweise aus definiert und erst zu einem späteren Zeitpunkt auf die Zielplattformen verteilt. Um schon während der Entwicklung der Steuerungsapplikation Tests durchführen zu können, lässt sich nun die komplette Applikation auf dem Entwicklungssystem simulieren (SiL).

Die Offline-Simulationsfunktionalität soll den Entwickler von verteilten Steuerungsapplikationen schon frühzeitig unterstützen, Fehler in der Programmierung aufzuspüren. Auch eine iterative/agile Vorgehensweise ist möglich, das heißt, der Applikationsingenieur entwickelt Funktionsbausteine für ein bestehendes Subsystem (Subapplikation), testet diese, entwickelt ein weiteres Subsystem und testet dieses wieder. Werden nun einzelne Funktionsbausteine eines Subsystems verbessert oder weiterentwickelt, eröffnet sich mit den vorliegenden Tests eine elegante und rasche Möglichkeit, Fehler in der Implementierung zu finden.

Online-Monitoring und Debugging

Sobald die Steuerungsapplikation fertig programmiert und getestet ist, unterstützt die vorliegende Lösung den Anwender auch bei der Inbetriebnahme, und zwar über das Online-Monitoring von verteilt laufenden Steuerungsapplikationen sowie das Debugging derselben. Der Entwickler kann sich - analog zur Offline-Simulation - einzelne Werte von Daten-Ein- und -Ausgängen der Funktionsbausteine ansehen (Online-Monitoring), diese bei Bedarf verändern (Forcen) sowie Breakpoints und Conditional Breakpoints (Breakpoints mit Bedingungen) bei Event-Eingängen und Ausgängen setzen.

Um eine komfortable Bedienung des Online-Monitoring und des Debugging zu gewährleisten, wurde in die 4DIAC-IDE eine eigene Debugging-Ansicht eingeführt. Diese Ansicht umfasst die jeweilige Steuerungsapplikation mit den überwachten und geforcten Werten, eine Liste mit allen Breakpoints und den zugehörigen Bedingungen (für Conditional Breakpoints) sowie eine Watch-Liste, die alle überwachten Ein- und Ausgänge übersichtlich in einer Liste darstellt.

Sämtliche beschriebenen Funktionalitäten werden derzeit auf Basis der Open- Source-Implementierung 4DIAC als Erweiterungen implementiert. Neben der laufenden Erprobung beziehungsweise Integration in die M1-Steuerungsplattform sowie in das SolutionCenter von Bachmann Electronic unterstützt die erarbeitete Lösung die offenen Steuerungsplattformen von Siemens (Simatic Microbox PC und Simatic S7-mEC) und Beckhoff (CX-Serie, ausgestattet mit der IEC- 61499-Laufzeitumgebung FORTE der 4DIAC Initiative).

Last but not least arbeitet Profactor auch an der Integration des Testframework sowie der Monitoring- und Debugging-Funktionalität für die Embedded-Plattformen ARM7 und ARM9 von Digi, die sich ebenso für verteilte Aufgaben im Steuerungsumfeld einsetzen lassen. 

Autoren:

Gerhard Ebenhofer, Software-Engineer für verteilte Steuerungssysteme bei Profactor in Steyr-Gleink (A).

Gerold Kerbleder, Software-Entwickler für Development-Tools bei Bachmann Electronic, Feldkirch (A).

Josef Fritsche, Abteilungsleiter Software- Entwicklung bei Bachmann Electronic, Feldkirch (A).

Dr. Thomas Strasser, Senior Consultant für Advanced Automation Systems bei Profactor in Steyr-Gleink (A).

Die 4DIAC-Initiative

Die 4DIAC-Open-Source Initiative wurde im Sommer 2007 gemeinsam von der Profactor GmbH und der Technischen Universität Wien (Institut für Automatisierungs- und Regelungstechnik) ins Leben gerufen und wird von der O3neida-Organisation sowie von Bachmann Electronic unterstützt.

O3neida ist eine internationale Organisation, die sich der Förderung und Stärkung von Anwendungen mit verteilter Automatisierungstechnik verschrieben hat. Die Norm IEC 61499 ist eines der wichtigen Grundelemente dafür. Ziel der 4DIAC-Initiative ist die Entwicklung und Bereitstellung einer offenen Referenzimplementierung für verteilte Steuerungssysteme auf Basis der IEC 61499, welche die Forderungen nach Portabilität, Konfigurierbarkeit und Interoperabilität erfüllt. Hierfür stellt die 4DIAC-Initiative die folgenden zwei Projekte zur Verfügung:

• 4DIAC Runtime Environment (FORTE): Laufzeitumgebung für IEC-61499-basierte Systeme

• 4DIAC-IDE: Engineering-Werkzeug für IEC 61499, welches auf dem Eclipse-Framework aufgebaut ist

Beide Projekte werden unter der Eclipse Public License (EPL) zur freien Verfügung auf der 4DIAC-Website (http://www.fordiac.org) angeboten.