In the age of topics, user-oriented information, metadata, Industry 4.0, digital twin and other meaningful keywords, "PDF" or "documentation" almost seem like an artifact from a time shortly after the extinction of dinosaurs. But, unlike the dinosaurs, documentation in the sense of "document" is not extinct; instead, it shares an existence with the above-mentioned phenomena of our modern times.
In order to smoothly transition documentation into digitalised daily life, the VDI, and in particular Process Automation, has dedicated itself to the development of VDI 2770.
But what exactly is behind this Standard and what is its goal?
And is the preposition used in this blog's title even correct? "Versus" means "as opposed to" – but are these two Standards really so far apart?
Area of application for VDI 2770: What is it about or "About this Book"
"Operation of process engineering plants – Minimum requirements for digital manufacturer information in the process industry; basic principles": This is currently the full title of the Standard.
What exactly does the VDI associate with "digital manufacturer information"? First and foremost, the following:
- Classification of documents
- Structure of the documentation for simple and compound objects
- Metadata record per document
- File formats
And here, too, the choice of words is striking: "documents", "documentation", and "document". The focus of VDI 2770 is obviously on documents and "traditional" documentation.
In order to classify documents uniformly, VDI 2770 specifies a formula. A distinction is made between "Groups" and "Categories", whereby categories are assigned to different groups. The groups include:
- Technical condition
- Activity-related documents
- Contract documents
Examples of categories are:
- Technical specification (within the group "Technical condition")
- Components (within the group "Technical condition")
- Operation (within the group "Activity-related documents")
For example, if the document is a parts list, it would be marked in the "Technical condition" group with the "Components" category, contained therein.
An operating manual would have the "Operation" entry in the higher-level "Activity-related documents" group.
It is – and remains – a PDF
The first step in applying VDI 2770 was quickly completed: the document (example: operating manual for screw conveyors) must be available as a PDF in Specification A (PDF/A → Format for long-term archiving). Further distinctions from "A" are also made in the Standard.
The thing with the metadata – also no compromise with VDI 2770
In addition to the document (we will stay with the example of the screw conveyor operating manual), an XML file must be created in which the metadata of the document is logged.
VDI 2770 also specifies a set for the document-related metadata. Examples of this are:
- Document language (e.g. "German")
- Document title (e.g. "Screw Conveyor Operating Instructions")
- Document status (e.g. "Customer review")
- Document unique ID (e.g. "4711")
- Document version (e.g. "1.3")
Which metadata are appropriate for this Standard have not been newly devised, but are based (i.e. have been modified or reduced) on the information model of the DIN EN 82045-2 Standard.
The whole thing beautifully packaged: wrapped with a red ribbon
Once the Documentation Architect has gathered everything together (PDF of the document and metadata file), he or she packs both together into one file and calls the generated "Document Container".
This may be enough for a coffee machine or an electric fan – but not for a system that the VDI normally deals with: So the Documentation Architect packs not just one, but as many document containers as are required for the documentation scope of the system; this can result in a considerable number. In order not to lose sight of the overview, all "small" document containers are then packed into one single "large" container, which is aptly named a "Documentation Container".
Speaking of overviews: At this point, you might lose track of the "small" containers contained in the "big" container, including their contents. For this reason, you should also pack into the big container:
- a PDF that indicates the content of the big container, in a readable form (you could compare this to a ToC or a BOM)
- a metadata file of this "parts list" (i.e. the BOM)
In the metadata file of the "parts list", each metadata file contained in the Document Containers is referenced by the Unique Document ID contained therein.
One Machine – many Suppliers – lots of Documentation: a Problem?
No, on the contrary. If, for example, several manufacturers were to pack their document containers, they would "only" have to load them into the Document Container and expand the "parts list" to include their scope of delivery. The customer thus receives a container – populated by all suppliers.
What about iiRDS?
And what is there to mention about iiRDS? Quite a bit. Therefore, there is a separate blog post here all about this Standard. But in a nutshell: The iiRDS also specifies metadata, supports it with structuring templates and can be used for delivery.
The main difference between iiRDS and VDI 2770 is that the iiRDS is primarily concerned with the structuring and meta-dating of information units (i.e. "Topics"). Containing a certain amount of intelligence, information designed in accordance with iiRDS can be imported and displayed in various Content Delivery Portals, for example.
Combining both standards
To sum up, it could be said that both Standards each have their own areas of coverage. But both standards also overlap, which requires sound advice, in order to analyse.
Back to the question of whether we're really dealing with conflicting standards. My opinion is that one cannot attest that each approach has an aversion to the other. A more fitting heading would therefore be: "On the way to intelligent information with VDI 2770 and iiRDS".