Why does google think the Internet of Things demands an RTOS?

The embedded real-time operating system (RTOS) market is suddenly very popular, after years of being kind of obscure in the overall high-tech space. In recent months RTOS providers, who for many years have quietly helped embedded systems developers add multi-tasking capabilities to their products, have discovered that their competition may now include tech giants like ARM and even Google. By these companies' own accounts, the motivation behind their expansion into the RTOS field can be summed up with what has now become a ubiquitous three-letter acronym: IoT.    

Initially, the association between the Internet of Things and an RTOS might not be entirely apparent. We've all heard that the IoT will motivate the development of an obscene number of embedded systems, but the reliance of these systems on an RTOS is a topic that doesn't seem to attract much media attention. Clearly, the assumption of ARM, Google, and many other would-be embedded operating system providers is that most IoT products will be RTOS-based.    

Increasingly complex devices

Many of the factors that may lead to widespread adoption of RTOSes in the IoT also exist for conventional embedded systems, but are amplified by the demands being placed on the latest Internet enabled products. Complexity is a prime example of such a factor. At a high level an RTOS can be viewed as a means of managing complexity and it's relatively easy to imagine an existing embedded system becoming more complex as it evolves into an IoT device.

Although there is always a danger in making generalizations, there are certain characteristics that, by definition, are common to all IoT products. First and foremost, a device on the IoT must be a “thing,” which is a ridiculously generic term for an embedded system. Just like the countless embedded systems existing before the advent of the IoT, each “thing” maintains some type of interaction with the outside world. Thus, as Figure 1 indicates, a “thing” must use sensors, actuators, or maybe both.

Figure 1: An IoT device may have a number of very different components.

This requirement alone can motivate developers to seek the aid of a multi-tasking kernel, as the high rate of RTOS adoption in traditional embedded systems attests. However, the complexity of an IoT device goes beyond that required for sensors and actuators, because such a device must, of course, be connected to the Internet, either directly or indirectly. The device must have some mechanism for sending and receiving packets of data.

The software required for communication can vary widely across different classes of devices. Complete protocol stacks are necessary in some cases, while, in others, the presence of gateways and dedicated network hardware enables the use of little more than a serial driver. In all devices though, the need for communication adds some degree of complexity and, thus, creates additional incentive for using an RTOS.

Power concerns

Another factor that could drive RTOS adoption in the IoT is the widespread need for effective power management. The assumption of many Internet prognosticators seems to be that a substantial portion of devices on the IoT will be battery powered and will be expected to run for extended periods of time without any sort of user intervention. Here, again, an RTOS can prove highly beneficial.

In theory, the efficient use of power is easy to achieve with the latest MCUs, many of which offer numerous different low-power and sleep modes. In practice, though, questions quickly arise as to where, within application software responsible for managing a plethora of different peripheral devices, sleep mode enter and exit should take place. An RTOS can streamline such decisions by offering hooks for outfitting a system's scheduling infrastructure with code that initiates low-power operation. Furthermore, the most power-conscious RTOSs are implemented with capabilities, such as a dynamic tick rate, that minimize the CPU resources needed to provide a robust set of multi-tasking services.

The race against the clock 

While a properly designed RTOS can help a multi-task system achieve remarkable power efficiency, it can't be said that all low-power systems are RTOS-dependent. Likewise, the sort of complexity described above does not mandate the use of an RTOS. In other words, just about any application, even one involving complex communication protocols and severe power-consumption limits, could be written without the benefit of an RTOS's multi-tasking capabilities.

This being the case, it would seem that the most important factor likely to boost RTOS adoption for IoT devices is time-to-market concerns. In embedded systems, there is a substantial difference – which have become more pronounced with the coming of the IoT – between simply being able to do something and being able to do something quickly, efficiently, and in a repeatable way. What an RTOS ultimately provides developers, in the IoT and elsewhere, is a foundation for enhanced, accelerated project development.

There are numerous mechanisms, not limited to the software itself, through which an RTOS, as well as the RTOS's provider, can impact the development of an embedded device, and this combination of offerings is truly what distinguishes one provider from another. While every RTOS has its unique features, it would be relatively easy to identify a set of common RTOS services. For a portion of embedded developers, especially many in the maker and hobbyist communities, this basic set of services is a fine foundation for a new project. For other developers time-to-market challenges cannot be overcome with just any RTOS. To mitigate risks and ensure a successful project, these developers must select a proven RTOS, one that is fully documented and backed by time-saving support services.

Example platform

If the oft-quoted numbers are to be believed, then it seems likely that numerous developers from both of these camps will be needed to construct the IoT. At the moment, IoT discussions continue to be held in the future tense in many circles, but there are already numerous projects underway establishing patterns for RTOS usage in connected devices. A telling example of the type of solutions available to developers of such products is the recently released SmartMesh IP platform from Linear Technology.

Figure 2: The SmartMesh IP platform from Linear Technology offers impressive performance and minimal power consumption.

With SmartMesh IP, developers have at their disposal a collection of low-cost hardware modules for constructing 6LoWPAN-based mesh networks. The basic unit of these networks is a “mote,” like the one shown in Figure 2, that has a Cortex-M3 CPU core running Micrium's µC/OS-II RTOS. With the RTOS as its foundation, a mote can support surprisingly complex application code and is able to achieve battery life of 10 years or more. 6LoWPAN's use of IPv6 means that developers can easily connect their motes to a gateway, harness the data collection and analysis capabilities of the cloud, and transform any mesh network into a true IoT application.

Many of the features that the µC/OS-II RTOS makes available for developers are widely available in other embedded RTOSs. However, features and functionality represent just one concern of RTOS users. A list of today's top RTOS suppliers would include a number of companies that offer documentation, support, training, and consulting services alongside their software, and this model plays an absolutly vital role for embedded design engineers.

While it is a safe bet that RTOSs will often be used in IoT projects, it is not entirely clear that Google and other RTOS newcomers will be competing directly with the industry's longtime providers. It may be misleading to state that the IoT demands an RTOS. What may actually be required are multiple RTOSes, each serving a well-defined set of developers and offered under a model tailored to meet the needs of those developers.