A Logical Step

At the 2017 annual conference in Stuttgart, tekom presented the previous version “Request for Comments (RfC)” of its new standard "intelligent information Request and Delivery Standard", iiRDS for short, to the interested public. The standard was developed by the committed members of the "Information 4.0" working group on a voluntary basis and was implemented as an open source project. Thereby, the professional association sets a strong impulse in the direction of standardization in the Industry 4.0 environment.

The interactive stand-alone solution

Everywhere one reads and hears that devices and machines now report to the user autonomously, for example when maintenance work is due. This way, modern coffee machines detect early on whether there is a risk of calcification and show a message on the display. High-quality devices even support the user with specific instructions in order to carry out the necessary steps. So far, so good. But every coffee machine manufacturer realizes this interactivity according to its own ideas: The embedding of user information into the user interface is programmed manually and is ideally even linked to the structured information modules from the content management system of the technical editorial department. But this merging would certainly be much more efficient if the components of the controller and user information would automatically find themselves without programming effort.

The break in the communication chain

Let's take another example and imagine a modern machine tool: centric operating terminals with touch screen are already used for interactive communication with the device nowadays. By installing sensors and the associated evaluation logic, critical machine states lead to the output of messages. They ask the user to check a specific issue or draw his attention to upcoming maintenance work.

If the user wishes to carry out the specific procedure, he is referred to a procedure in the printed instructions for use. This is a break in the communication chain because in this case, the machine control system has no data link with the corresponding contents of the instructions for use. In case of doubt, the user has to organize the corresponding instructions individually. This costs time and the company money.

Even if manufacturers manage to display the user information on the operating terminal and link it to the machine control in a context-sensitive manner – it remains an individual procedure, restricted to a specific model or manufacturer. In this case, too, automated merging would have significant potential for improvement.

The plant operator's nightmare

Third: The operator of a large industrial plant, for example a refinery, uses a wide variety of products on its premises and in its units. The engineer responsible for maintenance is entrusted with the task of planning and organizing the demand-oriented deployment of his maintenance personnel. In order to succeed, he has to compile and view the technical documentation of all system components. In this way, he is able to identify the associated maintenance work and intervals.

The information is collected manually and transferred to the database of a maintenance management system (MMS), for example. This means that shift planning and the generation of maintenance orders is carried out on the basis of the data entered. Here it is above all the quantity of documents and the lack of standardization of the contents of operating and assembly instructions, data sheets or even technical documents. Collecting and viewing the content is an immense amount of time. In addition, changes to the individual source documents must also be tracked and taken into account. Plant operators currently have a great need for action and are pushing for optimization through standardization and automation with the goal that manufacturer information can be exchanged and evaluated digitally. These requirements are currently formulated in the new VDI Guideline 2770, which is to be published this year.

The need for action

Fully automatic coffee machine, machine tool and refinery - the examples describe the current situation from the user's perspective. But what about the opposite side, the technical communicators, who create user information and instructions for use? Due to the widespread use of content management systems in the offices, user information is nowadays created in a modular form as information modules or topics. Structures and metadata can be used to compile and publish user information on any information product.

However, a comprehensive model that generically describes the basic architecture of user information on a semantic level is still missing. Every company, every corporation, or every industry has its own concepts for content structures, information modules, metadata and publications. In addition, there are numerous content management systems from various manufacturers and DITA-based tool environments. These environments in turn require specific metadata to aggregate, identify, or publish content.

From a higher perspective, there is now a vast variety of procedures for creating user information in the field of digital technical documentation, which has led to an extremely heterogeneous information landscape. Looking into the future of Industry 4.0 and the scenarios discussed here, these are bad conditions. Just as systems from different manufacturers can only communicate with each other if standardized protocols are used, the same applies to the associated user information. This is exactly what iiRDS is supposed to do.

The digital twin

The scenario of Industry 4.0 assumes that every physical object in the real world is represented identically in the information world by reflection. This representation of the real object in the information world is completely described by metadata and referred to as "digital twin" (Fig. 01).

Figure 1: Model of the digital twin. Source: Roland Heidel

In thought and conceptual terms, the real object and its digital twin form the so-called "Industry 4.0 component". In technical jargon, they are referred to as "asset" and "administration shell" (Fig. 02).

Figure 2: The Industrie 4.0 component, consisting of asset and administration shell. Source: Roland Heidel

The metadata of the administration shell contains all information about the real object, including its properties, states and dependencies. What could be more obvious than to add the metadata for the associated user information to this metadata? Exactly these additional metadata can be defined uniformly using the iiRDS standard. Through its contacts with the Industry 4.0 working group, tekom would therefore like to extend the "Reference Architectural Model Industrie 4.0 (RAMI 4.0)" with iiRDS metadata.

The preparatory work of the Technical Writing Office

The situation analysis described at the beginning is disillusioning at first. And it shows that technical communication as a whole has so far lacked an overarching strategy for the phenomenon of "digitalization". With iiRDS, however, it is possible to further refine the indispensable preparatory work on information structuring, modularization, reuse or metadata that was previously carried out in the technical writing departments. The advantage is that they can be reused in the Industry 4.0 scenario outlined. The standard is currently the only contemporary approach for linking highly structured information units via semantic relationships in order to achieve context-sensitive and dynamic input and output.

In the iiRDS scenario, it does not matter whether the source information comes from a machine controller or a technical documentation. And the recipient of the information can be a human being, software, or even an interface. This universal processing of user information demonstrates the full potential of the new tekom standard.

The conceptual basis

The members of the working group "Information 4.0" have carried out three essential topics regarding the groundwork for the implementation of the standard:

1. Definition of requirements based on user stories:

Ten topic areas with a total of 59 individual applications were developed and prioritized using the MoSCoW method.

Examples:

• "As a maintenance technician, I want instructions to be context-sensitive in the event of a malfunction so that I can act appropriately." (mandatory)
• "As a user/operator/maintenance technician, when changing software configuration or hardware components, I would also like the correspondingly adapted user information so that system and information always fit together.”  (obligatory)

2. Definition of bilingual terminology (German/English):

Binding terms have been defined for all syntax elements of "iiRDS". These include the names for document categories, information types, and life cycle phases. This work was closely coordinated with the tekom working group "Terminology of Technical Communication" in order to use consistent terms.

3. Developing an ontology and modelling its components:

Prior to the technical implementation of iiRDS, a comprehensive and largely complete ontology that covers all aspects and dimensions of the task and structures them on the basis of interrelationships was developed. In addition to the information objects themselves, their assignments to classes, instances and their relationships to each other were modeled. Figure 3 shows some of the defined classes and their possible subclasses.

Figure 3: Defined classes and possible subclasses from the iiRDS ontology. Source: tekom

Interested parties can download the complete model and the specification after prior registration on the internet: iirds.org

The structure of iiRDS

The new tekom standard consists of two main components: Metadata and package format.

1. Standardized metadata:

Technically, an ontology is represented by a complex network of contents, relationships, attributes and resources. It can be understood as a set of standardized, structured metadata. With iiRDS, these relationships are modeled in an RDF scheme - Resource Description Framework. RDF is a data model of the Semantic Web, in which the data are statements about resources. The statements are modeled as a triple – as to be seen in Figure 4. Triple stands for subject, predicate, object.

Figure 4: Exemplary modeling of iiRDS elements. Source: tekom

The iiRDS metadata is organized in a class system that conceptually consists of three main classes:

• Information Unit – represents an iiRDS resource; can be a package, document, topic or fragment
• Information type – describes information types such as document type, topic type or topic
• Documentation Metadata – functional metadata such as maintenance intervals or events; docking points for product and component metadata from other domains

In addition, the auxiliary classes "selector" and "rendition" are available, which are required for selecting a physical source file and for creating directories.

2. Standardized package format:

The package format organizes the transport or exchange of information. For this purpose, the data is combined in a ZIP container with a predefined directory structure - Figure 5.

The format of the content files is not specified by default. Both highly structured data, for example topics in XML format, and low-structured data, for example documents in PDF format, can be used here.

Figure 5: Data is exchanged via a predefined directory structure and a ZIP container. Source: tekom

The standard in practice

If a company wants to implement iiRDS in its own operational practice, specific preparations are necessary. Unfortunately it will not be possible without additional work, because the conversion requires at least a mapping of existing information modules and metadata with the structural elements of the standard and their metadata. The first process models are already in progress and can serve as orientation. tekom will support this adjustment process as much as possible in the coming months through further information and publications. In addition, many manufacturers of content management systems have already announced that they will expand their products for the use of iiRDS – an important contribution to the intended standardization.