Was ist ENGDAT?
ENGDAT hat hier eigentlich gar nicht so richtig was zu suchen. Es ist weder ein Datenformat noch ein Nachrichtenstandard im engeren Sinne. Eigentlich müssten wir hierfür eine eigene Rubrik aufmachen, das wäre dann doch etwas übertrieben. Also, sei’s drum.
ENGDAT steht für Engineering Data Message und ist ein definierter Workflow
zum Austausch von technischen Dokumenten, vornehmlich in der Automotive-
Branche. Neben dem Austausch von technischen Dokumenten können auch
Kontaktinformationen ausgetauscht werden – hierbei handelt es sich um sogenannte ENGPART-Mitteilungen, die in einer ENGDAT-Nachricht übermittelt werden.
Die aktuelle Spezifikation von ENGDAT ist V3.1, die aktuelle Version von ENGPART ist V4.1. Tiefergehende Informationen über ENGDAT finden Sie beim Verband der Automobilindustrie VDA und bei der Strategic Automotive product data Standards Industry Group, kurz SASIG. Zur Datenübertragung hat sich das OFTP-Protokoll als Standard durchgesetzt.
Gerade in der Automotive-Branche (also alles rund um’s Auto, Zubehör, Ersatzteile, Transport usw.) werden jede Menge CAD-Dateien ausgetauscht. CAD steht für Computer-Aided Design, also für die Konstruktion von Produkten, Bauteilen u. ä. am Computer. Nun sind in solchen CAD-Dateien rein technische Informationen enthalten, nicht aber Platz für Organisatorisches, wie Ansprechpartner, involvierte Abteilungen u.s.w. Solche Daten – man nennt sie auch Metadaten – müssen also zusätzlich zu den reinen CAD-Dateien übertragen werden, wobei sichergestellt werden soll, dass auch die richtigen CAD- und Zusatzdateien zusammen bleiben.
Die Metadaten, die zusammen mit den Nutzdaten zur ENGDAT-Nachricht gehören, enthalten z.B. Informationen über Sender und Empfänger oder auch den Zweck der Daten.
Allgemeine Kontaktinformationen, die Partnerstammdaten, werden über ENGPART-Nachrichten ausgetauscht. Außerdem gehört zur Zusammenarbeit in diesem Bereich auch, dass man beim Partner (Lieferanten/Kunden) bestimmte Dokumente anfragt oder umgekehrt bestätigt, dass man sie erhalten hat. Solche definierten Abläufe nennt man Workflow.
Dass zur Übertragung der Daten OFTP benutzt wird, ist nicht offiziell vorgegeben. Allerdings kommt das OFTP-Protokoll, genau wie ENGDAT, aus der Automotive-Branche und hat sich dort als Standard-Übertragungsweg etabliert. Bis vor relativ kurzer Zeit wurde noch das OFTP über ISDN-Leitungen genutzt. Inzwischen stellen die ersten Unternehmen auf das TCP/IP- und TLS-basierte OFTP2 um. Genaueres hierzu im Artikel zum Übertragungsprotokoll OFTP.
Die technische Seite?
Die Übertragung per OFTP hatten wir schon. Mehr ist dazu nicht zu sagen.
Aber wie wird zum Beispiel kenntlich gemacht, welche Dateien einer Übertragung zusammengehören? Immerhin könnten ja auch in einer einzigen Verbindung mehrere ENGDAT-Nachrichten daherkommen.
Diese Problem wird durch das Dateimuster gelöst:
Jede Datei bekommt bei der Übertragung einen logischen Dateinamen. Und der ist großenteils für alle Dateien einer Nachricht identisch, bis auf einen fortlaufenden Zähler.
Konkret sieht das so aus, unterschieden nach ENGDAT Version 2 und 3:
- ENGDAT V2: „ENG“ oder „EN2“ + Zeitstempel im Format „yyMMddHHmmss“ + Route (alias Adresscode, fünf Zeichen) + Anzahl der technischen Dokumente (drei Zeichen) + Zähler der aktuellen Datei (drei Zeichen)
Ein Beispiel für die erste von vier Dateien am 21.02.2013 12:30 mittags wäre also: ENG130221123000ROUTE004002. Alles in allem 26 Zeichen. - ENGDAT V3: „ENG“ oder „EN3“ + Zeitstempel im Format „yDDDHHmmss“ + Route (alias Adresscode, fünf Zeichen) + Anzahl der technischen Dokumente (vier Zeichen) + Zähler der aktuellen Datei (vier Zeichen)
Dieselbe Datei in V3 hieße also: ENG3052123000ROUTE00040002. Auch hier haben wir 26 Zeichen.
Das Datumsformat ist recht seltsam. Es wird nur die letzte Ziffer der Jahreszahl (3 von 2013) genutzt und der Tag im Jahr komplett durchgezählt, also von 001 bis 365 (bzw. 366). Aber so ist das nun mal definiert.
In den beiden Beispielen würden also jeweils 4 zusammengehörige Dateien versendet, deren logischer Dateiname sich nur im fortlaufenden Zähler ganz hinten unterscheidet. Da auch die Gesamtzahl der Dateien mit drin steht, merkt man gleich, wenn eine Datei fehlt, und kann diese nachfordern.
Als nächstes müssen wir über die Datenformate sprechen.
Die CAD-Daten selbst (die Nutzdaten) befinden sich in einem der CAD-Formate, die so von den verschiedenen Programmen genutzt werden. Natürlich müssen sich die beteiligten Parteien auf ein Format einigen.
Aber wie sehen Metadaten und ENGPART-Nachrichten aus?
Früher wurde für diese Daten EDIfact genutzt, in den aktuellen Versionen (ENGDAT V3 und ENGPART V4) kommt XML zum Einsatz. Näher brauchen wir nicht darauf einzugehen, damit dürfen Sie sich herumschlagen, wenn Sie tatsächlich auch ENGDAT nutzen wollen. Wobei diese „low level“-Dinge eigentlich von der genutzten Software erledigt werden sollten, ohne dass Sie sich direkt damit beschäftigen.
Und dann noch ein paar Takte zu den definierten Nachrichtentypen. Generell wird eine V3-Engdat-Nachricht in „Conformance Classes“ (CC) unterschieden:
- CC1: Anfrage von Dokumenten (wird im Aufbau nochmals in a und b unterschieden)
- CC2: Senden von Dokumenten ohne zusätzliche Informationen über enthaltene Dateien
- CC3: Senden von Dokumenten mit zusätzlichen Informationen über enthaltene Dateien
- CC4: Bestätigung einer eingehenden Nachricht (wird im Aufbau nochmals in a und b unterschieden)
- CC5: gibt es nicht als Nachricht; man spricht von einer Conformance Class 5, wenn die eingesetzte Software CC1 bis CC4 unterstützt.
Bleibt noch zu sagen:
Eigentlich sollten ja bei EDI die Daten vollautomatisch zwischen den IT-Systemen der beteiligten Partner ausgetauscht werden. Ohne Eingriff des Menschen. Im Falle ENGDAT ist diese reine Lehre nicht durchzuhalten. Hier muss der Versand interaktiv von einem Mitarbeiter erledigt werden, der die zu den Nutzdaten gehörigen Metadaten bestimmt bzw. eingibt und sich auch um die Pflege der Partnerstammdaten kümmert. Zwar läuft der Austausch der Daten weitgehend automatisch, doch ein wenig Handarbeit muss einfach sein. Wenn Sie also bereits jetzt ENGDAT betreiben oder die Wahrscheinlichkeit besteht, dass dieses Thema in Zukunft ansteht, dann achten Sie bei der Auswahl ihrer EDI-Software darauf, dass sie auch eine vernünftige ENGDAT-Integration bietet.