An approach for Industrie 4.0-compliant and data-sovereign Digital Twins

2.1 Asset Administration Shell

The Asset Administration Shell (AAS) is a concept developed by the Plattform Industrie 4.0, a network of companies, associations, trade unions, science and politics in Germany [4]. It is motivated by the Reference Architectural Model Industrie 4.0 (RAMI4.0) [5] and driven by the idea to manifest the concept of DT in factories and industrial production plants. The specification is currently published in two parts. Part 1 [6] introduces the AAS meta model including different serialization formats (JSON, XML, RDF, AutomationML, OPC UA node set, AASX) and Part 2 [7] defines different APIs in a protocol- and technology-agnostic way that can be used to interact with an AAS. As the specification is still evolving, these documents are expected to be updated in the future, e. g., an updated version of Part 2 specifying a mapping of the protocol-agnostic API to HTTP is expected in the near future. The AAS specification is subject to standardization in the document series IEC 63278 ED1 „Asset administration shell for industrial applications – Part 1: Administration shell structure“.

2.2 International data spaces

The International Data Spaces (IDS) is a data network focusing on data sovereignty, the ability of a data provider to determine who and how their own data can be used [8]. The central component, the IDS connector, is a gateway to the network and different implementations are in development to ensure data security and sovereignty. DIN SPEC 27070 specifies requirements and a reference architecture for security gateways, that ensure a trusted exchange of industrial data and services [9].

The application domains are broad and IDS communities focus on specific use-cases to support different industry branches. For example, the IDS-I (Industrial Community) aims to apply the IDS in the Industrie 4.0 (I4.0) [3]. For the technical enforcement of usage policies, usage control frameworks ensure correct application in all connectors. Our work is focused on the MYDATA [10] usage control framework in the IDS Trusted Connector [11]. The Trusted Connector is a reference connector implementation in the IDS with security and trust as the highest priority [8]. MYDATA is a proprietary implementation of a usage control framework which can be integrated into many IDS Connector implementations.

3.1 Realizing Digital Twins with FA³ST

FA³ST (Fraunhofer Advanced AAS Tools for Digital Twins) [13] is a Java-based software toolbox to create and manage AAS-compliant DTs. It comprises a library for developers to easily create and execute DTs, called FA³ST service, as well as the FA³ST registry which allows registering and discovering of DTs.

Figure 2 shows a high-level schematic diagram depicting the components and interfaces of the FA³ST service library. It is designed to be easily extendable and customizable by offering a variety of extension points. Core element is the AAS Metamodel which represents the DT with all of its properties and operations. By introducing the Asset Connection extension point on south-bound side, we support connecting the AAS to an asset which can be any kind of resource or legacy system independently of the connection or protocol type. On northbound side, to realize an API to interact with the DT, we provide the Protocol Endpoint extension point, allowing to implement endpoints using multiple different communication protocols as envisioned by the AAS specification. FA³ST service provides a HTTP/REST-based and an OPC UA endpoint. Each endpoint can provide functionality defined by the different supported message types which may be API calls or Events (as defined in [6] and [7]) or may be formatted according to the I4.0 Language [14], [15] used by services with state machine-based interactions [16]. Mediation and synchronization between the endpoints and the metamodel happen in the Handler component. FA³ST service also supports multiple serialization formats via the De-/Serializer extension point as well as the use of different data storage systems via the Persistence Manager extension point.

As an additional feature, FA³ST service can be integrated with Apache StreamPipes [17] via the Apache StreamPipes Runtime extension. This enables adding stream processing capabilities to a DT allowing to compute additional properties of a DT at run-time. Apache StreamPipes provides an easy-to-use visual editor that supports non-expert users in creating so-called pipelines consisting of data sources, processors and data sinks. The data sources fetch data from external systems and feed it to the chain of processors. Data sinks can be used to send the result of the pipeline back to external systems. FA³ST already provides a DT source and sink component for Apache StreamPipes. More details on FA³ST can be found in [13] including a code example and details on the integration of FA³ST with Apache StreamPipes.

Figure 2

High-level schematic diagram of FA³ST service.

3.1.1 Alignment with Digital Twin reference architecture for manufacturing (ISO DIS 23247)

“The ISO 23247 series defines a framework to support the creation of Digital Twins” [18] in the context of the manufacturing domain. Part 2 of the series [18] defines a DT reference architecture for manufacturing on domain and entity level. It identifies the DT building blocks and provides guidance on how they should work together. This standard was used to design the FA³ST architecture as it ensures that all aspects are considered and each building block is well understood and correctly placed.

Figure 3 illustrates how the FA³ST service components introduced in Fig. 2 together with additional software components from the FA³ST ecosystem align with the entity-based DT reference model of ISO DIS 23247. The blue boxes represent the reference model entities from the ISO standard, the white boxes components of FA³ST, and dark grey boxes planned extensions to the FA³ST toolbox.

On the bottom of the figure are the observable manufacturing elements, i. e., the physical assets that should be represented by DTs. In the Data Collection and Device Control Entity, the Asset Connection of FA³ST spans across the Data Collection Sub-Entity and the Device Control Sub-Entity as it combines both functionalities.

Figure 3

Alignment of FA³ST with the entity-based Digital Twin reference model for manufactoring from ISO/DIS 23247-2 [18].

According to the ISO standard, the Core Entity is composed of the Operation and Management Sub-Entity, the Application and Service Sub-Entity, and the Resource Access and Interchange Sub-Entity. The Operation and Management Sub-Entity “operates and manages” the DT and is also responsible for representation and synchronization [18]. This functionality is provided by the AAS Metamodel, Persistence Manager, Handler, and De-/Serialization in FA³ST. The Resource Access and Interchange Sub-Entity is responsible for communication of the DT with the outside world. In FA³ST, this comprises all Protocol Endpoints (see Fig. 2) represented by the concrete endpoints of HTTP and OPC UA protocol, as well as the extension point for future I4.0 languages and events.

The Application and Service Sub-Entity provides additional services that can be integrated with a DT, e. g., for simulation or analysis purposes. With FA³ST, we provide an integration with the Apache StreamPipes framework, via the Apache StreamPipes Runtime component.

“The User Entity can be any entity that utilizes the Digital Twin for manufacturing, including a human […]” [18]. As part of the FA³ST ecosystem, we developed two components for the Apache StreamPipes visual editor, called DT Sink and DT Source, that enables non-expert users to use DTs as a data source and/or sink in their Apache StreamPipes pipeline with just a few clicks. Additionally, we are working on a web and a mobile application for users to interact with a DT.

The Cross-System Entity shown on the right is responsible for providing common functionality across the other entities, such as data assurance and security. FA³ST provides the IDS Connector component for these purposes.

3.2 Protecting Digital Twins with IDS

Figure 4

FA³ST in combination with the IDS aligned to ISO/DIS 23247-2 [18].

For the implementation of the I4.0-compliant DTs with FA³ST, the architecture of the IDS with their core component, the IDS Connector, is considered. In the context of ISO 23247-2, the IDS Connector is a Cross-System Entity used to realize data-sovereignty. Although the AAS specification basically proposes attribute-based access control (ABAC) for handling access control to data, there are only broad statements about the required service infrastructure to really support ABAC [6]. For example, the identity management solutions focus on the OpenID Connect framework. Data sovereignty includes usage control and data provenance tracking. Usage control extends the existing access control with additional obligations, that the data consumers need to follow. Provenance tracking describes the traceability of data in the network, allowing data owners to track their data even when it left their own connector [10]. Within the IDS-Industrial community, a joint activity between the Platform Industry 4.0 and the IDSA International Data Spaces Association (IDSA), data sovereignty requirements for the manufacturing industry are analyzed and mapped to joint architectural patterns that include a combination of AAS and IDS technologies [3].

However, the realization of a usage control system is a significant architectural endeavor and starting from scratch for the AAS would not be feasible for us. For example, the identity management is a central issue, which the IDSA already solved in its architecture [8]. The IDSA has several implementations of usage control frameworks in active development and demonstrated them in several use-cases [19]. These frameworks use Open Digital Rights Language (ODRL) policies which are then converted in implementation-specific policies [8]. While the specification of AAS policies currently focuses on access control, we defined ODRL policies for restricting usage of AASs and applied them with the IDS usage control framework “MYDATA Control” [10]. In future, the AAS policies defined with an AAS meta-model containing usage control rules have to be mapped to ODRL policies to be applicable in IDS usage control frameworks, in our case MYDATA. Another feasible approach in the future would be extending existing usage control frameworks or creating new frameworks to apply AAS usage policies directly in DTs. In this case a framework like MYDATA could be adapted to be used in I4.0-compliant DTs.

One fundamental key of the IDS architecture is that data resides inside of the IDS connectors, where usage control frameworks can control the data usage [8]. If data leaves the connector, it is difficult to enforce the correct usage. The IDSA is considering usage control outside of connectors by applying usage policies in the systems processing the data. In theory, AAS implementations like FA³ST could include its own usage control framework applying usage control rules. However, the IDS connector is designed as security gateway according to DIN SPEC 27070 and includes several security mechanisms like remote attestation and trusted platform support [8]. Current AAS implementations lack such features but will be enhanced as the implementations of DTs grow. In the current state, data is most secure inside the connector but looking at industry use-cases, it is unrealistic to expect companies to run all their software inside IDS connector containers including all of their I4.0-compliant DTs.

That is why we decided to keep most of the DT service outside of the IDS. Figure 4 shows the combination of FA³ST and IDS in alignment to ISO 23247. For clarity, the services inside of User Entity and Core Entity are not shown. The IDS Connector is part of the Cross-System Entity and contains a Service Container, Usage Control Framework and a component for the IDS Message. The Service Container contains isolated IDS Apps. The IDS Message component encodes and decodes messages for communication with other IDS connectors. Currently, the IDS Messages are multipart messages according to RFC7578 [8] but drafts for a generic IDS API [20] exist. DT services providing data are not part of the service container in the IDS Connector. DT services looking to process critical data, have to be deployed in the Service Container, but we usually extract the data processing part inside an IDS App to process highly critical data with usage policies, such as a business analytics app processing critical production parameter. In this case, the usage policy would ensure that the critical values are not leaked and only calculated KPIs are forwarded to other DT services.

In conclusion, we consider only running a subset of software processing highly critical data inside of IDS connectors as IDS apps. This can include IDS apps connecting to the core entity of the DT.

5.1 Use cases and applications of data-sovereign Industrie 4.0 Digital Twins

The combination of Industrie 4.0 Digital Twins with the IDS has also been tested in other projects, namely RIOTANA by Fraunhofer ISST / IAIS [23] and the Smart Connected Supplier Network (SCCN) by TNO [24]. In both cases, the Digital Twin is either placed directly into the IDS connector (service container) or an IDS app is used to act as a proxy. Since the IDS connector only understands IDS messages, specific clients (other IDS connectors or web-based GUI) are necessary to communicate with the digital twin. On the plus side, usage policies can be effectively applied inside of the connector. However, partners without IDS background cannot access the digital twin resulting in a split: data-sovereign digital twins inside the IDS and digital twins without usage control.

We focus on keeping the digital twin outside of the IDS connector while extracting functionality in need of usage control inside of IDS apps. For example, critical production data inside of a Digital Twin is sent to an IDS app analyzing this data and can then be viewed by partners in an IDS visualization app. This combination means that we can still provide Digital Twins without usage control for partners without IDS knowledge, while also providing critical data for IDS apps processing it according to our usage rules. However, providing critical data to IDS apps needs additional effort in form of configuration of the IDS connector. Our future work will focus on bringing the IDS usage control directly into the Digital Twin by mapping and applying AAS usage rules into ODRL policies. For this, the existing ABAC specification inside the AAS Security specification would need an extension for usage control. This will also reduce the effort of configuration and the aforementioned split between data-sovereign and non-data-sovereign Digital Twins.

5.2 Further Asset Administration Shell implementations

In this section we present further implementations of the AAS specification. The implementations are chosen based on our subjective perception of their level of maturity and current or future relevance. This list does not claim to be complete.

Interoperability across implementations comprises an offline aspect, serializing an AAS using one implementation and deserializing it using another one, as well as an online aspect, exchanging a running AAS with another implementation while not changing the API of the AAS to the outside world, e. g., an application. Interoperability across the different implementations is very limited. For the offline aspect this is because the AAS meta model and de-/serialization rules are still subject to changes every few years and different implementations often implement different versions. For the online aspect this is because there is only a protocol-agnostic definition of the API and each implementation is doing its own mapping of this protocol-agnostic API to the protocols they support (which is mostly HTTP) resulting in slightly different HTTP APIs.

PyI40AAS is a Python SDK developed by the RWTH Aachen University, which at the current date implements a subset of the AAS features, such as the serialization and deserialization of JSON and XML [25]. However, interaction with the AAS using OPC UA or HTTP/REST interfaces is not supported yet. [26].

Eclipse BaSyx [27] is an open-source implementation of the AAS specification. It has been developed as part of the research projects BaSys 4.0, that ended in mid-2019, and its successor BaSys 4.2, running until mid-2022, funded by BMBF. Compared to BaSyx, our implementation provides multiple unique features such as the ubiquitous extendibility, integration with Apache StreamPipes as well as with the IDS.

The AASXServer [28] is a C# based server implemented by the Industrial Digital Twin Association (IDTA) [29] and its members to deploy AASX files. These files are DT packages consisting of XML files describing the DT and additional files like PDFs and images. In this aspect, the AASXServer operates similarly to FA³ST, that supports DT descriptions in JSON, XML, RDF, AutomationML and AASX. It also supports REST, MQTT and OPC UA endpoints offering the AAS API over these protocols. The endpoints in the AASXServer are not synchronized, effectively operating several different DTs for the same asset over different protocols. FA³ST therefore implemented synchronization of all endpoints to enable operating on the same DT with different protocols. Set-up effort of both solutions is low by providing docker containerization. Additionally, FA³ST also supports connections to assets which do not provide I4.0-compliant protocols.

NOVAAS [30] is a reference implementation of the AAS specification from the research institute Instituto de Desenvolvimento de Novas Tecnologias (UniNova). It has been developed in the context of the H2020 PROPHESY project which aimed to enhance predictive maintenance services in the industrial environment [31]. NOVAAS is based on Node-RED which is a flow-based programming tool and provides a graphical user interface as well as web-based interfaces for experienced end users. In contrast to FA³ST NOVAAS is not implemented as a typical code library but rather realized using only Node-RED which might be harder to integrate in other systems.