The abbreviation iiRDS stands for intelligent information Request and Delivery Standard. Its purpose is to enable the provision and exchange of intelligent information independent of industry and manufacturer [1]. With the standardized exchange of information, machine and plant manufacturers can provide different customers with the information for use they need. In return, customers are able to integrate information from different manufacturers into their systems and processes without additional effort. However, this refers to the exchange of information not only between manufacturer and end customer, but also between suppliers (OEM) and manufacturers.
On the one hand, iiRDS standardizes the vocabulary – the metadata with which the information is labeled so that it can be clearly identified. On the other hand, the standard defines a package format with which the content can be interchanged between the applications for information generation (iiRDS generator) and information presentation (iiRDS consumer).
Accelerating information research
Content delivery portals (CDP) are primarily used to present information. The focus is on facilitating the search and finding information quickly. Instead of monolithic PDF documents, small information units (topics) are created, which are provided with metadata and made available in a web-based format.
By entering a search in the CDP, the user receives a hit list. With facet navigation, the search results can be narrowed down on the basis of the metadata. In the end, the user is shown exactly the information that fits his use case (Fig. 01). This facet search mechanism (pull principle) can be used to accelerate typical information retrieval use cases, such as finding technical information about a specific product. Various software vendors offer content delivery portals that cover this use scenario.
However, information can also be displayed in relation to the situation, without a search input (push principle). Two application examples illustrate this:
- Targeted help with the configuration and initial startup of a machine.
- Information on maintenance and service cases based on the status information of the machine.
To implement these tasks, the user typically uses IT systems such as configuration and engineering software, operator terminals on the machine, or service apps on mobile devices. In order to display information appropriate to the task or the machine status, the respective IT system takes over the interaction with the CDP. The IT system uses web services to precisely send the metadata to the CDP that uniquely identifies the required topic.
Fig. 01 Facet search – process from the search to the presentation of the result
Source: Thomas Katzenmeier
It is also possible that the information is not displayed in the CDP (web browser or mobile app), but directly in the IT system, for example in the operating software on the HMI terminal. The front end for the user is therefore not the CDP, but the IT system with which he is currently working. The content delivery portal remains in the background as "middleware" and delivers the desired topics to the IT system. It thus represents an overarching platform for the intelligent delivery of information in different IT systems. The machine manufacturer or plant engineer could therefore embed the content required for his use cases in his software without the front end of the CDP. In the following, the term Content Delivery System (CDS) is used as a proxy for any variants of the implementation of the front end.
Integrated help system
In addition to the technical requirements, it must be ensured that the individual information objects (topics) contain exactly the information that is suitable for processing the respective use case. When commissioning a plant with configuration or engineering software, this typically means the contents of the help system, which describe a dialog window or a specific software function, for example. When the help is called up via a help button or the F1 key, the software triggers a request to the CDS. The CDS acts as a context-sensitive help system and provides the appropriate information. The query to the CDS is composed of the metadata used to identify the software function in question, such as the name of the software, the existing software version and the software function itself (Fig. 02).
Fig. 02 Content delivery system for context-sensitive help
Source: Thomas Katzenmeier
When creating content for the help system, each topic must be provided with precisely this metadata in order to be able to uniquely identify it in the help system. In contrast to the classic help system – such as CHM or JavaHelp – the help topic is not identified by an additional identifier, but by the metadata that matches the topic. This has the advantage that the exact metadata already used to classify a topic in the CDS can also be used directly to access the help topic. Thus, an additional and often error-prone identifier mechanism is unnecessary. The use of the CDS as a help system offers further advantages:
- No additional help authoring tool for creating the help system content – the content can be created in the same system used for the other content in the CDS (single sourcing).
- No data silo – if the content for the help system is available in the CDS together with further content (for example, commissioning instructions or technical data), the user can research further information via the facet search of the CDS.
- No media disruption – a single stylesheet template provides a consistent layout for all content in the CDS and help system.
- No additional publication format – the content and metadata for the help system can be transferred to the CDS via the standardized iiRDS package format.
- Third party integration – some machine manufacturers open their development platforms and allow other companies to implement and integrate system functions as apps. With the iiRDS exchange format and the appropriate metadata, these third parties can make their app documentation available in the common help system in a context-sensitive way.
Some examples of iiRDS metadata are shown in Table 01.
Metadata as key
In the second application example, information is to be provided for maintenance and service cases. The IT system used for this purpose, for example a service app on a tablet or smartphone, communicates directly with the machine or plant. The maintenance employee first scans the machine's electronic identification plate. The service app accesses the machine's diagnostic data via a WLAN connection and identifies a problem with a component that may be installed deep within the machine. Using the metadata, such as the serial number or type designation, and the status information, the service app generates a query to the CDS. In response, the CDS provides the appropriate topic with information and action instructions for troubleshooting (Fig. 03). Required tools, equipment or even spare parts can also be displayed.
If the service technician cannot fix the problem on his own, he may need support from the helpdesk. For this purpose, the service app can make direct contact and transmit the metadata so that a helpdesk employee can process the problem and suggest a solution. In addition, the metadata can be used to link the service app to catalog, merchandise management or store systems and thus order replacement or repair parts to match the service case. This or similar application scenarios create new business models for manufacturers, suppliers and service providers, in short "value-based services".
Fig. 03 Situation-related information based on the machine status
Source: Thomas Katzenmeier
Open for proprietary metadata
iiRDS provides a basic set of metadata classes for technical communication by default and already suggests some common metadata. These can be extended by vendor-specific metadata. For the two application examples, iiRDS provides all required metadata classes and docking points:
- Docking points for product metadata (ProductMetadata) for the classification of products and variants, installed (supplier) components as well as their features and functions.
- Events such as machine/plant states or error codes (Event).
- Topic (InformationSubject) and type (TopicType) of the information.
- Location of the information in the product life cycle (ProductLifeCyclePhase)
- Action to be performed (Action)
- Information about tools that are required for the action (Supply)
- Qualification and role of the user (SkillLevel and Role)
While some metadata are already predefined, manufacturers must add their product- and application-specific metadata. For example, a supplier for electric drives can map his classification scheme for malfunction conditions in the class Event and label his Topics with it.
Products, product characteristics and labels for components are not defined in iiRDS. Here, the manufacturer can map his product hierarchy and, if necessary, assign existing classifications from ERP, PIM, product configurators or from standardized models such as ECLASS [2]. The same applies to metadata on utilities, actions, qualification and roles, which must be defined on an application-specific basis. The InformationSubject class contains some predefined metadata, for example: declaration of conformity. However, missing subjects must be added, for example: type examination.
Finding a common ground
To make the most of iiRDS for cross-manufacturer information, it is necessary to standardize the exchange of information. To do this, suppliers and manufacturers must reach bilateral or multilateral agreements and merge their respective proprietary classifications. Where no agreement can be found, metadata can be mapped. This is the way iiRDS provides for mutually aligning and mapping entire ontologies of different metadata designations. An example: The supplier designates a component as "operator terminal". The machine builder who installs this component, however, calls it "operator device". Using the mapping mechanism, both designations can be merged without changing the metadata values.
The standardized package format makes it possible to exchange all contents together with the metadata among each other. In this way, the machine manufacturer can integrate the various iiRDS packages from suppliers into his CDS without having to adapt the content further. The content can be in any file format, such as PDF, XML, HTML or MP4. Manufacturers and suppliers must agree on the file formats. If the content is to be provided in HTML format – as is usual for content delivery systems – the HTML elements used must be narrowed down if necessary and the stylesheets adapted accordingly. A simple way to achieve this is the so-called iiRDS/A format. This format, defined specifically for exchange, limits the permitted media formats and the HTML language scope [3].
Industry 4.0 offers perspectives
In addition to the standardization of metadata and the package format, the possibilities within the framework of Industry 4.0 should also be considered. Industry 4.0 refers to the intelligent networking of machines and processes in industry with the aid of information and communication technology [4].
Various working groups are developing important basic technologies and technical concepts for Industry 4.0. Participating companies and organizations are involved in concepts for the digital twin, for example. This digital twin is technically implemented in what are called administration shells. Different functional aspects of an Industry 4.0 component are mapped as partial models in an administration shell. Some partial models have already been implemented or are in the process of being coordinated. These include:
- Technical (meta)data for industrial equipment such as product classification (for example according to ECLASS), product identification and technical characteristics.
- Digital identification plate for product identification of industrial equipment.
- Minimum requirements for handover documentation from manufacturer to operator (according to VDI 2770).
- Exchange of information between partners in the Industry 4.0 value chain.
On this basis, technical communication also fits in as a partial model. Currently, the requirements are only specified at document level according to the principle of the VDI 2770 guideline [5]. iiRDS, on the other hand, considers the information more comprehensively and at a finer granularity. The standard was included in the "German Standardization Roadmap Industry 4.0" of DIN/DKE in July 2020 [6]. In the context of Industry 4.0, iiRDS is intended to enable the generation of situation-related context-specific information for the cases occurring in the product life cycle. In doing so, the information should fulfill the following Industry 4.0-compliant requirements:
- Adapt dynamically to the user and the application context
- Be available in a targeted manner for all lifecycle phases, from specification to maintenance
- Match the delivered system, even after configuration changes and updates
- Dynamically integrate assistance and sensor information as well as operating parameters
- Support diverse search and filter functions
These requirements can be mapped in a partial model with iiRDS. "Intelligent information" is thus further systematized, linked to other standards and made available in the digital twin. Agreements between suppliers, manufacturers and operators are becoming increasingly superfluous. It will become easier and more attractive to exchange information with each other. This will allow new applications and business models to emerge – iiRDS will play a central role in this.
Links and literature relating to the article
[1] tekom (2018): iiRDS – The International Standard for intelligent information Request and Delivery. https://iirds.org
[2] ECLASS e. V.: ECLASS – Standard for Master Data and Semantics for Digitalization. https://www.eclass.eu
[3] iiRDS Consortium (2020): tekom iiRDS Standard, Version 1.1. https://iirds.org/fileadmin/iiRDS_specification/20201103-1.1-release
[4] Bundesministerium für Wirtschaft und Energie: Plattform Industrie 4.0. https://www.plattform-i40.de
[5] VDI (2020): VDI 2770 Blatt 1. https://www.vdi.de/richtlinien/details/vdi-2770-blatt-1-betrieb-verfahrenstechnischer-anlagen-mindestanforderungen-an-digitale-herstellerinformationen-fuer-die-prozessindustrie-grundlagen
[6] DIN/DKE (2020): German Standardization Roadmap on Industry 4.0 https://www.din.de/en/innovation-and-research/industry-4-0/german-standardization-roadmap-on-industry-4-0-77392
