Private Blockchain to Track and Trace

Impulsive Web
Impulsive Web
Published in
7 min readMay 27, 2020

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:

  1. Every manufacturing plant has one software deployed and connected to the printer
  2. Codes were uploaded manually and software send instructions to the printer
  3. The printer generates a printing report
  4. 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:

  1. Multiple points of failures
  2. Unable to scale
  3. High management cost
  4. Vulnerable and prone to fail
  5. Lots of manual processes
  6. Offline dependencies

Research

Our research was based on solving three crucial problems in the existing process

  1. Remove offline dependencies and make it cloud-based
  2. Scaling possibilities when multiple parties are being involved
  3. 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

  1. EPICS Capture Interface
  2. Application-specific Interface
  3. 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

  1. Filtering and Collection Engine
  2. 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

  1. EPCIS Query Interface
  2. 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,

  1. EPCIS Repository
  2. 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:

  1. Open-source
  2. Backed by Linux Foundation and technology giants
  3. Robust tooling and application support
  4. 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

  1. Central Dashboard — cloud-based web application
  2. Capture — IoT based desktop application
  3. 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

--

--

Impulsive Web
Impulsive Web

A small but smart and passionate team looking to reimagine what is possible when your idea meets the technology.