Over-the-air (OTA) programming is the means by which an IoT device can be updated after it’s out in the field through a wireless connection. This can be advantageous for a host of reasons, as it offers:
- • the ability to add new software features to a product after a device has been deployed in the field;
- • the opportunity to rapidly respond to bugs and security vulnerabilities without the need for physical device recalls or truck rolls;
- • assurances that embedded developers can quickly prototype and seamlessly roll out new firmware versions.
OTA updates are quite common now, and we often take it for granted that our phones, tablets, and computers will update automatically with security patches and new features as they become available. Some devices offer user control, while others attempt to take the user out of the equation completely. It sometimes feels like our devices want to update themselves at inconvenient times, but we’re starting to get used to it.
OTA Updates for Embedded Devices
Unlike consumer devices, which typically are not mission-critical, updates of embedded devices must be much more predictable and secure. However, they’re still able to take advantage of OTA or remote updates. A multitude of options and frameworks are available to handle OTA updates, so developers need to do their homework before adopting a methodology.
A determination must be made as to how critical the update is and whether the timing can be controlled (and by whom). For example, industrial control equipment can’t be updated while it’s performing an operation. And if the update results in the need for a service call, that can get expensive. Also, there must be assurances that power remains on for the duration of OTA. Finally, fail-safe methods must be put in place, such as if the new image doesn’t boot as expected.
A key consideration when determining how much security and risk are available when embedded systems allow remote or OTA updates is, what really needs to be updated in the field? Some devices may only require that the application(s) be updated as new features and/or updates are provided. This method is typically the least risky and easiest to recover, as the main operating system (OS) remains untouched.
In other cases, you may want to update the main OS. For example, Microsoft Windows 10 IoT Enterprise includes updates, unless the user has configured it otherwise. The impact of those updates is not always in your immediate control, so caution is suggested. Similarly, Linux distributions can have security updates that can either be enabled or disabled, depending on the application.
In other cases, an OS update might be desired, where you want to push out an entirely new root file system and OS image. In this instance, you’ll want to have a recovery rollback method available in case something goes astray.
Updating the boot firmware
Then there’s the update to the BIOS or other software that runs/configures the system before the OS is loaded. While it’s possible to update this code through an operating system like Windows 10 IoT Enterprise or Linux, it does come with potential risks that should be evaluated. In some cases, the BIOS, including the UEFI and UBOOT software, can be configured to update through remote access. However, the flash-memory provisioning must be considered here. Without proper security implementation with an established root of trust, these implementations can be a security concern. You may want to look into whether a TPM 2.0 or similar security implementation is available.
The baseboard management controller (BMC) is one method developers are employing to monitor and control the remote management and update process. This is common in servers and high-end systems, where implementation occurs at the Edge of the industrial IoT (IIoT). In this scenario, each layer incurs its own set of risks, rewards, and costs.
Numerous OTA and remote update platforms are available for your IIoT devices, and they should be selected not only based on their cloud framework, but on having the necessary services and frameworks needed for the embedded hardware, OS, and firmware that will be used. Some of the possibilities come from Mender.io, ThingWorx, AWS IoT Core, and Azure IoT Central.
WINSYSTEMS works with its clients to help them understand the hardware and firmware considerations when implementing remote updates. One platform that can operate in this manner is the ITX-P-C444 industrial single-board computer (SBC).
The ITX-P-C444 is based on the Pico-ITX form factor and is designed with NXP’s i.MX8M Arm-based applications processor. With dual Ethernet, industrial I/O, and other expansion options, the SBC suits IIoT applications requiring performance in harsh conditions such as digital signage, industrial automation, energy, and building automation.