From 5b8566e69c91b0634c23b368305e3c14d41dfc24 Mon Sep 17 00:00:00 2001
From: deeaitch <himrodim@gmail.com>
Date: Wed, 29 Jul 2026 17:12:21 -0400
Subject: [PATCH] OTA overview

---
 docs/01-what-is-an-ota-update.md | 227 +++++++++++++++++++++++++++++++
 1 file changed, 227 insertions(+)
 create mode 100644 docs/01-what-is-an-ota-update.md

diff --git a/docs/01-what-is-an-ota-update.md b/docs/01-what-is-an-ota-update.md
new file mode 100644
index 0000000..27943fa
--- /dev/null
+++ b/docs/01-what-is-an-ota-update.md
@@ -0,0 +1,227 @@
+# What Is an OTA Update?
+
+> **Series:** OTA Reference Design
+>
+> This article is the first chapter of a practical reference design describing how reliable and secure over-the-air software updates are built for embedded Linux devices.
+
+---
+
+# Introduction
+
+Almost every modern connected device receives software updates remotely.
+
+Phones do it.
+
+Cars do it.
+
+Industrial controllers do it.
+
+Medical devices do it.
+
+Consumer electronics quietly update themselves while nobody is watching.
+
+This process is commonly known as an **Over-the-Air (OTA) update**.
+
+At first glance, the idea seems simple:
+
+> Download new software and install it.
+
+In reality, OTA is one of the most challenging reliability problems in embedded systems.
+
+---
+
+# Why OTA Is Different
+
+Updating software on a desktop computer is usually forgiving.
+
+If something goes wrong, the user can often retry the installation, download the package again, or reinstall the operating system.
+
+Embedded devices rarely have that luxury.
+
+Imagine a device installed:
+
+- on the roof of a building;
+- inside industrial equipment;
+- on a remote oil pipeline;
+- in a laboratory instrument;
+- in an autonomous vehicle.
+
+A failed update may leave the device completely unreachable.
+
+Nobody may be available to reconnect a keyboard, attach a monitor, or reflash storage.
+
+For embedded systems, software updates must be designed with failure as an expected condition rather than an exceptional one.
+
+---
+
+# The Real Problem
+
+The primary goal of an OTA system is surprisingly simple:
+
+> **Replace the software while always preserving a path to recovery.**
+
+Everything else exists to support this objective.
+
+Notice that this definition says nothing about how the update is delivered or installed.
+
+The engineering problem remains the same regardless of the implementation.
+
+---
+
+# Many Ways to Solve the Same Problem
+
+Different products solve OTA updates in different ways.
+
+An update may be based on:
+
+- complete system images;
+- software packages;
+- application bundles;
+- containers;
+- custom update formats.
+
+These are implementation choices.
+
+Each approach has its own strengths, weaknesses, and trade-offs.
+
+Throughout this series we will explore these options and discuss where each of them makes sense.
+
+---
+
+# Typical Failure Scenarios
+
+A robust OTA implementation assumes that failures are inevitable.
+
+Examples include:
+
+- power loss during installation;
+- interrupted network connection;
+- corrupted download;
+- damaged storage;
+- software crash during the first boot;
+- incompatible configuration;
+- interrupted filesystem writes;
+- unexpected reboot.
+
+None of these situations is unusual.
+
+If enough devices are deployed, every one of them will eventually happen.
+
+The question is never **if**.
+
+Only **when**.
+
+---
+
+# OTA Is a System, Not a Feature
+
+OTA is often imagined as a single application responsible for installing updates.
+
+In practice, it is an entire system composed of multiple cooperating components.
+
+A typical embedded Linux solution may include:
+
+- bootloader;
+- Linux kernel;
+- root filesystem;
+- update agent;
+- storage layout;
+- cryptographic verification;
+- backend services;
+- device identity;
+- rollback mechanism;
+- health monitoring.
+
+Each component has a specific responsibility.
+
+Only together do they provide a reliable update process.
+
+---
+
+# A Better Mental Model
+
+Instead of thinking:
+
+```
+download
+    ↓
+install
+```
+
+think:
+
+```
+prepare
+    ↓
+verify
+    ↓
+store safely
+    ↓
+activate
+    ↓
+boot
+    ↓
+health check
+    ↓
+commit
+      │
+      └── rollback if necessary
+```
+
+Almost every production OTA solution follows some variation of this workflow.
+
+The individual technologies may differ.
+
+The underlying principles remain remarkably similar.
+
+---
+
+# What This Series Covers
+
+Rather than focusing on a particular framework or vendor, this repository explains the engineering principles behind reliable OTA systems.
+
+Topics include:
+
+- OTA architectures;
+- update strategies;
+- boot process;
+- storage layouts;
+- A/B partitioning;
+- rollback mechanisms;
+- image verification;
+- cryptographic signatures;
+- update servers;
+- recovery strategies;
+- production considerations.
+
+Examples will use embedded Linux running on Raspberry Pi, but the concepts apply to many embedded platforms.
+
+---
+
+# Summary
+
+OTA updates are often described as "remote software updates."
+
+While technically correct, this definition misses the real engineering challenge.
+
+The true objective is ensuring that **the device remains recoverable after every possible failure during the update process.**
+
+Everything else—from storage layouts to cryptographic signatures—exists to support that goal.
+
+---
+
+## Key Takeaways
+
+- OTA is fundamentally a reliability problem.
+- Failures must be expected, not treated as exceptions.
+- Multiple implementation strategies exist for OTA systems.
+- The core objective is always safe recovery.
+- Technologies change, but the engineering principles remain the same.
+
+---
+
+## Next Article
+
+The next chapter explores the first major architectural decision in any OTA system:
+
+> **Update Strategies: Full Images, Packages, or Something Else?**
\ No newline at end of file