Our client is one of the major code generation and monitoring company for various products in Healthcare and FMCG sector.
They generate codes which 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
Printer generates a printing report
This printing report was uploaded to the tracking portal
When carefully analyze the existing process we figure out the following issues which needed to fixed into the process:
Multiple points of failures
Unable to scale
High management cost
Vulnerable and prone to fail
Lots of manual processes
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 consist 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.
There are three major interfaces into the EPCIS system which are
EPICS Capture Interface
Application specific Interface
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 application 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.
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:
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 type and format to the involved parties.
The two system components are available in the Share standard,
EPCIS Accessing Applications
The EPICS Repository consist 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.
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
An EPCIS event used to mark an observation or assertion about an object or objects.
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.
An EPCIS event used to associate or disassociate objects to business transactions.
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.
With EPICS we have a standard way to develop a system which 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 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 system 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.
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:
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.
There are four major tools initiatives under Hyperledger umbrella
Hyperledger Cello provides a Blockchain as a service (BaaS) environment and simplifies the creation and management of Blockchain networks.
Hyperledger Composer is used to creating and deploying business network applications (Smart Contracts) on the Hyperledger Network.
Hyperledger Explorer is a web-based application to explore the blockchain network running on Hyperledger network.
Hyperledger Quilty provides portability among multiple Blockchain Networks.
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 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 Hyperledger community. There are four major characteristics that make Hyperledger Fabric suitable to build DLT based applications for businesses.
A permissioned network allows the owner of the network to control its access as who can access what.
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.
Hyperledger Fabric is programmable which lets developers develop their own chain code and blocks within the network.
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
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 number 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 UI layer of the central dashboard
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
- ElectronJs - 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