This article is part of TechXchange: RTOS: Zephyr Project
Linux has become the de facto open-source operating system (OS), although there are niche alternatives like flavors of BSD (Berkeley Software Distribution). A variety of incarnations target minimal memory platforms such as Ubuntu Core/Snappy and Android Things.
Many commercial open-source solutions are available in this space, too, but they all require virtual memory-management-unit (MMU) hardware. Though such hardware can be found in a host of Internet of Thing (IoT) devices, many utilize microcontrollers that lack this support. These smaller devices require a more compact OS that utilizes a few kilobytes of RAM and around a dozen kilobytes of flash storage.
These days, most compact commercial real-time operating systems (RTOS) support IoT, either providing or partnering with cloud services to provide the internet component. There’s also a large group of open-source solutions available in this space. However, their support can vary, unlike the commercial alternatives that typically offer long-term support. All include networking protocol stacks, topped by IoT protocol support.
For example, a number of projects can be found on software repositories like Github including RIOT, TinyOS, and Mantis OS. Nano RK specifically targets the FireFly Sensor Networking Platform that includes the MicaZ motes.
Company Backing
Many others have a company that sponsors or supports the projects. Some are a mixed open-source/closed-source solution like Arm’s Mbed, which has proprietary components. Dual licensed solutions like Silicon Labs’ Micrium µC/OS are open source as well, but they require a commercial license to use the operating system in a product.
Other open-source solutions that have a company or organization behind them include Amazon FreeRTOS, Zephyr OS, Apache Mynewt, Thingsquare Contiki, and Huawei LiteOS. This means that the operating systems will have ongoing development. However, the amount of support that can be obtained will likely vary significantly. Some companies can provide support for these platforms, such as Intel’s Wind River Professional Services for Zephyr OS. The OS was originally based on Wind River’s RocketOS.
Most of these open-source platforms utilize more liberal BSD, MIT, or Apache licenses. These don’t require publishing source code, but they must include copyright notices within the source code utilized by the applications.
Targeting applications that require certifications like ISO 26262, IEC 61508, ISO 62304, SIL3/SIL4 IEC or even DO-178B can be problematic for some of these platforms. This is why a commercial RTOS is often the platform of choice, either that or an open-source platform where developers can get paid support. Such support would include long maintenance of software, bug fixes, and a place to turn to when problems arise.
Some companies opt for specific platforms in these scenarios. FreeRTOS-compatible alternatives from Wittenstein—SafeRTOS and OpenRTOS—were rebuilt from the same code base for compatability. SafeRTOS has been rewritten and meets the requirements of the IEC 61508 safety standard. OpenRTOS shares the FreeRTOS kernel code. Both have commercial licenses and come with a warranty.
Developers looking for an OS solution may also want to look at languages with built-in operating-system support. Programming languages like Java, Ada, and SPARK have multitasking and memory management built-in. They can usually take advantage of an operating system to provide these services, or developers can use runtimes that include this support.
The success of Linux is likely to be replicated with more compact, IoT-oriented OS solutions that have corporate sponsorship, such as Zephyr OS, FreeRTOS, Contiki, and LiteOS. They’re also a more likely choice for IoT cloud service providers. Supporting a wide range of platforms might be desirable for these providers, but that tends to be impractical. Targeting one or two is often more than sufficient to create a sustainable development community.
IoT developers should also keep security in mind. There are many facets to this issue, from secure communication using TLS protocol stacks to the initial boot process. Solutions like the Trusted Computing Group’s Device Identifier Composition Engine (DICE) offer one way to start with a secure base. DICE can be independent of the OS, but it makes more sense if that support is integrated and exposed to the applications running on the OS.
