Bild 1: Es existiert eine große Varianz an Virtualisierungs­lösungen. Für determini­stische Echtzeit-Anwendungen kommen nur Hypervisoren vom Typ 1 und die explizite Hardware-­Partionierung infrage. © Tenasys Europe

Wie Bild 1 zeigt, befinden sich am rechten Ende des Spektrums der sogenannte Hosted Hypervisor vom Typ 2, der auf der Basis eines bestimmten Hostbetriebssystems implementiert wird. Damit kann man eine vollständig virtualisierte Umgebung (Full VMM) abbilden, wie das zum Beispiel mit VMware oder VirtualBox möglich ist. Das Augenmerk dieser Virtualisierung ist primär darauf gerichtet, möglichst flexibel mehrere isolierte Applikations-Umgebungen auf derselben Hardware quasi simultan laufen lassen zu können, um verfügbare Hardware besser auszunutzen. Ein nicht deterministisch arbeitendes Host-Betriebssystem beeinflusst dabei maßgeblich das Zeitverhalten der Gastbetriebssysteme. In diesen IT-Umgebungen spielt ein zeitlich deterministisches Verhalten des Rechnersystems keine Rolle – hier steht die Systemkonsolidierung im Vordergrund. Damit scheidet diese Art des Hypervisors für die Anforderungen der embedded Virtualisierung grundsätzlich aus.

Nun ist es aber nicht damit getan, einen Hypervisor vom Typ 1 einzusetzen, um damit das gewünschte deterministische Verhalten zu erreichen. Auch hier gibt es keine Garantie für eine streng zyklische Verarbeitung. Denn wie die Host-basierten Hypervisoren zielen die meisten auch hier primär auf IT-Umgebungen ab. Typ-1-Hypervisoren werden auch gern als 'Bare Metal' bezeichnet, da diese ohne ein Hosting-Betriebssystem auf der jeweiligen Hardware installiert werden und somit ein Gast nur durch die Hypervisorschicht von der Hardware getrennt wird. Dabei werden CPU-Zyklen beliebig vom Hypervisor zugeteilt. Damit scheiden diese Typ-1-Hypervisoren für die Anforderungen der deterministischen Embedded-Applikationen allerdings aus.

Bild 2: Ein Hypervisor stellt eine Para-Virtuali­sierungs-Schnittstelle bereit, damit mehrere, heterogene Betriebssysteme auf einem gemein­samen System laufen können. © Tenasys Europe

Betrachtet man das Spektrum weiter, stößt man auf den deterministisch arbeitenden Hypervisor vom Typ 1. Hier gibt es zwei Klassen: Einerseits Hypervisoren, die alle verfügbaren Prozessorkerne verwalten (siehe Bild 2), und andererseits Hypervisoren, die gezielt einem bestimmten Gast-OS einen bestimmten CPU-Kern zuordnen können und den Rest des Systems nicht virtualisieren. Die erste Klasse wird von den meisten Anbietern realisiert. In ­beiden Fällen der deter­ministischen Hypervisoren ist eine CPU-Kern-Zu­ordnung zum Gast-OS implementiert, und auch die Zuteilung von Systemressourcen erfolgt exklusiv. Allerdings schränkt der Hypervisor die infrage kommenden Gastbetriebssysteme ein, da hier jeder Gast mit der Hypervisor-Schicht kooperieren muss, auf der er läuft. In diesem Fall kommen sehr häufig Para-Virtualisierungsmethoden zum Einsatz, um die Dienste innerhalb der Virtual Machine zu vereinfachen und damit die Latenzzeiten des 'Echtzeit-Gastes' zu minimieren. Diese Schnittstellen zur VMM-Kommunikation sind proprietär und erfordern einen nicht zu unterschätzenden Implementierungsaufwand im Gastsystem, der nicht in jedem Fall geleistet werden kann.

Bild 3: Bei der Hard-Realtime-Hypervisor-Techno-logie (HarTH) von Tenasys wird eine explizite Hardware-Partitionierung genutzt, um die CPU-Kerne unabhängig voneinander zu verwenden. © Tenasys Europe

Die zweite Klasse der Typ-1-Hypervisoren verfügt ebenfalls über die Gast-OS-CPU-Kern-Affinität und wird nur um diejenigen virtualisierten Dienste erweitert, die absolut notwendig sind, wie zum Beispiel den Zugriff auf ein zentrales Speichermedium oder einen virtualisierten Ethernet-Port. Echtzeit-kritische I/O-Geräte werden direkt an den Gast durchgereicht und können somit mit nativen Treibern gesteuert werden. Dieser Ansatz sorgt für die bestmögliche Echtzeit-Fähigkeit und den Determinismus des Gastes im laufenden Betrieb. Zudem unterstützen diese Hypervisoren nahezu jedes verfügbare Legacy-Echtzeit-Betriebssystem, zahlreiche Standardbetriebssysteme und auch proprietäre Betriebssysteme. Der große Vorteil dabei ist die Tatsache, dass Software-Anwendungen nicht an die virtualisierte Maschinenumgebung angepasst werden müssen. Darüber hinaus arbeitet Windows weiterhin vollkommen nativ ohne funktionale Einbußen durch das virtualisierte System.

Genau diesen Ansatz verfolgt beispielsweise Tenasys mit der Hypervisor-Technik namens HarTH. Das erste zugehörige Produkt ist seit 2010 unter dem Namen eVM für Windows ver­fügbar. Damit existiert ein Gast-OS auf  einem eigenen CPU-Kern parallel zum nativ laufenden Windows. Dies verdeutlicht Bild 3 anhand einer Linux-RT-Instanz innerhalb der virtuellen ­Maschine.

Die explizite Hardware-­Partitionierung

Bild 4: Die explizite Hardware-Partitionierung einer Betriebssystem-Umgebung mit Microsoft Windows und zwei Intime-RTOS-Instanzen auf einem Intel-Quadcore-Prozessor. © Tenasys Europe

Soll das Virtualisieren von Anwendungen mit der maximalen Rechenleistung erfolgen, kommt nur die explizite Hardware-Partitionierung infrage (siehe Bild 4). Hierfür sind allerdings zahlreiche Anpassungen am Echtzeit-Betriebssystem erforderlich, damit das Standardbetriebssystem und das RTOS bestmöglich koexistieren. Im Fall von Windows wird die Hardware-Partitionierung unter Einsatz von Standard-Windows-APIs erreicht. Das hat diverse Vorteile: Windows und RTOS laufen ohne jegliche Modifikationen auf den ihnen zugewiesenen Kernen. Derart virtualisierte Systeme sind ohne Hypervisoren sehr viel leistungsfähiger, da es keine Hypervisor-Schicht gibt, die Rechenzyklen verbraucht. Darüber hinaus verstößt man nicht gegen bestehende Lizenzregeln von Microsoft im Embedded-Bereich, da Windows weiterhin nativ auf dem Rechner ausgeführt wird.

Die explizite Hardware-Partitionierung wurde bereits 1997 eingeführt und ist somit seit mehr als 25 Jahren praxisbewährt. Das Unternehmen Tenasys etwa unterstützt mit seinem Echtzeit-Betriebssystem Intime dieses Konzept und nimmt dabei alle erforderlichen Anpassungen der sich ständig weiterentwickelnden Hardware- und Software-Plattformen vor. Dazu gehören auch die fortlaufende Unterstützung der Entwicklungsumgebung Microsoft Visual Studio und die Intime-APIs zur Erstellung der Windows-HMI- und In-time-Controller-Applikationen.

Interessante Mischformen

Daneben gibt es weitere interessante Kombinationen, die sich aus dem Einsatz von Typ-1-Hypervisor-Systemen und der expliziten Hardware-Partitionierung ergeben. Dazu gehört beispielsweise die Kombination aus einem Windows-basierten System, das keine Echtzeit-spezifischen Merkmale aufweist, und der expliziten Hardware-Partitionierung für eine Industrie-Anwendung wie eine Roboter-Steuerung und dem zusätzlichen Hosting einer weiteren Legacy-Applikation innerhalb einer Hypervisor-Umgebung vom Typ 1. Dies geschieht alles auf einem einzigen Rechner, der allerdings drei oder mehr Prozessorkerne aufweisen muss, was aber selbst mit heutigen Intel-Atom-Quadcore-Systemen kosteneffizient möglich ist.

Bild 5: Beim Hybridsystem können eine oder mehrere HarTH-Instanzen zum Beispiel für eine zusätzliche Linux-Firewall genutzt werden und das in Verbindung mit einer Windows- und Intime-Maschine. © Tenasys Europe

Aber auch ganz neue, konsolidierende Anwendungen sind mit solch einem hybriden Ansatz (siehe Bild 5) realisierbar. So lässt sich beispielsweise ein Standard-Windows-System durch eine virtualisierte Firewall-Applikation schützen, die parallel zu einer Windows-Installation läuft. Die Kommunikation zu Windows erfolgt lediglich auf Basis einer virtualisierten Ethernet-Verbindung zur Firewall, und die Windows-Applikationen sind durch die eigenständige Firewall gegen Cyber-Angriffe geschützt. Umgesetzt wurde dies beispielsweise in einer Firewall-Implementierung der Firma Innominate namens eVA (embedded Virtual Appliance). Das Resultat: Ein Windows-Rechner, der von einer leistungsfähigen Firewall gesichert wird, ohne dass zusätzliche Hardware-komponenten notwendig sind.

Beim Blick auf die vorhandenen Vir­tualisierungslösungen bleibt abschließend festzuhalten, dass im industriellen IT-Umfeld die passende Lösung vor allem den erforderlichen Grad der Echtzeit-Funktionalität bieten muss. Dementsprechend kommen Virtualisierungsanwendungen mit integriertem Hypervisor vom Typ 2 für RTOS-basierte Applikationen grundsätzlich nicht infrage. Hypervisor-basierte Lösungen vom Typ 1 hingegen können durchaus eine Alternative für Industrieanwendungen sein, wenn sie einerseits Echtzeit-Umgebungen unterstützen und andererseits übersichtliche Anpassungen an das Gastsystem verlangen. In diesem Fall ist allerdings mit ­Einschränkungen in Sachen Leistungs­fähigkeit und Investitionssicherheit zu rechnen.

Ist man auf die volle Leistungsfähigkeit des zugrundeliegenden ­Systems angewiesen und will man ­heterogene Anwendungen auf einer einzigen Plattform vereinen, so ist die ­explizite Hardware-Partitionierung im Vorteil. Sind obendrein wei­tere ­vorhandene Legacy-Lösungen zu integrieren, kommen zusätzliche ­Hypervisor-basierte Lösungen durchaus in Betracht. Und das alles auf ­Basis einer Rechnerarchitektur, die eine zukunftssichere Basis bildet und gleichzeitig die Anschaff­ungs- und Pflegekosten berechenbar hält.

Autor:
Kim Hartman ist Geschäftsführer bei Tenasys Europe.

Was ist ein Hypervisor?

Hypervisoren erlauben den Betrieb mehrerer Gastsysteme auf einem Hostsystem. Der Hypervisor verwaltet die Ressourcenzuteilung für einzelne Gastsysteme und verteilt die Hardware-Ressourcen derart, dass für jedes einzelne Gastbetriebssystem alle Ressourcen bei Bedarf verfügbar sind. Dies kann durch Hardware-Emulation, Hardware-­Virtualisierung oder Paravirtualisierung stattfinden. Den einzelnen Gastsystemen wird dabei jeweils ein eigener kompletter Rechner mit allen Hardware-Elementen (Prozessor, Laufwerke, Arbeitsspeicher usw.) vorgespielt.

Die tatsächlich vorhandene Hardware-Um­gebung wird als Hostsystem bezeichnet. Das gegebenenfalls darauf installierte Betriebs­system wird als Hostbetriebs­system bezeichnet. Die virtuelle Umgebung (oft auch als Virtuelle Maschine oder Gastsystem bezeichnet) mit dem installierten Gastbetriebssystem ist auf allen Hostsystemen lauffähig, auf denen der Hypervisor installiert beziehungsweise lauffähig ist. Es spielt dabei aus Sicht des Gastsystems keine Rolle, auf welcher ­Hardware-Umgebung der Hypervisor selbst installiert ist.

Die hardware-basierte Virtualisierung

Beide Typen der deterministisch arbeitenden Hypervisoren vom Typ 1 sind für Echtzeit-Umgebungen einsetzbar und machen sich Funktionen der hardware-basierten Virtualisierung zunutze. Intels VT-x ermöglicht es unter anderem, Adress-Offset-Berechnungen für einen Gast in Hardware zu vollziehen, was gerade dem Erhalt der Echtzeit-Fähigkeit eines virtualisierten Gastes sehr zuträglich ist. Falls aber bestimmte Chipsatz-Dienste wie zum Beispiel Intel VT-d zur I/O-Virtualisierung auf einer Plattform nicht vorhanden sind, müssen typischerweise Treiber des Gast­systems angepasst werden, was beispielsweise bei DMA-Operationen unabdingbar ist. Andernfalls kommt es zur Berechnung falscher Adressen, was zu Fehlern führen kann. Das ist zwar angesichts zahlreicher, vorhan­dener Treiberquellen für DMA-Geräte (oftmals Netzwerk-Controller) keine besondere Herausforderung, muss aber unbedingt berücksichtigt werden.