The online temperature monitoring system Temp-Sense includes wireless detectors installed in refrigerators and hot food counters, across the supply chain. All data that is measured is available “in the cloud” in real time and is displayed on the dashboard where the store and restaurant manager (or an internal auditor) can easily keep an eye on the processes within the entire supermarket or restaurant chain.
In this system, the IoT network service provider company Thinnect handles the sourcing and deployment of automatic IoT sensors into the Food supply chains, as well as collecting and processing the sensors’ data. Thinnect employs a specialised IoT blockchain to run the IoT service, which ensures that the sensors can’t be tampered with across the supply chain.
FoodDocs, a digital food safety and compliance expert company, uses the collected data to support supermarket and restaurant chains in assessing food safety and creation of documents required for food safety compliance.
Altogether, Temp-Sense delivers a digital solution that enables a proactive, reliable and highly efficient food safety and compliance process. Please see the blog post about Temp-Sense (used to be called ThinMoni) for more details.
Temp-Sense operates a PAYG business model in order to lower the barrier for adoption of IoT services in the supply chain. This business model implies that:
Whilst highly beneficial for all participants, this business model presents the following specific challenges.
It is easy to see that each participant of the chain are running their own business, with their own priorities and considerations. In this naturally trustless environment, ensuring transparency of billing and attribution for all stakeholders is a challenge.
In addition to the above, IoT networks are characterised by large numbers of micro devices, producing high volumes of micro readings. The challenge this poses is billing on the level of micro transactions, at scale.
Agrello employs blockchain Smart Contract technology to address these challenges:
In this particular instance, our blockchain technology of choice is Hyperledger. The key reasons for this choice are:
A typical Hyperledger network solution consists of the following components:
With a bit of a simplification and focusing on the core features of the contract for the purposes of this post, the structure of the Billing Contract is as follows.
Notes on the contract structure
Worth noting that X, Y and Z are defined on the level of micro-cents, creating a highly precise cost model per unit of consumed service.
This cost structure is used by Thinnect to bill FoodDocs for the Food Safety Monitoring and Compliance service. Further, the “sharing economy” principle applies in the way that the same cost structure is applicable to Thinnect, its subcontractors, Device Manufacturers and even Agrello, to obtain and distribute a portion of proceeds from each device reading transaction.
Below, we will explain the key aspects of implementation of such contract on the example of this Provider-Consumer billing contract.
Let’s have a look at the key entities of this contract’s network.
Consumer and Provider
Participant entities Consumer and Provider give parties permissioned access to the network and its assets through cryptographic keys, ensuring the highest degree of control and safety of confidential information.
This entity is designed to maintain records of contracts between Consumers and Providers, and is therefore implemented as an Asset. The two fundamental aspects of this entity are:
This entity is specific for this particular type of contracts. It is designed to hold the billing parameters of the contract, which in this use case are: a price per reading and a capped cost per month, dependent on the number of devices deployed to a customer location.
Device, Device Contract and Readings
One interesting aspect of this implementation is that Devices effectively work on Contracts. That is, we are not interested in metering or billing devices that are not deployed to any contract, or where the contract has expired or got terminated.
The Device entity maintains the record of all available devices and their current status, whether they are sitting in a warehouse or deployed to a customer.
The Device Contract entity maintains records of:
This overall structure allows for a good reusability of the model as well as for efficient updates and queries on it.
The Device Reading Transaction and Report Entities are described in the next section.
The key functions of chaincode in this use case are:
Device Reading Transaction
The DeviceReadingsTransaction transaction depicted in the diagram above executes chaincode that implements the special condition of the contract — ensures that only valid readings from “ACTIVE” devices are committed as billable. Blockchain safeguards the solution from malicious transactions entering the system.
There are two levels of reports developed for this use case, driven by and aligned with the structure of the Billing Contract:
The Chaincode takes the Billing Period, Customer and Location as parameters and posts a blockchain transaction which executes the following key steps:
In this project, we didn’t need to build a sophisticated front end solution. Instead, we’ve leveraged the Hyperledger Composer’s presentation capabilities to visualise billing reports, thus making them natively available to all permissioned network participants. We’ve also employed the Hyperledger Rest API capabilities to receive data from Thinnect’s IoT blockchain, and to expose the reporting Rest API back to Thinnect. This API provides full capabilities for building billing dashboards and generating reports where required.
A typical report looks as follows:
Core components of the solution are packaged in Docker containers so deploying a new instance of the network or bootstrapping a new node is quite straightforward using standard tools.
Here comes another key advantage of using blockchain and Hyperledger in particular for this use case. That is, every significant party of the supply chain (or any sufficiently interest one) can bootstrap their own node on the network, thus both contributing to the overall resilience of it as well as obtaining and running their own copy of the ledger they can trust.
In this article, we’ve considered a particular type of a Supply Chain use case — Food Safety in the Cold Chain. This use case presents a number of challenges, amongst which are: the transparent billing and attribution in a trustless environment, and billing on the level of micro transactions at scale. We’ve described the Agrello solution to these challenges, based on the Smart Contract technology.
The advantages of the described solution are:
Whilst this post has focused on the Food Safety use case, the solution has a wide range of applications, for example:
If you see how this type of solution can be beneficial for your business, let’s talk!