Updates

Updates for IoT devices are a complicated affair. In practice, they can only occur "over the air" (OTA; i.e., in a way that does not entail the provider having physical access to the device after delivery). The distribution model for updates accordingly provides that they be made available on central servers so that clients can download them autonomously. In practice, of course, this also means that an IoT device needs access to the Internet at its location, which is not a problem in most cases. Most providers integrate their IoT devices into existing WiFi networks that have a connection to the Internet. The provider of the respective software has to take care of the rest.

Foundries.io is up to pace here, too. Every part of the operating system – from the bootloader to the kernel to userspace – can easily be updated remotely according to defined standards. From a security point of view, this is a smart implementation. If you implement IoT devices with Foundries.io, you can, for example, specify that updates always need a digital signature for the target devices to import them. In this way, a provider can prevent attackers from hijacking its devices by loading a hacked firmware update. For userspace updates, Foundries.io relies on libostree (previously OSTree) to update individual parts right down to individual files, ensuring that updates can be installed regularly and incrementally instead of in the form of major release cycles.

Beyond IoT

The examples used in this article so far refer to devices from the IoT world, which are more likely to be found in a domestic environment. However, IoT now also plays a major role in industry, and many functions for this purpose can also be found in the Foundries stack. If you want to roll out IoT devices as edge applications in the enterprise, for example, you might need an option to execute commands directly from a safe distance. The developers have implemented this scenario by including the WireGuard virtual private network (VPN) client. If configured appropriately, systems with the Foundries stack open a VPN connection to their home address and are then open to receiving instructions.

The native cloud connectors for the major hyperscalers that come with the product are also aimed at business customers. For example, services and instances on AWS or Azure can be started or manipulated from the system without you having to implement the interface to these cloud environments yourself. Again, Foundries.io saves you considerable overhead by including a ready-made solution for a standard task.

The same applies to support for the protocols typically found in the IoT environment, which is included by default. For example, if the device has a chip with Zigbee support (Zigbee being the protocol for controlling smart lighting), Foundries.io provides an interface for it in the system. The same applies to the Open Mobile Alliance Lightweight Machine-to-Machine (OMA LwM2M) protocol, which specifies several standard communication methods between IoT devices, such as message queuing telemetry transport (MQTT) over HTTP. The following basically applies: Once a protocol has established itself as a standard in the IoT environment, the chances are good that the Foundries stack will support it.

Enter Docker

The Foundries stack comes with Docker as the runtime engine for containers, and third-party vendors are advised to integrate their specific customizations into the Foundries framework in the form of Docker containers for several reasons. Like the rest of the system, Docker containers in the Foundries stack can be upgraded to new versions with OTA updates. Therefore, vendors can effectively eliminate errors in IoT devices – even in the vendor-specific software components. Moreover, companies benefit from clear demarcation between the operating system on the one hand and their own applications on the other. Decoupling is also useful from a development point of view, as well as in everyday operation, because it enables far more granular work than monolithic firmware.