Datenempfehlung zur Nutzung des OMM entlang der Produktlebenszykluskette Sönke Knoch, Jens Haupert Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI GmbH) Kontakt: soenke.knoch@dfki.de, jens.haupert@dfki.de Stand: 22.07.2013 Einleitung und Motivation... 2 Das Object Memory Model... 2 Einordnung in das Product Lifecycle Management... 4 Einordnung in das Supply Chain Management... 6 Produktmodelle... 8 Austausch von Produktdaten... 9 e und Standards für den digitalen Datenaustausch... 10 Branchenübergreifende e und Standards... 11 Branchenspezifische e und Standards... 14 Übersicht... 16 Branchenspezifische Datenempfehlung anhand dreier Fallbeispiele... 18 Beispiel 1: Lebensmittelindustrie / Handel... 19 Beispiel 2: Luftfahrtindustrie... 23 Beispiel 3: Logistik... 26 Weitere Beispiele... 29 Vorgehensmodell... 30 Fazit... 30 Anhang... 31 Syntax... 31 Literaturverzeichnis... 31
Einleitung und Motivation Aus der Entstehung des Internet der Dinge und digitaler Produktgedächtnisse entstand der Bedarf für ein Strukturformat, das die Repräsentation und Verwaltung von digitalen Objektgedächtnissen und den Zugriff auf diese adressiert: Das Object Memory Model (OMM) (Haupert 2013). Der offene Ansatz des OMM im Sinne einer open-loop Lebenszykluskette, bei die Partner und deren Reihenfolge zu Beginn noch nicht feststehen, erfordert eine Verwendung geeigneter e innerhalb des OMM. Durch die Verwendung standardisierter und akzeptierter e können die Wechsel von einem Partner zum nächsten Partner, die typischerweise beim Wechsel von einer Lebenszyklusphase in die nächste stattfindet, die sogenannten Domänenübergänge, überwunden werden. Die mittels OMM erlangte Zusatzfunktionalität, die über eine reine Identifikationsfunktion hinausgeht, ist auf dem Weg in ein neues industrielles Zeitalter im Sinne der Industrie 4.0 wegweisend (Blocher 2013). In der vorliegenden Arbeit werden zunächst Grundlegende Terminologien und Konzepte des Product Lifecycle Management und des Supply Chain Management erläutert, um die einzelnen Phasen, die ein Produkt durchläuft genauer zu spezifizieren, den Datenbedarf in den einzelnen Phasen aufzuschlüsseln und bestehende Lösungsansätze zu untersuchen. In der Konsequenz wird dabei auch auf das zugrundeliegende Datenmanagement eingegangen. Des Weiteren werden Konzepte für Produktmodelle aus der Forschung erläutert. Im Anschluss werden Konzepte und Standards für den Austausch von Produktdaten, der während der einzelnen Lebenszyklusphasen stattfindet, diskutiert. Der darauf folgende Abschnitt befasst sich mit vorhandenen en und Standards, die entweder branchenübergreifend oder branchenspezifisch eingesetzt werden. Die Ergebnisse werden in einer Tabelle zusammengefasst. Im Anschluss werden drei Anwendungsbeispiele aus den Bereichen Lebensmittel-, Luftfahrtindustrie und Transportwirtschaft skizziert, die eine Einbettung eines spezifischen es in das OMM illustrieren und die jeweiligen branchenspezifischen Besonderheiten behandeln. Es folgen weiter Beispiele und Anwendungsgebiete. Die Erkenntnisse dieser Arbeit werden in einem kurzen Vorgehensmodell verdichtet, das die Entscheidungsschritte zur Etablierung eines geeigneten OMM-basierten Informationssystems schildert. Die verwendete Syntax zur formalen Beschreibung von einigen en wird im Anhang auf Seite 31 erläutert. Das Object Memory Model Das Object Memory Model ist ein Strukturformat, das im Rahmen einer W3C Incubator Group (XG) entwickelt und im Rahmen einer Dissertation, auf der die folgenden Ausführungen basieren, verfeinert wurde (Kröner et al. 2011; Haupert 2013). Die im OMM gespeicherten Informationen werden in Blöcken abgelegt. In Blöcken enthaltene Metadaten erleichtern die Suche nach Informationen. Ein sverzeichnis (Table of Contents) liefert eine Übersicht über die im Gedächtnis enthaltenen Informationen und der Gedächtnis-Header (OMM Header) enthält die Metadaten des gesamten Gedächtnisses. Die OMM-Struktur kann mittels Abbildung 1 nachvollzogen werden. Der OMM Header enthält eine optionale primäre ID, mit deren Hilfe Beziehungen zwischen Gedächtnissen hergestellt werden können. Eine einmal gesetzte ID kann nicht mehr geändert werden. Zudem können zusätzliche temporäre IDs in einem ID-Block abgelegt werden. Links zu extern gespeicherten Blöcken können ebenfalls im Header abgelegt werden. Unverzichtbar hingegen ist die Versionsnummer zu Beginn des Headers. Ein OMM-Block wird in Metadaten (Block Metadata) und Nutzdaten (Block Payload) unterteilt. Während in der Nutzdatenpartition beliebig strukturierte Daten abgelegt werden können, besteht die Metadatenpartition aus einer vorgegebenen Anzahl an Datenfeldern (vgl. Abbildung 1). Die ID dient der eindeutigen Identifizierung des Blocks und ist zwingend erforderlich. Das Feld Format dient der 2
Beschreibung des s von Nutzdaten, allerdings in Form einer MIME-Type Angabe gemäß dem Dublin Core Attribut Format 1. Das Setzen des Formats ist nur zwingend erforderlich, falls das Feld Namespace keine Angaben enthält. Creator beinhaltete zwingend das Blockerstellungsdatum und die Identität des Erstellers gemäß dem Dublin Core Attribut Creator. Das Feld Contributor enthält optional das Datum der letzten Blockänderung zusammen mit der Identität des Ändernden gemäß dem gleichnamigen Dublin Core Attribut. Pro Block können mehrere Einträge in das Feld Contributor erfolgen. Das Feld Title enthält einen mehrsprachigen Titel mit weniger als 255 Zeichen gemäß dem gleichnamigen Dublin Core Attribut und ist zwingend erforderlich. Description gibt optional eine mehrsprachige Beschreibung zu dem Block an basierend auf dem Dublin Core Attribut Description. Type wird optional mit einem zu den Nutzdaten passenden Typ belegt. Beispiele für Typen sind Collections, Dataset, Images, Sounds und Texts. Optional kann auch das Feld Subject mit Klartext-Tags oder Ontologiekonzepten in RDF oder OWL belegt werden. Die Klartextdarstellung basiert auf dem Dublin Core Attribut Subject. Mehrere Subjects pro Block sind möglich. Mit Hilfe des Feldes Link kann auf extern liegende Nutzdaten verwiesen werden. Das Feld ist nur zwingend erforderlich, wenn kein Payload zu diesem Block existiert. Abbildung 1. Datenstruktur des Object Memory Model (OMM), aus (Haupert 2013, S.124-147). Das OMM-sverzeichnis ermöglicht es mit geringem Kommunikationsaufwand einen Überblick über das Objektgedächtnis zu erhalten, ohne dass ein Zugriff auf den eigentlichen erfolgt. Ein Eintrag im sverzeichnis besteht aus einer Teilmenge der Metadatenfelder eines Blocks. Verpflichtend sind dabei ID, Namespace/Format, Creator und Title anzugeben, optional können weitere Datenfelder hinzugefügt werden. Neben der oben dargestellten Grundstruktur existieren im OMM standardisierte Blöcke. Mit Struktur- Blöcken lassen sich Beziehungen zwischen dem eigenen und anderen Objekten modellieren. ID-Blöcke kapseln identifizierende Informationen, die über eine bloße ID hinausgehen. Schließlich bietet die Schlüssel-Wert-Paar Blockvorlage die Möglichkeit Key-Value-Paare abzulegen. Innerhalb von OMM+ wurden weiter Ergänzungen definiert. Der OMM+-Semantik Block ermöglicht es semantische Zusammenhänge komfortabler darzustellen als es durch den OMM-Strukturblock gegeben ist. Der OMM+-Embedded Block ermöglicht die Einbettung eines gesamten Objektgedächtnisses in einem Block eines anderen Gedächtnisses. PiVis-Plugin Blocks können Plugins, bspw. in Form von Java-JAR- 1 http://purl.org/dc/elements/1.1/format 3
Dateien, für die Visualisierung transportieren. Auf der Datenebene wird das OMM im XML-Format oder RDFa/Microdata repräsentiert. Mit der libomm steht eine Programmierbibliothek zur Verfügung, die die Verwaltung von OMM-Gedächtnissen über eine API ermöglicht. Eine detaillierte Beschreibung des OMM und der dazugehörigen Architektur sind in (Haupert 2013) und auf der OMM-Webpräsenz 2 zu finden. Einordnung in das Product Lifecycle Management Digitale Objektgedächtnisse können eingesetzt werden, um den Lebenszyklus eines Produktes von der Herstellung über den Vertrieb bis hin zur Benutzung und Entsorgung mit relevanten Daten abzudecken. Aus diesem Grund soll im Folgenden kurz eine Zusammenfassung des Themengebietes Product Lifecycle Management (PLM) erfolgen, um eine terminologische Grundlage für diese Arbeit zu legen. Kern der Betrachtungen im PLM sind Produkte. Ein Produkt lässt sich differenziert als materielles Produkt, Dienstleistung oder immaterielles Produkt, das keine Dienstleistung ist (z.b. Software oder Algorithmus), betrachten (Saaksvuori und Immonen 2008, S.1). PLM ist als systematisches Konzept für das Management und die Entwicklung von Produkten und damit verbundenen Informationen (und angebundenen Informationssystemen) aufzufassen (Saaksvuori und Immonen 2008, S.3). Teilnehmer entlang der Produktwertschöpfungskette sind Kunden, Produktentwickler, Hersteller, Servicetechniker und Lieferanten; diese benötigen die passenden Informationen zu einer bestimmten Zeit im richtigen Format (Schilli und Kern 2006, S.186). Produktlebenszyklen können marktorientiert, ökologisch, aus Herstellersicht und Nutzersicht betrachtet werden (Stark 2011, S.17). Die Phasen des PLM werden in der Literatur unterschiedlich aufgefasst: In dem Buch über die Normenreihe ISO 10303 (STEP) nennen (Anderl und Trippner 2000, S.10) die Phasen Produktentstehung, -vertrieb, -nutzung und Produktrecycling & -entsorgung, wobei die Produktentstehung noch in die Teilphasen Produktplanung, Konstruktion, Arbeitsvorbereitung und Produktherstellung unterteilt wird. (Scheer et al. 2006, S.187) bieten eine prozessorientierte Sicht auf das PLM und definieren die Phasen Produktentstehung, Produktfertigung und Produktentsorgung. Ebenfalls prozessorientiert werden auf einer feingranularen Ebene die Phasen Concept, Design, Source, Manufacture, Sales und Service identifiziert (Schilli und Kern 2006, S.187). Nach (Saaksvuori und Immonen 2008, S.4) wird zwischen Produktionsprozess ( New Product Introduction, Wartung und Instandhaltung, beides begleitet vom Produktmarketing) und Order-Delivery-Prozess (Vertrieb, Beschaffung, Herstellung, Lieferung, Service und Wartung) unterschieden. Von der Domäne der technischen Dokumentationskontrolle (Engineering Documentation Control) oder dem Konfigurationsmanagement aus betrachtet, sind relevante Lebenszyklusphasen Definition, Development, Pilot, Production und Phase Out (Watts 2008, S.168). Im Hinblick auf die Optimierung von Produktentstehungsprozessen nennen (Eigner und Stelzer 2009, S.9) Anforderungen, Produktplanung, Entwicklung, Prozessplanung, Produktion, Betrieb und Recycling als relevante Phasen. Aus der Perspektive eines Decision Engineers definiert (Stark 2011, S.17-20) die Phasen Imagine, Define, Realise, Support/Service und Retire aus Sicht eines Herstellers und modifiziert die letzten beiden Phasen, wenn die Perspektive des Nutzers eingenommen wird durch Use/Operate und Dispose/Recycle. 2 http://www.dfki.de/omm-tools/index.php 4
Auf einer Metaebene beschreibt (Frey 2011, S.4-7) die Phasen Begin of Life, Middle of Life und End of Life und identifiziert einen lückenhaften Informationsfluss in den beiden letzten Phasen. Eine Übersicht aller dargestellten Auffassungen über den Lebenszyklus eines Produktes ist in Abbildung 2 zu finden. Das in der Abbildung angesprochene Konfigurationsmanagement, engl. Configuration Management (CM), stellt eine rein ingenieurwissenschaftliche Sicht auf den Produktlebenszyklus dar. Zu definieren ist das CM als ein einfacher, schlüssiger, schneller, exakter, messbarer und gut verstandener Prozess zur Planung, Identifizierung, Kontrolle und Monitoring einer Produktkonfiguration vom Anfang über den ganzen Lebenszyklus bei minimalen Kosten (Watts 2000, S.6-7). Abbildung 2. Phasen eines Produktlebenszyklus. Die Kernkompetenzen des Product Data Management (PDM) liegen im Datenmanagement, Prozessmanagement und der Integration von Systemen in allen Bereichen und über alle Produktlebenszyklusphasen hinweg erreicht durch ein ausgebautes Konfigurationsmanagement, besonders in den Phasen Design, Entwicklung und Konstruktion (Scheer et al. 2006, S.14). Im PLM stellt das PDM eines der wichtigsten Systemkomponenten dar (Stark 2011, S.233 ff.). PDM kann dabei als eine Menge von Werkzeugen aufgefasst werden, die produktbezogene Daten effizient verwalten und den gesamten Lebenszyklus eines Produktes unterstützen (Saaksvuori und Immonen 2008, S.vi). Während des Lebenszyklus anfallende Daten können in drei Typen unterschieden werden (Saaksvuori und Immonen 2008, S.7-8): 1. Definierende Daten beschreiben die physikalischen sowie die funktionalen Eigenschaften eines Produktes. 2. Lebenszyklusdaten informieren über technische Forschungsergebnisse, Design, Produktion, Nutzen, Wartung, Recycling und Beseitigung sowie über legislative Verordnungen. 3. Metadaten beschreiben Produkt- und Lebenszyklusdaten. 5
Strukturen von Produkten bzw. die Zusammensetzung eines Produktes ( Bill of Materials ) sowie verwendete Informations- und Produktmodelle sind eng verknüpft mit diesen Produktdaten (Saaksvuori und Immonen 2008, S.8; Watts 2000, S.93). Datenmodelle von Produktinformationen analysieren produktbezogene Informationen und die Beziehung von Produkten zu anderen Informationen während Produktmodelle Informationen zu einem individuellen Produkt, bspw. zur Produktstrukturierung, bieten. Die Identifizierung, Kodierung und Benennung eines Produktes oder Produktbestandteils erfolgt über sogenannte Items (Saaksvuori und Immonen 2008, S.11-13). Auch Dinge, die in den Produktionsprozess involviert sind, wie Verpackung, Maschinen und Software können als Items bezeichnet werden. Items und Item-Klassifizierungen sollten innerhalb eines Unternehmens einheitlich sein. Eine angemessene Bildung von Item-Klassen erleichtert das Management und die Suche nach bestimmten Items. Um Produkte in Fremdunternehmen zu identifizieren, können Querverweistabellen herangezogen werden, die den im Fremdunternehmen verwendeten Item-Code eines bestimmten Items aus dem eigenen Unternehmen zur Verfügung stellen. Eine Alternative zu diesen Tabellen stellt die Vereinheitlichung der Items und damit die Integration von Fremdunternehmen dar. Die Phasen eines Produktlebenszyklus verlaufen entlang verschiedener Stationen oder Domänen, auch die Vertikalen genannt. An den Domänengrenzen sind somit Übergänge vorhanden, die beim Informationsfluss zu überbrücken sind. (Saaksvuori und Immonen 2008, S.14) nennen die Domänen Partner & Lieferanten, das produzierende Unternehmen im Zentrum sowie Partner und Kunden am Ende des Produktions- bzw. Order-Delivery-Prozesses. Im Unternehmen selbst werden noch die Stationen Beschaffung, Vertrieb, Forschung & Entwicklung, Fertigung und Lieferung genannt. Da in dieser Arbeit der Fokus auf den Domänenübergängen liegt und unternehmensinterne Systemgrenzen häufig durch unternehmensspezifische Softwarelösungen bereits überwunden werden (vgl. Scheer et al. 2006, S.67-117), wird im Folgenden im Gegensatz zu einer betriebswirtschaftlichen Sicht auf den Produktlebenszyklus nun die übergeordnete Sicht des Supply Chain Management eingenommen. Einordnung in das Supply Chain Management Im Gegensatz zum PLM, bei dem Produktplanung und entwicklung im Vordergrund stehen, hat im Supply Chain Management (SCM) der Fluss von Materialien und Produkten von der Rohstoffgewinnung, über die Produktion, bis hin zur Nutzung und Entsorgung die höchste Priorität. Im SCM werden unbearbeitete Materialien beschafft und Gegenstände in einer oder mehreren Fabriken gefertigt, zu Lagerhäusern zur Zwischenlagerung transportiert, um dann an Händler und Kunden geliefert zu werden (Hugos 2006; Basu 2007; Bhatnagar 2009; Hertel et al. 2011). SCM wird in der Literatur unterschiedlich definiert. Hier soll der Definition von (Basu 2007, S.4-5) gefolgt werden, die SCM basierend auf der Definition von (Melnyk and Swink 2002) beschreiben. Letztere definieren SCM im Sinne eines Cradle-to-Grave Konzepts als ein Netzwerk aus Organisationen, die involviert sind in 1. die Transformation von unbearbeiteten Materialien und Informationen in Produkte und Dienstleistungen, 2. das Konsumieren von Produkten und Dienstleistungen und 3. das Entsorgen von Produkten und Dienstleistungen. (Basu 2007, S.4-5) erweitert diese Definition um das Wort Prozess und sieht die Supply Chain als einen kompletten End-to-End-Prozess. Abbildung 3 zeigt den Supply Chain Prozess. Da bewegte Märkte den Unternehmen schnellere Reaktionen auf die Nachfrage der Konsumenten und sich ändernde Rahmenbedingungen diktieren, ist die Supply Chain bei Vorliegen eines solchen Marktes (Abbildung 3, rechts) in der Regel wesentlich dynamischer und flexibler gestaltet als eine Supply Chain 6
an starren Märkten (Abbildung 3, links). Gerade die flexiblere Supply Chain geht einher mit einer Vielzahl an Datentransformationen, die notwendig sind, um allen beteiligten Unternehmen die notwendigen Informationen zukommen zu lassen. Abbildung 3. Prozesse der Supply Chain alt (links) gegenüber neu (rechts), in Anlehnung an (Bhatnagar 2009, S.13; Hugos 2006, S.21). Die Haupttreiber in der Welt des SCM sind die Produktion (was, wie und wann produziert wird), der Warenbestand (Produktions- und Lagerkapazität), der Ort (wo werden bestimmte Aktivitäten am besten ausgeführt), der Transport (wie und wann wird ein Produkt bewegt) und die Informationen (die Basis für Entscheidungen in allen zuvor genannten vier Punkten) (Bhatnagar 2009, S.17; Hugos 2006, S.3). Der zentrale Treiber Information, der mit den Treibern Produktion, Warenbestand, Ort und Transport vernetzt ist, ist Gegenstand der vorliegenden Arbeit (vgl. Abbildung 4). Auf Basis von Informationen werden Entscheidungen in den anderen vier Supply Chain Treibern getroffen (Bhatnagar 2009, S.10). Das Timing mit der die Daten verfügbar gemacht werden können sowie die Genauigkeit und Vollständigkeit der Daten hat einen starken Einfluss auf die Entscheidungen, die innerhalb von SCM Prozessen gefällt werden. Primäre Ziele des SCM sind eine Straffung der Supply Chain in Hinblick auf Zeit, Kosten und Effizienz sowie die Vermeidung unerwünschte Effekte, wie z.b. dem Bullwhip Effect (vgl. Basu 2007, S.23). Das SCM besitzt viele Anknüpfungspunkte zum Gebiet der Logistik. 7
Abbildung 4. Haupttreiber der Supply Chain, in Anlehnung an (Bhatnagar 2009, S.11; Hugos 2006, S.17) Produktmodelle Da im Zusammenhang mit dieser Arbeit produktrelevante Daten gehandhabt werden müssen, werden im Folgenden kurz Arbeiten aus dem Bereich der Produktmodelle vorgestellt: Das Core Product Model (CPM) von (Fenves et al. 2001) ist ein offenes, abstraktes Produktmodell, anzusiedeln im PLM. Das Modell bildet die notwendigen Informationen zur Funktionsweise, Form und Verhalten eines Produktes ab und dient der Unterstützung von Computer Aided Design (CAD) Software. In (Fenves et al. 2005) wurde das Modell in CPM2 überarbeitet. Aufgrund der expliziten Ausrichtung auf CAD Systeme ist das Modell den frühen Lebenszyklusphasen Design und Konstruktion zuzuordnen. (Pels 2006) stellt Hierarchien zur Klassifikation von Produkten dar. Produktinstanzen werden zu Produktklassen aggregiert, die wiederum Produkttypen bilden. Typische Produktklassen sind Produktfamilien. Der Hierarchische Ansatz soll helfen die Komplexität von Produktmodellen zu reduzieren. Eine formale Notation zur Beschreibung der Hierarchie wird eingeführt. Die Notation basiert auf UML. Weiteren Forschungsbedarf sieht der Autor im Bereich von Produktstrukturen und Stücklisten ( Bill of Materials ), da die semantischen Konzepte der UML in diesem Bereich nicht hinreichend sind. Das Open Assembly Model (OAM) von (Rachuri et al. 2007) bietet ein auf elektromechanische Produkte zugeschnittenes, objektorientiertes Model zur Abbildung der Produktzusammensetzung. Beschrieben wurde das Model mit Hilfe der Unified Modeling Language. Das Modell stellt eine Erweiterung für das CPM2 dar. Im OAM wird die Zusammensetzung konzeptuell aufgefasst, während die Zusammensetzung im STEP ISO-10303 als Datenstruktur fungiert. (Lee et al. 2011) schlagen ein generisches, unabhängiges und mehrschichtiges Modell vor, das in die Ebenen Daten, Modell und Metamodell unterteilt ist. Produkte sind auf der Datenebene, Produktmodelle auf der Modellebene und Modelle von Produktmodellen auf der Metaebene angesiedelt. Das Metamodell wird mit Hilfe der Web Ontology Language (OWL) spezialisiert, um Produktdesignern zu ermöglichen semantische Zusammenhänge so auszudrücken, dass diese von Ingenieuren verstanden werden. Die Ontology Product Modeling Language (Bock et al. 2010) wurde verwendet, da Ingenieure mit deren Hilfe in ihrer Terminologie im Sinne einer konkreten Taxonomie modellieren können und zudem die Möglichkeiten einer Ontologiesprache wie OWL zur Verfügung 8
stehen. Klassen, wie Artefakte oder Verhalten werden in OWL definiert, womit die Semantik von OWL Designern und Ingenieuren zur Verfügung steht. (Barbau et al. 2012) entwickelten ein Konzept, um das STEP Schema in die OWL-Welt zu transferieren. Des Weiteren wird das STEP Produktmodell um nichtgeometrische Informationen zu Funktion und Verhalten eines Produkts (vgl. CPM-Ansatz) angereichert. Austausch von Produktdaten Für den Datenaustausch zwischen zwei getrennten Systemkomponenten muss eine exakte Spezifikation vorliegen, damit eine verlustfreie Kommunikation ermöglicht wird. (Saaksvuori und Immonen 2008, S.55-56) sprechen in diesem Zusammenhang von Agreements on Transfer Files, die getroffen werden müssen. Diese beinhalten übereinstimmendes Wissen aller Kommunikationsteilnehmer darüber 1. welche Informationen bewegt werden, 2. wie die Informationen bewegt werden, und 3. in welchem die Informationen bewegt werden. In Abhängigkeit von der Lebenszyklusphase in der ein Datenaustausch stattfindet stehen die e der übermittelten Daten. So unterscheidet sich bspw. der Datenaustausch während der Design- und Konstruktionsphase stark von dem Datenaustausch während der Produktions- und Wartungsphase (Schilli und Kern 2006, S.193). Der prominenteste Standard für den Austausch von Produktdaten auf Modellebene ist der unter ISO- 10303 zertifizierte, internationale Standard for the Exchange of Product Model Data (STEP) (Anderl und Trippner 2000). In STEP wird ein möglichst generisches, objektorientiertes Produktmodell definiert, indem Objektklassen für alle gängigen Anwendungsfelder und bereichsspezifische Objekte im Application Protocol beschrieben werden. Somit lassen sich mit der Hilfe von STEP Produktmodelle und strukturen definieren. Zudem wird ein Werkzeug für den Austausch von Produktdaten zwischen verschiedenen Informationssystemen und Teilnehmer des Lebenszyklus (die Vertikalen) bereitgestellt. Der Fokus von STEP liegt auf den Lebenszyklusphasen Design und Konstruktion, in denen eine detailgerechte Beschreibung von Anforderungen und Designkonzepten essentiell ist. Anzutreffende Systeme in diesem Bereich sind überwiegend im Segment des CAD angesiedelt. Um in diesem Bereich den Datenaustausch mittels STEP einzusetzen, müssen Softwarepakete für die eingesetzten CAD- Werkzeuge eingekauft werden, die Schnittstellen für den Datenaustausch zur Verfügung stellen. Nur die Bereitstellung dieser Schnittstellen, gekapselt in den Application Protocols, ermöglicht eine Kollaboration unter den Partnern. Ein weiterer Standard, der in den Phasen Design und Konstruktion zum Einsatz kommt, ist der American National Standard Institute Initial Graphics Exchange Specification (ANSI IGES) Standard, der ebenfalls einen Datenaustausch zwischen CAD Systemen ermöglicht. Seit 2012 hat sich der Dateiformat-Standard JT (Jupiter) als internationaler Standard zur Visualisierung und zum Austausch von 3D Geometriedaten etabliert. JT wurde erstmals 1998 von Hewlett-Packard und der Engineering Animation Inc. spezifiziert und gehört seit 2007 zum PLM Software Paket der Siemens AG. Die Datenstruktur von JT ist ein Szenengraph, dessen Knoten CAD- Daten enthalten. Abbildung 5 zeigt eine Visualisierung auf Basis von JT-Daten. Auf der linken Seite sind die einzelnen Bauteile und Komponenten aufgeführt, die Knoten des Szenengraphen. 9
Abbildung 5. Visualisierung eines Modells für einen strahlenförmigen Motors im JT-Format. In den Phasen Produktion und Wartung haben sich bis Dato keine Standards etabliert. Lösungen, die existieren sind (1) einem Konsortium zuzuordnen, z.b. OAGIS (vlg. S.16), (2) domänenspezifisch, z.b. OPENTrans (vgl. S.15) oder (3) unternehmensspezifisch, z.b. Business Data Objects von ABB (Schilli and Kern 2006). Ein Standard, der die Phasen Produktion und Wartung abdeckt ist dringend notwendig und sollte die folgenden Informationen einbeziehen (Schilli und Kern 2006, S.193-194): Bill of Materials, Bill of Service parts, elektronische Kataloge, Produktprozessparameter, Tabelle mit Charakteristiken, Kommerzielle Informationen, Vertragsinformationen und installierte Ausgangsdaten. Für die Recycling-Phase liegt ebenfalls kein Standard vor. Allerdings decken Formate wie der VDA 260 (vgl. S.15) aus der Automobilindustrie das Thema Recycling bereits ab. e und Standards für den digitalen Datenaustausch Bei der Betrachtung von en zum Austausch von Produktdaten gewinnt der Begriff Electronic Data Interchange (EDI) an Bedeutung. Unter EDI ist der Austausch von formatierten Nachrichten zwischen zwei Maschinen zu verstehen (Kantor und Burrows 1996). Um diese Art der Maschinen-zu-Maschinen Kommunikation zu ermöglichen werden Standards benötigt, die die Syntax und deren Semantik definieren, die notwendig ist, um einen automatisierten Zusammenbau, die Zerlegung und die Verarbeitung von Nachrichten zu ermöglichen. Werden beim Datenaustausch zwischen zwei Kommunikationsteilnehmern unterschiedliche e benutzt, müssen die Daten evtl. von dem einen in das andere Format übersetzt werden. Zur Umsetzung von EDI existieren zum einen Protokolle, die sich mit dem Transfer der Daten befassen und zum anderen Formate, die sich mit der Art und Weise in der die zu übermittelnden Daten strukturiert werden befassen. Im Folgenden wird auf einige verbreitete e eingegangen, die zum Datenaustausch verwendet werden können. Dabei wird zwischen branchenübergreifende und branchenspezifische e 10
unterschieden. Auf gängige Dateiformate des Internetzeitalters, wie z.b. XML, PDF oder JP(E)G wird dabei nicht eingegangen. Branchenübergreifende e und Standards Das STEP (ISO 10303-21) ist für den Datenaustausch gemäß STEP-Standard konzipiert. Das besitzt eine ASCII Struktur. STEP Dateien sind in eine Header- und Datenabschnitt unterteilt. Der Header enthält 3 bis 6 Gruppen: FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA, FILE_POPULATION, SECTION_LANGUAGE und SECTION_CONTEXT. Die letzten drei Gruppen gelten erst ab der zweiten Ausgabe des Standards im Jahr 2002. Die einzelnen Gruppen enthalten verschiedene Datenfelder. Der Datenabschnitt enthält Anwendungsdaten gemäß eines bestimmten Schemas der in STEP verwendeten Datenmodellierungssprache EXPRESS. Namen von Entitätsinstanzen wird dabei ein innerhalb der Datei eindeutiger String zugeordnet und sollte eine natürliche Zahl enthalten, z.b. #4711. Instanzen von Entitätsdatentypen werden in Großbuchstaben gefolgt von dem Wert in runden Klammern notiert, z.b. #123=PRODUCT( <Wert> ). Abbildung 6. Struktur des SDXF Chunk. Beim Structured Data exchange Format (SDXF) handelt es sich um ein hierarchisch strukturiertes, das als Internet RFC 3072 veröffentlicht wurde (Wildgrube 2000). Das Format ist für den Einsatz als Dateiformat und als Networking-Message-Format gleichermaßen geeignet. SDXF erlaubt eine Datenstrukturierung in beliebige Tiefe, wobei die Datenelemente selbstbeschreibend gestaltet sind. Die gesamte SDXF-Struktur sowie deren Elemente werden als Chunks bezeichnet. Ein Chunk besteht aus einem Header mit Metadaten (sechs Bytes groß), gefolgt von den eigentlichen Daten. Der Header enthält eine Chunk-ID (zwei Byte), die Länge der nachfolgenden Daten und den Typ der 11
nachfolgenden Daten sowie optional zusätzliche Informationen über bspw. Komprimierung und Verschlüsselung der Daten. Mit Hilfe des Typ-Feldes im Header wird im Wesentlichen eine Unterscheidung in Textdaten, Binärdaten und Strukturdaten getroffen. Im Falle von Strukturdaten handelt es sich um ein strukturierendes Chunk, das weitere Chunks enthält. Abbildung 6 zeigt die Struktur eines Chunks. Beim Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) Standard (UNECE 2013) handelt es sich um einen branchenübergreifenden internationalen Standard zur Formatierung elektronische Daten im Geschäftsverkehr, der Teil der EDI-Standards ist. Der UN/EDIFACT wurde unter dem Dach der Vereinten Nationen, in der Einrichtung Centre for Trade Facilitation and Electronic Business (CEFACT) entwickelt und gilt als ISO zertifiziert unter der Nummer 9735. Zudem gibt es industriespezifische und auf Nationen zugeschnittene Versionen des Standards. EDIFACT wurde basierend auf dem überwiegend in Nordamerika verwendeten ANSI ASC X12 Standard und dem überwiegend in Großbritannien anzutreffenden, von der UN/ECE in Genf entwickelten Guidelines for Trade Data Interchange (GTDI) entwickelt. Vom industriespezifischen EDIFACT existieren mehrere Versionen, die als Verzeichnisse bezeichnet werden. Des Weiteren existieren branchenspezifische Subsets, die auf bestimmte Anwendergruppen zugeschnitten sind. Beispiele für solche Subsets sind folgende: CEFIC, chemische Industrie EANCOM, Konsumgüterindustrie Edi@Energy, Strom und Gas in Deutschland EDIBDB, Baustoffe EDIFICE, High Tech Industrie EDIFOR, Speditionen EDIFURN, Möbel EDIGAS, Ferngas EDILEKTRO, Elektroindustrie EDILIBE, Buchhandel EDITEC, Sanitärbranche EDITEX, Textilindustrie EDITRANS, Transportwirtschaft EDIWHEEL, Reifen- und Radhersteller ETIS, Rechnungen im Bereich Telekommunikation ODA/ODIF, allgemeine Dokumente ODETTE, Automobilindustrie RINET, Versicherungen Kern des EDIFACT Standards ist die einheitliche Typisierung von Nachrichten. EDIFACT ist hierarchisch strukturiert. Auf oberster Ebene steht ein Umschlag, der mit Header (UNB) und Abschluss (UNZ) die auszutauschenden Informationen flankiert. Der Umschlag selbst besteht aus Codes für Absender und Empfänger sowie den der Nachricht, Zeitstempel und Prüfelementen. Eine Ebene tiefer befinden sich optional Gruppen, die eine Sequenz von Segmenten oder weiteren Gruppen darstellen. Gruppen enthalten ebenfalls einen Header (UNG) und einen Abschluss (UNE), die alle einschließenden Elemente flankieren. Die eigentliche Nachricht verfügt wieder über Header (UNH) und Abschluss (UNT) und enthält auf unterster Ebene die einzelnen Datensegmente. Optional steht zu Beginn einer jeden EDIFACT Nachricht noch das UNA-Segment, welches die Trennzeichen spezifiziert, die in der übrigen Nachricht zur Interpretierung der Syntax verwendet werden sollen. Per Default sind das : als Separator von Komponenten, + als Separator von Elementen,. als Dezimaltrennzeichen,? für 12
Release Daten, als Leerzeichen und indiziert das Ende eines Segments. Eine detaillierte Beschreibung finde sich in (GXS 2013). Zahlreiche spezialisierte Standards nutzen den EDIFACT als Basis. Die GS1 bietet mit dem EANCOM Subset eine eigene Implementierung an (GS1 2013). Die beschriebene Struktur wird in Abbildung 7 visualisiert und wird im Folgenden nun detailliert beschrieben. Abbildung 7. EDIFACT Nachrichtenstruktur. Eine Nachricht repräsentiert ein Geschäftsdokument und besteht aus sechs Buchstaben, z.b. ORDERS für eine Bestellung oder INVOIC für eine Rechnung. Eine Nachricht wird mit dem UNH Segment (Message Header) eingeleitet und mit dem UNT Segment (Message Trailer) beendet. In einer Segment Tabelle wird definiert welche Segmente in welcher Reihenfolge in einer bestimmten Nachricht aufgeführt werden. Segmente können dabei als verpflichtend oder optional spezifiziert werden. Tabelle 1 zeigt einen Auszug aus der Segment Tabelle für ORDERS. In der Spalte Erforderlich steht M für Mandatory (verpflichtend) und C für Conditional (optional). Bei der Wiederholung mehrerer Segmente in derselben Reihenfolge bietet sich die Gruppierung in Segmentgruppen an. Segmentgruppen lassen sich auch ineinander verschachteln, d.h. eine Gruppe kann in einer anderen Gruppe enthalten sein. Position Tag Name Erforderlich Wiederholungen 0010 UNH Message Header M 1 0020 BGM Beginning of Message M 1 0030 DTM Date/time/period M 35 0090 ---------- Segment group 1 --------------------------- C 9999 0100 REF Reference M 1 0110 DTM Date/time/period C 5 0120 ---------- Segment group 2 --------------------------- C 99 0130 NAD Name and address M 1 0140 LOC Place/location identification C 99 0150 FII Financial institution information C 5 Tabelle 1. Auszug aus der Segment Tabelle für das Geschäftsdokument ORDERS. 13
Segmente bestehen aus einer Zeichenkette und einem drei Zeichen langen alphanumerischen Code sowie einer Kette von Datenelementen variabler Länge. Datenelemente können dabei einfach (simple) oder zusammengesetzt (composite) sein. Um Datenelemente voneinander zu trennen wird das + verwendet. Datenelemente, die sich aus weiteren Elementen zusammensetzen werden mit dem : voneinader getrennt. Für Datenelemente stehen die drei Typen Numerisch (n), Alphabetisch (a) und Alphanumerisch (an) zur Verfügung. Über die Notation {n a an} [.. ] < #character > werden Typ und Anzahl der Zeichen definiert. Sind 1 bis n Zeichen erlaubt werden zwischen Typ und n zwei Punkte hinzugefügt (vgl. Tabelle 2, letzte Spalte). Folgendes Beispiel veranschaulicht die Zusammensetzung eines Segments unter der Annahme, dass ein Segment mindestens ein Element enthält: Segment = < tag > + [ el simple el composite + ] { el simple el composite } el composite = [ el sub ] { el sub } Die Anzahl der Elemente entspricht dabei der Anzahl der als Mandatory gekennzeichneten Elemente plus die Anzahl aller verwendeten Elemente, die als Conditional gekennzeichnet wurden. Werden als Conditional gekennzeichnete Elemente übersprungen werden diese durch ++ oder :: gekennzeichnet, damit die Identifizierung der nachfolgenden Elemente erfolgen kann. Befinden sich ausgelassene Elemente am Ende eines Segments, wird das Segment vorzeitig durch das Abschlusszeichen beendet. Der Interpreter weiß dann, dass keine weiteren Elemente folgen. Tabelle 2 zeigt einen Ausschnitt aus der Spezifikation für das Datenelement NAD (Name And Address). Die Einträge C082 und C058 stellen dabei optionale zusammengesetzte Elemente dar. Ein gültiger Ausdruck für einen Eintrag in der Nachricht sieht wie folgt aus: NAD + CA+ < party ID > GS1+ < name and address > C082 C058 Pos. ID Name Erforderlich Wiederholung Typ 010 3035 PARTY FUNCTION CODE QUALIFIER M 1 an..3 020 C082 PARTY IDENTIFICATION DETAILS C 1 3039 Party identifier M an..35 1131 Code list identification code C an..17 3055 Code list responsible agency code C an..3 030 C058 NAME AND ADDRESS C 1 3124 Name and address description M an..35 3124 Name and address description C an..35 Tabelle 2. Ausschnitt aus der Spezifikation für das Datenelement NAD (Name And Address). Branchenspezifische e und Standards Tradacoms ist ein veralteter Standard, der inzwischen durch den EDIFACT EANCOM Standard ersetzt wird. Der Tradacom Standard war 1982 eingeführt worden und hauptsächlich für den Datenaustausch im Handel im Vereinigten Königreich verwendet worden. Die Syntax ähnelt stark der Syntax von EDIFACT. Der Voluntary Inter-industry Commerce Standard (VICS) wird von Handelsunternehmen in Nordamerika eingesetzt und stellt eine Untergruppe von ANSI ASC X12 dar. ebxml ist ein Überbegriff für Standards, die mit dem Dateiformat XML arbeiten. Bspw. PDX, RosettaNet, PLMX und OpenTRANS sind XML-basierte Standards, die im Folgenden erläutert werden. Der Product Data exchange Standard (PDX) (IPC 2001) ist Standard für den Austausch von Produktdaten in der Supply Chain der Elektronikbranche. Der Standard besteht aus einer Serie von IPC- 14
257X Spezifikationen und basiert auf XML. Im Fokus steht dabei der Austausch von Produktinformationen zwischen Erstausrüstern ( Original Equipment Manufacturers ), Auftragsfertiger elektronischer Baugruppen ( Electronics Manufacturing Services ) und Zulieferern. Produktinformationen, wie Bill of Materials, technische Änderungsanfragen ( Engineering Change Requests ), Änderungsanweisungen ( Engineering Change Orders ) und Abweichungen werden im XML-Format abgelegt und den Stationen der Supply Chain in einem einheitlichen Format zur Verfügung gestellt. Der PDX hat Schnittstellen zu weiteren Standards: Der GenCAM (IPC 2510) Standard gewährleistet, dass elektronische Leiterplatten so beschrieben werden, dass auf Basis dieser Beschreibung eine Anfertigung und Montage durchgeführt werden kann. Da der PDX-Standard diesem hohen Detailgrad nicht genügt, können GenCAM-Dokumente in PDX-Paketen enthalten seien. Der RosettaNet Dokumenten Standard (GS1 US 2013) basiert auf XML. RosettaNet ist ein Konsortium von Computer-, Unterhaltungselektronik-, Halbleiter-, Telekommunikations- und Logistikunternehmen und zielt auf einen koordinierten Prozess unter Partnern einer Supply Chain ab. Dazu werden die Schnittstellen für einen Austausch zwischen den Partnern definiert, damit Daten über Produkte und elektronische Komponenten ausgetauscht werden können. Ein Mechanismus für den Austausch von Herstellungsinformationen ist in der Entwicklung, wird aber schon vom PDX-Standard bereitgestellt. Der OAGIS-Standard (vgl. S.16) definiert Schnittstellen zwischen Anwendungen von Unternehmenssoftware. Schnittstellen zum PDX existieren nur im geringen Umfang. Das Produkt Lifecycle Management exchange (PLMX) (The PLMX Partnership 2007) wurde für die technische und herstellende Industrie geschaffen, um einen Produktdatentransfer zwischen Computersystemen innerhalb des Unternehmens und mit Supply Chain Partnern zu ermöglichen. Das Format ist frei verfügbar und XML-basiert. PLMX besteht aus einer XML-Schema Datei und einem komprimierten ZIP-Archiv, in dem sich die entsprechende XML-Datei befindet und weiter Dokumente enthalten sind. Der opentrans 2.0 (CC Electronic Business Fraunhofer IAO 2013) ist ein offener XML-basierter Standard, der Geschäftstransaktionen zwischen Handelsunternehmen unterstützt. Der Standard wird seit 2001 entwickelt, die aktuelle Version wurde zuletzt 2009 überarbeitet. Mit Hilfe von opentrans wird der Austausch sogenannter Geschäftsdokumente ermöglicht. Beispiel für Geschäftsdokumente sind Angebote (QUOTATION), Bestellungen (ORDER) und Auftragsbestätigungen (ORDERRESPONSE). Ein solches Dokument besteht aus den drei Elementen Kopfbereich, Positionsbereich und Zusammenfassung. Im Kopfbereich/Header werden Metadaten erfasst, wie z.b. Ersteller und Adressat des Dokuments. Der Positionsbereich (ITEM_LIST) enthält bspw. die Produkte oder Lieferpositionen eines Auftrags. Der zusammenfassende Teil (SUMMARY) dient der Überprüfung der im Dokument enthaltenen Informationen. Der Verband der Automobilindustrie (VDA) aus Deutschland spricht Empfehlungen für EDI zugeschnitten auf die Automobilindustrie aus. Zunächst war unter dem Namen VDA-FS ein Standard zum Austausch für CAD Daten entwickelt worden, der inzwischen durch den STEP Standard ersetzt wurde. Konkret empfohlen werden Formate für bspw. Lieferscheine (VDA 4913), Computer Aided Manufacturing (CAM) / CAD-Daten (VDA 4951) und Materialkennzeichnungen für das Recycling (VDA 260). Letzteres definiert die Stoffkennzeichnung von Automobilteilen fest, um eine möglichst hohe Rate an Wiederverwertung zu erreichen. Dazu werden in einer internationalen Materialdatenbank (Hewlett Packard 2013) alle Teile bis hin zu ihrer chemischen Zusammensetzung aufgeschlüsselt. Um einem globalen Standard zu fördern, entwickelt sich der VDA seit 2011 in Richtung des EDIFACT 15
Standards. Der VDA 6.X Standard ist für das Qualitätsmanagement bestimmt und in die Teile Management und Produkte/Prozesse unterteilt. Die Organization for Data Exchange by Teletransmission in Europe (ODETTE) vertritt die Interessen der Automobilindustrie in Europa und stellt das Äquivalent der Automotive Industry Action Group (AIAG) in Nordamerika, der Groupement pour l Amélioration des Liaisons dans l Industrie Automobile (GALIA) in Frankreich oder des VDA in Deutschland dar. Dieser auf dem Syntaxnormen des EDIFACT- Standards basierende Standard löst nach und nach den VDA Standard ab. Aus der Arbeit von ODETTE resultiert bspw. das Odette File Transfer Protocol (OFTP), welches die Kommunikation zwischen Geschäftspartnern ermöglicht. Im Gegensatz zu en handelt es sich beim OFTP um ein Protokoll zur Datenübertragung, das bspw. Nachrichtenverschlüsselung, -signierung und -kompression unterstützt. Des Weiteren wird von ODETTE eine Menge an auf die Bedürfnisse der Automobilindustrie zugeschnittenen Dokumentenstandards bereitgestellt. Teil dieser Standards ist die Auszeichnung von Bauteilen durch ODETTE- oder VDA-Labels, die beim Automobilhersteller sofort lesbar sein müssen. Ein Beispiel für den Einsatz von ODETTE bei der Firma Volvo findet sich bei (VOLVO 2008). Die Society of Worldwide Interbank Financial Telecommunication (SWIFT) betreibt ein weltweites System für den Nachrichtenaustausch zwischen Banken und anderen Institutionen der Finanzwirtschaft. SWIFTNet stellt dabei die notwendige Infrastruktur für den Datenaustausch bereit und die Module FIN, InterAct und FileAct das. Der SWIFT Standard wurde 1977 ins Leben gerufen und ist damit der älteste EDI-Standard. Die Open Application Group Integration Specification (OAGIS) wurde 1994 gegründet, um einen Standard zu schaffen, der die Kommunikation unter Geschäftsanwendungen ermöglicht. Die übermittelten Nachrichten werden unter OAGIS als Business Object Documents (BOD) bezeichnet (OAGIS 2013). Das Format wir mit Hilfe von XML Schema beschrieben. EIN BOD besteht aus einer Application Area und einer Data Area. Die Application Area fungiert als Header und enthält Informationen, die von der Kommunikationsinfrastruktur genutzt werden können. In der Data Area werden geschäftsspezifische Informationen in Form von Nomen und Verben abgelegt. Verben spezifizieren die Aktionen, die von einem Nomen ausgeführt werden, während Nomen die geschäftsspezifischen Informationen enthalten, wie z.b. Bestell- und Lieferauftragsdaten. Ein Nomen enthält des Weiteren Komponenten, die in Felder (z.b. Name und Beschreibung) und Verbünde (z.b. Menge und Betrag) unterteilt sind. Ein Beispiel für Standards bzgl. des elektronischen Datenaustauschs bzw. der Datenverwaltung im Gesundheitswesen im Raum Nordamerika stellt der Health Insurance Protability and Accountability Act (HIPAA) dar, der 1996 vom U.S. Kongress beschlossen wurde. Übersicht Eine Übersicht zu allen beschriebenen und weiteren Standards sowie deren Eigenschaften liefert Tabelle 3. Es ist zu beachten, dass die Liste der Standards und Formate in diesem Kapitel keineswegs vollständig ist, sondern lediglich die am häufigsten anzutreffenden Standards und Formate abdeckt. Gerade im Unternehmensumfeld sind viele Individuallösungen anzutreffen, die nicht offen zugänglich sind. Die wichtigsten Formate im Hinblick auf die Verbreitung sind der STEP in der Produktentwicklung, EDIFACT in seinen verschiedenen Ausprägungen, SWIFT im Finanzbereich und AIAD/ODETTE im Automobilsektor. Eine sehr detaillierte Auflistung von Standards mit vielen sehr spezifischen en enthält die Liste des Auto-ID Centers am MIT (Auto-ID Center MIT 2002), die jedoch in Teilen veraltet ist. Bei der Betrachtung von Tabelle 3 ist zu beachten, dass leere Felder entweder auf mangelnde Informationen zurückzuführen sind oder keine eindeutige Zuordnung, bspw. bezüglich der relevanten Lebenszyklusphase oder der Daten, möglich war. Die e bzw. Standards sind in der Ausprägung gemäß sieben Kategorien arrangiert. Pro Eintrag werden relevante 16
Lebenszyklusphase, Branche, abgebildete Daten, Angaben zu Format, Herkunftsland, Gründungsdatum und die Organisation, die hinter der Entwicklung des betrachteten Formats/Standards steht, aufgeführt. Standard/ Format PLM XML Lebenszyklusphase Branche Daten Format Land Gründung Produktstrukturenland XML Deutsch- Prozessinformationen Organisation Proprietär, Siemens AG ODETTE, mehrere Normen VDA, mehrere Normen GALIA SWIFT, mehrere Normen GAEB DA XML EDIFACT GenCAM PDX XBRL VICS, ANSI ASC X12 Subset TRADACOMS, Vorgänger zu EDIFACT EANCOMS OPENTrans Leiterplattendesign CAD-, Tabellenund Design- Daten Finanzdaten zur Berichterstattung Design/ Produktion Materialbeschaffung/ Produktion/ Transport Produktion, Transport, Lagerung Produktion und Wartung Deutschland Automobilindustrie Finanzinstitute HIPAA, Kongressverordnung RosettaNet Gesundheitswesen Handel Handel SDXF Hierarchisch 2000 Frei, Privat JT (Jupiter) Design Maschinenbau 3D-Daten, CAD Szenengraph USA/ Deutschl. 1998 Proprietär, Siemens AG AIAG, mehrere Normen Automobilindustrie USA Proprietär, AIAG Automobilindustrie Automobilindustrie Geschäftsdokumente, CAD-Daten (VDA-FS) Logistikund CAD- Daten EU 1978 (VDA 4905) Proprietär, ODETTE Proprietär, VDA Basiert in Frankreich 1984 GALIA großen Teilen auf EDIFACT Finanzdaten Internat. 1977 Proprietär, SWIFT Hierarchisch/ XML Deutschland 1985 GAEB UN/EDIFACT: Internat. 1987 Frei, United hierarchisch; Nations XML/EDIFACT: XML XML 2000 Frei, IPC Branchen spezifische Spezialisieru ngen Elektroindustrie Elektroindustrie Nordamerika Geschäftsdokument Banken- und Finanzwesen Bauwesen Projektbasiert Bauinformation XML 2001 Frei, IPC XML USA/ International Nordamerika 1999 Frei, XBRL- Organisation 1996 Staatlich XML Internat. 1998 Frei, Konsortium/ GS1 US Hierarchisch, vergleichbar mit EDIFACT XML Halbleiterindustrie, Elektronik, Telekommunikation, Logistik Handel Geschäftsdokumente UK 1982 Frei, GS1 UK Deutschl./ Internat. 1999 Frei, Konsortium/ Frauenhofer 17
OAGIS SEDAS, Vorgänger zu EDIFACT EANCOM Produktion und Wartung Hauptsächlich IT Geschäftsdokument Konsumgüterwirtschaft/ Handel myopen- Factory PLMX ANSI IGES, Vorgänger zu STEP STEP Auftrags- u. Projektabwicklung Design und Konstruktion Maschinenbau Design und Konstruktion Maschinenbau CAD-, PLM-, ERP-, SCMund CRM- Daten 3D-Objekt in CAD 3D-Objekt in CAD Rechnungsund Bestelldaten XML USA 1994 Proprietär, Konsortium/ OAGi Deutschland 1977 GS1 Germany Microsoft Excel XML E-Rates Transport Logistik Luftfrachtdaten Fortras Transport/ Logistik Speditionsdaten Lagerung Deutschland Deutschland/ EU Maschinen- & Anlagenbau Maschinenbau Auftragsdaten Deutschland 2002 Konsortium Proprietär, System Alliance 2006 Proprietär, myopen- Factory GmbH XML USA 2007 Frei, PLMX Partnership/ Active Sensing Inc. IGES-File in 80 Char ASCII Datensätzen (Lochkartenära) STEP-File (ASCII), STEP- XML USA 1979 Proprietär, Konsortium/ NIST Internat. 1984 Proprietär, ISO/TC 184 Automation Systems and Integration PML Mehrere XML USA 2002 Frei, Auto-ID Center MIT Tabelle 3. Ausgewählte Standards und e. Branchenspezifische Datenempfehlung anhand dreier Fallbeispiele Branchen oder Wirtschaftszweige sind gemäß (Porter 2008) als Gruppen von Unternehmen aufzufassen die eng verwandte Substitute produzieren. Die Einordnung von Unternehmen wird von einzelnen Staaten vorgenommen, die zum Teil auf eigenen oder länderübergreifenden, internationalen Standards beruht. Die in Deutschland derzeit gebräuchliche Klassifikation von Wirtschaftszweigen ist die WZ 2008 (Statistisches Bundesamt 2008). Die aktuelle Gliederung umfasst momentan 21 Wirtschaftsabschnitte. Die Abschnitte werden über Kennbuchstaben (A-U) identifiziert und weiter über Kennzahlenbereiche in 88 Abteilungen, 272 Gruppen, 615 Klassen und 839 Unterklassen unterteilt. Die hier behandelten Beispiele sind im Bereich des verarbeitenden Gewerbes (Abschnitt C) in den Kennzahlenbereichen 10 für Herstellung von Nahrungs- und Futtermitteln (Beispiel 1) und 28 für Maschinenbau (Beispiel 2) sowie im Bereich des Verkehr und der Lagerei (Abschnitt H) im Kennzahlenbereich 52 für Lagerei sowie Erbringung von sonstigen Dienstleistungen für den Verkehr (Beispiel 3) anzusiedeln. (Silverston 2001) stellt branchenspezifische Datenmodelle für die Bereiche Fertigung, Telekommunikation, Gesundheitswesen, Versicherungen, Finanzwesen, Dienstleistung/Professional Services, Reisen und E-Commerce dar. (Hay 2011) bietet neben Datenmodellen für Unternehmensbereiche auch industriespezifische Beispiele aus den Bereichen Kriminologie, Mikrobiologie, Bankwesen, Ölfeldproduktion und Straßenverkehrsbau. All diese Modelle sind allerdings auf Datenbanken zugeschnitten und vernachlässigen den Aspekt der Domänenübergänge, d.h. den Austausch von produktrelevanten Daten zwischen Teilnehmern einer Supply-Chain oder eines Produktlebenszyklus. Daher wird im Folgenden anhand dreier Beispiele der Austausch von Informationen unter Berücksichtigung der Domänenübergänge illustriert. Die Beispiele werden 18
entlang des in Abbildung 8 skizzierten Produktlebenszyklus betrachtet, wobei auch Aspekte des SCM berücksichtigt werden. So stellt das Zentrum des Lebenszyklus das Informationsmodul dar, welches durch das OMM realisiert werden kann. Daten werden dabei Objekten zugeordnet und können zentral oder verteilt organisiert werden. Die Art der Daten in Abhängigkeit von der gegenwärtigen Lebenszyklusphase und des ausgewählten Wirtschaftsbereichs ist Gegenstand der folgenden Diskussion: Abbildung 8. Produktlebenszyklus am Beispiel Pizza. Beispiel 1: Lebensmittelindustrie / Handel Objekt: Tiefgekühlte Lachs-Spinat Pizza Design Das Design entspricht in der Lebensmittelindustrie der Kombination und Dosierung von Zutaten für ein konkretes Produkt. Dieses Rezept stellt die Grundlage für die Produktion dar, anhand derer die Fertigung durchgeführt wird. Im Designprozess sollten zunächst Informationen über die Entscheidungen zur Wahl der Zutat und Dosierung abgelegt werden, damit die Begründung für die Rezeptur aus dem Produktgedächtnis hervorgeht. Das finale Rezept stellt den Output des Designprozesses und zugleich den Input für den Folgeprozess dar. Anhand der Angaben im Rezept muss es möglich sein die notwendigen Zutaten zu beschaffen und die Art der Verarbeitung zu bestimmen, um die Produktion planen zu können. Bezüglich Herkunft und Art der Zutat bleibt das OMM zu diesem Zeitpunkt für gewöhnlich noch variabel, es sei denn bestimmte Reglementierungen werden bereits zur Design-Zeit getroffen, bspw. in Form einer Fair-Trade-Policy, die alle nicht Fair-Trade Lieferanten ausschließt. Im 19
vorliegenden Beispiel setzt sich das Rezept aus den Zutaten zusammen, die in Abbildung 9 in hierarchischer Weise dargestellt sind. Es wurde kein Format identifiziert, das die Entwicklung von Lebensmittelprodukten explizit unterstütz. Empfohlen wird daher die Verwendung branchenunabhängiger Formate, wie PLM XML, SDXF, PML sowie gängiger Formate, wie XML und JSON. Materialbeschaffung Abbildung 9. Zusammensetzung einer Lachs-Spinat Pizza. Während der Materialbeschaffungsphase geht es primär darum Daten über die Eigenschaften und Herkunft einzelner Materialien, hier die Zutaten der Pizza, zu erfassen. Dies ermöglicht in Folgeprozessen die Identifikation der Zutaten im konkreten Produkt. Für eine Pizza kann also bspw. zurückverfolgt werden aus welchem Fanggebiet der Lachs auf der Pizza kommt. Dies kann sich von Pizza zu Pizza unterscheiden. Des Weiteren ist die Identifikation einzelner sstoffe, die in den Zutaten enthalten sind möglich, bspw. zur Information von Allergikern. Zu den in der Designphase genannten Formaten werden nun noch Formate zur Unterstützung der Bestell und Einkaufsprozesse relevant. Eingesetzt werden können dafür z.b. VICS, EDIFACT und OPENTrans. 20