Bild 2. Die Zuteilung vorhandener PC-Ressourcen zu den Betriebssystemen erfolgt über ein grafisches Management Tool.

© acontis

Die Prozessor-Cores können auf un­terschiedliche Art und Weise aufgeteilt werden: Beim Shared Core-Betrieb teilt sich Windows und Linux ein Core, wobei Linux aus Echtzeit-Gründen die höhere Priorität hat und durch Echtzeit-Interrupts sofort aktiviert werden kann. Windows hingegen erhält nur dann Rechenzeit, wenn Linux freiwillig – etwa nach einem Interrupt oder in der Idle-Task – die Rechenzeit des Shared Core abgibt. Diese Betriebsart funktioniert auf x86 Singlecore-Prozessoren und auch auf Multicore-Prozessoren ohne Hardware-Virtualisierungsunterstützung beliebiger Hersteller,  was bei anderen am Markt verfügbaren Echtzeit-Virtualisierungslösungen meist nicht möglich ist.

Sollten weitere Cores vorhanden sein, so können diese konfigurierbar entweder von Windows oder von Linux verwendet werden (Bild 2). So können bei einem Quad-Core-Prozessor zwei Cores dem Windows und die anderen beiden Cores dem Linux zugeordnet werden. Ein Core für Windows und drei Cores für Linux beziehungsweise anders herum sind weitere Aufteilungsmöglichkeiten der Prozessor-Cores.

Bild 3. Devices und deren Interrupts lassen sich einfach verwalten.

© acontis

Soll harte Echtzeit mit maximalen Jitter bis hinunter in den Mikrosekundenbereich erreicht werden, sollten gewisse Prozessor-Eigenschaften wie Throtteling und andere Energiesparmaßnahmen oder auch Hyperthreading – meist im BIOS – abgeschaltet werden.
Die Realtime Virtual Machine stellt neben zwei Timern (System und Auxiliary) dem Linux eine Interrupt-Verwaltung zur Verfügung. Diese dient der Anmeldung, Abmeldung und der Bearbeitung von Echtzeit-Interrupts, welche von PCIe-Devices ausgelöst werden. Die Latenzzeiten des Interrupt- und Thread-Handling sind unter dem Echtzeit-Linux-Betriebssystem sehr kurz, was niedrige Zykluszeiten bis hinunter in den Bereich von 50 µs ermöglicht.

Zusätzlich zu den geteilten Ressourcen gibt es die Möglichkeit, exklusive Ressourcen zu bestimmen. Dies sind in der Regel PCI/PCIe-Devices, welche entweder nur vom Linux oder nur von Windows angesteuert werden. Die exklusiven Ressourcen für Linux werden von diesem durch direkte HW-Zugriffe genauso angesteuert, als ob Linux allein auf dem PC ablaufen würde. Dadurch können alle Gerätetreiber, welche für Linux existieren, ohne Änderung auch innerhalb der VM verwendet werden. Die Verwaltung und Konfiguration dieser exklusiven Ressourcen übernimmt das sogenannte Real Time Device Management innerhalb des RTVM. Für diejenigen Devices, welche Linux ansteuern soll, werden unter Windows Dummy-Driver installiert (Bild 3). Diese tun unter Windows gar nichts, sondern stellen nur sicher, dass der Windows-Plug&Play-Mechanismus zufriedengestellt wird und dass die Geräte-Ressourcen von Windows freigehalten werden.
 

Die Kommunikation

Mit den erwähnten Eigenschaften ist die Kombination aus Linux und Windows grundsätzlich funktionsfähig. Für die tägliche Praxis fehlt jedoch noch etwas Entscheidendes: Die Kommunikation zwischen Windows und Linux. Die RTVM bietet hierfür mehrere Mechanismen an: TCP/IP-Kommunikation, Zugriffe auf das Windows-Dateisystem, Datenaustausch über Shared Memory, Events, Pipes und Message Queues.

Die TCP/IP-Kommunikation wird durch Netzwerk-Treiber auf beiden Betriebssystem-Seiten realisiert, welche, statt einen realen Ethernet Controller anzusteuern, auf einem gemeinsamen Shared Memory arbeiten. Der Netzwerk-Treiber für Windows und der Linux-spezifische Treiber sind Bestandteil des LxWin-Produktes. Über dieses virtuelle Netzwerk lässt sich jegliche Art von UDP- und TCP/IP-Kommunikation auf Applikationsebene abwickeln, aber auch das Online-Debugging von Linux-Applikationen durch Visual Studio oder Eclipse unter Windows (Bild 4).

Bild 4. Neben Eclipse kann auch Microsoft Visual Studio unter Windows zur Linux-Software-Entwicklung verwendet ­werden.

© acontis

Die Kommunikation über mehrere Shared-Memory-Bereiche hinweg ist in der Größe und bezüglich der Zugriffsrechte per Konfiguration einstellbar. Durch entsprechende API-Aufrufe sowohl auf der Windows- als auch auf der Linux-Seite bekommen Applikationen auf User-Ebene direkte Pointer in das Shared Memory hinein und können darüber Daten austauschen. Unterstützt wird dies durch Interlocks, um Zugriffe auf gemeinsame Speicherbereiche zu synchronisieren (Spinlocks) und durch bidirektionale Events, also asynchrone Nachrichten, welche von einem Betriebssystem zum anderen geschickt werden. Dadurch kann eine Applikation dem Gegenpart auf dem anderen Betriebssystem signalisieren, dass sich Daten im Shared Memory geändert haben. Zusätzlich gibt es Mechanismen für komplexere Kommunikationsarten zwischen Linux und Windows wie etwa Pipes, Message Queues oder Real-time Sockets, welche intern alle auf Shared Memory und Events basieren. Zugriff auf das Windows Dateisystem von Linux aus ist ebenfalls möglich.

Die Verwendung der optional vorhandenen Hardware-Virtualisierungstechnologie VT-x in Intel-CPUs eröffnet weitere Optionen. So lässt sich dem Linux mehr als 4 GByte Speicher bereitstellen, wenn das 32 Bit Linux verwendet wird. Dies geschieht durch Einblenden beliebiger Speicherbereiche in den Adressraum des Linux. 

Bei 64 Bit Linux ist VT-x notwendig, um sich einzelne Cores mit Windows zu teilen. Windows wird dabei immer nur dann aktiviert, wenn Linux nichts mehr zu tun hat und in der Idle Loop angekommen ist. Windows läuft dabei also sozusagen in der Idle Loop des Linux.

Eine weitere Fähigkeit, welche durch VT-x ermög­licht wird, ist, einen fatal Linux crash abzufangen, sodass Windows völlig ungestört weiterläuft. Linux gelangt dabei in den Virtual Monitor Modus, anstatt das gesamte System neu zu booten. Die Aktivierung von VT-x ist ganz einfach und erfolgt über die grafische Oberfläche des mitgelieferten System-Manager-Tools. 

Kombination mit Ethercat, TSN und OPC UA

Eine echtzeitfähige IPC-basierte Steuerung nützt nur dann etwas, wenn mittels der Echtzeit entsprechende Sensoren und Aktoren angesteuert werden können. Dies geschieht heute meist über Feldbusse. Steht also Linux ein Standard Ethernet-Controller exklusiv zur Verfügung, kann der Ethercat Master Stack von Acontis diesen Ethernet-Controller in harter Echtzeit betreiben und darüber externe Ethercat-Slaves ansteuern. Dadurch werden Zykluszeiten bis hinunter zu 50 µs möglich. In Entwicklung befindet sich bereits die nächste Generation von echtzeitfähiger Netzwerk-Kommunikation in Form von TSN mit OPC UA Pub/Sub-Anbindung.

Autor: Heinrich Munz ist stiller Teilhaber von Acontis Technologies aus Ravensburg