Future-proofing embedded system designs: firmware and hardware upgrade strategies

Building for tomorrow: why upgradeability matters

The extraordinary raw compute performance provided by the processors at the heart of today’s embedded systems has altered the balance of the value provided by hardware and software. Some 20 years ago, the main source of value in an embedded product was its hardware.

Today, the hardware is capable of supporting much more complex, and valuable, software applications. The introduction of neural processing units (NPUs) and other forms of AI hardware acceleration in microcontrollers and application processors means that AI software is an additional contributor to the value of the user experience of embedded systems.

A feature of software is that it can be repeatedly and remotely upgraded, normally through the installation of over-the-air (OTA) update packages. Where appropriate, updates can also be installed via a wired network.

The continual ability to upgrade software has added a new dimension to the competition between rival embedded device manufacturers: customers evaluate the performance and specifications of competing products not only at their initial installation, but also demand that the product’s performance and feature set should improve over the lifetime of the device. This demand is particularly pressing in embedded computing products that have long life cycles, typical of systems in use in the industrial, automotive, or medical sectors.

Multiple reasons for embedded system updates

The main reasons for embedded device manufacturers to provide updates are:

• To fix security vulnerabilities through a software patch. The requirement to monitor common vulnerabilities and exposures (CVE) notices, and to correct any known security problems, is a new legal provision of the European Union’s Cybersecurity Resilience Act (CRA), which applies to electronics products sold or manufactured in Europe. Because of the global importance of the European market, the ability to implement security update patches is set to become a standard feature of embedded systems.
• To provide feature extensions and improvements, adding value to the product. This capability is becoming particularly important in AI-enabled embedded systems, because of the continually improving performance and capabilities of AI software such as large language models (LLMs).
• To fix bugs which are discovered after the product is shipped.

So firmware upgradeability gives developers a new way to augment the lifetime value of the products they design, avoiding the need to declare an outdated or insecure product obsolete.

This new ability to extend the lifetime of embedded devices means that customers can benefit from continually improved features and security protection without the need to repeatedly decommission and dispose of outdated hardware, and replace it with all-new hardware.

This reduces the cost to the customer of using the latest technology, and helps to reduce the amount of electronic waste delivered to landfill sites, as future-proof embedded design makes products less disposable.

Firmware upgrade paths in embedded systems

The techniques for delivering firmware upgrades to embedded systems enable manufacturers to scale the update process over thousands or millions of installed units, while providing robust mechanisms to recover from update failures or faults.

Enabling secure OTA firmware updates

OTA firmware updates are the most convenient and scalable way to deliver updates, provided that the target device has a secure means to connect wirelessly to the internet or other network accessible to the update provider.

An essential enabler of OTA updating is a bootloader: this creates a secure, isolated environment separate from the main application firmware, enabling reliable over-the-air updates without requiring physical access to devices.

The bootloader validates the integrity of firmware through cryptographic signatures and checksums, preventing corruption of the firmware image, or installation of malicious code. It also manages memory partitioning, allowing fallback to previous versions of the firmware if an update fails. This is important to eliminate the risk of an update bricking or otherwise disabling individual units in the field, or even an entire fleet of devices.  

A bootloader enables centralized deployment of security patches, feature updates, and bug fixes across thousands of devices simultaneously, dramatically reducing maintenance costs.

In limited circumstances, it might be preferable or necessary to deliver updates via a hard-wired JTAG or USB interface than over-the-air. For instance:

• When devices are bricked or bootloaders are corrupted, a JTAG interface provides low-level access which bypasses failed software
• Security-critical air-gapped systems or those requiring strict change control often mandate physical access to eliminate the risk of remote cyber-attack. Likewise, auditing of regulatory compliance might require a physical presence during firmware modifications

These interfaces provide guaranteed connectivity independent of network infrastructure or application-layer failures.

Architecture of the firmware update package

Separate from the decision over which method to use to deliver an update package, embedded device developers also need to arrange the structure of the package. The question is broadly whether to structure the package as one all-inclusive unit (monolithic), or to split it into bite-sized chunks (modular).

The monolithic architecture makes for a simpler OTA implementation: the entire firmware is replaced as one unit, ensuring consistency and making it easier to roll back the update in the event of a problem. Update validation is straightforward, and there are fewer potential failure points during the update process.

A modular architecture enables selective updates of individual components, reducing the requirement for network bandwidth, and shortening the duration of the update procedure. In addition, important modules can remain untouched while updating peripheral functions, minimizing system downtime.

The modular approach, however, is more complex because of the impact on:

• Dependency management
• Version compatibility
• The handling of partial update failures

The developer’s choice depends mostly on system constraints.

A monolithic architecture suits resource-constrained devices, which call for simplicity and reliability.

A modular architecture is best for complex systems that require frequent updates to specific sub-systems without affecting core functionality.

Constraints and trade-offs in designing embedded products for remote upgrading

This article has explained above the strong reasons for embedded systems manufacturers to build firmware upgradeability into their products. It is important to acknowledge, however, that provision for upgrading firmware does not come without a cost: there are trade-offs.

In general terms, support for remote upgrading requires additional hardware resources and/or higher specifications for components which would have been integrated anyway. This could have a noticeable effect on the product’s size, weight, bill-of-materials cost, and power consumption.

For instance, the embedded device’s code storage capacity might need to be doubled to allow for the older version of firmware to be retained while a new version is uploaded. The OEM might also need to implement a technique for storage headroom planning, such as Flash memory partitioning, to enable firmware versions to be securely quarantined from one another.

Additional security and validation measures

In addition, security has to take center stage when designing for firmware upgradeability. This is because the update procedure – although often deployed to install a security patch which protects against a known vulnerability – is itself a potential vector for cyber-attacks. For instance, an attacker might seek to use an update event as a means to load a corrupt version of firmware on to the device, either to disable it, or with a view to exploiting a vulnerability that the attacker has inserted into the firmware.

Securing the update process calls for a complex chain of security functions, stretching from a root of trust on-device, secure boot to ensure that the device only runs authentic firmware, through secured communication links, to encrypted processes for signing and authenticating the update package.

This imposes a requirement for minimum hardware capabilities in the device, including the hardware basis for the root of trust, such as a hardware security module (HSM) or trusted platform module (TPM), secure memory, and the ability to isolate security-critical processes in a trusted execution environment.

All of these requirements impose extra bill-of-materials cost above that which a non-connected device would incur, as well as giving rise to substantial extra development time and cost for implementing security software and processes.

As well as the impact on its hardware design, the device manufacturer also needs to take account of the effect on the device user. While a remote update capability might be a common part of manufacturers’ response to the requirements of the CRA, the ability to remotely install new software on a device without the user’s consent can be controversial in the minds of some consumers.

In certain use cases, the manufacturer will need to design the update procedure carefully to allow for the user’s involvement or consent.

Lifecycle management and version control

Hardware and software design can provide for the delivery and deployment of update packages as one-off events. But a future-proof embedded design needs to allow for a series of updates to be installed over the lifetime of an embedded computing or IoT product, and to large fleets of devices. This calls for robust strategies for tracking the versions of firmware and hardware deployed in any given unit.

Versioning is important to maintain the integrity of updates in remotely upgradeable devices. It enables the manufacturer to check the compatibility of a proposed update deployment,preventing incompatible firmware from being installed on certain hardware versions.

Dependency tracking ensures all required components are present and compatible. Versioning combines with rollback capability to allow the system to revert to known-good versions when an update fails or introduces problems.

Versioning also supports fleet management by enabling targeted deployments to specific device populations, backed by measurement of the rate of success of update installations.

A continually updated software bill-of-materials (SBOM), maintained individually for every production unit, is an effective method for ensuring version control of devices in the field. It is particularly useful for vulnerabilities and exposures analysis, allowing the manufacturer to precisely identify the units running versions of firmware that are at risk from known threats. It also supports auditing of a manufacturer’s compliance with regulations such as the EU’s CRA.

Practical guidelines for update roll-outs

Semantic versioning helps with fleet management by providing clear categories for different firmware updates: major versions for breaking changes, minor for backward-compatible features, and patches for bug fixes.

In addition, it is prudent to implement applications programming interface (API) versioning in communication protocols, allowing devices to negotiate supported versions with cloud services. Developers should maintain deprecated API support for at least one major version cycle, providing migration warnings to backend systems.

Feature flags and capability negotiation provide a means to enable/disable functionality based on the capabilities of the device and its server. Manufacturers have also learned to avoid delivering an update package to every device in a fleet simultaneously: staged rollouts allow them to test compatibility across multiple generations of a device before beginning full deployment.

Developers will also do well to document migration paths clearly, providing timeline warnings for API deprecation. This approach minimizes service disruption while enabling evolutionary improvements across heterogeneous device fleets.

Future trends: smarter updates and industry standards

The embedded computing industry has in recent times embraced the need for regular and fleet-wide remote firmware upgrades, introducing innovations which make the process easier and more secure.

These include:

Containerized firmware updates – a container provides an isolated execution environment which prevents update processes from interfering with running applications. By isolating an update package inside a container, the developer can ensure consistent dependency management across different device configurations, simplify rollback, and enable atomic updates: either the entire container deploys successfully or it fails cleanly. This reduces the potential of an update to corrupt an entire system, and so improves reliability.

RTOS with integrated update manager – a real-time operating system (RTOS) provides a stable, predictable foundation which substantially improves the reliability of update processes compared to bare-metal implementations. The RTOS provides for isolation of task scheduling to ensure update processes receive guaranteed CPU time without interference from application tasks. Memory management prevents memory fragmentation and ensures sufficient resources are available during updates. Real-time prioritization maintains critical system functions while updates occur in the background. Built-in synchronization primitives co-ordinate between the update manager and running applications, enabling graceful shutdowns and state preservation. Interrupt handling maintains system responsiveness during lengthy update operations. Watchdog integration prevents update hangs from bricking devices.

Edge AI bootloaders provide for intelligent failure prediction, and determine the timing for implementing an update. An AI bootloader also provides adaptive rollback decisions based on post-update performance analysis, anomaly detection to identify corrupted downloads before installation, and predictive scheduling to avoid updates occurring during critical operations or when the device is in a low-power state.

Reducing hardware dependency

Other trends in the technology of embedded computing are not being introduced with the purpose of making OTA updating easier, but nevertheless have this effect as a by-product.

A hardware abstraction layers (HAL) decouples firmware from hardware, enabling the same update package to work across different hardware revisions. This means that it provides a standard interface which remains consistent even when underlying drivers change. This allows developers to isolate hardware-dependent code in targeted updates, and to simplify validation by reducing hardware-specific testing requirements across device variants.

In addition, software-defined peripherals enable runtime reconfiguration of hardware functionality through firmware updates, allowing devices to gain new capabilities or optimize performance without hardware changes.

The industry is also collaborating widely to help manufacturers generally to implement OTA updates more easily and effectively. The implementation of standards is a crucial element of this industry effort. Relevant standards for OTA update managers include:

SUIT (Software Updates for Internet of Things) – provides standard manifest formats for secure, interoperable firmware delivery across vendors.

LwM2M (Lightweight M2M) – offers device management protocols including standard firmware update procedures over CoAP.

FIDO Device Onboard – enables secure device provisioning and trust establishment for authentication of update packages

OMA-DM – delivers enterprise-grade device management with update orchestration.

CBOR/COSE standards – ensure compact, secure packaging and signing of update packages.

RFC 9019 (Firmware Updates for Constrained IoT) – defines best practices for resource-limited devices.

Conclusion: designing for change

As if firmware upgradeability was not important enough in the protection of embedded and IoT device manufacturers’ reputations and financial well-being, it is now also required for compliance with new regulations applied in Europe and elsewhere. This article has outlined the key considerations when planning to build firmware upgradeability into new device designs.

Techniques to consider include the use of modularity, planning in advance for the extra memory capacity required by update procedures, and the security architecture required to protect update code and the required network communication from the threat of cyber-attack.

At a higher level, experience across the industry suggests that it is prudent to plan for the implementation of OTA updates from the beginning of a new product development. Decisions taken early about hardware architectures, and software deployment techniques such as containerization and continuous integration/continuous development (CI/CD), can have a profound effect later on if they are taken without consideration for the need to support OTA updating. The effects can include dramatically extending development time, delaying a product’s entry to market, and substantial extra cost in development and bill-of-materials caused by the difficulties of bolting on firmware updating capabilities to hardware unsuited to it.

Today, it is hard to imagine any connected embedded or IoT device that will not need to be remotely updated at some point in its lifecycle. It is best for the developer to make this assumption from the first day of work on the design of such a product. And when selecting hardware for any embedded computing device, developers can always turn to the ipXchange library of information about microcontrollers, application processors, AI hardware accelerators, memory and many other types of components which will help them to build firmware upgradeability into their next device design.