Decades-old RTOS technology is still going strong, and is responding to new trends and advances to meet today’s embedded system needs.

Many moons ago the microprocessor gave birth to a new age in embedded systems development. Soon after, engineers began developing custom task schedulers to manage hardware resources for applications being created to run on these new programmable chips. From there, Real-Time Operating Systems (RTOSs) began proliferating. These RTOSs, some recognizable, others perhaps not – VRTX, pSOS, RMX, OS-9, QNX, Nucleus, SMX, LynxOS, Deos, INTEGRITY, ThreadX, VxWorks, and others – developed in the 1970s and 1980s began replacing in-house task schedulers and made it easier to develop embedded products.

These were simpler times; the I/O and network connectivity used RS-232 and/or RS-422 serial ports. Sixty-four kilobytes of RAM for the entire software build was the norm. Graphics were unheard of. Engineers were comfortable with assembly language, and C language was largely discounted due to the need to highly optimize the software running on these systems.

Fast forward to 2014 – powerful multicore processors, Gigabytes of memory, lots of I/O, graphics, and networking options have transformed embedded systems into a very different animal. Virtualization is being employed in embedded systems as a means to consolidate complex architectures and provide separation between real-time and non-real-time systems.

For many years, the RTOS has largely flown under the embedded radar, but still serves a critical role in many systems that require hard computing deadlines be met. A number of RTOS companies have contributed to the evolution of embedded systems over the past ten years with disruptive technologies, helping shape the RTOS as we know it today.

Some things never change

The fundamental requirements of the RTOS from years ago still apply today – maintaining real-time determinism, high reliability, and time to market.

There will always be embedded devices that require hard real-time determinism, so real-time characteristics of the RTOS are still at the top of the list in importance. As processors have increased in performance, more instructions can be executed while still meeting traditional real-time deadlines, but determinism has, is, and will continue to be most important.

The RTOS itself must be rock solid in terms of managing platform resources, providing error resistant Application Programming Interfaces (APIs) and ensuring that the implementation is reliable and resistant to fatal errors.

"An RTOS is like a network of freeways,” says Ralph Moore, President at Micro Digital (www.smxrtos.com). "There may be thousands of origins and destinations, but most traffic flows through kernel pathways. The smx RTOS has been progressing toward greater error checking recovery features in the API to make kernel pathways safer. For example, code that goes past the curly brace of its main function causes smx to put that task into a dormant state to prevent undefined operation.”

Time to market is also a subject of interest, as more finished code, complete vertical platform packages, good development tools, and robust error checking are the most critical contributors to accelerating deployment time.

Chris Ault, Senior Product Manager at QNX (www.qnx.com) emphasized pre-integration of features for vertical market applications. "Expectations years ago stopped at the Board Support Package (BSP) and development was measured in years. Now more features and capabilities are on the boards and added to QNX to provide less development effort.” Ault cited the QNX Car platform as integrating GPS, power management, and smartphone integration, in addition to helping to achieve ISO 26262 certification as an example of an RTOS with software stack support for the auto industry vertical market.

The Deos RTOS from DDC-I (www.ddci-com) is an example of an RTOS focused on a specific market through its APIs and certifications. Tim King, Product Marketing Manager at DDC-I says Deos is tailored for safety-critical applications through providing a time- and space-partitioned DO-178 Level A certifiable RTOS. The "vertical stack” in this instance comes in the form of ARINC 653 specification conformance and implementing Rate Monotonic Analysis (RMA) to comply with avionics standards.

Embedded virtualization

There are two key benefits of embedded virtualization. First is the ability to consolidate the real-time and non-real-time systems in a single platform. Second is providing isolation between software environments where one side is high reliability and safety critical and the other side may run third-party applications and be open to possible errors as a result.

TenAsys (www.tenasys.com) and the RMX kernel were founded on the notion of combining a real-time OS with a more robust software environment, thus RMX and the INtime package was born. Kim Hartman, Owner and VP of Sales and Marketing at TenAsys described the inception of the INtime environment. "The whole thing started with the use of 80386 and its ability to task switch. Then an application called Windows came along. TenAsys used the RMX RTOS and a run-time package called INtime to enable utilization of PC software in conjunction with an RTOS environment.” The INtime environment is designed to work in a virtualized environment in a para-virtualized way. The environment also makes use of the Intel Architecture Virtualization Technology (VT) support to make the embedded virtualization environment as efficient as possible.

Wind River (www.windriver.com), LynuxWorks (www.lynuxworks.com), and others are also strong proponents of embedded virtualization, and are actively providing hypervisors (Wind River Hypervisor, LynxSecure) in various forms that support separation of OSs, sharing or segmenting of resources, as well as communications hooks that still provide isolation between environments.

These kinds of embedded virtualization capabilities enable RTOSs to blend Linux or Windows operating environments. However, unlike enterprise virtualization where separate Virtual Machine (VM) environments operate autonomously, these virtualized RTOS implementations require communications pathways between the embedded virtualized environments in order to exchange data and control information.

Multiple CPU architectures

RTOS vendors tend to diverge on the tenet of multiple CPU architectures. Some RTOS vendors focus on specific processors while others work to make their RTOS available across a large number of architectures. Focusing on fewer processors, in theory, enables a more complete, focused solution set for that architecture. Supporting a wide range of architectures increases the realm of portability and allows the user to move to other architectures as their products evolve.

The OS-9 RTOS was a market leader for Motorola VME systems back in the day, and was also widely used in early-adopter consumer devices like the Radio Shack Color Computer, Motorola Pagewriter, Compact Disc Interactive (CD-i) players, and interactive TV set-top boxes. Allan Batteiger, GM of OS-9 company Microware LP (www.microware.com), believes that supporting multiple CPU architectures as well as multicore OS virtualization will be important going forward. "This requires the RTOS to support a memory-based virtual Ethernet, provide time synchronization between the OS environments, and efficient inter-process communications,” he says.

The OS-9 architecture consists of a number of independently compiled modules from the kernel, I/O systems, file managers, drivers, applications, and libraries that provide the ability to independently update a given module while the system is in use. The ability to perform this kind of granular update/maintenance is an important characteristic for systems that require high availability.

Multicore

Multicore in embedded is becoming mainstream. Multicore processors enable embedded virtualization while increasing performance, and because of it we are entering a new era in embedded development.

John Carbone, VP of Marketing at Express Logic (www.rtos.com) talks about the impact of multicore on the ThreadX RTOS. "Multicore has prompted us to add support for Symmetric Multiprocessing (SMP). This has also opened up SoC additions like downloadable application modules for firmware flexibility and the introduction of a new Graphical User Interface (GUI) framework that can create professional GUIs even on small MCUs.”

Most vendors either have or are developing a Symmetric Multiprocessing (SMP) version of their RTOSs, which only makes sense given that processor technology has evolved over time to add more cores rather than faster CPU clock speeds.

Green Hills’ (www.ghs.com) INTEGRITY RTOS provides Symmetric and Asymmetric Multiprocessing (AMP) options. Similar to LynuxWorks’ LynxSecure hypervisor and the Wind River Hypervisor, Green Hills offers an INTEGRITY Multivisor that provides embedded virtualization to host multiple OS environments on a multicore processor for embedded applications.

The "Internet of Things” effect

Wind River’s perspective and roadmap for VxWorks is strongly influenced by the Internet of Things (IoT) phenomenon. Dinyar Dastoor, VP of Product Management at Wind River, provided an overview. "Driven by the convergence of cloud technology, rapidly growing data volumes, and increasingly connected devices, the Internet of Things (IoT) poses new challenges and opportunities,” Dinya says. "To address the IoT, an RTOS must evolve to deliver more modularity, security, and a rich graphics feature set being demanded by this new IoT world.” The latest version of VxWorks includes updates to connectivity and protocol standards, and modularity that enables scaling across processors and platforms.

John Blevins, Director of Software Tools Development at LynuxWorks emphasized the influence of the IoT on LynxOS evolution, stating that "LynuxWorks is responding to the new M2M and IoT technology trends by combining new security features, networking stacks, and open standards with LynxOS RTOS products.” Blevins cited cyber-attacks and Internet connectivity with M2M and IoT systems as driving RTOSs features like discretionary access controls, roles and capabilities, audit logging, authentication, cryptography, trusted path, and self-test capabilities, all of which he says are being added to LynxOS 7.

Andrew Caples, Senior Product Manager, Real Time Operating Systems at Mentor Graphics (www.mentor.com) also mentioned the Nucleus RTOS being driven by the IoT trend. "IoT is characterized by low-end systems that require features typically seen on high-end, feature-rich systems,” he says. "The RTOS architecture needs the flexibility to incorporate a wide range of middleware and run on a spectrum of low-cost MCUs up to high-end MPUs.” Andrew also mentioned the importance of power management and how the Nucleus Power Management Framework provides the ability for software developers to access specific processor and I/O power modes to conform to power requirements of specific embedded devices.

A common theme with RTOS and the IoT is power sensitivity and the range of the networks and communications protocols needed. Common communications standards support goes well beyond just Internet Protocol (IP), including CAN, Bluetooth, Continua, ZigBee, USB, and Wi-Fi as additions beyond Ethernet.

Building a modern real-time operating system

As embedded systems technologies progress and new standards, processors, platforms, I/O, and applications emerge, the RTOS continues to evolve and adapt to incorporate these new capabilities and play a vital role in the development of the next generation of embedded systems. The RTOS is no longer only about managing memory, I/O, and task scheduling with a few tools thrown in. It’s about complete and robust integrated development and debug environments, rich graphics, and network capabilities, security features, and the ability to communicate with other virtualized software environments while maintaining real-time determinism, high reliability, and efficiency.

As an engineer who got his software start developing RTOS software, I can appreciate the complexity and talent it takes to satisfy the myriad of scheduling, latency, and efficiency requirements that an RTOS must meet in some of the most demanding environments. As I spoke with people charged with moving RTOSs forward, I came away impressed with how robust and interoperable these environments have become to accommodate these latest technology trends; I’m even more impressed that all this is being achieved while still providing the same determinism and reliability required since the inception of the RTOS.

For more information contact Curt at [email protected].