New separation kernels and embedded hypervisors can help ease the pain of migrating legacy systems to new hardware platforms, including multicore processing systems. Bringing multiple OSs and applications on to the same hardware also opens up new possibilities for combining systems that offer real-time performance within a familiar GUI environment. The LynxSecure separation kernel and embedded hypervisor from LynuxWorks is one of the latest generations of this technology, and is used to illustrate these new capabilities.
A major problem facing embedded software developers is how to easily migrate applications onto new hardware. The risks and difficulties of migration often force developers to stick with outdated software and hardware platforms, making it difficult and costly to add new competitive features to their embedded products. Undertaking development in high-level languages (e.g., C and C++) and using RTOS platforms with open standards interfaces (e.g., POSIX) can make the transition a little easier, but there are still major porting efforts required when the hardware changes.
Much of the time, the embedded software engineer just wants to run his legacy system on the new hardware without having to change anything, and add new features alongside it to, say, offer a more modern user interface or perhaps to pick up new communication protocols to talk to the outside world.
Interestingly enough, something similar was recently needed in the IT world, where multiple applications and versions of OSs needed to run on multiple hardware platforms. The prevailing solution in IT has been using software virtualization. It provides a common software environment in which to run different ‘guest’ OSs and their applications across many hardware environments.
This virtualization—or ‘hypervisor’—technology is now available to embedded developers, offering similar benefits for the reuse and migration of legacy platforms. Another interesting benefit of using an embedded hypervisor when combined with a software separation kernel is that it allows a traditional embedded RTOS to be resident on the same physical hardware as a more traditional desktop OS like Windows or Linux without compromising the real-time performance and determinism of the system.
The separation kernel is a modern version of an RTOS that includes the ability to safely and securely partition both time and memory for the different software applications running in the system. The applications run in their own virtual machines that are protected from each other by using the separation kernel and the memory management unit of the processor. Partitioned OSs have been used in safety-critical systems (e.g., avionics applications) for a while, but the separation kernel adds two new components, security and multi-processor support, that make them still more widely applicable.
In a safety-critical system, a partitioned OS is used to guarantee that any fault condition is isolated to the application in question and cannot corrupt or contaminate other applications that are running on the same hardware. At the same time, there are guarantees that each application gets its required time slice regardless of what else is happening, based on predetermined priorities and time allocations. In a system requiring security functionality, the separation kernel must have the ability to stop malicious faults or attacks that have entered into the system through a breach in one of the applications.
The separation kernel can also help with another interesting challenge, that of embedded software development on multicore devices. The traditional RTOS has been good at distributing functionality on a single device, as it can control and marshal all the resources that the single processor can control. In a multicore system there is a need to control and synchronize resources and applications that are spread over multiple cores. Running multiple instantiations of a traditional RTOS can deal with the spread of different applications across different cores, but is typically somewhat limited in the communication between, and the synchronization across those applications.
A well designed separation kernel can actually run one instantiation of itself in a multicore system. Using the partitioning and secure communication mechanisms described above, it can allow partitioning of the system across multiple cores and allow communication paths and synchronization mechanisms between applications regardless of which core they are running on.
Separation kernels have a great deal of flexibility and yet offer a greater degree of security than traditional embedded RTOSs, and are likely to become very widely used over a broad range of different embedded applications on many different hardware platforms. This gets really interesting when the separation kernel is married to a software hypervisor. The embedded hypervisor is designed to be smaller and more efficient than its IT cousins, but still gives the benefit of being able to run different ‘guest’ OSs on top of an RTOS.
The hypervisor and separation kernel combination gives a new dimension to embedded software development, offering the ability to run multiple guest OSs and applications securely separated by a real-time system. The combined use of multicore processors, a separation kernel and a hypervisor allows developers to partition their system with guest OSs spread over multiple cores, and retains the ability to control communications between them using a common separation kernel.
Many new multicore processors also offer hardware virtualization to allow hypervisors to more efficiently run guest OSs. Although much of this technology has been built for the IT world, it offers some very compelling benefits for embedded users. By allowing the hardware to help with software virtualization, for example the VT-D and VT-X technology provided on Intel processors, it enables the hypervisor to leave many of its instruction and data handling operations to hardware. This boosts the performance of running guest OSs to near native performance, and does not compromise the real-time attributes of the guest applications even though they are running in a virtualized environment.
Rather like a memory management unit, hardware virtualization also prevents the guest OSs from interfering with other parts of the system without having to rely totally on software management. This increases the security of the system without degrading the real-time performance and determinism.
For many embedded systems, performance is a key factor, and this separates the new generation of embedded hypervisors from traditional IT-centric offerings. There are different types of software virtualization available to the embedded developer, offering the best control over a guest OS.
The first is not really virtualization or a hypervisor, but rather a software emulation package. This is often provided under the guise of virtualization, but it has a very important element that needs to be clarified—that of performance.
A software emulator essentially translates the machine instructions of one processor on top of the target hardware, and is available as an application that can run on top of a partitioned OS. This software emulator then can present a full emulated environment to a run a guest OS on. This can be very appealing as it appears to give the same functionality as a hypervisor, but there is a huge performance hit as the emulator is having to translate each instruction for both the guest OS and the applications running on it.
A true hypervisor will assist in the running of guest OSs, but they will still be running on the processor for which they were designed, removing the need for emulation and hence increasing performance.
Two types of hypervisor virtualization are available: para-virtualization and full virtualization. Para-virtualization is a term used for a guest OS that has been modified to run on top of a hypervisor. In this case, the virtualization environment on which the embedded applications run has been optimized for performance, both for the processor environment and for the hypervisor. This approach offers a near native execution performance for the embedded applications and OSs when combined with hardware virtualization extensions, and can be used to host true RTOSs in their own partitions.
Another approach that can be used with this technology is that of full virtualization. Here, the same hypervisor can offer a virtualization environment to the guest OS that is akin to running on the native hardware. This requires no changes to the guest OS, but because the hypervisor is adding more virtualization, there is a small performance hit in comparison to the para-virtualized approach. An advantage of full virtualization is that OSs where the source cannot be para-virtualized (e.g., Windows) can still be run in this embedded system.
The LynxSecure separation kernel and embedded hypervisor from LynuxWorks offers both para- and full virtualization as well as the ability to run these different types of virtualization simultaneously in the same system. This allows the embedded developer to pick and choose the type of virtualization based on what guest OSs are required and the performance aspects of different parts of the system. This elegant solution has unlimited flexibility without sacrificing the performance required by embedded systems.
Returning to the original issue of code migration, this new technology not only allows applications to be migrated to new hardware, but also for them to use the OSs that they were originally run on. The use of the separation kernel also allows these legacy systems to be contained in their own virtual machine, and even allocated their own core in a multicore system.
Figure 1 shows a legacy RTOS application running in its own partition, sharing a core with a new set of applications on a new RTOS, while the other core has the GUI element with a fully virtualized guest OS like Windows for a familiar man machine interface.
This scenario is likely to become quite common in many embedded industries from industrial controls through to medical, financial, military and automotive systems. It brings together a real-time system (e.g., data collection from a networked sensor system) with a more traditional GUI-based OS such as Windows or Linux. This combination on a single piece of hardware has always been a challenge, as both systems have individually required control of underlying hardware, which could compromise both the real-time performance aspects as well as the security and integrity of both systems. The separation kernel and hypervisor allows both the RTOS and GUI OS to each run in their own partition, possibly each on their own core in a multicore system, both protected from one another, but allowing each to securely communicate with each other.
Because the software environment is virtualized, any legacy applications will also run as before, removing the need for a large amount of recoding. The RTOS will be able to run in real time because the underlying separation kernel still provides a deterministic environment; the GUI OS will believe it has full control of the processor, and will perform as if it has its own dedicated machine. This system will then be able to offer a familiar user interface to control and display the data, while the RTOS busily collects the information without compromise.
855 Embedded Way
T: 1 408 979 3900