5.4.1. Performance of the Decentralized Database

The performance of OrbitDB was measured in terms of response latency (i.e., how fast the inventory data were inserted into OrbitDB after being sent by a UAV ground station). Three scenarios (named A, B and C) were simulated in order to evaluate the effect of payload size and network delay, so small, medium and large payloads were sent to OrbitDB when it was running either in the same Intranet (i.e., the same private local network) as the ground station, and when it was running in a remote cloud on the Internet (i.e., for simulating the connection with other stakeholders such as suppliers or external audits). As a reference, it can be indicated that the minimum/average/maximum round-trip times to the machine that ran OrbitDB in the Intranet were 0.935/1.034/1.695 ms, while the same values for the connection between the ground station and the remote cloud were 37.948/39.362/51.172 ms. Scenarios A, B and C take place inside an Intranet. Scenario A corresponds exactly to the environment tested in Section 5.2: the inventory data were only 13 Tag IDs, which derived into a very small payload (around 1 KB). Scenarios B and C simulate inventory data of 5000 (around 30 KB) and 10,000 (around 67 KB) items, respectively. Regarding Scenarios D, E and F, they also simulate 13, 5000 and 10,000 items, respectively, but the inventory data is sent from the local network to a remote OrbitDB instance that runs on a cloud on the Internet.

These scenarios resulted into the six use cases characterized in Table 5, which shows, for each scenario, the number of inventoried tags, as well as the mean and variance of the obtained OrbitdB response latency. In addition, Figures 13 and 14 show the response latency for the six evaluated scenarios and for 2000 insertion requests per scenario when measuring the time elapsed since each request is issued, until the OrbitDB hash is obtained (i.e., from step 1 to step 2 of Figure 5).


**Table 5.** Mean and variance of the use cases considered in the OrbitDB performance test.

The results show that, in terms of response delay, OrbitDB insertions are really fast: in the worst tested case (Scenario F), the average inventory data insertion time requires roughly 0.55 s. In addition, it can be pointed out that, as expected, the larger the payload, the slower the insertion. However, the difference in response delay between the insertion of 13 and 10,000 tag IDs is negligible when OrbitDB runs on the Intranet (only 31.6 ms), while, in the same case but when OrbitDB was running of the remote cloud, the difference rose up to 190.5 ms. Moreover, at the view of the low variance values, it can be observed that response delay is very stable in both networks, although, obviously, it is clearly more stable for Scenarios A, B and C (i.e., on the Intranet).

Regarding Figures 13 and 14, they seem to show a clear average response time, although such a time oscillates depending on different factors, like the network load (i.e., the network is actually shared with other users). Despite such oscillations, it is possible to obtain the Probability Density Function (PDF) of the different response delays. Figure 15 shows the PDFs for the three Intranet scenarios, which follow a Generalized Extreme Value (GEV) distribution with different values for the parameters of location (*μ*), scale (*σ*) and shape (k) [87]. In the case of the Internet scenarios, Figure 16 shows that they seem to follow a multimodal distribution (e.g., bimodal), although in the Figure it was fitted to a kernel distribution [88]. Therefore, the mentioned PDFs may be used in the future to model the behavior of the different scenarios

and then generate artificial samples from the fitted distributions to perform Monte Carlo simulations to test the theoretical load that can be supported by the proposed system.

**Figure 13.** Response time in OrbitDB for (**A**) Scenario A, (**B**) Scenario B and (**C**) Scenario C.

(**C**)

**Figure 14.** Response time in OrbitDB for (**A**) Scenario D, (**B**) Scenario E and (**C**) Scenario F.

(**C**) **Figure 15.** Probability Density Function (pdf) in OrbitDB for (**A**) Scenario A, (**B**) Scenario B and (**C**) Scenario C.

**Figure 16.** Probability Density Function (pdf) in OrbitDB for (**A**) Scenario D, (**B**) Scenario E and (**C**) Scenario F.

### 5.4.2. Performance of The Blockchain

It is also interesting to measure the blockchain response latency in order to detect a possible bottleneck of the architecture. While Rinkeby is a PoA testnet whose time to mint a block is set to an average of 15 s, the Ropsten testnet is based on PoW and thus the same time may vary noticeably.

Figure 17 shows the response latency of almost 100 transactions (9.4 KB) in the Ropsten testnet during a smart contract update of the proposed system. Specifically, the elapsed time is measured since the transaction is included in a block until it is validated (from step 3 to step 5 in Figure 5). As it can be observed in Figure 17, the response time varies significantly from less to 5 s up to more than 70 s, being the delays significantly higher than in the OrbitDB performance tests.

**Figure 17.** Ropsten testnet time response.

Figure 18 shows a caption of Etherscan where the specific details of the transactions performed on the smart contract used for the tests performed in this Section (0x3A99AFac4A32b29C17 Aeb7d0B4E3C4F28EA200c7). The details of the transaction include the account balance, the performed

transactions, the addresses of the involved parties and the number of miners. Additional details are available on https://ropsten.etherscan.io/address/0x3a99afac4a32b29c17aeb7d0b4e3c4f28ea200c7.


**Figure 18.** Caption of Ropsten Testnet transactions.

### **6. Conclusions**

This article presented the design, implementation and evaluation of an UAV and blockchain-based system for Industry 4.0 inventory and traceability applications. After reviewing the most relevant initiatives related to industrial UAV applications and identification technologies, the architecture and components of the proposed UAV and RFID-based system were detailed. Such a system is able to collect and process inventory data in real-time and send them to a blockchain and to a decentralized storage network for providing enhanced cyber security, redundancy and the ability to run decentralized applications. Moreover, the system was able to use smart contract to automate certain processes without human intervention. The proposed system was tested in a real warehouse and the obtained results show that it is able to collect inventory data remarkably faster than a human operator and that it is possible to locate items in the warehouse by using their SSI. Furthermore, the performance of the proposed blockchain-based architecture was evaluated in diverse scenarios.

**Supplementary Materials:** The following video is available online at http://www.mdpi.com/1424-8220/19/10/239 4/s1, Video S1: Blockchain-based UAV performing a warehouse inventory.

**Author Contributions:** T.M.F.-C. and P.F.-L. conceived and designed the system; O.B.-N. built the drone, O.B.-N., T.M.F.-C., I.F.-M. and P.F.-L. performed the experiments; P.F.-L. and T.M.F.-C. wrote the paper.

**Funding:** This work has been funded by the Xunta de Galicia (ED431C 2016-045, ED431G/01), Centro singular de investigación de Galicia accreditation 2016-2019 through the CONCORDANCE (Collision avOidaNCe fOR UAVs using Deep leArNing teChniques and optimized sEnsor design) project, the Agencia Estatal de Investigación of Spain (TEC2016-75067-C4-1-R) and ERDF funds of the EU (AEI/FEDER, UE).

**Conflicts of Interest:** The authors declare no conflict of interest.
