Private Blockchain to Track and Trace
Requirements
Our client is one of the major code generations and monitoring companies for various products in the Healthcare and FMCG sector.
They generate codes that are being used as Batch Number or other identification numbers to identify these products individually in the market. These codes are also being used to check the authenticity of the product to prevent counterfeiting.
The wanted to solve the problems in their existing process so that they can involve more parties in the process to build the track and trace capabilities for any individual code generated, sent, printed, or being checked at any point in the process.
The Existing Process
The existing process was a hybrid process including some automated and some manual steps, which are as follows:
- Every manufacturing plant has one software deployed and connected to the printer
- Codes were uploaded manually and software send instructions to the printer
- The printer generates a printing report
- This printing report was uploaded to the tracking portal
Problem
When carefully analyze the existing process we figure out the following issues which needed to fix into the process:
- Multiple points of failures
- Unable to scale
- High management cost
- Vulnerable and prone to fail
- Lots of manual processes
- Offline dependencies
Research
Our research was based on solving three crucial problems in the existing process
- Remove offline dependencies and make it cloud-based
- Scaling possibilities when multiple parties are being involved
- Automate the manual process to make it less vulnerable
We started exploring other similar problems in various industries and how they have fully or partially solved it.
While in the same research we came across the GS1 (The Global Language of Business) and their standards for EPCIS (Electronic Product Code Information Services) which was a complex but effective process.
Introduction to EPCIS
An EPCIS system is consists of two major top-level standards, Capture and Share to record every event generated by all parties involved and share them with the required parties.
The Capture Standard
The capture standard consists of various interfaces allowing the other connected applications to send events into the EPCIS system along with the System Components required to perform certain operations on the shared data.
Interfaces
There are three major interfaces into the EPCIS system which are
- EPICS Capture Interface
- Application-specific Interface
- IoT Interfaces
EPCIS Capture Interface acts as a bridge between EPCIS Capture and Share standards. The Application-specific Interfaces are the interfaces shared among other third-party applications using the EPCIS for sending events to capture. The IoT Interfaces are similar to Application-specific Interfaces designed specifically for IoT devices involved in the process. These IoT devices can be RFID Tag, RFID Reader, Bar Code Reader, etc.
System Components
There two major system components consist of capture standard which are
- Filtering and Collection Engine
- Data Capture Workflow
The filtering and collection engine is to filter and collect the required events emitted by the IoT devices or sent from various application interfaces. Whereas the data capture workflow is the process created to capture the events.
The Share Standard
The Share standard also consists of various interfaces and system components as follows:
Interfaces
The available interfaces in share standards are
- EPCIS Query Interface
- Interface exposed to other parties
The EPCIS query interface provides a tool to query the EPICS repository for various events sent and captured by the EPICS system. Whereas the third party interfaces are there to provide detailed guidelines on the standards for various data types and format to the involved parties.
System Components
The two system components are available in the Share standard,
- EPCIS Repository
- EPCIS Accessing Applications
The EPICS Repository consists of all information captured by the Capture standard and stored in a time-series fashion. Whereas the EPICS accessing applications are the other required systems to provide access on the EPICS Repository, an ACL (Access Control List) to manage the various access level on the EPICS repository is a good example for the same.
EPICS Events
Events in EPCIS are the points where data can be generated by other processes and emit to the EPICS capture standard to store into the EPICS repository. A typical EPICS event consist of
Object Event
An EPCIS event used to mark an observation or assertion about an object or object.
Aggregation Event
An EPCIS event used to associate one object or a number of contained objects with their containers. This association is often called aggregation, containment, or packing.
Transaction Event
An EPCIS event used to associate or disassociate objects to business transactions.
Transformation Event
An EPCIS event used to represent objects that are consumed in one form and produced in another form.
The above is the representation of different data available in a single EPICS event.
The Blockchain
With EPICS we have a standard way to develop a system that can be distributed. high performance and fully automated involving multiple parties to use it. But still, we had one last problem to solve, establishing trust between these involved parties so that they can be free to participate in a trustworthy fashion.
Initially, we thought of to have a centralized trust broker system who take control and participate with all the involved parties but as it might become a single point of failure and not everybody will be trusting the same we needed a distributed trust system to be designed and developed.
When it comes to distributed trust system Blockchain technology is very effective but costly at the same time, so we have proposed the pros and cons of both systems and let the client make his decision. After having a detailed discussion and analysis we both agreed to get started with the distributed trust system and build the same using Blockchain technologies.
So we have started exploring the available open-source options into the Blockchain technology and decided to go with HyperLedger.
Why Hyperledger?
There are many options to get started with a private permissioned blockchain network for any business needs but we have chosen Hyperledger for the below reasons:
- Open-source
- Backed by Linux Foundation and technology giants
- Robust tooling and application support
- Big community to help and support
Introduction to Hyperledger
The Hyperledger project started by Linux Foundation in 2015 to develop open-source tools for Blockchain technologies inviting multiple teams to collaborate and develop open-source frameworks and tools for Distributed Ledger Technology.
Hyperledger Tools
There are four major tools initiatives under Hyperledger umbrella
Hyperledger Cello
Hyperledger Cello provides a Blockchain as a service (BaaS) environment and simplifies the creation and management of Blockchain networks.
Hyperledger Composer
Hyperledger Composer is used to creating and deploying business network applications (Smart Contracts) on the Hyperledger Network.
Hyperledger Explorer
Hyperledger Explorer is a web-based application to explore the blockchain network running on the Hyperledger network.
Hyperledger Quilt
Hyperledger Quilty provides portability among multiple Blockchain Networks.
Hyperledger Frameworks
There are many Hyperledger Framework initiatives like Sawtooth by Intel, Iroha by Soramitsu, Burrow from Monax but we will only talk about Hyperledger Fabric developed by IBM.
Hyperledger Fabric
Hyperledger Fabric is the end result of IBMs Open Blockchain source code combined with IBM partner Digital Assets. On 11 July 2017, a production-ready Hyperledger Fabric has announced by the Hyperledger community. There are four major characteristics that make Hyperledger Fabric suitable to build DLT based applications for businesses.
Permissioned network
A permissioned network allows the owner of the network to control its access as who can access what.
Confidential transaction
A confidential transaction helps businesses to protect confidential transactions and may require not to make them visible to everyone.
No cryptocurrency required
Businesses required to set up their own network and let the other businesses interact without cryptocurrency.
Programmable
Hyperledger Fabric is programmable which lets developers develop their own chain code and blocks within the network.
Solution
The very first version of the solution was to have EPCIS developed and set up for all the involved parties and then move their transaction events into distributed ledgers on Blockchain.
The solution is divided into three major parts
- Central Dashboard — cloud-based web application
- Capture — IoT based desktop application
- Distributed Event Ledger — Hyperledger based distributed ledger of events
Central Dashboard
The central dashboard is being used to manage products, vendors, manufacturers, packagings, codes, and EPCIS Events.
Followings are the modules in the central dashboard
- Products — manage all the products involved in EPCIS flow
- Location — locations are the addresses of the plant, vendor or manufacturer
- User — users are the admin, CMO, vendor or manufacturer
- Code — codes are batch numbers for the various level of packaging like primary secondary, tertiary, etc.
- Events and Actions — events generated on each action taken on any above modules along with the action taken on those events
The technologies used to build the central dashboard are
- NodeJs — used to build RESTful APIs for central dashboard
- Preact — used to build the UI layer of the central dashboard
Capture
The capture is being used to capture data and installed at various locations, it also has IoT integration with various sensors and scanners.
Every vendor and manufacturer needed to install the capture desktop application with required drivers for their sensors and scanners to generate events.
The technology used to build capture
- NodeJS — IoT drivers
- electrons — desktop app interface for windows platform
Distributed Event Ledger
The distributed event ledger is the EPCIS events ledger distributed among all the involved parties (vendors, manufacturers, CMO, and admin) using a private blockchain.
Each time an event is recorded a new block is created which goes to their assigned parties for verification and added to the chain once verified. The verification level is private and only involved the related plant and product along with the vendor and manufacturer.
The technology used to build distributed event ledger
- Hyperledger Composer — to compose the private blockchain network
- Hyperledger Explorer — to explore, verify or reject the event inside the network