Proof of Concept für das Service Design Studio und Supply Chain Execution

Transkript

1 Verbundprojekt Service Design Studio Proof of Concept für das Service Design Studio und Supply Chain Execution Version: 1.0 Arbeitspaket: Arbeitspaket 1: Service Design Environment Autor(en): Dr.-Ing. Heiko Gsell, Fraunhofer ISST Seite 1

2

3 Partner im Verbundvorhaben Service Design Studio Fraunhofer ISST Orga Systems SOPERA tarent Seite iii

4

5 Über dieses Dokument Dieses Dokument beinhaltet ein Proof of Concept für das Service Design Studio (SDS). Das SDS ist ein Web-basiertes Werkzeug zur Anreicherung existierender Logistik-IT-Dienste um Spezifikationen nicht-funktionaler Eigenschaften. Solche nicht-funktionalen Eigenschaften können z.b. die Absicherung (d.h. Authentisierung und Autorisierung), den jeweiligen Service Level oder die Abrechnung der Dienstnutzung betreffen. Mit dem SDS können somit ganzheitliche IT- Dienstbeschreibungen in vereinheitlichter Form erzeugt werden. Die anschließend zur Laufzeit eines so angereicherten IT-Dienstes zusätzlich zur Verfügung stehenden Informationen können dann von Endkunden bei der Suche nach geeigneten IT-Diensten berücksichtigt werden. Um die Funktionsweise des SDS nachzuweisen, wird in diesem Dokument zunächst ein Beispielszenario aus dem Verbundprojekt Supply Chain Execution beschrieben. Dieses Szenario wird in seine Prozesselemente zerlegt und analysiert. Mit den Analysen werden die für das Proof of Concept relevanten Serviceaufrufe identifiziert und mittels SOA ML dokumentiert. Auf Basis der Serviceaufrufe werden die Methodenaufrufe, die zum Anstoßen der Mehrwertdienste erforderlich sind, ermittelt und in einem Sequenzdiagramm beschrieben. Das Diagramm visualisiert die Kommunikation zwischen einem Simulationsservice und den an diesen Service anzubindenden Mehrwertdiensten. Der Simulationsservice beschreibt für den Fall, dass im Zuge einer Qualitätskontrolle Fehler bzw. die Nicht-Erfüllung von Qualitätsstandards von Bauteilen bei der Möbelmontage identifiziert werden, die erforderlichen Nacharbeiten. Neben der Darstellung der notwendigen Demontage- und Montageschritte prüft der Service die Verfügbarkeit der ersatzweise benötigten Bauteile sowie deren Bereitstellungszeit; er erlaubt eine Voraussage über den Aufwand, der für die Beseitigung der Qualitätsmängel einzusetzen ist. Der Simulationsservice stellt somit ein wesentliches informationstechnisches Element im Prozess der Möbelproduktion dar. Zum Abschluss des vorliegenden Proof of Concept werden die Schnittstellen der Mehrwertdienste zum Simulationsservice und zu weiteren Systemen auf der jeweiligen Cloud-Plattform visualisiert und die Nutzung des Service Design Studios zur Anbindung dieser Mehrwertdienste an den Simulationsservice dargestellt. Mit diesen Darstellungen ist die Funktionalität des Service Design Studios entsprechend der Zielsetzung seiner Entwicklung nachgewiesen. Seite v

6

7 Inhaltsverzeichnis ÜBER DIESES DOKUMENT... V INHALTSVERZEICHNIS... VII 1 EINLEITUNG ZWECK DES DOKUMENTS ZIELE UND UMFANG DES PROOF OF CONCEPTS FÜR DAS SDS UND FÜR SCE VERWEISE AUF SONSTIGE RESSOURCEN UND QUELLEN ERLÄUTERUNGEN ZU BEGRIFFEN UND/ODER ABKÜRZUNGEN BEISPIELSZENARIO GESCHÄFTSPROZESS PROZESSABLAUF ABLAUF DER SERVICEAUFRUFE FÜR DIE FUNKTIONALEN SERVICES EINBETTUNG DER MEHRWERTDIENSTE IN DAS GESAMTSYSTEM SERVICEAUFRUFE UND ÜBERTRAGENE INFORMATIONEN BESCHREIBUNG UND FUNKTION DER HINZUZUFÜGENDEN MEHRWERTDIENSTE ABLAUF DER SERVICEAUFRUFE FÜR DIE MEHRWERTDIENSTE SYSTEMARCHITEKTUR MODELLIERUNG MIT DEM SERVICE DESIGN STUDIO KONZEPT DES SERVICE DESIGN STUDIOS NUTZUNG DES SERVICE DESIGN STUDIOS ASPEKTE ABGLEICH DES BEISPIELSZENARIOS MIT DEM SDS-KONZEPT FALLBEISPIEL RAHMENBEDINGUNGEN FÜR DIE AUSGESTALTUNG DER ASPEKTE MODELLIERUNG EINES ABRECHNUNGSASPEKTS MODELLIERUNG EINES SICHERHEITSASPEKTS ZUSAMMENFASSUNG UND AUSBLICK ABBILDUNGS- UND TABELLENVERZEICHNIS ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS LITERATURVERZEICHNIS Seite vii

8

9 1 Einleitung 1.1 Zweck des Dokuments Dieses Dokument beschreibt ein Proof of Concept für das Service Design Studio (SDS) sowie für Supply Chain Execution. Dazu werden die Serviceaufrufe an ein Assistenzsystem aus unterschiedlichen Kontexten und Domänen beschrieben, sodass daran aufgezeigt werden kann, was der jeweilige Service macht und welche Daten dieser Service für seine Ausführung benötigt. Die Untersuchungen und Darstellungen erfolgen entlang eines Beispiels aus der Qualitätskontrolle Endmontage in einem Geschäftsprozess zur Möbelherstellung. In diesem Beispiel wird eine Aktivität in dem genannten Prozess fachlich ausmodelliert. 1.2 Ziele und Umfang des Proof of Concepts für das SDS und für SCE Das wesentliche Ziel des Proof of Concept liegt im Nachweis der optimalen Aufgabenerfüllung eines mittels des SDS um nicht-funktionale Eigenschaften angereicherten Services und damit im Nachweis der komfortablen Abrechenbarkeit dieses Services, seiner hohen Sicherheit sowie der verlässlichen Überwachung und Einhaltung der für seine Ausführung festgelegten Service Level Agreements im Zusammenspiel mit den jeweils dahinter liegenden Systemen. Es soll damit aufgezeigt werden, welche Elemente das Service Design Studio an einem Service modelliert, wie es mögliche architektonische Rahmenbedingen berücksichtigen kann (kundenlokale vs. Web-basierte Systeme) und damit die Steuerung und Lenkung vor dem Hintergrund seiner Kern-Designfelder Abrechnung, Sicherheit und SLA realisiert. Ziel ist es somit, entlang des Beispiels aufzuzeigen, was ein Service-Entwickler wie mit dem Service Design Studio modellieren kann. 1.3 Verweise auf sonstige Ressourcen und Quellen Die Dokumente, die als Input bzw. begleitende Unterlagen für das vorliegende Dokument dienen, sind nachfolgend aufgelistet: Dokument Präsentation Präsentation Dokument Verbundvorhaben Service Design Studio: Konzeptpapier zum Service Design Studio, Version 1.0, Arbeitspaket 1 Service Design Environment, S. Steinbuß EffizienzCluster LogistikRuhr: Supply Chain Execution, , G. Yüzgülec EffizienzCluster LogistikRuhr: Service Design Studio, , S. Steinbuß Verbundvorhaben Service Design Studio: Glossary 1.4 Erläuterungen zu Begriffen und/oder Abkürzungen Der Begriff, die im vorliegenden Proof of Concept von großer Bedeutung und wiederholt genutzt wird ist, ist im Projekt-Glossar definiert. Dabei handelt es sich um den Begriff Aspekt, dessen Definition sich wie folgt darstellt [Gss11, S. 2 f.]: Ein Aspekt beschreibt eine nichtfunktionale Eigenschaft eines funktionalen SOA-Services. Aspekte Seite 9

10 können (a) zur Filterung bei der Suche nach geeigneten SOA-Services oder (b) zur Gewährleistung der Einhaltung nichtfunktionaler Eigenschaften beim Aufruf von Services genutzt werden. Ein Aspekt definiert einen konfigurierbaren Typ für spezifische nichtfunktionale Eigenschaften. Ist ein Aspekt komplett konfiguriert (d.h. alle Eigenschaften bzw. Parameter des Aspekts sind mit Werten versehen), und wird an einen Service gebunden, so wird eine Aspekt-Instanz erzeugt. Genauer gesagt können Aspekt-Instanzen nicht nur an einen Service, sondern auch direkt an einzelne Service-Operation gebunden werden. Zusätzlich gibt es noch Aspekt-Template: In einem Aspekt- Template können einige oder alle Parameter des zu Grunde liegenden Aspekts mit sinnvollen Werten vorbelegt sein; das Aspekt-Template ist im Gegensatz zu einer Aspekt-Instanz jedoch noch nicht an einen Service oder eine Service-Operation gebunden. Beispiel: Authentisierung, Abrechnungsmodell, Kosten. Seite 10

11 2 Beispielszenario Für das Proof of Concept des Service Design Studios wird ein Beispielszenario aus dem Verbundprojekt Supply Chain Execution herangezogen, das teilweise durch informationstechnische Services gesteuert wird. Diese Services werden durch logistische Assistenzsysteme (LAS) der SCE (Supply Chain Execution) ausgeführt, welche die Aufgaben Zustandserfassung & Bewertung, Entscheidungsunterstützung und Entscheidungsdurchführung wahrnehmen. Bei den LAS handelt es sich um IT-Systeme oder Funktionen, die eine effiziente Steuerung logistischer oder produktionstechnischer Netzwerke unterstützen. Dazu werden bspw. aktuelle Sensordaten genutzt, die in der SCE-Infrastruktur erzeugt, durch einen sog. Premiumservice Sensordatenhandling erfasst und durch diesen Service an ein LAS übermittelt werden. Ggf. werden die erfassten Sensordaten ergänzend in ein Verhältnis zu Daten aus Backend-Systemen gesetzt. Das Spektrum der LAS reicht von der reinen Anzeige der Informationen bis hin zur Ausführung von Aktionen (Steuerung) auf IT- Backendsystemen oder auf realen Objekten (Transportsysteme, Maschinen, etc.). Sie können mit einem Anwender über ein User-Interface kommunizieren oder als autonome Systeme in eine IT- Infrastruktur integriert werden. 2.1 Geschäftsprozess Die IT-Services, die durch das SDS erweitert werden, werden zur Unterstützung bzw. Durchführung definierter Aktivitäten eines Geschäftsprozesses genutzt. Dies gilt auch für das Beispielszenario, das die Supply Chain von einem Sägewerk über die Möbelherstellung bis hin zur Auslieferung der Möbel an den Kunden abbildet. Im Fokus des Beispielszenarios steht die Qualitätskontrolle innerhalb der Endmontage im Prozess Möbelherstellung (vgl. Abbildung 1). Für diese Aktivität wird das SCE-Beispiel abgebildet. Abbildung 1 SCE-Beispiel Qualitätskontrolle Endmontage Seite 11

12 Der Geschäftsprozess Möbelherstellung setzt sich aus neun Teilprozessen zusammen, von denen einer die Montage ist. Der Teilprozess Montage lässt sich wiederum in weitere Teilprozesse untergliedern. Die Qualitätskontrolle wird mehrfach im Montageprozess durchgeführt (vgl. Abbildung 1). Diese Aktivität wird durch den Premiumservice Sensordatenhandling informationstechnisch unterstützt. Der Premiumservice nimmt Daten des Oberflächenprofils des montierten Bauteils über einen Sensor auf. Auch werden über den Sensor die folgenden weiteren Informationen erfasst: - die Qualitätskennzahl (Oberflächenbewertung und Vollständigkeit), - Ort und Zeit, - der vorausgegangene Prozessschritt und - die Identifikationsnummer des kontrollierten Bauteils (Bauteil-ID) Die erfassten Daten werden an ein LAS namens OTD-NET übermittelt. 2.2 Prozessablauf Auf Basis der erfassten Daten erfolgt die weitere SCE-Steuerung des Prozesses durch das logistischen Assistenzsystem in einem definierten Prozessablauf, der in Abbildung 2 dargestellt ist. Dieser Ablauf zeigt den konzeptionellen Entwicklungsstand des Systems im Oktober Abbildung 2 SCE-Steuerung im Prozess, Auswahl der Systemfunktion Seite 12

13 Der Prozessablauf in Abbildung 2 zeigt die Qualitätskontrolle sowie die Schritte, die zur Auswahl einer Systemfunktion zur Vorbereitung der Nacharbeit erforderlich sind. Im ersten Schritt des Prozessablaufs werden die mittels des Premiumservice erfassten Qualitäts- und Prozessdaten mit den Auftragsinformationen (Auftragsnummer, Liefertermin, etc.) und den Artikeldaten (Qualitätsanforderungen, etc.) zusammen geführt. Diese Informationen und Daten stammen aus dem ERP-System des Möbelherstellers. Unter Heranziehung aller erfassten und abgerufenen Daten erfolgt die Prüfung, ob Nacharbeit erforderlich ist. Im Beispielszenario gehen wir davon aus, dass diese Qualitätskontrolle eine mindere Qualität anzeigt, sodass Nacharbeit erforderlich ist. Damit muss eine Abschätzung der Einflüsse der Nacharbeit erfolgen. Um zunächst festzulegen, auf welche Art diese Abschätzung erfolgen soll, werden die im rechten Strang der in Abbildung 2 dargestellten SCE-Steuerungsschritte durchlaufen. Demnach werden zur Auswahl der Steuerungsoption die folgenden Prozessschritte durchlaufen und entsprechende Dialoge auf einem mobilen Gerät angezeigt: - Nach der Prüfung, ob Nacharbeit erforderlich ist, wird das Prüfergebnis angezeigt, mit dieser Anzeige ist die Prüfung abgeschlossen; - Im nächsten Schritt wird im Display des Mobilen Gerätes eine Liste der Systemfunktionen angezeigt, aus denen eine Auswahl getroffen werden kann, im vorliegenden Fallbeispiel sind dies u.a. die Funktionen Monitoring, Szenario Manager und Impact Manager ; diese Funktionen bieten Zugang zu einer Auswertung der zeitlichen Entwicklung der Prüfergebnisse, zur Berechnung zu unterschiedlichen Szenarien auf Basis von Handlungsaktivitäten sowie zur Darstellung der Einflüsse, die die Prüfergebnisse auf den Montageprozess haben - Über das Display des mobilen Gerätes wird im Fallbeispiel die Funktion Szenario Manager ausgewählt Ausgelöst durch die getroffene Auswahl erfolgen die weiteren SCE-Steuerungsschritte und eine Anzeige der entsprechenden Dialoge im Display des mobilen Gerätes. Diese Schritte stellen sich wie folgt dar: - Auf Basis der Auswahl Szenario Manager wird hier eine Liste der verfügbaren Steuerungsoptionen angezeigt, aus der wiederum eine Auswahl getroffen werden kann. Für die getroffene Auswahl sind die Funktionen Nacharbeit im Verpackungsbereich, Nacharbeit nicht im Verpackungsbereich, Allokation Alternativbauteile und Verlassen des Systems zur Auswahl verfügbar; - Über das Display des mobilen Gerätes wird im Fallbeispiel die Funktion Nacharbeit im Verpackungsbereich ausgewählt; - Diese Auswahl steuert den nachfolgenden Service im vorliegenden Proof of Concept die Simulation der Nacharbeit im Verpackungsbereich an (vgl. Abbildung 3) Die angestoßene Simulation wird in einem separaten logistischen Assistenzsystem zur Entscheidungsunterstützung (OTD-NET) durchgeführt. Die Ergebnisse der Simulation werden von diesem Seite 13

14 LAS auf das anfragende Mobile Gerät übertragen und auf dessen Display angezeigt. Mit der Anzeige ist die Prüfung des Einflusses der Nacharbeit auf den gesamten Prozess abgeschlossen. Abbildung 3 SCE-Steuerung im Prozess, Auswahl der Steuerungsoption Eine wesentliche Aktivität im dargestellten Prozessablauf liegt in der Simulation der Nacharbeit im Verpackungsbereich. Diese Simulation wird durch einen eigenen Service durchgeführt, der im nachfolgenden Abschnitt detailliert dargestellt wird. 2.3 Ablauf der Serviceaufrufe für die funktionalen Services Die Simulation der Nacharbeit im Verpackungsbereich wird durch einen Simulationsservice mit definierten Serviceaufrufen innerhalb des Entscheidungsunterstützungssystems gesteuert. Serviceaufrufe bezeichnen das Anfragen eines Client-Programms an einen Service und das Bereitstellen der angefragten Informationen durch den Service, sie leiten somit die Kommunikation zwischen Client und Service ein. Der größte Anteil an Steuerungsoptionen fällt an die Bereitstellung von Informationen und Daten aus den unterschiedlichen Systemen der Akteure. Folgende Informationen und Daten müssen für die Simulation der Nacharbeit bereitgestellt werden: - Auftragsinformationen (Auftragsnummer, Liefertermin, etc.) aus dem ERP-System des Möbelherstellers; Seite 14

15 - Baubarkeitsregeln des Produkts aus dem ERP-System des Lieferanten; - Bestandinformationen (Bauteil-IDs, Abmaße, etc.) aus dem ERP des Möbelherstellers sowie aus dem WMS des Lieferanten und dem WMS des Möbelherstellers Neben diesen Daten müssen auch die durch den Premiumservice über einen Sensor aufgenommenen Informationen über den nachzuarbeitenden Artikel bereitgestellt werden, damit der Simulationsservice den Bezug zwischen diesem Artikel und den oben aufgelisteten Daten herstellen kann. Die nachfolgende Abbildung 4 stellt den Ablauf der Serviceaufrufe für den Simulationsservice schematisch dar. Die Abbildung zeigt außerdem, welches System den jeweiligen Serviceaufruf anstößt bzw. auf eine Anfrage antwortet. Abbildung 4 Ablauf der Serviceaufrufe des Simulationsservice Nachfolgend wird der dargestellte Sequenzablauf der Serviceaufrufe des Simulationsservice im Detail beschrieben, sodass der Zweck dieser einzelnen Aufrufe transparent wird und zu jedem die jeweils übertragenen Informationen und Daten zugeordnet werden können. Der Ablauf der Serviceaufrufe beginnt mit der Auswahl der Steuerungsoption Nacharbeit im Verpackungsbereich über das mobile Gerät. Zur Anforderung der benötigten Daten aus den unterschiedlichen Systemen und zur Durchführung der Simulation werden die nachfolgend aufgelisteten Serviceaufrufe getätigt. - Nacharbeit im Verpackungsbereich am mobilen Gerät auswählen: Mit diesem Serviceaufruf erfolgt die Auswahl der durch das System zur Entscheidungsunterstützung OTD- NET auszuführenden Aktion, nämlich die Simulation - Senden der Auftragsinformationen durch OTD-NET an die ERP- und WMS-Systeme: Mit diesem Serviceaufruf werden die relevanten Auftragsdaten, die zuvor durch den Premi- Seite 15

16 umservice aufgenommen worden sind, wie Bauteil-ID, Ort und Zeit sowie die Qualitätskennzahl, an die führenden Systeme übermittelt; die führenden Systeme sind das ERP und WMS des Möbelherstellers sowie das WMS des Lieferanten - Empfangen der Auftragsinformationen durch die führenden Systeme: Mit dem Empfang der Auftragsinformationen identifizieren die führenden Systeme das Produkt, für das diese Systeme Daten bereitstellen müssen; die bereitzustellenden Daten werden in weiteren Requests durch das System zur Entscheidungsunterstützung OTD-NET angefordert - Anfordern der Bestandsinformationen: Die Anforderung der Bestandsinformationen erfolgt durch Requests an das ERP und WMS des Möbelherstellers sowie an das WMS des Lieferanten; mit jedem Request müssen die Artikel-IDs der nachzuarbeitenden oder zu ersetzenden Bauteile übermittelt werden, damit die führenden Systeme die Bestandsinformationen für exakt diese Artikel zurück geben - Bereitstellen und Senden der Bestandsinformationen durch die angefragten Systeme: Das ERP und WMS des Möbelherstellers sowie das WMS des Lieferanten geben die Bestandsinformationen in einer Response in den jeweiligen Systemen zu den angefragten Artikel-IDs an das System zur Entscheidungsunterstützung OTD-NET zurück; dabei werden aus den drei angefragten Systemen die Bestandshöhen geliefert, aus dem WMS des Lieferanten werden dem System zur Entscheidungsunterstützung OTD-NET zusätzlich die Transportdauer und die Beschaffungsdauer der angefragten Artikel bereitgestellt - Speichern der Bestandsinformationen: Die aus den führenden Systemen bereitgestellten Informationen werden gespeichert und damit für die eigentliche Simulation vorgehalten - Anfordern der Baubarkeitsregeln: Die Anforderung der Baubarkeitsregeln erfolgt durch ein Request des Systems zur Entscheidungsunterstützung OTD-NET an des ERP des Lieferanten; mit diesem Request wird die Produkt-ID zur Identifikation des Produkts übertragen - Bereitstellen und Senden der Baubarkeitsregeln: Das ERP des Lieferanten stellt die angeforderten Baubarkeitsregeln und die Bearbeitungsdauer in einer Response bereit und das OTD-NET speichert diese Daten strukturiert für die spätere Simulation - Durchführung der Simulation: Mit der Durchführung der Simulation werden die gespeicherten Daten zusammengeführt und entlang definierter Algorithmen verarbeitet - Bereitstellen und Senden der Simulationsergebnisse: Nach Abschluss der Simulation werden die Simulationsergebnisse an das die Simulation anfordernde mobile Gerät übermittelt; bei den übermittelten Daten handelt es sich u.a. um die Bestandseignung, die Durchlaufzeit, die Liefertermintreue und die Service-Laufzeit - Anzeigen der Simulationsergebnisse: Die an das mobile Gerät übertragenen Daten werden grafisch aufbereitet und die Simulationsergebnisse auf dem Display des mobilen Gerätes angezeigt Seite 16

17 Um die vorangehend beschriebenen Serviceaufrufe sowie den zugehörigen Datenverkehr zwischen den unterschiedlichen Systemen übersichtlich darzustellen, werden diese Zusammenhänge in einem Sequenzdiagramm visualisiert (vgl. Abbildung 5). In diesem Sequenzdiagramm werden keine Methoden beschrieben, da diese derzeit noch nicht festgelegt und bekannt sind. An den dargestellten Serviceaufrufen sind die jeweils übertragenen Daten als Notizen dargestellt. Abbildung 5 Serviceaufrufe des Simulationsservice Seite 17

18 3 Einbettung der Mehrwertdienste in das Gesamtsystem Zur Beschreibung der Aufgaben, die durch das Service Design Studio wahrzunehmen sind, werden zunächst der Simulationsservice und seine architektonische Einbettung in das Ökosystem aus Mobiler Anwendung, dem System zur Entscheidungsunterstützung OTD-NET sowie den ERP- bzw. WMS-Systemen des Möbelherstellers und seiner Zulieferer analysiert. Weiterhin werden die Methoden, die dieser Service nutzt, beschrieben. Darauf aufbauend stellt der Autor Überlegungen an, um welche nicht-funktionalen Mehrwertdienste der Simulationsservice sinnvollerweise für seine Aufgabenerfüllung angereichert werden sollte und wie diese Mehrwertdienste mit der Kernfunktionalitäten des Simulationsservice interagieren. Dazu werden die Interaktionen der Mehrwertdienste mit unterschiedlichen Systemen in einem Sequenzdiagramm beschrieben. Abschließend wird daraus ein Vorschlag für die Einbettung der Mehrwertdienste in die Architektur des Gesamtsystems abgeleitet. 3.1 Serviceaufrufe und übertragene Informationen Damit der Simulationsservice ausgeführt werden kann, muss dieser zunächst aufgerufen werden und dann seinerseits Informationen, die er für die Simulation benötigt, bei unterschiedlichen Systemen anfordern. Bei diesen Systemen handelt es sich um die ERP- und WMS-Systeme des Möbelherstellers sowie der Zulieferer. In Abbildung 6 ist die Servicearchitektur des Simulationsservice unter Verwendung von SOA-ML (vgl. [OMG09, S. 25 ff.] abgebildet. Diese Abbildung zeigt die Zusammenhänge zwischen den unterschiedlichen Akteuren bzw. Systemen auf. Abbildung 6 Servicearchitektur des Simulationsservice (SOA-ML) Seite 18

19 Wesentlich für die weiteren Untersuchungen sind die beiden Service-Kontrakte Simulation und Data Request. Die Serviceaufrufe, die zur Erfüllung dieser beiden Kontrakte von den beteiligten Systemen zu tätigen sind, sind bereits in Abbildung 5 schematisch dargestellt. Mit dem Serviceaufruf Simulation der Nacharbeit im Verpackungsbereich durch das mobile Gerät an OTD- NET müssen im Wesentlichen die durch den Premiumservice am Beginn des Prozesses erfassten Informationen an das System OTD-NET übergeben werden, um die Auftragsdaten und den Simulationsinhalt und -umfang für den Simulationsservice verfügbar zu machen. OTD-NET bildet im dargestellten Szenario die Zielplattform. Weitere Serviceaufrufe werden von dieser Zielplattform an die ERP- und WMS-Systeme des Möbelherstellers sowie seiner Zulieferer gerichtet, um ergänzende Daten für die Simulation vor allem für die zeitliche Planung der Nacharbeit zu generieren. Abbildung 7 Übermittelte Informationen an Service bzw. Information Provider Abbildung 7 zeigt, welche Daten und Informationen erstens vom mobilen Gerät an das System zur Entscheidungsunterstützung (OTD-NET) und zweitens von diesem System an die auftragsführenden Systeme (ERP- und WMS-Systeme) übertragen werden. Um eine Simulation ausführen zu können, benötigt OTD-NET Informationen über das Bauteil, für welches die Nacharbeit im Verpackungsbereich durchgeführt werden soll, über die Qualität des Beuteils bzw. den aufgetretenen Fehler, über den Ort, der durch die ID des erfassenden Sensors ermittelt wird, über den Zeitpunkt des Auftretens des Fehlers sowie über den Prozess, in dem der identifizierte Fehler aufgetreten ist. Weiterhin benötigt das System zur Entscheidungsunterstützung ergänzende Informationen aus den ERP- und WMS-Systemen des Möbelherstellers und seiner Lieferanten. Mit der Anforderung dieser Informationen werden die Beuteil-ID, die ID des Kunden, die Liefermenge und der geplante Liefer- Seite 19

20 termin sowie die Qualitätskennzahl und die erwartete Qualität von der Zielplattform an diese Systeme übermittelt. Nach Übermittlung dieser Informationen erfolgen die Serviceaufrufe an die ERP- und WMS-Systeme. Abbildung 8 zeigt die Nachrichteninhalte dieser Serviceaufrufe. Abbildung 8 Anforderung der Informationen aus den ERP- und WMS-Systemen Die Nachrichtendetails für die einzelnen Serviceaufrufe werden durch Request-Response-Prozeduren zwischen der Zielplattform (OTD-NET) und den ERP- bzw. WMS-Systemen des Möbelherstellers sowie seiner Zulieferer ausgetauscht. Aus Abbildung 8 ist ersichtlich, dass die folgenden Informationen für die Simulation aus verschiedenen ERP- und WMS-Systemen abgefragt werden: - Lagermenge von benötigten Bauteilen mit der angegebenen ID, - Transportdauer der benötigten Bauteile, - Wiederbeschaffungsdauer der benötigten Bauteile sowie - Baubarkeitsregeln für das Produkt Zur Übermittlung der Identifizierungsinformationen für Produkte, Aufträge und Bauteile sowie zum Anfordern der für die Simulation benötigten Informationen aus den ERP- und WMS-Systemen ruft OTD-NET Services (vgl. Abbildung 5) mit geeigneten Methoden auf. 3.2 Beschreibung und Funktion der hinzuzufügenden Mehrwertdienste Die funktionalen Methodenaufrufe für die Simulation müssen in ergänzende Methodenaufrufe eingebettet sein, die die erforderlichen Mehrwertdienste verfügbar machen, nämlich Sicherheitsabfragen (Authentifizierung und Autorisierung), die Umsetzung der Abrechnung der Simulation sowie die Seite 20

21 Sicherung der Servicequalität. Für diese Mehrwertdienste wird nachfolgend ebenfalls unter Nutzung von SOA-ML eine Servicearchitektur dargestellt, welche diese Services und ihr Zusammenspiel mit den zur Realisierung der Services notwendigen Akteuren visualisiert (vgl. Abbildung 9). Neben dem Zielsystem OTD-NET sind die weiteren Akteure der Authentifizierungs- und Autorisierungsservice, ein Abrechnungsservice, welcher die Abrechnung unterstützt, sowie ein SLA-Service, der die Einhaltung der für die Simulation vereinbarten Service Levels sicherstellt. Abbildung 9 Servicearchitektur der Mehrwertdienste (SOA-ML) Die Methodenaufrufe, die zum Anstoßen der Mehrwertdienste durch die Zielplattform OTD-NET genutzt werden, dienen den nachfolgend beschriebenen nicht-funktionalen Aufgaben: - Authentifizierung und Autorisierung: Übergabe der Nutzerdaten (Login, Passwort) an einen Authentifizierungsservice zur Verifizierung der Identität des Nutzers mittels eines Identity and Access Management Systems (IAM); der Autorisierungsservice räumt dem authentifizierten Nutzer anschließend wiederum mittels des IAM Systems die Rechte für die Nutzung definierter Funktionen des Simulationsservice ein; neben der hier beispielhaft dargestellten Umsetzung der Authentifizierung und Autorisierung mittels Login und Passwort gibt es auch andere Umsetzungsmöglichkeiten, wie z.b. die Nutzung eines Token - Abrechnung: Übergabe der Nutzungsdauer der Simulation (Zeitpunkt des Login eines autorisierten Nutzers, Beginn und Ende der Simulationsaufrufe, Zeitpunkt des Logouts des Nutzers) an ein Monitoring- und Abrechnungssystem Seite 21

22 - SLA-Einhaltung: Übergabe der Daten der erwarteten Service Level Agreements an einen SLA Service; dieser Service gleicht die erwarteten Daten mit den im Monitoring- und Abrechnungssystem erfassten Daten ab und stößt bei Nichteinhaltung der erwarteten SLA- Werte Aktivitäten zur Anpassung der SLA an, z.b. eine Benachrichtigung der Administration von OTD-NET zum Verändern von Wartungsintervallen oder zeitpunkten. 3.3 Ablauf der Serviceaufrufe für die Mehrwertdienste Aus den vorangehend dargestellten Methodenaufrufen und den zugehörigen Services bzw. Systemen leitet sich das folgende Sequenzdiagramm ab (vgl. Abbildung 10). Abbildung 10 Serviceaufrufe der Mehrwertdienste Der Ablauf der Serviceaufrufe für die Mehrwertdienste beginnt mit dem Einloggen des Benutzers über das mobile Gerät in das System zur Entscheidungsunterstützung (OTD-NET). Dazu erfolgt Seite 22

23 zunächst eine Anmeldung bei einem IAM-System, um den jeweiligen Nutzer zu authentifizieren. In einem zweiten Schritt wird die Autorisierung des Nutzers über einen Token realisiert, den das IAM- System bei der Authentifizierung an den Nutzer für die laufende Session vergeben hat. Zur Ausführung der Mehrwertdienste, in die die Simulation eingebettet ist, werden die nachfolgend aufgelisteten Serviceaufrufe getätigt. - Senden der Login-Daten des Benutzers an das IAM-System: Das IAM-System nutzt im ersten Schritt den Authentifizierungsservice und versendet ein Token an das mobile Gerät des Nutzers; dieser Token wird beim Aufruf von OTD-NET eingesetzt, um die Autorisierung des Nutzers durchzuführen und ihm damit Zugang zu bestimmten Funktionen des Systems zur Entscheidungsunterstützung zu gewähren - Weiterleiten der Nutzerdaten und eines Zeitstempels des Login an das Monitoring- und Abrechnungssystem: Das System erfasst das Login des jeweiligen Benutzers in OTD-NET - Übertragen der SLA-Anforderungen an den SLA-Service: Bei einer SLA-Anforderung kann es sich bspw. um die geforderte maximale Antwortzeit vom Aufrufen der Simulation in OTD- NET bis zur Übermittlung des Ergebnisses an das mobile Gerät handeln; OTD-NET sendet die im SLA vereinbarten Kenngrößen und deren Zielwerte an den SLA-Service, der diese Informationen für die Weiterverarbeitung speichert und an das Monitoringsystem weiter gibt - Bereitstellen der SLA-Zielwerte an Monitoring und Abrechnung: Damit das Monitoringsystem die Zielwerte der Kenngrößen mit den tatsächlichen Werten abgleichen kann, werden die Zielwerte vom SLA-Service an dieses System übermittelt - Durchführung der Simulation: Zum Durchführen der Simulation werden die funktionalen Serviceaufrufe für die Simulation getätigt (vgl. Abbildung 5) - Soll-/Ist-Abgleich der SLA-Kenngrößen: Das Monitoring- und Abrechnungssystem führt in definierten Intervallen ein Abgleich der vom SLA-Service übermittelten Soll-Kenngrößen mit den realen Kenngrößen des Simulationsservice durch; die Kommunikation dieser Ist-Werte vom Simulationsservice an das Monitoring- und Abrechnungssystem ist in Abbildung 10 nicht dargestellt - Senden von Problemmeldungen bei Nichteinhaltung der SLA-Zielwerte: Stellt das Monitoringsystem im Zuge des Abgleichs ein Über- bzw. Unterschreiten der SLA-Grenzwerte fest, so übermittelt es eine Problemmeldung mit Art und Zeitpunkt des Problems an den SLA- Service; der SLA-Service hat die Aufgabe, Aktivitäten zur Problembehandlung anzustoßen, wie z.b. eine Gutschrift der nicht nutzbaren Simulationszeit zu veranlassen - Ausführung des SLA-Services: Der SLA-Service dient dazu, Problemlösungen in der Infrastruktur der Cloud-Plattform, welcher der Simulationsservice zugehört, anzustoßen bzw. eine Kommunikation des Problems dahingehend zu initiieren, dass es für den Betreiber des Simulationsdienstes bzw. der Cloud-Plattform erkennbar wird und dieser geeignete Maßnahmen zur Problemlösung einleiten kann Seite 23