Food products supply chain is a rather complex use case. The process from a farm to a store shelf or restaurant kitchen takes time and often involves a long supply chain, where food products are handed from one party to another for storing, processing, or delivery. Without an active and reliable end-to-end monitoring solution, such supply chain can’t immediately react to adverse changes in handling conditions, and problems are only observed on the receiving end. Any break in the process, and decayed food product on a store shelf or in a restaurant kitchen goes to waste and creates compliance and reputational risks.
The Context: Temp-Sense Food Safety Compliance Solution
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.
Specific Supply Chain Challenges
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:
- customers pay exactly for the services they have actually consumed;
- and each participant of the chain, from carriers and storage facilities to sensor manufacturers and IoT service providers, receive their portion of the earnings as per the service billing contract.
Whilst highly beneficial for all participants, this business model presents the following specific challenges.
1. Transparent billing and attribution in a trustless environment
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.
2. Billing on the level of micro transactions, at scale
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 Smart Billing Contract Solution
Agrello employs blockchain Smart Contract technology to address these challenges:
- Agrello provides a framework to codify the Food Safety chain service billing contracts into Smart Contracts on blockchain;
- subscribes to metadata about sensor readings from the Thinnect IoT blockchain;
- executes service billing Smart Contracts on demand to produce billing and attribution reports for stakeholders.
In this particular instance, our blockchain technology of choice is Hyperledger. The key reasons for this choice are:
- enterprise grade architecture;
- permissioned network model;
- high performance and transaction throughput;
- efficient transaction endorsement policy with pluggable consensus option;
- no dependency on any cryptocurrency;
- no transactional costs for running transactions and queries;
- automatic creation of end-point Rest APIs to access functionality of the solution.
A typical Hyperledger network solution consists of the following components:
- data Model, specifying Assets and Concepts of the solution;
- definitions of Participants of the network and their Permissions;
- chaincode defining the business logic — IoT sensor usage billing rules in our case;
- presentation layer — billing reports in our case.
The Billing Contract
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.
Assets, Concepts and Participants
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:
- set of Contract Terms, specifying the billing rules in relation to the contract;
- set of Devices, as deployed for the Consumer in relation to the contract.
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:
- devices deployed to customer locations (one Device Contract per Device) against a Consumer-Provider contract,
- and Readings captured from active devices performing on active contracts.
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:
- validating device reading transactions against the status of the device and the contract, before committing it as valid and billable;
- and generating billing reports on request, based on report parameters.
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 aggregated level — total sensor readings and cost per Customer & Location;
- and a detailed level of readings and cost per Device per Customer & Location.
The Chaincode takes the Billing Period, Customer and Location as parameters and posts a blockchain transaction which executes the following key steps:
- fetches collected Device Asset data for the specified Billing Period / Customer / Location;
- fetches applicable Contract Terms (billing rules) from the corresponding contracts in the Data Model;
- aggregates the fetched Device Asset data and calculates costs using the fetched Contract Terms (billing rules).
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:
- reliability of the process, as deployed once it can’t be tampered with;
- transparency and trust, as any diligent stakeholder can run a node on the network and therefore have access to an up-to-date snapshot of data;
- billing on the level of microtransactions;
- high scalability;
- no need for traditional reconciliations between data, contract conditions and reports, as they all live in the same environment.
Whilst this post has focused on the Food Safety use case, the solution has a wide range of applications, for example:
- monitoring of environmental parameters in buildings;
- monitoring of air quality in factories and facilities;
- use of resources, such as rooms, vehicles or tools;
- and many more.
If you see how this type of solution can be beneficial for your business, let’s talk!