European Union European Regional Development Fund        Interreg Central Baltic

Project SmartLog: blockchain in logistics

29/03/2018 Mika Lammi
Thu, 29/03/2018 - 08:33 -- Mika Lammi

SmartLog is a research and proof of concept project which aims to reduce overall cargo unit transport times in two of the European main TEN-T transport corridors – Scandinavian-Mediterranean and North Sea-Baltic. The project consortium is made up from six organizations from four countries in the Baltics: Kouvola Innovation Oy as the lead partner from Finland, Tallinn University of Technology, Valga County development agency and Sensei OÜ from Estonia, Örebro Region from Sweden and finally Transport and Telecommunications Institute from Latvia. The project is funded through European Union’s Interreg Central Baltic program, and it has a runtime of three years, starting from September 2016 and ending in the summer of 2019.

The project idea was originally conceived in late 2014, when the blockchain mainstream phenomena was just about to pick traction, and the general IoT discussion was starting to pick up the concept of blockchains and the possibilities they could offer to industrial scale use cases and implementations. The idea and the concept which followed was greatly improved through extensive talks and sparring discussions with John Cohn, IBM Fellow and Chief Scientist at Watson IoT headquarters in Munich.

The project is divided into five distinct and parallel streams of activity. Administration and Communications aside, the focus of the work is in Development, Research and Field work packages. Development WP is responsible for the blockchain software development and eventual implementation in the pilot company context. Research WP is responsible for gathering data from the companies and from the SmartLog blockchain itself, and formulating the conclusions on how exactly this technology, implemented in this way, will affect the operative and business processes of the pilot companies. Field WP is responsible for identifying, contacting and working with the logistics industry companies in the target geographical are, and ensuring that the solution offered corresponds to the real problem.

Blockchain technology

A blockchain is a distributed database that is used to maintain a continuously growing list of records, called blocks. Each block contains a timestamp and a link to a previous block. A blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. By design, blockchains are inherently resistant to modification of the data. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks and a collusion of the network majority. Functionally, a blockchain can serve as an open, distributed ledger that can record transactions between parties efficiently and in a verifiable and permanent way. The ledger itself can also be programmed to trigger transactions automatically.

Blockchains are secure by design and are an example of a distributed computing system with high fault tolerance. Decentralized consensus has therefore been achieved with a blockchain. This makes blockchains very suitable for the recording of events, medical records, and other record management activities, such as identity management, transaction processing, and documenting provenance. [Source: Wikipedia]

Originally used to power the cryptocurrency Bitcoin, the blockchain has been subject to powerful hype and interest in the past couple of years in virtually every industry. It holds a very large potential for global disruptions, much in the way of the introduction of email did into the mix of business and private communication channels in the late 80’s. Currently, the number of blockchains in the wild is exploding, largely due to the maturity of the development frameworks and general business application interest.

Industry-wide problem

The industry problem we framed in the early concept stage is, simply put, the lack of communication and information sharing between the logistics companies, especially in the supply chains part of the industry. This may seem counter-intuitive, given that the industry is all about moving things from one place to the other and knowing where the things are is the cornerstone of any business viable operation. In order to recognize this problem, we had to take several steps backward and look at the supply chains from the top level network perspective. From that vantage point, the sub-optimization of the network level activity became apparent, even though some aspects of it were well optimized.

Cargo units are moving as efficiently as the surrounding infrastructure allows them to move. There is little that can be done to make them move faster, apart from investing considerable amounts of money into new roads, railroad tracks or port infrastructures. The information pertaining to the moving of the units, as we discovered, is moving very much less efficiently, and the possibilities to affect that are very much less costly and time consuming.

There are several different communication channels and standards in use, all the time and all around the logistics and supply chain industry. Phone calls, text messages, structured and unstructured emails, fax, and the various information management systems which are in use – not only per company, but very often numerous ones inside an individual organization. Added to them, the uncountable EDI messaging dialects and conventions, and competing standards multiplied with all the companies using them create far too many potential combinations. It is impossible to have viable integrations between companies’ systems and processes, which leads to a situation where all the vital information is already out there, but siloed away into small fragments hosted by individual companies with no incentive to share.

Connecting the dots

The industry’s problem comes back to the root cause of not sharing transaction-based information efficiently enough, and the thing at which blockchain technology excels is precisely that – facilitating and securing multi-party, trustless connections which are used for transaction sharing. The project concept is about creating a blockchain that is able to store logistics and supply chain related transactions, more specifically transactions which describe the movements and status of individual intermodal containers. This information is then processed and secured in a way which makes it possible to share it to the parties to whom it is relevant – and hide it from the parties to whose business it is irrelevant.

Each party participating in the SmartLog blockchain will have their own copy of the transaction log, and interfaces and tools required to access it. They can see every container in existence which will have relevance to their operations in the future, from the moment an empty container request order has been placed, triggered by an order made by a client to the supply chain owner in question. After the container has passed the supply chain operative company’s scope of operations, they no longer need to see the information related to it. The length of the supply chain measured in participating organizations along the way correlates directly to the efficiency boost the SmartLog blockchain approach brings about. On the network level, a total visibility scenario will be realized in all participating supply chains, providing of course that a sufficient critical mass of companies start sharing their container transaction data.

Picture 1: SmartLog concept
Picture 1: SmartLog concept

Once the network level visibility has been achieved, it is possible to start leveling up the automation of the work processes involved. Sharing, updating and reacting on information types of activities can be almost instantly automated to a high degree, and the more evolved processes will not lag behind for long. The key here is that once you can trust the integrity of the information, you can start acting on it without a too much amount of human intervention or supervision.

SmartLog as a message relaying platform

In regards to the platform, what we are trying to accomplish using the Hyperledger 1.0 framework as a codebase, is to create an application logic which will accept native UBL 2.1 formatted messages primarily describing the status changes of intermodal containers during transit in supply chain, and write them into the blockchain. The messages will be encrypted before the writing process initiates, in order to preserve the information security of the stakeholders involved. The keys which enable decrypting the messages will be formed on the basis of relevance to the business process in question: whoever has an operational need to see the message, will be given the access to it. Any parties with no relevance to the message in question will not even be aware of its existence.


Picture 2: Modified UBL 2.1. data model

We will also set up a conversion service component for messaging in EDI compliant format. The conversion will be done after the message source has been authenticated, and the converted UBL structured message will then be entered as a submission to the blockchain. To further lower the barrier to entry to the piloting activities, the conversion will be offered also when authenticated attempt to read the message has been initiated.

The platform is intended to be used as a machine-to-machine message relaying solution, in the sense that all inputs will in an optimal case originate in the host organization’s own information systems, and all outputs would be readable in the same or similar, existing systems. We do however recognize the need to provide the piloting companies with tools to operate the messaging flow, and interpret it for business use not dependent on the size and capabilities of the organization. We will therefore provide the piloting companies with data entry and viewing UI templates, which can be easily modified for each organization’s relevant practices and needs in mind.

Hyperledger Fabric base architecture

Fabric’s understanding of consensus is broad and encompasses the whole transaction flow, starting from proposing a transaction to the network to committing it to the ledger. Furthermore, nodes assume different roles and tasks in the process of reaching consensus.

Within Fabric, nodes are differentiated based on whether they are clients, peers or orderers. A client acts on behalf of an end-user and creates and thereby invokes transactions. They communicate with both peers and orderers. Peers maintain the ledger and receive ordered update messages from orderers for committing new transactions to the ledger. Endorsers are a special type of peer, whereas their task is to endorse a transaction by checking whether they fulfill necessary and sufficient conditions (e.g. the provision of required signatures). Orderers provide a communication channel to clients and peers over which messages containing transactions can be broadcasted. With respect to consensus in particular, the channels ensure that all connected peers are delivered exactly the same messages with exactly the same logical order.


Picture 3: Hyperledger peer architecture


Picture 4: Hyperledger service architecture

At this point, the problem arises that there might occur faults in the delivery of messages when many mutually untrusting orderers are employed. As a consequence, a consensus algorithm has to be used in order to reach consensus despite faults, e.g. inconsistent order of messages, thus making the replication of the distributed ledger faults tolerant. With Fabric, the algorithm employed is “pluggable”, meaning that depending on application-specific requirements various algorithms can be used. For example, in order to deal with random or malicious replication faults as outlined above a variant of the Byzantine fault-tolerant (BFT) algorithms could be used. Furthermore, channels partition message flows, meaning that clients only see the messages and associated transactions of the channels they are connected to and are unaware of other channels. This way, access to transactions is restricted to involved parties only with the consequence that consensus has only to be reached at transaction level.

The roles of nodes outlined above are now described in the context of the transaction flow: A client sends a transaction to connected endorsers in order to initiate an update of the ledger. All endorsers have to agree upon the proposed transaction, thus some sort of consensus has to be reached regarding the proposed ledger update. The client now successively collects approval of all endorsers. The approved transaction is now sent to connected orderers which again reach consensus. Subsequently, the transaction is forwarded to peers holding the ledger for committing the transaction. Fabric allows fine-grained control over consensus and restricted access to transactions which results in improved performance scalability and privacy. [Source: Philipp Sandner]

Hyperledger Fabric chaincode

Smart contract code simply denotes software written in a programming language. It acts as a software agent or delegate of the party that employed it with the intention that it fulfills certain obligations, exercises rights and may take control of assets within a distributed ledger in an automated way. Thus, it takes on tasks and responsibilities in the distributed ledger world by executing code that models or emulates contract logic in the real world, though its legal justification may be unclear. [Source: Philipp Sandner]

Hyperledger features smart contracting capabilities, just as any other framework currently in development and distribution. The Hyperledger terminology for this capability is ‘chaincode’, which can be used interchangeably in place of the term ‘smart contract’.

Chaincode resides in the node structure of the Fabric, and it is used for both operating the administrative peer structure tasks, which are essential for the Fabric’s operation, and for the application specific programmatic logic, such as retrieving information from the ledger or performing an initial filtering on the results. It can be applied either generically so that each executing peer contains an identical copy of the chaincode in question, or peer specifically so that a peer’s client can invoke organization specific application logic – for example, notification of an automated billing process, based on another chaincode execution event.

Distributing SmartLog platform

Hyperledger Fabric has adopted another open source project’s technology, Docker. Docker is a digital container as a service, which enables for running program code in an environment agnostic way – the same code will run exactly in the same way, not dependent on the environment or infrastructure it is installed in.

A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.

Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, one or more apps, necessary binaries and libraries - taking up tens of GBs. VMs can also be slow to boot.
Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), and start almost instantly.

This enables us to deliver the SmartLog platform in virtually any infrastructure, and maintain the codebase much more efficiently than with environment specific compilation and conversion model.


Picture 5: SmartLog platform architecture

Conclusion

Presently, it seems that the blockchain can provide a greatly enhanced visibility and potential for process automation to the logistics and supply chains industry. The solution we have been drafting and are in the process of testing appears to be 100 % scalable, in the sense that when the mass of transaction data starts to exponentially grow, the main load of processing can be divided amongst the participants in a fair ratio, so no one would expend any resources without incurring added value.

In the near future, if we manage to create a blockchain which will gain enough participants and traction in the live business environment, there is plenty of room for follow-up projects. Firstly, the level of automation which can be brought on top of data that is trusted is significant. This type of automation is called, in blockchain terms, smart contracts and it means simply that when certain conditions in the data are met, predetermined actions can be triggered. The quantity and quality of eligible data here makes all the difference. Secondly, the sheer mass of data which will be accumulated in a quite short period of time from the companies will mean that teasing any sort of business intelligence type of meaning out of it using human analytics is impossible. Artificial intelligence techniques and technologies are the only viable approaches when dealing with such huge amounts of largely uniform structured data. We have already submitted funding applications which will cover both aspects mentioned above, and more.

The future of the logistics industry, by all indicators, seems to be very much ripe for a large scale digital disruption. The only question each one of the actors in the field must ask and answer is, do we want to be a part of it or do we let it happen to us?

Tags: