hardware-on-demand/README.md

Hardware on Demand

# Hardware on Demand

Hardware on Demand is the process of specifically removing hardware friction (Ordering, Sourcing, Provisioning, Assembling and Distributing) from fleet owners.

An abstract overview of the hardware journey for a customer might look something like the following diagram, where their entry point would be placing an order and the completion would be receiving the hardware.

```mermaid
flowchart LR
Ordering --> Purchasing --> Provisioning --> Assembling--> Distributing
```

## Glossary

- HoD - Hardware on Demand
- EP - [EtcherPro](balena.io/etcher/pro)
- DUT - Device under Test
- PO - Purchase Order
- Operator - Individual responsible for managing hardware on production line
- BoM - Bill of Materials

## Why?

Traditionally fleet owners have been expected to source, configure and deploy their hardware, alongside the software running on top of the fleet.
This can be a huge barrier to entry for small players as challenges such as storing, ordering and distributing large quantities of hardware can be expensive in terms of cost, time and engineering power.

## What?

Hardware on Demand (HoD) is a process to abstract and remove the complexity of developing, designing, manufacturing and distributing hardware for fleet owners.
There are a number of different implementations of the process, providing a service for a number of device types and hardware options.

Presently the HoD process supports:

- SD cards
- [balenaFin](balena.io/fin)

### What is it currently not?

HoD is not a completely custom hardware assembly process, at present.
If customers want additional hardware to be included in their workflow, this must be feature requested into the HoD workflow.

## How?

We can alleviate complexity for the customer by providing, at a bare minimum, the service of flashing and distributing their hardware.

### Ordering

**Ordering** takes place via an online mechanism (TBD), leveraging balenaCloud or Shopify as an entrypoint to begin the HoD process.
This should be a self-serve process, allowing for automation from initial order through to delivery.
This process will require a number of inputs from the user:

1) Hardware required for provisioning (currently SD Card or balenaFin storage size)
2) Application or OS image to be flashed to the hardware (balenaCloud fleet or other .img)
3) Requirement for a case
4) Requirement for custom branding / packaging
5) List of address(s) for end customers
6) Payment for hardware + service

```mermaid
flowchart LR
    A(Order placed) --> B[Payment Received]
    C --> D[Purchasing]
    C --> E[Provisioning]

        subgraph Ordering
        direction LR
            B  -- send to HoD <br/>backend--> C[Create PO]
        end
```

### Purchasing

**Purchasing** will take place internally as a just-in-time mechanism for fulfilling the customer's ordering requirements.
Purchasing may require items such as cellular radios, hardware cases as well as branded packaging and stickers for hardware.

Initially supported:

- Cases
- Stickers
- Packaging

Future:

- Cellular Radio
- RPI HATS
- ect.

```mermaid
flowchart LR
    A(Ordering) --> AB{SKU in stock?} 
    A --> C[Receive PO] 
    AB -- Yes ---> B[Provisioning]

    subgraph Purchasing
        direction LR
        D  -- Next SKU --> AB
        AB -- No --> D[/Purchase SKU/] 
    end

    subgraph Invoicing
        direction LR
        C --> |Generate Invoice|F[Email Customer]
    end
```

### Provisioning

**Provisioning** is the process of flashing and/or preparing the hardware to be loaded with a custom application or fleet ready for powering on.
Most commonly this will be a balenaCloud fleet but this could also be a non-balena image, such as Ubuntu or Debian.

```mermaid
flowchart LR
    Ordering -->|Send img. <br/>to Preload Server| D[Preload Fleet Application<br /> to image file]
    Purchasing -- Send hardware<br/> to Flashing -----> E

    subgraph Preloading
        D[Download img.] --> F{Is balena fleet?}
        F -- yes --> yes[Preload application]
        F -- no --> no[d]
    end

    subgraph Flashing
        no -->|Send img. to EP| E[Operator attaches<br /> hardware to EP]
        E --> |EP flashes hardware| H[Validate flashing]

    end
    H --> J[Assembly]
```

### Assembling

**Assembly** is the process of taking the customer's BoM and assembling the constituent parts into a final product.
Initially this will be considered as the case for balenaFins and potentially stickers for SD cards / [cases](https://www.amazon.co.uk/Secure-Digital-Memory-Cards-INSDQUADBOX/dp/B003PEJODC/ref=sr_1_4?crid=11THJ75CM1SD9&keywords=sd+card+case&qid=1656089799&sprefix=sd+card+case%2Caps%2C81&sr=8-4).

```mermaid
flowchart LR

A(Provisioned <br />Hardware) --> C[Provisioned hardware<br /> & additional components]
B(Additional Components) --> C

C --> |Assembled|D[Packaged Hardware]
D --> |Packaged|E[Branding + Packaging Added]

E --> |Send Assembled hardware|Distribution

```

### Distribution

**Distribution** will be managed either as a bulk shipment back to the customer ordering via the HoD process (where they will then manage onward distrbution to their own customers) or fulfilled by HoD directly to the end customers.

```mermaid
flowchart LR

A(Assembling) --> C{Deliver to HoD<br /> customer or final<br /> customer?}

C --> |Final customer|End
C --> |HoD customer|End
```

### Future Considerations

- [ ] Custom hardware: RPi HATs, Cellular Radio, Cables, Sensors, etc.
- [ ] Custom stickers: MAC addresses, IMEI numbers, etc.
- [ ] Additional hardware devices, e.g. SBCs