Building the Industry 4.0 IT Infrastructure for Digital Twins

Industry 4.0 and Digital Twins promise many benefits, such as an efficient lot size 1 or various optimizations. However, successfully implementing these concepts requires a sophisticated IT infrastructure. What are the requirements on this infrastructure and how can it be set up? Based on state-of-the-art Industry 4.0 concepts, we will elaborate this question. In addition, an outline for a solution architecture will be presented.

Industry 4.0 offers a plethora of use cases and solutions for all different kinds of challenges. Unlike previous revolutions, it does not introduce a singular new technology, but covers a more groundbreaking change, which is the end-to-end digitalization of manufacturing processes. It is mainly driven by innovations in plant software systems and by the transfer and transformation of knowledge from the IT sector to manufacturing. Industry 4.0 introduces new concepts, e.g., Digital Twins and cyber-physical systems. However, implementing these concepts requires thinking plant architecture and infrastructure completely anew. Currently, automation is implemented using the “automation pyramid” reference architecture as defined by IEC 62264 [1]. This architecture consists of separate layers with defined interaction points. Due to this setup, cross-layer interaction in the automation pyramid is difficult, as every layer can only access information provided by neighboring layers. Therefore, changes require modifications in all layers. In contrast, Industry 4.0 propagates peer-to-peer communication to enable device-to-device communication. For further details on the overall plant architecture of the future, see BaSys 4.0 (in German).

Cross-layer interaction requires a structured approach for representing and exchanging data. The concept of Digital Twins, which originated from the testing of avionics systems [2], is a key concept for cross-layer communication in Industry 4.0. A Digital Twin is a representation of the state of an asset, i.e., of a physical entity. It enables unified access to asset data and services. As defined by the IIC [3], “a digital twin is a formal digital representation of some asset, process or system that captures attributes and behaviors of that entity suitable for communication, storage, interpretation or processing within a certain context”.

Digital Twins (DT) describe all relevant assets in an I4.0 production. Assets are, for example. products-to-be-produced, work pieces, and devices. DTs aggregate data generated in the physical world, enable experimenting with this data in digital representations of I4.0 assets (physical or non-physical entities), and provide insights that may be deployed back to the physical world as updated configurations. Thus, the data provided by the Digital Twins can be used to orchestrate and optimize the plant.

 

Requirements for an Industry 4.0 IT Infrastructure supporting Digital Twins

However, introducing the concept of Digital Twins on its own is not sufficient for leveraging the benefits of Industry 4.0. Additionally, a supporting IT infrastructure is needed to enable efficient handling and integration of Digital Twins. In the following, multiple scenarios are described to motivate the requirements of an Industry 4.0 IT infrastructure.

• Storing the complete DTs in the cloud is intuitive. However, it is not efficient. If there is data that is updated frequently, storing DTs in the cloud requires first pushing the data into the cloud before it is available to other applications. Depending on the update frequency and data size, this can produce significant data traffic, potentially overwhelm the plant’s communication infrastructure, and lead to high costs. Vice versa, storing all data in the edge may overwhelm the edge node itself. Instead, a hybrid approach is advisable. Static (or rarely updated) data can be stored in the cloud, while frequently updated data is stored in the edge. However, this approach requires an appropriate infrastructure to support distributed Digital Twins.
• Ideally, each device should provide its own Digital Twin. However, a DT may describe, for example, relevant maintenance data. Thus, a failure of the device (for example due to electromechanical reasons) should not affect the availability of the DT. Otherwise, the required maintenance information might not be available at the exact moment when it is needed most. Thus, a device should be able to upload its own Digital Twin (or parts of it) to the plant infrastructure.
• Industry 4.0 systems are dynamic. Thus, new, comparable, or identical asset types can come and go at all times. The corresponding access points (end points) to these components may change as well. Therefore, a central and always up-to-date registry service is imperative for the operation of an Industry 4.0 system. Using this registry, applications can browse through the available Digital Twins, for example to discover available manufacturing capabilities. This discovery can be based, for example, on tags identifying certain key properties of an asset (e.g., being a mill) or on a query language supporting simple requests. A typical use case for the latter is the retrieval of the Digital Twins of all products manufactured within a certain timeframe.

Considering these aspects is sufficient for setting up the core I4.0 IT infrastructure. However, Industry 4.0 draws great benefit from automation and from reducing the need for human intervention. Thus, an optional scenario incorporating this aspect can be formulated.

• Commissioning of devices and applications may take a lot of time. One reasons for this are multiple configuration steps that need human involvement. Thus, any automation of configuration steps is beneficial for reducing the overall integration effort. Ideally, integrating a new device can be reduced to configuring its network integration, plugging it in. and turning it on. Complementarily, any application should be able to pick up work with little to no configuration effort. In consequence, key infrastructure components should be discovered automatically.

To summarize, the following requirements on an I4.0 IT infrastructure can be formulated, each motivated by the scenario with the corresponding number:

• 1st Requirement: Support distributed Digital Twins
• 2nd Requirement: Allow upload of Digital Twins
• 3rd Requirement: Provide registry for Digital Twin discovery
• Optional 4th Requirement: Enable discovery of infrastructure elements

Additionally, the representation of the Digital Twin itself has to be chosen carefully. Ideally, it should enable the definition of semantics to prevent misunderstandings. Furthermore, a lot of data is already available in a standardized way. Thus, it should allow the integration of outside standards to enable the reuse of existing work.

 

Asset Administration Shells as Standardized Digital Twins

Standardization of assets is an important success factor of the German industry. This success can be extended to the digital world. Thus, it is advisable to utilize an agreed-upon and standardized format for representing Digital Twin. The Asset Administration Shell (AAS) [4] as specified by Plattform Industry 4.0 is such a format. It provides access to both properties and functions via standardized interfaces. Additionally, a defined meta-model specifies a common minimum set of information that all Digital Twins must export. An Asset Administration Shell references submodels, each of which provides a specific view of the Digital Twin. Furthermore, views enable splitting information by information type, but also by the role (e.g., type of person or connecting machine) that might be interested in it. For example, one submodel may describe the physical dimensions of the asset, while another submodel may provide access to sensor data and other submodels may provide information on the availability of spare parts.

By adding specialized submodels, AAS can be used to implement different versions of the Digital Twin. Submodels may, for example, provide static data, like a digital data sheet. They may provide access to live data, enable the controlling of a machine, and implement their own behavior to monitor data streams or the availability of spare parts. By using Asset Administration Shells and submodels, it is possible to provide a harmonized, service-based interface to the whole production system, in which every physical and virtual device, product, worker, and other assets are represented by their own object instance.

The AAS is the standardized self-description of a technical or logical component in production. Essentially, it is a machine-readable, technology- & device-agnostic description of a component that provides access to all of its properties and functions.

A fundamental difference between existing solutions and the AAS concept is the manufacturer-independent standardization of the AAS meta-model [5]. In this respect, there are currently no standards in the field of production automation that provide such a self-description of systems and devices in a technology-neutral and manufacturer-independent way.

Figure 1 – The Asset Administration Shell wraps an asset and provides unified access to its properties through submodels.

In current systems, the data semantics are either implicit or hard coded. However, the AAS focuses on the semantic description of data. In the end, all AAS data should be semantically described to define its meaning. In this case, it should not matter if a variable name or the data structure of an AAS submodel changes. This is where another advantage of the Asset Administration Shell comes into play: The Asset Administration Shell is able to link properties and functions with semantic information. For example, the semantic description of a property uses a standardized description for properties according to IEC 61360. This ensures that even if components from different manufacturers use different field names for properties, a common definition of the meaning of properties and operations is guaranteed. There are already extensive databases that offer a large number of properties for a wide range of device types and domains. Examples of such databases are eCl@ss and the Common Data Dictionary (CDD).

At the moment, only the structure of the Asset Administration Shell itself and the basic structure of submodels are defined by the Platform Industry 4.0, and are undergoing standardization. Users are responsible for the content of a submodel and can define numerous different submodel types for their devices that exactly meet their needs. The definition of ontologies that give semantics to the submodel properties is the subject of current work.

 

Setup of the Industry 4.0 IT Infrastructure Utilizing Asset Administration Shells

Using the concept of the Asset Administration Shell and considering the requirements specified above, an Industry 4.0 IT infrastructure can be specified. The following central components are defined:

• Registry: Keeps track of the AAS in the system, can be browsed based on certain criteria, and provides the endpoint information for AAS access.
• AAS Server: Provides the AAS and allows dynamic upload of AAS. Can be located in the cloud.
• Edge Node: Provided by the device. Hosts highly dynamic data, e.g., sensor values.

Figure 2 shows the resulting infrastructure. Additionally, it shows the initial setup of a device. As the initial step, the newly connected device pushes its AAS and appropriate submodels (e.g., a documentation submodel) to the AAS Server (1). Then it registers the pushed AAS and submodels as well as the submodels stored directly on its edge node with the registry by providing the AAS Descriptor containing meta-data and, most importantly, the endpoint of the AAS and possible submodels (2).

 

Figure 2 – Start-up with upload of the Digital Twin and registration

The interactions for Digital Twin retrieval are shown in Figure 3. First, the application requests the AAS based on certain criteria from the registry (1). The registry returns the AAS Descriptor of the appropriate AAS (2). The application connects to the AAS server and retrieves the AAS (3). Finally, the application connects to appropriate submodels to retrieve the needed data (4).

Figure 3 – Application access to Digital Twins

 

As soon as the corresponding end points have been queried from the registry service, components may communicate directly with each other, so that a failure of the registry service does not immediately lead to a stalled production. Only in case of a change in component availability do service users and service providers need to consult the registry again.

 

Tailoring the Digital Twins Infrastructure for Success

A strong IT infrastructure can be decisive in the successful implementation of Industry 4.0. The proposed infrastructure supports the given requirements and enables central use cases. However, standardization efforts and common data models can further strengthen this backbone of the smart factory. By providing submodels for specific application types, the need for human intervention can be decreased even further. For example, in a service-based production, an orchestration application can automatically discover newly introduced devices and their capabilities based on a service submodel.

By introducing application- or use-case-specific submodels, the infrastructure can be further extended and tailored. Thus, easy reactions to unforeseen changes can be enabled. For further information on how changeability can be helpful in the current pandemic, for instance, see this (German) blog post.

 

 

[1] International Electrotechnical Commission. „IEC 62264-1 Enterprise-control system integration–Part 1: Models and terminology.“ IEC, Genf (2003).

[2] Glaessgen, Edward, and David Stargel. „The digital twin paradigm for future NASA and US Air Force vehicles.“ 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference 20th AIAA/ASME/AHS Adaptive Structures Conference 14th AIAA. 2012.

[3] Definition of Digital Twin, https://www.iiconsortium.org/pdf/IIC_Digital_Twins_Industrial_Apps_White_Paper_2020-02-18.pdf, last accessed 2020/07/20

[4] Constantin Wagner, Ulrich Epple, Julian Grothoff, Rainer Drath, Somayeh Malakuti, Sten Grüner, Michael Hoffmeister, Patrick Zimmerman, „The role of the Industry 4.0 Asset Administration Shell and the Digital Twin during the life cycle of a plant”, ETFA 2017, Limassol

[5] https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details-of-the-Asset-Administration-Shell-Part1.html