The RTS Hypervisor works 32-bit or 64-bit Intel and AMD x86 multi processor or multi core hardware. This includes e.g. Intel Atom, Core, XEON or Core-i Architectures and AMD G-Series and R-Series.
As individual CPUs are assigned exclusively to the various operating systems, you may deploy as many operating systems on a given hardware as there are CPUs. This includes logical CPUs found on processors with hyper threading architecture.
Yes, multiple CPUs may be assigned to a guest operating system.
Out of the box, the RTS Hypervisor currently supports Microsot Windows 10 and older, Windows Embedded Compact, VxWorks, RTOS-32, QNX, OS-9, Linux and real-time Linux, RedHawk and T-Kernel. Support for other operating systems or your own real-time code can be added anytime upon request.
The RTS Hypervisor is a "Type 1", i.e. a bare-metal hypervisor.This implies that no host operating system is used. Operating systems are completely independent of each other. No specific operating system has to execute. Systems that simply run multiple instances of e.g. an RTOS or a mix of e.g. Windows, Linux and others can easily be configured.
Most of our customers previously had at least two independent computer systems for various tasks. E.g. a Windows PC running an HMI (Human Machine Interface) and a second system for real-time control, e.g. an ARM or PPC running a real-time operating system. With the RTS Hypervisor they were able to consolidate their hardware systems into one single x86 platform.
There are also applications where the users like to deploy the RTS Hypervisor running multiple instances of the same operating system in order to achieve load balancing, monitoring, redundancy or again hardware consolidation.
Anytime, cost, size, weight or power is limited or has to be reduced, the RTS Hypervisor might just be the solution for you. At the same time MTBF (Mean Time Between Failures), i.e. reliability can be increased.
No, there is no third party software used in the RTS Hypervisor. The virtualization software in the RTS Hypervisor has been specifically developed for the target markets of real-time and embedded applications. Unlike other virtualization solutions, only the approach of "Partition where you can, Virtualize where you have to" results in hard real-time and deterministic behavior of the system.
The RTS Hypervisor offers two different modes of deploying an operating system.
1. The fully "monitored mode", where operating systems run completely unmodified in a secure partion. In this mode it is guaranteed, that the OS can not impair or affect other operating systems running in parallel in any way. However, this comes at the expense of a slight performance hit.
2. In order to guarantee hard real-time and determinism for real-time code or real-time operating systems, the RTS Hypervisor also features a deployment mode called the "Privileged Mode". In the privileged mode, operating systems retain full hardware access and use a paravirtualization interface provided by the RTS Hypervisor. This allows operating systems to run at native speed without any latencies added by the Hypervisor.
3. Shared resources like last level cache or memory bus access can be prioritized between operating systems.
Absolutely! The RTS Hypervisor provides a simple API and examples to port your own operating system, BSP (Board Support Package) or just real-time code without any underlying operating system to the Hypervisor. Once an operating system or real-time code has been ported to this RTS paravirtualization interface, it can be deployed in any combination with other operating systems supported by the RTS Hypervisor and / or run in multiple instances on the same hardware platform.
As most traditional systems have been designed to communicate via TCP/IP, the RTS Hypervisor offers a high-performance virtual network in order to make porting as easy as possible.
Apart from the virtual network, the RTS Hypervisor also features shared memory as a means of communication and synchronization between operating systems.
On the RTS Hypervisor individual operating systems may also exchange events. The implementation uses Inter-Processor-Interrupts (IPI) to allow the event system to be used for real-time applications.
In order to guarantee hard real-time behavior, Interrupts are assigned exclusively to the various operating systems. To avoid conflicts when assigning devices to the various operating systems, the RTS Hypervisor allows the use of MSI (Message Signaled Interrupts), no matter if the operating system(s) run in privileged or in fully virtualized mode. Interrupts are not processed by the Hypervisor itself but routed directly in hardware to the respective cores. This guarantees native performance and allows the use of standard, unmodified device drivers.
Yes, since physical devices are assigned exclusively to operating systems, no matter if they are executing in fully virtualized or in privileged mode, standard device drivers can be used without porting. Any device supported by the operating system running without hypervisor, may be used in conjunction with the RTS Hypervisor.
If your OS, e.g. Microsoft Windows requires an installation to disk, you may first install the operating system(s) and then proceed with the Hypervisor installation. In case operating systems do not require an installation on disk, the RTS Hypervisor can also load images directly from a specified location.
After the regular BIOS execution, the boot loader loads the Hypervisor which then initializes the hardware and starts the various operating systems in the selected boot sequence. Both, boot loader as well as Hypervisor can be configured to be invisible to the end user.
Yes, the RTS Hypervisor may be booted by any multi-boot compliant boot loader.
Yes, when a physical video card is assigned to an operating system, the original video driver can be used and all features remain fully available.
Yes, all operating systems running on the RTS Hypervisor are independent and may reboot any time without affecting others executing in parallel.
Configuration for any hardware is typically a matter of minutes and can be performed by the user. No specialized know-how regarding hardware, I/O or memory is required to setup the system. A simple configuration file is used to specify guest operating systems, device assignment and e.g. boot sequence.
After setup of the system developers can start working immediately without further training. Development, debugging and tools are identical to the development on systems without a hypervisor.
Any standard debug tools and interfaces can be used. This includes tools for kernel debugging as well as application debugging. Unique about the RTS Hypervisor is the possibility to debug your real-time target e.g. from another core executing Windows in parallel via the virtual network. No specialized tool or training is required.
Note: Due to the number of requests, evaluations are limited to customers with current projects only. Thank you for your consideration.