The origin of embedded virtualization technology came about with the idea of creating an environment where a Real-Time Operating System (RTOS) could work alongside a General-Purpose Operating System (GPOS) such as Microsoft Windows. Embedded virtualization creates a partitioned environment in which the two OSs and the applications on them run on a single platform as if they were running on two separate platforms. The advantages of doing this are clear: system cost and complexity can be reduced if fewer processing platforms are required to serve the application’s computing needs. Product reliability can be enhanced as well if systems can be built with fewer hardware elements.

Back in the early ’80s, machine builders saw the opportunity to leverage the PC platform to build control systems for their machines. The first such applications were relatively simple, and the focus was mainly to leverage available hardware that was substantially lower in cost than specialized control hardware.

As the PC evolved with the addition of Windows, numerous application software packages were introduced, driving a new standard of Human Machine Interface (HMI) with supporting graphic engines and software tools. Machine builders saw the opportunity to use Windows to create advanced HMIs that could simplify their machines’ setup, operation, and maintenance. However, Windows-based PCs could not be used for portions of an application involving time-critical control because Windows, by itself, isn’t an RTOS and is not capable of performing control functions with determinism. Hence, embedded system designers would typically add a real-time computer subsystem to the machine in addition to the PC to deliver a full suite of product functionality.

RTOS suppliers, on the other hand, have not had the resources to build the kind of graphic software tools and support that are available for Windows. A few saw the opportunity to couple their OSs to Windows in order to add RTOS functionality to Windows-based systems on a single computing platform.

The benefits of combining an RTOS with Windows on one machine were obvious for embedded systems OEMs, but the technical issues associated with doing that were very complex. Running two OSs on one computer wasn’t a new concept; it had been done 10 years before on mainframes with virtualization technology. That technology virtualized the whole computer platform, essentially creating an interface layer between the OSs and the hardware much like modern server virtualization technology does today.

The fundamental problem with this is that isolating the OS and application software from direct access to the hardware causes nondeterministic time delays when the application software needs to interact with its I/O. Real-time applications, however, must have direct access (sometimes called bare-metal access) to the devices that the applications need to control, so that the software can write or read data to and from the I/O devices in a timely, deterministic manner.

Embedded virtualization solves the multi-OS determinism problem

A method must be devised to partition the platform resources so that the RTOS can gain direct access to I/O and interrupts that are necessary for it to run an application deterministically. GPOSs like Windows do not allow a co-resident RTOS to control its I/O devices.

Instead, GPOSs typically take control of all available I/O on the platform during installation. Barring the option of modifying Windows, which would bring a whole new dimension of problems, a means of reserving I/O from Windows had to be devised. And since this was initially done back in the days of single-core processors (Figure 1), techniques had to be developed for the processor to switch context from the RTOS to the GPOS with minimum overhead. These are the principles of embedded virtualization, principles that have been validated in thousands of successful embedded system products.

 

 

Interprocess communication enables task coordination

Multiple OSs running applications in shared but separate environments create the need for applications to pass data to each other. This could easily be performed with a simple block of reserved memory, but would require some level of housekeeping by the applications and would be cumbersome to manage in real-time systems, where messages need to be delivered and read at particular times.

The communication process needs to be structured in such a way that message delivery occurs when expected to maintain determinism. Communication has to take into consideration the priority of the message with respect to the priority of other real-time tasks that are running at the time, so that the message will be delivered at the right time or in the right sequence. This is particularly important when the communication is between an application running in a non-real-time GPOS environment and an application running on an RTOS in a real-time environment. An unprioritized event must not be allowed to interrupt a prioritized task.

Multicore processors aid functional partitioning

The introduction of multicore processors caused some of the rules to change. In principle, processors no longer need to be shared. Each OS can have its own processor core (or multiple cores can be dedicated to a single OS); however, in practice, OSs such as Windows assume that all processor cores belong to them at installation.

Setting up a multicore system so that the GPOS is in control of some cores and not in control of others requires a way to tell the GPOS which cores are not available to it. With the proper means of resolving this, a four-core processor could support several configurations of GPOS:RTOS, including 3:1; 2:2, and 1:3 (see Figure 2). This flexibility allows the user to optimize the platform’s computing resources depending on the application’s requirement. Whereas an application with a complex Windows portion and light real-time requirements could be configured with three cores running the GPOS application and one core running the RTOS, an application with multiple real-time control functions running simultaneously and communicating with a simple HMI might have one core dedicated to Windows and three to multiple instances of the RTOS.

 

 

With the possibility of running several RTOSs at the same time on a multicore processor, the communication system that was initially developed to communicate between the GPOS and the RTOS on a single shared processor can be extended to enable communication between multiple instances of the RTOS and GPOS. In theory the system architecture could be expanded to create a network of OSs talking to one another, each running application elements that are particularly suited to its own environment. As with the I/O needs of the system, the communications structure needs to maintain and support the real-time determinism requirements of the real-time subsystems.

Virtualization enables deterministic communication across platforms

One embedded virtualization environment that has proven itself in mission-critical applications is the INtime RTOS family from TenAsys Corporation. INtime’s embedded virtualization technology encapsulates the principle of partitioning the PC platform to enable Windows and the RTOS to run side by side. INtime facilitates deterministic communications between instances of the RTOS and Windows with a global object networking system called GOBSnet. This consists of a built-in communication network that allows multiple applications on separate OSs to communicate at the process level in a deterministic way.

Using Ethernet with an addressing scheme akin to that of a URL, GOBSnet was extended to enable separate system functional blocks, called nodes, to communicate deterministically with each other on the same multicore processor or across platforms that are physically distinct. In this manner, large and complex applications can be distributed across several nodes (see Figure 3), simplifying their creation, debugging, and optimization while leveraging the parallel processing capability of multicore processors. This allows OEMs to produce a range of products at different cost points or functionality levels by scaling the number of processors or processor cores that are employed.

 

 

Embedded virtualization techniques have been developed over more than a decade of use in real-time applications, but the full potential of these methods to revolutionize embedded system design is just now becoming clear with the advent of processors that include increasing numbers of CPU cores. Along with global object networking support, embedded virtualization is primed to become the standard way of building large multi-OS systems.

Chris Grujon is marketing director for TenAsys Corporation.

TenAsys Corporation [email protected] www.tenasys.com

Follow: LinkedIn