# Akri Scenario: Distribution of Vaccines
###### tags: `Scenarios`

[TOC]

## Synopsis

As of writing, the distribution of vaccines is a particularly relevant top of interest. Pfizer’s Covid-19 vaccine (one of several), must be maintained at -70℃ in order to ensure its efficacy. Vaccines must be transported safely from manufacturing locations to pharmacists who will then inject people with the vaccine.

## Scenario
The prototype scenario will model some subset of the production, distribution and consumption of vaccines. At each of these stages, different IoT devices, networks and other protocols will be involved (e.g. trucks communicating GPS locations, refrigerators reporting vaccine temperatures). These diverse technologies are “homogenized” by Akri into a set of more easily usable Kubernetes resources. Akri thus helps unleash the development of applications that are relevant to the safe production and transmission of vaccines.

## Rationale
Akri users benefit from realistic use-cases. Vaccine-distribution is a relevant scenario that benefits from IoT mechanisms providing real-time information of delivery truck locations and vaccine state. The scenario provides multiple possible implementation choices including network and transport protocols and device APIs. There are various prospective users of such a scenario, each having different needs.

## Assumptions
In reality, constituent “actors” (see below) would communicate using a myriad of network technologies (e.g. mobile networks, wifi, bluetooth). In the scenario, these networks will be simplified to HTTP over TCP to ensure that every developer is able to run those pieces of the scenario that they wish.

## Akri

Due to the diversity of “actors” (see below), IoT devices and users of the scenario, without akri each application developer would need to implement an extensive stack of technologies before they were able to begin developing relevant applications atop the stack. With Akri, this complexity is reduced. Different devices, network and other protocols, security mechanisms and APIs are reduced to a possible single technology stack. This reduced complexity allows developers to focus on building relevant applications atop this stack and not spending time dealing with connectivity, networking and other issues. In theory this should unleash developer productivity and apps that significantly improve the process (reduce manufacturing time|cost, improve delivery efficiency etc.).

## Actors
Actors are the constituent members of the scenario: pharmaceutical companies, vaccine manufacturing companies, distribution|trucking companies, the trucks, the refrigerators on the trucks etc. Each actor has some role to play and may be represented specifically within the scenario

### Pharmaceutical Company

### Trucking Company

### Truck
* Manifest as an IoT device “truck”. In reality there would likely be multiple types of these devices and each would have different interaction patterns (security, APIs etc.).
* In the scenario, trucks will be represented as HTTP/TCP-based Docker containers.
* A truck comprises some unique identifier, a GPS location, some set of “cargo” (list of vaccines), some health metrics (e.g. fuel, state [running, broken down]).

### Refrigerator
* In reality, it is unlikely that refrigerators would be represented as specific IoT devices.
* In the scenario, refrigerators will be represented as HTTP/TCP-based Docker containers.
* A refrigerator comprises some unique identifier, a location (e.g. manufacturing depot, truck, distribution point e.g. hospital or grocery store), its cargo (vaccines) and, importantly its health (e.g. state [running], temperature -70℃, its temperature history to ensure it hasn’t had an “excursion”.

### Units of Vaccine (distribution)
* Rather than model individual doses of a vaccine, these will be modeled in the aggregate as some amount of vaccine that’s sold by the pharmaceutical company to a distribution point (e.g. hospital).
* Units of vaccine comprise one or more unique identifiers, manufacturing details (dates, plant, line, machines etc. etc. This would be detailed).

### Distribution Point (e.g. Hospital, Grocery Store)
In reality, it is unlikely that distribution points would be represented by anything beyond a customer record in the e.g. pharmaceutical and trucking companies’ databases.
In the scenario, distribution points will be modeled as receiving vaccines.

## Customer User Journeys

### 1. Vaccine

1. Some units of vaccine are produced and stored pending shipment.
1. The units of vaccine are delivered to a shipper and then stored.
1. The units of vaccine are shipped (e.g. by truck). The pharmaceutical company, trucking company and customer (e.g. hospital) are all interested in this data for different reasons.
1. The state of the units of vaccine within the refrigeration mechanism is continually monitored. This information is useful to the shipper and the pharmaceutical company. If there’s an “excursion” beyond tolerances, the vaccine must be returned|destroy and replaced.
1. The units of vaccine are delivered and stored.
1. Individual doses of vaccine are administered to an individual. Everyone in the chain would benefit from knowing which vaccine specifically was dispensed and to whom.
1. Individual doses of vaccine are administered to an individual. Everyone in the chain would benefit from knowing which vaccine specifically was dispensed and to whom.

### 2. Truck

1. Some units of vaccine are loaded into a refrigerator and the refrigerator is then loaded|connected to a truck. 1. From a data perspective, the units of vaccine are 'associated' with the refrigerator becomes 'associated' with the truck
1. The truck moves from the trucking depot through a route comprising multiple drop-off locations. At each drop-off, units of vaccine are unloaded and ownership is transferred to the distribution point.

## Prototype(s)

|Repo|Description|
|----|-----------|
|[WebThing Vaccine](https://github.com/DazWilkin/webthing-vaccine)|Rust WebThing Refrigerator/Truck w/ basic Golang API client|