2020: DAC’s odyssey
By: Marek S. Tatara
Tags: Blockchain, Hackathons, Beacons, Supply Chain, Programming

The problem

Our team joined a challenge called the Internet of Logistics as part of the Circular Economy for Freight Packaging track. The problem we were trying to solve revolved around Returnable Transport Items (RTIs) — reusable containers used for moving or transporting goods. Although RTIs are usually not in the spotlight of stakeholders’ interests, RTIs loss or damage, according to a Dutch mutual insurance company TVM, may cost a single transporter €150,000 to €3,000,000 a year (not to mention the environmental impact). Therefore, an adequate system for tracking and tracing of not only the transported goods but the RTIs as well could reduce the financial burden of logistic companies.

Our pre-hackathon vision

In our first approach, we wanted to develop a solution fostering an ecosystem for balancing RTIs among the participants. The idea was that everyone starts from tabula rasa with a balance equal to zero. Then, each transaction either increases or decreases the balance of both parties taking part in the deal. The intention was to have a zero-sum game in the ecosystem — which means that at every moment, the sum of all balances must be equal to zero. To spice things up, all the updates related to balances were to be stored in a smart contract on the Ethereum blockchain. To increase the user experience, we wanted also to offer a filtering feature on a map, where all the participants of the ecosystem are shown with their balances.

The final view of the developed application

All this was quite a charming idea. Let’s say that you need 20 containers. What do you do? You simply open the app, filter by the number of RTIs you’d like to have and your preferred distance (as a radius from your location), and contact whoever seems to have a surplus as displayed on the map. You want to get rid of 100 pallets because you don’t have enough space? Just set up an appropriate filter and search for those who have a deficit of RTIs — they’ll probably use some in the nearest future. Simple as that.

And we actually did it. Front-end in Angular with OpenStreetMaps, Java+Spring back-end, Ethereum smart contract (written in Solidity using Truffle Suite), and PostgreSQL database for storing more information than just balances.

Let’s stop here for a while and take a closer look at the layers we’ve built. In order to help you fully grasp how the system works let’s describe them, one by one, bottom-up.

Blockchain interface — on this layer, that lies at the very bottom of our solution, we have provided a specification of the developed smart contract and how to interact with it. Since the solution was designed to support either private or public blockchains, and also respect the privacy of the ecosystem users, the amount of information stored on the blockchain should be minimal. Therefore, we store just the RTI balances for each participant, and a single balance is changed only once the transaction is confirmed (so, from that point on, there is no easy way to revert it). The interface has been augmented in the course of the development to address the comments from the jury constantly overlooking the development of our application. The final smart contract holds balances of different RTI types. A corresponding service on the back-end has been developed to interact with the smart contract and thus abstract the complexities typically associated with the blockchain. In consequence, it was exposed as an API and can be regarded as the first and base pillar of our solution. Back-end — in addition to the core blockchain-integrated functionality, we have also developed a fully functional set of services to monitor and execute transactions between stakeholders. This part was built as an addition to the blockchain interface to provide more functionalities than just change of the balances: RTI monitoring and tracking, querying for partners that are matching criteria related to their RTI balance, transactions execution, to name a few. In order to not abuse the blockchain usage, a PostgreSQL database has been designed to store the additional information related to the current state of single RTIs/batch of RTIs, or stakeholders’ contact information. The resultant specification of API can be treated as a second layer of our solution and can be used to integrate existing systems with the developed ecosystem. Front-end — for those who don’t have their own solution or want to have a separate toolchain for RTIs management, a web application integrating the aforementioned functionalities has been put together. It has been deployed on our Kubernetes infrastructure, where users can log in and manage their RTI transactions, check balances of partners in the ecosystem, filter partners that have a deficit/surplus of RTIs on a map, or track their own deliveries. This is the third layer of our system and it is intended to complement the two former ones.

The emphasis here is put on the fact that stakeholders can integrate with the system across ANY of the above-mentioned levels. If they have a system that monitors the balance of RTIs — they can use only the blockchain connector. If they have a proprietary system and want to extend it — they can integrate it on the second layer. Finally, if a stakeholder looks for a new tool — the third layer it is.

The cherry on top is the DevOps layer used to maintain the whole development and integration process. The dockerized applications were deployed on a Kubernetes cluster and the deployment was automated by appropriate pipelines integrated with the repository.

This is the baseline we wanted to deliver, and we did. But the day the hackathon started we came up with some ideas to spice things up.

The last-minute change of plans

We asked ourselves, how the general flow of the transactions looks like. What happens when a container is lost? How to automate and simplify monitoring or counting of the RTIs? In the end, we decided that we want to also include some icing on our cake.

The first feature that was added to the system is fine-grained tracking and automated counting of RTIs. To do this, Bluetooth Low Energy beacons were employed with the intention to be attached to RTIs. A single beacon advertises its UUID, battery level, and the type of RTI to which it is attached. Such information should be captured somehow, therefore we employed the Raspberry Pi to fill in as a scanner. To fit our idea, we had to design a scanner that is installed near a gate through which the truck is passing while leaving or entering a facility, and another one that is traveling with the goods (either attached to the truck or loaded with the cargo). The purpose of the gate scanner was to provide information about the beacons leaving or entering the facility. The truck scanner was designed to continuously monitor the state of a batch of RTIs and, thanks to the attached GPS module, to send it to the backend. Both scanners were designed to work out-of-the-box, so after plugging them in, they are up and running in less than 30 seconds. Bear in mind though, that this physical layer was only an addition to the developed baseline to simplify and automate the process of counting, adding our RTIs tracking solution some extra flavor. In other words, the system will be working without it as well, and can even integrate two stakeholders, where one works with and the other without this layer. Therefore, this is the fourth (physical) layer of the system.

Hardware used in our project — Raspberry Pi (left) and HM-10 beacons (right)

Finally, to take advantage of the continuous monitoring, we integrated on the front-end a near real-time tracking system for single RTIs. Moreover, in case any package gets lost or stolen while in transit, our system would alert the driver by triggering a text message containing details of that package and its last-seen location via Twilio gateway.

SMS alert sent to the holder when an RTI is lost

The last thing we initially didn’t want to include in our system was support for different types of RTIs. But, since all the parts of the systems were designed to be flexible and already had support for multiple types of RTIs, we decided to give it a try — and it eventually worked. It required us to make some changes to the front-end, but ultimately filtering by RTI type and reading RTI types from the API provided by one of the stakeholders was fully functional.

Final result

The final solution was tested in an experimental setup where we placed two gate scanners, one on a truck, and six beacons to simulate RTIs. During the live demo, we were able to collect the packages, pass through gates, simulate the loss of one package, pass the second gate, and drop the package. It was continuously monitored and visualized in our system, while all the assumed functionalities were working like a charm.

The final result can be summarized in the following picture:

The architecture of the developed solution with layers 1–3 visualized

We are still excited about what we achieved in less than 50 hours. We didn’t win, but we feel that the goal was achieved by 200%. Kudos to the winners (you can check out their solution here) — this time we were not the best, but we want to raise the bar. Now it’s time to draw some post-hackathon conclusions, make the solution bulletproof, and hit the market.