Blockchain-based digital trust mechanism: a use case of cloud manufacturing of LDS syringes for COVID-19 vaccination

2.1Cloud manufacturing

Many researchers have made valuable contrition to facilitate and enable the understanding of Cloud manufacturing (CMfg). The paper (Molina et al., 2007) reviews different traditional manufacturing models, highlights the gaps in these models, and sets the context for implementing the “Build to Order”(BTO) paradigm to address these gaps. The paper introduces the concept of “Virtual enterprise,” with the capability to collectively manufacture for a customer with individual manufacturers who only own some of its competencies. It set the stage for CMfg. The papers (Li et al., 2010), (Tao et al., 2011), (Wu et al., 2013) contribute significantly towards the emergence of CMfg as a strategic manufacturing model in the early 2010 s.

In the paper (Mell et al., 2011), the authors provide the NIST’s definition of Cloud Computing(CC). Following this definition, paper (Xu, 2012) defines CMfg as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable manufacturing resources (e.g., manufacturing software tools, manufacturing equipment, and manufacturing capabilities) that can be rapidly provisioned with minimal management effort or service provider interaction.” The author focuses on how CC is part of the CMfg model on the IaaS (Infrastructure as a Service) abstraction level. The paper emphasizes how adopting CMfg in the IaaS model at the production layer of enterprises (with high production volumes, variable batch sizes, and frequently changing product types) is necessary for the smart digital factory of the future.

In the recent past, many studies have focused on the digital transformation of manufacturing through the cloud. Paper (Borangiu et al., 2019) explores how digital transformation through cloud services and resource virtualization has changed traditional manufacturing and can facilitate the sustainability and maintainability of manufacturing. The authors attribute two crucial drivers that speed up the Digital transformation in manufacturing:

Another paper (Barbhuiya et al., 2019) that highlights exciting research in the CMfg domain is related to the SmartMaaS framework. The paper demonstrates SmartMaaS via a prototype that can accept customers’ product requests in design genes and manufactures 3D printed products using an actor-based system. It highlights how SmartMaaS can enable Smart Manufacturing by facilitating rapid turnaround time, product quality, and innovative design.

The paper (Zhang et al., 2014) highlights terms like Agile Manufacturing, Concurrent Engineering, Networked Manufacturing, Manufactured Grid, and Crowdsourcing. These terms collectively give way to what we know today as cloud manufacturing which leverages these concepts to provision manufacturing resources through the cloud. Research work in papers (Fisher et al., 2018), (Li et al., 2010) and (Zhu et al., 2020) point to a variety of advanced manufacturing systems (AMS) such as Computer Integrated Manufacturing (CIM), Flexible Manufacturing (FM), and networked manufacturing (NM). The paper reinforces how CMfg is an amalgamation of the concepts from several of these advanced manufactured systems with addressing the bottlenecks of each of these systems through cloud computing and IoT.

The papers (Caggiano et al., 2016) and (Zhong et al., 2017) introduced Smart monitoring as one of the critical factors for the success of a cloud-based manufacturing system. The paper (He & Xu, 2015) provides the leading influential technologies like cloud computing and IoT, which depend on high-performing computing (HPC) solutions that use supercomputers and computer clusters to handle multiple tasks at high speed. It also highlights a Service-Oriented-Architecture (SOA) for on-demand resource allocation. In papers (Caggiano et al., 2016) and (Lee et al., 2016), the authors focus on Internet-of-things-based sensors that help identify issues and provide operational data that can be used in predictive analytics to prevent issues occurring. IoT sensor-based monitoring is interchangeably also known as Smart Monitoring. The paper (Wu et al., 2013) provides the strategic vision for cloud manufacturing across the consumers/users, application providers, physical resource providers, aka manufacturers, and provides further insights into a Cloud-manufacturing approach’s fundamental characteristics. The paper highlights the key issues that Cloud manufacturing as an industrial practice faces and how digital trust is one of the central focus areas where further research is necessary.

2.2Trust mechanisms

Digital trust is one of the driving criteria for the success of a system, the components of which interact through the cloud. It is also one of the significant challenges faced by such systems. The paper (Liu et al., 2019) deep dives into some of the significant challenges of digital trust in Cloud Computing(CC). One of the main challenges that the paper highlights are that most enterprises have reservations to put their critical data and application in the cloud. Paper (Xu, 2012) highlights the trust and security concerns due to the anxiety of having sensitive data outside the physical perimeter of the organization. The key takeaway from the paper is that when CC is involved, establishing digital trust is an added responsibility of the service provider along with providing the actual service. Along with the service provider, the Original Equipment Manufacturers (OEM) and other stakeholders also need to have a digital trust established.

The paper (Yan et al., 2016) provides the criteria for trust evaluation on how the digital/cloud manufacturing space conducts direct and indirect trust evaluations. It provides a framework for quantifying the trust and formulates a model of comprehensive trust evaluation with the help of a case study. The paper (Wu et al., 2018) discusses the cybersecurity-related challenges cloud manufacturers and service providers face. How do we ensure that the integrated systems are secure when we introduce advanced technology into a legacy system and retrofit it with sensors and IoT devices? The paper identifies Intrusion detection, Authentication, Encryption, and Access control as the four control mechanisms to counter cybersecurity-related issues and concerns in the domain. With virtualization, the primary security issues include data leakage because multiple third-party manufacturers share physical resources, identity and access management, the physical protection of virtual resources, and the prevention of cross-virtual machine channel attacks.

In (Xu, 2012), the author presents how cloud computing provides a framework to connect distributed resources shared across enterprises. When manufacturing uses Cloud computing, it generates a very high volume of operational data due to the simulation, scheduling, monitoring, and optimization of cloud manufacturing services. However, with increased operational data comes issues with data governance and analytics of big data such a prediction analysis, analytics-based decision making, and edge computing. The paper (Y. Lu & Xu, 2019) presents how big data analytics can use a digital twin of manufacturing equipment connected via the cloud.

Paper (Umeda et al., 2015) discusses requirements and strategies to deal with intellectual property protection and management in cloud manufacturing. With a cloud model, the customers may not trust the service provider or third-party manufacturers unless precise protocols and regulations are in place to manage stakeholders’ intellectual property. There are many challenges with the lack of central governance due to geographically distributed stakeholders, such as how conflicts are regulated and how all stakeholders involved in the system adhere to regulatory compliance (Helo et al., 2014), (Moghaddam et al., 2019), and (Buterin, 2014) (Yadekar, Yaser; Shehab, 2013).

Provenance is an important type of evidence to gain trust. In recent years, research on blockchain-based product provenance for improving product traceability in the supply chain has received much attention (Q. Lu & Xu, 2017; Suhail et al., 2020). A single consignment may be sent to a customer through multiple shippers or manufactured by multiple OEMs and consolidated and shipped together. So, it is crucial to establish where each item is coming from, which plant produces them, the raw material, and whether the manufacturer followed suitable standards.

In (Huang & Nicol, 2013), the authors examined the existing trust mechanisms used in Cloud Computing practice. It proposes a framework that integrates a broad range of trust mechanisms like formal mechanisms (such as accreditation, audit, and attribute certification & validation) and informal mechanisms (interaction experience-based, reputation and recommendation-based, self-assessment and revealing, and transparency-based). The transparency-based trust mechanism demonstrated in this paper is particularly relevant for trust concerns in cloud manufacturing. As addressed in (Huang & Nicol, 2013), trust is a mental state comprising (1) expectancy: the trustor expects a specific behavior of the trustee such as providing valid information or effectively performing cooperative actions; (2) belief: the trustor believes that the expected behavior will occur, based on the evidence of the trustee’s competence, good intention, and integrity; (3) willingness to take a risk: the trustor is willing to take the risk for (or be vulnerable) that belief in a specific context, where there is an expectation for the specific behavior of the trustee. Cloud Security Alliance (CSA) operates the STAR (Security, Trust & Assurance Registry) program (CSA, n.d.), which allows free public access to cloud service providers’ self-assessment about their security control against the most frequently asked questions and the best practice of cloud services. CSC.com proposed, and CSA adopted the Cloud Trust Protocol (CTP) (CSA, 2011), which is a representative transparency-based trust mechanism, allowing cloud users to request the response of a cloud service provider on some specific information about configuration, vulnerability, audit log, service management, service statistics, and others, collectively called “elements of transparency.” “The primary purpose of the CTP and the elements of transparency is to generate evidence-based confidence that everything claimed to be happening in the cloud is indeed happening as described,..., and nothing else” (Knode & Egan, 2010). Cloud Manufacturing can borrow those ideas and create transparency-based trust mechanisms for this field.

2.3Blockchain for cloud manufacturing

Since the mysterious “Nakamoto” published the white paper Bitcoin (S. Nakamoto, 2008), blockchain has gone much beyond final services and found applications in many fields (Wang et al. 2019), such as Internet of Things, supply-chain, and cloud manufacturing, for its strong capability to conserve data integrity. The concept of smart contracts was first proposed by Nick Szabo (N. Szabo, 1996). Ethereum is perhaps the first or the most popular blockchain system running smart contracts. In Ethereum, smart contracts are expressed with language Solidity, which is a Turing-complete programming language. The powerful implementation of smart contracts in Ethereum makes it be widely used in many areas (Zheng et al., 2020; K. Christidis & M. Devetsikiotis, 2016, Mohanta et al., 2018). In the following, we discuss some research on incorporating blockchain into the cloud manufacturing industry.

The papers (A. Vatankhah Barenji et al., 2018) and (Rožman et al., 2021) highlight how blockchain can implement the cloud manufacturing framework at the shop floor and machine level. It provides an alternate approach to cloud computing and capacity allocation via blockchain. The papers attempt to project the existing gaps in cloud manufacturing around security along with information centralization and evaluate blockchain technology as a two-level peer-to-peer network to implement cloud manufacturing. The paper (Zhu et al., 2020) coins the term BBCM, which stands for blockchain-based Cloud manufacturing, and proposes an operation model for CMfg based on blockchain. The authors propose a shift in the operational model for cloud manufacturing from the traditional internet and service-based model to a consensus-based blockchain model.

The paper (R. Vatankhah Barenji, 2021) coins a new term for blockchain-based trust called Blocktrust to address the trust problem in cloud manufacturing. In Blocktrust based cloud manufacturing, trust in a private peer-to-peer network is maintained by having trust scores for each node. The core idea of this study is to establish trust using a feedback value assigned to every provider and requester in the network using blockchain. While this works very well in a private blockchain, addressing some challenges is necessary to implement it for a public blockchain.

The paper (Liang et al., 2017) provides valuable insights on how blockchain can provide data provenance on cloud data objects. Even though it does not directly refer to cloud manufacturing, the virtualized manufacturing artifacts are cloud data objects. A data provenance architecture named ProvChain is proposed to provide a tamper-proof environment for cloud data objects and uses blockchain receipt to validate every provenance data entry. This framework can work in a cloud-based application with the standard number of data reads but storing all the movements in a blockchain with large datasets might get challenging.

There is other exciting research around diverse use cases of blockchain in cloud manufacturing. The paper (Zhu et al., 2020) highlights concepts from blockchain such as virtual currency, smart contract, consensus algorithm, and HASH256 encrypted technology to realize automatic consensus-driven services. Furthermore, it demonstrates the concepts with a case study on 3D printing using blockchain-based cloud manufacturing.

3.1Scenario description

We propose the potential use of cloud manufacturing of LDS syringes to save extra vaccine doses in fighting the COVID-19 pandemic as our motivating scenario. Vaccine suppliers deliver vaccines with at least one extra dose in each vial. However, LDS syringes are needed to get that extra dose in each vial. While administering the vaccines, healthcare providers realized that the supplied vials came with at least one extra dose, which the standard syringes were incompetent to extract because of design limitations. The standard syringe that came with the vials holds 3 ml of vaccine after injecting, but a thinner, 1-ml syringe called “low dead-volume” or “low dead-space” syringe works well for small doses of vaccines, like that of Pfizer and Moderna. The supply of these 1-ml syringes is currently way lower than the demand (Hufford, Austen; Hopkins, 2021). A few hospitals upgraded their syringes but not all, leading to wastage of the precious vaccine doses. While the Pfizer kits are now coming with a suitable syringe, the Moderna kits still have the standard ones. Per stats, since the US has bought about 300 million Moderna doses so far, there is a high possibility of wastage of around 30 million doses by not enabling vaccinators with the suitable syringe. Also, this issue is not limited to the US. Several countries like Japan and other European countries have reported similar supply chain problems with the low dead volume syringes (Moutinho, 2021).

With so many countries struggling with vaccine supplies for mass vaccinations, the syringe shortage is a significant problem that needs immediate attention. Thus, bringing forth the significance of advanced manufacturing and further strengthening the need for digital transformation in manufacturing with modern practices like Cloud Manufacturing. With Cloud manufacturing, addressing the supply shortages of the syringes needs effective collaboration between multiple manufacturers who can cater their manufacturing artifacts and resources by virtualization and consumption on-Cloud. A cloud manufacturing system can tap into any available third-party manufacturing resources to address the manufacturing bottlenecks for low dead volume syringes. Multiple manufacturers can collaborate and manufacture syringes for a single service provider to speed up the process. However, for cloud manufacturing to work out and thrive, digital trust is essential. We aim to develop a digital trust mechanism by using smart contracts in an Ethereum blockchain.

This paper demonstrates the implementation of trust in cloud manufacturing with an example of LDS syringes. We will be using a smart contract leveraging the Ethereum blockchain. It will be a public blockchain with a smart contract between the manufacturer operating in a cloud manufacturing model. The potential customers will be service providers and end customers like hospitals and regulatory bodies such as the FDA (who regulate the medical devices’ manufacture).

Let us assume a scenario of cloud manufacturing to meet the surged needs of LDS medical syringes for the COVID-19 vaccination. To focus on the valuable insights, we use a simplified supply-chain relation as illustrated in Fig. 1. From the figure, we can identify several vital roles, such as

Fig. 1

Scenario of LDS medical syringe manufacturing.

Regulatory agency: e.g., FDA(G): Regulatory agencies oversee the manufacturing of medical devices such that their consumption is safe for the general public. E.g., In the USA, the FDA’s Center for Devices and Radiological Health (CDRH) regulates all firms that manufacture, repackage, relabel, or import medical devices sold in the country. The FDA protects the public health by having regulations for human and animal drugs and biologics, medical devices, tobacco products, food including animal food, cosmetics, and electronic products that emit radiation. FDA classifies both the LDS (low dead space) piston syringes and LDS hypodermic needles as Class II Medical Devices. In Class II devices, general controls alone cannot provide considerable safety assurance and effectiveness. Class II devices have a moderate to high risk to the patient or user.

Medical syringe supplier/distributor(S): The manufacturer distributes products to medical facilities. He will assemble the individual parts before distributing them to its end users.

Third-party manufacturers (B, N): e.g., Syringe barrel manufacturer, syringe needle manufacturer. These are the participant manufacturers in cloud manufacturing who collaborate towards the manufacturing of the LDS syringes.

Raw material supplier (Mi): These are the suppliers that supply the raw materials such as heat-treatable stainless steel or carbon steel for the needles and flexible synthetic rubber for the plunger heads, and biocompatible plastics or glass for the syringe body

Healthcare service provider(H): These are the direct consumers of the syringes who administer mediation through these syringes to the patients.

3.2Potential trust issues in cloud manufacturing of LDS Syringes

3.3System concept of CMfg for LDS syringes

As a potential solution focusing on the data provenance and adherence to the current good manufacturing practices (CGMP) in cloud manufacturing, we propose an IoT-enabled cloud manufacturing system setting that deploys a smart contract to record the readings of the IoT devices into the immutable blockchain. The IoT devices monitor the manufacturing conditions and record them so that no tampering is possible. Anyone requiring access to this information can traverse through the blockchain to get it and consume it as required. In the Cloud Manufacturing environment, we have the following assumptions for our motivating scenario.

Each IoT device identifies by a specific code and connects to a computer connected to the blockchain. The IoT device sends the sensor data to the computer that prepares and logs the transactions into the blockchain. It also enables demonstrating them to potential customers who can now confidently order products such as medical devices from this manufacturer once this manufacturer demonstrates the sterility in its manufacturing process.

4.1Identity management

For Identity management, an Identity Trust Fabric (ITF) blockchain, which will act as a distributed ledger for cryptographic proofs for decentralized identities, can be built. This ITF blockchain will provide verifiable credentials GTID (Global transaction ID) and facilitate decentralized trust between the entities involved, including the credential issuers, holders, service providers, and consumers, thus eliminating the need for a centralized authority. The ITF Blockchain will use Decentralized Publickey Infrastructure (DPKI) for identity management. The idea is to build a Self-Sovereign Identity (SSI) where individual stakeholders can own and manage their digital identities. Upon legally establishing a decentralized identity, we can verify the enrollment of service providers within the ecosystem. (Hewett et al., 2019) present the concepts of Digital Identity and their implementation using blockchain for the supply chain industry. The same concept extends in our use case for identity management.

Authentication: In one simplistic example, a person creates a pair of private and public keys in an identity wallet. An ITF stores the public key (identifier) hash immutably. While adding the transaction, the entity in the block transactions gets assigned an auto-generated identifier or Smart-ID by the smart contract. This ID is saved in the blockchain with the attributes and serves as a GTID.

The ITF also stores the certification record. If the user wants to access a service, it is enough to present its identifier/Smart-ID as a QR code or within a token. The service provider verifies the identity by comparing the hash values of identifiers with their corresponding hash records in the ITF. If they match, ITF grants the access. It can be a separate smart contract that service providers can query, partners to validate identity, or integrated with the transaction management with independent, smart-contract functions implementation.

Fig. 2

Data flow; cloud manufacturing of LDS syringes with blockchain.

4.2Manufacturing transparency and provenance management

In manufacturing medical devices, especially Class I and Class II, sterility is of utmost necessity. The idea here is to use IoT sensors to monitor the sterility determinants and store these manufacturing conditions in the blockchain to demonstrate adherence to sterile manufacturing. Once the blockchain stores the data, it is immutable and can be easily validated after the fact. It enables demonstrating these conditions to the authorities like the FDA when requested or in an inspection.

IoT sensors are used in various applications to record diverse readings such as temperature, humidity, and chemical concentration, among others. However, with the current scheme of things, it might not be possible to connect all IoT devices directly to blockchain since they are not as large as conventional computers, and there have been challenges with establishing a consensus with IoT devices in a blockchain. The consensus mechanisms we have today are comprehensive for IoT devices that have limited computing. IoT devices are heterogeneous, and Scalability is also one of the challenges as the size of blockchain proliferates, especially in IoT systems. Also, not all data generated by IoT devices can be stored on an Ethereum blockchain mainly because generating these many transactions is infeasible both from a storage standpoint and economically. It could make the maintenance of blockchain expensive and extremely slow.

Hence, we first need to establish what information the transaction management blockchain should store such that the data integrity can be confirmed without mirroring all the IoT readings into the blockchain storage. It is worth reiterating that blockchain is not a database but can be conceptualized more like a ledger.

4.3Validation of data

During an inspection, the readings from the database can demonstrate adherence and compliance with sterility for a duration of time. The hash is calculated on the dataset and compared to that hash saved in the Ethereum transaction blockchain. If it matches, it proves that the database is not tampered with, and the IoT device indeed captures the readings.

Validation of the Maximum, Minimum, Average readings for the configurable duration is possible without a site visit by traversing through the blockchain and querying the blockchain to check for exceptions logged. Additional validation and access control are in place in the smart contract for managing the access to functions of the smart contract.

Figure 3 shows a simple view of how manufacturing units place IoT devices. Each manufacturing unit manufactures one or more products. Based on the sterility requirements in manufacturing these products, each unit may have one or many IoT devices. Each could measure any reading, such as temperature, humidity, or chemical content. A manufacturer may have more than one unit to manufacture the same goods or a series of products.

Fig. 3

A brief view of deployment of IoT devices in LDS syringe manufacturing.

5.1Smart contract

A smart contract consists of snippets of executable code that run on top of the blockchain. When executed, it facilitates an agreement between two or more parties who may not trust each other without a trusted third party (Buterin, 2014). Smart contracts enable users to embed their agreements and trust relations into a code and enable the execution of automated transactions without the supervision of a central authority. Smart contracts help automate paper contracts and agreements that otherwise require a third party by converting them into digital contracts.

The proposed smart contract will be between a manufacturer, regulatory bodies (e.g., FDA), and the manufacturer’s potential customers. These customers could be hospitals that directly procure goods (E.g., LDS syringes) from this manufacturer or intermittent cloud manufacturing service providers who will procure and then distribute to medical centers and hospitals.

Each deployment of the smart contract will be associated with one manufacturer. Different manufacturers can deploy different instances of the smart contract, and these will be independent of one another hosted on different smart contract addresses on the Ethereum blockchain. It is in line with deploying an off-the-shelf application by different users where the same application will deploy independently. With the approach, the IoT devices are proposed to monitor the manufacturing facilities and act as sensors that capture the manufacturing conditions. A manufacturer can have one or more IoT devices placed in different manufacturing units associated with the syringes (or other products) manufacturing facilities. One smart contract implementation will hold information on all devices and readings in all the manufacturing units associated with this manufacturer. Each IoT device registered by the manufacturer will be assigned a threshold for low and high readings beyond which they will be outside its bound. If all readings are within the set low and high threshold, the environment in the manufacturing unit can be considered ideal for sterility and manufacturing the product. The smart contract will also hold a list of available products for customers to order and the inventory available through the manufacturer.

One of the advantages of cloud manufacturing is the cost efficiency it brings it. Hence, it would be counterproductive to have a cost overhead of a country-independent trusted third-party bank for regulating payments from service providers to manufacturers. A trusted payment mechanism that assures that the service provider will make payments on goods receipt is equally crucial for digital trust between the stakeholders involved. The proposed smart contract also provides ways of carrying out trusted transactions between a manufacturer and its customer (supplier/distributors or medical facilities).

5.2Smart contract template for CMfg

A transaction to a smart contract can be triggered by referencing the unique addresses assigned to it by blockchain technology. Solidity is a high-level language used to implement smart contracts. Like an object-oriented programming artifact such as a class, smart contracts have attributes or variables that are either private or public, along with methods that operate on these attributes. The private attributes of a smart contract can be accessed through these operations/methods of the smart contract, whereas the public attributes are accessible by reference outside the methods defined in that smart contract. Even though an attribute may be private, it does not mean the values of this variable are a secret. If a smart contract developer knows the exact transaction where the smart contract referenced this attribute on a blockchain, the private attributes may be viewed by referencing this transaction using a block explorer. However, the private attributes are nonmodifiable from outside the smart contract. In addition to attributes and methods, the smart contract also has events. Events are very crucial for smart contracts. Because smart contracts’ transactions are asynchronous, when a miner mines the transaction, the return code is not available synchronously to the frontend (JavaScript or any other UI of the blockchain). Here events come to the rescue as the smart contract’s address stores these events. The blockchain frontend can configure to listen/subscribe to these events and act accordingly. They can serve as transaction log as well.

The smart contract developed to ensure the sterility constraints in cloud manufacturing can have the attributes, events, and operations below.

5.2.1Attributes

• (1) Single EOA (Externally owned address) for Manufacturer.

• (2) Registration ID

• (3) Product Inventory. A mapping list of all products with their inventory available for selling on this blockchain.

• (4) A list of all devices deployed by manufacturer. The information is stored in a structure which has the device identifier, the manufacturing unit id, its status (ACTIVE/INACTIVE) which indicates if it is actively monitoring and logging into the blockchain, and its low and high threshold.

• (5) Any address may request for access to the readings of an IoT sensor device. This means FDA account; any service provider or end-customer can attempt to access the readings. Any data logged in Ethereum is public and available to any address subscribed to this blockchain. So, the data is immutable but not private.

The smart contract maintains a list of access requests made by any address through its get methods. It enables the manufacturer to have visibility on which accounts accessed the readings. The visibility of these attributes is private, so the access is only through the smart contract. In solidity, every public attribute has default getter methods for access. The private visibility keeps control on provisioning access only through the methods defined in the smart contract.

The Shipments list maintains the list of customers, the quantity to be sent out to each customer, and the amount exchanged for the product sale. The customer’s default mapping maintains any defaults for specific customers. For example, if a service provider states by default, auto-send 20 LDH syringe cartons if all readings are within bound, this default is saved in an attribute named Customer_Qty.

Figure 4 above represents a process workflow of possible interactions between a Manufacturer, two customers Customer-1 and Customer-2, the Regulatory body (FDA), and the smart contract.

Fig. 4

Process workflow diagram of the smart contract functions.

Figure 4 depicts how the smart contract template for CMfg works, capturing a few daily operating scenarios. Let us assume that the initial balance in the manufacturer’s account and two customer accounts are 100 ETH, respectively. The smart contract address does not have any amount locked against it. As the first step, the manufacturer deploys the smart contract. He then sets its registration id and sets default quantities for the two regular customers. Setting the default quantity implies that when these customers validate the IoT readings posted, get convinced that the current good manufacturing processes are adhered to, and approve to trigger an order from the manufacturer, the dispatch of shipments with respective default quantities happens. Ethereum deducts a small fraction of processing charges for these transactions. This amount of processing transactions depends on the code in the smart contract for these operations/methods.

Next, the manufacturer registers the IoT devices in their manufacturing units and sets the thresholds for these devices. Subsequently, the IoT devices will collect the sensor data and post the readings to the blockchain via the logging method of the smart contract. Once the readings are in the blockchain, the customers can check these readings to make informed decisions on purchases from the manufacturer. The regulatory body can also validate these readings in the event of an inspection.

Upon validation, Customer-1 triggers an order for product P1. Upon receiving this trigger for intent to purchase, the manufacturer initiates the order for P1 for the default quantity Q1 for Customer-1. The manufacturer also locks 10 ETH into the smart contract. This amount is the selling price of product P1 for quantity Q1. At this point, the manufacturer’s balance reduces to approximately 90 ETH. The smart contract has locked 10 ETH. The manufacturer’s balance is an approximation here as we are not tracing the fractional processing fee that gets deducted by each of the other operations performed by the manufacturer using the smart contract. Upon receiving the initiatial order event, Customer-1 confirms the order by locking 10 ETH into the smart contract’s address. The balance for Customer-1 is now 90 ETH, and the smart contract has a balance of 20 ETH in total. Subsequently, the manufacturer also initiates an order for Customer-2. Assuming the transaction amount is again 10 ETH, 30 ETH is now locked in the smart contract. The manufacturer now ships out to Customer-1. Upon receipt, Customer-1 confirms and pays the manufacturer. At this point, Customer-1 sends 20 ETH to the manufacturer’s account. It includes the 10 ETH locked by the manufacturer originally and the 10 ETH sent by the customer. Suppose the manufacturer aborts Customer-2’s order, on the other hand, for reasons better known to him. In this case, Customer-2’s 10 ETH locked with the smart contract will return to its account.

At the end of these interactions, the manufacturer gets a net of 10 ETH for his transaction with Customer-1. He gets nothing from Customer-2 as their transaction is in abort status. Hence final balance with the manufacturer is 110 ETH. Customer-1’s balance is less by 10 ETH, and Customer-2 is as-is. The residual balance locked on the smart contract is also 0 since no “in process” transactions are now pending.

5.3Examples of operations with smart contract

Once the smart contract is created and deployed on a blockchain, the smart contract code becomes immutable. No changes to the smart contract code are possible at this point. It ensures the integrity of the smart contract, and its terms are maintained. This section highlights the output for sample transactions to provide an outlook of the working of the smart contract created in the preceding section.

Example 1: Manufacturer posts readings from the IoT device into the blockchain

Once the Ethereum address deploys the smart contract, the address of the account through which it is deployed becomes the manufacturer. The manufacturer subsequently sets his registration ID, registers the devices in its manufacturing units, and sets the device thresholds. Only the manufacturer will be authorized to log the readings from the IoT sensors. The log_readings() function within the smart contract can register a manufacturer, add products to its list, activate a sample IoT device, set its thresholds, and log readings to the blockchain.

Below is the output of log_readings() once it executed successfully:

Example 2: An external account other than a manufacturer attempts to set default quantity for a customer.

Any account that has the address at which the smart contract is deployed can invoke a smart contract operation. The smart contract should have in-built security policy and restrictions to secure access management. In this example, an external entity uses its account that is not the manufacturer and attempts to set a default quantity for a customer. The smart contract is set in a way that only manufacturer can set up default quantity This operation should therefore not be successful.

The snapshot below demonstrated the same where the transaction is reverted to the initial state when invoked by any entity that is not the manufacturer.

Example 3: Manufacturer sets default quantity for a customer.

For setting the default quantity, The manufacturer calls the setQty_customer() function. The output of this transaction is shown as below.

Example 4: Customer triggers an order request to the manufacturer

Once the customer confirms that the logged IoT readings are within the threshold to make sure that the manufacturing conditions are sterile, the customer can trigger a request to the manufacturer for ordering the product. Two possibilities exist. Either a customer who already has an established relationship with manufacturer and for whom a default quantity is already set calls the trigger_order_scheduled() function or a new customer triggers an order request using trigger_order_adhoc() function by specifying a custom quantity they need. In the example below, Customer C1 triggers the trigger_order_scheduled() function to order product P1, for the default quantity Q1 set for the customer.

The manufacturer then sends a request for initiate purchase. The value specifies how many ether coins the manufacturer expects from the customer. With this manufacturer sends 10 ethers to the smart contract’s address. This is like an escrow account now. If manufacturer does any foul play, he will end up losing this money.

Next Customer confirms the transaction:

sendShipment() is called by manufacturer to confirm that goods are shipped. The tracing number is provided

Next, Customer confirms the purchase and pays. At this point the balances get transferred to the manufacturer.

Key insights:

The above experiment implemented with Ethereum Remix shows the feasibility of the proposed framework. By leveraging Blockchain, the framework could ensure the data integrity of the manufacturing provenance and achieve the goal of transparency for trust.

Placing IoT sensors at the operational layer generates humongous data. On the other hand, logging everything in a blockchain is not just expensive but infeasible. The smart contract above addresses these issues by leveraging edge computing and logging statistics (max, min, average, and standard deviation of readings) on the blockchain and potentially storing detailed records on a lower-cost local database on the manufacturer’s premise or on-cloud. Storing the hash of the records on the blockchain ensures that the detailed dataset has not been altered, providing a data-integrity-based digital trust mechanism to the stakeholders.

On operations, we have also illustrated by example how a manufacturer can potentially carry out financial transactions with customers using the smart contract without any other third party. The manufacturer can efficiently maintain product inventory and auto-trigger shipments of a set default quantity to their customers upon demonstrating sterile manufacturing conditions. The smart contract can also facilitate an online, over-the-blockchain manufacturing site inspection by regulatory authorities like the FDA.