FAQ

Als Hypervisor vom Typ I (bare metal) teilt der RTS Hypervisor den PC sicher in separate Hardware-Partitionen auf, die jeweils aus einem oder mehreren CPU-Kernen, Speicher, Timern und I/O-Geräten bestehen. Hardware wird üblicherweise nicht zwischen mehreren Betriebssystemen geteilt, was auch CPU-Kerne einschließt. D.h. die Betriebssysteme laufen parallel, ohne sich gegenseitig zu unterbrechen. Es stehen verschiedene Ausführungsmodi zur Verfügung: Von der vollständigen Isolierung bis hin zur harten Echtzeit. Im Gegensatz zu Echtzeit-Erweiterungen (bei denen Ressourcen für Echtzeit-Aufgaben von einem Host-Betriebssystem bereitgestellt werden) stellt der RTS Hypervisor sicher, dass Echtzeit-Aufgaben nicht von anderen Betriebssystemen kompromittiert werden können. Ein Betriebssystem offen für Endbenutzer und / oder mit der Außenwelt verbunden zu haben, während ein anderes Betriebssystem kritischen Code ausführt, ist einer der typischen Anwendungsfälle. Einen Mix aus Echtzeit- und Nicht-Echtzeit-Betriebssystemen zu betreiben ist nur eine Frage der Konfiguration.

Der RTS Hypervisor bietet verschiedene Betriebsmodi für Betriebssysteme.

• Der vollständig "überwachte Modus", bei dem Betriebssysteme in einer sicheren Partition vollständig und ohne Hardwareanpassungen ausgeführt werden. In diesem Modus ist gewährleistet, dass das Betriebssystem andere parallel laufende Betriebssysteme in keiner Weise beeinträchtigen oder beeinflussen kann. Dies geht jedoch, wenn auch minimal, zu lasten der Performance.
• Um harte Echtzeit und Determinismus für Echtzeitcode oder Echtzeitbetriebssysteme zu gewährleisten, verfügt der RTS Hypervisor über einen Deployment-Modus, den sogenannten "privilegierten Modus". Im privilegierten Modus behalten Betriebssysteme vollen Hardware-Zugriff und verwenden eine schlanke Paravirtualisierungsschnittstelle, die vom RTS Hypervisor bereitgestellt wird. Dadurch können Betriebssysteme mit nativer Geschwindigkeit laufen, ohne dass der Hypervisor Latenzen hinzufügt.
• Sicherheitsoptionen wie MMU-Virtualisierung, I/O-Einschränkungen und IOMMU können selektiv aktiviert werden.
• Gemeinsame Ressourcen wie z.B. Last Level Cache oder Speicherbuszugriff können zwischen den Betriebssystemen priorisiert werden.

Der RTS Hypervisor ist sehr flexibel. Unabhängig davon, ob ein Low-Power-Modul oder ein Multi-Socket-Server verwendet wird, wird die exakt gleiche Hypervisor-Binärdatei ausgeführt. Damit ist der RTS Hypervisor auf jedem PC lauffähig und anwendungsspezifische "Anpassungen" sind nur eine Frage der Konfiguration, die unsere Kunden selbst durchführen können.

Der RTS Hypervisor läuft auf jedem modernen x86-basierten PC mit beliebigem Chipsatz. Bestimmte Funktionen (z.B. IOMMU) können Hardware-Unterstützung erfordern.

Für die Zuweisung des Last Level Caches ist CAT erforderlich.

Zum Schutz des Speichers auf Geräteebene und zur Verlagerung von Betriebssystemen im Speicher wird eine IOMMU benötigt.

Während Caches im Allgemeinen Jitter reduzieren, können Shared Caches dazu führen, dass Betriebssysteme sich gegenseitig beeinflussen. Wenn der Prozessor die Cache Allocation Technology (CAT) unterstützt, kann ein Cache, der sonst gemeinsam genutzt werden würde, in OS-exklusive Caches aufgeteilt werden.

Es werden alle gängigen BIOS- oder EFI-Basis-Firmware (mit oder ohne CSM) unterstützt. Wenn allgemein übliche Betriebssysteme ohne Änderungen auf dem PC laufen, läuft der RTS Hypervisor ebenfalls auf solch einem System.

Um den RTS Hypervisor zu nutzen sind keine speziellen Funktionen erforderlich. Es kann jedoch sein, dass bestimmte wünschenswerte Hardware-Features durch die Firmware aktiviert werden müssen.

Nach der regulären Firmware-Ausführung lädt ein Bootloader den Hypervisor, der dann die Hardware initialisiert und die verschiedenen Betriebssysteme in der gewählten Boot-Sequenz startet. Sowohl Bootloader als auch Hypervisor können so konfiguriert werden, dass sie für den Endbenutzer unsichtbar sind.

Der RTS Hypervisor unterstützt derzeit Microsoft Windows 10 und älter, Windows Embedded Compact, VxWorks, XENOMAI, TenAsys Intime distributed RTOS, RTOS-32, QNX, Linux, Echtzeit-Linux und T-Kernel. Eine Unterstützung anderer Betriebssysteme kann bei Bedarf jederzeit hinzugefügt werden. Unterschiedliche Betriebssysteme können in verschiedenen Ausführungsmodi gleichzeitig ausgeführt werden und jede Mischung aus SMP und Single-CPU, 32-Bit und 64-Bit ist möglich.

Betriebssysteme können jederzeit ohne unsere Hilfe aktualisiert werden, auch durch den Endanwender.

Wenn Ihr Betriebssystem, z.B. Microsoft Windows, eine Installation auf der Festplatte erfordert, können Sie zuerst das/die Betriebssystem(e) installieren und dann mit der Hypervisor-Installation fortfahren. Für den Fall, dass Betriebssysteme keine Installation auf der Festplatte erfordern, kann der RTS Hypervisor auch Betriebssystem Images direkt von einem vorgegebenen Speicherort laden.

Für die die jeweilige OS-Entwicklung können die vom OS Lieferanten vorgesehenen Tools verwendet werden. Für die Konfiguration des RTS Hypervisor sind keine Entwicklungswerkzeuge erforderlich.

Es können alle gängigen Debug-Tools und Schnittstellen verwendet werden. Dazu gehören Tools für das Kernel-Debugging sowie das Applikations-Debugging. Einzigartig am RTS Hypervisor ist die Möglichkeit, Ihr Echtzeit-Target z.B. von einem anderen Kern aus zu debuggen, der Windows parallel über das virtuelle Netzwerk ausführt. Es ist kein spezielles Tool oder Training erforderlich.

Keine, Sie können Geräte einem Betriebssystemen zur exklusiven Nutzung zuordnen und vorhandene Gerätetreiber dann unverändert verwenden.

Es können beliebige Standard-PCI- oder PCIe-Geräte exklusiv zugeordnet werden (Pass-Through). Geräte wie AHCI- oder xHCI-Controller können zwischen Betriebssystemen geteilt werden.

Ja, Pass-Through ist eigentlich der Standardzuweisungsmechanismus, der vom RTS Hypervisor verwendet wird. Speicher- und Geräteschutz wird durch MMU-Virtualisierung und IOMMU erreicht.

Ja, AHCI-Sharing erlaubt die Zuweisung von Laufwerken oder Festplattenpartitionen und xHCI-Sharing die Zuweisung von xHCI-Ports.

Da PCI- und PCIe-Geräte exklusiv zugewiesen werden und vorhandene Gerätetreiber verwendet werden können, kann jedes Feldbus- oder Echtzeit-Ethernet-Protokoll verwendet werden.

Es können alle Netzwerkgeräte zugeordnet und vorhandene Treiber und Protokolle, einschließlich TSN dann verwendet werden.

Über ein internes (TCP/IP) virtuelles Netzwerk oder ein inter-OS-Event-System.

Ja, wenn mehrere Speichercontroller vorhanden sind, können den Betriebssystemen individuelle Speicherknoten zugeordnet werden.

Der RTS Hypervisor basiert auf keiner anderen Software. Dies ist wichtig, da bestehende Lösungen wie KVM oder XEN für andere Anwendungsfälle konzipiert sind. Der RTS Hypervisor wurde ausschließlich von Real-Time Systems in Ravensburg entwickelt und unterliegt keinen Exportbeschränkungen.

Bei vollständiger Isolierung können einige Prozent Virtualisierungs-Overhead gemessen werden. Allerdings gilt es zu bedenken, dass die Ausführung mehrerer Betriebssysteme auf derselben Hardware, von denen jedes mit weniger CPUs und weniger verfügbarem Speicher ausgestattet ist, zu einer geringeren Gesamtleistung in einem Gastbetriebssystem führt im Vergleich zu einer nativen Betriebssystemausführung, bei der die gesamte Hardware verfügbar ist.

Der RTS Hypervisor verfügt über einen Ausführungsmodus, in dem keine Latenzen durch Virtualisierung hinzugefügt werden. In diesem Modus kann der Determinismus eines Betriebssystems sogar besser sein als ohne Hypervisor, wenn man bedenkt, dass der RTS Hypervisor Auswirkungen auf das Energiemanagement reduziert und eine Lastverteilung ermöglicht, d.h. Geräte, die nicht für die Echtzeitanwendung benötigt werden, können von einem anderen Betriebssystem bedient werden. Andererseits kann die Nutzung gemeinsamer Ressourcen auch Auswirkungen auf den Determinismus haben.

Desktop oder Server Betriebssysteme wie Windows oder Linux können in gewohnter Weise installiert werden. Die Installation des RTS Hypervisor ist lediglich eine Frage des Austausches des Bootloaders und des Einfügens einiger Dateien in das Dateisystem. Um unsere Kommunikationsmethoden und APIs nutzen zu können, müssen die zur Verfügung gestellten Treiber installiert werden.

Die Installation des RTS Hypervisors und die Erstkonfiguration ist eine Sache von Minuten und erfordert keine Schulung. Alle darüber hinausgehenden technischen Fragen werden von unserem Support-Team beantwortet.

Ja. APIs zum Überwachen, Starten, Stoppen und Neustarten von Betriebssystemen werden bereitgestellt und Berechtigungen können selektiv konfiguriert werden.

Die reale Grafik (GPU) kann einem Betriebssystem zur Verfügung gestellt werden (dies ist sogar die Voreinstellung) und der native Grafiktreiber mit all seinen Möglichkeiten kann verwendet werden.