06.12.2018
The pilot project initiated by GS1 Germany was primarily intended to test blockchain technology using standardised pallet notes as an example. But what is behind the blockchain technology applied? And, of course, how well did it all work?
Blockchain has the potential for forming an ecosystem at the process level – in this case, for an exchange process involving reusable load carriers. The great advantage of the technology is that data can be shared confidently in a network of independent parties without an individual participant (such as an intermediary) ever having full data sovereignty (the ability to view and manipulate the data). This forms the basis for efficient digitalisation of complex, sensitive processes.
Furthermore, creating a shared, consistent global process framework greatly facilitates communication and consensus-finding in problematic situations, creating trust and, in the best-case scenario, promoting behaviour that conforms to the rules. Another project goal is to show that selective sharing of data can highlight further optimisation potential, specifically looking back at things.
Blockchain technology
Currently, there are many blockchain technologies that lend themselves to the enterprise environment (private permissioned blockchain, a blockchain form in which access is restricted), but they vary greatly in complexity and functionality. Examples are:
The blockchain technology used should always reflect the requirements of the use case. This is why, for this project, we consciously chose the simplest technology that could be used in the pallet note scenario – MultiChain. MultiChain is derived directly from the Bitcoin blockchain, but does not share its disadvantages (such as low throughput and high energy consumption). This solution also enables an easy understanding of the original blockchain concepts. A heterogeneous MultiChain network is set up so that the concept of decentralisation can be evaluated without specialist IT knowledge or a major investment of resources. All other blockchain technologies are much more complex and costly to operate. Of course, MultiChain’s simplicity has its price: a pre-defined programme code (such as smart contracts) cannot be executed on the blockchain. Furthermore, it wasn’t designed to support restricted data visibility, which makes such restrictions complex to implement. The blog article on technological considerations for future deployment goes into this in more detail.
The project participants were able to choose whether they played an active or passive role in the blockchain network using various channels:
- Blockchain core network on the SAP Cloud Platform: GS1, PwC and SAP each ran a MultiChain node on SAP Cloud Platform infrastructure. These nodes form a highly available core network, which ensures that there are always blockchain nodes to validate transactions and create new blocks (mining).
- External blockchain nodes: Since operating all nodes in a single cloud violates the fundamental blockchain principle of decentralisation, most project participants set up their own MultiChain node outside SAP’s administrative sovereignty. Some of these nodes were in other clouds (Amazon Web Services or Microsoft Azure, for example) or in the company’s own data centres.•
- Pallet portal and mobile data collection: A mobile web application for smartphones and tablets, which provided access to the blockchain network via the SAP cloud, was supplied to all forwarding agent drivers and shipper/retailer warehouse workers. The pallet portal enabled administrators to interact with the pallet application (known as the ‘business view’).
The development phase
During the development phase, the team initially focused on needs analysis. It proved beneficial to focus on the end users (user-centric design) and derive the process and procedures from their needs. A first workshop, attended by a large number of the later pilot participants, resulted in a detailed description of the process and initial drafts outlining the functionality of the application.
This rough description served as the basis for the design of the final application. ‘Design’ has a number of meanings here, since it was not only screens that needed designing, but the procedures in an application. This resulted in the following tasks:
- The creation of mock-ups/high-fidelity design drafts
- The data model design using GS1 standards
- The application design of the blockchain application
The final drafts and thoughts about application
During the development phase, long after we had considered the user needs, we also came up with several more interesting ideas. This explains why, for instance, quick identification using a GS1 QR code was only tested and validated with the companies’ representatives during the development process. The final version of the high-fidelity design, therefore, came very close to the application used in the field test.
Data model design
The data model was planned to be oriented closely around the GS1 EPCIS standard – which was, incidentally, one of the participants’ requests. The transactions themselves were no problem at all, but correcting transactions and dealing with the special case of exchanging via a pallet service provider proved trickier. At the end of long discussions, with smoke coming out of our ears, we finally managed to bring the standard and the blockchain together. You can find out more about the GS1 standards used in this blog article.
Application design
A blockchain-based application is not fundamentally special in architecture or design. But there were a few things that required attention:
- Benefits of MultiChain streams
We decided to use MultiChain streams, based on the possibility of throughput optimisation. In other words, each pair of exchange partners essentially had their own ‘table’ or ‘virtual blockchain’ to avoid having to bring all transactions into the usual order required for blockchains.
- Using a separate stream for proposed transactions
Transaction proposals themselves should not be permanently written to the actual blockchain, or rather, the relevant stream. This is why we agreed on a special ‘proposal’ stream to enable a decentralised exchange of proposals. Any other form of communication, such as a message queue shared between participants, could be used as an alternative. However, in our case, this would only have increased complexity unnecessarily.
- Multi-signature transactions
To reach a consensus among partners about the content of a transaction, we decided to use multi-signature transactions. This means that both exchange partners must sign with their private key to complete the transaction.
Evaluation and usability of the pilot application
An integral component for testing the blockchain technology is the user interface of the pallet exchange application. The operability of the prototype was evaluated via a usability test before the pilot phase and improved based on the feedback. This ensured that data and transactions were stored and that operator error returned insufficient data or none at all. The usability test showed us that, for example, text legibility is critical for older users and that the font size we had selected was too small. It also showed us that many forwarding agents work internationally and that we therefore needed to incorporate more languages if all user groups were to be able to operate the application. The optimised draft then went into the pilot phase and was tested in the field in parallel to the day-to-day paper-based operations.
“Simple to use, sometimes slow to save data”
Project Manager Logistics, Dr. August Oetker Nahrungsmittel KG
The speed of the application was perceived in conflicting ways. Most users were coming into contact with blockchain technology for the first time. During our pilot project, participants compared saving to the blockchain with their experience of the internet, where normal response times are in the low two-digit millisecond range. Because it took a while for the exchange partner to be able to see the proposed transaction, participants perceived the speed of exchange as slower than what they were used to. Nevertheless, the real-time processing of the transaction, the clarity of the information, and the transparency of the exchange process were all perceived as being very advantageous. Project participants believe that there is optimisation potential, especially with regard to downstream processes.
Based on the initial usability tests, companies participating in the pilot phase were sent a questionnaire after testing the application in their routine operations. The following feedback was received:
The pros
- extreme simplification of the pallet exchange transaction when unloading
- all further processes connected to pallet notes (manual entry of the note into the computer, posting in ERP systems, managing pallet accounts, etc.) are no longer needed
- the exchange partner can be scanned, calling up the transaction immediately
- no paper
- fewer discussions about the quality of the pallets, since this has already been definitively confirmed with the transaction
- fewer document errors (e.g. illegible hand-written number of pallets)
- an overview of all exchange processes, including damaged pallets
Wish list
- date and time recorded for each transaction in the app
- as soon as a lorry delivery includes a number of sub-deliveries, a great deal of information must be added to the exchange transaction by hand. This shows how important integration into existing systems is if key information is to be linked directly.
- take a photo of damaged pallets and link it to the delivery
- increase work speed
- favourites that can be selected in advance
Responses underlined the application’s ‘attractive and intuitive design’ and also included feedback on functionality.
Development of the network and onboarding
The construction of the core network marked the real start of the test. The services provided via the SAP Cloud Platform allowed the network to be set up quickly, before connecting the other project participants.
Both subjectively and objectively (based on the survey), the installation and integration of MultiChain nodes ran very smoothly. After the actual installation, we began connecting to the existing part of the network. In other words, the administrator of the specific node ran a command in the command line – which needs to include the name of the blockchain and the physical address (IP address) of a node that is already being run. In non-public networks, this command issues the address (wallet) of the node. As soon as this has been approved by the other party (white list), the connection is established.
Field test statistics
During the actual field test, we were unable to push the blockchain to the limits of its performance – there were simply too few transactions for that. Nevertheless, the results are fascinating.
Overall, we mapped 590 real exchange procedures between 19 exchange partners over the course of two test weeks. Every day, drivers, logisticians, and back-office employees recorded more than 50 new transactions. The number of transactions was spread relatively evenly across exchange partners during the pilot operation, although the logistics participants had a slight majority.
Minor problems such as faulty log-ins, display errors, and problems with blockchain communication were either solved or worked around with other solutions.
The 590 transactions mentioned were very evenly distributed over time. There are daily peak cycles and a noticeable drop in activity over weekends. Both of these phenomena can be explained by the limited framework of the test, involving 19 test partners.
The CPU of a MultiChain (small plan) instance on the SAP Cloud Platform has a constant load of about 40% – a very respectable value, since no load spikes occurred, even during the load test (see below). The main memory had a very balanced load at 30% and is thus a reserved value of the MultiChain instance, since it does not appear to fluctuate based on use. Throughout the entire test phase, at least 11 (and no more than 13) nodes were connected in the network.
We were often met with a great deal of scepticism regarding the latency in reading from and writing to the blockchain, since this aspect has a certain reputation in public blockchains. In our case, observations fell into the categories of proposal and confirmation. For transaction proposals, the waiting time was constant at roughly 700 ms (0.7 s), while confirmation required about 1.7 s. This is primarily due to the implementation of our solution, which requires multiple writing operations in various streams to enable confirmation. There was a global error rate of 0.2% – cases in which the MultiChain network did not react quickly enough, for example.
Another important point is the storage space used. A transaction (an exchange) takes a total of about 6.4 kB of storage on the globally replicated MultiChain. In other words, the 543 exchange transactions in the field test generated about 20 MB of data. The difference arose from indexes, volatile data, and caches.
The load test
As mentioned above, because we were didn’t come anywhere near to the performance limits of the blockchain network during the field test, we decided to perform a load test on our blockchain network as a follow-up. This test was performed with an increasing number of transactions – up to one exchange per second. The results were very positive here, as well.
As previously mentioned, CPU load, storage use, and latencies did not increase during the load test, providing positive feedback for the technology used. The test itself ran for 24 hours at an average load of one transaction per second. A total of 116,665 exchange procedures were simulated. Around 700 MB of data were generated during the tests. Even at this high load, the error rate remained constant at 0.2% of transactions.
Conclusion
In both field test and the load test, the project returned a very positive technological conclusion. The technologies in direct focus were tested successfully, and the blockchain network was set up quickly and used without complications. This explains why almost all participants decided to run their own node, either in their own data centres or in the cloud. It was a great result that underscored the feasibility of decentralisation while providing good reasons for choosing MultiChain as a blockchain technology. No participants needed to solve problems with the blockchain or restart their own node during the test.
“The idea behind the application, if introduced on a large scale/in the whole industry, has the potential to greatly improve an outdated, cumbersome and inefficient process. The app fulfils the necessary requirements. It is critical that implementation in existing systems is as simple as possible if it is to be widely accepted.”
Forwarding Manager, DHL Freight GmbH Hamburg
Most participants (8 out of 11) also confirmed that they enjoyed working with the pilot solution and would continue to use it in future. This is probably because we were able to show that digitalisation does not always have to involve a loss of control and high barriers for users. A strictly user-centred design in the initial definition process, interim user tests and flexibility in designing the project framework all contributed to this fantastic result.
However, our conclusion is somewhat more nuanced with respect to blockchain as a technology and the way in which it is currently implemented. For instance, most participants ultimately state their preference to limit transparency of exchange transactions – which makes this an issue to be addressed in the event of further deployment. The use of the GS1 standard was very well-received, however, especially with respect to the integration of a pallet-exchange system in its own system landscape.
Project participants believe that digitalising the process brings significant added value; however, the greatest potential to be exploited lies after the actual pallet exchange. It now remains to be seen how a true consortium can be developed from the project – perhaps the greatest potential here also lies after the pilot project?
Kommentare
Keine Kommentare