datenfernübertragung von cad/cam daten€¦ · vereinbarungen zum cad/cam datenaustausch vda 4950...

VDA Datenfernübertragung von CAD/CAM Daten 4951

Part 2: VDA-ENGPART V4.1 P 2

Die unverbindliche VDA-Empfehlung 4951 beschreibt Absprachen hinsichtlich Verfahren, Formaten und Inhalten von Dateien, die den Austausch von CAD/CAM - Daten und der dazugehörenden administrativen Informationen standardisieren und dadurch zuverlässig und sicher machen.

Aufgrund der Vielzahl der Themen im Aufgabengebiet des CAD/CAM-Datenaustausches ist die Empfehlung in einzelne Teildokumente gegliedert, die sich jeweils einem Thema widmen, teilweise aber auch aufeinander verweisen oder aufbauen. Die Nummerierung der Teildokumente sagt nichts über den Zusammenhang oder eine Priorität aus, sie ist lediglich historisch bedingt.

Dieser Teil: "Part 2: VDA-ENGPART V4.1" beschreibt das Format zum Austausch der Information, die zur Einrichtung der Kommunikationswege zwischen Endbenutzern notwendig ist.

Version 4.1 vom November 2009

ersetzt Version 2.2 vom Oktober 2005

Abteilung Logistik - Arbeitskreis "PLM"

Herausgeber: Verband der Automobilindustrie Copyright

Westendstraße 61 Nachdruck und jede sonstige Form Postfach 17 05 63 der Vervielfältigung ist nur mit

60079 Frankfurt Angabe der Quelle gestattet. Telefon 069/97507-284 Telefax 069/97507-300 Internet: www.vda.de

mailto:[email protected]

VDA-Empfehlung 4951 P 2 Version 4.1, November 2009 Seite 2 von 50

Copyright: VDA

Haftungsausschluss

Die VDA-Empfehlungen sind Empfehlungen, die jedermann frei zur Anwendung stehen. Wer sie anwendet, hat für die richtige Anwendung im konkreten Fall Sorge zu tragen. Sie berücksichtigen den zum Zeitpunkt der jeweiligen Ausgabe herrschenden Stand der Technik. Durch das Anwenden der VDA-Empfehlungen entzieht sich niemand der Verantwortung für sein eigenes Handeln. Jeder handelt insoweit auf eigene Gefahr. Eine Haftung des VDA und derjenigen, die an den VDA-Empfehlungen beteiligt sind, ist ausgeschlossen. Jeder wird gebeten, wenn er bei der Anwendung der VDA-Empfehlungen auf Unrichtigkeiten oder die Möglichkeit einer unrichtigen Auslegung stößt, dies dem VDA umgehend mitzuteilen, damit etwaige Mängel beseitigt werden können.


Copyright: VDA

Inhaltsverzeichnis

1 Allgemein ...................................................................................................................... 4

1.1 Anwendung ........................................................................................................... 4

1.2 Ziele der Empfehlung ............................................................................................ 5

1.3 Änderungen gegenüber der Vorversion ................................................................ 5

1.4 Kompatibilität zu Vorversionen .............................................................................. 6

1.5 Abkürzungen, Begriffe, Definitionen ...................................................................... 7

2 Die ENGPART-Message .............................................................................................. 8

2.1 Zielsetzung ............................................................................................................ 8

2.2 Inhalt und Struktur der ENGPART-Message ......................................................... 9

2.3 Varianten der ENGPART-Message ..................................................................... 12

2.4 Die Extensible Markup Language (XML) als Datenformat ................................... 13

2.5 Syntax-Beispiele der ENGPART-Message ......................................................... 14 2.5.1 Beispiel (A) einer kompletten/vollständigen ENGPART-Message ................ 14 2.5.2 Syntax-Beispiele für ENGPART-Updates .................................................... 16

2.6 Verfahren ............................................................................................................ 22 2.6.1 Übermittlung ................................................................................................. 22 2.6.2 Erzeugung und Empfang ............................................................................. 22 2.6.3 Automatische Verarbeitung .......................................................................... 23 2.6.4 Manuelle Verarbeitung ................................................................................. 24

Anhang A Inhalt der Partnerdaten ................................................................................ 25

Anhang B XML-Schema (XSD) einer vollständigen ENGPART-Message .................... 31


Copyright: VDA

1 Allgemein

1.1 Anwendung

Der Produktentstehungsprozess in der Automobil- und Automobilzulieferindustrie ist wesentlich geprägt durch den Einsatz moderner Informations- und Kommunikations-Technologien wie Computer-Aided-Design- (CAD), Computer-Aided-Manufacturing-Systeme sowie Produktdaten-Management-Systeme. Im Rahmen ausgedehnter Kooperationspartnerschaften werden die Daten dieser Systeme meist über weite Entfernungen zwischen den Kooperationspartnern ausgetauscht.

Ein solcher Austausch erfolgt zunehmend über (öffentliche) Netzwerke. Diese Art der Datenübertragung wird Datenfernübertragung (DFÜ) genannt. Die Vorzüge von DFÜ sind der geringe Zeitverlust und eine Automatisierung von Prozessen. Beides funktioniert aber nur dann zuverlässig, wenn gemeinsam festgelegte Regeln eingehalten werden.

Um dies zu ermöglichen werden in dieser Empfehlung Inhalt, Struktur und Format einer maschinell lesbaren Partner-Profilbeschreibung (Engineering-Partner-Data, kurz „ENGPART“) definiert.

ENGPART Version 4.1 ist als Ergänzung zum geltenden ENGDAT-Standard (Engineering-Data-Message) Version 3.1 der Exchange and Management Group of Technical Data (XMTD) Work Group der Stategic Automotive product data Standards Industry Group (SASIG) zu betrachten.

Der ENGDAT-Standard definiert einen elektronischen Lieferschein, die ENGDAT-Message, mit dessen Hilfe ein umfangreicher, weltweiter Austausch technischer Daten zwischen Kooperationspartnern automatisch abgewickelt und administriert werden kann.

Die durch eine ENGPART-Message ausgetauschten Partnerinformationen werden dazu verwendet, die bei einem Sendeauftrag zu generierende ENGDAT-Message mit korrekten Informationen über beteiligte Kommunikationspartner zu befüllen.

Diese Empfehlung stellt eine Ergänzung zu folgenden für den CAD/CAM - Datenaustausch erarbeiteten Empfehlungen und Normen dar:

Datenfernübertragung von ODETTE - Nachrichten (EDIFACT - Nutzdatenrahmen) VDA 4900

File-Transfer-Protokoll (OFTP) VDA 4914/2

Vereinbarungen zum CAD/CAM Datenaustausch VDA 4950

Umfang und Qualität von CAD/CAM-Daten VDA 4955

Flächenschnittstelle VDAFS 1.0 / 2.0 DIN 66301

Regeln für den CAD - Datenaustausch VDMA / VDA 66318

VDAIS (IGES - Subset) VDMA / VDA 66319

EDIFACT - Syntax Regeln DIN ISO 9735


Copyright: VDA

1.2 Ziele der Empfehlung

Ziel der Empfehlung ist es den Einsatz der ENGPART - Datei als verbindliches Verfahren beim CAD/CAM-Datenaustausch zu etablieren und die Entwicklung dafür notwendiger Software zu fördern.

1.3 Änderungen gegenüber der Vorversion

Version Änderung Kapitel Seite

1 keine, es erfolgte lediglich die Aufteilung in Teildokumente

2.0 Die ENGPART Version 4 stellt gegenüber den Vorgängerversionen 1-3, d.h. der Dokumentversion 1 eine signifikante Veränderung und Erweiterung dar.

Die wesentlichen Änderungen werden im Anschluss an diese Tabelle aufgelistet.

Alle Alle

2.1 Schema und XML-Beispiele korrigiert 2.5

2.2 Neues Layout, Haftungsausschluss hinzugefügt Alle Alle

2.3 Update gemäß SASIG ENGPART V4.1 vom Dez. 2007 2.2 11

Datenformat: Die Veränderungen in ENGPART zwischen dieser Version (4.*) und den vorhergehenden Versionen sind enorm. Diese neue Version führt eine neue Implementierungsmethode ein: XML. Daher ist es nicht praktikabel die Kompatibilität mit den Vorgängerversionen der ENGPART zu fordern. Die folgenden Kommentare sind daher eher informativ als kritisch bezüglich der Interoperabilität. Falls Interoperabilität zu vorhergehenden Versionen gefordert werden und Implementoren feststellen, dass ein Mapping von V3 zu V4.* grundsätzlich möglich ist, aber in umgekehrter Richtung viele Attribute kein Gegenstück finden. ENGPART Version 3 war kompatibel zu den ENGDAT Versionen 1 und 2 verfasst. ENGPART Version 4 ist kompatibel zu ENGDAT Version 3, die ebenso die neue Implementierungsmethode XML einführt und alle EDIFACT Notationen eliminiert. ENGPART wurde darüberhinaus vom Deutschen ins Englische übersetzt und, nach der Analyse von Unstimmigkeiten mit ENGDAT, korrigiert. Schließlich wurde, auf Basis der Version 4.1 der ENGPART, die ENGDAT Version 3.1 auf Einflüsse zur ENGPART untersucht und notwendige Ergänzungen und kleinere Änderungen vorgenommen.

Update-Mechanismus:

Mit Version 4 der ENGPART ist ein weitgehend beliebiger Austausch von Teilumfängen der Partnerinformationen (Partnerdaten-Deltas) möglich. Um dabei die Konsistenz und Redundanzfreiheit der Partnerdatenbestände zu sichern, beinhaltet Version (V) 4 einen Mechanismus, durch den sowohl die Kommunikationspartner als auch ausgetauschte Partnerinformationen einheitlich und zuverlässig mit Hilfe eindeutiger Kennungen identifiziert werden können.

Zur Identifikation der Kommunikationspartner wird in ENGPART V4 die DUNS-Number (Dun & Bradstreet – Data Universal Numbering System) genutzt. Dies ist eine weltweit eindeutige, kostenlose, zentral verwaltete 9-stellige Nummer. Über diese Nummer kann jeder Kommunikationspartner oder Organisationseinheit eines Partners eindeutig


Copyright: VDA

identifiziert werden. Voraussetzung ist, dass die beteiligten Partner diese Nummer beantragt haben.

Die Identifizierung eines Austauschpartners in ENGPART V4.1 wurde erweitert um nicht nur die DUNS-Nummer, sondern auch Nummern anderer Identifizierungssysteme zu erlauben. Dennoch bleibt die DUNS-Nummer das bevorzugte System. Das DUNS-Nummer-Feld wurde umbenannt und vergrößert sowie ein neues Feld hinzugefügt um das Nummerierungssystem anzugeben. Für DUNS lautet die Identifizierungsnummer: 16.

Alle Informationsblöcke innerhalb einer ENGPART werden ebenfalls durch eindeutige Identifier gekennzeichnet, für die der Erzeuger einer ENGPART verantwortlich ist. Gliederung der Informationsblöcke:

Zahlreiche Neuerungen wurden an der thematischen Gliederung der ENGPART-Message gegenüber der Vorgängerversion vorgenommen. Dies betrifft zum einen die Neugruppierung und Umbenennung einzelner ENGPART-Abschnitte und zum anderen die Überarbeitung darin enthaltener Informationen.

Die bisherige Reihenfolge der Einzelinformationen wurde dahingehend geändert, dass zusammengehörende Datenelemente nun sinngemäß zu abgeschlossenen ENGPART-Informationsblöcken zusammengefasst werden. Damit wird für eine einfach verständliche, realitätsnahe Abbildung von Organisationsstrukturen und der beim Kooperationspartner angesiedelten IuK-technischen Infrastruktur gesorgt.

In der ENGPART V4 wurde darauf verzichtet, der „Information über Empfänger“ wie bisher ein eigenes Kapitel zu reservieren. Außerdem sind nun im ENGPART-Abschnitt „Information über Kommunikation“ ENGPART-Informationsblöcke zu den Themen Odette-File-Transfer-Protokoll (OFTP), File-Transfer-Protokoll (FTP) und Offline-Medium vorgesehen. Das Kapitel „Nutzdatenspezifische Informationen“ wurde in die ENGPART-Abschnitte „Information über Austauschformat“ und „Information über Systeme“ untergliedert, um jede Art Daten verarbeitender IuK-Systeme sowie beliebige Formate zu beschreiben. Ein Kapitel „ENDE ENGPART“ wird nicht unterstützt. Feldinhalte:

Die Überarbeitung der in ENGPART enthaltenen Einzelinformationen betrifft vor allem bisher wenig genutzte oder veraltete Datenelemente. Sie wurden aus dem ENGPART-Umfang entfernt. Andererseits wurde die ENGPART durch neue, notwendig gewordene Datenelemente ergänzt.

1.4 Kompatibilität zu Vorversionen

Mit Veröffentlichung dieser Version wird empfohlen, auch die vorherige Version sowohl als Sender als auch als Empfänger zu unterstützen.


Copyright: VDA

1.5 Abkürzungen, Begriffe, Definitionen

Abstract-Datei

Die Abstract-Datei enthält die entsprechend der ENGDAT-Definition (siehe VDA4951/1) für die Zustellung und Verarbeitung eines ENGDAT-Paketes notwendigen Informationen.

ENGDAT-Paket

Unter ENGDAT-Paket wird die Gesamtheit der Dateien verstanden, die entsprechend der ENGDAT-Definition (siehe VDA4951/1) versendet werden, also die Abstract-Datei sowie alle über die Namenskonvention zum Paket assoziierten Nutzdateien.

ENGPART-Message

Die ENGPART-Message ist sowohl eine maschinell als auch für Menschen einfach lesbare Partner-Profilbeschreibung, die den vollständigen Umfang oder einen Teilumfang aller für den Nutzdatenaustausch notwendigen Partnerinformationen beinhaltet.

ENGPART-Abschnitte

Die in einer ENGPART-Message enthaltenen Partnerinformationen werden themenspezifisch in so genannte ENGPART-Abschnitte untergliedert. Ähnlich wie ein Kapitel, enthält jeder ENGPART-Abschnitt Informationen zu einem bestimmten Themenbereich der Partnerinformationen wie z. B. Information über Sender oder Information über Austauschformate.

ENGPART-Informationsblöcke

ENGPART-Informationsblöcke bündeln innerhalb von ENGPART-Abschnitten zusammengehörende Informationen. So sind beispielsweise im ENGPART-Abschnitt "Information über Austauschformate" alle Daten eines bestimmten Austauschformats zu einem ENGPART-Informationsblock zusammengefasst.

ENGPART-Einzelinformationen

ENGPART-Einzelinformationen beschreiben einzelne, in der ENGPART-Message enthaltene Partnerinformationen. Diese werden zu Informationsblöcken zusammengefasst. Jede ENGPART-Einzelinformation setzt sich zusammen aus einem XML-Datenelementbezeichner (TAG) und dem Datenelement selbst, welches die eigentliche Partnerinformation repräsentiert.


Copyright: VDA

2 Die ENGPART-Message

2.1 Zielsetzung

Der vermehrte Einsatz des elektronischen Datenaustausches hatte zur Folge, dass der Austausch von Informationen zur Einrichtung und Pflege der administrativen Daten für die Datenaustauschbeziehungen manuell und damit zeitintensiv über Fax oder Telefon zwischen den unterschiedlichsten Stellen und Abteilungen der beteiligten Firmen erfolgte. Dieser Umstand war der Anstoß dafür, Inhalt und Format einer Datei zu definieren, mit der diese Informationen automatisiert übertragen werden können.

Ziel ist, den mündlichen oder schriftlichen Austausch von Information zur Einrichtung oder auch Veränderung neuer oder bestehender Partner-Beziehungen zu ersetzen. Unter Partnern sind dabei jeweils die Personen oder Stellen zu verstehen, die den Austausch von Daten anstoßen. Nur zur Einrichtung einer ersten DFÜ-Verbindung wird evtl. Telefon, Fax oder E-Mail benötigt.

Unternehmen A

Informationssystem

Unternehmen B

Informationssystem

Kommunikationsmedium

ENGPART-Message

Administrative Informationen


Copyright: VDA

2.2 Inhalt und Struktur der ENGPART-Message

Inhalt der ENGPART-Message

In einer ENGPART-Message teilt eine Firma/Firmenguppe jeweils einer anderen Firma/Firmenguppe folgende Informationen mit:

In den Datenaustausch involvierte Organisationseinheiten (Abteilungen, Personen)

Für die Übertragung sowie die Weiterverarbeitung von Informationen notwendige Parameter der IuK-Infrastruktur verschiedener Firmenstandorte

Endbenutzer der entsprechenden Standorte, die jeweils Daten von der betreffenden Partnerfirma erhalten dürfen

Diese Informationen stehen größtenteils in Relation zu entsprechenden Informationen in der ENGDAT-Message.

Mit diesem bilateralen Austausch von Informationen wird sichergestellt, dass jeweils nur die für einen bestimmten Partner relevanten Informationen in einer Datei enthalten sind und somit nicht ungewollt Informationen an Unbefugte übermittelt werden. Für die Einhaltung dieser Regelung ist jeweils der Sender der ENGPART-Message verantwortlich.

Das Verfahren der Erstellung kann jeder Sender selbst wählen (Editor, selbst geschriebene Programme, Software im Rahmen von EDI-Systemen...), wesentlich ist die Einhaltung des in dieser Empfehlung definierten neutralen Formates der ENGPART-Message. Durch den Einsatz von XML als Datenformat ist eine unkomplizierte manuelle Erstellung sowie Auswertung einer ENGPART-Message möglich.

Struktur der ENGPART-Message

Durch eine gezielte Modellierung des XML-Datenformates ist es möglich, die in einer ENGPART-Message enthaltenen Partnerinformationen klar zu strukturieren. Alle Partnerinformationen werden themenbereichsspezifisch in so genannte ENGPART-Abschnitte (z. B. Sender Company Details) untergliedert. Zusammengehörende Einzelinformationen werden darin außerdem zu ENGPART-Informationsblöcken zusammengefasst, die einmal oder mehrmals je ENGPART-Abschnitt vorkommen können (z. B. Company Site).


Copyright: VDA

ENGPART-Message

Message Identifier (Status der Austauschdaten)

Sender Company Details (Information über Sender)

Sender Communication System (Information über Kommunikation)

Exchange File Format (Information über Austauschformat)

Exchange File Generating System (Information über Systeme)

Receiver Company Details

Company Site

Company Contact

Communication System OFTP

Communikation System Offline

File Format

Generating System

Destination Address

Sender Destination Address (Zieladressen)

ENGPART-Abschnitt ENGPART-Informationsblock aus Einzelinformationen

Communication System FTP


Copyright: VDA

Identifikation von Kommunikationspartnern und Partnerinformationen

Zur Identifikation der Kommunikationspartner wird die durch das Projekt Unique Partner Identifikation Key (UPIK) des VDA überarbeitete Dun&Bradstreet DUNS-Number favorisiert, aber Identifikatoren anderer Systeme sind ebenso zulässig. Damit ist sichergestellt, dass die durch die ENGPART-Message ausgetauschten Informationen innerhalb der Partnerdatenbanken den beteiligten Kooperationspartnern korrekt zugeordnet werden können.

Durch Verwendung des XML-Datenformates ist es außerdem möglich, ein erheblich vereinfachtes System eindeutiger Kennungen zur Identifikation der Partnerinformationen zu verwenden.

So besitzt jeder in den ENGPART-Abschnitten enthaltene ENGPART-Informationsblock einen firmenweit eindeutigen Identifier. Die hierarchische Struktur des XML-Datenformates sowie die eindeutigen und aussagekräftigen XML-Datenelementbezeichner (Tags) der ENGPART-Einzelinformationen erlauben eine eindeutige und klare Identifikation aller enthaltenen Partnerinformationen ohne den Einsatz weiterer Kennungen.

Standort A

Standort B

ID

ID

ID

Datenelement

…

Ansprechpartner 1

Weltweit eindeutige FirmenID DUNS-Nr. (oder äquivalent)

Informationsblöcke

CompanySite

Company Contact

Mustermann Heinz

…

…

Bsp-Einzelinformationen

von

ID Ansprechpartner 2

Ansprechpartner 1

ENGPART-Abschnitt SenderCompanyDetails


Copyright: VDA

2.3 Varianten der ENGPART-Message

Grundsätzlich können Partnerinformationen mit Hilfe zweier unterschiedlicher ENGPART-Varianten ausgetauscht werden. Dies sind eine komplette/vollständige ENGPART-Message, die den gesamten Informationsumfang einer Partnerbeziehung beschreibt, oder ein ENGPART-Update, das nur einen Teilumfang aller Partnerinformationen enthält. Komplette/vollständige ENGPART-Message

Eine komplette/vollständige ENGPART-Message enthält grundsätzlich alle ENGPART-Abschnitte und darin jeweils mindestens einen ENGPART-Informationsblock. Neben einem gewissen Mindestumfang administrativer Informationen müssen alle als obligatorisch definierten Einzelinformation sowie evtl. alle als optional definierten Einzelinformationen in einer kompletten/vollständigen ENGPART-Message enthalten sein.

Die komplette/vollständige ENGPART-Message eignet sich damit besonders für den initialen Informationsaustausch zu Beginn einer Partnerbeziehung. Beim Einpflegen einer kompletten/vollständigen ENGPART-Message wird das Prinzip der Fortschreibung von Informationen in den Partnerdatenbanken nicht eingehalten. So kann mit dem Austausch einer kompletten/vollständigen ENGPART-Message ein Informationsreset einer Kommunikationsbeziehung durchgeführt werden, indem alle bisher vorhandenen Informationen eines Partners aus der Datenbank gelöscht werden und durch die in der ENGPART-Message enthaltenen ersetzt werden. Damit wird sichergestellt, dass die Informationen in den Systemen der Kommunikationspartner im Laufe der Zeit nicht divergieren.

ENGPART-Update

Das ENGPART-Update dagegen dient dem gezielten Austausch bestimmter Teilumfänge von Partnerinformationen. Neben dem Mindestumfang an Informationen, die jede ENGPART-Message aus administrativen Gründen enthalten muss, kann es sich dabei entweder um vollständige ENGPART-Informationsblöcke handeln und/oder nur um bestimmte obligatorische bzw. optionale Einzelinformationen.

Das ENGPART-Update sieht folgende Modifizierungsmöglichkeiten der Partnerinformationen in der Datenbank des ENGPART-Empfängers vor:

Neuanlage vollständiger Informationsblöcke oder Einzelinformationen

Löschung vollständiger Informationsblöcke und/oder Einzelinformationen

Editieren/Überschreiben von Informationsblöcken und/oder Einzelinformationen

Das Löschen von obligatorischen Informationsblöcken ist nicht erlaubt, ebenso wenig das Löschen obligatorischer Einzelinformationen.

Von einer Modifikation ausgeschlossen sind alle identifizierenden Datenelemente. Das heißt zwar, dass im Rahmen eines Updates identifizierende Datenelemente verschwinden können (Löschen von Informationsblöcken; Beispiel B.2.b) oder hinzugefügt werden können (Einfügen / Neu anlegen von Informationsblöcken; Beispiel B.1). Ein vorhandener Informationsblock darf aber während seiner "Lebensdauer" seine Identität nicht verändern.

Besondere Sorgfalt erfordert die Veränderung von Referenzen. Ein Update wie bei Einzelinformationen ist hier nicht möglich, da sie nicht eindeutig identifizierbar sind. Um eine Referenz zu modifizieren, zu löschen oder hinzuzufügen muss immer der gesamte Block an Referenzen übermittelt werden, in dem die zu verändernde Referenz auftritt. Zusätzlich hat der Erzeuger darauf zu achten, dass die beim Empfänger nach einem Update vorliegende Gesamtinformation in sich konsistent und aktuell ist.


Copyright: VDA

Grundsätzlich ist der Sender der Partnerdaten jeweils für den aktuellen Stand seiner Informationen verantwortlich, d. h. bei Änderungen seines eigenen Datenbestandes ist jeweils der neue Stand an die von den Änderungen betroffenen Partnerfirmen zu versenden.

2.4 Die Extensible Markup Language (XML) als Datenformat

Die ENGPART-Message ist im XML-Format codiert. Mit Hilfe einer gezielten Modellierung des XML-Layouts ist es möglich, die in einer ENGPART-Message enthalten Partnerinformationen eindeutig, für den Menschen direkt lesbar und hierarchisch zu strukturieren.

XML-Schema-Definitionssprache

Zur Definition des XML-Layouts der ENGPART-Message wird die XML-Schema-Definitionssprache verwendet.

Im Rahmen des XML-Schemas sind die in der ENGPART-Message enthaltenen Einzelinformationen global als einfache Datentypen definiert. Deren Wertebereich, Länge und Format wird aus bestehenden, vordefinierten, einfachen Datentypen abgeleitet oder auf eine definierte Menge zugelassener Werte beschränkt.

Sowohl die Informationsblöcke einer ENGPART-Message als auch die ENGPART-Abschnitte werden jeweils durch global definierte, komplexe Typen im XML-Schema repräsentiert. Die darin aufgeführten Elementdeklarationen und –referenzen bilden die Struktur der ENGPART-Message im XML-Format ab. So kann die Häufigkeit des Vorkommens sowie die Reihenfolge der enthaltenen Einzelinformationen festgelegt werden, ebenso wie die Häufigkeit und Reihenfolge der ENGPART-Abschnitte und der Informationsblöcke selbst. Der Einsatz abstrakter Typen/Elemente erzwingt an geeigneter Stelle die Verwendung von Ersatzgruppen. Auf die Verwendung von Attributen wurde beim Layout des XML-Formates verzichtet.

Sprach-/Namenskonventionen

Die Bezeichnungen aller XML-Elemente und –Typen leiten sich ab vom Datenelementbezeichner der jeweiligen Partnerinformation. Jedes komplexe ENGPART-Element erhält bei seiner Definition die Erweiterung „type“.

Falls sich der Titel aus mehreren Wörtern zusammensetzt, entfallen die Leerzeichen und jedes neue Wort beginnt mit einem Großbuchstaben.

Daten-Typen von Aufzählungs-Listen (enumeration data types) erhalten die Erweiterung „…“.

Einfache Datentypen mit Längenbeschränkungen werden folgendermaßen beschrieben:

Datentyp String mit bis zu n Zeichen: String..n

Datentyp String mit einer Länge von m bis n Zeichen: String m..n

Datentyp String mit genau n Zeichen: String n

Entsprechend wird auch die Anzahl der Zeichen für die Datentypen Integer und Dezimal festgelegt.

Wird das Abstraktionsprinzip im XML-Schema verwendet, wird die Bezeichnung des Elementes durch eine weitere „type“-Erweiterung ergänzt.


Copyright: VDA

Entsprechend der ODETTE XML Work group lautet die Bezeichnung des allgemeinen Einsprungpunktes des XML-Schemas „Electronic Document Type“. Daraus wird als Instanz das ENGPART-Dokument abgeleitet.

XML-Syntax

Die ENGPART-Message verwendet den Zeichensatz UTF-8. Die XML-Syntax sieht vor, jedem Datenelement öffnende und schließende Tags zuzuordnen.

ENGPART-Abschnitte, die einen oder mehrere ENGPART-Informationsblöcke enthalten können, werden mit umschließenden Tags gegeneinander abgegrenzt.

ENGPART-Informationsblöcke mit zusammengehörenden Partnerinfor-mationen werden außerdem durch umschließende Tags zusammengefasst.

2.5 Syntax-Beispiele der ENGPART-Message

2.5.1 Beispiel (A) einer kompletten/vollständigen ENGPART-Message

(Beispiel ohne XML-Schema-Referenz)

004 00 031230145959 ISO 10646 DE 90-231-1224 Empfängerfirma 67-293-1928 Senderfirma ...

Der durch den inneren Rahmen markierte Bereich stellt den Mindestumfang an Informationen der ENGPART-Message dar. Dabei handelt es sich vor allem um administrative Daten der Kommunikationspartner.

Im Anschluss folgen alle für eine komplette/vollständige ENGPART als obligatorisch definierten Partnerinformationen sowie zur einfacheren Lesbarkeit einige optionale Partnerinformationen.

Min

de

stu

mfa

ng

an

EN

GP

AR

T-In

form

atio

nen


Copyright: VDA

Sind in einem ENGPART-Informationsblock lediglich optionale Referenz-Einzelinformationen vorgesehen (vgl. CompanySite), und diese werden nicht genutzt, brauchen auch die „Reference“-Datenelementbezeichner nicht verwendet zu werden.

… CompanySite_ID_1 Standort Eins Beispielstr. 1 Beispielstadt DE 003.1 Format_ID_1 System_ID_1 OFTP_ID_1 Contact_ID_1 Destination_ID_1 OFTP_ID_1 TCP/IP O0013000011SEND311 O0013000011SEND311 196.145.200.1 3305 CompanySite_ID_1 Format_ID_1 STEP AP 214 …


Copyright: VDA

… System_ID_1 CATIA RS 6000 Format_ID_1 Destination_ID_1 Mustermann +497031-555-55 [email protected] adr.code_muster CompanySite_ID_1

2.5.2 Syntax-Beispiele für ENGPART-Updates

Mit Hilfe eines ENGPART-Updates ist es möglich, die Partnerinformationen in der Datenbank des ENGPART-Empfängers auf unterschiedliche Weise zu modifizieren. Die jeweilige Art der Modifikation der Partnerdaten in der Datenbank des ENGPART-Empfängers ist bestimmend für die Syntax der ENGPART-Message.

Das nachfolgende Schema gliedert die möglichen Alternativen:

Funktion des

ENGPART-Updates Betroffener Informationsumfang

Einzelinformationen Informationsblöcke

Neuanlage - Beispiel B.1

Löschung Beispiel B.2a Beispiel B.2b

Editierung/Überschreiben Beispiel B.3

Das Datenelement mit dem Bezeichner „UpdateMode“ legt in der ENGPART-Message mit dem Wert 01 fest, dass es sich um ein ENGPART-Update handelt. Auch das ENGPART-Update muss die als Mindestumfang definierten Informationen enthalten.


Copyright: VDA

004 01 031111143000 ISO 10646 DE 90-231-1224 Empfängerfirma

67-293-1928 Senderfirma …

Der ENGPART-Abschnitt Sender Company Details schließt lediglich die Informationen über Name und DUNS-Number (oder äquivalenter, eindeutiger Nicht-DUNS-Identifikator) des Senders ein, es sei denn, es sind Modifikationen an den ENGPART-Informationsblöcken Company Site und Company Contact vorgesehen.

Alle Update-Informationen werden sowohl von den Tags des betroffenen ENGPART-Abschnitts umschlossen als auch von denen des ENGPART-Informationsblockes, in dem die Partnerinformationen modifiziert werden sollen. Um den Informationsblock eindeutig identifizieren zu können, muss ebenfalls dessen firmenweit eindeutiger Identifier immer enthalten sein.

Min

de

stu

mfa

ng

an

EN

GP

AR

T-In

form

atio

nen


Copyright: VDA

2.5.2.1 Beispiel (B.1) Neuanlage von Informationsblöcken (Beispiel ohne XML-Schema-Referenz)

Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden Informationsblöcke werden durch neue ergänzt, indem die eindeutigen Identifier der neuen Informationsblöcke zusammen mit allen dazugehörigen Einzelinformationen an den Empfänger der ENGPART geschickt werden.

Alle als obligatorisch definierten Einzelinformationen müssen im entsprechenden ENGPART-Abschnitt enthalten sein.


67-293-1928 Senderfirma Destination_ID_1 Mustermann +497031-555-55 [email protected] adr.code_muste CompanySite_ID_1

Die Zieladresse mit der ID „Destination_ID_1“ ist in der Partnerdatenbank des ENGPART-Empfängers noch nicht enthalten und wird dort, mit allen dazugehörigen Einzelinformationen, neu angelegt.

Up

da

te-In

form

atio

nen

Min

de

stu

mfa

ng

an

EN

GP

AR

T-In

form

atio

nen


Copyright: VDA

2.5.2.2 Beispiel (B.2.a) Löschung von Einzelinformationen (Beispiel ohne XML-Schema-Referenz)

Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden Einzelinformationen werden gelöscht, indem die eindeutigen Identifier der Informationsblöcke versandt werden, in denen die betroffenen Informationen enthalten sind.

Hinzu kommen lediglich die Datenelementbezeichner (Tags) der zu löschenden Einzelinformationen ohne die dazugehörigen Datenelemente selbst. Grundsätzlich ist keine Löschung obligatorischer Datenelemente erlaubt.



Das optionale Datenelement mit dem Datenelementbezeichner „FaxNumber“ ist in der Partnerdatenbank des Empfängers im Zieladressinformationsblock „Destination_ID_1“ vorhanden und soll dort gelöscht werden.

Up

da

te-

Info

rma

tion

en

Min

des

tum

fan

g

an

EN

GP

AR

T-In

form

atio

nen


Copyright: VDA

2.5.2.3 Beispiel (B.2.b) Löschung von Informationsblöcken (Beispiel ohne XML-Schema-Referenz)

Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden Informationsblöcke werden gelöscht, indem die Identifier der zu löschenden Informationsblöcke mit „leeren“ obligatorischen Einzelinformationen gesendet werden.


67-293-1928 Senderfirma Destination_ID_1

Der Zieladressinformationsblock mit dem Identifier „Destination_ID_1“ ist in der Partnerdatenbank des ENGPART-Empfängers vorhanden und soll dort vollständig gelöscht werden.

Min

de

stu

mfa

ng

an

EN

GP

AR

T-In

form

atio

nen

Up

da

te-

Info

rma

tion

en


Copyright: VDA

2.5.2.4 Beispiel (B.3) Editieren/Überschreiben von Einzelinformation oder Informationsblöcken (Beispiel ohne XML-Schema-Referenz)

Die in der Partnerdatenbank des ENGPART-Empfängers bestehenden Einzelinformationen oder Informationsblöcke werden editiert bzw. überschrieben, indem die eindeutigen Identifier der Informationsblöcke gesendet werden, denen die Einzelinformationen zugeordnet sind.

Hinzu kommen die neuen, editierten Einzelinformationen selbst, bestehend aus Datenelementbezeichner (Tags) und den neuen Datenelementen, die anstelle der alten eingepflegt werden.



Das Datenelement mit dem Datenelementbezeichner „PhoneNumber“ ist in der Partnerdatenbank des ENGPART-Empfängers im Zieladressinformationsblock mit dem Identifier „Destination_ID_1“ enthalten und wird durch das in der ENGPART-Message enthaltene Datenelement überschrieben.

Min

de

stu

mfa

ng

an

EN

GP

AR

T-In

form

atio

nen

Up

da

te-

Info

rma

tion

en


Copyright: VDA

2.6 Verfahren

2.6.1 Übermittlung

Der Normalfall für die Übermittlung ist die Nutzung eines ENGDAT-Paketes. In diesem Fall wird ein ENGDAT-Paket der Conformance Class 2/3 (s. ENGDAT V3.*) erzeugt, zu dem als Nutzdaten-Datei eine ENGPART-Message assoziiert ist. Zur Kennzeichnung, dass es sich bei den übermittelten Nutzdaten um ENGPART-Daten handelt, wird in der ENGDAT-Message im EFC-Segment das Datenelement Exchanged File Purpose mit dem Wert ENGPART belegt. In allen anderen Fällen muss die Vorgehensweise, wie die Informationen zu übermitteln sind, jeweils bilateral vereinbart werden. Es wird in dieser Empfehlung davon ausgegangen, dass für die Übertragung der Informationen Datenleitungen verwendet werden. Auch hier können andere Übermittlungswege vereinbart werden.

2.6.2 Erzeugung und Empfang

ENGPART- Message

Partner-Datenbank

ENGDAT-

Generator

ENGDAT-Paket

ENGDAT Message

ENGPART- Message

Erstellung eines ENGDAT-Paketes

ENGPART-

Generator Erstellung der

ENGPART-Message

Partnerinformationen

Erzeugung der ENGPART-Message bei der Senderfirma

Versand

ENGPART- Message

Partner-Datenbank

ENGPART-

Interpreter

ENGDAT-Paket

ENGDAT Message

ENGPART- Message

ENGDAT-

Interpreter Isolierung der ENGPART

Einpflegen der ENGPART- Informationen Auswertung des ENGDAT-

Paketes

Empfang

Empfang der ENGPART-Message bei der Empfängerfirma


Copyright: VDA

2.6.3 Automatische Verarbeitung

Durch die formale Struktur der ENGPART-Message können die darin enthaltenen Informationen automatisch in die proprietären EDI-Systeme des Empfängers übernommen werden. Der Ablauf der automatischen Verarbeitung beim Empfang einer ENGPART-Message hängt wesentlich davon ab, ob es sich um eine komplette/vollständige ENGPART-Message handelt oder um ein ENGPART-Update.

Bei einer kompletten/vollständigen ENGPART wird der gesamte Umfang an Informationen einer speziellen Partnerbeziehung aus der Partnerdatenbank des ENGPART-Empfängers gelöscht. Anschließend werden die in der empfangenen ENGPART-Message enthaltenen Partnerinformationen dort neu eingepflegt.

Da durch ein ENGPART-Update die Partnerinformationen auf unterschiedliche Weise modifiziert werden können, muss beim Empfang des ENGPART-Updates ausgewertet werden, um welche Art der Modifikation es sich dabei handelt. Anschließend werden der XML-Syntax entsprechend die Änderungen der Partnerinformationen in der Datenbank des ENGPART-Empfängers vorgenommen.

ENGPART-Update

Mindestumfang an Infos

ID 2 Zieladresse b

Informationsblock

Handelt es sich um ein

ENGPART-Update? Nein Ja

Informationsblock ID 2 vollständig

löschen

Identifikation der Update-

Informationen anhand der IDs

Ist der in der ENGPART ent-haltene Informationsblock auch in der Partnerdatenbank

des Empfängers vorhanden?

Identifikation des Senders

anhand seiner DUNS-Nr.

Ja

Nein

Sind im Informations-block ID 2 Einzelinformationen

enthalten?

Ja Nein

Ja

Nein

Bestehen die Einzelinformationen aus Datenelement-bezeichner (Tag)

und Datenelement?

Informationsblock

ID 2 neu anlegen

Einzelinformation löschen

Einzelinformationen im Informationsblock ID 2 in der Partnerdatenbank durch die aus der ENGPART überschreiben

Alle Informationen für diesen Partner neu einpflegen; Vorhandene

löschen

Zieladresse a ID 1

Partnerdatenbank des

Empfängers Informationsblock

- Zieladressen-

Einzelinfo zu Zieladr. a

Zieladresse b ID 2

Einzelinfo zu Zieladr. b

Zieladresse b ID 2


Zieladresse b ID 2


Zieladresse b ID 2


Bsp. A

Bsp. B.1

Bsp. B.2.a

Bsp. B.2.b

Bsp. B.3


Copyright: VDA

2.6.4 Manuelle Verarbeitung

Die formale Struktur der ENGPART-Message sowie die einfache Lesbarkeit durch den Einsatz von XML erlauben neben einer automatisierten, maschinellen Verarbeitung eine manuelle Erstellung und Auswertung.

Hinzu kommt die Unterstützung des XML-Formates durch XML-fähige Standard-Browser. Damit ist es möglich, sowohl die XML-codierte ENGPART-Message korrekt abzubilden als auch unter Verwendung von Stylesheets Informationen selektiv aus einer ENGPART-Message in HTML darzustellen.

ENGPART-

Message

Stylesheet HTML-Darstellung im Standard-Browser

Verknüpfung über URL

Manuelle Auswertung einer ENGPART-Message


Copyright: VDA

Anhang A Inhalt der Partnerdaten

VDA ENGPART Version 4 Standard

EN

GP

AR

T-A

bsch

nit

te

Info

rmati

on

sb

löck

e/

Un

tera

bs

ch

nit

te

Date

nele

men

t-N

um

mer

Datenelement-bezeichnung

XML-Tag (Datenelement-

bezeichner) Sta

tus

Fo

rmat

Datenelement- beschreibung

Beispiel- daten-

element

Mess

ag

e Id

en

tifi

er

(Sta

tus d

er

Au

sta

us

ch

date

n)

1 ENGPART-Version m x..5 004.1

2 Update-Modus m n2 00: vollständige ENGPART; 01: ENGPART-Update

00

3 Datum/Zeit m n12 Format 'JJMMTThhmmss', CET bzw. CEST

031212135534

4 Zeichensatz m an..25 ISO 10646, alternativ ISO 6947/2-1983 od. ISO-2022

ISO 10646

5 Sprachversion m a2 Laut ISO 639: 2002 DE

Receiv

er

Co

mp

an

y D

eta

ils

6 Eindeutiger Empfänger-Firmen-Schlüssel

m x..5

Identifikator der Firma oder Organisation die das System verwaltet oder wartet aus dem der folgende Identifikator erzeugt wurde

16

7 Eindeutige Empfängerfirmen-ID

< CompanyInternalIDNumber >

m x..50

Dun&Bradstreet DUNS-Nummer (oder äquivalenter, eindeutiger Nicht-DUNS-Identifikator) der ENGPART-Empfängerfirma

90-231-1224

8 Firmenname Empfänger

m x..100 Name der Empfängerfirma der ENGPART

Empfänger-firma


Copyright: VDA

9 Eindeutiger Empfänger-Firmen-Schlüssel

< CompanyInternalIDCode >

m x..5

Identifikator der Firma oder Organisation die das System verwaltet oder wartet aus dem der folgende Identifikator erzeugt wurde

16

10 Weltweit eindeutige Firmen-ID (DUNS-Nummer)

< CompanyInternalIDNumber >

m x..50

Dun&Bradstreet DUNS-Nummer (oder äquivalenter, eindeutiger Nicht-DUNS-Identifikator) der ENGPART-Sender- firma

67-293-1928

11 Firmenname m x..100 Name der Senderfirma der ENGPART

Senderfirma

ENGPART-MINDESTUMFANG

Sen

de

r C

om

pan

y D

eti

ls

(In

form

ati

on

üb

er

Sen

de

r)

Co

mp

an

y S

ite

1 Firmenweit eindeutige Standort-ID

m x..100

Beliebige Kennung zur Identifikation eines Standortes, ggf. Standort-DUNS

CompanySite_ID_1

2 Name Standort m x..100 Standort Eins

3 Straße m x..50 Straßenname Beispielstr.

4 Nummer k x..25 Hausnummer 1

5 Ort m a..50 Beispielstadt

6 Bundesland / State k x..50 Hessen

7 Ländercode m a2 Codierte Form laut ISO 3166-1

DE

8 Postleitzahl (Ort) k x..25 99999

9 Kommentar k x..50 Adresszusätze Gewerbepark

10 Funktion k x..35 Funktion des ENGPART-Senders

Sender

11 ENGDAT-Versionen m x..5 Angabe der unterstützten ENGDAT-Versionen

003.1

12 Kompression k x..25 mehrere möglich gzip

13 Verschlüsselung k x..50 mehrere möglich none

k

Refe

re

nce

11 Referenz zu Austauschformat

k x..100 Format_ID_1

12 Referenz zu Systeme

k x..100 System_ID_1


Copyright: VDA

13 Referenz zu Kommunikations- medium OFTP

k x..100 OFTP_ID_1

14 Referenz zu Kommunikations- medium FTP

k x..100 FTP_ID_1

15 Referenz zu Kommunikations- medium Offline

k x..100 Offline_ID_1

Co

mp

an

y C

on

tact

1 Firmenweit eindeutige Ansprechpartner-ID

m x..100 Beliebige Kennung zur Identifikation eines Ansprechpartners

Contact_ID_1

Refe

rence

m

2 Referenz zu Zieladresse

m x..100 Destination_ID_1

3 Referenz zu Werk/Standort

k x..100 CompanySite_ID_1

Sen

de

r C

om

mu

nic

ati

on

Syste

m (

Info

rmati

on

üb

er

Ko

mm

un

ikati

on

)

Co

mm

un

icati

on

Syste

m O

FT

P

1 Firmenweit eindeutige OFTP-System-ID

m x..100 Beliebige Kennung zur Identifikation eines OFTP-Systems

OFTP_ID_1

2 Verbindungsart

m x..6 DSS1 oder TCP/IP TCP/IP

3 ODETTE-Kennung: SSIDCODE

m x..25 O0013000011 SEND311

4 ODETTE-Kennung: SFIDDEST

m x..25 O0013000011 SEND311

5 DFÜ-Rufnummer (m) n..25 alternativ zu 6 07303155511

6 OFTP-Server-IP-Adresse (numerisch)

(m) x..15 alternativ zu 5

196.145.200.1

7 IP - Port Nummer k n..5 Default-Port 3305 wenn keiner angegeben

1976

Refe

ren

ce

m


m x..100 CompanySite_ID_1

Co

mm

un

icati

on

Syste

m F

TP

1 Firmenweit eindeutige FTP-System-ID

m x..100 Beliebige Kennung zur Identifikation eines FTP-Systems

FTP_ID_1

2 FTP-Server-IP-Adresse (numerisch)

m x..15 53.110.324.10

3 FTP-Server-IP-Adresse (Hostname)

k x..100 OFTPANET


Copyright: VDA

4 FTP-User-ID m x..50 xxx

5 FTP-User- Passwort

m x..50 xxx

6 Daten-Directory m x..1024 /mailbox R

efe

ren

ce

m



Co

mm

un

icati

on

Syste

m

Off

lin

e

1 Firmenweit eindeutige Offlinemedium-ID

m x..100 Beliebige Kennung zur Identifikation eines Offline-Mediums

Offline_ID_1

2 Offline-Medium m x..50 CDROM

Refe

ren

ce

m



Exch

an

ge F

ile

Fo

rmat

(In

form

ati

on

üb

er

Au

sta

usch

form

at)

File F

orm

at

1 Firmenweit eindeutige Austauschformat-ID

m x..100 Beliebige Kennung zur Identifikation eines Austauschformates

Format_ID_1

2 Austauschformat m x..25 Freier Text STEP AP 214

3 Version Austauschformat

k x..25 IS (2003) TC2

4 Austauschformat k an3 Codierte Form laut ODDC 77

STP

5 Zeichensatz k x..25 Freier Text US ASCII 7BIT

6 Zeichensatz codiert

k x..25 Codierte Form laut ODDC 78

646

7 Kompression k x..25 none

Exch

an

ge F

ile

Gen

era

tin

g

Syste

m

(In

form

ati

on

üb

er

Syste

me)

Gen

era

tin

g S

yste

m

1 Firmenweit eindeutige System-ID

m x..100 Beliebige Kennung zur Identifikation eines Systems

System_ID_1

2 Eingesetztes System

m x..25 Freier Text CATIA RS 6000


Copyright: VDA

3 Version System

k x..25 V5R17

Refe

ren

ce

m


m x..100 Format_ID_1

Sen

de

r D

esti

nati

on

Ad

dre

ss

(Zie

lad

ress

en

)

Desti

nati

on

Ad

dre

ss

1 Firmenweit eindeutige Zieladress-ID

m x..100 Beliebige Kennung zur Identifikation einer Zieladresse

Destination _ID_1

2 Nachname m x..50 Mustermann

3 Vorname k x..50 Manfred

4 Abteilung k x..100 Abteilung 1

5 Telefonnummer m x..50 +497031-555-55

6 Handynummer k x..50 +49172-555-66

7 Faxnummer k x..50 +497031-555-56

8 Electronic-Mail- Adresse

m x..100

M.Mustermann@ senderfirma.com

9 Adresscode m x..50 rout.code_ muster

Refe

ren

ce

m


m x..100 Company Site_ID_1


k x..100 Format_ID_1

12 Referenz zu System

k x..100 System_ID_1

13 Referenz zu Kommunikations- medium OFTP

k x..100 OFTP_ID_1

14 Referenz zu Kommunikations- medium FTP

k x..100 FTP_ID_1

15 Referenz zu Kommunikations- medium Offline

k x..100 Offline_ID_1

Format Notation:


Copyright: VDA

Struktur der Referenzen einer ENGPART-Message

an8 alphanumerisches Format (Buchstaben plus Zahlen), exakt 8 Zeichen

a..30 alphabetisches Format, bis zu 30 Buchstaben

n..10 numerisches Format, bis zu 10 Einzelzahlen

x..100 bis zu 100 beliebige Zeichen (Buchstaben plus Zahlen plus interpunktion plus multibyte Zeichen wie Umlaute etc.)


Copyright: VDA

Anhang B XML-Schema (XSD) einer vollständigen ENGPART-Message


Copyright: VDA


Copyright: VDA

ISO 3166-1 alpha 2 (2000)


Copyright: VDA


Copyright: VDA

ISO 639-1 alpha 2 (2002)


Copyright: VDA

datenfernübertragung von cad/cam daten€¦ · vereinbarungen zum cad/cam datenaustausch vda 4950...

Documents