Keywords

1 Introduction

The results are part of the project “Robotix-Academy” funded by the Interreg V A Großregion (no 002–4-09–001). Furthermore the research is part of the “COTEMACO”-project and funded by the European Union’s Horizon 2020 research and innovation program at ZeMA.

By 2022, up to 4 million industrial robots are expected in industrial companies worldwide with an annual growth rate of 12%. In addition, there is an increasing demand for rentable industrial robot systems or robots as a service, which means that the number of suppliers is also rising. ABI research [2] forecasts that by 2026 up to 1.3 million “Robot as a Service” (RaaS) systems will be in use. Due of the temporarily shut down of entire production facilities in the context of the Covid-19 pandemic, robot systems and automation solutions are gaining more attention for several industries. This could lead to an increase in the number of and demand for robotic systems. [2, 3, 12, 17].

In case of Robot as a Service, the customer will no longer buy the robot system, but will rent it for a certain period of time in order to counteract bottlenecks, staff shortages or increased demand for a product. The customer only wants to pay for the robot service time, or per part produced, that is actually used, in order to ensure a return on investment for the customer. Especially in small and medium sized enterprises (SMEs) a robot system in assembly does not produce continuously like in a large company [7].

The company benefits from renting instead of buying with lower initial investment costs, no long-term commitment to the system, no costs incurred when the robot system is shut down and no maintenance work or costs. To a certain extent, the robot rental business can be compared to a car rental business. One major difference is the commissioning. Whereas a car only requires a key and driver to drive off, the robot system in addition requires considerable programming effort. Therefore, robot rental companies usually offer various applications (palletizing, material handling, welding or machine tending) that are compatible with the system [1, 9].

A further issue for the hiring company is the clarification of the question of responsibility in the event of failure, downtimes and ensuring that the contractually agreed working hours or produced parts are observed. On the one hand, the lessor of the robot system does not want the hirer to work with the robot more than contractually negotiated. On the other hand, the lessor must be assured that in the event of a standstill or failure, the fault for the failure or the standstill is attributable to the lessor. Only then, a tenancy agreement be concluded in a legally secure and holistic manner.

The question of responsibility could, for example, be clarified by collecting and storing process-relevant data, logs and events. This process-relevant information is stored on a data storage device (PLC, hard disk, database, cloud) and can be used to determine the invoice amount. This point requires mutual trust between tenant and lessor, as the entered and generated data is not stored in a manipulation-proof manner. This means there is a chance that the data on the data storage device will be changed after the conclusion of the contract or, for example, in the event of a fault.

In the context of this article, a concept developed at ZeMA is presented, which shows how this trust could be generated with a data storage device without reducing the accessibility of the data. An approach of a manipulation-proof database with the coupling of a payment model is presented. Blockchain offers and combines these two functionalities in one platform, but will not considered as the superior solution at this state in the areas of manipulation-proof database and payment models.

For implementation, the potential advantages of blockchain as a tool are applied to the use case Robot as a Service, also considering the disadvantages of blockchain. Advantages of blockchain are data and process integrity for risk reduction, potential for transaction processing and verification and automated business transactions using smart contracts. Further advantages are transparency and pseudonymity, which can also be seen as a disadvantage of blockchain. E.g.: This means that every participant has an encryption key when uploading transactions transparent but encrypted to the blockchain. If the key is stolen by a stranger, he can accordingly trace what and when the participant uploaded something to the blockchain (pseudonymity) [4].

Due to a possible transaction processing, the data, events and logs of a robot can be directly linked to a digital currency, which will not be discussed in detail in this article. The focus is on the manipulation-proof storage of process-specific data and a payment concept for the control and release of a robot system. The service business model “Rent-a-Robot” is regarded as given and not further researched.

2 State of the Art and Initial Situation

This article links the blockchain topics with the business model of renting a robot. In the following, blockchain and Rent-a-Robot/Robot as a Service will be examined more closely in order to define the basics and points of contact of the article with the state of the art.

2.1 Rent-a-Robot and Robot as a Service

When researching the literature, it is particularly noticeable that the topic of Robot as a Service has a strong industrial relevance, but only few scientific articles have been published on it so far. Considerably more articles have been published in scientific journals or blogs on this topic. These are examined in more detail below.

Rent-a-Robot or Robot as a Service is part of the “as-a-Service” philosophy and consists of the components of a service system as well as a service business model to reflect the rental business. Service systems can be industrial robots, driverless transport systems or even entire robot cells. During the loan transaction, fees can vary from a fixed continuous value to a variable value based on the service duration or number of products. This ensures that no further costs are incurred if the rented system stops operating and the service provider is responsible for maintaining and ensuring availability. This is warranted within the framework of a Robot as a Service—Service Level Agreement (SLA) [3, 14, 19].

The idea or vision of Robot as a Service is to integrate cloud-based “robot rental” systems at the user's premises for the required assembly processes with on-site robot hardware and cloud-based programming. This allows systems to be adapted to changing requirements without having the necessary infrastructure in advance. Users are therefore able to quickly expand or redesign their production and reduce pre-production costs. In addition, the cloud connection allows, for example, the robot operating time to be monitored and data to be stored [1, 14].

In the project “Rent-a-Robot”, the consortium around Schuh et al. [3] has dealt with the consistent conceptual design for the temporary automation of assembly activities. On the one hand, a modular robot assembly system suitable for industrial use is described and. On the other hand, methods for evaluating, planning and designing the required operator models are developed. This should ensure a quick cost calculation and selection of an operator model when a system is requested. Flexible costs during the runtime of the system as well as data collection and storage on a manipulation-proof medium in order to have a basis for decision making in case of downtimes were not considered [3].

READY Robotics, RobotWorx, Hirebotics or Essert are examples for companies that offer robots for rent. They offer robot cells with or without pre-defined tasks for rent. The collection and storage of data on service lifetime and workload is done sporadically. Payment methods are pay-per-hour, pay-per-week or pay-per-use. The problem and starting point of this article is a concept for the manipulation-proof storage of process-relevant data for a well-founded assessment of the costs incurred [1, 6, 9].

2.2 Blockchain and the Alternative IOTA

Blockchain technology is a type of Distributed Ledger Technology (DLT), in which transactions are bundled together in blocks (see Fig. 1. DLT forms the basis for innovative applications such as crypto-currencies, identification possibilities, machine communication or smart contracts, with which orders can be automatically triggered or contracts concluded. Blockchain represents a distributed, manipulation-proof, time-stamped database. The transactions and data are protected against manipulation using cryptographic procedures and consensus algorithms. Each transaction is encrypted by a so-called hash. In addition, each network participant is regularly provided with an updated transaction history, which means that 51% of the network would first have to be “convinced” in case of attempted manipulation. This is because each block in the blockchain refers to the previously completed block (see Fig. 1) [8, 10, 18].

Fig. 1
figure 1

Data structure of a blockchain [16]

Full size image

The blockchain technology is based on five basic principles: Distributed data bank, peer-to-peer data transmission, transparency through pseudonymity, irreversibility of recordings and computerised logic. Not each of these basic principles bring only advantages. Once something is uploaded in the blockchain, it is difficult to remove the data or messages. Furthermore, not every company wants to have company related data stored in a public accessible database. These problems are taken into account when implementing a blockchain based payment model and independent secure documentation for a Robot as a Service[1, 11].

Based on the characteristics of the blockchain technology, Chowdhury et al. [5] analysed under which aspects a blockchain or a conventional database is more reasonable. Blockchain is considered to be the better solution for confidence building, robustness and validity of the data. For confidentiality and performance reasons, the traditional database is better. [5].

The low performance is due to the straightness of most blockchain technologies. To achieve better scalability and thus performance, IOTA is used as alternative with their Directed Acyclic Graphs (see Fig. 2). IOTA is not an acronym for IoT, but is a proper name and based on the smallest Greek letter in the alphabet. Instead of bundling transactions into blocks and chaining them together, IOTA links transactions as nodes in a graph. IOTA is subject to the basic idea, advantages and characteristics of blockchain and is also often perceived as a blockchain. Accordingly, IOTA is seen as a kind of modification of the blockchain.

Fig. 2
figure 2

IOTA directed acyclic graph according to [13]

Full size image

Furthermore, IOTA allows zero-value data transactions, which means that the transactions can be used for pure data exchange or data storage. Masked Authenticated Messaging (MAM), which is a data communication protocol and publishes encrypted data streams, called channels, in transactions in the tangle, is used for this purpose. The Tangle is shown in Fig. 2 [13, 15].

3 Concept for Expanding the Business Model Robot as a Service with Blockchain

In order to create a fundamental trustworthy basis for the hiring of robot systems, existing concepts and business models of Rent-a-Robot/Robot as a Service will be combined with blockchain. IOTA is used as “blockchain technology” to counteract the disadvantages of scalability and performance of other blockchain technologies. By using IOTA, the disadvantages of the previous business model of Robot as a Service, such as validity and the manipulation-capable storage of data, are to be avoided. The concept is intended to map Robot as a Service more economically.

In the case of rental transactions, static and dynamic costs can arise during the rental period. The static costs can be calculated in advance, which Schuh et al. have already researched in the project “Rent-a-Robot” [3] for robot rental. Until now, the dynamic costs and the effects of failures, malfunctions or non-compliance of contract numbers on the final cost calculation were not or only partially considered.

This is where the concept developed at ZeMA takes effect. In order to offer a dynamic rental model, process-specific and -relevant characteristics, data as well as logs and events, e.g. in case of malfunction or failure, must be validly stored. Process-relevant data are operating time, production turnover, sensor data as well as safety data in case of an emergency stop. Furthermore, information which is used as a basis for decision-making, e.g. for cost calculation, must be stored in a more manipulation-proof manner. This way, well-founded and legally binding statements can be made if the contractual objectives are not reached. In case of malfunction or damage, the question of responsibility can be clarified via the data. Figure 3 shows the necessary components and links between them to extend the Robot as a Service use-case with IOTA.

Fig. 3
figure 3

Extended Robot as a Service use-case with IOTA

Full size image

Starting from the robot, the concept for the extension of existing technologies with blockchain using the example of Robot as a Service uses a single-board computer (e.g. Raspberry Pi), a database, a web dashboard and a connection to the IOTA Tangle. The single board computer is the centre point and forms the interface between the blockchain technology (IOTA Tangle), the robot and the database. The single board computer should be a universal interface to IOTA and should also be useable for other systems and databases. This creates a certain modularity and theoretically allows to use any infrastructure (machine, database). Through the connection, each robot gets its own virtual wallet, which can be used to implement a pay-per-use model and to store process-relevant data in a manipulation-proof way. These two scenarios are presented in more detail below. Finally, the web dashboard serves as a control centre for the systems in use by managing and monitoring process data and payments.

3.1 Pay-per-Use Via Crypto Currency

Pay-per-use in itself exists and already functions in the rental business. The novelty is that the blockchain technology allows to automate the rental process. The robot is equipped with an IOTA wallet through the single-board computer, which is used for payment. By means of activities with a value, the costs can be tracked in an automated, manipulation-proof and transparent way. If the hirer wants to use the robot, he has to pay accordingly with the certain valence. This could be implemented time-based as well as product number-based. The renter pays only as long as he produces with the rented machine. Figure 4 shows how this model could be implemented on basis with IOTA.

Fig. 4
figure 4

Payment for production authorization executed with IOTA

Full size image

Initially, payment via the web dashboard is managed by the lessor. In the web dashboard, transactions to the robot can be viewed. Moreover, addresses for handling payments can also be managed in the web dashboard. The transmission of a new address is triggered with the web dashboard and communicated to the robot via a MAM channel. This ensures an automated transmission. The hirer can use the address associated with the robot to pay accordingly. After payment, the hirer is able to move and produce with the robot. If no payment has been made, the rented robot system is on-hold and waits either for a new address or payment. This results, the hirer only pays if the robot is used. In the meantime, it is also checked whether a payment is expected. If this is the case, the robot is authorised to move. It sends and documents a confirmation to the IOTA MAM channel (see Fig. 5).

Fig. 5
figure 5

Robot authorized to move through IOTA

Full size image

For the payment history, further data on the executed process is optionally recorded after the robots movement has been authorised. In the first step, the process-relevant data (robot data, sensor data) are stored in the database. In the second step, the single-board computer polls the database at regularly definable intervals and writes the data in a specific MAM channel in the IOTA Tangle. In this way, the payment history can be stored directly linked to the process-relevant data in a manipulation-proof manner.

3.2 Independent Data Certification for Manipulation-proof Documentation of Process Data, Events and Logs

A disadvantage of this storage method for process- and company-relevant data is the transparency and pseudonymity of the block chain technology. Not every company is willing to store sensitive data in a publicly accessible database. Therefore, two options are presented below, one using the blockchain technology as pure data certification and the other using blockchain as a database. Figure 6a shows the two options.

When information is uploaded, a unique non-changeable hash of this information is formed. If the information would be uploaded again at a later time, the hash is still the same as when it was first uploaded. If the information is manipulated, the two hashes would be different. Accordingly, the hash can be regarded as the unique signature of the information. With option one, the single board computer retrieves the corresponding data from the database, generates a hash and stores it in the blockchain. Whereas with option two, the corresponding data from the database is stored directly in the blockchain. Both options ensure that the data is stored in a certified way. The advantage of the first option is that the data is not uploaded. The advantage of the second option is that the data could theoretically be released directly, as they are already available in the IOTA tangle.

For maintenance, checking or billing purposes, the logged data can be accessed via the Web Dashboard (see Fig. 6b). The Web Dashboard reads the process data from the database and from the IOTA MAM channel. By comparing the two data sets from the different storage media, an integrity check can be performed to guarantee the authenticity and that the data is not manipulated. The data and the integrity check are displayed in the Web Dashboard. In addition, the stored hash from the IOTA MAM channel with the newly created hash of the data from the database could also be used for the integrity check.

Fig. 6
figure 6

a Robot logging activity; b Access to logged data and data integrity check; with IOTA

Full size image

4 Conclusion and Outlook

In the article a concept was presented that with blockchain a technology under development can add value for already existing use cases, in this case Robot as a Service. A modular approach was chosen to apply the presented concept to other industries and systems. The aim of the implementation was to increase the confidence in the generated process specific data of Robot as a Service without reducing the accessibility of the data. An approach to combine the resulting dynamic costs and pay-to-use with the blockchain crypto currency was also presented. This was implemented with IOTA, as it offers advantages in terms of scalability and performance compared to other blockchain technologies. Other blockchain technologies also offer features such as the manipulation-proof storage of data and could be applied.

Although blockchain has promising properties, more attention must be paid to the development of the technology in the coming years in order to realise an industrial application of the technology. At the moment, there are good approaches, but some questions and undesired peculiarities for the industry, such as transparency and pseudonymity of blockchain as well as strongly fluctuating exchange rate of the crypto currency, have not been clarified. Blockchain still has to find its benefit to existing technologies. Furthermore, Blockchain and IOTA should always be seen as a tool to solve a problem.

Especially the point that many blockchains have a fluctuating price of its cryptocurrency must be considered. Therefore, from an economic point of view, it is extremely difficult to implement an automated payment or pay-per-use model via blockchain technology. At the moment, it makes more sense to use the cryptocurrency as a fictitious currency like a token system to link process data, events and logs (e.g. operating time, produced parts) with a valence. The links between the token and the data can be used for automated invoice generation.

Nevertheless, the concept offers a high potential to extend existing technologies and to create added value. The next step is the further concretization of the concept and its application to a use case and a demonstrator. Thereby, further approaches and weak points shall be defined in order to make it usable for industrial application. Furthermore, the modular aspect is to be extended to cover a larger number of use cases, especially for assembly activities.