What is ENGDAT?
Strictly speaking, ENGDAT doesn’t really belong on our list. It’s neither a data format, nor a messaging standard in the narrow sense of the term. We really ought to create a new category for it – though that would be overdoing things slightly. But anyway.
ENGDAT stands for Engineering Data Message, and is a defined workflow for exchanging technical documents, primarily in the automotive industry. In addition to technical documents, it can also be used to exchange contact information, which is done by means of ENGPART messages that are transferred within an ENGDAT message. The latest specification of ENGDAT is V3.1, while the current version of ENGPART is V4.1. You can obtain more detailed information about ENGDAT from the VDA (the German Association of the Automotive Industry) and from the Strategic Automotive product data Standards Industry Group, or SASIG for short. The OFTP protocol has emerged as the standard means of data transfer.
The automotive sector in particular (i.e. the branch of industry involved in cars, accessories, spare parts, transportation and so on) exchanges enormous quantities of CAD files. CAD stands for Computer-Aided Design, which refers to digital techniques used to design products, components, and so on. These CAD files contain technical information, but they have no room for organisational information, such as points of contact, relevant departments, and so on. Data of this kind – which are also known as metadata – therefore need to be transmitted alongside the pure CAD files, and in the process, we need to make sure that the right CAD files are kept together with the right extra data. These metadata form part of the ENGDAT message alongside the application data, and might contain information about the sender and the recipient, or about the purpose of the data.
General contact information – the partner master data – is exchanged by means of ENGPART messages. In addition, cooperation in the automotive sector means that businesses need to request certain documents from their partners (suppliers/customers), or to confirm receipt of such documents. These defined processes are known as workflows.
There is no official requirement that OFTP should be used for transferring data; however, the OFTP protocol – like ENGDAT itself – originates from the automotive industry, where it has developed into a standard transfer path. Until relatively recently, OFTP was still used over ISDN lines, but companies are now beginning to switch to the TCP/IP- and TLS-based OFTP2. You can find more information about this in the section on the OFTP transfer protocol.
The technical side
We have already discussed transfers via OFTP. There isn’t anything to add to that. But how can we indicate which files form part of a particular transfer (for example)? After all, we could easily send multiple ENGDAT messages in a single connection. This problem is solved using file templates:
During transfer, each file is assigned a logical file name. And this is generally identical for all the files within a single message, aside from a sequential counter. Here’s what that looks like in practice for ENGDAT versions 2 and 3:
- ENGDAT V2: “ENG” or “EN2” + time stamp in “yyMMddHHmmss” format + route (aka address code, five characters long) + number of technical documents (three characters) + counter for the current file (three characters). For example, the second of four files sent at 12.30 p.m. on 21/02/2013 would be:
ENG130221123000ROUTE004002
That comes to 26 characters in total.
- ENGDAT V3: ”ENG” or “EN3” + time stamp in “yDDDHHmmss” format + route (aka address code, five characters long) + number of technical documents (four characters) + counter for the current file. The same thing in version 3 would be:
ENG3052123000ROUTE00040002
Once again, it comes to 26 characters. The date format here is particularly odd. Only the last digit of the year (the 3 from 2013) is used, while the date is counted as the nth day in the year, from 001 to 365 (or 366). But that’s just the way it’s been defined.
In each of these examples, we are sending 4 associated files whose logical file names differ only in terms of the sequential counter that appears at the end of the file name. Because the total number of files is included in the name, we can easily spot if a file is missing and request it from our partner.
Next, let’s talk about the data formats. The CAD data themselves (the application data) are held in one of the CAD formats used by the various different programs. Of course, the parties involved will need to agree on a single format.
But what do metadata and ENGPART messages look like? Previously, EDIFACT was used for these data, but in the current versions (ENGDAT V3 and ENGPART V4) XML comes into play. We don’t need to go into any more detail here – you can play around with it yourself if you actually intend to use ENGDAT. That said, these low-level things ought to be handled by the software you are using, so you shouldn’t have to engage with them directly yourself.
And now let’s take a quick look at the defined message types. Generally speaking, a V3
ENGDAT message can come in three different “conformance classes” (CCs):
- CC1: Request for documents (this is further subdivided into ‘a’ and ‘b’ in its structure).
- CC2: Transfer of documents with no additional information about the files included.
- CC3: Transfer of documents with additional information about the files included.
- CC4: Confirmation of an incoming message (this is further subdivided into ‘a’ and ‘b’ in its structure).
- CC5: This doesn’t exist as a message; we only refer to conformance class 5 when the software we are using supports CC1 to CC4.
One other thing: Strictly speaking, in EDI, the data should be exchanged fully automatically between the IT systems of the partners involved. In other words, there should be no human intervention.
However, this theory falls by the wayside in ENGDAT, since transfers need to be made interactively by an employee whose job is to input or define the relevant metadata to go with the application data, and to maintain the partner master data. The data interchange itself takes place largely automatically, but a little manual work is a necessary part of the process. So if you already operate ENGDAT or are likely to have to deal with this topic in future, then you should make sure that the EDI software you choose offers you a reasonable level of ENGDAT integration.