Blockchain’s Real World Applications; Automotive Supplychain, A Technical Proposal
Bosch Automotive in partnership Hyperledger India Chapter has released a problem statement for automotive supply chain for Hyperhack 2021.
Prasaga has answered the challenge for a blockchain based “Real World Application” Solution with the following proposal. We will release the Enterprise Development and TestNet environment for Proof of Concept (PoC) projects in Automotive supplychain and any other vertical/industry where Fungible or Non Fungible assets solve real world problems.
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.
The current version of XBOM is implemented with the Go programming language (Golang). The base runtime environment loads as normal Hyperledger Fabric chaincode. XBOM uses the Golang plugin modules capability to enable dynamic loading of class code when each class is referenced directly or indirectly by transactions. This includes the capability to develop and deploy classes to a running Hyperledger Fabric chain at anytime after the chain has been launched. A Hyperledger Fabric transaction sent to an XBOM object consists of a normal invoke command and JSON syntax to reference the objects and arguments for the transaction. Hyperledger Fabric returns the results of a transaction normally as a string. The XBOM runtime return arguments are JSON encoded strings within the Hyperledger Fabric return string.
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.
The source code for all classes created for Hyperhack 2021 problem statement as well as existing foundation classes will be open source available from the Prasaga public gitlab repository.
Classes
The following classes will be implemented, dynamically loaded into a running test network, and will demonstrate the scenarios:
Class Supplier Account
Class OEM Account
Class Dealer Account
Class Customer Account
Each of the above account classes may be instantiated any number of times to create user accounts of the specified type. To realize the scenarios, the appropriate accounts will be created to match the defined configuration.
Class Asset
An object instantiation of Class Asset represents the inventory of a part produced by a supplier (i.e. spark plug, tires, etc.). The inventory is managed by the object such that it may be increased or depleted based on new production and customer deliveries. A supplier account may contain any number of asset objects, where each asset object may represent the same or different parts. Each part type has a unique part number, thus asset objects of different parts have differing part numbers.
Class Assembly
An object instantiation of Class Assembly represents a subassembly of a component of a finished car. Each object may contain any number of references to Class Asset parts depending on the design of the intended assembly. Each object represents a unique instance of an assembly such that each has a unique serial number. An OEM may contain any number of assembly objects. Although this is not directly part of the Hyperhack 2021 scenarios it fits with the overall theme of supplychain management.
Class Product
An object instantiation of Class Product represents a finished car. Each object represents a unique instance of a car, and may contain any number of assemblies. Each object has a unique serial number. An OEM may contain any number of finished car objects.
Class Contract
An object instantiation of Class Contract represents a B2B supplier contract. The contract is stored as human readable text on the blockchain. Each account, Supplier, OEM, Dealer may contain any number of contracts reflecting the various products contractual commitments at each stage in the supplychain.
Class Asset Certificate
An object instantiation of Class Asset Certificate represents a certification that the referenced part, assembly or car meets the contractual obligations of the associated contract. Each part, assembly or car may reference one or more Class Asset Certificate objects.
Class Reputation Account
An object instantiation of Class Reputation Account is an account that contains reputation ratings for one of the Account entity types in the supplychain. That is, it could contain reputation ratings just for suppliers as opposed to OEMs, etc. Although there can be multiple Class Reputation Account objects the intent is to have a single such account to collect reputations for the type of account.
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.
Each scenario will be demonstrated by first sending a series of transactions to the appropriate objects. To setup the scenarios, the classes described above will be dynamically loaded in to the test network after all of the nodes have been initialized and loaded with the XBOM platform as the chaincode.
After the classes have been loaded, objects of the classes will be instantiated with further transactions. The account classes above will be used to create the accounts for the scenario. The asset classes will be used to create inventory of parts in the supplier account and so on.
To create a car, the assembly objects shall be created with inventory from the parts provided by the supplier account, and the car will similarly be created with the assembly objects.
An audit may be performed at any point in the supplychain by follow object references back up the supplychain and interrogating the appropriate certificate objects and contract objects.
Similarly, a delivery validation may be performed to reject parts or assemblies that are not certified to meet the contractural obligations. The transfer of ownership of parts, assemblies and cars is realized through the use of object references.
Diagrams:
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
Customer Account only has a Vendor List. Although for a private sale, it could have a Customer List.
Asset (part, assembly, finished product) Relations
Asset (part, assembly, finished product) Relations: Example
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.
OEM
- 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
- 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.
Comments
- 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.
In the Hyperledger Fabric environment, the need for loading multiple chaincodes on a channel becomes no longer necessary. Class code is distributed to running HyperLedger Fabric nodes on demand, when needed for a node to execute a transaction that depends on a given class. In a sense, this makes a single channel multi-application capable with read/write relationships between the applications, as opposed to multi-channel multi-applications where cross-channel data is read-only.
In addition, because the XBOM design is channel agnostic, it would be possible to use classes from one channel on another channel, since class code is read-only. This would further increase the usefulness of the XBOM. (Note: this feature is not implemented in the current version)
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.
These unique advantages not only make it possible to develop new blockchain applications faster, but increase the ease of use for blockchain users.
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
The proposal and Demo of XBOM offers a completely different solution to Smart Contract based Platforms. All class code and user interface code is open source and available at XBOM.io. The demo platform will be available to all whom would like to explore the use of XBOM in use-cases, not only for supply chain, rather for any vertical that uses Fungible and Non Fungible assets.
We look forward to comment on this proposal and our approach to asset and account structures on blockchain.
