Update
Updates for Industrial Embedded Linux.
OTA Updates for Industrial Devices
Industrial embedded devices require fully automated update mechanisms that function without human intervention. OTA update systems must accommodate diverse storage media including NAND flash, NOR flash, eMMC modules, SD cards, and address diverse deployment requirements.
Modern system-on-chip architectures introduce complexity beyond simple software replacement. Contemporary embedded systems incorporate heterogeneous processing elements: application processors running Linux, real-time processors executing RTOS, FPGAs requiring bitstream updates, and more. Each component demands specialized update procedures while maintaining coordination with the overall system update process.
Industrial requirements impose stringent constraints. Deployed devices often lack local operators or must be rolled out at massive scale, necessitating automatic recovery mechanisms.
Our Industrial Grade Linux OS includes an A/B update mechanism with rollback protection pre-integrated — so teams don’t have to build the update client, server coordination, and signing pipeline from scratch.
A/B OTA Update Architecture
A/B updates have become the de facto standard for industrial applications where reliability outweighs storage costs. The basic update architecture includes two connected components:
Update client
A system service running on the embedded device that monitors for available updates through periodic polling or push notifications. Upon detecting updates, the client downloads packages and performs preliminary validation including signature verification before installation. The client executes the installation, manages configuration, coordinates system reboots, and performs health checks to verify successful update
Update Server
A management infrastructure that stores update images, maintains device inventory, manages update campaigns, and more. The server authenticates devices, serves update packages, and provides rollout control mechanisms including phased deployments.
The communication flow
The communication flow proceeds through several phases.
- First, the update client receives a push notification from the update server that an update is available.
- The server sends update metadata including version information and package checksums.
- The client evaluates compatibility and available storage before requesting the full update package.
- During download, the client verifies cryptographic signatures.
- After installation to the inactive partition, the client modifies bootloader configuration and triggers a system reboot.
- Post-reboot health monitoring determines update success, and if unsuccessful, an automatic rollback to the previous version is triggered.
Delta Updates
Regardless of whether A/B or asymmetric strategies are used, it is possible to limit the amount of transmitted data via delta updates (differential). Instead of transmitting complete system images, delta updates send only the binary differences between the current system image and the target image.
The update mechanism computes a differential patch on the server side by comparing source and target images at the block level, then packages these changes into a compact delta bundle. On the device side, the update client applies this patch to reconstruct the new system image from the existing installation. This approach provides multiple benefits:
70–90%
smaller than full image updates , faster deployment, better reliability over constrained network connections, and longer eMMC lifetime through fewer write operations.
Security Architecture
OTA update systems represent a critical attack surface in embedded devices. A compromised update mechanism grants complete system control, making security fundamental to any reliable update infrastructure.
Cryptographic Verification
- Image Signing: Every update package must be cryptographically signed using asymmetric algorithms (RSA-2048/4096 or ECDSA). The update infrastructure maintains private keys in hardware security modules (HSMs), while devices verify signatures using public keys anchored in immutable storage or hardware-protected storage (ROM, eFuses, TPM).
- Chain of Trust: Security propagates from the SoC through each boot stage. The ROM bootloader validates the secondary bootloader, which validates the kernel, which validates the root filesystem. This unbroken chain ensures compromised components cannot persist across reboots.
Secure Communication
Update communication requires mutual authentication using TLS 1.3. Servers authenticate devices through client certificates stored in secure elements (TPM, OP-TEE). Devices authenticate servers through certificate pinning, preventing man-in-the-middle attacks.
Rollback Protection
- Anti-Rollback: Hardware-backed monotonic counters prevent downgrade attacks. Counters increment with each verified update, and the bootloader refuses to execute firmware below the stored minimum version using ARM TrustZone secure storage, TPM NV counters, or SoC OTP fuses.
- Replay Protection: Update packages include cryptographically-signed timestamps and nonces to prevent replay attacks.
Key Management
Long-term deployments require hierarchical key structures where root keys validate intermediate certificates, intermediate keys (rotated regularly) sign update packages, and per-device keys enable individual revocation.
Learn more about embedded security solutions or the pre-integrated IGLOS platform.
Updates in Product Lifecycle
Industrial embedded devices operate for 10-15 years or longer, requiring update strategies that adapt throughout the product lifetime.
Deployment Strategies
Phased Rollouts
Update Classification
Classify updates by risk level (critical security patches, feature enhancements, or bug fixes) to determine appropriate deployment velocity. Critical security updates require accelerated out-of-band deployment, while feature updates follow scheduled maintenance windows.
Rollback Procedures
Every update must include automatic rollback capabilities. Define rollback triggers including boot failures, health check failures, and watchdog timeouts. The inactive partition maintains the previous version until successful validation confirms update stability.
Long-Term Support
Long-Term Maintenance
Embedded Linux systems deployed in industrial environments require support for 10-15 years or longer. This demands maintaining kernel versions, drivers, and userspace components.
End-of-Life Management
Define clear end-of-support policies. Devices reaching end-of-life may receive final security-only updates or transition to locked-down configurations preventing further modifications.
Monitoring and Validation
Fleet Analytics
Collected data from deployed devices provides visibility into update success rates, failure patterns, and version distribution. Post-update monitoring tracks boot success rates, application health checks, and performance benchmarks. Automated systems detect anomalies and trigger rollbacks.
Build your Update Solution
Linutronix supports customers across all stages of OTA update development:
Architecture design
A/B and asymmetric update system design for your hardware platform.
Build system integration
ELBE or Yocto integration for reproducible update packages.
Security implementation
Cryptographic verification, secure boot integration, and compliance with IEC 62443 and CRA requirements.
Delta update optimization
Bandwidth-efficient differential update systems.