About embedded virtualization

Virtualization means different things to users with different types of applications. Most forms of virtualization employed in IT server environments aren't of interest to embedded system developers because they don't ensure that processing of time-critical tasks is deterministic. Instead, the way for single and multiprocessor platforms to support multiple operating environments while maintaining real-time responsiveness is to functionally partition processor resources so that they are controlled by specific operating environments, which run directly on the processor silicon rather than on virtual machine implementations.

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.

refer:

http://embedded-computing.com/articles/the-multiprocessor-multi-os-systems/#utm_source=Multicore%2Bmenu&utm_medium=text%2Blink&utm_campaign=articles