Spezifikation der mobilen Workflow Enactment Engine, der entwickelten Referenzprozessmodelle und der mobilen Dienste

Transkript

1 Grid-basierte Plattform für die Virtuelle Organisation im Bauwesen Gefördert durch Förderkennzeichen: 01IG07001 BauVOGrid-Bericht A-5.1 Spezifikation der mobilen Workflow Enactment Engine, der entwickelten Referenzprozessmodelle und der mobilen Dienste Verantwortlicher Partner: Verfasser: FIRST Stefan Klose Autor(en): Stefan Klose, Ralf Angeli, Thorsten Dollmann, Thilo Ernst, Michael Fellmann, Frank Hilbert, Andreas Hoheisel Datum : Version: 1.0 Verteiler: Projektpartner X Projektträger X D-Grid X Öffentlichkeit X Copyright: BauVOGrid-Konsortium Projektlaufzeit: 06/ /2010

2 BMBF-Projekt BauVOGrid BauVOGrid Bericht A-5.1 Spezifikation der mobilen Workflow Enactment Engine, der entwickelten Referenzprozessmodelle und der mobilen Dienste BauVOGrid Konsortium 2010 Seite 2 von 44

3 Konsortium Institut für Bauinformatik der Technischen Universität Dresden Dresden Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik (FIRST) Berlin Institut für Wirtschaftsinformatik (IWi) im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) Saarbrücken Seib InformationsTechnologie Consult GmbH (SEIB ITC) Würzburg Bilfinger Berger AG Mannheim BAM Deutschland AG Standort Dresden Dresden IDS Scheer AG Saarbrücken RIB Information Technologies AG Stuttgart TransMIT Gesellschaft für Technologietransfer mbh Gießen TUD FIRST IWI SEIB BB BAM IDS RIB TMIT Koordinator Institut für Bauinformatik der Technischen Universität Dresden Postanschrift: Kontakt: Institut für Bauinformatik TU Dresden D Dresden Prof. Dr.-Ing. Raimar J. Scherer Telefon: +49/351/ Fax: +49/351/ Web:

4 Vorwort Vorwort Ein wesentliches Ziel des BauVOGrid-Projektes liegt in der nachhaltigen Verbesserung der Struktur, Effizienz und Operabilität von Arbeitsgemeinschaften im Bauwesen durch ein verteiltes IT-System. Dazu gehören unter Anderen die Unterstützung des Informationsaustauschs zwischen den verschiedenen Projekträumen und Projektpartnern sowie der mobilen Erfassung von Prozessen und Daten auf der Baustelle. Dafür wurde auf Basis der in Bericht A-2.1 zusammengefassten Technischen Anforderungen die in dem Bericht A-2.2 beschriebene Systemarchitektur in Zusammenarbeit aller am BauVOGrid-Projekt beteiligten Partner erarbeitet. Mit den bereitgestellten Diensten soll das Mangelmanagement bei Bauprozessen unter Verwendung vorgefertigter Workflows unterstützt werden. Der vorliegende Bericht spezifiziert die verwendeten mobilen Workflows und beschreibt den Weg vom von den fachlichen Geschäftsprozessen zu den ausführbaren IT-Prozessen. Er bildet damit die fachliche Grundlage für das im Bericht A7.1 verfasste Pflichtenheft und für die Pilotprojekte, welche die erarbeitete Lösung verifizieren sollen. Der Bericht ist wie folgt in neun Kapitel strukturiert: Kapitel 2 stellt die Referenzprozesse für das mobile ment vor; Kapitel 3 widmet sich der Methodik der der prozessbasierten Integration der mentdienste. Insbesondere wird die Verwendung der Grid Workflow Description Language im Rahmen des Projektes und der Weg von den fachlichen Geschäftsprozessen zu ausführbaren IT-Prozessen beschrieben; Kapitel 4 präsentieren die mobilen Dienste, welche für die Aufnahme der Mängel vor Ort entwickelt wurden; Kapitel 5 fasst schließlich die erreichten Ergebnisse zusammen und gibt einen Ausblick auf mögliche Weiterentwicklungen. Versionshistorie Version Beschreibung Autor(en) Datum vollständige Vorab-Version FIRST Vollständige Version mit Beiträgen aller Partner, Korrekturen und Einzelfreigaben Alle Freigegebene Endversion TUD Seite 4 von 44

5 BauVOGrid-Bericht A-5.1 Inhaltsverzeichnis 1. Einleitung 6 2. Referenzprozess für mobiles ment 7 3. Methodik der Prozess-basierten Integration der mentdienste Grid Workflow Description Language (GWorkflowDL) Abbildung dynamischer Prozesse und Ressourcen auf ausführbare Workflows Mobile Dienste Ortung Site Survey Mobiles mentsystem (MMS) Barcode-Bildzuordnung Synchronisation mit dem zentralen mentsystem (ZMMS) Zusammenfassung und Ausblick Literatur Anhang: Referenzprozessmodelle 35 Seite 5 von 44

6 Einleitung 1. Einleitung Ziel dieses Arbeitspaketes ist es, unter Berücksichtigung der eingeschränkten Ressourcen mobiler Endgeräte, Dienste zur mobilen Mangelaufnahme bereitzustellen. Dies umfasst Komponenten zur Ortung, zur initialen Begehung der Baustelle, zur Mangelaufnahme sowie zur Synchronisation mit dem zentralen mentsystem (ZMMS). Mit den bereitgestellten Diensten ist der Nutzer in der Lage einen zuvor definierten Mangelaufnahme-Workflow selbstständig durchzuführen. Eine IT-unterstützte Mangelaufnahme erleichtert die Kommunikation zwischen den beteiligten Partnern eines Bauprojektes und erhöht durch vorgefertigte Beschreibungsbausteine die Eindeutigkeit und Nachvollziehbarkeit von aufgenommenen Mängelbeschreibungen. Die direkt auf der Baustelle auszuführenden, mobilen Prozessschritte sind dabei Teil eines übergeordneten Workflows, über den die Abarbeitung der hier exemplarisch gezeigten Mangelaufnahme koordiniert und teilweise automatisiert sowie kontrolliert wird. Diese Workflows können prinzipiell bei statischen Prozessen, deren Struktur und verwendeten Ressourcen relativ beständig sind, fest in die Anwendungslogik einprogrammiert werden (sogenannte fest verdrahtete Workflows). In dynamischen Umgebungen mit variablen Prozessen bietet sich jedoch stattdessen die Verwendung einer Workflow-Engine an, wie sie für das Projekt BauVOGrid durch den Grid Workflow Execution Service (GWES) gegeben ist. Diese Workflow-Engine kann dabei sowohl online im Grid als auch offline auf den mobilen Geräten selbst zur Automatisierung, Ausführung und Kontrolle von generischen Prozessen eingesetzt werden. Der Vorteil bei der Nutzung einer Workflow-Engine liegt insbesondere darin, dass bei dynamischer Umgebung und variablen Prozessen die Anwendungslogik nicht neu programmiert oder angepasst werden muss. In dem Projekt wurde exemplarisch die Überführung von Geschäftsprozessen aus dem Bereich ment im Bauwesen auf Dienste der Grid-Infrastruktur durchgeführt. Abschnitt 2 beschreibt zunächst den entwickelten kollaborativen Referenzprozess des mobilen ments. Die gegebene Problemstellung verdeutlicht ein Beispielausschnitt, der die Schritte von der Aufnahme eines Baumangels durch den n bis hin zur Übergabe der Mangeldaten an den Generalunternehmer betrachtet. Zunächst können bei einer Baustellenbegehung verschiedene Baumängel durch den n (BH) erfasst und mit einem mobilen Gerät in das System eingegeben werden (vgl. Abschnitt 4, mobile Dienste). Anschließend werden vorhandene Fotos, welche zusätzlich mit einem anderen Gerät zur Dokumentation der Mängel erstellt wurden, den Mängeln zugeordnet. Die Zuordnung erfolgt über die Dekodierung von im Foto enthaltenen 2D-Barcodes, die beim Fotografieren mit ins Bild gehalten wurden. Da die Datamatrix-Codes, anders als in etablierten Systemen, nur einen sehr kleinen Bereich der Fotografien ausmachen und erst nach mehreren Bildbearbeitungsschritten deutlich zu erkennen sind, ist dieser Prozessschritt sehr rechenintensiv und wird in der Regel auf Rechen-Clustern im Grid ausgeführt. Nachdem die Fotos den Mängeln zugeordnet wurden, müssen die Mängeldaten aktualisiert, zentral gespeichert und an den Generalunternehmer () weitergeleitet werden, welcher für die Beseitigung der Mängel zuständig ist. Die Notwendigkeit einer Automatisierung eines solchen Prozesses wird deutlich, wenn man beachtet, dass bei größeren Baustellen wie zum Beispiel den Bau eines Flughafens durchaus etwa 200GB an Fotos und Mängel anfallen können, deren Beseitigung bis zu 10% der gesamten Bausumme ausmachen kann. Für jeden Mangel muss dabei eine neue Instanz des entsprechenden technischen Prozesses ausgeführt werden. Durch den hier vorgeschlagenen Ansatz können die ausführbaren Prozesse direkt aus den entsprechenden EPK-Modellen generiert und auf leistungsfähigen Grid-Ressourcen ausgeführt werden, ohne dass sich die Nutzer mit den technischen Details der Infrastruktur auseinandersetzen müssen. Durch die strukturell sehr einfache Seite 6 von 44

7 BauVOGrid-Bericht A-5.1 und direkte Abbildung der Geschäftsprozessmodelle auf ausführbare IT-Prozesse können zudem dynamische Änderungen in den Geschäftsprozessabläufen, welche z. B. durch eine Havarie auf der Baustelle oder durch den Wechsel von Unterauftragnehmern (Insolvenz) ausgelöst werden können, schnell auf modifizierte IT-Prozesse abgebildet werden. Im Gegenzug wird eine direkte Überwachung der IT-Prozesse in der Geschäftsprozesssicht ermöglicht, sodass zum Beispiel auf Verzögerungen im Prozessablauf aufgrund von Engpässen in der IT (Datenspeicher voll) direkt auf Ebene der Geschäftsprozesse reagiert werden kann. Im Rahmen von BauVOGrid ist insbesondere die Transformation von EPML nach GWorkflowDL wichtig, da dies die Schnittstelle zwischen den Geschäftsprozessen und den ausführbaren Grid-Prozessen darstellt. Die Instanziierung eines Prozesses im Sinne der Erzeugung eines konkreten, ablauffähigen Vorgangs entspricht technisch gesehen einem Export eines EPML-Dokuments aus dem Modellierungswerkzeug, einer anschließenden Konvertierung nach GWorkflowDL und eines Importes in den GWES. Die durchgängige Methodik basiert auf dem im A4-1-Bericht dokumentierten integrierten Methodenbaukasten der Prozessmodellierung und ist Gegenstand von Abschnitt Referenzprozess für mobiles ment Der Referenzprozess für mobiles ment beschreibt allgemein die Bearbeitung eines Mangels von dessen Entdeckung bis zu dessen Beseitigung oder auch Nichtbeseitigung. Es wird davon ausgegangen, dass drei Akteure an der Prozessdurchführung beteiligt sind: : Rechtlich und wirtschaftlich verantwortlicher Auftraggeber des Bauvorhabens Generalunternehmer: Dienstleister, der sämtliche Bauleistungen zur Errichtung eines Bauwerks erbringt Nachunternehmer: Dienstleister, der vom Generalunternehmer beauftragt ist und die vom Generalunternehmer dem en geschuldete Leistung teilweise oder zur Gänze erbringt In großen Arbeitsgemeinschaften sind an der Prozessdurchführung oftmals neben dem en ein oder mehrere Generalunternehmer sowie mehrere hundert Nachunternehmer beteiligt. Der Referenzprozess ist in zwei Ebenen modelliert. Die erste Ebene bildet der Hauptprozess, der den gesamten Ablauf der Mangelbearbeitung über alle Akteure hinweg beschreibt. (Vgl. Abbildung 28.) Diese Beschreibung ist sehr grob gehalten und beinhaltet nicht die detaillierten Abläufe innerhalb der Organisationen einzelner Akteure. Die organisationsinternen Prozesse werden als Prozessmodule auf der zweiten, unteren Ebene ausgestaltet. (Vgl. Abbildung 29 bis Abbildung 35.) Diese Aufteilung folgt dem Prinzip der Objektorientierung und ermöglicht einen Austausch der Prozessmodule unter der Voraussetzung, dass die Schnittstellen der einzusetzenden Module oder Business Process Objects (BPO) zu denen des Hauptprozesses passen. Durch die Kapselung und Austauschbarkeit der BPOs wird gewährleistet, dass die Mangelbearbeitung von unterschiedlichen Organisationen durchgeführt werden kann, wobei deren interne Abläufe unerheblich sind und nicht offengelegt werden müssen. Die beschriebenen Prozessmodule haben hierbei einen Vorschlagscharakter. Der Hauptprozess ist ebenfalls als Referenz zu verstehen und kann den Gegebenheiten einer konkreten Mangelbearbeitung durch Ändern, Entfernen oder Hinzufügen von Prozessteilen angepasst werden. Hauptprozess ment Die Bearbeitung eines Mangels startet mit der Entdeckung eines Mangels durch den en oder den Generalunternehmer. In beiden Fällen wird geprüft, ob der Mangel sofort zu beheben ist Seite 7 von 44

8 Referenzprozess für mobiles ment und dies gegebenenfalls gemacht. Ist der Mangel nicht sofort zu beheben, wird der Mangel systemtechnisch erfasst und bei Erkennung durch den n an den Generalunternehmer weitergegeben. Der Generalunternehmer bearbeitet anschließend den Mangel, indem er selbst den Mangel beseitigt, ihn zurückweist oder ihn an einen Nachunternehmer weiterleitet, welcher den Mangel verschuldet hat, oder welcher zur Mangelbeseitigung besonders geeignet ist. Dieser bearbeitet den Mangel indem er ihn entweder beseitigt oder zurückweist. Beseitigt der Nachunternehmer den Mangel, muss der Generalunternehmer die Mangelbeseitigung abnehmen. Dies kann zu einer Nacharbeitsforderung gegenüber dem Nachunternehmer führen oder zur Akzeptanz der Mangelbeseitigung. Im letzteren Fall meldet der der Generalunternehmer den Mangel ab und informiert den en über die Mangelbeseitigung. Im Anschluss nimmt der die Mangelbeseitigung ab. Dieser kann die Mangelbeseitigung akzeptieren oder zurückweisen. Bei Zurückweisung folgt wieder die Mangelbearbeitung durch den Generalunternehmer. Bei Akzeptanz endet der Prozess an dieser Stelle. Ein weiteres Ergebnis der Mangelbearbeitung kann die Beurteilung des Mangels als nicht behebbar sein, woraufhin der entsprechend informiert wird. Wird der Mangel zurückgewiesen oder ist nicht behebbar, wird der entsprechend informiert. In diesem Fall kann der nach Prüfung das Ergebnis akzeptieren oder den Generalunternehmer über einen Einigungsvorschlag informieren. Abbildung 28 zeigt den Prozess in Form einer Ereignisgesteuerten Prozesskette (EPK). Prozess Mangel erfassen (BH) Der Prozess Mangel erfassen (BH) beinhaltet die Schritte zur Erfassung eines Mangels durch den en. Unter Berücksichtigung der zur Verfügung stehenden technischen Möglichkeiten wird der Mangel direkt vor Ort mit einem mobilen Endgerät oder später im Büro per Personalcomputer in das mentsystem eingetragen. Im Anschluss wird der Mangel kategorisiert und basierend auf der Schwere des Mangels eine einfache oder genaue Mangelverfolgung und -prüfung angeordnet. Abbildung 29 zeigt den Prozess in Form einer EPK. Prozess Mangel erfassen () Der Prozess Mangel erfassen () beinhaltet die Schritte zur Erfassung eines Mangels durch den Generalunternehmer. In Bezug auf die durchgeführten Funktionen und die Prozessstruktur ist er deckungsgleich mit dem Prozess Mangel erfassen (BH). Lediglich der Akteur (Generalunternehmer statt ) und das betroffene mentsystem (System des Generalunternehmers statt das System des en) ist unterschiedlich. Abbildung 30 zeigt den Prozess in Form einer EPK. Prozess Mangel bearbeiten () Der Prozess Mangel bearbeiten () beschreibt die Schritte, die der Generalunternehmer nach Erfassung eines Mangels bis zu dessen Weiterleitung, Beseitigung oder Zurückweisung durchführt. Hierbei wird unterschieden, ob es sich um einen neu erkannten oder bereits aufgenommenen Mangel handelt. Bei einem neu erkannten Mangel, wird der Eingang des Mangels zunächst im mentsystem des Generalunternehmers registriert. Bei einem bereits aufgenommenen und freigemeldeten Mangel, dessen Freimeldung durch den n abgelehnt wurde, wird der Mangelstatus zurückgesetzt. Bei einem bestehenden Mangel, der nicht durch den Nachunternehmer beseitigt wird, wird keine besondere Aktion durchgeführt. In jedem Fall wird im Anschluss geprüft, ob der Mangel Vertragsbestandteil ist. Falls nicht, wird der Mangel zurückgewiesen und der über die Zurückweisung informiert. Falls er Vertragsbestandteil ist, wird die Zuständigkeit für die Mangelbeseitigung geprüft und der Mangel entweder an den Nachunternehmer weitergeleitet oder die Mangelbeseitigung selbst vom Generalunternehmer Seite 8 von 44

9 BauVOGrid-Bericht A-5.1 vorgenommen. Stellt sich heraus, dass der Mangel nicht beseitigt werden kann, wird der entsprechend informiert. Abbildung 31 zeigt den Prozess in Form einer EPK. Prozess Mangelzurückweisung bearbeiten (BH) Der Prozess Mangelzurückweisung bearbeiten (BH) beschreibt die Schritte des en zur Bearbeitung einer Mangelzurückweisung durch den Generalunternehmer. Zuerst wird die Zurückweisung geprüft. Falls sie akzeptiert wird, wird der Mangel im mentsystem des en als nicht zu beheben markiert und der Prozess endet hier. Wenn die Zurückweisung nicht akzeptiert wird, werden Reaktionsmöglichkeiten evaluiert. Sollte eine Einigung mit dem Generalunternehmer nicht wahrscheinlich sein, werden vertragliche bzw. gerichtliche Konsequenzen vorbereitet und der Prozess endet hier. Wenn eine Einigung wahrscheinlich ist, wird ein Einigungsvorschlag aufgesetzt und der Generalunternehmer darüber in Kenntnis gesetzt. Abbildung 32 zeigt den Prozess in Form einer EPK. Prozess Mangel bearbeiten (NU) Der Prozess Mangel bearbeiten (NU) beschreibt die Schritte, die der Nachunternehmer durchführt, um einen eingegangenen Mangel zu beseitigen oder zurückzuweisen. Wenn es sich um einen neuen oder einen vorher zurückgewiesenen Mangel handelt, wird der Eingang des Mangels zuerst im mentsystem des Nachunternehmers registriert. Sollte es sich um einen bereits aufgenommenen Mangel handeln, dessen Freimeldung durch den Generalunternehmer abgelehnt wurde, wird der Status des Mangels im System entsprechend zurückgesetzt. In allen Fällen wird im Anschluss geprüft, ob der Mangel Vertragsbestandteil ist. Falls dies nicht der Fall ist, wird der Mangel zurückgewiesen und der Generalunternehmer darüber informiert. Wenn der Mangel Vertragsbestandteil ist, wird die Mangelbeseitigung geprüft. Entscheidet sich der Nachunternehmer, den Mangel nicht zu beseitigen, informiert er den Generalunternehmer mittels Individualschreiben. Andernfalls beseitigt er den Mangel und meldet den Mangel gegenüber dem Generalunternehmer frei. Abbildung 33 zeigt den Prozess in Form einer EPK. Prozess Mangelbeseitigung abnehmen () Der Prozess Mangelbeseitigung abnehmen () beschreibt die Schritte des Generalunternehmers, um die Mangelbeseitigung durch den Nachunternehmer abzunehmen. Hierbei wird die Mangelbeseitigung auf der Baustelle überprüft. Ist der Generalunternehmer mit dem Ergebnis nicht zufrieden, wird die Freimeldung des Nachunternehmers zurückgewiesen. Bei zufriedenstellender Beseitigung erfolgt keine spezielle Aktion, aber es kann mit der Abmeldung des Mangels fortgefahren werden. Abbildung 34 zeigt den Prozess in Form einer EPK. Prozess Mangelzurückweisung bearbeiten () Der Prozess Mangelzurückweisung bearbeiten () beschreibt die Schritte des Generalunternehmers zur Bearbeitung der Zurückweisung eines Mangels durch den Nachunternehmer. Hierfür wird die Zurückweisung zuerst überprüft. Wird sie akzeptiert, wird der Status des Mangels im mentsystem des Generalunternehmers angepasst und die eigene Bearbeitung des Mangels angestoßen. Falls die Zurückweisung nicht akzeptiert wird, werden zur Verfügung stehende Reaktionsmöglichkeiten evaluiert. Sollte eine Einigung mit dem Nachunternehmer nicht wahrscheinlich sein, werden vertragliche bzw. gerichtliche Konsequenzen vorbereitet und anschließend die eigene Bearbeitung des Mangels angestoßen. Wenn eine Einigung wahrscheinlich Seite 9 von 44

10 Methodik der Prozess-basierten Integration der mentdienste ist, wird ein Einigungsvorschlag aufgesetzt und der Nachunternehmer darüber in Kenntnis gesetzt. Abbildung 35 zeigt den Prozess in Form einer EPK. Prozess Mangel abmelden () Der Prozess Mangel abmelden () beschreibt die Schritte des Generalunternehmers zur Abmeldung eines aus seiner Sicht behobenen Mangels. Der Generalunternehmer markiert ihn hierfür in seinem mentsystem als erledigt und meldet ihn beim n ab. Abbildung 36 zeigt den Prozess in Form einer EPK. Prozess Mangelbeseitigung abnehmen (BH) Der Prozess Mangelbeseitigung abnehmen (BH) beschreibt die Schritte, die ein durchführt, um einen freigemeldeten Mangel abzunehmen. Hierfür überprüft er die Beseitigung des Mangels auf der Baustelle. Ist diese nicht zu seiner Zufriedenheit erfolgt, wird die Freimeldung zurückgewiesen und der Generalunternehmer entsprechend informiert. Andernfalls wird der Mangel in seinem mentsystem als erledigt gekennzeichnet und der Prozess endet hier. Abbildung 37 zeigt den Prozess in Form einer EPK. 3. Methodik der Prozess-basierten Integration der mentdienste In enger Zusammenarbeit mit den Anwendungspartnern wurden in AP 5.5 Prozessmodule für das mobile ment als ausgewähltes Anwendungsszenario entwickelt (vgl. Abschnitt 2). Der methodische Einsatz der Modelle erfolgt durch die stufenlose Überführung der fachlichen Prozessmodelle in Implementierungsmodelle und der Integration verteilter Workflowprozesse. Im Rahmen von BauVOGrid werden dabei verschiedene Werkzeuge zur Prozessmodellierung und Automatisierung eingesetzt, welche die gesamte Kette von der fachlichen Modellierung von Geschäftsprozessen bis hin zur automatisierten Ausführung der darunterliegenden IT-Prozesse auf der Grid-Infrastruktur von BauVOGrid abbilden. Da die unterschiedlichen Werkzeuge jeweils eine eigene Sicht auf die Prozesse haben, liegen diesen unterschiedliche Formalismen und Beschreibungssprachen zugrunde, die in BauVOGrid ineinander überführt werden müssen. Die im Projektfokus ausgewählten Werkzeuge und Transformationsschritte, die von der initialen Modellierung von Geschäftsprozessen bis zu ihrer Ausführung auf der Grid-Infrastruktur durchlaufen werden, wurden bereits anhand des integrierte Methoden- und Werkzeugbaukasten zur Prozessmodellierung in Bericht A4-1 dokumentiert. Die Prozessorientierung des Gesamtentwurfs von BauVOGrid zielt auf die Etablierung und Unterstützung der für das Bauwesen neuen prozesszentrierten Arbeitsweise. Bei der Abbildung der dynamischen Prozesse werden Zusatzinformationen bei der Modellierung mitgegeben, welche die Integration bzw. Kopplung von Prozessen in Grid- Umgebungen (teil-)automatisiert ermöglichen. Basis der Grid-basierten Workflow-Unterstützung bildet die Grid Workflow Description Language (GWorkflowDL), auf die anschließend die dynamischen Prozesse abgebildet werden Grid Workflow Description Language (GWorkflowDL) Für die Beschreibung von IT-gestützten Prozessen in SOAs, Clouds oder Grids entwickelt Fraunhofer FIRST die XML-basierte Workflow-Beschreibungssprache GWorkflowDL, welche auf High-Level-Petrinetzen basiert, um die Kontroll- und Datenflüsse von verteilten IT-Prozessen zu modellieren [Al06, Al06b, HA06]. Der Begriff Workflow wird hierbei als Automatisierung von IT-Prozessen mittels Graphen verstanden. Ziel der GWorkflowDL ist neben der Modellierung Seite 10 von 44

11 BauVOGrid-Bericht A-5.1 und Analyse von Workflows insbesondere deren effektive Ausführung und Überwachung. Diese Ausführungen beziehen sich auf die aktuelle GWorkflowDL Version 2.0, welche erstmalig die für die Abbildung von Hinterlegungen wichtigen Unternetze direkt unterstützt und zudem besondere Kantentypen für Verbesserung des Datenflusses in verteilten Systemen vorsieht. Für eine formale Spezifikation der GWorkflowDL sei auf das XML-Schema der GWorkflowDL [Ho09], sowie auf Kapitel 3 von [Vo08] verwiesen. Abbildung 1: Komponenten zur grafischen Notation der GWorkflowDL. Abbildung 1 zeigt die grafische Notation der einzelnen Bestandteile der GWorkflowDL. Entsprechend des Standards ISO/IEC [Is04] werden Stellen durch Kreise, Transitionen durch Quadrate und Eingabe- sowie Ausgabekanten durch durchgezogene Pfeile dargestellt. Im IT- Prozess repräsentieren die Stellen Platzhalter für Daten oder Kontrollmarken. Die Kapazität gibt die maximale Anzahl von Marken an, die auf einer Stelle liegen können. Falls keine Kapazität angegeben ist, haben die Stellen standardmäßig eine unendliche Kapazität. Die Transitionen dienen zur Modellierung abstrakter oder konkreter Aktivitäten, die zum Beispiel auf Web-Service- Methodenaufrufe in einer SOA, Programmausführungen in einem Grid oder auf Unterprozesse die selber wieder als Petrinetz dargestellt werden können abgebildet werden. Die Eingabekanten sind Pfeile von Stellen nach Transitionen, Ausgabekanten sind Pfeile von Transitionen nach Stellen. Die Stellen, die über Eingabekanten mit einer Transition verbunden sind, nennt man Eingabestellen dieser Transition. Analog hierzu nennt man die Stellen, die über Ausgabekanten mit einer Transition verbunden sind, Ausgabestellen. Jede Stelle kann mehrere unterscheidbare Marken enthalten, die als ausgefüllte Kreise dargestellt werden und im XML-Format der GWorkflowDL entweder einen Verweis auf Daten (z.b. als URL) oder die Daten selber enthalten. Eine spezielle Form der Marken sind die Kontrollmarken, welche lediglich die booleschen Werte wahr oder falsch annehmen können. Transitionen können Bedingungen enthalten, die in Form von XPath- Ausdrücken [CD99] als boolesche Funktionen der Eingabemarken formuliert werden. Eine Transition nennt man aktiviert, wenn auf allen Eingabestellen der Transition mindestens eine Marke vorhanden ist und keine der Ausgabestellen ihre Kapazität erreicht hat. Eine aktivierte Transition kann eintreten (ausgeführt werden, schalten), wenn alle ihre Bedingungen erfüllt Seite 11 von 44

12 Methodik der Prozess-basierten Integration der mentdienste sind. Beim Eintreten einer Transition wird von jeder Eingabestelle eine Marke entfernt und anschließend auf jede Ausgabestelle eine neue Marke gelegt. Sind mehrere Transitionen zugleich aktiviert, tritt die Transition ein, welche die höchste Priorität besitzt. Durch die Einführung von Prioritäten wird die GWorkflowDL Turing-Vollständig und erhält die gleiche Beschreibungskraft wie Inhibitor-Netze. Dadurch werden zwar die Analysemöglichkeiten eingeschränkt (zum Beispiel der Beweis der Beschränktheit), da aber die Workflow-Ausführung und nicht deren Analyse im primären Fokus steht, wird dies in Abwägung der besseren Ausdrucksmöglichkeiten in Kauf genommen. Zudem bietet das Konzept der Prioritäten gute Möglichkeiten, die Ausführung von Workflows zu beschleunigen, z. B. indem bei nebenläufigen Transitionen alle Transitionen des kritischen Pfades mit hohen Prioritäten versehen werden. In der GWorkflowDL kann über das XML-Element <operation> eine Transition mit einer bestimmten Workflow-Aktivität verknüpft werden, sodass jedes Eintreten der Transition eine Ausführung der entsprechenden Aktivität zur Folge hat. Jede Aktivität konsumiert dabei einen Satz Eingabedaten also die Daten jeweils einer Marke aller Eingabestellen und erzeugt einen Satz Ausgabedaten, der anschließend in Form von Marken auf alle Ausgabestellen gelegt wird (jeweils eine Marke pro Ausgabestelle). Anders als in der Theorie erfolgt das Eintreten einer Transition nicht instantan, sondern benötigt eine unbestimmte Zeitdauer, da das Schalten der Ausführung einer realen Workflow-Aktivität entspricht. Um die nebenläufige Verarbeitung eines GWorkflowDL-Prozesses zu ermöglichen, müssen daher während der Ausführung die Eingabemarken gesperrt und bei beschränkter Kapazität Platz für die Ausgabemarken reserviert werden. Zur besseren Modellierung von Workflow-Aktivitäten, die nicht nur Daten konsumieren (= lesen + löschen) und neue Daten erzeugen, sondern auch Daten lesen bzw. vorhandene Daten (ggf. teilweise) überschreiben, wurden zusätzlich Lesekanten bzw. Schreibekanten eingeführt, die durch gestrichelte Pfeile zwischen Stellen und Transitionen bzw. Transitionen und Stellen dargestellt werden. In der Theorie sind Lese- und Schreibekanten gleichbedeutend mit einer Schleife. Eine Schleife bezeichnet hierbei einen Bereich im Petrinetz, in dem eine Transition und eine Stelle sowohl durch eine Eingabekante, als auch durch eine Ausgabekante miteinander verbunden sind, die Stelle somit zugleich Eingabestelle und Ausgabestelle einer Transition ist. Um festzustellen, ob eine Transition aktiviert ist, kann man alle Lese- und Schreibekanten jeweils durch eine Schleife von Eingabe- und Ausgabekante ersetzen und oben definierte Regel zum Begriff aktiviert anwenden. In der Praxis erlauben Lesekanten die effektive Modellierung von nebenläufigem Zugriff von Workflow-Aktivitäten auf gemeinsame Daten. Anstatt also beim Eintreten der Transition eine Marke von einer Stelle zu entfernen und sie anschließend unverändert wieder auf die selbe Stelle zu legen, können die Marke und die damit verbundenen Daten an Ort und Stelle verbleiben. Damit die Transition aktiviert ist, muss die Marke jedoch auf der mit der Lesekante verbunden Stelle bereits vorhanden sein. Bei der Ausführung der Workflow-Aktivität werden die Daten gelesen, aber nicht verändert. Im Gegensatz hierzu werden bei Schreibekanten Daten überschrieben ohne sie zuvor zu lesen. Beim Eintreten der Transition wird jeweils eine Marke, die bereits auf einer mit einer Schreibekante verbundenen Stelle liegt, durch eine neue Marke ersetzt. Eine Schleife, die sowohl eine Lese- als auch eine Schreibekante darstellen soll, kann alternativ als Aktualisierungskante durch eine gestrichelte Linie mit Pfeilspitzen an beiden Enden modelliert werden. Eine Aktualisierungskante beschreibt das Lesen und anschließende (ggf. teilweise) Überschreiben von Daten. Analog hierzu beschreibt eine Auswechselkante eine Schleife aus Eingabe- und Ausgabekante, bei der die entsprechende Aktivität Daten nimmt (also liest und löscht) und anschließend auf derselben Stelle neu erzeugt. Eine Auswechselkante kann alternativ als durchgezogener Strich mit Pfeilspitzen an beiden Enden dargestellt werden. Das Ersetzen von Schleifen durch Lese-, Schreibe-, Aktualisierungs- oder Auswechselkanten ändert jedoch nichts an der prinzipiellen Abfolge eines Petrinetzes. Sie dienen lediglich zur Optimierung der Datenflüsse bei der Ausführung der mit den Transitionen verbundenen Aktivitäten. Seite 12 von 44

13 BauVOGrid-Bericht A-5.1 Die Bedeutung der Kantenanschriften weicht in der GWorkflowDL etwas von der sonst gebräuchlichen Notation in High-Level-Petrinetzen ab. Üblicherweise werden die Kantenanschriften dazu verwendet, um die Typen von Marken zu bezeichnen, die beim Eintreten einer Transition von der Transition konsumiert bzw. erzeugt werden [Is04]. In der GWorkflowDL dienen die Kantenanschriften hingegen dazu, die Marken den einzelnen Parametern einer Workflow- Aktivität zuzuordnen. Bei Eingabe- oder Lesekanten gibt die Kantenanschrift eine Variable vor, über die im Kontext der Transition auf die entsprechenden Marken zugegriffen werden kann. Befindet sich zum Beispiel auf einer Stelle, welche über eine Eingabekante mit der Kantenanschrift i mit einer Transition verbunden ist, eine Marke mit dem Inhalt 5, so wird beim Eintreten der Transition der Wert 5 der Variable i zugewiesen: i=5. Im Kontext der Transition kann auf den Inhalt der Variablen mit einem vorangesellten $ zugegriffen werde, z.b. in der Bedingung $x>4. Die Kantenanschriften an Ausgabe- bzw. Schreibekanten geben hingegen entweder einen Ausgabeparameter einer Aktivität an, oder eine Verarbeitungsanweisung in Form eines XPath- Ausdruckes, der eine Funktion der Ausgabedaten der Workflow-Aktivität sowie der durch die eingehenden Kantenanschriften definierten Variablen ist, z.b. $i+6. Die Notation eines ausführbaren GWorkflowDL-Prozesses ist exemplarisch in Abbildung 2 dargestellt. Die Transition f ist aktiviert da die Stellen A und B eine Marke enthalten und die Stelle C eine unendliche Kapazität besitzt. Die Transition f kann eintreten, da die Bedingung $i<10 mit i=0 erfüllt ist. Wenn die Transition eintritt wird die Aktivität f(i,d) ausgeführt mit i=0 und d=2. Anschließend wird die Marke auf Stelle A mit dem Inhalt 0 entfernt und eine neue Marke mit dem Inhalt $i+$d=2 auf Stelle A gelegt. Zudem wird eine neue Marke mit dem Wert des Ausgabeparameters output auf die Stelle C gelegt. Insgesamt tritt die Transition f fünfmal ein und zwar mit den Eingabedaten i={0,2,4,6,8} und d={2,2,2,2,2}. Abbildung 2: GWorkflowDL-Beispiel eines iterativen Aufrufs einer Aktivität f. Die XML-Syntax der GWorkflowDL ist eine direkte Umsetzung eines High-Level-Petrinetzes und orientiert sich an der Petrinet Markup Language (PNML) [WK02]. Im Gegensatz zur PNML, welche überwiegend auf die Visualisierung und Analyse von Petrinetzen ausgerichtet ist, bietet die GWorkflowDL jedoch bessere Möglichkeiten, Transitionen mit realen Workflow-Aktivitäten zu verknüpfen. Außerdem werden Kanten nicht als eigenständige Komponenten, sondern als Unterelement von Transitionen definiert, da dies eher dem intuitiven Vorgehen bei der Modellierung von Methoden- oder Funktionsaufrufen in IT-Prozessen entspricht. Die Erweiterbarkeit der GWorkflowDL ist über generische property-elemente gegeben, mit denen die einzelnen Komponenten des Petrinetzes annotiert werden können. Weitere GWorkflowDL-Beispiele, darunter auch die GWorkflowDL-Repräsentation einiger Workflow-Muster aus [AH02] (Workflow Patterns) findet man in der Workflow-Registry des myexperiment-projektes [My09]. Um komplexe Prozesse in verschiedenen Detailabstufungen zu modellieren, können ähnlich wie die Hinterlegungen in EPKs einzelne Transitionen mit Unternetzen verknüpft werden. Ein Beispiel ist in Abbildung 4 dargestellt. Die Anschlussbedingungen sind über die Kantenanschrif- Seite 13 von 44

14 Methodik der Prozess-basierten Integration der mentdienste ten gegeben. Bei jedem Eintreten der Transition wird eine neue Instanz des Unterprozesses gebildet und jeweils eine Marke von jeder Eingabestellen des übergeordneten Netzes an die Stelle des Unternetzes kopiert, die durch die entsprechende Kantenanschrift gegeben ist. Nachdem das Unternetz vollständig ausgeführt wurde, also keine Transition mehr aktiviert ist, werden jeweils eine Marke von der durch die ausgehenden Kantenanschriften bezeichneten Stellen vom Unternetz wieder in das übergeordnete Netz kopiert Abbildung dynamischer Prozesse und Ressourcen auf ausführbare Workflows Aktuelle Business Process Management-Systeme gliedern IT-gestütztes Geschäftsprozessmanagement in der Regel in drei getrennte, aufeinanderfolgende Phasen der Prozessmodellierung, Prozessautomatisierung und Prozessausführung und -beobachtung [Pe09]. In der Phase der Prozessmodellierung werden fachliche Modelle der Geschäftsprozesse erstellt und analysiert (vgl. Referenzprozess aus Abschnitt 2). In der Phase der Prozessautomatisierung werden aus fachlichen Modellen technische Prozesse abgeleitet, welche als Grundlage für die IT-gestützte Automatisierung dienen. Der Begriff Automatisierung bezieht sich hierbei auf das Prozessmanagement; ein Prozess gilt somit auch dann als automatisiert, wenn einzelne Aktivitäten durch Personen ausgeführt werden. In der Phase der Prozessausführung und -beobachtung schließlich erfolgt die Ausführung der Prozesse in einer SOA-, Grid- oder Cloud-Umgebung (im Projekt basierend auf der Beschreibung mit der im letzten Abschnitt beschriebenen GridWorkflowDL). Für die drei Phasen der Modellierung, Automatisierung und Ausführung/Beobachtung kommen jeweils eigenständige Methoden und Werkzeuge zum Einsatz, welche die Durchlässigkeit zwischen den Phasen behindern. Der vorliegende Abschnitt beschreibt das gewählte Vorgehen, das dynamische Prozesse durch eine engere Verzahnung der drei BPM-Phasen besser unterstützen soll (vgl. [Ho09]). Basis hierfür ist die Verwendung eines über weite Teile einheitlichen Prozessbeschreibungsformalismus, der eine einfache Abbildung zwischen den Phasen ermöglicht und somit eine direkte Interaktion zwischen Modellierung, Automatisierung und Beobachtung zulässt. Dadurch soll eine bessere Abstimmung zwischen fachlichen und technischen Prozessen realisiert werden, was insbesondere für dynamische Prozesse zweckdienlich ist. Ad-hoc-Änderungen in fachlichen Prozessen (z. B. Unterauftragnehmer insolvent ) können dadurch einfacher an die technische Ebene durchgereicht werden. Andersherum ist eine schnelle Reaktion auf Änderungen in der technischen Ebene (z. B. Datenspeicher voll ) eine wichtige Voraussetzung für die effektive Anwendbarkeit von BPM. Wie in Abbildung 3 dargestellt, lässt sich die Dynamik von Prozessen und Ressourcen anhand der Variabilität von Umwelt und Prozess in vier Kategorien unterteilen: 1. Konstanter Prozess in konstanter Umwelt. Ein Beispiel hierfür sind Unternehmen, die in stabilen Märkten mit einem konstanten Prozess immer gleichartige Leistungen anbieten. 2. Konstanter Prozess in dynamischer Umwelt. Ein Beispiel hierfür ist ein Industrieunternehmen, dessen Fertigungsprozess tolerant ausgelegt sein muss gegenüber dem Ausfall einer Ressource wie einer Maschine. 3. Dynamischer Prozess in konstanter Umwelt. Ein Beispiel hierfür wäre ein Unternehmen, dessen Produkte aufgrund einer Unternehmensübernahme ggf. mit anderen (zeitlich konstanten) Ressourcen erstellt werden müssen. 4. Kombination von 2+3, d. h. sowohl der Prozess ändert sich als auch die Umwelt. Ein Beispiel hierfür wäre ein Unternehmen, dessen Geschäftsprozess ständig an sich ändernde Märkte und Ressourcen angepasst werden muss. Seite 14 von 44

15 BauVOGrid-Bericht A-5.1 Abbildung 3: Kategorisierung der Dynamik von Prozessen und deren Umwelt. Schwerpunkt des gewählten Ansatzes ist die Berücksichtigung von Prozess- und Ressourcendynamik (Quadrant 4). Bezüglich der drei Phasen Modellierung, Automatisierung und Beobachtung ergeben sich dabei unterschiedliche Lösungsansätze: Phase 1 Prozessmodellierung: Die Auswirkung von Änderungen in fachlichen Prozessen werden direkt während der Modellierung analysiert und simuliert. Falls andersherum ein fachlicher Prozess auf Grund der variablen Umwelt modifiziert werden muss z. B. wegen eines Ressourcenengpasses so werden die hierfür notwendigen Informationen von der technischen Ebene zurück auf die Ebene der fachlichen Prozessmodellierung abgebildet und dienen dort als Entscheidungshilfe. Phase 2 Prozessautomatisierung: Änderungen von fachlichen Prozessmodellen werden handhabbar durch möglichst automatische Abbildung auf technische, ausführbare Prozessmodelle sowie späte Bindung der Fachfunktionalitäten an Ausführungskomponenten. Durch Einführung einer Virtualisierungsschicht, die es ermöglicht, ausführbare Prozesse unabhängig von der verfügbaren Infrastruktur zu formulieren, wird zusätzliche Unabhängigkeit gegenüber einer variablen Umwelt gewonnen. Phase 3 Prozessausführung und -beobachtung: Variable Ressourcen und Komponenten werden handhabbar durch Mechanismen der Lastverteilung und dynamischen Ressourcenverteilung sowie durch zeitnahe Ressourcenüberwachung und fehlertolerante Ausführung. Unterstützt wird dies durch eine flexible, z. B. Constraint-basierte Ressourcenplanung, die ein dynamisches und automatisches Nachplanen bei Änderungen der Prozesse oder der Umwelt ermöglicht. Die folgenden Abschnitte stellen die realisierten Arbeiten bezüglich Modellierung (Abschnitt 3.2.1), Automatisierung sowie Ausführung und Beobachtung (Abschnitt 3.2.3) von dynamischen Prozessen noch einmal strukturiert dar. Seite 15 von 44

16 Methodik der Prozess-basierten Integration der mentdienste Modellierung fachlicher und technischer Prozesse Zur Modellierung fachlicher Prozesse existieren im Wesentlichen zwei etablierte Modellierungsnotationen: Die Business Process Modeling Notation (BPMN) [Ob09] sowie die Ereignisgesteuerten Prozessketten (EPK) [KS92]. Aufgrund der einfacheren Struktur sowie der semantischen Nähe zu Petrinetzen welche im Projekt der Prozessautomatisierung zugrunde liegen basiert die Geschäftsprozessmodellierung im kollaborativen Projektkontext auf EPKs. Zum Austausch von Prozessmodellen, die mit Hilfe einer Ereignisgesteuerten Prozesskette beschrieben werden, hat sich die Event-driven Process Markup Language (EPML) durchgesetzt [MN04]. Die XML-basierte Notation gestattet eine Plattform- und sprachunabhängige Repräsentation von EPK-Modellen und wird von einigen Werkzeugen am Markt direkt unterstützt. Die Modellierung technischer Prozesse basiert auf High-Level-Petrinetzen gemäß ISO/IEC [Is04] und dem entsprechenden XML-Austauschformat GworkflowDL (vgl. Abschnitt 3.1), welches neben der Modellierung und Analyse von technischen Prozessen auch eine direkte Automatisierung und Überwachung der Prozesse unterstützt Überführung von fachlichen Geschäftsprozessen in ausführbare IT-Prozesse Um EPKs in ausführbare IT-Prozesse zu überführen, haben wir einen Konverter entwickelt, welcher EPML-Prozessbeschreibungen unter Verwendung einer XSLT-Transformation [Cl99] in GworkflowDL-Workflowbeschreibungen übersetzt [Ho09b]. Zugrunde liegt hierbei eine Abbildung von EPKs auf Petrinetzen ähnlich zu der in [Aa99] beschriebenen. Während van der Aalst jedoch jeweils einzelne EPK-Komponenten auf eine Kombination von Stellen, Transitionen und Kanten abbildet, haben wir eine Abbildungsvorschrift verwendet, welche Ereignisse, Funktionen und Konnektoren einer EPK in genau eine Transition oder Stelle eines Petrinetzes mit den ggf. notwendigen Eingabe- und Ausgabekanten übersetzt. Dadurch wird der Transformationsprozess einfacher und benötigt zudem keine Erweiterungen der EPK, falls zwei Konnektoren (z.b. XOR und AND) direkt miteinander verbunden sind. Analog zu [Aa99] ignorieren auch wir den OR- Operator, zumal er in der Praxis wenig eingesetzt wird und zudem, je nach Definition des OR- Operators, durch eine Kombination aus AND und XOR ersetzt werden kann. Abbildung 4: Beispiel eines hierarchischen GworkflowDL-Netzes bei dem die Transition SUB auf ein Unternetz verweist, welches bei jedem Eintreten der Transition ausgeführt wird. Seite 16 von 44

17 BauVOGrid-Bericht A-5.1 Die verwendeten Abbildungsvorschriften zur Transformation der einzelnen Komponenten von EPKs in Petrinetze sind in Abbildung 6 dargestellt. Während Ereignisse und XOR-Konnektoren von EPKs auf jeweils eine Stelle des Petrinetzes abgebildet werden, erfolgt die Abbildung von Funktionen und AND-Konnektoren jeweils durch eine Transition. Bei den Kanten gibt es jedoch zwei Sonderfälle: Kanten in einer EPK, die eine Funktion mit einem AND-Konnektor verbinden, werden im Petrinetz durch eine zusätzliche Stelle ergänzt, da sowohl Funktionen als auch AND- Konnektoren durch Transitionen abgebildet werden und eine direkte Kante zwischen zwei Transitionen in einem Petrinetz nicht erlaubt ist. Analog hierzu werden Kanten zwischen Ereignissen und XOR-Konnektoren in EPKs durch eine zusätzliche Transition im Petrinetz ergänzt. Abbildung 5: Abbildung der Workflow-Aktivitäten von aktivierten Transitionen auf verfügbare Ressourcen. Direkte Kanten zwischen zwei Funktionen sind in EPKs zwar oftmals nicht erwünscht, aber in der Praxis durchaus anzutreffen. Durch das Weglassen von sogenannte Trivialereignisse (z. B. Brief ist an Post übergeben als Ergebnis einer Funktion Brief an Post übergeben ) kann ein EPK-Modell somit für den Nutzer kompakter dargestellt werden. Zudem gestatten auch die meisten Modellierungswerkzeuge derartig vereinfachte Modelle. Um auch diese unsauberen EPKs in korrekte Petrinetze zu überführen, wird eine Kante zwischen zwei Ereignissen im Petrinetz durch die Kombination einer Eingabekante, einer Transition und einer Ausgabekante dargestellt. Analog wird eine Kante zwischen zwei Funktionen im Petrinetz durch eine Ausgabekante, eine Stelle und eine Eingabekante dargestellt (nicht in Abbildung 6 gezeigt). Ein einfaches Beispiel einer Transformation einer EPK in ein Petrinetz zeigt Abbildung 7. Die Ereignisse A, B und D werden zu den Stellen A, B und C; die Funktionen D und E zu den Transitionen D und E. Die beiden XOR-Konnektoren werden jeweils durch eine Stelle abgebildet, der AND-Konnektor durch eine Transition. Zwischen die Stellen A und XOR, sowie zwischen B und XOR wird jeweils eine Transition eingefügt, alle anderen Kanten werden 1:1 abgebildet. Seite 17 von 44

18 Methodik der Prozess-basierten Integration der mentdienste Abbildung 6: Abbildungsvorschriften zur Transformation von EPKs in Petrinetze Mit den Transformationsvorschriften aus Abbildung 6 lässt sich somit die Übersetzung einer EPK in ein Petrinetz in einem Schritt durchführen, ohne wie bei [Aa99] zunächst die EPK um zusätzliche Komponenten erweitern zu müssen. Dieses Vorgehen produziert zwar in einigen Fällen einige redundante Stellen/Transitionen im Netz, welche sich aber leicht bei Bedarf wieder reduzieren lassen. Ein gewichtiger Unterschied zwischen EPKs und GworkflowDL-Netzen ist der, dass EPKs in der Regel den Kontrollfluss von fachlichen Prozessmustern beschreiben, während GworkflowDL- Netze konkrete Instanzen von ausführbaren (technischen) Prozessen inklusive der darin zu verarbeitenden Daten sind. Um eine EPK auf einen ausführbaren Prozess abzubilden, benötigt man neben den Funktionen, Ereignissen und deren Verknüpfungen daher folgende zusätzliche Informationen: Anfangsmarkierung (Kontrollmarken): Die Anfangsmarkierung gibt die Verteilung von Marken auf den Stellen des Petrinetzes zu Beginn der Ausführung an. Dabei wird in der GworkflowDL zwischen Kontrollmarken und Datenmarken unterschieden. Die Kontrollmarken der Anfangsmarkierung können dadurch generiert werden, dass die Startereignisse der EPK durch ein Attribut am Ereignis annotiert werden (z.b.: <attribute typeref= workflowstart />). Seite 18 von 44

19 BauVOGrid-Bericht A-5.1 Abbildung 7: Transformation einer EPK in ein Petrinetz analog zum Beispiel aus [Aa99]. Die Anschriften XOR und AND im Petrinetz dienen lediglich der Information, aus welchen Teilen der EPK die Komponenten herrühren und sind für die Funktion des Petrinetzes nicht notwendig. Anfangsmarkierung (Datenmarken): Komplexer stellt sich die Generierung der notwendigen Datenmarken auf den Stellen dar. Eine Möglichkeit stellt die Verwendung von Transitionen dar, die mit einer Workflow-Aktivität verknüpft sind, die aktiv im Rahmen des Prozesses aus den Kontrollmarken der Anfangsmarkierung Datenmarken erzeugen ( hole-daten-aktivität ). Bei diesem Vorgehen besteht die Anfangsmarkierung also nur aus Kontrollmarken. Eine zweite Möglichkeit ist die explizite Modellierung von Daten unter Verwendung von Informationsobjekten der EPKs. Diese werden üblicherweise mit Funktionen verbunden, um deren Relation zu Dokumenten oder anderen Daten in einer EPK darzustellen. Diese Informationsobjekte können in Datenmarken übersetzt werden, die auf ggf. zusätzlich zu erzeugende Eingabe- bzw. Ausgabestellen gelegt werden. Eine dritte Möglichkeit ist die Verwendung von speziellen Attributen an Ereignissen, analog zu den Kontrollmarken. So kann zum Beispiel in der EPML über ein Attribut <attribute typeref= data value= /> ein Ereignis mit dem Vorhandensein von bestimmten Daten in Verbindung gebracht werden. Ausführbare Aktivitäten (Operation): Die GworkflowDL zielt auf die konkrete Ausführung von Workflows in einem verteilten System ab. Als Mindestinformation benötigt es hierfür das <oc:operationclass>-element, welches die Klasse von Aktivitäten festlegt, die beim Eintreten einer Transition ausgeführt werden soll. Die technisch einfachste Art, diese Information in einer EPK vorrätig zu halten, ist über eine Namenskonvention, bei der der Name einer Funktion in einer EPK identisch ist mit dem Namen des entsprechenden <oc:operationclass>-elements. Der ResourceMatcher, der für die Suche passender Dienste zuständig ist, muss dies dann in seiner Konfiguration berücksichtigen. Des Weiteren können auch Ontologiedienste verwendet werden, um Funktionsnamen oder zusätzliche Kennungen auf passende Aktivitätsklassen abzubilden. Die verschiedenen Möglichkeiten der Annotation sind in Abbildung 8 exemplarisch dargestellt. Seite 19 von 44

20 Methodik der Prozess-basierten Integration der mentdienste Kantenanschriften: Die Kantenanschriften der GworkflowDL stellen eine Beziehung zwischen den konkreten Daten (Marken auf Stellen) und bestimmten Funktionsparametern einer Workflow-Aktivität her. Eine EPK beschreibt jedoch einen abstrakten Prozessablauf, der in der Regel unabhängig von konkreten Daten ist und daher diese Beziehung nicht enthält. Um trotzdem die Kantenanschriften für den Datenfluss in einem GworkflowDL-Netz generieren zu können, benötigt man somit eine externe Wissensbasis, die zum Beispiel Profile der Workflow- Aktivitäten mit deren Eingabe- und Ausgabeparametern vorhält. Wenn bei der Benennung der Daten gewisse Namenskonventionen eingehalten werden, können die dazu gehörenden Kantenanschriften z.b. auch direkt aus der WSDL-Schnittstellenbeschreibung des entsprechenden Web- Services extrahiert werden. <function id= 4 > <name>f</name> <attribute typeref= ontologyclassid value= fservice /> <attribute typeref= operationclass value= urn:dgrdl:service:f /> <attribute typeref= wsoperation value= f /> </function> Abbildung 8: EPML-Beispiel einer Annotierung einer EPK-Funktion durch Attribute, die für die Zuordnung einer Funktion zu ausführbaren Workflow-Aktivität verwendet werden können. Hinterlegungen: Hinterlegungen einer EPK können wie in Abbildung 4 gezeigt hierarchisch durch Unter-Workflows abgebildet werden, auf die innerhalb einer Transition verwiesen werden kann. Abbildung 9 zeigt exemplarisch den Ausschnitt aus dem XSLT-Stylesheet, welcher für die Transformation eines Ereignisses der EPK (event) in eine Stelle des Petrinetzes (place) zuständig ist. Die EPK-Annotation control.token, workflowstart oder startevent wird dabei in eine Marke (token) des Petrinetzes übersetzt, welches Bestandteil der Anfangsmarkierung ist. <! convert event to wf:place <xsl:template match= event > <xsl:element name= place namespace= > <xsl:attribute name= ID >p<xsl:value-of /></xsl:attribute> <xsl:apply-templates select= name /> <xsl:apply-templates select= graphics/position /> <xsl:apply-templates select= attribute /> <! convert token attribute to token <xsl:for-each select= (attribute[@typeref= control.token ] attribute[@typeref= workflowstart ] syntaxinfo[@implicittype= startevent ])[1] > <xsl:element name= token namespace= > <xsl:element name= control namespace= >true</xsl:element> </xsl:element> </xsl:for-each> </xsl:element> </xsl:template> Abbildung 9: Ausschnitt aus dem XSLT-Stylesheet zur Konvertierung von EPML nach GworkflowDL. Der EPK-Gegenpart der GworkflowDL-Komponente wird über ein <property>-element im Petrinetz annotiert, sodass das Petrinetz sehr einfach wieder auf die ursprüngliche EPK abgebildet werden kann z.b. zur Darstellung des Fortschritts des Prozessablaufes in der EPK und zur Synchronisation bei Ad-hoc-Änderungen. Seite 20 von 44

21 BauVOGrid-Bericht A-5.1 Abbildung 10 zeigt erneut den gewählten Lösungsansatz für die schrittweise und zum großen Teil automatisierte Abbildung von fachlichen Prozessbeschreibungen auf die jeweils geeigneten und verfügbaren Ressourcen. Die Geschäftsprozesse werden zunächst annotiert und dann auf abstrakte technische Prozesse (gelb) abgebildet, in diesem Fall durch die Abbildung von EPKs auf GworkflowDL-Dokumente [Ho09]. Jeder Aktivität werden dann zunächst mit Hilfe des ResourceMatcher-Dienstes Service-Kandidaten (blau) zugeordnet, welche die entsprechende Funktionalität bereitstellen. Ein Scheduler wählt einen der Kandidaten aus (grün) und führt die Aktivität auf den entsprechenden Ressourcen aus. Ein Beispiel einer Überführung eines EPK- Modells in einen ausführbaren GworkflowDL-Prozess ist in Abbildung 11 dargestellt. Abbildung 10: Überführung von fachlichen Prozessbeschreibungen in automatisierte Prozesse Automatisierung und Beobachtung der Prozesse Der von Fraunhofer FIRST entwickelte Grid Workflow Execution Service (GWES) ermöglicht die Automatisierung und das interaktive Management von komplexen und dynamischen Prozessabläufen in Serviceorientierten Architekturen oder Grid-Umgebungen [Ho08, Ho06, GH07, Vo08]. Durch die Marken des Petrinetzes wird nicht nur ein Prozessmuster, sondern auch der Zustand einer jeden Prozessinstanz beschrieben. Dies ermöglicht die direkte Überwachung der Prozesse sowie eine einfache Realisierung von Fehlertoleranzmechanismen. Unter Anderen wird der GWES derzeit auch in den D-Grid-Projekten MediGRID, MedInfoGrid, PneumoGRID und TextGrid eingesetzt. Das Grid-Workflow-Management-System besteht aus mehreren Diensten, deren Kerndienst der Grid Workflow Execution Service (GWES) ist, welcher Workflows automatisch, persistent und fehlertolerant auf verteilten IT-Ressourcen ausführt. Neben dem GWES besteht das Grid- Workflow-Management-System aus einer Ressourcen- und Workflow-Datenbank, einem ResourceMatcher zur Abbildung von abstrakten Job-Anfragen auf verfügbare Hardware- und Software-Ressourcen, einem Monitoring-System, welches über verteilt installierte ResourceUpdater alle 10-20s Informationen über die aktuelle Auslastung der Zielsysteme erhält, sowie einem Scheduler, welcher die Auswahl der Zielsysteme optimiert. Seite 21 von 44

22 Methodik der Prozess-basierten Integration der mentdienste Fachlicher Prozess als EPK Technischer Prozess als GworkflowDL Abbildung 11: Beispiel einer Überführung eines einfachen Geschäftsprozesses aus dem Bereich ment im Bauwesen in einen ausführbaren Grid-Workflow Der GWES selber kann sowohl als Web-Service online zum Beispiel in einer verteilten Grid- Umgebung sowie offline als Java-Bibliothek auf mobilen Endgeräten lokal genutzt werden. Mit Hilfe einer hierarchischen Modellierung der Prozesse lassen sich so die lokalen Workflows autark auf den mobilen Endgeräten ausführen und an den Eingabe und Ausgabestellen mit einem übergeordneten Workflow verknüpfen. Die Schritte, die intern im GWES bei der Ausführung von Workflows durchgeführt werden, sind in vereinfachter Form in Abbildung 12 schematisch dargestellt. Abbildung 13 zeigt die Web-Schnittstelle der online-version des GWES. Unter der Adresse kann der GWES inklusive Source-Code und Dokumentation heruntergeladen werden. Die Lizenzbedingungen erlauben die kostenfreie Nutzung für eigene Forschung und Lehre. Die in den folgenden Kapiteln beschriebenen mobilen Dienste sind derzeit meist noch in statische, unveränderliche Prozesse eingebettet, sodass hier zunächst die Workflows fest in die Anwendungslogik der mobilen Anwendungen einprogrammiert sind. Durch den GWES ergeben sich für die Zukunft zusätzliche Möglichkeiten die Dienste flexibel direkt auf den mobilen Endgeräten zu orchestrieren, um so besser auf dynamische Prozesse und Ressourcen reagieren zu können. Seite 22 von 44

23 BauVOGrid-Bericht A-5.1 Analysiere Workflow Wähle nächste aktivierte Transition Verfeinere Workflow ResourceMatcher, Scheduler, Prüfe Bedingungen Keine aktivierte Transition und keine laufenden Aktivitäten Workflow beendet Transition == abstrakt Transition!= abstrakt Sperre Marken und starte Aktivität asynchron/nebenläufig Wenn Aktivität beendet: führe Transition aus entferne Eingabemarken und erzeuge Ausgabemarken Abbildung 12: Vereinfachter Ablauf zur GWES-internen Ausführung von GWorkflowDL-basierten Prozessen Abbildung 13: Screenshot der Web-Schnittstelle zum GWES am Beispiel eines ZMMS-Workflows Seite 23 von 44

24 Mobile Dienste 4. Mobile Dienste In Abbildung 14 wird der Workflow zur Mängelaufnahme schematisch dargestellt. Im ersten Schritt chritt erfolgt die Ortung mit Hilfe einer RFID. Über die in dieser RFID gespeicherten InformaInform tionen lässt sich mit Hilfe einer Zuordnungs-Datenbank Zuordnungs Datenbank die Ortsinformation abrufen. Im nächsten Schritt erfolgt die Erfassung des Mangels durch den Benutzer. Wenn der Nutzer hierbei den Mangel mit einem separaten Fotoapparat (also nicht mit der eingebauten Kamera des PDA) fotofot grafiert, wird aus der Mangel-ID ID ein 2D-Barcode 2D Barcode generiert, der auf dem PDA angezeigt und vom Benutzer zusammen mit dem Mangel fotografiert wird. wird. Sind alle Mängel erfasst (bzw. am Ende eines Arbeitstages) wird der PDA mit dem zentralen mentsystem synchronisiert. Alle Mängelfotos werden in ein Medienmanagementsystem hochgeladen. Zur Zuordnung der separat (nicht mittels des PDA) aufgenommenen aufgenommenen Bilder wurde ein webbasierter Service realisiert, der in jedem dieser Bilder den 2D-Barcode 2D Barcode lokalisiert und dekodiert. Zur Steigerung der Effizienz wurden hierbei Vorkehrungen getroffen, um Teilaufgaben parallel und im Grid verteilt abarbeiten zu können. Abbildung 14 Workflow zur Mängelerfassung 4.1. Ortung Bei der Mangelaufnahme wird vielfach die Position des Mangels aufgenommen. Dieser Prozess lässt sich durch eine automatisierte Ortung vereinfachen. Im Rahmen dieses Arbeitspunktes Arbeit wurden verschiedene Ortungstechniken evaluiert (GPS, W-LAN, W LAN, RFID) und eine für die AnwenAnwe dungsdomäne gut geeignete RFID-Lösung RFID prototypisch implementiert. Die Ortung erfolgt im Rahmen dieses Projektes auf Raumbasis. Seite 24 von 44

25 BauVOGrid-Bericht A-5.1 Eine Nutzung des Global Positioning Systems (GPS) ist auszuschließen, da die Signalstärke innerhalb von Gebäuden für eine gute Ortung zu schwach ist. Des Weiteren liegt die Messgenauigkeit im Meterbereich. Somit wäre eine Ortung auf Raumbasis nicht mehr möglich. Der Vorteil von W-LAN Ortung liegt in der Benutzung von vorhandener Infrastruktur. Insbesondere Bürogebäude werden mit einer Vielzahl an W-LAN Access Points ausgestattet, die für eine W-LAN Ortung benutzt werden. Diese Access Points sind allerdings nicht in allen Bauphasen verfügbar. Somit müssten diese temporär an geschützten Stellen aufgestellt und mit Strom versorgt werden, was unter Umständen nicht oder schwer möglich ist. Des Weiteren weisen die gemessenen Positionen starke Sprünge von bis zu 5 Metern auf (siehe Abbildung 15), wodurch auch diese Ortungsmöglichkeit nicht nutzbar ist. Abbildung 15 Messungenauigkeiten bei W-LAN Ortung Bei der RFID-Technik ist zwischen aktiven und passiven RFID-Tags zu unterscheiden. Aktive Tags verfügen über eine eigene Stromversorgung und sind somit auch aus größerer Entfernung noch auszulesen. Die zum Lesen eines passiven Tags benötigte Energie wird durch das Lesegerät bereitgestellt, das diese Tags über keine eigene Stromversorgung verfügen. Allerdings sind sie nur aus kleinen Entfernungen (cm Bereich) auslesbar. Dies stellt allerdings keinen Nachteil dar, da der Scanprozess Teil des mobilen Workflows ist und die Ortung außerdem eindeutig ist. Die Tags insbesondere die passiven sind robust, billig und visionär auch innerhalb von intelligenten Bauteilen einsetzbar. Aus diesem Grund wurden im Rahmen des Projektes passive RFID- Tags der ISO eingesetzt. Auf diesen Tags sind insgesamt 112 Byte speicherbar, was ausreicht, um alle für die Ortung notwendigen Daten abzulegen. Diese bestehen aus der globalen Raum-ID (32 Byte), einer Raumbezeichnung (16 Byte), einer Ebenenbezeichnung (8 Byte) sowie einer Projektbezeichnung (56 Byte). Für die Anwendung im Rahmen des Pilotprojektes im Dresdner Rudolf Harbig Stadion wurden die Datentypen entsprechend angepasst (ID, Blockbezeichnung, Toiletten- bzw. Reihenbezeichnung, Projektbezeichnung). Die RFID-Ortungskomponente wurde als Webservice implementiert sowie in ein mentsystem integriert. Die Implementierung als Webservice hat den Vorteil, dass beliebige Programme auf diesen zugreifen können. Mit beiden Varianten ist es möglich RFIDs zu lesen bzw. diese mit den erwähnten Ortsinformationen zu beschreiben. Seite 25 von 44

26 Mobile Dienste 4.2. Site Survey Eine initiale Begehung der Baustelle (Site Survey) ist notwendig da derzeit noch keine intelligenten Bauteile 1 verfügbar sind. Diese Begehung der Baustelle muss nur einmal erfolgen und dient als Grundlage für die spätere Mangelaufnahme. Die für die Site Survey benötigte Datenbank, welche die bereits im vorigen Abschnitt erwähnten Informationen enthält, wird automatisch aus einem digitalen Bauplan erzeugt und als database.csv gespeichert. Der mobile Site Survey Client erzeugt aus dieser Datenbank eine Baumansicht (siehe Abb. 16). In Dieser kann der Benutzer leicht in der Struktur des zu begehenden Objekts navigieren und das entsprechende Element der Objektstruktur (Raum, Stadionblock, Sitzreihe, o.ä.), welches verortet werden soll, auswählen. Abbildung 16 Baumansicht (Ausschnitt) der Beschreibung des Rudolf Harbig Stadions. Abbildung 17 Abgehakte Blätter des Baumes noch erfolgreichem Schreiben einer RFID Bei der Begehung werden RFIDs an einer zuvor definierten Stelle (z.b. Türrahmen oder jeweils die äußeren Stühle einer Reihe im Stadion) angebracht. Anschließend werden die ausgewählten Ortsinformationen in der RFID gespeichert. Das Beschreiben einer RFID ist nur möglich, wenn ein Blatt des Baumes gewählt wurde. Wurde eine RFID erfolgreich beschrieben, so wird die mit dieser RFID verknüpfte Ortsinformation im mobilen Client als erledigt abgehakt (siehe Abb. 17). Der Fortschritt der Site Survey wird beim Verlassen des Programms gespeichert, so dass die Begehung nicht in chronologischer Reihenfolge erfolgen muss Mobiles mentsystem (MMS) Nach erfolgreicher Verortung von bestimmten Örtlichkeiten eines Gebäudes im Rahmen der Site Survey kann die Mangelerfassung durchgeführt werden. Im Hauptmenü stehen dem Benutzer zwei Möglichkeiten zur Verfügung (Mangel erfassen, RFID zuweisen; siehe Abbildung 18). Durch Drücken des Buttons neuen Mangel erzeugen werden dem Benutzer weitere Auswahl- 1 Bauteile, die beispielsweise mit Ortungssensorik oder anderer Sensorik, mit denen der Lebenszyklus des Bauteils nachverfolgt werden kann, ausgestattet sind. Seite 26 von 44

27 BauVOGrid-Bericht A-5.1 möglichkeiten zur Beschreibung des Mangels zur Verfügung gestellt. Wurde ein oder mehrere Mängel erfasst ersichtlich durch den Zähler im rechten Teilbild von Abbildung 18 kann der Benutzer diesem oder diesen Mängeln eine ID die in einer RFID gespeichert wurde zuweisen (Button RFID zuweisen ). Auf diesen Button wird etwas später noch näher eingegangen. Abbildung 18 Hauptmenü des mobilen MMS. Nach Drücken des Buttons neuen Mangel erzeugen erscheint das Menü aus Abb. 19. Gleichzeitig wird die Ordnerstruktur BauVOGrid Pilot\tmp\tmp\ auf dem PDA erzeugt. Dabei handelt es sich um einen temporären RFID Ordner und einen temporären Mangelordner. Der Benutzer hat in diesem Menü die Möglichkeit einen Mangelbeschreibungsdialog aufzurufen (Button Mangelbeschreibung ), mehrere Fotos und Audiofiles aufzunehmen (Button Foto aufnehmen, bzw. Audio aufnehmen ) sowie textuelle Beschreibungen einzugeben (Button Freitext eingeben ). Die Erfassung der Daten kann in beliebiger Reihenfolge erfolgen. Die aufgenommenen Daten werden im temporären Ordner BauVOGrid Pilot\tmp\tmp\ in entsprechenden Unterordnern gespeichert (siehe Abb. 20). Wird der Button Mangel verwerfen gedrückt, werden diese temporären Daten gelöscht. Nach Betätigung des Buttons Mangel speichern wird eine ID erzeugt und der temporäre Mangelordner in selbige umbenannt (siehe Abbildung 21). Seite 27 von 44

28 Mobile Dienste Abbildung 19 Mangelbeschreibungsmenü Abbildung 20 temporär gespeicherte Mangeldaten Abbildung 21 Umbenennung des temporären Mangelordners in eine ID Abbildung 22 Mangelbeschreibungsdialog für das Rudolf Harbig Stadion (Auszug). Nach Drücken des Buttons Mangelbeschreibung erscheint der Dialog aus Abb. 22. In diesem hat der Benutzer die Möglichkeit einige typischerweise auftretende Mängel auszuwählen. Die Informationen werden nach Drücken der Speichern-Taste in der Datei Mangelbeschreibung.txt abgelegt. Reichen die Informationen dieses Dialoges nicht aus, so hat der Nutzer des Weiteren die Möglichkeit detailliertere Beschreibungen des Mangels mit Hilfe von Fotos, Audiodateien oder Freitext anzulegen. Seite 28 von 44

29 BauVOGrid-Bericht A-5.1 Wie bereits erwähnt dient der Button RFID zuweisen der Verknüpfung von Mängeln mit den Ortsinformationen, die in einer RFID gespeichert sind. Beim Drücken dieser Taste wird eine RFID, die sich dafür natürlich in der Nähe befinden muss, gescannt. Nach erfolgreichem Lesen wird der temporäre RFID Ordner in die in der RFID abgelegt ID umbenannt (siehe Abbildung 23). Somit sind alle zuvor gespeicherten Mängel dieser ID zuzuordnen. Beim Verlassen des Programmes werden die gespeicherten Informationen in XML Dateien überführt (siehe Abbildung 24) Abbildung 23 Umbenennung des temporären RFID Ordners in die in einer RFID abgelegte ID Abbildung 24 Mangelbeschreibung als XML Datei. Seite 29 von 44