help protect their legacy software investment as they move to new hardware platforms. This gives embedded developers the same benefits as IT organizations that have been running legacy Operating Systems (OSs) and applications on new server platforms for years. This investment is particularly key as hardware platforms shift from single-core to multicore 32- to 64-bit architectures and add new connectivity such as Wi-Fi, Bluetooth, or cellular communications.

As embedded systems take on a new lease on life with the advent of the Internet of Things (IoT) and as they take part in the very relevant subset of Machine to Machine (M2M) communications, they are evolving faster now than ever over their relatively short history. These traditionally dedicated systems now have to evolve onto new architecture platforms that have more than one core, and often have or need 64-bit architectures rather than only 32 bits of address space. Adding new communication mediums such as Wi-Fi, Bluetooth, or cellular and new GUI requirements such as touch, swipe, and drag brings a whole new set of complications for embedded designers.

However, the virtualization paradigm can now be used by embedded developers as they try to evolve their legacy systems to meet these new requirements without a complete rewrite or redesign of their existing systems; hence, virtualization can help developers manage the cost and time of bringing their systems into today’s connected world.

An elegant solution to a tricky problem

There is one technology that allows embedded developers to preserve their legacy software system even though the world around it – including the hardware that it runs on – is in a world of change. The technology is virtualization. This technology has been used in the enterprise software world for many years, allowing the IT departments to run multiple versions of IT applications and operating systems long after they are effectively obsolete. It is not widely used in the embedded world yet, mainly because the embedded system refresh rate is not as fast as in the enterprise world, but also because the enterprise hypervisors do not meet the embedded size and performance requirements in much the same way a desktop OS is less frequently used than a Real-Time Operating System (RTOS). What is needed for the embedded world is an embedded hypervisor that gives the benefits of virtualization but satisfies the key embedded requirements of small memory and code size and real-time deterministic performance.

Before examining how an embedded hypervisor can benefit the embedded developer, let’s examine virtualization in a little more detail. Virtualization is a technology that offers a “virtual” representation of hardware to the software running on top of it, including the processor, memory, and devices. A good example of this in our everyday world is the hypervisor that runs on an Apple Mac and allows Microsoft Windows to run next to Mac OS on the same hardware platform, because it is supplying Windows a “virtual” PC. This is a good example of a Type 2 hypervisor, where the hypervisor actually runs on top of the native operating system as an application, and then the “guest” operating system runs on top of it. This gives the advantage that the native OS is still in control and the guest OS is running at the same time, as it is essentially running as an application. However, there is a huge performance issue with the multiple layers of software in this solution, and this technology is not very portable for use across all embedded RTOSs.

There is also another virtualization solution that is commonly known as “Type 1” or “bare metal” that doesn’t rely on the native OS, and interacts directly with the hardware to provide the “virtual” hardware to the guest. This is getting closer to meeting the needs of the embedded developer, as it is certainly more efficient than the Type 2. However, as can be seen in Figure 1, it still relies on a “helper” operating system, which is close in size to the native OS in the Type 2 case. And even though it is known as “bare metal,” that does not mean it has the real-time or deterministic properties required by embedded developers.

Thus, a different breed of hypervisors has been developed that could be used by embedded developers to utilize a virtualization solution. Because of some inherent differences in design required to build an efficient embedded hypervisor, a new name was required to differentiate from the Type 1, and so, the embedded hypervisor has been called a Type 0 hypervisor.

Two key differentiators when comparing Type 0 to Type 1 are 1) size and 2) real-time performance. By removing the “helper” OS used in a Type 1 and creating a true bare-metal hypervisor, the runtime memory requirements drop from GB to MB and the static code size drops from MB to KB (see again Figure 1). Also, by removing the heavyweight helper OS and replacing it with a small embedded real-time kernel or “separation kernel” to separate resources, real-time determinism can now be realized. Additionally, by taking advantage of hardware virtualization features found in modern processors, the performance overhead of using a hypervisor get to over 95 percent of native performance.

 

 

Real world embedded virtualization use

Having established that an embedded hypervisor can provide a reasonable embedded footprint and real-time performance, we can now focus on the benefits to embedded developers as they look at their migrating their existing system to the next generation of connected embedded devices. The key objectives for these new systems can be the following:

• Move to modern hardware platforms that can be both multicore and 64-bit
• Compatibility with a modern standard user interface
• Increased connectivity, and with that the requirement for increased security

How can an embedded hypervisor help with all of these, and reduce the amount of rewritten code from the legacy system? The hypervisor does a couple of things really well that would be difficult to achieve with just a standard RTOS.

Abstracting the underlying hardware

The first of these hypervisor capabilities is that of abstracting the underlying hardware from the RTOS and applications that run on it. This really helps when migrating an existing RTOS and applications to a new hardware platform, as the hypervisor can make the virtual hardware look just like the original hardware, and can apply to memory, processor, and devices.

So as the new physical hardware could be a multicore, 64-bit processor with a set of new modern devices, the hypervisor could present a 32-bit, single-core virtual processor with the new physical devices being mapped to virtual versions of the legacy devices. This prevents the immediate move to a new SMP, 64-bit RTOS, and also reduces the need to create new BSPs for the new devices on the board. It is also a relatively elegant way of introducing new connectivity options such as Wi-Fi or cellular networks, as they could be made to look just like a regular Ethernet device by means of device virtualization.

Multi-OSs facilitate new interfaces, security

The second key capability of virtualization is to allow multiple operating systems to run on a single hardware platform. This allows the embedded developers to keep their legacy system intact, and add new functionality by introducing another operating system running in parallel. This might seem very inefficient, but with the leap in hardware technology, and the cost of memory, a modern multicore system with hardware virtualization support could actually run multiple operating systems without any performance degradation; this is also much cheaper than having to source obsolete hardware components. This multi-OS scenario is another interesting design consideration when bringing new connectivity mediums into the system, as rather than virtualizing the new devices, the new operating system could be used to communicate externally and then pass information via the hypervisor’s internal communication scheme to the legacy system.

This multi-OS scenario also has some interesting design benefits for connected embedded systems outside of just bringing in legacy systems, and can help bring in new requirements such as modern user interfaces and additional security. An issue that has been constant for embedded developers has been standard user interfaces for embedded systems, as standard GUI-based OSs have traditionally been too big or too slow for real-time systems. And with RTOSs, the GUI has to be built from scratch and hence does not have all the touch/swipe functionality that we are used to on our phones, tablets, and computers.

By using an embedded hypervisor, developers can have their cake and eat it too. By having an RTOS in one Virtual Machine (VM) and a more traditional GUI OS such as Android in another VM, the real-time part is taken care of and a user-friendly standard GUI is built in; by using a multicore processor, each can be given their own dedicated processor, memory, and resources by the hypervisor. (See Figure 2, which shows the separation of real-time from desktop functions.)

 

 

The final piece of the puzzle is security – possibly one of the hottest topics for connected embedded devices, as these once dedicated and proprietary systems are now being connected and controlled across the open Internet; therefore, they are now possible targets for cyber crime and cyber terrorism. By using a separation kernel and embedded hypervisor, different parts of the system can be easily segregated and protected.

For example, the virtual machine that is connected to the Internet is often different from the virtual machine that is controlling something or storing information, which is typically the primary target for malicious attacks. So even if one VM gets infected, that infection cannot spread to another virtual machine as the separation kernel is keeping them apart, in much the same way that they would be if they were running on physically separate pieces of hardware.

Is embedded virtualization real?

In conclusion, the virtualization technology known as the embedded hypervisor, based on a real-time separation kernel, can help embedded developers bring their legacy embedded systems into the next generation of connected, multicore systems with user-friendly GUIs and added security to protect against malicious threats. It all seems a little too good to be true. At LynuxWorks, we have developed a separation kernel and embedded hypervisor called LynxSecure, and now in its fifth generation, it is helping embedded developers meet their new design goals – on time and on budget.

Robert Day is Vice President of Marketing for LynuxWorks, where he is responsible for all global external and internal marketing functions. With more than 20 years in the embedded industry, his most recent position prior to joining LynuxWorks was heading marketing for Mentor Graphics’ embedded software division. Prior to the marketing role, he held a variety of management, sales, and engineering positions for Mentor Graphics and Microtec Research, spanning more than 18 years in total. He is a graduate of the University of Brighton, England, where he earned a Bachelor of Science degree in Computer Science.

LinuxWorks www.linuxworks.com

Follow: Twitter Facebook LinkedIn