Ready for VDI-2770?

The VDI-2770 guideline describes an exchange format that enables efficient merging of extensive documentation from different sources. The underlying concept of a container format and a metadata model forms the basis for a functioning digital information exchange. The full name of the guideline is VDI-2770 - Sheet 1: “Operation of Process Plants — Minimum Requirements for Digital Manufacturer Information for the Process Industry — Basics.”

Process industry

The guideline primarily addresses companies in the process industry. Here are some industry-specific challenges to which the guideline provides answers. When complex plants are renewed, expanded, or modified, the product information from numerous different pieces of equipment must be brought together.

The correct information must be available throughout the entire product life cycle. If, for example, parts of a system are replaced, the associated documentation must also be updated. Legal requirements and the resulting audits to check safety can make it necessary for even the material certificate of a single screw to be verified. The required document management can keep entire project teams busy for days.

The concept of the VDI-2770 guideline makes it possible to overcome these challenges by assigning and classifying documents in a clear, machine-readable manner.

Suppliers to the process industry

Suppliers to the process industry must expect that in the future, the documentation for the products supplied will increasingly be required as a VDI-2770 package. However, this circumstance is not only a challenge but also an opportunity: If you supply different companies, it is easier to stick to one standard than to work through numerous individual catalogs of requirements.

Several aspects come into play when compiling a valid VDI-2770 package. These aspects are briefly outlined below.

(1) Document container

We will illustrate the structure using a single document in order to make the concept easier to understand. In this example, an operating manual. This finds its place as a PDF/A document together with the original file (“Free”) and an XML metadata file in a document container. This ZIP container bundles all the information for a document, in this case, the operating instructions.

(2) PDF/A file format

All documents must be in PDF/A format. This file format ensures that the documents can be accessed and displayed correctly in the long term. The guideline only permits PDF/A formats in which the textual content is electronically accessible, i.e., searchable (e.g. PDF/A-2a and PDF/A-3a). There is an exception for testimonials, certificates, and attestations (document category 02-04). Since these documents often contain only scanned image information, additional PDF/A variants are permitted. It is up to the package creators to supply the original files (cf. “Free” in the graphic).

(3) All metadata per document in one XML file

The metadata must be supplied in an XML file for each document. A critical metadata is the document category. The documents contained must be assigned to one of the 12 specified document categories on the basis of their document type and intended use. Classification according to DIN EN 63551 is also possible (DCC - Document Kind Category Code).

Classifying documents according to their intended use makes it easier to find the contents. After a glance at the document category, it is clear which information is contained in which document. The categories are derived according to the typical information needs of relevant work activities in the product lifecycle.

[Quelle: VDI 2770, S.12]

Administrative metadata is specified per document version, e.g., version identifier, release status, and language.[Source: VDI 2770, p.25f]

In addition to the specification of the document category, the assignment of documents to objects is a central metadata. At least one object reference must be established for each object. For details, see point (5), “Product reference.”

(4) Documentation container for bundling

For valid compliance with the standard, a document container must be created for each document. All document containers are then combined into one object, together with a main document, in a documentation container. This main document serves as a kind of table of contents in the form of an XML file and a PDF/A document.

If a product consists of several parts, the product structure is mapped in nested documentation containers. Zipping the files facilitates the transfer of the collected documents and metadata files. It is also possible to check the integrity of the documentation with the help of a checksum. This means that it is always possible to see whether a package has changed. The same checksum means “no change” or “same content.”

(5) Product reference

In order for information to be retrievable in a targeted manner, each document needs a reference to the product. All documents relating to a product or a product component (both “object” according to the guideline) must also be grouped in a documentation container and assigned to the product.

When a product consists of several components, the corresponding documentation container also contains the same structure and corresponding subpackages (subordinate documentation containers). The analogy in the structure makes it possible to transfer changes to the product directly to the documentation. If individual parts of the product are exchanged or changed, the corresponding documentation containers can also be exchanged or updated.

(6) Main document

Each package must include a main document as a table of contents in the form of a PDF/A document and an XML file. The respective sub-packages are listed in these main documents. A special feature of main documents is that they may only be assigned to exactly one object. On the one hand, the main document is available as a human-readable PDF/A (cf. example in the graphic below). On the other hand, the same information is to be stored at the same level in the machine-readable XML file.

On the one hand, the main document is available as a PDF/A that is easily readable by humans (cf. example in the graphic below); on the other hand, the same information is to be stored at the same level in the machine-readable XML file.

Not everything is regulated

The content, change management, and completeness and accuracy of the documents themselves are not addressed by the guidelines.

The guideline provides that each document is assigned to a document category according to its content, type, and importance.

In practice, documents often contain information from several document categories, e.g., operating instructions contain technical data (02-01 Technical specification), information on assembly or commissioning (03-01 Assembly, disassembly), and troubleshooting (03-05 Maintenance).

There are two possible solutions: You can either decompose the source document or create documents for one document category at a time. Or you can use the option described in the guideline to assign several document categories to one document in exceptional cases.

The data model contains several ways for the object relationship. Generally, a distinction is made between object-type references and references to individual objects. An object type reference can, for example, be specified via an order number, a product number, or an EAN (European Article Number). The value always refers to a series of objects.

When referring to individual objects, the documents are assigned exactly to one real object: Serial numbers or IDs or URIs corresponding to DIN SPEC 91406 specify such instance-based product references. An object can also be identified by several IDs, e.g., via the serial number of the manufacturer and the equipment ID of the plant operator. At least one of the IDs must be found directly on the product, ideally on the nameplate or in its immediate vicinity.

A restriction applies to the main documents and, thus, also to all object packages (or documentation containers): They may only apply to one individual object at a time. If you deliver 500 products from a series to a company, 500 VDI-2770 packages with identical documents must also be delivered.

The effort involved in creating VDI-2770-compliant documentation should not be underestimated. Especially when it involves a large number of projects with a high volume of data.

The plusmeta Automate, our “headless” variant, is a good choice in these cases. The information and documents are transferred to plusmeta via an API and processed directly in the application server.

The generation and delivery of the corresponding packages are fully automated and do not require a user interface. This means that package generation can be scaled effectively. The only prerequisite is a clear set of metadata that enables precise assignment to the individual documents.

With plusmeta, of course! Our self-developed AI supports you in finding the appropriate document categories and establishing clear product references for the documents. The built-in validation ensures that all required data is available.

Thus, plusmeta generates standard-compliant packages with the appropriate structure, the required metadata, and overview documents within seconds.

You can also create other standard formats for digital data exchange, such as iiRDS, with plusmeta in no time at all.