*2.1. Labelling and Identification Technologies*

Currently, one of the most popular identification technologies is barcodes, which are essentially a visual representation of Global Trade Item Number (GTIN) codes [24]. However, barcode readers need Line-of-Sight (LoS) with the barcode label to read it correctly and it can only be read at relatively short distances (just a few tens of centimeters). Despite the mentioned limitations, barcodes improved inventory speed in industrial scenarios with respect to traditional manual identification procedures. In addition, barcode label manufacturing cost is really low, since they only require specific software and a printer.

In the middle of the 1990s, barcodes evolved towards bidimensional codes known as BiDimensional (BiDi) or Quick Response (QR) codes, which are able to store data (usually more than 1800 characters) and can be read with a simple smartphone camera, thus, reducing the overall cost of the inventory/traceability system. Nonetheless, QR codes can only be read up to a distance that depends on the size of the QR marker (the reading distance is often estimated to be less than ten times of the QR code diagonal).

Since both barcodes and QR codes are limited by their reading distance and their need for LoS between the reader and the code, they evolved towards more sophisticated labels (Figure 1 illustrates such an evolution). Labels based on RFID are considered the next step in the inventory and traceability system

evolution [25]. Such a kind of label can be read at a distance that goes from several centimeters to several tens of meters [26]. In fact, reading distance is commonly related to the type of RFID tag: passive tags (i.e., tags that do not depend on batteries for carrying out RFID communications) reading distance usually does not exceed 20 m, while active tag communications (i.e., the ones that do use batteries for carrying out RFID communications) can easily reach 100 m in unobstructed environments. In addition, certain RFID tags can store information, which may be useful in certain inventory and traceability processes. It must be also noted that, in the last years, academia and industry have evolved RFID tags in order to add to them sensing capabilities, thus, creating tags that are able to measure temperature [27], acceleration [28] or light [29].

**Figure 1.** Technological evolution of identification tags.

The next step in the tag evolution are the so-called smart labels [30], which are noticeably more complex than RFID tags and allow for providing industry 4.0 functionality like event detection [31], operator interactivity, a display for visual feedback, one or more communication technologies, positioning services or embed IoT sensors that collect environmental data that are relevant for the state of a product. Omni-ID's View smart labels [32] are one of the few on the market and embed an e-ink display, flash memory storage, active and passive UHF RFID transceivers, and an infrared receiver for beacon-based positioning.

Besides the identification technologies related to the previously mentioned labelling solutions, there are others that have been suggested. For instance, Near Field Communication (NFC) [33] has been used in inventory applications, but it is only dedicated to scenarios where a short reading distance (often less than 30 cm) is needed.

There are other technologies, which, have been actually conceived as communications technologies, but can also provide identification mechanisms. For instance, Bluetooth Low Energy (BLE) is a generic Wireless Personal Area Network (WPAN) technology that usually does not reach more than 10 m when used through smartphones or up to 100 m in industrial applications [34]. There are diverse BLE profiles and specific devices called beacons that can be useful in certain inventory and traceability applications, as well as in indoor locations [35,36] and IoT applications [37,38], since they transmit a periodic signal to be located and identified.

The Media Access Control (MAC) address of a WiFi device (i.e., a device compatible with the IEEE 802.11 family of standards, including its vehicular version [39,40]) can also be used for identification purposes, as well as other technologies less frequently used in inventory tags, like devices based on ultrasounds, infrared communications, ZigBee [41], Low-Power Wide-Area Network (LoRA) [42], Dash7 [43], Ultra Wide Band (UWB), WirelessHART [44], RuBee (IEEE standard 1902.1), SigFox [45], ANT+ [46] or IEEE 802.11ah, among others.

As a summary, the main characteristics of the most relevant identification technologies for inventory and traceability applications are shown in Table 1, which specifies their frequency band, usual maximum range, data rate, power consumption, relevant features and some examples of applications that have made use of each technology.


#### *2.2. UAVs for Inventory and Traceability Applications*

UAVs have been suggested for providing services in a number of industrial applications, like for critical infrastructure inspections [47–51] or sensor monitoring [52–54]. It is important to note that industrial environments require certain UAV features that may differ from other applications, like obstacle collision avoidance [55], automatic cargo transport [56,57] or logistics optimization for swarms of UAVs [58].

UAVs have already been used for traceability and inventory management applications. For example, in [59], the authors use a QR code-based UAV to detect items. Although the system shows an impressive precision of 98.08%, it requires LoS with QR codes, which in practice limits its application to certain scenarios. Another interesting article is [60], where UWB devices are used to accurately position (i.e., with an indoor location accuracy of only 5 cm) a UAV that performs inventory management tasks.

RFID is the identification technology embedded in a UAV in [61]. In such a paper, the scenario is an open storage yard that is monitored by a DJI Phantom 2 drone that carries a passive UHF reader embedded by a PDA. Researchers from MIT have also conceived a similar theoretical system where multiple UAVs carry RFID readers to aid inventory automation in a warehouse [62]. Finally, it is worth mentioning the work in [63], which proposes the collaboration of an Unmanned Ground Vehicle (UGV) and a UAV to perform inventory tasks in a warehouse. Specifically, the UGV is used as a ground reference for the indoor flight of the UAV, which embeds a camera that recognizes augmented reality markers. Thus, the UGV carries the UAV to places where there are items to be inventoried and then the UAV flies vertically to scan them, sending the collected data to a ground station.

#### *2.3. Big Data for Inventory and Supply Chain Management*

Big Data analytics can also be applied to optimize knowledge extraction and decision-making in inventory and supply management applications. A comprehensive review on the application of big data to such fields can be found in [64], with the management of safety stocks being one of the key aspects [65]. Moreover, other authors have already analyzed how to face the current challenges and opportunities that the transformation of supply chain management suppose in order to be driven by big data techniques [66].

With respect to practical deployments, in [67], the authors propose a big data analytics framework that processes the information collected from an RFID-enabled shop floor. The authors define, at a logistics management level, different Key Performance Indicators (KPIs) in order to evaluate different manufacturing objects and the main findings are converted into managerial guidance for decision making.

Regarding the use of big data analytics for inventory applications, several advantages can be pointed out [11]: it can help to take informed decisions related to inventory performance, it may aid to obtain a holistic view at inventory levels across the supply chain and with external stakeholders, and it enables to predict inventory needs and changes in customer demand using statistical forecasting techniques, as well as to reduce inventory costs dramatically.

### *2.4. Analysis of the State of The Art*

Table 2 shows a comparison of the most relevant characteristics of the previously cited UAV-based inventory systems together with the ones of the system proposed in this article. As it can be observed after reviewing the different aspects of the state-of-the-art, it is possible to highlight several important shortcomings that motivated this article.




 processes.


First of all, few papers detail practical UAV-based applications for inventory and traceability applications, specially with RFID as the identification technology embedded in the UAV. Specifically, most of them do not take into consideration in the UAV design a trade-off between cost, modularity, payload capacity and robustness. Second, the emergence of Big Data analytics impose additional issues to emerging solutions that are still open for research like:


Although different alternatives have been proposed for facing some of the issues mentioned above, DLTs seem to be the most promising solution in order to guarantee operational efficiency and data transparency, authenticity and security. However, there is a shortcoming related to the fact that, although there are examples in the literature of DLTs applied to other sectors, to the knowledge of the authors, there are no examples of DLTs or blockchain-based architectures for the upcoming big data-driven supply chain applications.

Finally, it must be noted that the use of current DLTs, and specifically blockchain, involve certain weaknesses related to the immature status of the technology, like the lack of scalability, high energy consumption, low performance, interoperability risks or privacy issues [18–22]. Moreover, blockchain technologies face design limitations in transaction capacity (i.e., throughput and latency), in validation protocols or in the implementation of smart contracts. Therefore, architecture design should consider these constraints together with the specific decentralization requirements. Furthermore, as of writing, there are several open issues that require more research. For instance, no references were found in the literature on the evaluation of the performance of blockchain-based application architectures.

As a consequence of the previous analysis, the design of the system proposed in this article has been devised taking the previous shortcomings into consideration.

### **3. Design of the System**

Figure 2 depicts the proposed communications architecture. In such an architecture, a UAV carries a Single-Board Computer (SBC) and a tag reader. The tag reader is used for collecting data from wireless tags that are attached to the items to be inventoried or traced. Regarding the SBC, it collects tag data from the tag reader, processes them and sends them through a wireless communications interface to a ground station. Then, to provide enhanced cybersecurity, the ground station can make use of its internal software modules to send the collected information to two possible destinations: to a decentralized remote storage network or to a blockchain.

**Figure 2.** Proposed communications architecture.

In the case of sending the data to a blockchain, the ground station makes use of a software module that acts as a blockchain client. Therefore, the SBC is able to store in a secure way the collected data (or their hashes) into the remote blockchain, which also allows the proposed system to participate in smart contracts that enables the direct participation of suppliers, manufacturers, retailers or logistics operators [68]. It is important to note that very similar features may be provided by traditionally centralized solutions like databases, cloud-based services or complex-event processing software, but blockchain technologies include the following features that make them really attractive for industrial scenarios where third parties may be

interested in carrying out audits or financial evaluations, or may need to verify the fulfillment of certain laws [21]:


With respect to the decentralized storage, it is included in the architecture in order to provide the following three main advantages that useful for enhancing the security of the inventory and traceability data:


Both the blockchain and the decentralized storage system essentially manage the same data types as in other traditional inventory solutions: sets of unique alphanumeric identifiers (UIDs). Thus, item UID association and information processing (e.g., to determine the number of items available of one specific type) need to be performed by an additional software layer that may be implemented through a Cyber-Physical System (CPS). Moreover, note that, although remote users may access the collected raw information directly from one of the nodes of the decentralized storage network or through a blockchain browser, it is usually more practical to make use of a user-friendly interface like the one provided by the CPS. Thus, a CPS collects and processes the data needed by remote users and presents them in a way that can be easily understood by remote users [72].

#### **4. Implementation**

### *4.1. UAV Implementation*

UAVs vary widely in size, materials, components and configuration. In the design of the proposed UAV, the main objective was to develop a cost-effective, simple and modular initial prototype that can be easily adapted to different applications, scenarios and/or performance criteria.

Figure 3 depicts the main components of the designed UAV, while Table 3 shows a summary of their characteristics. A multipurpose UAV was designed with both indoor and outdoor flight capabilities in order to extend its use to different applications and maximize its exploitation opportunities. The chosen configuration offers a good trade-off between cost, payload capacity and reliability; an hexacopter configuration has the minimum number of motors in order to be able to recover and land in the case of a motor failure without damaging people or goods. More rotors would increase the reliability even further but would also increase the cost and its total weight.

Specifically, the UAV is mounted on an hexacopter frame of 550 mm of diameter mostly made out of carbon fiber except for the arms, which are made of plastic reinforced by carbon fiber rods in the interior. The flight controller is a PixHawk 2.4.8 that has been flashed with the well-known open-source firmware Ardupilot [73] The thrust to move the UAV is generated by six 920 Kv brushless motors controlled by six 30 A Electronic Speed Control (ESCs), which are powered by a four-cell 5 Ah Li-Po battery that also provides power to all the on-board electronics through a voltage conversion module. Besides the built-in sensors of the flight controller board, a UBLOX M8N GPS module was included to enable outdoor autonomous flights since in this industrial use case, there are storage areas outdoors in a nearby dock next to the warehouse where inventory can also be performed.

**Figure 3.** UAV used for the inventory and traceability system.


**Table 3.** Main features of the UAV components.

### *4.2. Implemented Architecture*

Figure 4 shows the actual implemented architecture of the proposed system. It can be observed that it is very similar to Figure 2, but, since this article is focused on assessing the performance of the UAV-based inventory system, it includes certain simplifications on aspects that are not evaluated (i.e., on the CPS).

As it can be observed in Figures 3 and 4, in order to perform the inventory, an RFID reader (NPR Active Track-2) is carried by the hexacopter. Specifically, active Ultra High Frequency (UHF) RFID has been selected as item identification technology due to its performance in environments with multiple metallic obstacles [26]. The RFID reader has been modified to reduce its weight by replacing its steel case with a lighter one made of foam, which protects the reader and reduces vibrations. In addition, it is worth pointing out that, as it can be observed in Figure 3, the RFID reader antennas were placed as far as possible from the hexacopter propellers, which can influence communications performance. Nonetheless, the location of the antennas may be further optimized.

Regarding the used RFID tags, they are active UHF tags from RF-Code [74] that can be read with the NPR Active Track 2 reader (e.g., Active Rugged Tag-175S). Such a reader is connected through an Ethernet cable to the SBC. The tag UIDs collected by the SBC are first stored locally in a JavaScript Object Notation (JSON) file and then sent through WiFi to the ground station server, which, for the experiments performed in this article, it was run in a laptop.

Figure 4 shows a high-level view of the implemented blockchain-based architecture. As it can be observed in the Figure, to persist the collected inventory data, the proposed system makes use of the decentralized database OrbitDB [75], which runs over InterPlanetary File System (IPFS) [76]. IPFS provides a high throughput content-addressed block storage model with content-addressed hyper links. This forms a generalized Merkle Directed Acyclic Graph (DAG), a data structure upon which one can build versioned file systems, blockchains, and even a Permanent Web. Specifically, the main features of IPFS are:



**Figure 4.** Implemented architecture.

OrbitDB is built on top of IPFS to create a serverless, distributed, peer-to-peer database in alpha-stage software. It uses IPFS as its data storage, as well as IPFS Pubsub to synchronize databases with peers automatically. In addition, OrbitDB provides various types of databases for different data models and use cases:



All the previously mentioned types of databases are implemented on top of ipfs-log, an immutable, operation-based Conflict-free Replicated Data Structure (CRDT) for distributed systems. If none of the OrbitDB database types match a dApp needs or if a specific functionality is needed, it allows for implementing a custom database easily.

With respect to the blockchain, two different Ethereum testnets (i.e., test networks that are isolated from the public Ethereum blockchain [77]) were used: Rinkeby [78] and Ropsten [79]. Rinkeby is a Proof-of-Authority (PoA) testnet created by the Ethereum team that makes use of the Clique PoA consensus protocol, where authorized signers are responsible for minting the blocks. In such a network blocks are created on average every 15 s and Ether cannot be mined (it is requested through a faucet [80]). In contrast, Ropsten is a Proof-of-Work (PoW) Ethereum testnet where Ether can be either mined or requested from a faucet [81]. Ropsten's blocks are usually minted in less than 30 s and, although the testnet reproduces with more fidelity than Rinkeby Ethereum's mainnet production environment, it is prone to Denial-of-Service (DoS) attacks (e.g., by increasing the block gas limit remarkably while sending large transactions through the network), which makes synchronization slow and makes clients consume a lot of disk space. Rinkeby and Ropsten testnets allow for executing smart contracts (compiled and deployed through Truffle [82]), which store in a string the JSON file with the inventory data and its hash, so the blockchain acts both as a immutable log and as a timestamping server.

In the implemented architecture, remote users are able to access the raw OrbitDB and Ethereum data, but, thanks to the proposed architecture, it is straightforward to develop a backend that collects data from OrbitDB and Ethereum, and presents them through a frontend.

### *4.3. Inventory Data Insertion and Reading Processes*

Figure 5 illustrates all the components that are involved in the implementation of the part the architecture related to decentralized storage and the blockchain. Besides the previously mentioned components (i.e., OrbitDB, IPFS, the Ethereum testnets and Truffle), three another elements are used:


Figure 5 also shows the steps performed when inserting inventory data in OrbitDB and Ethereum. Before starting to store data, it is assumed that all the involved components are up and running, and that the different OrbitDB nodes synchronize their data periodically (this is illustrated by steps 0A and 0B, which indicate that every node is synchronized through a publish/subscribe scheme). Moreover, it is also assumed that the smart contracts haven been deployed through Truffle in one of the Ethereum's testnets. Then, when a ground station wants to upload new inventory data, it first appends them to OrbitDB, which returns a hash as an acknowledgement of the transaction. Such an OrbitDB hash, together with the inventory data and the Infura authentication token, are sent to Infura through a data insertion request. If the authentication token is valid, Infura would take the inventory data and the OrbitDB hash, and would

execute the setData function of the smart contract, so that it updates the stored inventory data values and the OrbitDB hash. As a result of this operation, Ethereum returns a hash that can be used later to request the blockchain transaction information.

**Figure 5.** Inventory data insertion process and implemented architecture.

Figure 6 illustrates the steps required by an entity that wants to verify that the data stored in OrbitDB have not being altered after their insertion. In such a case, the entity only would need to first request the inventory data from OrbitDB and them perform through Infura a *GetData* request to the corresponding Ethereum's smart contract, which would return the inventory information stored on the blockchain and its OrbitDB hash. Then, the entity would only need to compare the inventory information collected from OrbitDB with the one from Ethereum, and determine whether it has been modified.

As it can be concluded from the proposed architecture and processes, they enable data trustworthiness through four different mechanisms:


• Similarly, the data that is exchanged with Ethereum are managed by Infura, which protects them through an API key and a secret key.

**Figure 6.** Inventory data verification process.

### **5. Experiments**

### *5.1. Experimental Scenario*

In order to evaluate the proposed system, it was tested in a big industrial warehouse that is shown in Figure 7. The warehouse is approximately 120 m long and 40 m wide, but, due to security reasons (the warehouse was in operation during the experiments), the tags were deployed in an isolated subarea of 50 m × 40 m.

As it can be observed in Figure 7, the warehouse stores items that are packaged into wooden, plastic or cardboard boxes. There are also items that are not packaged and, thus, only a plastic inventory label is attached to them. Due to such an item diversity, in order to provide a fair estimation of the performance of the proposed system, the deployed tags were attached to items made out of diverse materials, some of which are shown in Figure 8.

**Figure 7.** Warehouse where the experiments were performed.

**Figure 8.** Warehouse material diversity.

A total of 13 different tags were attached to items scattered throughout the previously mentioned isolated area of the warehouse that was monitored with the drone. Figure 9 shows the location of the ground station during the tests, while Figure 10 illustrates one of the moments during the experiments. As it can be observed in Figure 10 and in the video of the Supplementary Materials, during the tests the drone was operated in manual mode in order to avoid possible physical security problems. Such an operation is expected to be automated thanks to the use of different on-board sensors and the placement of multiple image-based or RFID markers in the environment. In the same way, while during the tests the operator moved the drone to follow a circular path over the monitored area, in the future such a path will be prefixed by software through indoor waypoints.

**Figure 9.** Ground station setup.

**Figure 10.** One of the instants during the inventory tests.

#### *5.2. Inventory Time*

The firsts tests were carried out in order to determine how fast the inventory data could be collected. Figure 11 shows the percentage of read tags through time for four different tests. During such tests the tags remained at the same location and were attached to the same items. Considering the nature of the proposed experiments and the RFID reader reading range, the pilot experience and skills can be considered negligible in the results obtained.

An example of the collected data is shown in Table 4, which is related to Test 2 of Figure 11. Specifically, the table indicates the number and percentage of read inventory tags, and the time stamp collected by the drone every time a new tag is detected (its ID is indicated in the last column).

**Figure 11.** Percentage of read tags during four inventory flights.


**Table 4.** Example of the collected inventory data.

During Tests 1 and 2, the drone departed from the same spot and followed a similar path. This can be observed in Figure 11: the curves for both tests are very similar. Nonetheless, the inventory was gathered faster during Test 2: it only took approximately 78 s to collect the data, which is less than the 116 s needed during Test 1.

Although the tags were scattered randomly throughout the monitored area of the warehouse (with the only restriction of attaching them to items of the three most common materials), the departing point of the drone is essential for accelerating the inventory collection. This can be observed in the curves of Figure 11 related to Tests 3 and 4. In the case of Test 3 the departing point was located in the opposite side of the beginning of the monitored area, where several tags were placed. This derived into requiring a total of 229 s to collect all the UIDs of the inventoried items. However, in Test 4 the drone was roughly in the middle of the monitored area, thus accelerating remarkably their detection (it only took 26 s to complete the inventory).

Except for Test 3 (due to its specific location), in the other cases, mainly because of the reading range and the omni-directional antennas of the reader, during the first 11 s (as the drone rose from the ground), it was possible to read roughly 30% of the tags. Moreover, in all tests, 50% of the items where inventoried in less than a minute and all of them in less than four minutes. These results are really promising, since the time required by a human operator to collect the same information is far greater than when using the proposed UAV-based system (the operator needs to walk through the area, locate the items and identify them manually).

### *5.3. Signal Strength Monitoring*

As the drone hovers above the warehouse, besides tag UIDs, it also collects the Signal Strength Indicator (SSI) of such tags, which can potentially be used for locating industrial items and for creating signal strength maps [86].

An example of the SSI fluctuation perceived by the drone for one of the RFID tags during an inventory flight is shown in Figure 12. It can be observed that while the drone is hovering around the warehouse, in locations far from the tag, the collected SSIs fluctuate between −50 and −62 dBm. However, once the drone is close to the tag, SSI levels go up to around −40 dBm and, as the drone moves away from the tag, the collected SSI values go down again to be between −50 and −62 dBm. Therefore, if the location of the drone can be obtained through an indoor positioning system, due to the existent correlation, tag locations may be estimated at the same time as the inventory data are collected. However, it must be noted that, in order to design an indoor positioning system for industrial environments, additional factors should be considered, like the reflections, diffraction and refraction caused by surrounding materials, the presence of hostile electromagnetic sources, certain features of the scenario (e.g., presence of metals, water, exposure to liquids, acids, salinity, fuel or other corrosive substances, tolerance to high temperatures) or the actual reading distance, among others [26].

Finally, it is worth pointing out that just after flying over the tag there were several seconds (roughly between seconds 120 and 160) during which the tag SSIs were not received by the UAV, what was probably caused by a signal blockage related to the presence of large metallic item in the scenario. This must be taken into account in future developments in order to determine the optimal tag and item positions to maximize SSI reception.

**Figure 12.** SSI evolution of a tag during an inventory flight.

#### *5.4. Performance of the Implemented Architecture*
