Integriertes Engineering mit. Automation Service Bus

Transkript

1 hauptbeitrag Integriertes Engineering mit Automation Service Bus Paralleles Engineering mit heterogenen Werkzeugen Dieser Beitrag stellt einen neuen herstellerneutralen Ansatz zur Integration von Software- Werkzeugen vor, den Automation Service Bus. Es geht darum, wesentliche Lücken bisheriger herstellerneutraler Ansätze zu schließen und Vorteile, die sich bisher nur mit herstellerspezifischer Integration erreichen ließen, auch für die Integration heterogener Werkzeuge zu ermöglichen. SCHLAGWÖRTER Paralleles Engineering / Software-Werkzeug-Integration / Datenaustausch / Werkzeug unterstützte Arbeitsabläufe / Automation Service Bus Integrated Engineering with the Automation Service Bus Making parallel engineering with heterogeneous tools more efficient This contribution introduces a novel vendor-neutral approach for the integration of software tools, the Automation Service Bus, in order to close relevant gaps of present vendorneutral approaches and enable benefits, which were previously achieved only with vendorspecific integration, also for the integration of heterogeneous tools. KEYWORDS parallel engineering / software tool integration / data exchange / tool-supported workflows / automation service bus 888

2 Stefan Biffl, Richard Mordinyi und Thomas Moser, Technische Universität Wien Der erste Teil dieses Beitrags in atp-edition 54(5) hat den Bedarf an besserer Integration zwischen Software-Werkzeugen und deren Datenmodellen anhand exemplarischer Anwendungsfälle diskutiert. Daraus wurde der Bedarf für Mechanismen in Software-Werkzeugen abgeleitet und die Stärken und Beschränkungen von drei generellen Integrationsansätzen diskutiert: Behelfslösungen und herstellerspezifische beziehungsweise herstellerneutrale Ansätze. Das Ergebnis: Herstellerspezifische Werkzeug-Suiten decken zwar den Großteil der vorgestellten Anwendungsfälle ab, schränken allerdings typischerweise die Auswahlmöglichkeiten der verwendbaren Werkzeuge ein oder geben ein zu verwendendes Datenmodell fix vor. Herstellerneutrale Ansätze erlauben die freie Auswahl der Werkzeuge und Datenmodelle, erfordern aber oft einen erhöhten Grundaufwand für die Einbindung der Werkzeuge, da es keine offene Integrationsplattform zur Integration von Daten und Funktionen aus Software-Werkzeugen zur Unterstützung von Abläufen auf Projektebene gibt. Die AutomationML-Initiative [1] definiert zum Beispiel ein Schema für den Austausch von Topologie-, Geometrieund Verhaltensinformationen, stellt aber keine automatisierte Austauschmöglichkeit für diese Informationen zur Verfügung. Im Bereich der Wirtschaftsinformatik wurde der Architekturtrend umfangreicher Software-Werkzeug-Suiten in den 1990er Jahren etabliert und in den 2000er- Jahren durch offene, komponentenorientierte Systeme, etwa auf Basis des Enterprise-Service-Bus [2], abgelöst. Ein Beispiel für ein derartiges System ist der Automation Service Bus (ASB) Ansatz [3], ein Ergebnis der Forschung des von Logical automation solutions und services betriebenen Christian-Dopple- Forschungslabors Software Engineering Integration für flexible Automatisierungssysteme (CDL-Flex) an der Technischen Universität Wien. Der ASB schließt die Lücke zwischen den spezifischen Software-Werkzeugen der Fachexperten und den Arbeitsabläufen der Projektteilnehmer, die unter Verwendung der Daten aus mehreren Software-Werkzeugen effizient durchgeführt werden sollen, durch eine systematische und nicht-proprietäre Integration auf den Ebenen der (1) technischen Systeme und Funktionen, (2) der Datenmodelle und (3) der Beschreibung der Arbeitsabläufe. Die Integration der lokalen Datenmodelle (das Engineering Babylon ) wird adressiert, in dem genau die von den Fachexperten für die Kooperation benutzten gemeinsamen Konzepte modelliert, auf die lokalen Repräsentationen der Software-Werkzeuge abgebildet und so für Maschinen verständlich gemacht werden. In den folgenden Abschnitten beschreibt der Beitrag die Kernkomponenten des ASB, spezifiziert den Prozess zum Entwerfen einer Integrationslösung und diskutiert Vorteile, Limitierungen und den benötigten Aufwand. 1. Der Automation Service Bus Ansatz Dieser Abschnitt stellt den Automation Service Bus [3] vor und beschreibt dessen Hauptkomponenten. Ziel des Einsatzes des ASB ist das Bereitstellen einer offenen Plattform zur Integration von heterogenen Software- Werkzeugen für die Entwicklung von Automatisierungssystemen. Im Lebenszyklus der Herstellung und Operation von Automatisierungssystemen lassen sich Software- Werkzeuge und Systeme als Software-Komponenten [4] betrachten, deren Beitrag zum Entwicklungsprozess durch eine bessere Kooperation deutlich effektiver und effizienter werden kann. Basierend auf dem in der Wirtschaftsinformatik erfolgreichen Enterprise Service Bus Ansatz [2] werden dafür die für das Engineering Umfeld erforderlichen Verbesserungen wie eine herstellerneutrale Kommunikation vorgenommen, um das Engineering Polynesien der Werkzeuginseln systematisch zu integrieren (siehe Bild 1). Software-Werkzeuge sind mit dem ASB über Konnektoren verbunden und stellen an den Schnittstellen Software- Services [5] bereit, die den Datenaustausch und den Aufruf von Werkzeugfunktionen als Basis für die Automatisierung von Arbeitsabläufen im Engineering erlauben. 889

3 Hauptbeitrag Bild 1 zeigt eine vereinfachte Sicht auf eine konkrete Lösungskonfiguration mit dem ASB, die folgende Elemente beinhaltet. (1) Spezifische Werkzeuge für Fachexperten aus dem Anlagen-Engineering, etwa zur Planung von Rohrleitungs- und Instrumentenfließbildern, Funktionsplänen, Elektroplänen, Systemkonfigurationen und SPS- Kontrollprogrammen. (2) Den Service Bus mit Konnektoren zur technischen Verbindung der Software-Systeme miteinander. (3) Die Engineering-Datenbank und die Engineering-Knowledge-Base, um gemeinsam verwendete Daten auf Projektebene versioniert zu halten und zur Übersetzung von gemeinsamen Konzepten auf Projektebene, die in den Werkzeugen (in Bezug auf Begriffe oder Datenstrukturen) unterschiedlich repräsentiert sind. (4) Anwendungen auf Projektebene, die auf die integrierten Daten und Funktionen aus den Software-Werkzeugen aufbauen, etwa ein Engineering-Cockpit zur besseren Projektstatusübersicht oder ein Ticketing System zur Benachrichtigung relevanter Projektrollen. (5) Die Konfiguration von Arbeitsabläufen, die Software-Werkzeuge verwenden und über Regeln gesteuert werden. Nachfolgend wird näher auf die Kernkomponenten des ASB in Bild 1 eingegangen, die Services anbieten, die die angebundenen Werkzeuge nicht zur Verfügung stellen. 1.1 Spezifische Werkzeuge für Fachexperten Software-Werkzeuge stellen für Fachexperten Daten und Funktionen zur Planung von Anlagen in herstellerspezifischer Technologie bereit und bieten typischerweise Schnittstellen an, um auf Daten und Funktionen aus den Werkzeugen von außen zuzugreifen. Der ASB unterstützt die Anbindung von Werkzeugen auf zwei Arten. Bei der Datenintegration werden Dateninstanzen entsprechend dem Datenmodell des Werkzeugs an den ASB geschickt beziehungsweise vom ASB empfangen. Die entsprechenden Konnektoren lesen/schreiben Dateninstanzen in Dateien, die über die Werkzeug-spezifischen Datei-Export/ Import Schnittstellen verarbeitet werden können. Werkzeuge, wie Eplan Electric, Eplan Engineering Center der Hardware-Konfigurator OPM, MS Excel oder MS Visio gehören zu dieser Kategorie. Bei der Funktionsintegration werden das Datenmodell und Werkzeug-spezifische Funktionen bei der Anbindung verwendet. Dies erfordert eine Kooperation mit dem Werkzeughersteller oder Werkzeugpartner, um Werkzeug-spezifische Schnittstellen zu implementieren. Der Konnektor tauscht also mit dem Werkzeug Informationen über APIs aus, die der Werkzeughersteller bereitstellt. Daraus ergibt sich, dass die erzielbare Qualität beziehungsweise Tiefe der Anbindung vom Werkzeughersteller abhängt. Aus dem Bereich der Automatisierungssysteme wurden die Funktionsplansysteme Logicad und Logidoc angebunden, aus dem Bereich Software-Engineering-Werkzeuge wie das Ticketing-System Trac zur Sammlung und Organisation von Aufgaben, die aus dem Änderungsmanagement entstehen [7]. 1.2 Werkzeugdomänen zur Anbindung von Werkzeugen Konnektoren verbinden Werkzeuge mit dem ASB und bestehen daher aus einer technisch spezifischen Schnittstelle zum Werkzeug und einer technisch neutralen Schnittstelle, die eine Kommunikation mit allen anderen Komponenten am ASB erlaubt. Die neutrale Schnittstelle eine Werkzeugdomäne entspricht einer Standardisierung von Konnektoren zu Werkzeugtypen, etwa Hard- BILD 1: Grundlegende Elemente einer Soft ware-werkzeugintegration mit dem Automation Service Bus. BILD 2: Semantische Integration [10] heterogener Repräsentationen von Engineering...Wissen. 890

4 ware-konfiguratoren, und ermöglicht einerseits den einfachen Austausch von Werkzeugdiensten und erlaubt andererseits anwendenden Fachexperten weiterhin die gewohnte Verwendung ihrer Werkzeuge (für Details siehe [8], [9]). Eine neutrale Schnittstellenbeschreibung gestattet eine von Werkzeugen unabhängige Beschreibung von Arbeitsabläufen im Projekt und den effizienten Einsatz von für das Projekt besonders gut passenden Werkzeugen. 1.3 Engineering Knowledge Base Werkzeugdomänen vermindern die Komplexität der Integration von Werkzeuginseln. Allerdings sind Konnektoren und auch Werkzeugdomänen nicht in der Lage, semantisch heterogene Werkzeuge so an den ASB anzubinden, dass die unterschiedlichen Datenmodelle für Computer verständlich werden. Ein wesentlicher Beitrag der Integrationslösung ist daher die Bereitstellung von Daten, die unterschiedliche Projektteilnehmer bearbeiten und verwenden, sogenannten gemeinsamen Konzepten (siehe Bild 2 und Bild 3), in einheitlicher Darstellung auf Projektebene. Dieses virtuelle gemeinsame Datenmodell lässt sich dynamisch erzeugen oder an neue Projektbedürfnisse anpassten und unterscheidet sich dadurch stark von klassischen, vor Projektbeginn zu definierenden, und starren statischen Datenmodellen. Die Engineering Knowledge Base (EKB) [10] repräsentiert das Datenmodell der gemeinsamen Konzepte auf Projektebene und die Datenmodelle der unterschiedlichen lokalen Repräsentationen in den Software- Werkzeugen und erlaubt die notwendigen Transformationen zwischen den lokalen Datenmodellen. Das Engineering Babylon entsteht durch unterschiedliche lokale Repräsentationen der gemeinsamen Konzepte des Projektteams in den beteiligten Softwaresystemen und erfordert vermeidbaren Aufwand von Fachexperten für wiederkehrende Tätigkeiten, etwa Änderungskaskaden. Die EKB adressiert dieses Problem durch die Modellierung der von den Fachexperten für die Kooperation benutzten gemeinsamen Konzepte, die Modellierung der lokalen Repräsentationen der Software-Werkzeuge und die Abbildungen der einzelnen Konzepte zwischen diesen Modellen (siehe Bild 2) in einer expliziten und für Computer verständlichen Form, einer Ontologie. Dadurch wird die Übersetzung zwischen den unterschiedlichen Darstellungen automatisiert und die Fachexperten können Abfragen an die Daten auf Basis der gemeinsamen Konzepte stellen. Bild 2 zeigt die lokalen Datenmodelle von drei Fachbereichen (farbige Elipsen) und deren Überlappungsbereiche (in Weiß), die die gemeinsamen Konzepte beinhalten, etwa Anforderungen, Geräte, mechatronische Objekte oder Signale. Diese Überlappungen erlauben es, ein virtuelles gemeinsames Datenmodell zu erstellen, das die schematischen und semantischen Informationen der einzelnen Konzepte beinhaltet und eine Infrastruktur für semiautomatische Transformationen zwischen den Konzepten bereitstellt. Die werkzeugunterstützte Modellierung der Engineering Konzepte ermöglicht eine automatische Ableitung der benötigten Transformationsanweisungen. Ein guter Ansatzpunkt für das Identifizieren gemeinsamer Konzepte ist die Analyse der Schnittstellen exportierbarer Daten, die Werkzeuge anbieten, oder auch von Standards in der Domäne. Sobald die relevanten Konzepte identifiziert sind, können diese Konzepte aufeinander abgebildet werden (Bild 2) [11]. Dadurch lassen sich die Auswirkungen von parallelen Änderungen in mehreren Engineering-Plänen automatisch analysieren; dies erlaubt den Abgleich von Engineering-Modellen aus unterschiedlichen Fachbereichen in kürzeren Zyklen mit signifikant geringerem Aufwand für die Fachexperten. Das Finden von Risiken und Beheben von Fehlern kann früher stattfinden. 1.4 Engineering Database Die Engineering Database (EDB) [12] ist eine Datenbank, die zu den im vorigen Unterabschnitt beschriebenen gemeinsamen Konzepten die Datenbeiträge aus allen relevanten Werkzeugen versioniert speichert und zum Datenaustausch sowie für Abfragen zur Verfügung stellt. Dadurch wird es möglich, jeglichen Datenzustand zu einem bestimmten Zeitpunkt zu reproduzieren und zeitliche Analysen über Systemereignisse durchzuführen, zum Beispiel die Anzahl der Änderungen pro Benutzer im Gesamtprojekt. Bild 3 zeigt dazu den grundlegenden Ablauf: Die Verwendung des virtuellen Datenmodells (1), welches in der EKB explizit in Form einer Ontologie spezifiziert wurde, ermöglicht die effiziente und effektive Ableitung und Herstellung der zur Laufzeit notwendigen Transformationen (2) zwischen den ausgetauschten Werkzeugdaten. Die derartig transformierten Daten werden dann in der EDB (3) abgelegt. Ein Beispiel für eine derartige Transformation ist im unteren Teil von Bild 3 dargestellt. Hier wird die Instanz von Cust_Signal namens Cust S1 in eine Instanz von FB_Signal namens FB 1 transformiert. Die Darstellung des Inhalts der EDB zeigt, dass sich die gemeinsamen Elemente beider Konzepte am Anfang des Eintrags befinden, während am Ende des Eintrags die werkzeugspezifischen Elemente der Werkzeuge Elektroplan und Funktionsplan angehängt werden Anwendungen auf Projektebene Auf Basis der versionierten Werkzeugdaten in der EDB und der Abfragemöglichkeiten der EKB können auf Projektebene neue Auswertungs- und Kommunikationsmöglichkeiten bereitgestellt werden. Das Engineering-Cockpit [13] ist eine Kollaborationsplattform für Projektmanager und Ingenieure und kann, basierend auf der Analyse von automatisch erfassten Prozessdaten, etwa dem Projektmanager Informationen über den Projektfortschritt (siehe Bild 4), absehbare Risiken und Unterlagen für Claim Management ohne zusätzlichen Aufwand bereitstellen. Die Grundlage für eine Analyse sind die abgelegten Modelle in der EKB und die Instanzen in der EDB. Abfragen über die Daten aus mehreren Werkzeugen, etwa Signale, Planungs- oder Implementierungsstände und die Team-Konfiguration im Projekt können kombiniert werden, etwa, um zu sehen, welche Personen in einem Zeitraum welche Änderungen an den Signalen 891

5 Hauptbeitrag BILD 3: Virtuelles gemeinsames Datenmodell und Transformationen eines Engineering-Objekts durchgeführt haben. Ein Ticket-System ermöglicht die Aufgaben im Team im Überblick zu behalten, etwa Änderungsbedarfe auf Grund einer Änderungskaskade, die nicht automatisch adressiert werden können. Vorkonfigurierte Soll-Werte aus den Erfahrungen mit Projekten ähnlicher Größe können dem Projektmanager als zusätzliche Vergleichsbasis dienen, um über Abweichungen vom Soll-Wert mögliche Risiken frühzeitig zu erkennen. Bei der Qualitätssicherung im Engineering und der Inbetriebnahme einer Anlage müssen Fachexperten zwischen gemeinsamen Konzepten, etwa Signalen oder Geräten, in Plänen aus unterschiedlichen Bereichen navigieren, um die Plausibilität und Konsistenz abzusichern. Die Software-Werkzeuge der Fachbereiche vernetzen die gemeinsamen Konzepte oft nicht vollständig und effizient, sodass die Experten diese in unzureichend vernetzten Software-Plänen relativ aufwändig suchen müssen. Durch die Verbindung von gemeinsamen Konzepten können Anwender effizient zwischen unterschiedlichen Plänen und Werkzeugen navigieren und behalten dabei den Kontext, zu dem sie Informationen suchen. Das Netz an Abbildungen zwischen lokalen und gemeinsamen Konzepten in der EKB zeigt konkrete Navigationsmöglichkeiten zwischen Ausgangs- und Zielwerkzeug auf Konfiguration von Arbeitsabläufen Ein wesentlicher Nutzen des ASB ist die technologieunabhängige Beschreibung von (bestehenden) Engineering- Prozessen und deren Automatisierung, um die Fachexperten von Tätigkeiten zu entlasten, die Software-Werkzeuge übernehmen sollen. Die in den ASB integrierte Workflow-Engine unterstützt die automatisierte Ausführung von Arbeitsabläufen zwischen Werkzeugen und ist daher für das Management von Regeln und Ereignissen beziehungsweise für die korrekte Ausführung von Engineering-Workflows verantwortlich. Technisch beschreibt ein in einer Sprache wie BPMN modellierter und in die ASB-Umgebung transformierter Engineering-Workflow konfigurierbare Prozessschritte, die die gewünschte Art der Integration der einzelnen Werkzeuge im Projekt darstellen. Die vom Prozessmanager erarbeiteten und zu konfigurierenden Schritte [6] basieren auf den in der EKB beschriebenen Datenmodellen (Rollen, Verantwortlichkeiten, Gewerken, Signalen, Einschränkungen) und auf für die Ausführung relevanten Werkzeugdomänen (inklusive deren Datenmodelle und Funktionen) beziehungsweise den in der Projektkonfiguration spezifizierten konkreten Werkzeuginstanzen. Eine im ASB laufende Komponente zur Prozessanalyse sammelt während der Ausführung Informationen über die Zustände der einzelnen Prozesse, um den wirklichen Ablauf mit dem im BPMN beschriebenen Verlauf zu vergleichen und so Abweichungen vom Sollzustand zu identifizieren. Für den Anwendungsfall von Änderungskaskaden und der automatischen Notifizierung von Projektmitarbeitern über Änderungen mit Hilfe eines Ticketing-Systems ist das projektspezifische Zusammenspiel aller zuvor erwähnten Komponenten zu beschreiben, zum Beispiel: die notwendigen Iterationen für eine Überprüfung, die Art einer Änderungsanfrage, der Umgang mit parallelen Aktivitäten und mit Konflikten [7, 14]. Änderungen in einem Werkzeug können je nach Art der Anbindung entweder direkt aus dem Werkzeug heraus oder über die Export- Schnittstelle des Werkzeugs dem ASB mitgeteilt werden. Dies hat zur Folge, dass der aktuelle Datenbestand des Werkzeugs in der EDB abgelegt wird. Dieser Vorgang wird über einen Engineering-Workflow gesteuert, der durch die Versionierung der Daten in der EDB Änderungen im Datenbestand erkennt, und auf Basis der Abbildungen zwischen Datenmodellen über gemeinsame Konzepte in der EKB in der Lage ist, Werkzeuge oder deren Benutzer zu identifizieren, die über diese Änderung informiert werden sollten. Je nach Konfiguration des Ablaufs werden den identifizierten Experten über die Werkzeugdomäne Ticketing neue Tickets zugeordnet beziehungsweise die Änderungen nach Durchführung der spezifizierten Transformationsschritte entweder sofort oder nach er- 892

6 BILD 4: Auswertungen im Engineering-Cockpit etwa die Anzahl der Signale nach Projektphase. folgter Bestätigung durch die Ingenieure zum jeweiligen Werkzeug geleitet. Dadurch ist es möglich den Ablauf der Änderungskaskaden einfach und flexibel an die Bedürfnisse der Projektteilnehmer anzupassen. 2. Arbeitsschritte und Aufwand Dieser Abschnitt beschreibt die Arbeitsschritte und den Aufwand, um mit dem ASB zu einer auf Projektbedürfnisse abgestimmte Integrationslösung zu kommen. Im ersten Schritt Datenmodellierung erstellen die Werkzeugexperten die Datenmodelle für die jeweiligen im Projekt verwendeten Werkzeuge einer Werkzeugdomäne [15]. In einem weiteren Schritt definieren die Experten gemeinsam das dazu passende Datenmodell der Werkzeugdomäne. Das Resultat sind in der EKB gespeicherte semantische Beschreibungen [16] der Modelle und Abbildungen zwischen den Datenmodellen. Abschließend werden die Modelle mit qualitätssichernden Maßnahmen auf Korrektheit und Gültigkeit überprüft [17, 18]. Die in der EKB verwendete Datenmodellierungsmethode benutzt Ontologien, wodurch sich klare Vorteile ergeben in Bezug auf dynamische Erweiterbarkeit der Datenmodelle, explizite semantische Beschreibung der Datenmodelle und Unterstützung von automatisierten Regel- und Abfragesprachen. Herausforderungen in der Verwendung von Ontologien ergeben sich aus nicht garantierbaren Laufzeiten von Abfragen und aus der mit der Handhabung von Ontologien verbundenen Komplexität. Im nächsten Schritt Prozessbeschreibung werden die Arbeitsprozessbeschreibungen [7] (etwa in der BPMN [19]) analysiert und auf die Funktionen abgebildet, die die zu verwendenden Werkzeugdomänen bereitstellen. Die Architektur des ASB ist darauf ausgelegt, ein flexibles Zusammenspiel der vorgestellten Konzepte zu ermöglichen. Ein Vorteil ist die iterative Umsetzbarkeit von Integrationslösungen, die eine schrittweise Migration bestehender Integrationslösungen Richtung ASB mit überschaubaren Risiken und Kosten [20, 21] erlaubt. Im darauffolgenden Schritt Prozessumsetzung erfolgt die konkrete Umsetzung der Integration, in dem die erfassten Modelle und Arbeitsabläufe dazu verwendet werden, um projektspezifische ASB-Artefakte wie Konfigurationsdateien, Quellcode und Testszenarien semi-automatisiert abzuleiten. In diesem Schritt werden (a), (b), (c) Vorlagen für Werkzeugkonnektoren erstellt, die neben der konkreten Anbindung an das Zielwerkzeug die Funktionalität der Werkzeugdomäne beziehungsweise Gültigkeitsüberprüfungen von Dateninstanzen implementieren, b) Schnittstellen und Funktionsaufrufe der Werkzeugdomänen angelegt, c) Transformationsinstruktionen zwischen Datenmodellen abgeleitet, um zwischen Werkzeugen Daten semantisch korrekt austauschen zu können und d) Testszenarien erstellt, um die Anbindung der Werkzeuge an den ASB testen zu können. Die ASB-Integrationslösung kann dann auf einem Server, etwa in einer Java VM, zur Verwendung im Projekt bereitgestellt werden. Erfahrungen aus der Anwendung des ASB mit Software-Werkzeugherstellern und Fachexperten in der Anlagenplanung haben folgenden Aufwand ergeben: ein bis zwei Workshop-Tage für die Analyse der Datenmodelle für Werkzeugkonnektoren und zu unterstützende Arbeitsabläufe, einige Personentage für die Umsetzung eines Werkzeugkonnektors als Java beziehungsweise C# Klassen anhand des Datenmodells durch Werkzeug- und ASB-Experten. Werkzeughersteller können unterschiedliche Versionen von Werkzeugkonnektoren anbieten, Werkzeugdomänen halten die Auswirkungen von Änderungen der Werkzeugspezifika auf ASB-Anwendungen möglichst gering. Die Beschreibung der Transformationsmodelle ist typischerweise in ein bis zwei Tagen möglich, allerdings kann Mehraufwand entstehen, falls Daten in der Organisation bisher inkonsistent verwendet wurden, was durch die Analyse und den Einsatz der automatischen Datenabgleiche oft erstmals auffällt. Die Einbindung bekannter Werkzeuge in etablierte Standardarbeitsabläufe ist typischerweise in einigen Personentagen erzielbar. Wesentlicher Aufwand entsteht durch die Abstimmung und Entwicklung organisationsspezifischer Arbeitsabläufe, insbesondere gut verständlicher Anwenderschnittstellen, die je nach Anforderungen und Umfang typischerweise einige Personenwochen erfordert. In den ASB-Projekten hat sich eine iterative Vorgehensweise in Projektphasen über zwei bis drei Monate bewährt, um nützliche und überschaubare Integrationsschritte zu setzen. Mit Bezug zum Aufwand für die Integration ist es wichtig zu unterscheiden, ob es sich um Initialaufwand oder um Aufwand für Änderungen der Integrationslösung handelt. Einen wichtigen Unterschied zu anderen Integrationsansätzen stellt die explizite Verfügbarkeit von Wissen über Arbeitsabläufe oder verwendete Software-Werkzeuge in Form von Ontologien dar, wodurch eine automatisierte und maschinenverständliche Verwendung dieses Wissens ermöglicht wird. Der Inititialaufwand anderer Integrationsansätze ist daher etwas niedriger, da für die ASB-Integration das explizite Wissen über Arbeitsabläufe und Software-Werkzeuge zusätzlich modelliert werden muss. Dieses externalisierte Wissen macht jedoch Änderungen der Integrationslösung leichter. Zusätzlich unter- 893

7 Hauptbeitrag stützt das Konzept der Werkzeugdomänen effektiv die Stabilität von Arbeitsabläufen, auch bei Änderungen an Software-Werkzeugen, die lokal in den Konnektoren adressiert werden können. Einen weiteren Vorteil bietet der ASB im Bereich von qualitätssichernden Maßnahmen. Durch die explizite Verfügbarkeit von Wissen über Arbeitsläufe und Software-Werkzeuge wird die automatisierte Durchführung von qualitätssichernden Maßnahmen erleichtert, wodurch die konsistente und plausible Datenhaltung verbessert wird; zusätzlich können automatisiert Testfälle abgeleitet werden, um die Integrationslösung bereits vor der Inbetriebnahme zu testen. Zusammenfassung und Ausblick Dieser Beitrag hat den Automation Service Bus (ASB) [3] vorgestellt, einen offenen herstellerneutralen Ansatz zur Integration von Software-Werkzeugen. Die Vision des ASB ist die offene Integration von Daten und Funktionen aus Software-Werkzeugen, um Abläufe in Engineering- Projekten systematisch zu automatisieren. Wesentliche Eigenschaften des ASB sind die herstellerneutrale, offene Anbindung von Software-Werkzeugen an eine Integrationsplattform. Diese Plattform beschreibt die Datenmodelle der anzuschließenden Werkzeuge in expliziter Form mit Hilfe von Ontologien, und ermöglicht dadurch einerseits die effiziente Konfiguration benötigter Modelltransformationen und andererseits die versionierte Speicherung von Werkzeugdaten. Gleichzeitig erlaubt der ASB die werkzeugunabhängige Definition von Arbeitsabläufen, die auch bei Austausch von konkreten Werkzeugversionen weitgehend stabil bleiben. Der ASB-Ansatz ermöglicht, vorhandene Engineering- Prozesse sichtbar und analysierbar zu machen und diese Prozesse nach dem Bedarf der Fachexperten zu automatisieren oder anzupassen. Der ASB-Ansatz wurde anhand realer Projekterfordernisse von Industriepartnern aus dem Bereich des industriellen Anlagenbaus konzipiert, iterativ verbessert und evaluiert. Die Erstellung von Konnektoren für Software-Werkzeuge durch die einschlägigen Experten ließ sich je nach Umfang der anzubindenden Daten und Funktionen in zwei bis zehn Tagen erledigen. Durch die Integration von Daten und Funktionen werden neue Funktionen auf Projektebene ermöglicht, etwa die Navigation zwischen Sichten auf ein mechatronisches Objekt in den unterschiedlichen Werkzeugen oder die Datenauswertungen auf Projektebene über heterogene Datenmodelle aus den verwendeten Software-Werkzeugen. Referenzen [1] Drath, R. und Barth, M.: Concept for interoperability between independent engineering tools of heterogeneous disciplines. In: Proceedings Emerging Technologies & Factory Automation (ETFA 2011), S. 1-8, 2011 [2] Chappell, D.: Enterprise Service Bus - Theory in Practice. O Reilly, 2004 [3] Biffl, S. und Schatten, A.: A Platform for Service-Oriented Integration of Software Engineering Environments. In: Proceedings SoMeT 09, S , 2009 [4] Szyperski, C.: Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 2002 [5] Papazoglou, M.P. und Heuvel, W.-J.: Service oriented architectures: approaches, technologies and research issues. The VLDB Journal 16(3), S , 2007 [6] Sunindyo, W., Moser, T., Winkler, D., Mordinyi, R., Biffl, S.: Workflow Validation Framework in Distributed Engineering Environments. In: Proceedings 3rd International Workshop on Information Systems in Distributed Environment (ISDE'11), S. 1 10, 2011 [7] Winkler, D., Moser, T., Mordinyi, R., Sunindyo, W.D., Biffl, S.: Engineering Object Change Management Process Observation in Distributed Automation Systems Projects. In: Proceedings 18th European System & Software Process Improvement and Innovation, S. 1-12, 2011 [8] Biffl, S., Mordinyi, R., Moser, T.: Automated Derivation of Configurations for the Integration of Software(+) Engineering Environments. In: Proceedings 1st International Workshop on Automated Configuration and Tailoring of Applications (ACoTA 2010), S. 6 13, 2010 [9] Mordinyi, R., Moser, T., Biffl, S., Dhungana, D.: Flexible Support for Adaptable Software and Systems Engineering Processes. In: Proceedings 23rd International Conference on Software Engineering and Knowledge Engineering (SEKE 2011), S. 1 5, 2011 [10] Moser, T. und Biffl, S.: Semantic Integration of Software and Systems Engineering Environments. IEEE Transactions on Systems, Man, and Cybernetics, C-42(1), S , 2012 [11] Moser, T., Schimper, K., Mordinyi, R., Anjomshoaa, A.: SAMOA - A Semi-Automated Ontology Alignment Method for Systems Integration in Safety-Critical Environments. In: Proceedings International Conference on Complex, Intelligent and Software Intensive Systems, S , 2009 [12] Waltersdorfer, F., Moser, T., Zoitl, A., Biffl, S.: Version Management and Conflict Detection Across Heterogeneous Engineering Data Models. In: Proceedings 8th IEEE International Conference on Industrial Informatics (INDIN 2010), S , 2010 [13] Moser, T., Mordinyi, R., Winkler, D., Biffl, S.: Engineering Project Management Using The Engineering Cockpit. In: Proceedings 9th IEEE International Conference on Industrial Informatics (INDIN'2011), S , 2011 [14] Mordinyi, R., Moser, T., Winkler, D., Biffl, S.: Navigating between Tools in Heterogeneous Automation Systems Engineering Landscapes. In: Proceedings 38th Annual Conference of the IEEE Industrial Electronics Society (IECON 2012), S , 2012 [15] Moser, T., Mordinyi, R., Mikula, A., Biffl, S.: Making Expert Knowledge Explicit to Facilitate Tool Support for Integrating 894

8 Der ASB wurde seit 2010 mit Industriepartnern konzipiert und entwickelt. Aktuell laufen Evaluierungsprojekte mit mehreren Werkzeugpartnern und Anwendern aus dem Bereich Anlagenbau, deren Ergebnisse zum Teil bereits in realen Projekten eingesetzt werden. Eine Open- Source-Variante des ASB, durchläuft den Prozess Richtung Apache-Projekt. Gemeinsam mit dem Unternehmenspartner Logicals wird der ASB laufend verbessert, um die Konfiguration und Verwendung nicht nur für Softwareentwickler mit Kenntnis der Modellierungssprachen, sondern auch für Anwendungsexperten leicht zugänglich zu machen, und damit die Entwicklungszeiten zu verkürzen. Die Entwicklung und Anwendung systematischer Ansätze zur offenen Integration von Daten (etwa AutomationML [22]) und Funktionen (etwa der Automation Service Bus) beschleunigen die Innovation von Software- Werkzeugen für das Engineering. Sie stärken durch Verbesserungen der Effizienz im Engineering die Wettbewerbsfähigkeit der europäischen Industrie. Autoren Ao. Univ.Prof. DI Mag. Dr.techn. Stefan Biffl (geb. 1967) ist Leiter des Christian Doppler Forschungslabors Software Engineering Integration für flexible Automatisierungssysteme (CDL-Flex) an der Fakultät für Informatik der Technischen Universität Wien. Seine Forschungsinteressen liegen im Bereich der Produktund Prozessverbesserung für Software-intensive Systeme sowie der empirischen Evaluierung im industriellen Umfeld. Technische Universität Wien, Favoritenstr. 9-11/188, A-1040, Wien, Tel. +43 (0) ; Manuskripteingang Im Peer-Review-Verfahren begutachtet Complex Information Systems in the ATM Domain. In: Proceedings International Conference on Complex, Intelligent and Software Intensive Systems(CISIS '09), S , 2009 [16] Moser, T., Mordinyi, R., Winkler, D.: Extending Mechatronic Objects for Automation Systems Engineering in Heterogeneous Engineering Environments. In: Proceedings 17th IEEE Conference on Emerging Technologies and Factory Automation (ETFA), S. 1-8, 2012 [17] Biffl, S., Mordinyi, R., Schatten, A: A Model-Driven Architecture Approach Using Explicit Stakeholder Quality Requirement Models for Building Dependable Information Systems. In: Proceedings 5th International Workshop on Software Quality, Minneapolis, S. 6, 2007 [18] Biffl, S., Mordinyi, R., Moser, T., Wahyudin, D.: Ontologysupported quality assurance for component-based systems configuration. In: Proceedings the 6th international Workshop on Software Quality (WoSQ), S , 2008 [19] Allweyer, T.: BPMN 2.0 Introduction to the Standard for Business Process Modeling. Books on Demand, 2010 [20] Biffl, S., Mordinyi, R., Moser, T.: Anforderungsanalyse für das integrierte Engineering Mechanismen und Bedarfe aus der Praxis, Automatisierungstechnische Praxis 54(5), S , 2012 [21] Biffl, S., Moser, T., Mordinyi, R.: Automation Service Bus löst Software-Problematik, Computer & AUTOMATION 2012(6), S , 2012 [22] Drath, R.: Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA. Springer, Berlin Heidelberg, 2010 DI Mag. Dr.techn. Richard Mordinyi (geb. 1979) ist Postdoc im Christian Doppler Forschungslabor Software Engineering Integration für flexible Automatisierungssysteme (CDL-Flex) an der Fakultät für Informatik der Technischen Universität Wien. Seine Forschungsinteressen liegen im Bereich der Modell-getriebenen Konfiguration von Integrationsplattformen, Agiler Softwarearchitekturen und sicheren Koordinationsstrategien in komplexen verteilten Systemen. Technische Universität Wien, Favoritenstr. 9-11/188, A-1040, Wien, Tel. +43 (0) richard.mordinyi@tuwien.ac.at Mag. Dr.rer.soc.oec. Thomas Moser (geb. 1981) ist Postdoc im Christian Doppler Forschungslabor Software Engineering Integration für flexible Automatisierungssysteme (CDL-Flex) an der Fakultät für Informatik der Technischen Universität Wien. Seine Forschungsinteressen liegen im Bereich der Datenmodellierung und Datenintegration für Softwareintensive Systeme sowie im Bereich Semantic Web. Institut für Softwaretechnik und interaktive Systeme, Technische Universität Wien, Favoritenstr. 9-11/188, A-1040 Wien, Tel. +43 (0) , thomas.moser@tuwien.ac.at 895