Arsitektur OTA: Monolit vs Modular & Trade-off Kompatibilitas

Latar Belakang: Risiko Regresi pada Sistem Terintegrasi

Pembaruan Over-The-Air (OTA) pada perangkat edge seperti In-Vehicle Infotainment (IVI) atau telematics gateway membawa risiko tinggi terhadap integrasi eksternal. Kasus umum terjadi pada ekosistem proyeksi pihak ketiga seperti Android Auto atau Apple CarPlay: pembaruan minor pada stack Bluetooth, USB gadget driver, atau IPC (Inter-Process Communication) daemon lokal dapat memutus kompatibilitas protokol handshake. Kegagalan ini biasanya tidak memicu kernel panic, namun fungsionalitas kritis pengguna rusak total.

Akar kegagalan ini berpusat pada pemilihan arsitektur OTA: apakah sistem harus diperbarui secara atomik sebagai satu kesatuan utuh (monolit), atau dipecah menjadi subsistem independen (modular)? Keputusan ini menentukan determinisme sistem, kebutuhan storage, konsumsi bandwidth, dan batas toleransi kegagalan.

Pola Arsitektur: Monolit vs Modular

1. Monolithic Firmware Update (Full OS Image)

Pendekatan monolitik mendistribusikan sistem operasi utuh menggunakan skema partisi ganda (A/B Partitioning). Update ditulis langsung ke partisi pasif (misal: slot_b saat slot_a aktif) pada tingkat block device (bit-by-bit atau block delta compression).

• Mekanisme Validasi: Hash block-level (dm-verity) memverifikasi integritas seluruh filesystem sebelum sistem switch boot flag.
• Keuntungan: Determinisme mutlak. Matriks dependensi hanya ada satu: konfigurasi image lab sama persis dengan yang berjalan di unit client. State drift antar pustaka dinamis (shared libraries) mustahil terjadi.
• Kelemahan: Payload besar. Update patch kecil memerlukan re-flashing partisi skala gigabyte atau pembuatan block-delta yang membebani komputasi cloud.

2. Modular Component Update (Subsystem Packages)

Pendekatan modular memisahkan stack sistem ke dalam beberapa layer terisolasi (misalnya: base BSP/kernel, middleware framework, dan application packages/containers). Pembaruan ditargetkan per paket spesifik melalui package manager internal atau update container image independen.

• Mekanisme Validasi: Package signing berbasis cryptographic keys dan runtime dynamic linking resolution.
• Keuntungan: Efisiensi transfer data sangat tinggi. Hanya layer bermasalah yang didistribusikan.
• Kelemahan: Ledakan matriks kombinasi status sistem (combinatorial state explosion). Client A menjalankan Kernel v1.2 + HAL v2.1 + App v3.0, sedangkan Client B menjalankan Kernel v1.0 + HAL v2.0 + App v3.0. Menguji seluruh permutasi sebelum rilis hampir mustahil.

Evaluasi Trade-off Teknis

Verifikasi Backward Compatibility: Contract & Negotiation

Pada arsitektur modular, regresi protokol periferal terjadi karena asumsi kontrak API/IPC dilanggar. Dua pola rekayasa wajib diterapkan:

1. Schema-First Contract Definition

Definisikan seluruh IPC lokal (D-Bus, binder, gRPC domain socket) menggunakan skema eksplisit dengan field numbering ketat. Protokol tidak boleh bergantung pada struct memory layout C polos yang rentan terhadap perbedaan compiler optimization.

2. Runtime Capability Negotiation Handshake

Sebelum memulai transfer frame data atau peripheral projection, layer klien dan daemon periferal wajib melakukan feature handshake. Jika ada ketidaksesuaian versi mayor, sistem fallback ke protokol terendah yang didukung, bukan langsung abort koneksi.

package main

import (
	"errors"
	"fmt"
)

type ProtocolVersion struct {
	Major uint32
	Minor uint32
}

type HandshakeRequest struct {
	ClientVersion ProtocolVersion
	Features      []string
}

type HandshakeResponse struct {
	NegotiatedMajor uint32
	NegotiatedMinor uint32
	ActiveFeatures  []string
}

var (
	ErrUnsupportedMajor = errors.New("ERR_PROTOCOL_MISMATCH: Incompatible major version")
	SupportedMajor      = uint32(2)
	SupportedMinors     = []uint32{0, 1, 2}
)

func NegotiateProtocol(req HandshakeRequest) (*HandshakeResponse, error) {
	// Rule: Major version breaking, minor version backward-compatible
	if req.ClientVersion.Major != SupportedMajor {
		return nil, fmt.Errorf("%w: client sent %d, required %d", 
			ErrUnsupportedMajor, req.ClientVersion.Major, SupportedMajor)
	}

	selectedMinor := uint32(0)
	for _, m := range SupportedMinors {
		if m <= req.ClientVersion.Minor && m > selectedMinor {
			selectedMinor = m
		}
	}

	// Filter common feature flags
	supportedMap := map[string]bool{
		"audio_sink_v2": true,
		"h264_stream":   true,
		"wireless_proj": true,
	}

	activeFeatures := make([]string, 0, len(req.Features))
	for _, f := range req.Features {
		if supportedMap[f] {
			activeFeatures = append(activeFeatures, f)
		}
	}

	return &HandshakeResponse{
		NegotiatedMajor: SupportedMajor,
		NegotiatedMinor: selectedMinor,
		ActiveFeatures:  activeFeatures,
	}, nil
}

Canary Rollout dan Automated Rollback

Jangan pernah mendistribusikan OTA langsung ke 100% populasi armada edge. Pola distribusi bertahap (canary) wajib dipadukan dengan health-check verification loop lokal pada perangkat.

1. Tahap Canary: Distribusi ke 1% populasi (fase uji armada operasional internal).
2. Stage Rollout: Naik bertahap ke 5%, 25%, 100% berdasarkan analitik telemetri error-free window (72 jam per stage).
3. Device-side Automated Rollback: Jika sistem baru boot, jangan langsung tandai slot sebagai berhasil (mark boot successful). Jalankan sequence verifikasi integrasi eksternal terlebih dahulu.

Contoh Skrip Health-Check Watchdog (Systemd/Bootctl Integration)

Script berikut dijalankan via systemd one-shot service setelah boot target selesai pada slot baru. Jika peripheral gateway gagal merespons dalam durasi grace period, status slot ditandai rusak dan perangkat me-reboot ke slot lama.

#!/usr/bin/env bash
set -euo pipefail

# Health check periferal eksternal (IPC Daemon & Accessory Interface)
TIMEOUT_SECONDS=60
ENDPOINT_SOCKET="/run/accessory/projection.sock"
PASSED=0

echo "[HEALTHCHECK] Memulai verifikasi fungsionalitas integrasi periferal..."

for ((i=1; i<=TIMEOUT_SECONDS; i++)); do
    if [ -S "$ENDPOINT_SOCKET" ]; then
        # Ping IPC daemon menggunakan test payload
        RESPONSE=$(nc -U -w 2 "$ENDPOINT_SOCKET" <<< '{"cmd":"PING_PROJECTION_READY"}' || true)
        if [[ "$RESPONSE" == *'"status":"OK"'* ]]; then
            echo "[HEALTHCHECK] Daemon merespons valid pada detik ke-$i."
            PASSED=1
            break
        fi
    fi
    sleep 1
done

if [ "$PASSED" -eq 1 ]; then
    echo "[HEALTHCHECK] Integrasi periferal terverifikasi. Konfirmasi slot boot."
    # Memanggil boot control subsystem (contoh: systemd-boot / U-Boot bootctl)
    bootctl mark-boot-successful
    exit 0
else
    echo "[CRITICAL] Integrasi periferal gagal! Membatalkan slot boot dan revert..."
    # Mengurangi counter boot attempt slot aktif menjadi 0 agar bootloader fallback ke slot alternatif
    systemctl reboot
fi

Panduan Pemilihan Arsitektur

• Pilih Monolitik A/B jika: Keandalan mutlak adalah prioritas (otomotif, avionik, alat medis), batasan bandwidth seluler bukan kendala utama, atau tim QA tidak memiliki resource untuk memvalidasi jutaan variasi kombinasi paket dinamis.
• Pilih Modular jika: Perangkat dibatasi kuota transfer data ekstrem (satellite IoT), aplikasi bisnis diperbarui mingguan tanpa menyentuh core driver, atau sistem memiliki runtime container native (misal: embedded OCI container) yang mengisolasi total dependency antar daemon.