Planer von industriellen Anlagen benötigen heute eine Vielzahl spezialisierter Werkzeuge, welche die En­gineering-Arbeit der Experten aus den Fachbereichen Mechanik, Elektrik und Software unterstützen. Damit der Gesamtprozess des parallelen Engineer­ings funktioniert, ist eine effektive und effiziente Zusammenarbeit der Tools  erforderlich. So kann eine vom Maschinenbauer vorgenommene Typänderung eines Füllstandsensors beispielsweise weitere Änderungen bei der Verkabelung durch den Elektriker und bei der Kontroll-Logik durch den Experten für die Automatisierungs-Software notwendig machen. Allerdings arbeiten die speziellen Software-Werkzeuge sowohl auf einer technischen als auch einer semantischen Ebene in den meisten Fällen nicht nahtlos zusammen, sodass eine effektive und effiziente Erkennung, Verteilung und statistische Auswertung von Planungsänderungen kaum möglich ist.

In vielen Fällen sind die Anlagenplaner daher bis dato auf Behelfslösungen lokaler Experten angewiesen, um einen Datenaustausch und Funktionsaufrufe zu ermöglichen beziehungsweise die Lücken zwischen Werkzeuginseln mehr oder weniger gut zu schließen. Eine besondere Herausforderung ist dabei die in den Software-Werkzeugen unterschiedliche Repräsentation gemeinsamer Konzepte der Fachexperten auf Projektebene – zum Beispiel was Signale betrifft. Diese unterschiedlichen Repräsentationen erfordern wiederum aufwendige Datentransformationen – oft mit Hilfe von Excel Arbeitsmappen, Datenbanken oder Transformationsprogrammen.

Ziel moderner Engineering-Ansätze ist die systematische Ablösung von Behelfslösungen: Über abgeschlossene Werkzeug-Suiten (Werkzeugkasten) oder über Mechanismen zur Integration der für die Aufgabenstellung jeweils am bestgeeigneten Werkzeuge.

© Technische Universität Wien

Zurzeit sind zwei Trends zu beobachten, um diese Behelfslösungen systematisch und über Projekt- und Unternehmensgrenzen hinweg abzulösen: Einer davon ist der Einsatz von Werkzeug-Suiten, die alle relevanten Software-Funktionen beinhalten und durch eine gemeinsame Datenbasis homogene Sichten aller beteiligten Fachbereiche auf die gemeinsame Planung ermöglichen sollen. Beispiele hierfür sind etwa das TIA Portal von Siemens, das Eplan Engineering Center oder auch Comos von Siemens.

Die Entscheidung für eine Werkzeug-Suite ist dann sinnvoll, wenn diese Suite alle für das Projekt wesentlichen Technologien allein abdeckt und die strategischen Nachteile – etwa die Festlegung auf einen einzigen Anbieter – nicht gravierend erscheinen. In vielen Fällen ergibt sich allerdings der Bedarf, zusätzlich zu einer Werkzeug-Suite weitere Werkzeuge oder gar zusätzliche Werkzeug-Suiten zu verwenden. Hinzu kommt, dass vielfach externe Projektpartner wie Kunden oder Berater außerhalb der Engineering-Umgebung des Projekts immer wieder Änderungen an Planungsdaten durchführen. Das Einpflegen dieser externen Änderungen, die oft über Excel ausgetauscht werden, ist aufwendig und fehleranfällig, da die gängigen Software-Werkzeuge für die Änderungsanalyse kaum Unterstützung anbieten. Nicht zuletzt ist bei Werkzeug-Suiten eine schrittweise Migration von bestehenden Integrationslösungen zur Werkzeug-Suite nur schwer möglich und erfordert eine Art „Big-Bang“-Migrationsstrategie mit hohen Risiken, Aufwänden, Kosten und dem möglichen Verlust an angesammeltem Engineer­ing-Wissen.

Die 5 Kernanforderungen an Integrationsmechanismen

End-to-End-Test zwischen Sensor und Software-Variable als Beispiel für automatisierte und disziplin­übergreifende Qualitätssicherung.

© Technische Universität Wien

Will man diese Nachteile nicht in Kauf nehmen und seine unterschiedlichen Arbeitsabläufe stattdessen mit den dafür am besten geeigneten Werkzeugen automatisieren, kommt man um spezielle Integrationsmechanismen nicht umhin, die das Engineering in heterogenen Software-Landschaften effektiv und effizient unterstützen. Dabei lassen sich fünf Kernbedarfe identifizieren, denen die Integrationsmechanismen Rechnung tragen müssen:

1. Eine offene Schnittstelle zum Werkzeug, die ein Exportieren von anwenderspezifischen Attributen über Planungsdaten in ein nicht proprietäres Datenformat ermöglicht. Diese Schnittstelle muss in der Lage sein, Planungsdaten in standardisierten Formaten zu importieren.
2. Effizienter und qualitätsgesicherter Import externer Daten. Das Erkennen von Änderungen externer Projektpartner soll auch unabhängig von der Projektdatenbasis möglich sein, sodass nur erwünschte Änderungen ins Projekt übernommen werden. Zudem soll das Erkennen und Auflösen von Konflikten, die aufgrund zwischenzeitlicher Änderungen der Projektdatenbasis entstehen, effektiv realisierbar sein, um Fehler frühzeitig zu erkennen.
3. Die Datenintegration auf Projekt­ebene, das heißt zwischen allen an einem Projekt beteiligten Werkzeugen, erfordert die Transformation zwischen den heterogenen Konzepten der einzelnen Werkzeuge. Die Versionierung der ausgetauschten Daten von allen Werkzeugen, die an der Integrationslösung beteiligt sind, und die Möglichkeit, Abfragen auf Basis gemeinsamer Konzepte (zum Beispiel gemeinsames Signal-Konzept, welches in Elektroplanungs-, SPS-Programmier- und Hardware-Konfigurationswerkzeugen Verwendung findet) über die versionierten Daten vorzunehmen, sollen dabei helfen, Risiken für das Projekt frühzeitig zu erkennen und eine durchgängige Sichtbarkeit des Projektstandes zu gewährleisten.
4. Offene Funktionsschnittstelle. Automatisierte Abläufe erfordern die Möglichkeit, relevante Werkzeugfunktionen von außen anzusteuern, um manuelle Aufwände zu reduzieren und so den Grad an Automatisierung der Integrationslösung zu maximieren.
5. Unterstützung von Arbeitsabläufen auf Projektebene. Anlagenplaner sollen in der Lage sein, die Integra­tionslösung an Hand etablierter Arbeitsabläufe optimal auf Projektbedürfnisse einzustellen. Das Erkennen und Verteilen von Planungsänderungen im Anlagen-Engineering soll am Arbeitsablauf des Anlagenplaners orientiert, effizient und robust sein. Die Verknüpfung von Projektinformationen und Planungsdaten soll die Projektqualität erhöhen sowie die Koordination und das Management von Projekten verbessern.

Der ASB - eine Weiterentwicklung aus der Informatik

Diese fünf Kernbedarfe vor Augen, haben es sich die Forscher des Christian Doppler Labors an der TU Wien in Kooperation mit dem Industriepartner logi.cals zur Aufgabe gemacht, das existierende „Engineering Polynesien“ systematisch zu integrieren. Herausgekommen ist dabei der so genannte „Automation Service Bus“. Dabei handelt es sich um eine Weiterentwicklung des in der Informatik erfolgreichen Ansatzes „Enterprise Service Bus“ (ESB). Darunter versteht man einen Architekturstil für Integrationslösungen, der die Kommunikation über einen gemeinsam genutzten Kommunikationsbus einer Vielzahl von Punkt-Zu-Punkt-Verbindungen zwischen Anbietern und Nutzern von Softwareservices vorzieht.

In Analogie dazu ist der Automation Service Bus – kurz ASB – vereinfacht gesagt als eine Integrationsapplikation zu sehen, welche dazu dient, Daten und Funktionen von Software-Werkzeugen der Automatisierungsdomäne zusammenzuführen. Die Kommunikationsverbindung zwischen einem Werkzeug – also einer spezifischen Software – und dem ASB stellen Konnektoren her. Ein solcher Konnektor besteht aus einer werkzeugspezifischen Schnittstelle und einer werkzeugneutralen Schnittstelle, der sogenannten Werkzeugdomäne. Dieses Konzept fasst Eigenschaften von Werkzeugen mit ähnlicher Funktionalität oder Zielsetzung zusammen und abstrahiert gemeinsame Funktionen über eine werkzeugunabhängige Schnittstelle. Dies entspricht einer Standardisierung von Konnektoren zu Werkzeug­typen und ermöglicht den Wechsel von Werkzeugversionen mit minimalen Auswirkungen auf das Zusammenspiel mit anderen Teilen der Integrations­lösung. Der Entwurf erlaubt zudem sowohl den Einsatz von für das Projekt besonders gut passenden und für Fachexperten gewohnten Werkzeugen als auch eine werkzeugunabhängige Beschreibung von Arbeitsabläufen.

Unterstützung des direkten Imports und Exports (inklusive Änderungsanalyse) von Informationen aus MS Excel zur einfacheren Integration des ASB in bestehende Engineering-Prozesse mit Hilfe des „Engineering Object Editors“.

© Technische Universität Wien

Konnektoren stellen zwar eine Kommunikationsverbindung zwischen einem Werkzeug und dem ASB bereit; darüber hinaus ist allerdings die Bereitstellung von Daten, die von unterschiedlichen Projektteilnehmern bearbeitet werden, ein essentieller Bestandteil einer effizienten Integrationslösung. Die „Engineering Knowledge Base“ repräsentiert die semantisch einheitliche Darstellung dieser gemeinsamen Konzepte auf Projektebene. Die EKB benutzt Ontologien als zugrundeliegende Datenmodelle. Auf diese Weise stehen die lokalen Repräsentationen der Werkzeuge, die von den Fachexperten für die Kooperation benutzten gemeinsamen Konzepte sowie die Abbildungen der einzelnen Konzepte zwischen diesen Modellen in einer expliziten und maschinenverständlichen Form zur Verfügung. Dadurch ist eine automatisierte Übersetzung zwischen den unterschiedlichen Darstellungen gegeben und Abfragen können von Fachexperten auf Basis des gemeinsamen Konzepts formuliert, gestellt beziehungsweise ausgeführt werden.

Eine weitere zentrale Komponente des ASB ist die „Engineering Data Base“ (EDB): Dabei handelt es sich um eine Datenbank, welche die Datenbeiträge aus allen relevanten Werkzeugen versioniert für den Datenaustausch und für Abfragen zur Verfügung stellt. Dadurch wird es möglich, jeglichen Datenzustand zu einem bestimmten Zeitpunkt zu reproduzieren und zeitliche Analysen über System-Ereignisse durchzuführen.
Ein „Engineering Workflow“ beschreibt eine konfigurierbare Sequenz an Prozessschritten, die zuvor zum Beispiel mittels einer Prozessbeschreibungssprache modelliert und in die ASB-Umgebung transformiert worden sind. Als projektspezifische Integrationslösung ist die in den ASB integrierte „Workflow En­gine“ für die Verwaltung von Regeln und Ereignissen und für die Ausführung der definierten Arbeitsabläufe verantwortlich. Die Konfiguration der Arbeitsschritte basiert auf den in der EKB definierten Modellen der für die Ausführung notwendigen Werkzeug-Domänen beziehungsweise Werkzeug-Instanzen.

Das „Engineering Cockpit“ stellt schließlich eine konkrete Anwendung auf Projektebene dar, welche die zuvor beschriebenen Konzepte verwendet. Es versteht sich als Kollaborationsplattform für Projektmanager und Ingenieure und kann über Abfragen, die auf Grundlage der EKB definiert worden sind, Informationen über den Projektfortschritt, absehbare Risiken oder Unterlagen für das Nachforderungsmanagement über alle projektrelevanten Werkzeuge hinweg ohne zusätzlichen Aufwand bereitstellen.

Der ASB in der Praxis

Typisches Szenario für die Integration von Software-Werkzeugen mittels ASB: Der ASB wird zum Datenaustausch zwischen einer Reihe von Software-Werkzeugen (siehe 1) genutzt. Zudem bietet der ASB viele Zusatzmöglichkeiten (siehe 2 bis 4).

© Technische Universität Wien

Soviel zur Theorie. Wie kann nun ein Maschinen- oder Anlagenbauer den Automation Service Bus in der Praxis anwenden? Der ASB ist eine auf einem Server in einer Java-VM-Umgebung laufende Applikation, die der Anwender zur Verwendung im Projekt entsprechend der folgenden Prozessschritte noch konfigurieren muss: Im ersten Schritt beschreiben die Werkzeug-Experten in der EKB die Datenmodelle für die jeweiligen im Projekt verwendeten Werkzeuge und das Datenmodell der zugehörigen Werkzeug-Domäne. Das Ergebnis sind in der EKB gespeicherte semantische Beschreibungen der Modelle und Abbildungen zwischen den Datenmodellen. Im nächsten Schritt werden die im Projekt notwendigen Arbeitsprozesse zum Beispiel in der BPMN (Business Process Modeling Notation) beschrieben, mit den zu verwendenden Werkzeug-Domänen verknüpft und in die Workflow-Engine geladen.

Im darauffolgenden Schritt erfolgt die konkrete Umsetzung der Integration. Die erfassten Modelle und Arbeitsabläufe werden dazu verwendet, um erstens halbautomatisiert Vorlagen für Werkzeug-Konnektoren zu erstellen, zweitens konkrete Schnittstellen und Funktionsaufrufe der Werkzeug-Domänen zu erstellen und drittens Transformations-Instruktionen zwischen Datenmodellen abzuleiten, um zwischen Werkzeugen Daten semantisch korrekt austauschen zu können. Für die Werkzeug-Experten ist es dann noch notwendig, die abgeleiteten Vorlagen zu den Werkzeug-Konnektoren so zu erweitern, dass sie als Plug-ins in den jeweiligen Werkzeugen einsetzbar sind.

Die verwendeten Technologien

Die unterste Schicht der Architektur des „Automation Service Bus“ bildet die „Java Virtual Machine“ (JVM). Diese abstrahiert betriebssystemspezifische Aspekte von der Implementierung und erlaubt es so, zahlreiche Plattformen zu unterstützen. Um eine modulare, erweiterbare und komponentenorientierte Entwicklung zu ermöglichen wird die Spezifikation der „Open Services Gateway Initiative“ (OSGi) als Basis der ASB-Architektur verwendet. OSGi ermöglicht das Installieren und Austauschen von Software-Komponenten zur Laufzeit und lässt diese über eine Service-orientierte Architektur interagieren. Als konkrete Implementierung der OSGi-Spezifikation kommt „Apache Felix“ zum Einsatz.

Auf Basis von OSGi operiert „Apache Karaf“ als ein Management-Werkzeug, um die Verwaltung von Software-Komponenten in Apache Felix zu vereinfachen. Dazu kombiniert Apache Karaf Software-Komponenten aus zahlreichen anderen Projekten, um häufig benötigte Funktionen bereitzustellen. Auf Basis der JLine-Java-Bibliothek steht eine dynamische und benutzerfreundliche Konsole zur Verfügung, sodass Administratoren mit dem ASB kommunizieren können. Mit pax-url können Software-Komponenten aus externen Quellen bedarfsgerecht einfach nachinstalliert werden. Dies ermöglicht das effektive Nachladen von neu erstellten Werkzeug-Konnektoren. Pax Web dient als Implementierung des in OSGi spezifizierten http-Service, um über eine Browser-Schnittstelle mit dem ASB in Verbindung treten zu können. Mit der Apache-Aries-Bibliothek werden dem ASB Enterprise-Features bereitgestellt. Neben der „Java Management Extension“ zur Verwaltung und Überwachung von Java-Anwendungen gehören dazu Implementierungen von anderen relevanten Java-Standards wie der „Java Persistence API“ (JPA) oder des „Java Naming and Directory Interfaces“ (JNDI).

Für die Verteilung existieren momentan eine Web-Service- sowie eine Java-Messaging-Service-Schnittstelle (JMS). Web-Services stellen den Standard für Service-orientierte Architekturen dar und sind einfach in Kombination mit anderen WS-Standards einsetzbar. Die JMS-Schnittstelle bietet den Vorteil einer einfacheren Zweiwege-Kommunikation. Client-Applikationen sind so leichter und transparenter integrierbar als Komponenten. Die Schnittstelle basiert auf der nachrichtenbasierten Middleware ActiveMQ, welche auch in Enterprise-Service-Bus-Implementierungen verwendet wird.

Zur Bereitstellung einer modularen grafischen Web-Benutzeroberfläche dient Apache Wicket, die mit Hilfe der OSGi-Erweiterung PaxWicket mit OSGi-Spezifikationen wie Blueprint verbunden wird. Außerdem wird dadurch die Möglichkeit geboten, einzelne Seiten oder Teile von Seiten als Service anzubieten, die von anderen Komponenten dynamisch eingebunden werden können. Die Administrationsoberfläche des ASB ist basierend auf diesem Konzept modular aufgebaut, sodass alle Komponenten auch in eigenen spezifisch angepassten User Interfaces direkt eingebunden werden können.

Autoren: Prof. Dr. Stefan Biffl leitet das Christian-Doppler-Forschungslabor „Software Engineering Integration für flexible Automatisierungssysteme“.

Mag. Dr. Richard Mordinyi ist Postdoc am Christian Doppler-Forschungslabor „Software Engineering Integration für flexible Automatisierungssysteme“ der TU Wien.

Dr. Thomas Moser ist Postdoc am Christian Doppler Forschungslabor „Software Engineering Integration für flexible Automatisierungssysteme“ der TU Wien.