Marietheres Dietz

Benedikt Putz

Günther Pernul

A Distributed Ledger approach to Digital Twin secure data sharing

Keywords: trust frameworks, distributed systems security, distributed ledger technology, digital twin

The Digital Twin refers to a digital representation of any real-world counterpart allowing its management (from simple monitoring to autonomy). At the core of the concept lies the inclusion of the entire asset lifecycle. To enable all lifecycle parties to partake, the Digital Twin should provide a sharable data base. Thereby, integrity and confidentiality issues are pressing, turning security into a major requirement. However, given that the Digital Twin paradigm is still at an early stage, most works do not consider security yet. Distributed ledgers provide a novel technology for multi-party data sharing that emphasizes security features such as integrity. For this reason, we examine the applicability of distributed ledgers to secure Digital Twin data sharing. We contribute to current literature by identifying requirements for Digital Twin data sharing in order to overcome current infrastructural challenges. We furthermore propose a framework for secure Digital Twin data sharing based on Distributed Ledger Technology. A conclusive use case demonstrates requirements fulfillment and is followed by a critical discussion proposing avenues for future work.

Introduction

Hardly anything has revolutionized society as much as digitization. At its beginning, data from everyday life was captured and stored digitally. After reaching significant amounts of digital data, recent years have been devoted to gaining relevant insights into data by leveraging Big Data Analytics, Artificial Intelligence and so on. A next step in digitization is now emerging in the form of the Digital Twin (DT) paradigm.

The Digital Twin refers to a digital representation of any real-world counterpart, at most times an enterprise asset. Its core building blocks are asset-specific data items, often enhanced with semantic technologies and analysis/simulation environments to explore the real-world asset digitally. The DT thus allows management of such an asset ranging from simple monitoring to autonomy. An essential part of the concept is the inclusion of the whole asset lifecycle. To integrate

The first two authors have contributed equally to this manuscript.

all lifecycle participants, the DT should provide comprehensive networking for its data, allowing it to be shared and exchanged [4].

Although the DT concept certainly advances digitization, it nevertheless poses new challenges in terms of IT security, especially in industrial ecosystems [START_REF]Overview of cyber vulnerabilities[END_REF][START_REF] Rubio | Analysis of cybersecurity threats in industry 4.0: The case of intrusion detection[END_REF]. Most notably, security must be maintained during the exchange of DT data between different, non-trusting parties. For instance, consider the DT of a power plant. Synchronizing tasks between twins should uphold integrity to avoid manipulated operations on the power plant. Also, involved parties should not be able to read every shared data element (e.g. the manufacturer of the power plant need not know the plant's current status), resulting in confidentiality requirements. To the best of our knowledge, current DT frameworks do not permit secure data sharing. Bridging this gap, our work provides a framework introducing security-by-design in DT data sharing.

To achieve this goal, we consider Distributed Ledger Technology (DLT). DLT is the umbrella term for distributed transaction-based systems, shared among several independent parties in a network. Distributed Ledgers have built-in mechanisms for access control and asset management, including authentication and authorization mechanisms. We focus on permissioned distributed ledgers, which target enterprise usage by restricting access to fixed set of independent and semitrusted participants. One of the main reasons for using a Distributed Ledger is disintermediation, replacing the need for trust in a third party or central operator through a replicated and integrity-preserving database. Inherent transparency and auditability are additional advantages over centralized solutions. Due to these properties, DLT is uniquely suited to solve the challenges of DT secure data sharing.

Accordingly, this work proposes a framework for secure DT data sharing across an asset's lifecycle and collaborating parties based on DLT. We contribute to the body of knowledge by offering a solution without a trusted third party (TTP) based on security-by-design. The remainder of this paper is organized as follows: Chapter 2 introduces the background of our work. Afterwards, we proceed to the description of the current problems in DT data sharing and name the resulting requirements for secure DT data sharing (Chapter 3). In Chapter 4, we provide a framework for secure DT data sharing for multiple parties based on DLT. To show practical relevance and the functionality of our framework, a use case is provided in Chapter 5. In Chapter 6, we evaluate our approach in terms of fulfillment of the stated requirements. To conclude, Chapter 7 sums up the main contributions and gives an outlook for future work.

Background

At present, the Digital Twin phenomenon is still in its infancy. Nevertheless, implementation and design of this concept are addressed to date, especially in the area of Industry 4.0. With strong focus on the industrial domain, the major part of research suggests DT implementation through AutomationML-formatted descriptive data of the real-world counterpart, e.g. [START_REF] Schroeder | Digital Twin Data Modeling with AutomationML and a Communication Methodology for Data Exchange[END_REF][START_REF] Banerjee | Generating Digital Twin models using Knowledge Graphs for Industrial Production Lines[END_REF]6]. The XML-based AutomationML (AML) format describes industrial assets and provides objectorientation for modeling the asset's physical and logical components [START_REF] Schroeder | Digital Twin Data Modeling with AutomationML and a Communication Methodology for Data Exchange[END_REF]. Eckhart and Ekelhart [6] propose a framework for using a DT's simulation mode for security purposes such as pen testing. While these works focus on an initial development of a DT, the consideration of data sharing functions are still missing. However, exchanging data is vital for enabling the lifecycle integration and collaboration [4]. Our work builds on existing DT propositions, resulting in a concept that can be applied in a complementary way to enable secure DT data sharing.

Regarding DT data sharing, both the communication between lifecycle parties and the bidirectional communication between the DT and its real-world asset counterpart need to be considered. Bidirectional communication consists of the DT's instructions for the asset and the asset's status update for the DT. To uphold integrity among multi-domain DT models, Talkhestani et al. [START_REF] Talkhestani | Consistency check to synchronize the Digital Twin of manufacturing automation based on anchor points[END_REF] offer a solution. They detect model changes by applying anchor points, and upon detection synchronize the DT while keeping model dependencies consistent. However, this includes drawbacks such as the manual creation of anchor points and reliance on a Product Lifecycle Management (PLM) system, while our solution offers platform-independence. Security aspects, such as the guarantee for all lifecycle partners to access the data while upholding confidentiality, are not considered to date, but integrated in our solution.

DT management is a form of enterprise asset management, which is one of the prime use cases of Distributed Ledgers [START_REF] Androulaki | Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains[END_REF]. Distributed Ledgers are able to track events and provenance information along an asset's lifecycle and increase transparency for all participants. For example, Litke et al. [START_REF] Litke | Blockchains for Supply Chain Management: Architectural Elements and Challenges Towards a Global Scale Deployment[END_REF] studied the benefits of Distributed Ledgers for different actors in supply chain asset management, a research area closely related to DT asset management. In another study, Meroni and Plebani [START_REF] Meroni | Combining Artifact-Driven Monitoring with Blockchain: Analysis and Solutions[END_REF] investigate how the blockchain technology can be used for process coordination among smart objects. Smart objects are similar to DTs in that they are applied for monitoring physical artifacts. An issue with their proposed approach is that sensor data is also stored on the blockchain, which can be detrimental to performance and scalability. We consider this issue and provide a solution to overcome this obstacle.

Problem statement

On the one hand, DTs should facilitate the access to asset information for different stakeholders along its lifecycle [START_REF] Ríos | Product avatar as digital counterpart of a physical individual product: Literature review and implications in an aircraft[END_REF]. It is a task which enables feedback loops, while stepping towards a circular economy [START_REF] Baumgartner | Nachhaltiges Produktmanagement durch die Kombination physischer und digitaler Produktlebenszyklen als Treiber für eine Kreislaufwirtschaft[END_REF]. On the other hand, the involved parties do not necessarily trust each other, resulting in a confidentiality dilemma. A useful example is given in [START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF]: Two separate standalone DTs exist for a single device instance, one for the manufacturer and the other at the customer site -due to information security reasons. Additionally, current works state that enterprise infrastructures need to overcome the following obstacles to provide secure DT data sharing:

application of different tools [START_REF] Uhlemann | The Digital Twin: Realizing the Cyber-Physical Production System for Industry 4.0[END_REF][START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF] usage of various data formats [START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF] missing standards [4] broken information flow across lifecycle phases [START_REF] Uhlemann | The Digital Twin: Realizing the Cyber-Physical Production System for Industry 4.0[END_REF][START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF] clarification of the ownership of information [START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF] This calls for a holistic approach that provides confidentiality and integrity, two central security dimensions in networks [START_REF] Voydock | Security Mechanisms in High-Level Network Protocols[END_REF]. Figure 1 illustrates DT data sharing and an exemplary set of lifecycle stakeholders. The depicted DT model comprises different capabilities and two types of asset-specific data. Descriptive data refers to static properties of the device and infrequently changing state information. This data is mainly produced by users. Sensor data occurs frequently and should be available in near real-time. It is generated by sensors of the physical asset or in its proximity, which provide valuable information on the asset's environmental conditions. Moreover, data of both types needs to be synchronized with the physical counterpart. Therefore, the sync capability compares the state of the DT to its real-world counterpart and resolves possible discrepancies.

Digital Twin Model

The access control capability provides authentication and authorization modules to enable data sharing of involved parties without hampering confidentiality. The monitoring, simulation and analysis capabilities represent advanced operations of the DT. Depending on the extent of the operations present in a DT, DT status data can be returned to the participant or the real-world counterpart's state can be modified.

The depicted information flows show how information about the physical device is gathered from and sent to the lifecycle parties. Generally, the type of data accessed and shared by the different lifecycle parties depends on the real-world twin, the parties' roles in its lifecycle and thus, the specified access control mechanisms in the DT. The system flows represent necessary bidirectional synchronization between the DT and its real-world counterpart as stated in Section 2. Both flows contribute to making the data sharing activities of the involved parties traceable. This enables feedback from the latest stages of the asset lifecycle to the earliest ones [START_REF] Ríos | Product avatar as digital counterpart of a physical individual product: Literature review and implications in an aircraft[END_REF].

A formal basis for secure Digital Twin data sharing

Although a methodological literature analysis to establish requirements is the state-of-the-art approach, it is currently not sensible to carry out with regard to our research focus. On the one hand, this is due to the fact that only a small number of publications exist. In addition, data sharing has not yet been a focus in DT literature to date. Moreover, security-by-design concepts have not been considered yet. Therefore, we establish a formally valid basis in order to create a uniform understanding of DT data sharing. To derive the requirements, the mechanisms to achieve the central goal of secure DT data sharing have to be examined in detail. Figure 2 illustrates the formal functions required to achieve this goal, which are also described hereafter.

DT Data: We see DT data twofold: At first, there is a set of descriptive data elements D desc := {d 1 , ..., d m } varying from documents to models or analytic outcomes. Its essential data element is the specification of the DT d spec ∈ D desc . The second set contains environmental, device-produced data, namely sensor data D sensor := {d 1 , ..., d n }, whereby D desc D sensor .

Sharing: A finite set of lifecycle parties N := {n 1 , ..., n k |k ≥ 2} can share the respective data elements of D desc (write operation) or access the data elements of D desc , D sensor (read operation). This results in the following necessary functions:

write(n i , d j |d j ∈ D desc ) and read(n i , d j |d j ∈ D desc ∨ d j ∈ D sensor ). Note that 1 ≤ i ≤ k as well as j 1 ≤ j ≤ m if j ∈ D desc 1 ≤ j ≤ n if j ∈ D sensor .
Security-by-design: Security-by-design infers introducing security mechanisms at the very beginning of a system's design [START_REF] Tankard | The security issues of the Internet of Things[END_REF]. In terms of DT data and sharing security, data integrity and confidentiality mechanisms are of special interest. Confidentiality in terms of securing data from view of non-trusted third parties can be reached by access control mechanisms [START_REF] Sandhu | Access Control: Principles and Practice[END_REF]:

authentication: authenticate(n i ) authorization: authorize(read(n i , d j )) authorize(write(n i , d j ))
Integrity of data can be achieved by auditability and traceability of write operations. Given D desc as the origin set of data, D desc is the set of data after a data element d j is added to the origin set. The following functions can cover integrity aspects: auditability:

audit() : D desc → D desc ⇐⇒ write(n i , d j ) ∧ D desc D desc ⇐⇒ ¬write(n i , d j ) traceability: trace() : D desc → D desc =⇒ D desc • D desc
Thereby, auditability guarantees that D desc is transformed to D desc in case of an authorized write operation whereas other operations are not able to transform the data in any way. Traceability ensures that authorized writes of data elements and thus, transformations of D desc to D desc , are chained up. In conclusion, data integrity is ensured as the data cannot be manipulated or tampered with in retrospect.

Requirements for secure DT data sharing

To provide a sound solution for secure DT data sharing, the following requirements were derived from the formal basis and the aforementioned challenges identified in the literature analysis.

R1. Multi-party sharing. To enable lifecycle inclusion, a vital characteristic of the DT paradigm [4], the multiple stakeholders N involved in the lifecycle have to be considered. As described in Figure 1, parties can vary from manufacturer to maintainer. However, all involved parties are pre-registered and therefore determinable.

R2. Data variety support. At the heart of the DT lie the relevant digital artifacts D desc , D sensor , which vary from design and engineering data to operational data to behavioral descriptions [4]. Thus, different data types and data formats [START_REF] Malakuti | Architectural aspects of digital twins in IIoT systems[END_REF] need to be supported during data sharing. For instance, Schroeder et al. claim that using the semi-structured AutomationML format to model attributes related to the DT (d spec ) is very useful for DT data exchange [START_REF] Schroeder | Digital Twin Data Modeling with AutomationML and a Communication Methodology for Data Exchange[END_REF]. In addition to semi-structured data, structured data (e.g. sensor tuples in D sensor , database entries) and unstructured data such as human-readable documents can be asset-relevant and shared via the DT.

R3. Data velocity support. Often, DT data is distinguished between descriptive, rather static data, and behavioral, more dynamic data (see Figure 1). The latter changes with time along the lifecycle of the real-world counterpart [START_REF] Schroeder | Digital Twin Data Modeling with AutomationML and a Communication Methodology for Data Exchange[END_REF]: With each lifecycle stage the asset-related information evolves, resulting in different versions and a dynamic information structure [START_REF] Ríos | Product avatar as digital counterpart of a physical individual product: Literature review and implications in an aircraft[END_REF]. Naturally, dynamic data includes sensor data D sensor -which mostly refers to the actual state of the real-world counterpart [START_REF] Glaessgen | The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles[END_REF]. While the infrequently changing data D desc might not require high throughput, sensor and dynamic data D sensor accrues in intervals ranging from minutes to milliseconds. Therefore, the solution must support high throughput and low sharing latency for efficient sharing of dynamic data -thus supporting data velocity.

R4. Data integrity and confidentiality mechanisms. An important requirement is taking into account data security features, especially integrity and confidentiality. At first, this requirement aims at safeguarding data integrity to avoid wrong analytic decisions based on manipulated data. It can be ensured by audit() and trace() mechanisms. The second main security objective is to avoid confidentiality and trust problems while enabling multi-party participation. This calls for restricted data access dependent on the party through authenticate() and authorize() functions, while ideally keeping the effort for user registration low. Different levels of confidentiality should be possible for different data elements. For instance, D sensor might need a lower level of protection than D desc , as the latter might include sensitive corporate information such as blueprints. Detailed authorize() functions, providing access-restrictions for each data element, can cover this aspect.

R5. Read and write operations. To interact with DT data, a DT data sharing solution must provide read() and write() data operations for the sharing parties. The allowance of operation modes for the data elements should be chosen carefully for each party to ensure R4 (cf. Figure 2). Overall, we do not claim that these requirements are complete. There may be other requirements of importance, but regard these as essential for the following reasons. On the one hand, these requirements were found to be mentioned most often in the reviewed literature, while others were less frequently mentioned and are therefore considered of lower importance (see Section 6.2 for further explanation). On the other hand, the stated requirements were also the main focus in various practitioners reports (e.g. [START_REF] Ovtcharova | Beyond the Digital Twin -Making Analytics come alive[END_REF][START_REF] Usländer | Engineering of Digital Twins[END_REF][START_REF] Greengard | Building a Better Iot[END_REF]) and during discussions with experts.

Solution architecture

In order to develop a framework for secure DT data sharing, we first evaluate the suitability of DLT in Section 4.1. Afterwards, Section 4.2 explains the system architecture and Section 4.3 explains how the various data types are stored. Section 4.4 details the inclusion of the DT capabilities as part of the DLT solution. Finally, Section 4.5 explains the initial setup procedure for our framework.

Technology selection

To develop a solution architecture, we first evaluate different data storage solutions' properties to select the technology best suited to fulfill the requirements.

A centralized solution could be created in the form of a portal, operated by a third party or the operator of the twinned device. This requires trust of the participating parties towards the portal maintainer, as the maintainer could manipulate data or revoke access to the DT for other parties. A distributed approach jointly operated by all participants could solve this trust issue. Distributed Ledgers represent such a distributed solution. They permit verifiable decentralized execution of business logic via smart contracts, ensuring that rules and processes agreed upon by the lifecycle participants are followed.

We evaluate the applicability of Distributed Ledgers to our DT data sharing requirements based on the blockchain applicability evaluation framework by Wüst and Gervais [START_REF] Wüst | Do you Need a Blockchain?[END_REF]. As illustrated in Figure 1, there is a need to store various types of data as part of the DT state. Multiple parties interact with the twin during its lifecycle who do not fully trust each other. These writers are usually known in advance or change infrequently (i.e. the maintenance service provider changes). These characteristics lead to the choice of a public or private permissioned blockchain in the framework [START_REF] Wüst | Do you Need a Blockchain?[END_REF]. In our case, this choice depends on whether public auditability is required or not. While use-case dependent, we focus on private permissioned blockchains for the rest of this paper. If needed, public read-only access to blockchain data can be enabled during implementation for most permissioned blockchain frameworks (i.e. through a REST API).

System architecture

The proposed DLT-based architecture for secure DT data sharing is shown in Figure 3. Every participant runs three components: a node of a Distributed Hash Table (DHT), a node of the Distributed Ledger and a client application. The DHT and Distributed Ledger make up the shared data storage, while the client application is responsible for the user interface and backend logic for retrieving and processing the data stored on the ledger and DHT. For owners of twinned physical devices, a Device agent manages the physical devices and coordinates their interactions with the system. As part of operational technology, the Device agent functions as a bridge between the cross-organizational asset management system and the physical devices controlled by a single organization. Data storage systems based on distributed ledgers have two ways of storing data: on-chain and off-chain [START_REF] Xu | The blockchain as a software connector[END_REF]. On-chain storage is restricted to transactions and the internal state storage of smart contracts. Due to full replication of onchain data, items larger than a few kilobytes in size need to be stored in a different, off-chain location. Using a traditional database would however result in a single point of failure or reintroduce a trusted party.

For this reason, we resort to a structured DHT for large data items. DHTs are distributed key-value stores, where all key-value pairs are mapped to one or more nodes. The DHT entries can be linked to the corresponding on-chain asset based on the DHT key hash. By storing the hash on the blockchain, integrity of the off-chain data can be verified after retrieving it from the DHT. To maintain confidentiality and availability, data stored on the DHT is encrypted, sharded and replicated. Correspondingly, an access control mechanism is needed to allow authorized parties to access the data. The k-rAC scheme illustrates how a DHT can implement the required functionality [START_REF] Kieselmann | k-rAC -a Fine-Grained k-Resilient Access Control Scheme for Distributed Hash Tables[END_REF]. In k-rAC, access control is implemented using access control lists (ACL) stored along with each key-value pair on the DHT. We propose reusing the Distributed Ledger's public key identities for DHT authentication. A symmetric key is used for encryption, which is then available to authorized parties by encrypting it with their public key. The encrypted access keys are distributed with each data item's ACL. Manipulation of the ACL is prevented by requiring a quorum of 2k +1 nodes for write operations, where k is the number of tolerated malicious nodes.

Data storage

There are two types of descriptive data that need to be stored by the system: a machine-readable specification and device-related unstructured data (i.e. human-readable documents). The specification includes a description of the device's hardware components as well as their functions. The DT's physical properties are derived from this specification. For our work we assume that AML is used to describe the physical asset. The AML specification is stored on the ledger in a modifiable way. This approach guarantees that updates to the device specification are observed by all parties. Distributed Ledgers can store complex modifiable state by using smart contracts. We thus refer to the resulting contract as the specification contract.

Unstructured data can be uploaded to the system and may subsequently be annotated or modified by other parties. Due to its size it cannot easily be parsed and stored in contracts. For this reason, it is stored off-chain and registered in the smart-contract with a document title and a hash of the contents. To update a document, a new version must be uploaded to the DHT and the smart contract reference updated. This ensures that changes to the documents are traceable.

Sensor data needs to be stored off-chain due to its frequent updates and the considerable amount of generated data. A history of the sensor data is kept to allow for further analysis, e.g. predictive maintenance or troubleshooting. The link to the on-chain data is established via a pointer to the off-chain storage location, stored on-chain in the specification contract. To avoid having to update the storage location hash every time new sensor data is uploaded to the DHT, we take advantage of DHT feeds. This concept is inspired by the Ethereum network's DHT Swarm [START_REF]Ethereum Swarm Contributors: Swarm 0.3 documentation[END_REF]. In Swarm, a feed is defined by a feed manifest with a unique address on the network. The feed manifest's owner (i.e. the physical device) is the only user permitted to upload signed and timestamped data to this address. Any data format can be used and a history of uploaded data is kept. The DHT feed enables frequent sensor data sharing without having to update an on-chain reference. Based on the feed, the client application may compare sensor updates with expected values derived from the specification contract to detect anomalies. Additionally, there is no need for directly accessing the physical device, which may reside in a protected network. Instead, data updates are readily available on the DHT for authorized participants.

Many organizations also have additional internal data sources or microservices that provide structured data relevant to the Digital Twin. These data sources can be included in the twin by adding references (i.e. an URI) to the DT specification contract. This allows inclusion of legacy data sources and complex data which cannot easily be stored on a DHT (i.e. relational data). If the external data source requires authentication, it is the responsibility of the data source provider to ensure access rights for the DT ledger's identities.

Listing 1.1 shows a pseudocode representation of the data types stored in the specification contract. The syntax is inspired by Ethereum's Solidity smart contract programming language. All data stored on the contract is readable by all lifecycle participants. Besides general device metadata, the contract also includes a program call queue for interaction with the physical device's program interfaces (see also Section 4.4). Since smart contracts must be deterministic and thus cannot interact with files, the AML specification is stored in a string variable. This variable can later be parsed and modified, as illustrated in Section 4.4. Hash references to new original documents on the DHT are kept track of in the documents mapping. The hash serves as an identifier, while the document struct provides metadata. Updated versions of each document are stored in the documentVersions mapping. The componentID and corresponding feed reference of the sensor data stream on the DHT are stored in the sensorFeeds mapping.

Capabilities

We focus on the three capabilities required for accessing and publishing DT data: DT interaction, access control and sync.

DT interaction refers to the information flows in Figure 1, which allow users to interact with the twin's data. The specification contract implements this functionality. It allows users to read and potentially modify the DT instance. The relevant interfaces that can be called with transactions are shown in Listing 1.2. New or updated references to documents may be appended by any authorized user. The same applies to external data sources and sensor feed references to the DHT. The specification can be manipulated by inserting or removing specific AML segments, which are identified by their ID. To determine the position of a new AML code segment in the AML document, the parent ID and the ID of the preceding element need to be passed as parameters. The twin's program interfaces for setting device parameters can be accessed via callProgram. This function checks authorization, finds the requested program in the AML specification and places it in a queue for the Device agent to retrieve. The agent then forwards the program call to the device for execution.

The access control capability is responsible for authentication and authorization of user interactions with the DT data. For user authentication, accounts are created on the blockchain and represented by their public key. An initial solution could be provided by the framework's built-in identity management, for example Hyperledger Fabric's Membership Service Provider (MSP) [START_REF] Androulaki | Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains[END_REF]. The MSP lists the certificate authorities who may issue digital identities for the Distributed Ledger. The same identity can then be reused for authentication in the DHT. Authorization is realized in a separate access control smart contract. Any protected interaction with the Digital Twin is first authorized through that contract. Such interactions are for example modifications of the twin's properties, like changing parameters or modifying its specification. A query from the client application provides an identity to the specification contract, which then interacts with the authorization contract to determine if the user is allowed to perform the action. Authorization is then granted or denied based upon a stored role-permission mapping. Accordingly, the contract's interfaces are based upon a Role-based Access Control (RBAC) scheme. We do not describe the access control contract in detail here, as there are other works describing blockchain-based access control schemes [START_REF] Francesco Maesa | Blockchain based access control[END_REF].

The sync capability requires regular interaction between the Device agent and the Distributed Ledger. For synchronization, the Device agent pulls updates from the real-world asset and uploads them to the off-chain DHT sensor data feed. The Device agent monitors the ledger and pushes any modifications instructed by committed on-chain transactions to the asset. The synchronization interval depends on the use case.

Other DT capabilities like monitoring, simulation and analysis can be executed off-chain by interacting with the local copy of the ledger. Simulation or analysis instructions and results can be shared on the ledger as documents. This would allow other parties to verify the results, should they desire to do so.

Setup Process

Initially, each lifecycle participant sets up one network node running both a DHT and a Distributed Ledger node. These serve as local replicas of ledger data and access points for off-chain data. They may also be used for transaction-based interaction with the smart contracts. Additionally, an identity provider must be set up to allow federated identities from all participating organizations based on public key certificates.

Once the network is set up, a Digital Twin instance can be created on the ledger by the device owner. The manufacturer should first provide the AML file to the owner, who then proceeds to set up a Digital Twin sharing instance on the ledger. The client application provides the interface to upload the file and create a smart contract based on it. Before uploading, the owner also needs to specify the access rights associated with the various parts of the specification.

Although use case dependent, sensible default values could be write access by owner and maintainer and read access by everyone else.

In this way, any number of Digital Twin instances can be created by the various parties on the network. Each instance is represented by a specification contract. Subsequent modifications take place via authorized on-chain transactions and are stored as part of the contract's internal state. As a result, auditing the twin is possible by (actively or retroactively) monitoring smart contract transactions for anomalies.

Use Case

This chapter intends to show how the theoretical framework developed in Chapter 4 is traversed in a use case. To begin with, the overall setting of the use case is described in Section 5.1, while the subsequent Section 5.2 iterates the use case through the solution architecture. At last, a summary is given, focusing on the automation degree in data sharing and the reading operation (Section 5.3).

Setting

The setting is chosen close to reality. The asset, the real-world counterpart to the DT, is a bottling plant, where bottles are filled with beverages. The parties involved in the asset lifecycle are a manufacturer, an owner, a maintainer of the bottling plant and an external auditor that audits the safety of our bottling plant. For our use case, we consider the following scenario: The bottles are flooding due to a broken sensor in the bottling plant. Consequently, the maintainer detects the damage and changes the broken sensor in the bottling plant.

This entails the following shared data interactions. At first, the specification of the plant needs to be updated by replacing the broken sensor's specification entry with the newly added sensor. Additionally, the new sensor's data stream has to be integrated in place of the old sensor stream. Other documents concerning the maintenance task might also be shared, such as a maintenance report.

While the maintainer is the only party sharing data in this scenario, the owner should also be updated on the state of the bottling plant. Furthermore, the manufacturer needs to be informed that the sensor is broken, so that an analysis of the time and circumstances can be conducted. This way relevant insights for future plant manufacturing can be gained. Additionally, the external auditor needs to access the information about the maintenance task to review the procedure in terms of safety compliance.

Framework iteration

This use case triggers a specific logical order of events in the framework, which are highlighted in Figure 4 and described hereafter. The framework first comes into play when the maintainer replaces the broken sensor. The Device agent then sends a transaction containing the new sensor specification to the Distributed Ledger. This transaction invokes the specification contract, resulting in several updates. First, the old sensor entry is removed and the new sensor specification given by the Device agent is added. Secondly, the storage location of the sensor stream on the DHT is added by a reference to the location. These three transactions concerning the specification are stored on the Distributed Ledger. 3. Having performed the maintenance task, the maintainer writes a maintenance report and pushes it onto the Client application. 4. The Client application adds the maintenance report by performing two actions. Firstly, it adds the report to the off-chain DHT. Secondly, it stores the reference to the DHT location of the report on the specification contract. Thereby, the location is added to the entry of the sensor specification.

Results

In a nutshell, the recognition of new sensor and the AML update with the new component is already accomplished by the Device agent without requiring human interaction. The new data stream is automatically forwarded to the DHT and the reference to the new storage location of the component's data stream is added to the specification contract. Additional unstructured non-specification data (e.g. the maintenance report) can be added manually. The Client application takes care of the necessary background work by inserting the file into the DHT and adding the respective storage reference into the specification contract. All participating parties can view the latest transactions on the ledgerpresented in a comprehensive way in the Client application. Advanced Client applications could also notify the user whenever an ledger update takes place.

Considering security, the advantages of this framework shine when compared to the alternative solution: A TTP could deliberately transfer shared information and know-how to rival enterprises. For instance, confidential sensor data or blueprints could be leaked to competitors, which may then deduce quality issues of the rival product. The service of the TTP could also be compromised by attackers, resulting e.g. in a violation of integrity so that the sharing parties receive inconsistent asset versions.

Evaluation

To evaluate our framework, Section 6.1 discusses the suitability of the framework in reference to the requirements. Finally, the results are discussed in Section 6.2.

Requirements fulfillment

To sum up, our approach fulfills the requirements R1-R5. The following paragraphs explain how each requirement was addressed in our solution architecture.

R1. Multi-party sharing. The main argument for using Distributed Ledgers is the involvement of multiple parties N who produce and consume data. Next to the ledger, our approach provides a client application for all parties that accesses the data on the ledger and the DHT. Therefore, our approach clearly fulfills R1.

R2. Data variety support. To enable the sharing of different data in various formats, our approach provides a central documentation and two storage options. The standardized asset description d spec is included in the Distributed Ledger and serves as the basis of the DT within the specification contract. All other data of D desc as well as the sensor data D sensor are stored off-chain in the DHT. Moreover, each stored data element in DHT is registered in the central specification contract as a reference to the storage location of the data element. For instance, a sensor in the specification contract contains a reference to the storage position of its data stream in the DHT. Hence, R2 is met.

R3. Data velocity support. Modern sensor data streams' frequency and volume exceed the performance characteristics of current Distributed Ledger frameworks. Since the data streams D sensor do not describe main features of the DT (d spec ), they are stored off-chain in the DHT. This way, high throughput of D sensor is supported, while the sharing latency is also kept low (seconds). The Distributed Ledger maintains verifiability by storing the hash reference to the data stream on the DHT in the specification contract. This ensures no loss in performance and data access through the DHT, supporting R3. R4. Data integrity and confidentiality mechanisms. With respect to data integrity, the Distributed Ledger attaches every new data element (trace()) and prevents manipulation of the data by replicating it among all involved parties. A manipulation would result in a version mismatch or loss of consensus and could be detected easily (audit()). The second storage component (DHT) also supports integrity by storing the respective hash values to the data. A manipulation of DHT data would also be detected by a mismatch between the hashes in the nodes (audit()). However, there remains the problem of adding non-valid data, which is a common issue in the area of DLT. Here, we rely on the parties' interest in sharing valid data and on mechanisms ensuring quality of input data that the respective responsible party applies.

In terms of data confidentiality, our approach ensures that the data is read only by authenticated and authorized parties. Authentication is ensured through lifecycle party login to the client application (authenticate()). Access control concerning the party and the data elements is realized through an ACL and encryption for off-chain data and an authorization smart contract for on-chain data (authorize()). In concrete terms, the ACLs specify access rights on a perdocument basis, while the smart contract stores authorization information for all involved parties. Therefore, different confidentiality levels can be realized.

To conclude, our approach provides data integrity and confidentiality mechanisms (R4) -reinforcing data security in DT data sharing.

R5. Read and write operations. Read and write operations are managed through the Client application. For read() operations, the Client application fetches the requested data from the DHT and the ledger and presents the data in a comprehensive way adjusted for the demanding party. In case of a write() operation, the Client application triggers the right procedure to alter the smart contract with a transaction and uploads additional asset-relevant data beyond specification to the DHT. Consequently, our approach also fulfills R5.

Discussion

Keeping the requirements variety (R2) and velocity (R3) in mind, the question arises why data volume is not considered a requirement. As literature is currently not at consensus regarding the relevance of the Big Data feature volume [START_REF] Negri | A Review of the Roles of Digital Twin in CPSbased Production Systems[END_REF] for Digital Twins, we consider explicit support for data volume to be non-necessary. Nevertheless, by storing documents off-chain, our approach can handle considerable amounts of data. Future implementations of our concept may conduct benchmark studies to explore scalability limits with regard to big data volumes.

It should be noted that our approach depends on multi-party participation. The more independent parties maintain the Distributed Ledger and DHT, the less vulnerable the data sharing is to manipulation. With regard to the access control capability, a decentralized identity management solution with a shared identity database could be an even more holistic, next-generation solution.

While we are aware that our approach currently lacks an implementation, we nevertheless believe that the use case shows suitability for practice. Future work will focus on implementing the framework. Here, challenges might include adjusting a DHT framework to support authorization and data feeds (although Swarm shows promise in this regard [START_REF]Ethereum Swarm Contributors: Swarm 0.3 documentation[END_REF]), as well as selecting a suitable Distributed Ledger framework.

The Distributed Ledger and the concomitant smart contracts could also be handled in a different way. For instance, the AML could be transformed into classes and types in the smart contract, similar to the BPMN to Solidity transformation in [START_REF] Weber | Untrusted business process monitoring and execution using blockchain[END_REF]. However, the effort clearly outweighs the utility as AML is a very powerful standard allowing very complex descriptions. Moreover, not all of the hypothetically generated classes and functions might be needed. Plus, functions or classes might be newly added later on, which results in the need to re-create the smart contract as they are currently not represented in the smart contract. This clearly increases effort and downgrades utility.

Another issue is entailed by the possibility to directly alter variable values referring to an actual function in our current version of the ledger. For instance, consider a PLC device with various functions such as setting a conveyor belt's velocity (with an integer parameter). Without constraints, the changed velocity could exceed safety bounds. Safety threats like this one, be they malicious or accidental, need to be mitigated in a production system. Therefore, we suggest integrating safety and security rules as proposed in [6]. They could be integrated as part of the specification contract, with the Device agent checking conformance of program calls on synchronization.

With respect to the current problems hampering secure DT data sharing, our approach tackles the issues stated in Chapter 3 in the following ways:

-The usage of different tools that can be connected with our main data sharing approach (External data sources, Fig. 3) is possible (application of different tools)

-Our approach is tailored for the integration of data in multiple formats and variety as stated in section 4.3 (usage of various data formats)

-An agreement only on the standard describing the asset (e.g. AML) is required to transform the main description of the asset into the specification smart contract, while other standardized or non-standardized data can still be shared via the DHT (missing standards)

-The proposed shared collaborative data basis is distributed among all involved parties and the information flow is universal across the lifecycle phases (broken information flow across lifecycle phases)

-The Distributed Ledger registers the data as well as the involved party sharing the data, while mechanisms such as access control (Authorization contract, Fig. 3) support confidentiality issues (clarification of the ownership of information)

To sum up, the major part of the identified issues in the literature referring to DT data sharing are diminished or solved by our approach.

Conclusion

DT data not only ties physical and virtual twin [START_REF] Tao | Digital twindriven product design, manufacturing and service with big data[END_REF], it also enables integration of the whole asset lifecycle, which is essential for realizing the DT paradigm. Moreover, the exchange of asset-relevant data (DT data) is vital for achieving the effects of a feedback loop. Closing the feedback loop in turn favors the development of a circular economy. However, maintaining data security becomes a major requirement when sharing DT data between multiple parties, especially as the parties do not necessarily trust each other. Our approach of applying DLT can clearly solve this issue and enable secure multi-party data sharing. It provides confidentiality through access control arranged by usage of a smart contract. Moreover, data integrity is implicitly supported through the immutability of the original data in the ledger.

To conclude, our approach fulfills the requirements R1-R5 for secure DT data sharing. Nevertheless, there remain minor drawbacks that need to be addressed in future research (see Section 6.2). Our upcoming work will focus on implementing our theoretical concept to demonstrate its feasibility in practice.

Fig. 1 .

 1 Fig. 1. Overview of the asset lifecycle participants interacting with the DT.

Fig. 2 .

 2 Fig. 2. Control flows for a single DT.

Fig. 3 .

 3 Fig. 3. DLT-based architecture for DT data sharing.

Listing 1 . 1 .Listing 1 . 2 .

 1112 Data structures of the specification contract / * descriptive data interfaces * / function addDocument(document) function addDocumentVersion(string hash) function removeDocument(string hash) function addExternalSource(string URI) function removeExternalSource(string URI) / * sensor data interfaces * / function addSensorFeed(string componentID, string reference) function removeSensorFeed(string componentID) / * interaction with the specification * / function insertAML(string amlCode, string parentID, string afterID) function removeAML(string ID) function callProgram(string programName, string parameters[]) Function interfaces of the specification contract

Fig. 4 . 1 .

 41 Fig. 4. Use case tailored architecture for DT data sharing.


NAPS: a Nomadic and Accurate Positioning System

Virgile Daugé 1 , Sylvain Contassot-Vivier 1 , and Laurent Ciarletta 1 Abstract-Providing accurate pose estimation over time in various and unknown environments is a key component to the realization of autonomous missions where an absolute positioning system (like GPS) is not available. A lot of work has been done in that field where Simultaneous Localization And Mapping systems (SLAM) are still highly environmentdependent and computationally expensive. However, a major issue in SLAM solutions is the drift that appears in their odometry, due to error accumulation in the successive pose estimates. This may imply significant errors in the environment reconstruction or mission success.

In this paper, a Nomadic and Accurate Positioning System (NAPS), based on the collaboration of mobile robots and their mutual sensing, is proposed. The originality and advantage of our solution is to provide a motion capture system with the nomadic ability. The result is environment-independent, computationally efficient, accurate and mobile. The system follows one or several mobile robots (explorers) and provides accurate positioning all along their mission.

The NAPS is described as well as its moving process, and its accuracy is confirmed through a series of experiments, validating the whole approach.

I. INTRODUCTION

One of the major issues in UAVs (Unmanned Autonomous Vehicles) is to obtain and maintain very accurate localization and orientation, especially for indoor contexts. Such information is essential in many tasks, either to ensure the success of the task (actions), the validity of the results (measurements), or to avoid costly post-processing phases of acquired data.

In common approaches of SLAM (Simultaneous Localization And Mapping), both a map/representation of the environment along with the relative poses of one or several UAVs in that environment are regularly updated, in real-time when possible. However, those approaches suffer from two major issues: the pose estimates accuracy and the drift in the estimates along the path followed by the UAV.

Errors in pose estimation are directly related to the sensors that are embedded in the UAV to be tracked. In most cases, there is an IMU (Inertial Measurement Unit) that provides gravity and acceleration information. Also, cameras are often used to complete the positioning system. However, IMUs can only provide relative information and are prone to errors, and the cameras require expensive image processing to find elements (landmarks) that allow a better position estimate. Moreover, cameras are environment dependent as they require luminosity and clear atmosphere.

The way to integrate measurements and uncertainties often use Bayesian approaches to maintain correct estimates of the robot pose and environment map. However, such solutions Université de Lorraine, CNRS, LORIA, F-54000 Nancy, France.

virgile.dauge@loria.fr are not sufficient to avoid the drift and its accumulation that occur along the path of the tracked UAV.

In fact, the positioning problem in classical SLAM solutions mainly comes from the fact that the exploring UAV tries to evaluate its own position from its embedded sensors. Yet, the best technique to obtain very accurate position measurements is the one used by the land surveyors, with external and still sensors. In our case, the principle is to use a small set of additional UAVs (beacons) with specific sensors allowing them to track each others. When tracking the UAVs of interest (mission UAVs), the beacons stay immobile. Otherwise, they move to the next place of interest.

In this paper, we propose to take advantage of such a solution by designing and implementing an external tracking system that has the ability to be nomadic. This solution is called NAPS: Nomadic and Accurate Positioning System.

In the next section, a brief overview of works related to pose estimation is provided. Then, in Section III is fully described the NAPS concept as well as its implementation aspects. Experimental validation is given in Section IV, demonstrating the interest of NAPS.

II. RELATED WORKS

To the best of our knowledge, the originality of NAPS leads to a lack of similar studies in the literature. However, the proposed objectives and use cases are similar to the Simultaneous Localization and Mapping (SLAM) problem. According to [START_REF] Cadena | Past, present, and future of simultaneous localization and mapping: Toward the robust-perception age[END_REF], SLAM is not solved yet, despite the extensive research in the field, as long as the robustness and the environment dependence problems (lightning, structure,...) are not addressed. Modern formulations of SLAM are often broken down into two parts : front-end and back-end. The front-end produces estimations from sensors data while the back-end merges and refines those estimations, often a posteriori. In this paper, we consider our contribution and the other odometry solutions in the front-end category, although boundaries between front and back-end are sometimes fuzzy.

A. Back-end

The way to deal with uncertainty in measurement and sensor combination in robotics has received much attention, and Bayesian solutions like Kalman filtering [START_REF] Chen | Kalman filter for robot vision: A survey[END_REF] are widely used as part of current SLAM solutions. Furthermore, some state of the art libraries are available, providing optimal solutions formalized as factor graphs computing maximum a-posteriori estimations [START_REF] Kümmerle | G2o: A general framework for graph optimization[END_REF], [START_REF] Kaess | ISAM2: Incremental smoothing and mapping using the Bayes tree[END_REF].

The drift and poor estimates can be partially corrected either by loop closure (or visual place recognition [START_REF] Lowry | Visual Place Recognition: A Survey[END_REF]) or by offline optimization tools/frameworks [START_REF] Schneider | maplab: An Open Framework for Research in Visual-inertial Mapping and Localization[END_REF] at the expense of high computation cost.

B. Front-end

In robotics, multiple and heterogeneous sensors are commonly used. By providing very dense geometric data, namely point-clouds, the Lidar allowed some valuable results [START_REF] Zhang | LOAM: Lidar Odometry and Mapping in Real-time[END_REF]. Nevertheless, as stated in [START_REF] Pomerleau | A Review of Point Cloud Registration Algorithms for Mobile Robotics[END_REF], despite the extensive use of Iterative Closest Point (ICP) and point-cloud registration in general, a consequent work is dedicated to choose, organize and tune different parts of existing software to make it work in a particular context. Research works based on Lidars have lost popularity in recent years, probably with an exception in the field of autonomous vehicles that often operate in a different context, i.e., in more controlled environments.

The trend is currently on the side of cameras. Indeed, they are quite cheap and easy to embed, even in small UAVs. Some work has been done with RGB-Depth cameras [START_REF] Kerl | Robust odometry estimation for RGB-D cameras[END_REF], but most of the research on UAVs odometry is now dedicated to visual-inertial odometry. By merging camera and IMU data, those approaches yield promising results [START_REF] Qin | VINS-Mono: A Robust and Versatile Monocular Visual-Inertial State Estimator[END_REF], [START_REF] Delmerico | A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots[END_REF]. However, these algorithms are still computationally expensive and environmentally dependent as they require a significant and constant illumination, as well as sufficiently discriminating textures in the environment. Also, the tracking frequency of those techniques (≈20Hz) does not always allow to get an accurate tracking of rapid moves that often occur with UAVs, especially the flying ones.

C. Performance Evaluation

Performance evaluation and benchmarking is complex and not often done in SLAM field due to closed-source implementations of many algorithms as well as a lack of common datasets. Fortunately, this is not the case for visual-inertial odometry, where several datasets [START_REF] Burri | The EuRoC micro aerial vehicle datasets[END_REF], [START_REF] Schubert | The TUM VI Benchmark for Evaluating Visual-Inertial Odometry[END_REF] and even benchmarking tools [START_REF] Geiger | Are we ready for autonomous driving? the KITTI vision benchmark suite[END_REF], [START_REF] Zhang | A Tutorial on Quantitative Trajectory Evaluation for Visual(-Inertial) Odometry[END_REF] are available. Also, some works take into account computational cost to strengthen quantitative comparisons between algorithms [START_REF] Delmerico | A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots[END_REF]. In Section IV, these tools are extensively used to get a fair evaluation of NAPS.

III. NAPS POSITIONING SYSTEM

As mentioned in the introduction, there are two major problems with mobile positioning systems used in SLAM. The former is the tracking accuracy that is generally limited and the latter is the drift that occurs during the moves of the explorer. Moreover, such systems often require a large amount of computation to update the explorer position (often based on acquired environment data).

In this context, we propose an original system that combines the accuracy of static positioning systems (used by land surveyors or for motion-capture) with the mobility of collaborative UAVs.

The interest of the NAPS approach is to preserve a very accurate positioning of the explorer with very few computations that can be made on-board. Moreover, NAPS is much less environment dependent than existing systems as it does not rely on any specific hypothesis over its features (structure, textures properties, light,...).

A. Concept

As mentioned above, NAPS is inspired by the techniques used by the land surveyors who manually place artificial beacons in the environment.

The main concept of NAPS is to use a small set of additional UAVs that forms a positioning system for the explorer. In this system, those UAVs are used as reference beacons that are themselves accurately localized in the initial map. Then, the relative position of the explorer with respect to the beacons is used to accurately deduce its global map position in real-time. At each time, one element is used as the reference position and all other elements are localized relatively to this reference.

The only constraint to build the NAPS is to have some sensors that allow to evaluate relative positions between elements. As the hardware implementation of our prototype is described in the next subsection, we assume here that each element can get its relative position with respect to any other element in the system.

Let's describe how the system operates. At the initialization of the system, the beacons are disposed to form an area of a few meters diameter (depending on the sensors range). Then, one of them is set as reference and its position and orientation in the global map is computed. All other elements are localized with respect to that reference thanks to the sensors. According to those local positions, they can be accurately localized in the map by the following computation: let's denote M T R the position/orientation (pose) matrix (4×4 homogeneous transform matrix) of the reference in the map, L T R the measured relative pose matrix of the reference in the local coordinate system, and L T D the measured relative pose matrix of any other device in the local system. Then, the global pose matrix M T D of that device in the map can be deduced by:

M T D = M T R . L T -1 R . L T D (1)
as depicted in Figure 1. So, at this point, the explorer can move inside the geometric volume described by the beacons. Its relative position can be accurately updated in real-time by Equation 1. This is the phase 1 of the NAPS process. It is worth noticing that when the explorer moves, it is located by a static system, so no additional error is induced. Moreover, it would be possible to use and track several explorers within the beacons area.

Map M T R M T D L T R L T D Reference Local Device
Once the explorer has scanned the area, it stops (saving its energy) and one (or several) of the UAVs is set as the new reference (it can be an explorer). Then, all other elements can move to other positions in order to change the exploration area. Once they have moved, their relative and global poses are computed thanks to the current reference. This is the phase 2 of NAPS. Once this is done, the explorer can begin to scan the new area (phase 1). This process, depicted in Figure 2, can be repeated as many times as needed to cover the zone to be explored. Here again, it is worth mentioning that positioning error evolves only when the set of beacons moves. Hence, the position accuracy of the explorer stays stable during its scans. Moreover, the accuracy loss that occurs when moving the beacons may be reduced by limiting the number of beacons that move at the same time. In fact, if one beacon is moved at a time, the error made in the evaluation of its new position should be smaller than when using only one reference beacon. The choice of the number of moving beacons at each step of the process directly depends on the accuracy and range of the sensors used to measure the relative positions. Thus, with very accurate and wide-range sensors, only one beacon may be used as reference while the others move, as in Figure 2. Also, whatever the number of beacons are moved, the accuracy loss can be restrained by a temporal integration of real-time measures. The idea is to compute the average of a set of measures obtained within a temporal window (typically 1s). Such integration is pertinent for the beacons at the end of phase 2 since they do not move during phase 1.

As can be seen, the major difference with classical land surveyor systems is that our beacons are mobile. Also, compared to SLAM techniques, our beacons play the same role as detected features (landmarks) in the environment, both drastically reducing measurement errors and eliminating the possibility of errors in data associations that are required in SLAM, but not in NAPS.

The counterpart of those advantages is that NAPS makes use of several beacons (at least two to provide accuracy and nomadism), which means additional UAVs (at least one if the explorer plays also the role of a beacon). However, those UAVs need only to carry the positioning sensors. So, they can be relatively small and simple, contrary to the explorer that may embed many sensors of different kinds, or even actuators, to fulfill its mission.

B. Implementation

In order to demonstrate the validity and interest of the NAPS approach, we have implemented a prototype system.

As NAPS requires additional UAVs as beacons (at least one), their price may condition the choices of UAV models and sensors to be used. This may affect the final accuracy of the system as well as its autonomy. Indeed, this is just a trade-off between cost and performance. However, a more fundamental constraint that must be taken into account is the embedding ability of the sensors. As our prototype is a proof of concept, that aspect was not a priority, although the hardware we have used can be technically embedded on UAVs with electric power adaptations. A last constraint that is mandatory for building the NAPS is the ability of the hardware to get unique identifiers for all the devices, in order to distinguish the UAVs.

According to all those requirements, we have chosen the Vive Pro tracking system [START_REF] Niehorster | The accuracy and precision of position and orientation tracking in the HTC vive virtual reality system for scientific research[END_REF] as it provides accurate measures (an evaluation is provided in Section IV) and the cost of the elements (trackers and lighthouses) is quite limited. This system is based on one or two lighthouses that emit lasers, and on trackers that receive the lasers on different small sensors, allowing for the computation of their relative pose according to a local system. Indeed, the system provides a transforms tree of all connected objects in real-time.

In our context, the major issue encountered with this system is that it is designed for static use-cases (virtual reality experience in a static area), i.e., the lighthouses are used as static references, and only the trackers are meant to move. So, we developed additional software in order to add the ability to move the lighthouses. In fact, the Vive API does not include any lighthouses recalibration on the fly, so the measures are no longer valid when moving one of them. As a consequence, we implemented a software environment that allowed us to recalibrate the system after each move of the lighthouses beacons. Obviously, for release versions of the system, such problem would be considered at the design level so that moving any beacon would not require such additional recalibration step.

Finally, we obtain a prototype that allows us to experimentally validate the NAPS approach.

IV. EXPERIMENTS

The particularity of NAPS, namely the use of other sensors than cameras and IMUs, prevented the use of datasets commonly referenced by the community. Therefore, some datasets have been specifically built, keeping in mind that accurate ground-truth acquisition is a key determinant for the validation of the approach. In this context, we have used a motion capture system composed of 8 Optitrack Prime 17w infrared cameras providing a 6DOF tracking at 250 Hz in a 5×4×3 meters capturing volume with a sub-millimeter accuracy on pose estimation (calibration feedback). Another constraint has been the limited number of devices at our disposal (2 lighthouses and 3 trackers). It is worth mentioning that the motion capture system illuminates the whole area with infrared light. This can disturb the VIVE tracking system which is based also on infrared communication between devices. However, although this setup may disadvantage NAPS a little by reducing its accuracy, preliminary tests have shown that such perturbations were not significant enough to invalidate the experiments.

A. Protocols

To demonstrate the validity of our approach, two distinct experimental protocols have been designed. Both of them use our moving process in two phases, described in Section III, alternating between explorer(s) tracking and beacons repositioning. Also, they are both designed according to the limited ground-truth (Optitrack) acquiring area at our disposal (covering ≈ 20m 2 while one lighthouse covers ≈ 30m 2 ). Due to that limitation, almost all beacons where located out of the ground-truth area, preventing us from getting that information for all devices. This explains why we only evaluate one trajectory (that could be the explorer's one). Indeed, comparing only the explorer position estimates is sufficient to validate our system as any error on the beacons positions would imply an error on the explorer.

As our implementation of NAPS uses the Robot Operating System (ROS), pose estimates are computed and published on topics for all beacons and explorers at a 150 Hz rate. In addition, a ROS node writes the ground-truth and pose estimates immediately upon their publication. Also, after each move of the beacons, their positions are updated with a temporal integration of 1s, i.e., around 150 measurements to obtain one estimate.

a) Random move: The objective of the first protocol is to cover the transition phases of an exploration process, namely the local repositioning (translations and rotations) of the system. In the first phase, the explorer moves freely in the area formed by the NAPS beacons in order to fulfill its mission, then it lands anywhere in that area. In the second phase, all the beacons are randomly re-arranged in the same area. It is important to notice that all beacons are moved, effectively adding estimations errors to the system.

In the context of this experiment, the explorer is used as the reference and all the beacons move to form a new tracking area. However, the use of the explorer as reference is only a practical choice but it does not induce any loss of generality of the approach since all the UAVs in the system are tracked with the same accuracy.

The results of that experiment are labeled RMi. For each experiment, the raw concatenation (no post-treatment) of the consecutive steps (phases 1 and 2) provides time-stamped trajectories of one UAV (the explorer) for both ground-truth and NAPS pose estimates.

b) Guided move: This second protocol is designed to reproduce a complete guided exploration process, i.e. moving the system in a specific direction. The mechanism is quite the same, except that instead of moving randomly, the beacons are moved to a neighboring area, in a given direction. In order to preserve the accuracy of the system when the beacons move to another area, the explorer must land near the border of the current area that is common to the aimed area. Then, the second phase can begin.

This iterative process is repeated several times in order to evaluate the error accumulation along a realistic path length (several tens of meters) requiring several tracking areas. Those experiments are labeled GMi in the following.

B. Results

In order to compare our results with state of the art (visualinertial) odometry, we need to use the same metrics. What we need to quantify is the error between the ground-truth trajectory and the trajectory estimated by NAPS. In Table I are gathered the general features of the datasets collected during our experiments: 4 random moves (RM) and 4 guided moves (GM). Also, a high-speed test (HST) is added, in which the robustness of NAPS to fast moves of the explorer (above classical use) is tested. The differences between the number of ground-truth poses and the number of NAPS poses come from different acquisition frequencies. The open Toolbox for trajectory evaluation [START_REF] Zhang | A Tutorial on Quantitative Trajectory Evaluation for Visual(-Inertial) Odometry[END_REF] provided by the University of Zurich and ETH Zurich Robotics and Perception Group has been used to compute translation and orientation root mean square errors (RMSE) along the complete trajectories, as well as to produce KITTI style analysis [START_REF] Geiger | Are we ready for autonomous driving? the KITTI vision benchmark suite[END_REF], giving the errors for different segment lengths along the trajectories. a) Raw data: As a first accuracy overview, the overlapped trajectories measured by Optitrack and NAPS are given in Figure 3 and4, respectively for a random move experiment and for a guided move one. As the trajectories are initially expressed in different coordinate systems (Optitrack and Vive), the alignment toolbox (sim3 type) has been used to obtain the overlaps. As can be seen, Optitrack and NAPS trajectories are pretty close to each other in both cases. In order to get a closer look to the accuracy of our system, translation and orientation errors of the NAPS pose estimations in the GM2 experiment are plotted in Figure 5, for all dimensions or axes. Other experiments obtain similar plots, but in GM2, there is a translation error peak is visible in step 0 for one x value. Indeed, this corresponds to a temporary loss of sight between explorer and beacons during manual testing. However, such problem can be avoided by moving algorithms ensuring line of sight. All other measures are coherent and stay in an error interval around [-40:30] mm. Step 0

Step 1

Step 2

Step 3

Step 4 yaw pitch roll Fig. 5: Pose estimation errors over the whole GM2 experiment. Each vertical separation corresponds to a transition phase in which all beacons are moved (phase 2 of NAPS).

b) Absolute error: The Root Mean Square Error metric is often used for trajectory error analysis. It offers the benefit to summarize the errors on the whole trajectory with only one value. In Table II are presented the RMSE obtained in our experiments. As already mentioned, a direct comparison of our results with those obtained by other algorithms is quite difficult as the datasets are different. However, the results presented in several odometry benchmarks [START_REF] Schubert | The TUM VI Benchmark for Evaluating Visual-Inertial Odometry[END_REF], [START_REF] Delmerico | A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots[END_REF] suggest a higher order of the RMSE metrics. For instance, the best results reported in [START_REF] Delmerico | A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots[END_REF] are 0.03 m for a specific dataset whereas it is the maximal RMSE value observed for NAPS, with the longest trajectory (176 m). c) Relative Error: Another common approach for trajectory analysis is the KITTI style analysis [START_REF] Zhang | A Tutorial on Quantitative Trajectory Evaluation for Visual(-Inertial) Odometry[END_REF]. Its principle is to split the whole trajectory into sections of given lengths, to align the couples of ground-truth and estimate values for each section, and finally to compute the relative error for each section. This technique has been used to produce Figure 6, in which the relative error distributions in translation and yaw are depicted for several section lengths along every trajectories obtained in our entire set of experiments. It can be seen that NAPS median errors are 29 mm and 0.5 • for a 35 m section length. As a comparison, the best results reported in the literature [START_REF] Delmerico | A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots[END_REF] are obtained by the vinsmonolc method [START_REF] Qin | VINS-Mono: A Robust and Versatile Monocular Visual-Inertial State Estimator[END_REF], with a median translation error of 150 mm the same path length. Although the datasets are not the same, the diversity, complexity and generality of our experiments make them representative of general use-cases.

So, we can conclude that according to the limited environment dependency of our NAPS prototype, its high quality sensors for pose measurements and its update rate of 150 Hz allowing time integration, similar results should be obtained in most real-case contexts. One of our future works will consist in testing our prototype in the real context of a mine.

V. CONCLUSION

A nomadic and accurate positioning system (NAPS) has been presented. Its originality is to combine advantages of static localization systems with mobility provided by UAVs. Indeed, the system is composed of two sets of UAVs. One set contains positioning beacons and the other set contains one or more explorers.

The interest and validity of the system has been practically demonstrated by a series of experiments, showing the very good accuracy of pose estimates of any of the elements (beacons and explorers). The NAPS positioning errors stay in the order of the centimeter along quite long paths (<45 mm for 175 m), which is much smaller that existing solutions.

Although the NAPS results are very promising, several tracks for further works can be identified. In particular, our experiments have pointed out that the way the beacons are moved may have an impact over the overall accuracy. So, we plan to study different strategies for moving the beacons in order to preserve accuracy while optimizing the energy consumption of all elements. Also, the number of beacons is an important parameter. A minimum of two beacons is necessary. In an extreme case, only one beacon may be required if the explorer plays also the role of a beacon. However, such reduction of the number of beacons would induce significant constraints over the consecutive moves of the system, probably implying more steps in the moving process. This issue deserves a specific study in itself. Another work of interest will be to test the behavior of NAPS in different environmental conditions (smoky/dusty air,...). Finally, we would like to enhance our current hardware prototype by embedding the lighthouses on UAVs. This will make our system fully autonomous and will allow us to conduct realcase explorations with additional sensors (Lidar,...) for full 3D reconstructions.

Fig. 1 :

 1 Fig. 1: Global pose deduction from local and reference poses.

Phase 1 :Fig. 2 :

 12 Fig.2: NAPS process: explorer in action tracked by the beacons (left and right), beacons moving to another area (center). The dashed rectangle (not used in the process) represents the same part of environment. It is drawn to help the understanding.

Fig. 3 :Fig. 4 :

 34 Fig. 3: Trajectory from the RM2 experiment (top view)

  RM1 RM2 RM3 RM4 GM1 GM2 GM3 GM4 EST Trans. (m) 0.011 0.010 0.016 0.015 0.011 0.011 0.010 0.031 0.014 Ori. (deg) 1.288 0.936 1.090 0.894 0.973 0.939 1.492 1.669 1.824

Fig. 6 :

 6 Fig. 6: Translation (top) and yaw (bottom) errors over the 9 datasets.

TABLE I :

 I Datasets collected during the experiments: total trajectory length, number of NAPS moves and number of recorded poses for both ground-truth and NAPS.

TABLE II :

 II Translation and orientation RMSEs for NAPS.

ACKNOWLEDGMENT

This work was supported by the Interreg V -Grone -Project 024-4-09-076 of the European Union and the Region GrandEst. The experiments presented in the paper have been done in the Creativ'Lab at Loria.