Keywords

1 Introduction

One of the key factors in Industry 4.0 is the availability of data and information about industrial machines, components and products at all times over an asset’s life cycle. Assets represent physical or logical things that hold a value for the owning organisation. The Asset Administration Shell (AAS), as an industrial interpretation of a digital twin, is the new data centre for industrial assets. To exploit the full potential of data throughout the asset’s life cycle, the linked AAS enables the communication and stores all relevant information about the asset. These can be e.g. construction data of a machine, process data coming from the installed sensors of the machine or a description of executed process steps [2].

With a standardized, safe and secure data exchange between different organisations, data can be made available for all value chain instances [14]. The challenge is the infrastructure that stores and administrates the AASs and makes these available to other parties in the value chain. Different asset owners or users should be able to access the information stored in the AAS or, depending on the life cycle phase, submit new relevant asset describing information to the AAS [15]. The connection of the information stored in the AAS to the information systems and processes of the respective companies should be as seamless and automated as possible. In practice, this means that today’s centralized IT systems of companies hosting the AAS instances should enable ad-hoc connections to the systems of other companies and enable them to access and to edit the respective AAS. From a practical and pragmatic point of view, this seems to be almost unthinkable, at least for security reasons.

This would be remedied by a common infrastructure allowing industrial enterprises and potential value chain partners to collaborate and directly exchange information in a secure and trustworthy way. The technology that makes this possible should meet industrial requirements like availability, integrity, confidentiality, scalability and efficiency to be accepted and provide a transparent life cycle documentation of the assets [6, 12].

With Distributed Ledger Technology (DLT) it is possible to create a open decentralized data base of performed transactions between different organizations. Behind DLT is the idea of a distributed system in which the participating parties are on an equal level and can interact directly with each other. Each network node holds an identical data base. The algorithms of the nodes ensure that newly added information is distributed throughout the entire network. The consensus mechanism ensures that the nodes agree on the current state of the data base. To add new a data transaction to this data base, a node has to validate previous transactions by a cryptographic function. Once a transaction is validated, it is not possible to alter this without also manipulating all validating transactions, which are also stored on the other nodes of the distributed ledger. Therefore, no central organisation needs to be involved to guarantee the immutability of the transactions [24]. Accordingly, the data exchange with DLT can provide a transparent and traceable transfer of the data between different organizations [29].

These technologies can be used to realize the Industry 4.0 use case of Value Based Services (VBS) and Transparency and Adaptability of delivered Products (TAP) [4, 11]. Therefore, trustworthy data directly coming from the supplier can be used to track the product quality. Additionally, several product life cycle steps can be stored tamper-proof in the DLT to provide more transparency in the supply chain or send feedback with usage data about assets back to the producer.

This paper discusses, whether DLT can meet mentioned above industrial requirements and improve the data exchange considering security and data integrity aspects as well as provide an exchange solution for the complete product life cycle.

2 Background

The following section describes fundamentals about the AAS and DLT in the context of industrial automation.

2.1 Asset Administration Shell: Fundamentals

The development of the concept of the AAS is still in progress. However, a DIN specification [10] describes the basic concepts of the AAS as follows:

An asset and an AAS together form an Industry 4.0 component. If a product, described in an AAS type, is produced several times, several AAS instances with unique identifier are created. To avoid entire copies of identical elements of AASs, several AASs can refer to each other, like the individual AAS instances can refer to the identical AAS type. Via further modularisation of AASs, different organizations of the value chain can store different information like confidential engineering data held back by the manufacturer or confidential production data held back by the producer [5].

An AAS can be stored on the embedded storage of an asset or in an external repository and has different communication capabilities. For instance, some assets, like PLCs, can store data and the AAS on a local storage and communicate actively by logging in to a network of AASs to exchange information. Other assets, like sensors, can not store, but provide data. Lastly, an asset, like mechanical component, has neither embedded storage nor communication capabilities, but can provide data stored in the AAS on a repository [10].

The data in an AAS is separated in several submodels with submodel elements. This makes it possible for supplier and manufacturer of parts of the asset to add particular data during the asset’s life cycle and follow the standardized structure of the AAS [30].

2.2 Distributed Ledger Technology

The key security aspects for data exchange between AASs are availability, integrity, and confidentiality [10]. Additional objectives like scalability and performance of DLT are reviewed in this chapter.

Availability

One of the most important aspects for manufacturing industries is to not have down times in the production caused by errors which can be avoided by early detection and handling or redundancy of components [6]. The availability of the network is a crutial advantage of DLT. The decentralized network replaces single server architectures that present a single point of failure [27]. With the network of nodes storing the distributed database, the probability that a node is available to receive or provide the data increases with every node in the network. Also, in case of local data loss, there is always an identical copy of the distributed ledger on the other nodes in the network [13].

Integrity

For data that is once added to the distributed ledger, a high effort for manipulations is necessary, as there are local copies of the ledger on the other network nodes, that would have to be changed. Additionally, each transaction is referring to previous transactions by adding a hash value of these. If one transaction is manipulated, all referring transaction also need to be edited, as the hash values would change.

Nevertheless, the integrity of different DLTs can vary. Hence, it is important to choose a DLT with the right integrity characteristics. For some DLT there were manipulations, where a single entity could control more than 50% of the validating computers in the DLT network and thus approve and reject transactions [3].

A weak point for manipulations is the transition from real world values, like a temperature value, to the value in the distributed ledger. If already manipulated or wrong measured data is added to the distributed ledger, this can not be detected by the DLT [32].

Confidentiality

In contrast to the high availability, industrial organizations can see the distributed storage as a disadvantage in the view of confidentiality. The data can be protected through encryption before adding it to the distributed ledger [11]. However, for the encrypted data, there is the threat of deciphering. As a result, the companies do not have the control about the local copies of the ledger on all the other nodes. To minimize the threat of deciphering, strong and quantum-proof encryption algorithms should be used.

Scalability and Performance

A big and often mentioned challenge of DLT is the scalability due to waiting time for validation of transactions and the acceptance of a transaction by all other nodes. Also, the energy consumption due to the necessary computing power for the validation of new transactions can be high for some DLT, like Bitcoin [33]. For creating blocks and storing transactions, a fee is often charged in public blockchains, which requires the purchase and handling of a Cryptocurrency.

Some newer DLTs, like the IOTA Tangle as in implementation of a Directed Acyclic Graph (DAG), aim to overcome the cost and scalability limitations of blockchain. The Tangle has not a single chain like a Blockchain and thus can add several transaction parallel, which raises the number of possible transactions in a defined time. Instead of several miners trying to validate each block, in the IOTA network every node has to validate two previous transactions to add a new transaction to the distributed ledger. Thus, there is no extra fee for the validation of new transactions, executed by other nodes, required [8, 25].

Another challenge is the increasing demand of memory for the DLT because of the several synchronized local copies of the ledger [22]. The scalability, performance and memory consumption highly depends on the chosen DLT.

3 Model Architecture

The following chapter shows the state of the art in using AASs and DLTs and presents the proposed idea to combine both concepts for a cross-company data exchange solution.

3.1 Current State

Using AAS

One way for the cross-company exchange of data stored in an AAS, is to forward the whole AAS as an XML- or JSON-file or in the AASX format, a file format for AASs following the Open Package Conventions standards. To gather the data for the AAS, the organizations can use AutomationML in the engineering phase and OPC-UA during the operation phase, as suggested in [5]. For the direct interaction between two active AASs, OPC-UA, HTTP-REST and MQTT are proposed [7]. But, as companies fear to lose control over the data access [14], the IT infrastructures are often isolated from the internet and the cross-company data exchange is limited.

Another way for the communication between AAS are platforms such as Industrial Marketplace based on the DLT IOTA [17, 25]. On this decentralized marketplace, AASs of independent organizations can autonomously interact with each other by requesting and providing services like calls for proposals using IOTA transactions [8].

Using DLT

Independent of AASs, DLT can be used to track and trace products in the supply chain [23]. With the decentralized solution and immutable record of data transactions, transparency is provided in the complex and global system of suppliers to proof the origin of each part of a product. Therefore, each product has a unique digital profile to store all life cycle data directly in the DLT and make it accessible for all involved stakeholders. This can include ownership of data, time stamps, location data, product specific data, environmental impact data and many others [1].

Reference [9] shows in a concrete example of a fine cutting press, how DLT can be used to store data about the product in the IOTA Tangle to create a digital twin of the product. This can be used as a certificate of origin for each asset, prove the fulfilment of standards, or prevent double quality inspections due to not shared data (Fig. 1).

Fig. 1
figure 1

Architecture

Full size image

3.2 Proposed Idea

In this chapter, a solution for the data exchange with the AAS combined with DLT is proposed. This is leading to a new possibility to record an asset’s life cycle in the instance phase. The solution can be used as an additional protocol to the existing ways of AAS exchange between organizations and extends the tracking and tracing with DLTs.

In the considered scenario, the asset exists as a physical product. Now, further processes on the asset and the transportation of the asset need to be executed by different involved companies. Meanwhile, the AAS instances, with individual information about each asset, are stored on a remote repository and the AAS type, containing general construction data about the asset, can be stored in the file systems of the different involved companies, who process the assets. The asset does not have to have communication capabilities, but the AAS has an API to collect the life cycle data from production and transportation [7].

Every AAS has an identifier, for instance an address, to receive data transactions in the distributed ledger. This identifier can be stored in different ways, such as RFID chip, NFC chip or simply printed as a QR-Code on the product itself [1]. By scanning the chip or code, every actor in the supply chain can send data to the AAS by sending it to the identifier in the distributed ledger. Afterwards, at any point in time, the AAS can access the data in the distributed ledger to add it to the AAS in the repository.

To provide confidentiality, all data transactions can be encrypted with a public key, that is also stored on the RFID chip, NFC chip or QR-Code. While accessing the data from the distributed ledger, the AAS can decrypt it with the private key stored in a separate submodel. Public, and not encrypted, data can be stored directly in the distributed ledger and is available for all actors in the supply chain [1].

The data structure in the transactions should follow the AAS meta-model. Therefore, a transaction can contain a submodel with the data. Furthermore, the API should follow the definition of the “Details of the Asset Administration Shell” document series [5].

Besides the advantages in using standardise AAS as a digital twin and storing data in a distributed ledger to provide a high integrity, the proposed solution enables the AAS to use the DLT as buffer and access the data in an asynchronous manner at any point in time without the threat of manipulation in the meantime. Furthermore, the data supplier can always add the data without establishing a direct connection to the AAS in the repository using HTTP-REST or OPC-UA. In the same way, other organizations in the value chain can access the latest submodels of the AAS instance directly from the distributed ledger. It is even possible to add and access the data, if the AAS is stored locally on the asset itself, which may be unavailable during transportation or transfer of ownership.

The communication with the DLT can also be used, to send feedback to the producer during the utilisation phase of the product and use this data to improve future products or to offer value-based services [10, 31].

4 Implementation

For a proof-of-concept, the IOTA Tangle [25] is used as a DLT and the BaSyx framework [28] for the AASs. Therefore, the IOTA Java client library is integrated into the BaSyx SDK to use the IOTA API.

The example supply chain consists of a Versatile Production System (VPS) in the SmartFactoryOWL [26] consisting of four production modules responsible for the following operations: “Delivery”, “Storage”, “Dosing” and “Production” (see Fig. 2). Each station has an OPC-UA-Server providing status data about the stations. Additionally, each station has an AAS with an OPC-UA-Client to receive the data from the stations and an IOTA-Client to send IOTA transactions. On a remote repository, there is an AAS instance of the asset which can receive the transactions from the stations via the IOTA API.

Fig. 2
figure 2

Versatile Production System (VPS) in the SmartFactoryOWL [26]

Full size image

The distributed IOTA network consists of a peer-to-peer network of nodes. To connect a client to the IOTA network to send and receive transactions with the data from the distributed ledger, the specific client application should be connected to one of the public nodes. Every transaction is sent from the client to the node to attach the transactions to the distributed ledger, which is called Tangle for IOTA. The transactions with their validation status can be seen in the IOTA Tangle Explorer [18].

During the production process, the four AASs of the stations receive the data via OPC-UA and pack the data in submodels, whereas the data can be of a primitive data type or String. These submodels are converted into JSON Strings and sent as a message of a non-value-transaction to the IOTA address of the product’s AAS. By doing so, the data is added to the distributed ledger.

In any point in time, the AAS of the product can check its address for received transactions independent of the transaction send time. The transaction can be read from the distributed ledger, the message with the JSON String of the submodel extracted and then added to the AAS. Additionally, the bundle-hash of the transaction in the Tangle is added as a second submodel element to the received submodel. Thus, in a later point in time, the bundle-hash can be shared to find the transactions with the submodel in the distributed ledger.

5 Evaluation

As the used IOTA client library is in beta status and the node software to run the IOTA network is not in the final version, a detailed evaluation will not be executed here. For now, the developed software runs stable and the time until a sent transaction is confirmed takes only several seconds. Also, the request to read transactions from the Tangle is done within seconds. In the Tangle Explorer [19], everyone can search for a bundle-hash or address and see every associated transactions. To increase privacy, an AAS could use multiple addresses to receive the data.

The message length in each transaction is limited. In case, the JSON String with the submodel exceeds the message length, it is automatically split in multiple transactions combined as a bundle. As IOTA uses the ternary instead of binary system, every message is converted into trytes. One tryte consists of three trits which can each have one of the three states − 1, 0 and 1. Thus, IOTA uses an alphabet with 33 = 27 character. In doing so, two trytes equal one byte. The maximum length of message in one transaction is 2187 trytes [16], which is equal to 1093 byte of data respectively a submodel JSON with 1093 ascii character. Non-value-transactions also do not contain a sender address, so that a solution to identify the sender of a transaction needs to be implemented.

By using the client library, there is no need to run a local node. In that case, the client depends on other nodes to store the transactions. To avoid that, everyone can setup and run a node on a local device. Nevertheless, the memory demands of the Tangle can grow quickly with the increasing number of transactions performed in the network. Therefore, IOTA is working on a framework called “Chronicle” to let a node, then called “Permanode”, only store transactions that are relevant for the user [20, 21].

An advantage of IOTA are the Client Libraries written in many different programming languages like C, Go, Java, JavaScript and Python for an easy integration in existing projects [20].

6 Discussion

With a DLT as the decentralized data exchange platform, the exchanged data is stored tamper-proof in a distributed ledger. Especially audit-relevant data and data that requires a high integrity, like security- and safety-relevant data, can be sent to the AAS by using the DLT as an interface. Consequently, not the whole life cycle data needs to be stored in the distributed ledger to limit the memory demands of the ledger. The AAS is still the information center for all data and the DLT can be used to proof the existence and correctness of single submodels with the reference to the transaction in the distributed ledger.

Due to the fact that a customer already can store the AAS on his server even before the asset arrives in his organization, he can access all information about the product in his own file system. In any point in time, he can also check the distributed ledger for new data and monitor the production- and logistic-status of the asset.

On the other hand, the supplier and logistic organizations in the supply chain do not have to handle the AAS instances of the products in their IT systems. Also, no direct connection between suppliers and AASs on another server is necessary, as they simply can send their data to the highly available decentralized network. The other way around, other companies in the life cycle can always access the newest submodel from the distributed ledger. This is even possible, if the AAS instances are not available and can prevent production stops due to not available AASs. The DLT as a central, but decentralized, exchange point buffers and stores the transactions and the target AAS can access this data later.

There is no dependency on third parties as central instances to trust and the companies with the AASs on their server do not have to unblock their IT systems for many connections. They only send and receive transactions to and from the distributed ledger. All involved actors like supplier, customer, audit organizations, and product certification authorities share the same state and can trust the same database.

However, the limited amount of data per transaction needs to be taken into account. At the same time, a solution to manage the high amount of data that is stored by all participating nodes in the network needs to be developed. Therefore, the DLT should mainly be used for data which needs a high integrity and not storing the whole AAS in the distributed ledger. Another option would be to store the data off-chain in another database and use the distributed ledger only to transfer a checksum of the data to avert the manipulation and guarantee the integrity [6].

Also, the proof-of-concept runs without encryption and the identification of the transaction sender is missing. Thus, incoming transactions should be checked for malicious content.

7 Conclusions

The proposed idea shows a new solution to improve the data exchange across different organizations in the supply chain of assets. The DLT as an open network, enables every actor in the supply chain to send data about the asset’s life cycle to the AAS instance. This data can be accessed by the AAS and added as a new submodel. With the reference to the transaction in the distributed ledger, the integrity of the submodels is guaranteed and the data can be used to prove the compliance of quality standards. In addition, other organizations in the supply chain can directly access the submodels in the distributed ledger.

A proof of concept with IOTA as a DLT was implemented and evaluated in the SmartFactoryOWL in Lemgo [26].