Blockchain’s Real World Applications; Automotive Supplychain, A Technical Proposal

XBOM Background

Prasaga has created a development and runtime environment on Hyperledger Fabric that implements an on-chain first-class object model enabling both the inherent and inherited reuse of class code. It enables flexible user account models using objects instantiated in containment trees. The development and runtime environment is known as the eXtensible Blockchain Object Model (“XBOM”). The version implemented on Hyperledger Fabric uses the test network configuration for development and could be deployed with any standard Hyperledger Fabric release version 2.0.0 or higher with appropriate supported configurations. No source code changes to Hyperledger Fabric are required.

Proposal

Prasaga proposes to use the XBOM platform to demonstrate how the scenarios described in the automotive Hyperhack can be implemented with XBOM as a set of accounts, parts, assemblies, and cars as object instantiations of associated classes. Further because of the flexibility of the object model creating additional accounts (e.g. suppliers, OEMs, dealers), and/or adding new parts, assemblies, and cars is nothing more than sending appropriate transactions performing method calls on the appropriate objects and classes.

Classes

The following classes will be implemented, dynamically loaded into a running test network, and will demonstrate the scenarios:

Scenarios

The XBOM platform will be loaded as part of the test network setup, technically as the chaincode for the channel. Because the account concept is implemented with objects using the XBOM, the number of nodes in the test network does not relate to the accounts. However, the test network setup will include a number of nodes intended to be owned by individual accounts to avoid confusion.

Diagrams:

Account Relations

Account Relations
  • Vendor versus Customer accounts object is determined by class type.
  • Each object can have any number of accounts in the list.
  • There can be more than one Vendor List and one Customer List Account object in an account.

Supplier-OEM-Dealer-Customer

Supplier-OEM-Dealer-Customer
Asset (part, assembly, finished product) Relations
Asset (part, assembly, finished product) Relations: Example

Contracts & Certificates

Contracts & Certificates
  • An account can have one or more contracts.
  • Each asset (batch part, assembly, or product), has an individual certification object associated via an object reference.
  • The asset objects reference the certificate object, instead of including the certificate fields as state. This allows for multiple certificates for an individual asset, if needed.

Supplychain Operation

Supplier

  • A supplier account contains a factory class object for each type of asset (part) to be created.
  • The types are distinguished by SKU and human readable text string (along with its LOID)
  • Creating a batch of a SKU, happens by sending a create inventory to the factory class object for the specific SKU. This returns a new asset object initialized with the inventory count.
  • An OEM account contains a factory class object for each Assembly type. These are similarly distinguished (SKU, readable text)
  • When creating an assembly object, it is initialized with the list of part asset objects from the suppliers. For each, the assembly object draws down on the part asset object inventory.
  • For forward auditing the part asset object in the supplier account could record the OEM assembly object
  • Note: An assembly object can have an inventory of list of assemblies. Each has a list of part object references for tracing.
  • A product consists of assemblies (and possibly parts, but not depicted for the hack)
  • The product objects and assembly objects are contained within a single OEM account. This implies the OEM does subassemblies as well as finished products.
  • The same relationships and factory patterns hold
  • Dealer account maintains an inventory of finished products from the OEMs.
  • A finished product list object for each OEM is maintained in the Dealer account. This object contains the OEM account object reference, a finished product object reference for each product, which is either in an inventory or sold list.
  • On a customer sale, the finished product is moved from inventory to sold.
  • This is modeling a demand driven sequence for the transfer of asset references.
  • Transfers occur when a “manufacturing operation” or sale to customer happens.
  • Only the reference (object handle) to the objects is transferred. The objects remain in the accounts they were created. This provides a permanent audit on what was created, when.
  • On each such transfer, available and used inventory counts are updated accordingly
  • For the hack — we won’t deal with out-of-inventory situations.
  • The above does not describe the details of the classes, or any inheritance. It is mostly focused on the instantiated objects and references.

Advantages

The XBOM enables creating a dynamically expandable class library for a running Hyperledger Fabric implementation. By developers creating classes designed for various blockchain applications, users of the applications do not need to be concerned about the code for their objects, as is common with smart contracts. This makes a running Hyperledger Fabric implementation more versatile, building new use-cases by adding to its class library, without the need for creating new channels, or loading entire new smart contract applications.

Solution Uniqueness/Novelty

  • The unique advantages of XBOM not only make it possible to develop new blockchain applications faster, but increase the ease of use for blockchain users.
  • XBOM extends the well-known strengths of object-oriented programming to the blockchain.
  • As a First-class object model, XBOM supports metaclasses, classes and objects, with the concepts of abstraction, encapsulation, inheritance and polymorphism.
  • Although the XBOM on Hyperledger Fabric is implemented in Golang, conceptually classes written to use the XBOM are not required to be written in any particular programming language.

Demo

The source code for all classes created for Hyperhack 2021 as well as existing foundation classes will be open source available from the Prasaga public GitLab repository accessible at https://xbom.io

Example User Interface for supplychain, fully customizable open source code

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Holdmann

Michael Holdmann

Founder & CEO at prasaga.com A Foundation building Decentralized GlobalOS and a Single, World Class Tree.