Custom system integration
Embedded Redesign
Board Support Package for System Houses
Updatability is more than just transferring a file
OTA updates describe how an update is delivered to the device. Update capability describes what must happen on the device afterward: transfer the update, verify the package, install it in a controlled manner, start it up safely, and maintain a functional state in the event of errors.
OTA updates aren't the only way to update
“Over the Air” refers to the delivery of a software update via an existing network connection - for example, Wi-Fi, Bluetooth, via satellite or an already integrated cellular connection. Whether this method is possible depends on the deployment location, the network connection, and the operating concept (security requirements).
The underlying update architecture remains relevant even for local service channels. An update via Ethernet, an USB drive, SD card, or service interface must also be verified, installed under controlled conditions, and recoverable in the event of errors.
Wireless ConnectionsOTA Update via Existing Network Connections
Isolated systems or temporarily not connected systemsLocal Update via Service Route
New or existing product platformsPlan for upgradeability from the start or retrofit as needed
Deploy Update
Deploy approved software for the appropriate target platform - via OTA or a local service channel.
Package Received in Full
Only update packages that have been fully transferred may be processed further.
Verify Origin and Integrity
Confirm the signature and verification information: The package is authorized and has not been altered.
Install and Save Update
Write the new software to the designated system area or slot.
Enable with Caution
After successful installation, the device will start up using the new version.
Confirm startup or roll back
The version is confirmed only after a successful startup. Otherwise, a functional older state remains active or is activated.
Upgradability is a chain of technical decisions
A robust solution does not result from a single component. The key is the coordination between update content, installation logic, storage allocation, and the boot process.
It contains the software components required for a new version - depending on the target architecture, these may include the system image, kernel, device tree, application, configuration, or customized embedded drivers. Version information, compatibility details, and signatures make the package verifiable.
The framework checks and installs the bundle according to defined rules. For embedded Linux, we have, among other things, in-depth expertise in the RAUC environment.
An A/B system provides two separate areas for system states. While one area is in active use, the other can be programmed with a new version. Whether this approach is appropriate depends, among other things, on available storage, flash technology, and recoverability requirements.
The bootloader - such as U-Boot - is part of the controlled boot path. Depending on the architecture, it can control the boot of a new version and enable a rollback to a verified software version.
Before widespread distribution, the version, target hardware, release status, and fallback behavior must be clearly defined. The technology can only be managed effectively if the process is appropriate for it.
If the update process is interrupted
Robust update capability is not judged by ideal-case scenarios, but by how the system behaves during failures. Select a typical failure scenario and see what task the update architecture must handle.
Do not install incomplete packages
If the network connection is lost during the download, the incomplete update must not be activated. The device retains its previous, confirmed software version and can download the package again later or receive it via a local service channel.
Is your device prepared for a fault-tolerant update process?
Whether an A/B system, a different slot concept, or a defined recovery path is appropriate depends on the target hardware, memory layout, bootloader, and operating model. We assess the technical requirements of your embedded system and outline possible implementation steps.
Signed Updates and Secure Boot
An update package must not only be complete; the device must also be able to verify that it comes from an authorized source. Signatures and integrity checks therefore protect the update process from unwanted or tampered software versions and are part of a comprehensive embedded security strategy.
Signed Update Bundles
Before installation, the system checks whether an update package is complete, unchanged, and released by an authorized source. This ensures that no corrupted or unintended software versions enter the update process.
Secure Boot
Secure Boot verifies the chain of trust for the software components during startup. This ensures that only authorized components are launched along the intended boot path. The package verification performed before the update and Secure Boot during system startup complement each other in this process.
Integration Support
We provide support for integrating security-related platform features into the respective embedded system architecture. These include, among other things, Secure Boot, signed update bundles, and cryptography-related mechanisms - tailored to the target hardware, boot process, and update strategy.
RAUC - A Framework for Robust Updates
RAUC is an open-source framework for the device-side installation of signed software updates on embedded Linux systems. It supports update bundles and can be integrated into various storage, slot, and boot configurations.
RAUC deliberately distinguishes between the transfer of an update bundle and its processing on the target device. The framework can verify a bundle that is available locally or delivered via a network connection and install it according to the configured slot architecture. The actual OTA transfer and any management infrastructure are separate components.
Among other things, SIGMA possesses in-depth technical expertise in the field of RAUC.
For new embedded systems
The ability to update should be taken into account as early as the platform architecture phase. Key factors include memory reserves, the structure of system areas, startup and boot mechanisms, software packages, key management, and the planned operating model.
The specific implementation depends on the operating system and target platform. For Linux-based systems, for example, a suitable update framework, slot concepts, and bootloader integration can be part of the architecture.
For existing devices
For existing devices, we check the current software version, the operating system in use, the memory layout, boot and startup behavior, available interfaces, and recovery requirements. This applies to Linux-based platforms as well as to existing Windows Embedded or WinCE/WEC systems.
Not every existing device can be retrofitted to the same extent. A reliable assessment can only be made after analyzing the specific platform.
Is your embedded device already designed to be updatable?
Review the key fundamentals of a robust update architecture. While this checklist is not a substitute for a technical analysis, it quickly highlights areas that require clarification before the start of series production or widespread distribution.
Select the points that have already been clarified for your system.
Assess update capability For an initial assessment, information about the target hardware, operating system, bootloader, memory layout and intended update path is helpful.Classifying the Upgrade Capability of Your Embedded System from a Technical Perspective
Whether you’re planning a new product platform or want to make an existing device capable of controlled updates: We’ll assess the technical requirements of your target architecture.
Together, we’ll determine:
- Which software components should be updated
- How update packages will reach the device
- Which storage and slot configuration is appropriate
- How the boot process, confirmation, and fallback can be designed
- What role RAUC, U-Boot, signatures, and Secure Boot play
Update capability encompasses the entire architecture of a system. This means hardware decission, package verification, installation, activation, boot process, error handling, and recovery.
No. Whether OTA is a good option depends on the network connection, the number and distribution of devices, and the maintenance strategy. Even without a remote connection, signed, verified updates installed via USB, SD card, or a service interface can be a viable option.
An A/B system uses two separate areas for software versions. The active system remains unchanged at first, while the update is written to the inactive area. The new version is confirmed only after it has been successfully tested and launched in a controlled manner. This ensures that a previously functioning version remains available in case of problems.
That depends on the update architecture. A robust solution is designed so that an incomplete installation process does not result in the only bootable system state. The previously validated system remains available, or there is a defined recovery path.
RAUC processes update bundles on the embedded Linux device: It checks and installs them according to the configured architecture. The transfer of the bundle over a network and any central management infrastructure are separate components.
Signatures verify, prior to installation, whether an update package is authorized and unaltered. Secure Boot verifies the chain of trust for software components during startup. Both mechanisms serve different purposes and complement each other.
OTA updates refer to the transmission of an update to a device via a wireless connection. The local delivery method involves wired update transmission, such as via LAN, USB, or SD card.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
