How is the advent of the IoT impacting both RTOS development and developing with an RTOS?

CAPLES: Certainly, the landscape of RTOS is changing. In the ‘90s it was all about networking – slapping a TCP/IP stack on every device possible, and it was very exciting when you saw the first Ethernet controllers built into the 68332 microcontrollers (MCUs) way back then. Now it’s all about connectivity, whether it’s 802.11, Bluetooth, Bluetooth Low Energy (BLE) – any way to connect devices.

You’re now starting to see the introduction of platforms specifically geared towards IoT – mbed, Zephyr, etc. They offer a lot of connectivity and IoT protocols, and that’s what’s needed essentially when it comes to device design. It’s all about connectivity today.

This changes the philosophy of the developer, for sure. There’s less of an emphasis on doing RTOS development. It’s all about the platform and the ease of use. When it comes to hardening the platform, customers are expecting the platform to already be hardened and the connectivity to already be there. They’re expecting out-of-the-box solutions that will work on their platforms of choice and have the IoT connectivity selections that they need. Essentially, the developer is looking to focus on their use case. The assumption is that the RTOS and the connectivity just work.

DASTOOR: One of the key changes that we see from an RTOS perspective is that RTOS initially were single-function devices. You’d program them to do one thing and then they would do that thing extremely well in a very deterministic fashion. Then, they became more sophisticated, so they could do several things – again, in a very deterministic fashion.

Now that same RTOS is also supposed to do all kinds of communications, and with communication also comes the headache of managing communication, storing, logging, and the like – and all of these need not be deterministic, but the overall device should be fairly deterministic. This is really showing up in the industrial/medical world, and creating interesting paradigms because you have very controlled real-time determinism on the operational side so that if you have a machine doing something with a patient, for example, it retains its safety, its security, and all of that. At the same time you also want to extract data from the device and put it in the cloud.

Technology has evolved to address some of these challenges, but as an RTOS developer you have to keep these issues in mind because when you’re designing a device you’re constantly thinking, “How will I communicate with the outside world in a secure fashion?” If you have to add five layers of software encryption, the CPU may not have enough horsepower to run your application, so you have to opt for a device that has encryption built in or something that helps you protect your device.

LAMIE: As device vendors open up their APIs to share data and enable greater interoperability with other products on the IoT and single-point devices and systems, information security and protection become significant issues. Architectures like ARMv8-M enable a commercial-grade RTOS to assign partition boundaries to multiple code regions, enabling non-trusted code to be “confined” to those regions and thereby prevented from accessing trusted regions or the RTOS itself. Like the earlier Cortex-M MPU solution, ARMv8-M provides a remote access capability, enabling “managed code” to request services from the RTOS while disabling the code from accessing trusted regions. With ARMv8-M, this approach and mechanism is fully implemented in hardware, offering high efficiency and easy setup.

How do you see RTOS being used in lieu of, in conjunction with, or not at all given other choices available to IoT developers, such as general-purpose OSs, open source options, or bare metal development?

CAPLES: It’s all about the requirements of the system. Based on the requirements, bare metal might be completely satisfactory for the design. In other situations, something like a FreeRTOS may be well suited – based on the limited functions and features that it brings, it still may be enough to meet the system requirements.

Certainly an RTOS, by definition, “a real-time operating system,” is going to continue to have a significant role. You do see GPOS out there that provide a lot of connectivity and find their way into embedded systems, but those systems they find their way into do not have real-time requirements. They may lack other types of requirements where an RTOS is very well suited (Figure 1).

[Figure 1 | Mentor Graphics’ Nucleus RTOS recently added support for the EtherCAT Master protocol for hard real-time performance in industrial automation devices.]

When it comes to devices that are more feature rich or have requirements such as the utilization of space-domain partitioning, power management, connectivity, dual networking stacks, file systems, execute in place (XiP), security, and so forth, these historically become more problematic or challenging for some of the free RTOSs out there to be able to introduce. These systems truly require not only the feature set of a commercial offering, but also the expertise of the people that support it in order to be able to deploy the features in a meaningful way to meet the system requirements of the project.

Especially on the end nodes, sensors, and actuators, we do see real-time requirements with low latency, fast interrupt context switching, small footprints, fast boot-up times, and maybe even features like XiP where there are limited system resources. These are features that are better suited for an RTOS than a GPOS or even bare metal.

LAMIE: Development with a commercial RTOS versus in-house, bare-metal development can be beneficial in several ways. First, an RTOS is easier to develop with and maintain, as threads (tasks) can be developed to handle smaller sets of functionality, spread out over a team. Second, it is easier to add middleware with a commercial RTOS as a product becomes more connected or complex due to increased functionality. Third, a commercial RTOS is more portable because it eliminates the need for processor-specific code that otherwise would have to be part of the application. Fourth, most commercial RTOSs provide widely available technical support.

An RTOS provides developers the flexibility to add new features to a given device, as the RTOS manages the processor allocation logic such that real-time performance of a high-priority thread can easily be guaranteed, regardless of whether the firmware is 32 kB or 1 MB in size and regardless of the number of threads in the application. This alone makes it easier to maintain the application and easier to add new features to a device. In addition, most commercial RTOS offerings have an extensive set of middleware that is pre-integrated and ready to be deployed. This enables developers to easily add networking, file systems, USB, and graphical user interfaces (GUIs). A commercial RTOS should have a small footprint, something in the area of 2 kB of instruction area memory (usually flash) and 1 kB of RAM, which means there is more memory available for supporting connectivity and GUI needs.

Applications that use an RTOS are more portable because service functions are accessed through an application programming interface (API). The API makes the RTOS platform-independent, meaning that it’s the same regardless of the processor it runs on. This makes switching processors easier since none of the application’s service references need to be changed. The application will run anywhere the RTOS can run, and with most popular commercial and open-source RTOSs, that means virtually any 32-bit processor architecture. This gives developers application portability with only minimal changes to their code.

Responsiveness is another area where an RTOS works well for IoT devices. This is because an RTOS invisibly handles allocation of the processor to the threads that perform the various duties of the embedded device. With the proper assignment of thread priorities, application software does not have to concern itself with the processing time required for each thread. Even better, changes in the processing responsibilities of a given thread do not impact the processor allocation (or responsiveness) of higher priority threads. The key is to ensure that your RTOS is priority-based and supports fully deterministic processing.

Safety and security are vital concerns for IoT device developers, and there, too, an RTOS can make a difference. Many safety-critical systems, such as those found in medical devices and automobiles, require certification by responsible government or other regulatory authorities (Figure 2). This generally requires that the system developer qualify their scheduling code or provide artifacts for all of the software in the system. But many commercial RTOSs are pre-certified, which frees developers using them from having to do this. This can save time and costs.

[Figure 2 | Express Logic’s NetX Duo RTOS has been certified by SGS-TUV Saar for use in safety-critical systems according to the highest safety integrity levels (SILs) of the IEC 61508, IEC 62304, ISO 26262, and EN 50128.]

In addition, a commercial RTOS is more likely to be widely used, thus “field proven,” with fewer bugs likely to “pop up.” Commercial RTOS vendors can invest in improvements of the RTOS in an organized and customer-focused fashion.

DASTOOR: As far as RTOS being used alongside a GPOS, we absolutely see the two being used in together, and there are two ways this would happen. One is that, with multicore, you have more cores at the same price point than you can put to use. There are many devices today that have four cores, but only one core is used. With multicore, it opens up this possibility that, on the same processor, I can run two heterogeneous applications or heterogeneous OSs doing two different things altogether (Figure 3). That’s one classic case of virtualization where you are running VMs, and one example where that is popping up is in gateways.

[Figure 3 | The ubiquity of multicore processors, paired with virtualization technology, enables multiple heterogeneous OSs to be deployed in the same system, with gateways being a prime example. Shown here are heterogeneous OSs containerized using Wind River’s Virtualization Profile for the VxWorks RTOS.]

Gateways are a classic device where you want to protect something that is either deterministic or real time on the operational technology side of it. On the other side, you’re connecting to the cloud, which is the IT domain. With the IT domain, of course you are looking at more security, bandwidth, cost of transportation, etc., so a hard separation comes along when trying to put two heterogeneous OSs or two heterogeneous use cases on the same box.

The other concept that comes up is extensibility of devices, which means that you install a device today but you don’t know what you’ll want to do with this device two years from now because technology changes so fast. So containerization is another big trend that we see in the IoT. We know the advantages of containerization – isolation, it provides you a nice sandbox to write applications, etc. – but we see that, more importantly, looking to the future if I want to do something with the device, I can do it. I can update the whole firmware. Therefore, you would rather have a framework in your device that allows you to deploy applications remotely and run them. Containerization also allows you now to separate soft real-time from hard real-time from no real-time requirements, and still have the applications mish-mashed together in the same system.

Given the microkernel architecture that many RTOSs employ, as well as the need for portability and scale in IoT devices, is it recommended to begin development with an RTOS so there is headroom for the future?

CAPLES: RTOSs today bring a lot of connectivity capability and IoT protocol support, whether it’s CoAP or MQTT or XMPP. Those IoT protocols are routinely supported by leading RTOSs, and much of this stuff is functional in resource-constrained devices that you would find in MCUs. It includes even the crypto you would expect to see, like OpenSSL equivalents from wolfSSL that integrate with our Nucleus RTOS in a small-footprint manner so it can be utilized on memory-constrained devices.

But just because it’s on memory-constrained devices doesn’t mean these platforms can’t transcend up the food chain into Cortex-A devices. What you’re finding on the higher end is the multicore, heterogeneous cores, and heterogeneous OSs, and if you already have that type of capability built into a small MCU, many of today’s heterogeneous system on chips (SoCs) already include a Cortex-M-type core that perhaps you use as the communications core sitting next to the applications processor. Certainly that’s going to give great advantage to the RTOS.

DASTOOR: The decision is what to start with. Should you start with an RTOS and then extend or do you start with a GPOS and run an RTOS as a virtual machine (VM) within that GPOS? Both have their place.

One very interesting thing now is that, as you containerize, you’re almost creating a fragment of functionality that is running on the device. Now, what prevents you from running that fragment of the device somewhere else or in another server? Maybe still in the same geographic location, but on another system?

This is where the concept of software-defined automation or the software-defined factory starts bubbling up. As a good example, if you have a programmable logic controller (PLC) controlling a machine, it also does intelligent analytics of whatever it is trying to control. If you start containerizing the analytics portion of it, you can run it on a server in the data center. Then, once you virtualize something, you are into the familiar world of IT virtualization. So software-defined everything (SDX) is showing up in many places.

What else do you see happening in the world of RTOS in the next 5-10 years?

DASTOOR: The “things” that we talk about today – we call them devices – those things will have feelings like humans have feelings, which means the things will have a need to be identified. You put them in a factory and when they power up they should immediately figure out, “Where am I? Who do I belong to? What language should I speak? And who do I trust in this world?” Also, once you have that identification and connectivity, the next element of feeling is, “Can I learn something on my own?” Machine learning becomes a big thing for those devices; self-healing becomes another big thing for those devices.

It’s a very complex problem to solve because you may have 1 billion devices waking up one day needing to be identified and find their place in the world. Those kinds of features will become very fundamental to the OS or the RTOS itself.

LAMIE: A study published in Business Insider tells us there will be 25 billion IoT devices shipping by the year 2019. Because such devices will require network connectivity (for example, Wi-Fi, BLE, ZigBee, Ethernet, etc.) and will often include a GUI, they also will require 32-bit microprocessors to provide the necessary address space and processing power. We are already seeing strong migration from 8- and 16-bit microprocessors due to enhanced functionality, as well as the cost versus performance attributes of new 32-bit microprocessors.

The predicted IoT explosion promises to sharply accelerate this migration. Moreover, the increased connectivity requirements alone necessitate the execution of communication protocol stacks on 32-bit embedded microprocessors. That, in turn, necessitates the use of an RTOS. GUI design and runtime software from third parties typically rely on RTOS services as well. All this makes it increasingly likely that IoT device developers will consider using an RTOS.

Express Logic

www.rtos.com

LinkedIn: www.linkedin.com/company/express-logic

Mentor Graphics

www.mentor.com/embedded-software

@MentorEmbedded

LinkedIn: www.linkedin.com/company/mentor-embedded

Wind River, an Intel Company

www.windriver.com

@WindRiver

LinkedIn: www.linkedin.com/company/wind-river