OTA Updates

Proč je OTA kritická infrastruktura¶

Špatná OTA aktualizace může brick-nout tisíce zařízení najednou. A na rozdíl od serveru, IoT zařízení v terénu nemůžete restartovat přes SSH. Nemůžete k nim dojet za hodinu. Některá jsou na střechách, v tunelech, v kontejnerech na moři.

OTA update infrastruktura pro IoT vyžaduje paranoický přístup. Každý update je potenciální brick. Každý rollout je řízený experiment. Každý krok má fallback.

Stavíme OTA systémy, kde se žádné zařízení nemůže permanentně brick-nout a žádný rollout neproběhne bez validace.

A/B Partition Schema¶

Princip¶

Zařízení má dva boot sloty: Partition A (aktivní) a Partition B (neaktivní):

1. Aktuální firmware běží na Partition A
2. OTA update se stáhne a zapíše na Partition B
3. Bootloader přepne na Partition B a restartuje
4. Nový firmware projde boot testem (health check)
5. Úspěch: Partition B se stane aktivní, A je záloha
6. Selhání: Bootloader automaticky vrátí Partition A

Výsledek: Zařízení má vždy funkční firmware. I v nejhorším případě (corrupted update, nekompatibilní firmware, hardware regression) se vrátí do předchozího stavu.

Boot test¶

Po prvním bootu na nové partition proběhne validace:

• Hardware check: Všechny senzory a periferie odpovídají
• Connectivity check: Připojení k backendu úspěšné
• Application check: Hlavní aplikace nastartuje a reportuje healthy
• Watchdog: Pokud systém nepotvrdí health do 120 sekund, watchdog vynutí restart na starou partition

Až po úspěšném boot testu se nová partition označí jako „confirmed”. Bez potvrzení = automatický rollback při dalším restartu.

Staged Rollout¶

Rollout fáze¶

Nikdy neaktualizujeme celou flotilu naráz. Staged rollout minimalizuje blast radius:

1. Internal testing (0.1%) Dev a QA tým na vlastních zařízeních. Smoke testy, manuální validace. Gate: zero critical bugs.

2. Canary (1-5%) Malá skupina produkčních zařízení, typicky v jedné lokaci. Automatický monitoring: crash rate, telemetry health, error rate. Gate: metrics stejné nebo lepší než baseline.

3. Early adopters (10-20%) Širší skupina across lokací a HW variant. Business KPI monitoring — funguje to, co má? Gate: no regression v business metriky.

4. General availability (50% → 100%) Postupné rozšíření na celou flotilu. Monitoring pokračuje. Halt kdykoliv při anomálii.

Automatická evaluace¶

Mezi každou fází automatický gate:

IF crash_rate > baseline * 1.05 THEN halt_rollout
IF telemetry_gap > 5min THEN halt_rollout  
IF error_rate > 2% THEN rollback_stage
IF business_kpi < threshold THEN halt_and_investigate

Gate je automatický — žádný člověk nemusí schvalovat v 3 ráno. Člověk zasahuje jen při halt (investigate) nebo pro override.

Differential Updates¶

Problém¶

Full firmware image pro embedded Linux: 200-500 MB. Přes mobilní síť (LTE-M, NB-IoT) to trvá desítky minut a stojí peníze. Přes satelit je to neproveditelné.

Řešení¶

Differential update posílá jen změny oproti aktuální verzi:

Binary diff (bsdiff/xdelta): Porovnání starého a nového image na binary úrovni. Typická komprese: 60-80%. 500 MB image → 100-200 MB diff.

Mender: Open-source OTA platform pro embedded Linux (Yocto, Debian). A/B updates, delta updates, device management. Self-hosted nebo SaaS.

RAUC: Lightweight update framework pro embedded Linux. Bundle-based updates, A/B slot management, custom update handlers. Nižší overhead než Mender.

SWUpdate: Flexibilní update agent. Podporuje různé update strategie, scripted updates, recovery mode.

Resumable downloads¶

Přerušený download pokračuje od místa přerušení:

• HTTP Range requests pro partial download
• Checksum per chunk (ne jen celého souboru)
• Corrupted chunk se stáhne znovu, ne celý update
• Download na pozadí, žádný dopad na normální provoz

Security¶

Firmware signing¶

Každý firmware image je digitálně podepsán:

1. Build server vytvoří image
2. Signing server (HSM-backed) podepíše image pomocí private key
3. Zařízení ověří podpis pomocí embedded public key před instalací
4. Nevalidní podpis = update odmítnut, alert do management konzole

Secure boot chain: Bootloader → kernel → rootfs → application. Každý krok ověřuje podpis dalšího. Kompromitace aplikace nemůže modifikovat kernel.

Anti-rollback¶

Zařízení sleduje monotonic counter. Každý firmware má version number. Nelze nainstalovat firmware s nižším version number než aktuální. Ochrana proti downgrade attack — útočník nemůže nainstalovat starší verzi se známou zranitelností.

Encryption¶

Firmware image šifrovaný during transit (TLS) i at rest na zařízení (AES-256). Decryption key v secure enclave (TPM, TEE). Ochrana IP — firmware nelze extrahovat a analyzovat z ukradnutého zařízení.

Scheduling a constraints¶

Ne každý okamžik je vhodný pro update:

• Maintenance window: Aktualizace jen mimo peak hours (výrobní linky: noční směna)
• Battery level: Minimálně 30% baterie, nebo připojené napájení
• Connectivity: Wi-Fi preferováno. Cellular jen pro kritické patche. Žádný update přes NB-IoT (příliš pomalé)
• User consent: Consumer zařízení — notifikace a potvrzení. Průmyslová zařízení — automaticky v maintenance window
• Dependencies: Pokud firmware vyžaduje novou verzi backendu, backend se aktualizuje první

Fleet-wide coordination¶

Nikdy neaktualizujeme všechna zařízení ve stejné lokaci současně. Staggered rollout per lokace — pokud jedna lokace má problém, ostatní nejsou postiženy.

Monitoring a reporting¶

OTA dashboard¶

• Rollout progress: Kolik zařízení aktualizováno, kolik čeká, kolik selhalo
• Version distribution: Pie chart — kolik zařízení na které verzi
• Health metriky: Crash rate, reboot count, connectivity post-update
• Error analysis: Top failure reasons, affected device types, firmware versions

Alerting¶

• Rollout success rate klesne pod 98% → halt + alert
• Reboot loop detekován (3+ restarty za 10 min) → automatic rollback + alert
• Device offline po update déle než 30 min → alert

Technologický stack¶

OTA platforms: Mender, RAUC, SWUpdate, Hawkbit, Azure IoT Hub, AWS IoT Jobs.

Diff tools: bsdiff, xdelta3, zstd compression.

Security: OpenSSL, wolfSSL, TPM 2.0, PKCS#11, secure boot (U-Boot verified boot).

Monitoring: Grafana, Prometheus, custom OTA analytics dashboard.

Build: Yocto/BitBake, Buildroot, custom CI pipeline (GitHub Actions, GitLab CI).

Souvisí s