Home About

Heka

Heka is a school project I’ve been working on for the past few months. It explores the use of wireless mesh networking to facilitate last-mile delivery of vaccine payload during an epidemic crisis.

This post is a brief summary of what went down over the duration of the entire project.

Context

At the start of the semester, we were given a few challenge statements to work on. After coming up with a project, we did a three-day hackathon to build prototypes and pitch (This was a graded assessment, so our grades were pretty much riding this hackathon 🥴).

Pitching for our grades to SAP Reps

FAQ: Why was the team name “Battle Royale”?

Initially joking around about how there has recently been a battle royale gamemode for every game, my groupmates and I teamed up with the idea titled “Vaccine battle royale”.

The joke was to, much like in battle royale video games, distribute vaccines airdrop-style to civilians.

Now, we may have taken that joke a bit too far during the initial stages, but when a sudden stroke of inspiration hit— the idea just sort of crystalised.

Challenges

We started by laying out the challenges we wanted to tackle in getting self-administered vaccines out to everyone.

Medical diagnosis is no joke and requires someone with extensive domain knowledge, trying to come up with a tech solution for useful medical diagnosis without any sort of domain knowledge in this small timeframe is honestly just a dead end.

Macro

Looking the scope of our selected challenges, the problem we were trying to solve pretty much covered the supply chain and distribution aspects of things.

Our initial idea? Just put a tracker on the packages and hook that up with some cloud IoT provider.

While the solution to tracking delivery and distribution seemed relatively straightforward then, we realised that this solution was very naive (cost, point of failure, doesn’t solve other challenge statements).

So, how do we quickly distribute vaccines to everyone?

Right now, vaccines are presumably brought to distribution points where they are dispensed to civilians. With this existing model, there is no way that weaving technology into this process would benefit the situation.

As software people focusing on the digital product, it is very difficult to see that sometimes, digitalising processes is not the best way to solve things.

If we built an app/website to track distribution progress and medical personnel, we would be complicating the distribution progress even more. It’s an epidemic and people are already panicky, installing an app/registering with your website is the last thing they will want to do.

Philosophy

So, we took a step back and laid down core principles that our solution should follow.

“During an epidemic, it is everyone’s responsibility to do their part to curb the outbreak of any infectious disease.”

Our solution to this issue thus took a more society-driven approach. Our goal was to create something that empowers the civilian community to do their part.

A Decentralised Approach

What if civilians did the distribution in a chain fashion?

Propogating packages containing vaccine payload in pre-computed routes— can this be a faster, smarter way to distribute vaccines? How would we then track and monitor the distribution process?

From a technical perspective, keeping track of packages and devices with a conventional client-server model at such a scale is costly.

Going off-grid

So, this led me to formulate an actually fully decentralised distribution model: not only in the sense of physical distribution, but also for the app that would facilitate this distribution.

We could keep track of all local information about nearby civilians and the distribution process on a P2P Network, and only rely on a backend to verify and register new peers onto the network?

This idea did seem pretty cool, so my team did a quick writeup along with a simple technical model, and we started work on it.

Significance of the supply chain

According to the WHO, much of the world’s burden of disease can be prevented or cured with known, affordable technologies.

The problem is getting drugs, vaccines, and information to those who need them on time, reliably, and at a reasonable cost.

Fully civilian-driven

With the help of civilian volunteers to kick off the distribution chain, we envision this to be a 100% civilian driven means of payload distribution.

Agile

Without the conventional overhead from last-mile distribution/delivery, people will be able to receive proper vaccination quicker.

Offline

Heka aims to be as frictionless as possible, as such, the distribution process is completely offline and done on the distributed network.

Trackable

Making use of metadata sent from whenever there is an available internet connection on the users’ devices, we are able to analyse package spread patterns to follow the progress of package distribution.

Why?

More accessible

A civilian-driven means of distribution is much more affordable as it eliminates the conventional hassle and costs with conventional last-mile delivery methods.

Medical Assistance

Without the need of a medical personnel to distribute the vaccine, more professional attention can be directed to civilians in need of assistance. Users with disabilities or elderly can request medical assistance to help administer the vaccine.

So for our prototype, the idea was to build a small scale P2P network to demonstrate how it can facilitate the civilian delivery process.

Our hackathon workstation

I wrote a simple demo iOS app, building a library on top of iOS’s Multipeer Connectivity Framework to support the transmission of unified data throughout a P2P network (Almost our entire team uses iPhone).

Peers on the network with internet connection update a simple Node-backed application that caches network state with Redis. The idea was to carry out validation of new peers on the network server side.

Design

Quick designs to ensure that our prototype brings accross it’s application to real life.

Check out the demo app on Github.

Winning the hackathon!

Re-thinking our project

Since the hackathon, we reviewed and discussed the feedback that we received in order to determine our next steps.

Some important issues from feedback that we got from the SAP panel, and reflections was:

In lieu of the oncoming assignments, we decided that it was probably best to build on top of our existing projects, we also still had an admin dashboard to work on, Jeremy and Yong Kang took responsibility for this segment.

Shift of focus

After the hackathon, we discussed that our project should be more focused on the technology behind the decentralized last-mile delivery method, rather than the application of it to vaccine distribution.

Our reasoning was that we already got the affirmation we needed from winning the first hackathon about the usefulness of this technology.

And so, we felt that this project would be much more interesting if we explored deeper into improving the technology, rather than creating a polished product.

Re-design

With our new focus, I redesigned and simplified the iOS App with debuggability in mind.

I patched up most of the bugs in the P2P Library with the help of a nifty debugger to make transaction handling more reliable.

Here you can peek into the details of interactions between other peers on the network, allowing us to debug on-the-go and accross all test devices.

Securing Transactions

Because we still have to store vaccine transaction records in a central silo, this makes it insecure and difficult to scale across a wider region. We thought about this and what steps to take in order to solve this problem.

Distributed ledgers

The idea behind a distributed ledger seems to be a useful solution to this issue as it would solve issues with scaling and security.

Setting up the slave

In order for us to keep a distributed ledger of medical records, I need to implement a ‘slave’ client that can be distributed for nodes to join the mining pool. This client will need to be socketed with the server to receive and send blocks to mine. Upon receiving each block, the client should start validating it, replying with a solved block and adding it to it’s ledger.

Because the server is written in JavaScript, It would be best to write the slave in JS as well in order to be more consistent with the socketing library that we would make use of.

The miner client was written in javascript, and uses socket.io for socket connections to the server.

Blocks

In this case, our transactions are not very complex, so we decied to not use any form of hash tree (Merkle) to store transactions in each block.

Proof of work

Following traditional blockchain implementations, I used the proof of work algorithm to mine blocks. The PoW algorithm is how blocks are created on the blockchain.

Miner clients will compete to mine the current through hashing the identity of the current block with a nonce.

Blockchain-as-a-service?

In order to facilite the validation of mined blocks, I had to collaborate with my teammate working on the server to poll for new blocks to mine.

Key technologies

At this point, I think its worthwhile to mention a few key technologies/tooling/platforms (other than SAP IoT) that have made our solutions possible:

We were very excited to update everyone about the progress of our project, and had fun talking and connecting with people during a student showcase event.

SAP representatives expressed their ideas and thoughts about our project, which sparked some very interesting discussion about industry trends, and the viability of this last-mile delivery technology accross different fields.