author: Lam Duc Nguyen; Arne Bröring; Massimo Pizzol; Petar Popovski
bibliography: main.bib
title: Analysis of Distributed Ledger Technologies for Industrial Manufacturing

# Introduction

Industrial Internet of Things (IIoT) is a recent concept that gained traction with the emergence of the wireless 5G technology and it is already exhibiting a great impact within the manufacturing domain. The general trend is to embrace digitalization and automation towards manufacturing plants that act as cyber-physical systems. This results in an increasing number of smart devices with sensors and actuators that are being integrated in industrial automation processes. In parallel, local edge computing infrastructures are being built up in manufacturing plants, which provide resources for advanced computing and henceforth the basis for next generation IIoT applications. The key economic driver behind this technological evolution is the increase in the production flexibility. This allows for smaller lot sizes and more individualized products for customers. These trends are supported by business models, such as manufacturing-as-a-service, where manufacturing facilities are utilized more flexibly by numerous tenants who utilize the machines in the plant, which are offered by different providers. These economic forces drive manufacturing plants towards an increase in technological complexity and require improvements in system reliability, intelligence, and trustworthiness during operation. Especially the opening of the manufacturing plant's ecosystem to a diverse set of involved parties poses many challenges for manufacturing enterprises to satisfy the trust requirements of multi-partner collaboration .

Distributed Ledger Technology (DLT) can be used to address those trust and privacy challenges in the manufacturing environment of the future, e.g., to transparently store machinery's usage data as a basis for pay-per-use business models on the manufacturing shop floor. A DLT is a distributed ledger of transactions—rather than being kept in a single, centralized location, the information is held by all the nodes of a network. In general, all these network nodes have copies of the same ledger. This removes the need for a third-party to assure that rules are being implemented correctly, instead, this is implicitly done through a decentralized system. Although the most widely known instance of DLT is Blockchain, and, specifically, the most popular decentralized digital currency based on Blockchain is Bitcoin , the transactions on a DLT do not have to be financial. In essence, a transaction simply represents a change in state for whichever data point the DLT's stakeholders want to track. DLTs are driven by consensus: when a node or a *DLT-client* initiates a transaction, its details are broadcast to the entire network, checked by other nodes and accepted if there is consensus. *DLT-clients* are considered as lightweight devices which have limited resources and just initiate transactions, as well as transmit transactions to *DLT-managers* to validate. When the DLT takes the form of a Blockchain, once a transaction has been validated, it is bundled with other transactions into a block of data. Each block is secured via a cryptographic algorithm. This results in a unique signature for each block known as a hash. These blocks are then ordered sequentially into a chain of blocks, with each block also containing the previous block's hash. This makes it extremely difficult to tamper with a block, as altering a single piece of data would result in a different hash value, making it evident to the DLT's users and causing the transaction and block to be rejected.

In short, DLTs allow the storage of transactions in immutable records and every record is distributed across many nodes. Thus, security in DLTs comes from the decentralized operation, but also from the use of strong public-key cryptography and cryptographic hashes. The key benefits of the integration of DLTs into manufacturing systems are: i) auditable and guaranteed immutability and transparency for stored data (e.g., machine usage data, sensing data about machine conditions, or logs about user/technician engagements), ii) no need for a third party to assure the rules between the different parties in the manufacturing ecosystem are met, iii) enabling security and privacy of information in manufacturing networks in conjunction with others techniques e.g, private transactions and private channels, which is urgently needed as more than 25% of cyber attacks will involve IoT.

To showcase these benefits and to have a realistic use case as an example for our studies, we implement in this work the DLT-based application of *shared manufacturing*, which relates to the economic driver of 'flexible production'. Specifically, a robot arm, as part of a production cell with multiple machines, is offered by a provider, who allows different tenants of the plant the usage of the robot arm, while expecting a usage fee. In this application, the DLT is required to capture the usage times of the robot arm through the various tenants, which is then the basis for a correct billing and payment for usage time. Some parts of this process can be done automatically with smart contracts. These involve two entities turning a business contract into code that recognizes actions on the DLT. For example, a smart contract might recognize that a rental of a machine from "provider A" to "customer B" on a certain date for a specific time period should be for a specific price. This simplifies processes that take significant time to check. This structure gives DLT participants confidence in their transaction without the need to trust each other. Nor do they need to agree on a trusted third party to make sure they're both following the rules. Because the ledger of transactions is consensus-based and distributed, records stored in it cannot be erased or changed.

To be able to implement the above described application and reap the described benefits, the system designs of current manufacturing plants need to be adjusted to be able to accommodate the operation of a DLT and overcome certain limitations: First, today's computation infrastructures of industrial manufacturing plants are typically designed as centralized systems, where cloud services perform data aggregation and analysis. While the manufacturing infrastructure comprises a multitude of IoT devices and sensors that collect data and have only little computing power, the gathering and processing of data in a centralized cloud service may lead to network overload and single points of failure . To setup a DLT network in such an environment, a sufficient amount of local computing capacity needs to be available and, potentially, edge computing facilities can be integrated in the computation infrastructure. Furthermore, industrial communication systems have been traditionally designed for reliable operation in a noisy factory environment, employing mainly wired and proprietary communication technologies to connect sensors, actuators, and controllers. Nevertheless, with the emergence of IIoT, future factories will increasingly rely on diverse communication technologies, including wireless standards, to ensure reliability, interoperability, and remote operation and control of production processes through the Internet. These wireless links are potentially less reliable and are more constrained, which needs to be considered, when operating a DLT network. From these limitations regarding the system infrastructure, we derive the key *research question* of this work: *"What is the computation and communication overhead that results from the operation of a DLT network in a manufacturing environment?"* The answer to this question will be critical to understand for future research on applications of DLT in manufacturing, as well as for practitioners who want to deploy a DLT network in a manufacturing plant.

The use of DLT in manufacturing has received attention from both academia and industry because of its promise for easing supply chain and manufacturing operation management problems due to its advantages in transparency, traceability, and security . In industry, Bosch increasingly connects their products to the IIoT in order to directly participate in the digital economy. The goal is to build an *Economy of Things*, which will be based on DLT . Another example is a concrete solution by Siemens, which enables their *Mindsphere* IIoT platform to track products of the food and beverage industry transparently throughout their entire life cycle based on DLT . *MindSphere* exploits all useful information before forwarding only a crucial subset to the distributed ledger. The DLT then makes sure the collected data is safe and transparently accessible to everyone who is part of the ecosystem. In academia, Li et al. introduced a distributed P2P system that improves the security and scalability of the cloud-based manufacturing platform based on DLT. Danzi et al. analyze the communication aspects in terms of delay and overhead between IoT devices and Blockchain network. The authors demonstrate that, if the statistics of account updates and the channel state are known, the lightweight IoT clients can construct a list of events of interest that provides a predictable average communication cost. In addition, a survey about performance of different Blockchains is conducted, but the work mainly focuses on theoretical aspects, and lacks a detailed analysis in specific application areas such as manufacturing. Fu et al. presented an innovative environmentally sustainable DLT-energized strategy for the fashion apparel manufacturing industry. Yu et al. proposed a DLT-based service composition architecture for manufacturing. In general, the public DLT-based applications are characterized by the distinctive metric of computational trust.

In order to be able to answer our research question, we extend state-of-the-art through the following research contributions:

-   General analysis of different DLTs and their capabilities when used in industrial manufacturing environments;

-   System design for DLT-based IIoT manufacturing systems that can integrate and adapt multiple features and components;

-   Evaluation of communication and computation overhead of different DLTs in resource-constrained IoT networks. This benchmark of different DLTs for manufacturing scenarios will help interested parties to understand the trade-offs in DLT-based systems.

The remainder of this paper is organized as follows. In the next section, we present the results of this study. First, we present a general analysis of five different DLT platforms. Second, we introduce a system design for using DLT in industrial manufacturing. Third, we implement the shared manufacturing use case and perform a performance evaluation of the five different DLTs. Finally, we discuss our findings and indicate avenues for future research.

# Results

In this section, we first study five different DLT platforms, then we propose a general framework to integrate DLT in manufacturing. Finally, we implement the use case of shared manufacturing and conduct the evaluation.

## Analysis of DLTs for Industrial Manufacturing

Although a large number of DLTs are available, within the scope of whic work we have selected five representative DLT platforms that are either already used or appear as most promising for manufacturing environments: Hyperledger Fabric, Ethereum, Quorum, Solana, and IOTA. The overview comparison of these DLTs is shown in Table .

|  | **Hyper. Fabric** | **Quorum** | **Ethereum** | **IOTA** | **Solana** |
|:---|:---|:---|:---|:---|:---|
| *DLT type* | Private | Private | Public / Private | Public / Private | Public / Private |
| *Goals* | Open DLT framework | Open, based on Ethereum | Broad ecosystem | Lightweight | High scalability |
| *Application* | Enterprise DLT | Enterprise DLT | DApps | IoT | DApps |
| *Governance* | Linux Foundation | ConsenSys | ETH Foundation | IOTA Foundation | Solana |
| *Cryptocurrency* | N/A | N/A | Ether (ETH) | MIOTA | SOL |
| *Consensus* | Pluggable | Voting Protocol | PoW | Tangle | PoH |
| *Smart Contract* | nodejs, go, java | Solidity | Solidity | Solidity, Go, Rust | Rust |
| *Throughput* | $\sim$`<!-- -->`{=html}2000 tps | $\sim$`<!-- -->`{=html}100 tps | $\sim$`<!-- -->`{=html}100 tps | 1000$\sim$`<!-- -->`{=html}1500 tps | $\sim$`<!-- -->`{=html}1400 tps |
| *Latency* | $\sim$`<!-- -->`{=html}250 ms | $\sim$`<!-- -->`{=html}414 ms | $\sim$`<!-- -->`{=html}2150 ms | $\sim$ 258 ms | $\sim$ 500 ms |

Comparison of different enterprise DLT platforms

Each DLT can be categorized as public, private, or hybrid, where the latter one can support features of both public and private ones. *DLTs* allow any user to pseudo-anonymously join the DLT network and do not restrict the rights of the nodes on the network. We are investigating in this paper the public DLTs Ethereum, IOTA, and Solana. However, for the implementation of our use case within a manufacturing plant such public DLTs are used in a private deployment by installing local networks. In contrast, private DLTs restrict access to their network to certain nodes and may also restrict the rights of nodes on the network. In this paper, we are investigating the private DLT platforms Hyperledger Fabric and Quorum. The identities of the users of a private DLT are known to the other users of that private DLT. In a Hybrid DLT, every transaction can happen quickly in its own private chain and commits to the public chain only happen as and when necessary, e.g., when public verification is required. This provides the immutable trust from the Blockchain as well as the scaling from private DLTs. Layer 2 solutions and side-chains are variations of this concept.

Besides their type, the five DLTs have different goals and applications in focus. Hyperledger Fabric and Quorum are both aiming to offer a open foundation for new components to build a broad ecosystem that supports enterprises with various functionalities to deploy their own private DLT. Ethereum has a large community of developers and already an established ecosystem that focuses on decentralized applications (DApps), e.g., for decentralized finance. Solana follows a similar application focus, while aiming for higher scalability than Ethereum. IOTA's focus is on IoT applications and therefore aims to support DLT participants with a small footprint.

IIoT applications in the manufacturing environment will involve many stakeholders with different roles, functionalities, and information with access rules, identities and security factors. An important factor to provide security is the support to validate transactions generated by participating nodes. While Hyperledger Fabric and Quorum are suited solely for private setups, Ethereum, IOTA and Solana are designed for public networks, but can also be configured for private purposes. In terms of security and confidentiality, public networks can show certain advantages over private ones, especially if they are able to provide transparency and distributed storage. Besides, the more users a public DLT has, the more secure it is. However, for enterprise use (i.e., also for typical manufacturing scenarios) public DLTs are not ideal as companies deal with highly sensitive data and cannot allow arbitrary users to join their network. Also, private DLTs provide very low or no fees for validation and a faster consensus process. However, a private DLT can be altered by its owners, making it more vulnerable to hacking. Besides, only Hyperledger Fabric supports data confidentially by default; this is done via in-band encryption and guarantees the privacy of data by creating private channels (e.g., to setup for departments within an organization). Therefore, Hyperledger Fabric allows for authorization with trusted Certificate Authority per channel. These features are vital in a trusted IoT system for enterprises.

Each DLT platform deploys a different consensus mechanism. Ethereum uses the Proof-of-Work (PoW) consensus that requires involved parties of a network to expend effort solving a mathematical puzzle to prevent anybody from gaming the system. PoW consensus consumes significant computing and energy resources, which is not suitable for resource-limited systems. Quorum, as an enterprise version of Ethereum, uses a voting-based consensus protocol. This consensus protocol achieves consensus on transactions and key network decisions by counting the number of votes cast by nodes on the networks and not consuming more energy for verification as compared to PoW. IOTA uses "little" PoW for preventing spamming attacks. In Ethereum, doing PoW is to receive the power to define the truth, the node with more power can solve the PoW faster and consume more energy. Meanwhile, IOTA use PoW with lower difficulty to prevent spamming and to allow transactions to be attached in the Tangle. The "little" PoW is still similar to original PoW but with lower difficulty. Hyeperledger Fabric modularized the consensus part among distributed peers in an ordering service, so that this platform allows users to choose their preferred algorithm, e.g., CFT (crash fault-tolerant) or BFT (byzantine fault-tolerant) ordering. Finally, Solana introduces a new consensus algorithm called Proof-of-History which allows timestamp field to be built into the blockchain itself instead of using values of timestamps as PoW DLTs. Whereas other DLTs require validators to talk to another in order to agree that time has passed, each Solana validator maintains its own clock by encoding the passage of time in a simple SHA-256, sequential-hashing Verifiable Delay Function (VDF).

Table specifies the smart contract programming language supported by the DLT. Smart contracts act as autonomous entities on the ledger that deterministically execute logic expressed as functions of the data that are written on the ledger. Therefore, smart contracts can be established to have automatic reactions from the DLT network to specific events. For example, in the use case of shared manufacturing, smart contracts can be used for restricting, tracking and payment for the usage of the rented machinery. The smart contract feature is currently supported by Ethereum, Solana and Hyperledger Fabric (called 'Chaincode'). In IOTA, a smart contract is called Quobic which is now deprecated and the new beta version of smart contract is developing.

Furthermore, Table  states the performance characteristics of the DLTs. These values have been acquired both through our own experiments and the data available in the literature. These measures are of vital importance for IoT applications, particularly in manufacturing, where a large number of sensors may generate millions of data points per day. This requires high efficiency of the consensus mechanism, including the way in which transactions are processed by the peers, known as *endorsing peers* in Hyperledger Fabric, validators in Solana, and full nodes (peers) in Ethereum. Specifically, we have Solana, with 600 nodes and around 1000 validators. Currently Solana is hosting around 340 apps. Meanwhile, Ethereum has over 3000 Dapps running on its network. Regarding latency, the transaction confirmation time must be sufficiently short to avoid queuing in the DLT and to ensure consistency in the ledgers. The confirmation time of an Ethereum transaction in a public network is around $25$ seconds in public networks. This value indicates that consensus over public networks may not be suitable for real-time IoT applications. However, other DLT platforms can achieve much lower confirmation times . Note that in Table the transaction confirmation time is included in the end-to-end latency, which however does not account for the communication latency at the radio access networks.

Another important performance feature of the DLTs is related to the CPU usage and resulting energy consumption. The idea that DLT technologies and crypto-assets consume an excessive amount of electricity has been at the heart of recent discussions around this technology. The energy consumption of a DLT protocol should not be equated with its environmental footprint. Indeed, many use cases related to DLT technologies and crypto-assets may even contribute to improving the environmental footprint, in particular by using the surplus of decarbonised energy in certain geographical areas where the need for electricity is lower than the level of production. In the scope of this work, we study the carbon footprint of the different selected DLT platforms within the local testbed of the shared manufacturing use case.

The charge of fees to process the transactions, commonly known as *gas* is yet another factor to take into account to select the appropriate DLT. These may greatly increase the operational costs of the network, which negatively impacts the throughput of the DLT. On the one hand, transaction fees pose a problem in massive IIoT scenarios if the generation of a large number of transactions is essential. On the other hand, these fees may contribute to minimizing the amount of redundant transactions generated by the sensors, which in turn offloads the DLT. In industrial manufacturing domain, the required fee for generating transactions within a company or among some cooperative organizational setup may not be suitable. In addition, businesses have always required a reasonable degree of privacy as well as control over their networks, so that publishing the data on a Blockchain is not reasonable and potentially unsafe. Therefore, we consider only private Blockchains for the enterprise scenario.

## System Design for using DLT in Industrial Manufacturing

The proposed system design is described in Figure . It comprises four key parts as described below.

**DLT System:** This component includes all modules to build various features of DLT technologies such as consensus, smart contract, data authorization, identity management, and peer-to-peer (P2P) communication. These components must ensure that every change to the ledger is reflected in all copies in seconds or minutes and provide mechanisms for the secure storage of the data generated by IoT devices and parameter configurations. There are numerous DLTs with different characteristics that may be beneficial for different target applications. The DLT nodes can be located everywhere and connected with base stations via the Internet.

**Physical Machines:** This component consists of physical robots, machines, and IoT sensor devices which collect the data and publish to the distributed ledger for accounting or analyzing purposes.

**Plant Edge System:** Even though DLT-based solutions offer significant countermeasures to secure data from tampering and support the distributed nature of the IoT, the massive amount of generated data from sensors and the high energy consumption required to verify transactions make these procedures unsuitable to execute directly on resource-limited IoT devices. Instead, edge servers with high computation resources can be used to handle real-time applications and to further increase the degree of privacy (e.g., through cloud computing) . The edge network is a potential entity to cooperate with the DLT network in computationally heavy tasks and return the estimation results (e.g., from solving proof-of-work (PoW) puzzles, hashing or algorithm encryption) to the DLT network for verification.

**External Services:** The devices of the manufacturing environment are typically resource-constrained with limited storage space and low computation capacity. Hence, external infrastructure which operates on the edge may be incorporated to provide external services, such as storage and computing. For example, the Interplanetary File System (IPFS) is a distributed file storage system that can store data generated from IoT networks and return a hash to the ledger based on the content of the data. Since the ledger cannot handle and store the massive amount of manufacturing data collected by the sensors, machines, and robots, the service provided by the IPFS is a vital component. The default configuration of IPFS connects to the global distributed network. In some cases regarding to privacy and confidentiality, a private IPFS network is preferred over connecting to the public IPFS network. In our scenario, we prefer to configure IPFS privately in a local cluster. Second, we introduce the application of payment channels to sharing manufacturing use case because of its natural advantages. In specific, a Payment Channel is a process where customers can make multiple transfers with e.g, plant operator, without sending a transaction to the DLT. Once the final transaction occurs between the participants the recipient can claim their funds by submitting one final transaction to the Smart Contract on the ledger. This allows both parties to avoid fees involved with multiple transactions. Smart Contracts can be an agreement about the rental time, specific tasks between customers and plant operators, or smart contracts created at the beginning of the process of payments. In addition, a Digital Identity Management (DID) could be added to support managing identity of participant devices in a distributed manner.

## Performance Evaluation of DLTs in a Shared Manufacturing Use Case

|  | ***DLT-manger-1*** | ***DLT-manager-2*** | **DLT-Client 1** | **DLT-client 2** |
|:---|:---|:---|:---|:---|
| *Devices* | Siemens Microbox | Laptop | Rapsberry Pi 3+ | Raspberry Pi 3+ |
| *RAM* | 4GB | 8 GB | 1 GB | 1GB |
| *Connectivity* | Ethernet | Ethernet | Wifi | Ethernet |
| *Capacity* | Intel(R) Core i7-351UE CPU @ 1.70GHz x4 GHz | Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz 1.9 GHz | Quad Core 64 bit ARM cortex at 1.2 GHz | Quad Core 64 bit ARM cortex at 1.2 GHz |

Testbed Settings

In this section, we analyze the application of the Shared Manufacturing use case and study its performance. The application uses DLT to automate the management of rentals of industrial robots, where the manufacturing plant operators and their customers can make agreements without third parties and the associated delay.

Along with data sharing and vehicle sharing, the machine sharing concept in industry manufacturing has been recently identified as a key innovation for implementing the next industrial evolutionary step. Open and shared manufacturing factories are composed of a number of industrial robots and other production machines that can be rented by customers. The advantage over traditional manufacturing plants is that such plants can have a higher workload and less idle periods, which in turn can make the production cheaper. Therefore, production tasks need to be efficiently allocated on the available machine resources under consideration of system performance.

Our shared manufacturing application scenario is described in Figure  . As an initial step (1), the plant operator of a factory publishes the list of machine resources which are available for rent. Thereby, each machine has a unique ID and described capabilities to perform specific jobs. A *manufacturing marketplace* running on a DLT-based network can be implemented in such an environment to offer access to those machine descriptions. In the DLT-based manufacturing network, smart contracts are running to receive requests from customers rent machines (step 2) and match them to resources offered by the plant operator (step 3). In addition, the rules and agreements, e.g., about the rent period, specific tasks, or payment methods between plant operator and customers are pre-defined in the smart contracts and executed autonomously. The customers can check the list of available machines published by the plant operator, and if the customers have a relevant job coming up, they can request the suitable machines via smart contracts. This is the first difference between the DLT-based and non-DLT shared manufacturing system. In a non-DLT based system, a plant operator and customers could not work directly by exchanging messages without the guarantee about the trust of contracts as well as payment. This guarantee requires a third-party to complete the deal. After DLT-based smart contracts executed and mapped the requests from plant operator and customers, the plant operator account will unlock automatically the available machines (step 4) and assign the control of the machines to customers. Then, the customers can start control and program the machines for their jobs (step 5), which are then executing these jobs (step 6). Compared to standard shared manufacturing, the second innovation in DLT-based systems is that we implemented a layer 2 *payment channel* between the plant operator and customer for micro-payments (step 7).

To study the communication and computation overhead resulting from DLT in manufacturing systems, we have implemented the above described *shared manufacturing* application in a private setup as shown in Figure . The setup involves the DLT components *DLT-manager 1 and 2* and *DLT-clients*. The *DLT-manager* has a high computation capacity and enough storage for a full ledger with all the information and data. The *DLT-clients* are lightweight and are limited in terms of computation and resources. The *DLT-clients* can query and access the data from the ledger without downloading the full chain of blocks. The *DLT-managers* are implemented in two different equipments: as a Siemens Microbox and a Macbook Pro. The *DLT-clients* are implemented in Raspberry Pi 3+. The specifications of these devices are found in Table . *DLT-manager-1* and *DLT-manager-2* are connected via Ethernet, and communicate with DLT-clients via local WiFi. The communication method can be extended to other long-range communication or global internet depending on specific scenarios. The distributed ledger is deployed in the DLT Managers. We have implemented five types of *DLTs*, namely Ethereum, Quorum, IOTA, Hyperledger Fabric, and Solana.

During our evaluation, the DLT-client sends 10 transactions per second to the ledger, which is hosted by the DLT-manager-1 and -2. The reason why we set 10 transactions per second is that traffic from UR5 robots to a server is usually low at around 1-5 updates per hour or per day, depending on the specific scenario. Therefore, we stress the network with 10 TPS to test the efficiency of the system. In addition, we assume that the time required for completing a task with a robot could be a day or a week, so the robot could update the task progress and sensing information in a period of minutes or hours is sufficient. By recording the CPU usage percentage of the DLT-specifc processes, we have observed the computation overhead in each case of the 5 selected DLT platforms. Looking at the DLT Managers, we have found Ethereum as an outlier, as it requires by far the most computation time of around *85%* of CPU as shown in Figure due to the usage of the Proof of Work (PoW) for the consensus and verification process. The *non-PoW* DLTs, Solana, Hyperledger Fabric and Quorum, require in our private network setting only around *1-3%* CPU usage in both *DLT Manager 1* and *DLT Manager 2*. Similarly, the IOTA platform uses *PoW* only rarely in order to prevent spam attacks, so the CPU usage of the DLT Managers is relatively low, similar to Hyperledger Fabric and Quorum. On the DLT Client component, the CPU usage is primarily the generation and transmission of transactions, so that these DLTs require around 5-10% CPU usage of the Raspberry Pi as shown in Figure .

Figure and show the communication overhead of the five different DLTs in our shared manufacturing setup. The Hyperledger Fabric produces more network traffic than the others on the DLT Managers. The reason is that the network architecture of Hyperledger Fabric is optimized for an enterprise environment with high security requirements, where the raw data need to be formatted for signed transaction proposals, then going through the complex endorsement and validation process, before attachment to the Blockchain. This process introduces more communication overhead. IOTA produces the lowest traffic on the DLT Managers thanks to the design based on the Tangle. Specifically, the interconnected Tangle infrastructure does not require total verification across the whole ledger. Instead, all parties are verifying simultaneously and, as a result, the energy and time required to complete transactions are shortened. In addition, Tangle's verification process purports to ensure that there are no duplicate transactions that would lead to double-spending. On the *DLT-clients*, the communication overhead is mainly coming from publishing the collected data via formatted transactions to DLT managers. In specific, a single transaction in IOTA consists of *2673 trytes* which is equivalent to *1589 bytes*, if encoded, a Ethereum transaction includes around *109 bytes* of header, and no limited metadata , Hyperledger Fabric transaction sizes depends on the type of transactions, for example, *3.06 kB* for spend and *4.33 kB* for mint. The overhead of a Solana transaction includes *64 bytes* signature and maximum *1232* bytes for given metadata.

In order to analyze the scalability of the integration of Blockchains in manufacturing, we simulate Blockchain networks with a varying number of *DLT managers* and *DLT clients*, from $4$ to $16$ nodes. The number of input transactions per second is generated from 20 TPS to 100 TPS. In this experiment, we choose to simulate the Ethereum Blockchain network. The simulation is extended from the framework of Blockchain for Swarm Robotics. Specifically, both *DLT-manager* and *DLT-client* is executed in separated Docker Containers. The simulated robots are considered as light Blockchain clients and periodically published data to the managers for validation. The results in Fig. show that the more the number of *DLT-managers* increases, the more the number of transactions validated per second decreases. The reason is that the more number of validators leading to the more number of transactions to be validated and exchanged among managers, as well as adding the system some delays in validating transactions. We observe that increasing the number of participants raises the challenges e.g, scalability, throughput, latency. Hence, private Blockchains are suitable for industrial IoT manufacturing environments. However, hybrid DLTs which provides flexibility on data visibility without compromising security also could be immense potential.

Based on the CPU usage and the utilized computing hardware, we determined the energy consumption of the five selected DLT platforms and computed the carbon footprint. We assume that electricity for running the computational operations is consumed and produced in Germany. As a measure of carbon intensity of the German energy mix, calculated in a life cycle perspective, we used data from the life cycle database ecoinvent v.3 cutoff system model. In particular, the dataset *Market for electricity, low voltage, DE* was chosen, which represents an average low-voltage energy mix for Germany. We obtained the life cycle impact of producing *1 kWh* electricity according to this version of the database via the software *SimaPro* and using the default IPCC Global Warming Potential (GWP) method with a time horizon of 100 years . This resulted in a value of global warming impact of *0.540* *kg -eq / kWh* that represents the impact of all greenhouse gases emitted in the electricity production process and upstream activities in a life cycle perspective. This value was further used to calculate the total carbon footprint of the computation based on its energy requirements. The results are shown in Table . We observe that the annual ** generated through PoW consensus is significantly higher than that of non-PoW Blockchains. The private Ethereum DLT produced around *26692 $\cdot 10^{-6}$* *kg -eq/hour*, which is equivalent to the average of *4.3* charged smartphones. This compares to around *203 $\cdot 10^{-6}$* *kg-eq/hour*, *211* *kg-eq/hour*, and *198* *kg -eq/hour* from Hyperledger Fabric, Quorum, and IOTA, and Solana respectively. Note that all results are extrapolated to the utilization of our private DLT setup for the shared manufacturing application over an operation day.

| **Platform** | **Power of Machine (kW)** | **Energy consumed on Average (kWh)** | **Avg. CPU Usage for Blockchain Operation (%)** | **Energy Consumed for Blockchain operation (kWh)** | **Greenhouse gas (GHG) emission in DE (kg -eq/kWh)**\*\* | **GHG emission per blockchain operation (kg -eq)** |
|:---|:---|:---|:---|:---|:---|:---|
| *Hyper.Fabric* | 0.06 | 0.06 | 0.625% | 375 $\cdot 10^{-6}$ | 0.540 | 203 $\cdot 10^{-6}$ |
| *Ethereum* | 0.06 | 0.06 | 82.35% | 49392 $\cdot 10^{-6}$ | 0.540 | 26682 $\cdot 10^{-6}$ |
| *Quorum* | 0.06 | 0.06 | 0.65% | 390 $\cdot 10^{-6}$ | 0.540 | 211 $\cdot 10^{-6}$ |
| *IOTA* | 0.06 | 0.06 | 0.61% | 366 $\cdot 10^{-6}$ | 0.540 | 198 $\cdot 10^{-6}$ |
| *Solana* | 0.06 | 0.06 | 0.61% | 366 $\cdot 10^{-6}$ | 0.540 | 198 $\cdot 10^{-6}$ |

Carbon FootPrint of private DLT testbed with 5 *DLTs* calculuated in Germany market running per hour

# Discussion

We have seen that deploying a DLT in an industrial manufacturing environment allows to realize novel business cases. Choosing the right DLT platform for industrial use cases, such as the one we elaborated above, is challenging, as their are many options available. Therefore, we have conducted here an evaluation of five of the most popular and promising DLT platforms and proposed how to integrate those into a physical manufacturing system.

A clear observation is that Ethereum is an outlier in terms of CPU usage, due to its PoW consensus algorithm, which of course also results in high energy consumption. Therefore, we can conclude that Ethereum and other PoW DLTs should, in general, not be used in the envisioned manufacturing environments. In order to still be able to use many of Ethereum development tools, a plant operator can use Quorum, which is an enterprise version of Ethereum. Both Quorum and Hyperledger Fabric show a similar performance in our local evaluation regarding CPU usage. However, Hyperledger Fabric introduces higher communication overhead as compared to Quorum. Therefore, in an environment with communication restrictions, the operator could opt for Quorum out of these two by simply looking at slight performance advantages. IOTA, which is specifically designed for IoT networks, requires the lowest CPU and communication overhead and can hence be favoured by an operator that has strong requirements in this regards. However, IOTA's smart contract mechanism is still under development and also the tooling support is not as strong. Finally, Solana is a public Blockchain network with a focus on achieving high scalability. In our local network, Solana performed similarly to Quorum in terms of communication overhead as well as CPU usage.

The results measured from our local experiments can be considered as a benchmark regarding sustainability aspects in specific shared manufacturing use cases. In the scope of this research, we evaluated the greenhouse gas emission per Blockchain operation based on energy consumed by Blockchain activities. For example, IOTA foundation provided an energy benchmark for the IOTA network, which shows results that are similar to our experimental results. In terms of Hyperledger Fabric, we have used Hyperledger Caliper for the benchmark evaluation. Referring to prior research, the energy consumed by beyond-PoW blockchains, such as Polkadot, Cardano, or Hedera Hashgraph, is within a range that is similar to the energy consumed in our experimental setup.

Looking towards the future, we see many benefits for the use of DLT in manufacturing, enabling a broad range of use cases and business models. The vision at the horizon is a truly *collaborative industrial IoT* in which *things* (such as machines in a manufacturing plant) ubiquitously and automatically interact without intervention of humans. This is fuelled by the capability to autonomously make (micro-)payments. This would empower devices, e.g., to rent cloud server capacity for additional computational capacity when required, to pay directly to other devices for access to the Internet, or automatically pay for electricity consumed. The current payment systems are not well suited for massive-scale micro-transactions due to high transaction costs and limited capacity. This calls for a vision of payments between things, which will be a small per transaction, but autonomous and running efficiently at a massive scale. Besides, the research on governance, security aspects, and optimal consensus mechanism could be considered as a future work.

# Acknowledgements

This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 957218 (Project IntellIoT).

# Author contributions statement

L.D.N and A.B proposed the idea, implemented the system, and drafted the main manuscript. P.P revised manuscript and derived the structure for the research. M.P analyzed the sustainability aspect regarding emission of the research. All authors contributed, edited, and reviewed the manuscript.

# Competing interests

The authors declare no competing interests

# Data Availability

The datasets used and/or analysed during the current study available from the corresponding author on reasonable request.


abstract: We present the first fully automated Sit-to-Stand or Stand-to-Sit (StS) analysis framework for long-term monitoring of patients in free-living environments using video silhouettes. Our method adopts a coarse-to-fine time localisation approach, where a deep learning classifier identifies possible StS sequences from silhouettes, and a smart peak detection stage provides fine localisation based on 3D bounding boxes. We tested our method on data from real homes of participants and monitored patients undergoing total hip or knee replacement. Our results show 94.4% overall accuracy in the coarse localisation and an error of 0.026 m/s in the speed of ascent measurement, highlighting important trends in the recuperation of patients who underwent surgery.
author: Alessandro Masullo[^1]; Tilo Burghardt; Toby Perrett; Dima Damen; Majid Mirmehdi
title: Sit-to-Stand Analysis in the Wild using Silhouettes for Longitudinal Health Monitoring

# Introduction

Novel concepts and technologies like the Internet of Things (IoT) for Ambient Assisted Living (AAL) or specific health monitoring enable people to live independently, to be aided in their recuperation, and improve their quality of life. Such systems often include multiple sensors and monitoring devices, producing large amounts of data that need to be analysed and summarised in a few, clinically relevant parameters . The transition from a sitting position to a standing one (StS[^2]) is one of the most essential movements in daily activities , especially for older patients suffering from musculoskeletal illnesses. StS has been linked to recurrent falls , sedentary behaviour and fall histories . Continuous monitoring of the StS action over a long period of time can therefore highlight important trends, particularly for subjects undergoing physical rehabilitation.

To the best of our knowledge, the automatic analysis of StS has not been attempted for long term monitoring and trend analysis. Some previous works have focused on automating the Sit-to-Stand clinical test, performed under supervised conditions and often in the presence of a clinician, e.g. . Shia et *al*.  suggested modelling the physics of the human body during stand-up transitions by using a motion capture suite. Their method was tested in the lab on 10 healthy individuals but this approach is clearly impractical for long-term monitoring. In , Galna et *al*. investigated the suitability of skeleton data extracted by the Kinect sensor to assess clinically relevant movements, showing that the StS timing can be accurately captured with errors comparable to the VICON motion capture system. Their method was applied in the lab on 9 individuals with Parkinson's Disease and 10 control subjects. Skeleton data was also used in to estimate the StS timing by using the vertical displacement of the head joint and a manual threshold. Their method was tested in the laboratory for 94 subjects and in participants' own homes for 20 individuals.

The detection of StS transitions can be seen as an action classification problem, and a large body of research has investigated the application of deep convolutional neural networks (CNN) for this task, for example . However, while these works enable high accuracy in action classification, they always make use of RGB or depth data, which is not compatible with the privacy requirements of home monitoring systems, for instance . As already addressed in , silhouettes constitute a valid alternative form of data that allows action recognition to be performed whilst respecting privacy requirements.

The aim of this work is to propose a novel approach to continuously monitor StS transitions in the wild and, while addressing privacy issues, to generate automatic trend analysis. For each StS transition, we measure the speed of ascent/descent as an indicator of physical function. We installed RGBD cameras (PrimeSense) in participants' own houses and recorded silhouette video data from 9 subjects in 4 different habitations, for a minimum period of 4 months, up to 1 year, under the auspices of the SPHERE and HemiSPHERE projects . Two of the participants, aged between 65 and 90, underwent total hip or knee replacement and we monitored them before and after their intervention. The remaining 7 participants, aged between 40 and 60, did not record any particular health condition that could affect their mobility. We show that our method can identify StS transitions into the wild with 94.4% overall accuracy and our measurement of the speed of ascent is comparable with the VICON motion capture gold standard in a supervised setting. Moreover, our analyses highlight important trends linked to the rehabilitation process, potentially allowing for surgeons to follow the progress of their patients remotely and anticipate possible complications.

# Methodology

Monitoring people in their homes poses stringent ethical restrictions on the type of data that can be recorded, analysed and shared, e.g. prohibiting the use of RGB data . To provide a privacy-compatible monitoring system (based on a user study ), we generate silhouettes and 3D bounding boxes from the RGB data and discard the raw pixel values immediately thereafter. We deployed one camera in each house (in the living room) and set it up at a similar height to have a comparable field of view.

Our proposed pipeline can be divided into three steps: pre-processing of videos, classification and StS measurement. First, the incoming silhouettes are cropped at the detected bounding boxes and resized, producing one video per individual. These videos are subdivided into short clips of 10 seconds each[^3], which are then classified with a deep CNN (detailed in Section ) into one of three categories: "Sit-to-Stand", "Stand-to-Sit" or "Other". The StS video clips only are then further analysed to measure the speed of ascent/descent using the 3D bounding boxes, as described in Section .

Contrary to previous works that have focused on StS duration , our method measures the speed of ascent/descent, defined as the maximal transferring velocity of the centre of gravity (CG) between the start and the completion of the StS movement . The speed of ascent/descent does not depend on a specific beginning or end of the movement, but rather on the maximum velocity. Thanks to this property, the speed of ascent/descent shows no significant difference between the Sit-to-Stand and the Sit-to-Walk movements , or the Stand-to-Sit and the Walk-to-Sit movements, making it a more suitable measurement for free-living monitoring.

## Classification

Inspired by the work from Carreira et *al*. , we built our classifier network using Inception modules with 3D convolutions, as presented in Figure . It was shown in our previous work that using very deep networks on silhouette data increases the computational cost without inducing any advantages. We therefore adopted a shallow architecture composed of 4 stacks of Inception modules, followed by a Long Short-Term Memory (LSTM) layer located between the last convolutional layer and the final fully connected layer. In our experiments, we found that the use of an LSTM module in addition to the 3D convolution produced the best results in classification accuracy.

The video sequences recorded from the participants' homes contained highly varied data, with video clips of StS transitions only constituting less than 1% of the whole dataset. To tackle this class imbalance problem , we under-sampled the "Other" class to match the size of the minority classes "Sit-to-Stand" and "Stand-to-Sit", sampling new random elements for each epoch. This ensured a balanced training and prevented the potential loss of useful data from the "Other" class.

## Speed of Ascent Measurement

The 10-seconds clip classifier provides a coarse time localisation of the StS transitions. To narrow the exact frame of the transition and measure the speed of ascent[^4], we employ data from the 3D bounding boxes, in particular the evolution in time of the upper edge. Let the 3D bounding box $B$ for the time interval $[t_\text{start},\ t_\text{end}]$ of a clip be $B\left(t\right) = \left[x_1(t), y_1(t), z_1(t); x_2(t), y_2(t), z_2(t)\right]$, where the indices 1 and 2 respectively represent the 'right', 'top', 'front', and 'left', 'bottom', 'back' vertices of the 3D box. Let us call $y_1 \equiv y_\text{top}$ the $y$ component of the top vertex, and the vertical speed of the subject can then be estimated as: $$\label{eq:derivative}
    V_y(t) = \pm\frac{d y_\text{top}}{dt} ~,$$ where the sign is $+$ for "Sit-to-Stand" and $-$ for "Stand-to-Sit" classes. Using the definition of speed of ascent as the maximum vertical velocity during the StS movement, we can then compute the speed of ascent $V_{\text{SOA}}$ as: $$\label{eq:speed_of_ascent}
    V_\text{SOA} = \max_{[t_\text{start},\ t_\text{end}]}\left\{V_y(t)\right\}.$$ It is important to note that the computation of Eq. () is only performed on those clips classified earlier as StS. In fact, its simplicity is built upon the accuracy of the classifier, which filters out all the other possible movements that might contain a vertical motion and are not StS transitions. A visualisation of this computation can be seen in Figure , showing a strong correlation between the vertical speed of the bounding box and the Sit-to-Stand action.

In order to reduce noise of the 3D bounding boxes, we adopted a Savitzky-Golay filter (`savgol`) as implemented in SciPy. The advantage of the `savgol` filter is that it replaces each data-point by the least-squares polynomial fit of its neighbours, allowing noise reduction and a simple analytical derivative of the polynomial. We used a kernel window size of 11 points and a polynomial of 3rd order. The vertical velocity can then be computed as the ratio between the filtered $y_\text{top}$ and the filtered time vector: $$\label{eq:savgol_deriv}
    V_y = \frac{\text{savgol}(y_\text{top},\text{ deriv=1})}{\text{savgol}(t,\text{ deriv=1})}$$

# Experiments

The architecture was built with 4 Inception modules , each composed of a sequence of (1) 3D convolutions, (2) batch normalisation and (3) activation ReLu, using respectively 16, 32, 64 and 128 filters. The last layer produces a set of convolutional features which are, once reshaped, 512 dimensional for 25 pseudo-time steps. The resulting features are fed into an LSTM module with 128 units, whose output is then fed into a 3D fully connected layer with *softmax* activation. The input comprises video clips of 100 frames, each 100 by 100 pixels, while the output is a 3 by 1 classifier.

We demonstrate the validity of our algorithm by assessing the StS video classifier and the speed of ascent/descent computation independently on two different datasets.

## Physical Rehabilitation Movements Data Set

The UI-PRMD dataset includes skeleton data from typical exercises and movements which are performed by patients during therapy and rehabilitation programs . It consists of 10 healthy subjects, performing 10 different movements 10 times each, and recorded simultaneously using a Kinect and a VICON (gold standard) motion-capture system.

In particular for our work, we extracted the Sit-to-Stand movement from the dataset and used the VICON motion capture data to validate our proposed approach. We generated 3D bounding boxes using the extent of Kinect skeleton joints and we compared the speed of ascent with the one computed using the centre of gravity (CG) from the VICON data[^5].

The curves in Figure a show a comparison of the true speed of ascent, computed using the VICON CG (blue curve), and our estimation using the Kinect head joint (orange). In both cases, the vertical derivative was obtained for all the StS transitions available ($N_\text{StS}=100$) and averaged to highlight possible discrepancies, while the time was normalised using the beginning and the end of the StS trasition. The two curves exhibit a very similar pattern, with a maximum value (i.e. the speed of ascent) which differs by 23.3%. This amplification of the maximum vertical speed results in a bias error of the speed of ascent of about 0.026 m/s, or 28.3% of the average measurement. In spite of this bias error, the correlation between our estimated speed of ascent and the ground truth is more than 92.8%, as shown in Figure b. While this bias could be mitigated by appropriate calibration, the aim of this work is to investigate trends in the speed of ascent/descent and the high correlation between our measurement and the ground truth is more than sufficient for its application.

## SPHERE data

The SPHERE project (Sensor Platform for Healthcare in a Residential Environment) developed a multi-modal sensing platform aimed to record data from up to 100 houses in the Bristol (UK) area for healthcare monitoring. Each house was equipped with a variety of sensors, including RGBD cameras, which were used to generate human silhouettes and 2D/3D bounding boxes via the OpenNI API , from different communal spaces: living room, kitchen and hall. The HEmiSPHERE (Hip and knEe study of SPHERE) project is an UK National Health Service application of SPHERE sensors within the homes of patients undergoing a total hip or knee replacement.

In this work, we present data collected from the living room of 4 different houses, described in Table , two belonging to the HEmiSPHERE cohort and two belonging to the SPHERE one. This subset includes a total of 1,177,082 video clips, of which 5,645 are StS transitions and the rest belong to the "Other" class. The videos were manually labelled by the authors using the MuViLab annotator tool[^6] and were used for cross-validation as per Table . The discrepancy between the number of Sit-to-Stand and Stand-to-Sit transitions can be explained by the type of silhouette detector adopted (OpenNI), that was optimised for standing poses. This increases the chances of detecting a person walking and sitting down and hence the number of Stand-to-Sit transitions recorded.

| **Id** | **Duration** | **Occup.** | **\#Other** | ** #Sit-to-Stand** | **\#Stand-to-Sit** |
|:---|:--:|:--:|:--:|:--:|:--:|
| **House *A*** | 4 months | 2 | 107404 | 339 | 491 |
| **House *B*** | 3 months | 2 | 266853 | 1289 | 2051 |
| **House *C*** | 9 months | 4 | 416628 | 297 | 1054 |
| **House *D*** | 6 months | 1 | 380552 | 54 | 70 |

Description of the data from the 4 houses: 2 cohorts of SPHERE (bottom two rows) and HemiSPHERE (top two rows).

## Classification

Data from homes *A*, *B* and *C* was used to train and validate the network (described in Section ) using a cross-validation strategy, as depicted in Table . Data from *House D* was left out of this procedure and was only used to generate the trend plot. Results are presented in Table  and show an overall accuracy of 94.8%, 95.0% and 93.5% for the three validation folds, computed by averaging the accuracy of the three classes. The average accuracy across the three folds is 94.4%. Details of the classification results are presented in Figure , showing the confusion matrices for each validation fold.

Particular attention must be paid to the false positive scores. The number of "Other" videos mis-classified as StS was found to be 1.63%, producing 28119 false positive against the 6548 correctly identified StS transitions. While these values might potentially damage our score, a manual inspection of the false positives concluded that many of the mis-classification videos are, indeed, visually similar to StS transitions. This included subjects interacting with the environment for long periods of time while standing up, raising from the floor, kneeling while doing exercises or housekeeping chores. Although these movements are not strictly StS transitions, they still involve a vertical motion that requires physical effort. As we will show in the next Section, although the presence of these false detection increases the uncertainty of our measurements, it does not hamper the calculation of the trend plots.

| **Fold** | **Train** | **Validate** | **Stand-to-Sit** | **Sit-to-Stand** | **Other** | **Overall** |
|:--:|:--:|:--:|:--:|:--:|:--:|:--:|
| 1 | House C, B | House A | 97.2% | 91.2% | 96.0% | 94.8% |
| 2 | House C, A | House B | 95.2% | 93.2% | 96.5% | 95.0% |
| 3 | House A, B | House C | 96.7% | 86.0% | 97.9% | 93.5% |
| Average |  |  |  |  |  | 94.4% |

Cross-validation accuracy results, with $94.4\%$ overall average accuracy.

## Trend plots

Following the classification, the speed of ascent/descent was computed for all the video clips detected as StS transitions and it was averaged per week. The resulting trend plot, for *Fold 2* as an example, is presented for the manually labelled video clips (*Manual trend*) in Figure a, and for the automatic labels (*Automatic trend*) in Figure b. The reader is reminded that one of the occupiers of this house underwent a total hip or knee replacement intervention and the surgery day is marked with a solid black line. Before surgery, the speed of ascent is between 0.35 and 0.45 m/s, which is followed by a sudden drop soon after the operation. This is due to the pain and the discomfort following the surgery, which impair the physical ability of the patient and hence their speed of ascent. In the following weeks, the speed of ascent shows a slow but steady increase with a slope of around 0.04 m/s per month. Finally, 14 weeks after the surgery, the speed of ascent reaches a value which is just shy of 0.5 m/s, confirming a full recovery. The presence of the trend is also corroborated by a high coefficient of determination $R^2=0.86$.

The comparison between the *Manual trend* and the *Automatic trend* from Figure  shows a very similar pattern, with a correlation coefficient between the two plots of 0.88. In spite of the higher error bars, due to false positives, the main characteristic aspects of the plot are preserved, including the drop in the speed of ascent following the surgery and the full recovery after 14 weeks.

For comparison, we present *Automatic trends* generated for *House C* and *D* in Figure , occupied by healthy participants. As expected, no particular trend can be noticed for these houses, as confirmed by the low coefficients of determination $R^2$ of -0.21 and -0.45 respectively.

Although the trend plots presented in this section only refer to the speed of ascent (i.e. Sit-to-Stand), the trend plot computed using the speed of descent (i.e. Stand-to-Sit) showed a very similar behaviour and were omitted from this paper for brevity.

# Conclusions

The demand of AAL technologies for home monitoring is continuously increasing. We presented a simple and efficient approach for the detection and analysis of StS transitions for home monitoring in completely unsupervised environments. We implemented and tested our method in 4 different houses, 2 of which were occupied by patients with total hip or knee replacement. We showed that we are able to reliably identify StS transitions in video clips of binary silhouettes and we can confidently measure the speed of ascent for each transition as an indicator of improving or deteriorating functionality for the StS test. Plots of the average speed of ascent estimated by our method highlights important trends in the recovery process of the surgery patients.

# Acknowledgements

This work was performed under the SPHERE IRC funded by the UK Engineering and Physical Sciences Research Council (EPSRC), Grant EP/K031910/1. The authors wish to thank all the study subjects for their participation in this project and Rachael Gooberman-Hill, Andrew Judge, Ian Craddock, Ashley Blom, Michael Whitehouse and Sabrina Grant for their support with the HEmiSPHERE project. The HEmiSPHERE project was approved by the Research Ethics Committee (reference number: 17/SW/0121).

[^1]: firstname.lastname@example.com

[^2]: In this work, by StS we do in fact mean both 'Sit-to-Stand' and 'Stand-to-Sit', but will specify which of the two, if and when necessary.

[^3]: The frame-rate of the silhouette recorder varied according to different conditions and produced 10 fps on average

[^4]: Although here we refer to the computation of the speed of ascent, the methodology applies identically for the speed of descent by simply using the negative sign in Eq. .

[^5]: The CG was estimated using the average of the Left, Right, Anterior and Posterior Superior Illiac skeletal joints.

[^6]: Available on GitHub: <https://github.com/ale152/muvilab>