Von Andreas Reinhardt

Multithreading, Networking, State-of-the-art-Visualisierung – alles Features aus der PC-Welt, die heute auch im Umfeld von Maschinen und Robotern gefragt sind. Wichtigste Voraussetzung dafür: die Verbindung von Echtzeit-Fähigkeit mit Standard-Betriebssystemen wie Windows und Linux. Kein leichtes Unterfangen, zumal Standard- und Echtzeit-Betriebssysteme sehr unterschiedliche, zum Teil konkurrierende Anforderungen erfüllen müssen. Das eine ist von der Struktur her auf Durchsatz getrimmt, soll also möglichst effizient viele Daten bearbeiten und transferieren können, wie das beispielsweise bei Server- oder Streaming-Data-Anwendungen der Fall ist.

Die Bearbeitung von Aufträgen erfolgt bei durchsatzorientierten Betriebssystemen stets nach dem Prinzip „shortest remaining time first“, also das Begonnene wird möglichst zuerst fertig gestellt, bevor ein anderer Job angefangen wird. Diese Strategie des Schedulers lässt sich nur bedingt beeinflussen. Reaktionsschnelligkeit ist für diese Aufgaben nicht erforderlich, sondern eher hinderlich, da die Effizienz der Abarbeitung sinkt.

Ein Echtzeit-Betriebssystem hingegen arbeitet nach der Devise „highest priority first“. Es verfolgt also grundsätzlich die Strategie, auf Ereignisse (Interrupts aus dem E/A-Bereich wie Endschalter, Fehlersensor, Alarm, abgelaufene Zeit, Kommunikationspakete) unmittelbar zu reagieren, damit ein Prozess deterministisch (vorhersagbar) ablaufen kann. Ein Echtzeit-System muss dabei nicht notwendigerweise schnell sein. Es muss vielmehr in der Lage sein, in dem geforderten Zeitrahmen zu reagieren (= reaktives Betriebssystem) – und das zu jedem Zeitpunkt und absolut zuverlässig. Situationen, wie wir sie von unseren Windows-PCs kennen – etwa dass wegen eines Kopiervorgangs auf der Festplatte für kurze Zeit die Bewegung des Mauszeigers stockt –, sind beispielsweise für den ruckfreien Transport von flüssigem Aluminium völlig inakzeptabel, weil gefährlich für Mensch und Maschine.

Um den vielfältigen Anforderungen von komplexen Maschinen gerecht zu werden, kam in den Anfängen der PC-basierten Automation oft eine Kombination von zwei unterschiedlichen Rechnern zum Einsatz: ein PC für die Mensch-Maschine-Interaktion und dazu eine Spezialhardware, auf der ein Echtzeit-Betriebssystem den Prozess regelt. Heute ist die Formel „ein Rechner – zwei Betriebssysteme“ sowohl für Windows als auch für Linux state-of-the-art. Die Realisierung des Echtzeit-Parts erfolgt dabei meist über 2-Kernel-Lösungen wie RTX, RTCore, Xenomai oder auch durch Veränderung des Standard-Kernels.

Dabei teilen sich PC- und Echtzeit-Betriebssystem die Ressourcen des Rechners. Um eine zuverlässige Echtzeit zu erreichen, sind die beiden Hemisphären strikt getrennt: Eingebaute Interrupt-Sperren und Prioritäten-Grenzen sorgen dafür, dass die Steuerung immer und ausnahmslos zum Zug kommt und vorhersagbar auf die Prozessparameter reagiert. Das Standard-Betriebssystem bekommt Ressourcen und Rechenzeit, wenn alle Steuerungsaufgaben erledigt sind und das Echtzeit-System in die Idle-Task abgibt. Selbst die Task mit niedrigster Priorität in der Steuerung hat Vorrang gegenüber der höchstprioren Task im Standard-Betriebssystem.

Echtzeit und Nicht-Echtzeit

Mit diesem Ansatz sind zwar die beiden Welten – Echtzeit und Nicht-Echtzeit – auf einem Rechner koexistent, jedoch aufgrund der Sperren noch immer nicht optimal verbunden. So kann es nach wie vor passieren, dass sich eine in Windows beziehungsweise Linux verfügbare Infrastruktur nicht im Echtzeit-Kontext nutzen lässt. Ein Echtzeit-Ethernetbus beispielsweise wäre in der Lage, sowohl Prozesskommunikation als auch Standard-IP-Verkehr über das gleiche Kabel zu transportieren. Aufgrund der softwareseitigen Trennung der beiden Betriebssysteme ist er jeweils in einem der beiden Subsysteme nur mit Einschränkungen oder überhaupt nicht nutzbar (siehe Bild 1).

Angesichts dieser Mankos hat Keba es sich zum Ziel gesetzt, die harten Grenzen zwischen den Betriebssystemen durchlässig zu machen und somit auch Windows- beziehungsweise Linux-Standardtreiber im Echtzeit-Kontext nutzen zu können. Herausgekommen ist mit KemroRT eine Technologie, bei der sich der Anwender nicht mehr mit zwei Klassen von Prioritäten abfinden muss, sondern diese sowohl für die Echtzeit- als auch für die Standard-Applikation frei vergeben kann.

Die Prioritäten von Steuerung und allen anderen „Mitspielern“ im System lassen sich je nach Anforderung verschachteln, ohne dabei die Echtzeit-Fähigkeit zu verlieren. Mit einfachen und im Standard-Betriebssystem vielfach verfügbaren Analysetools lässt sich das Systemverhalten schnell überprüfen und so die Vorhersagbarkeit sicherstellen. Eine weitere Verbesserung gegenüber bisherigen Lösungen ist die gemeinsame Nutzung von interruptfähigen Geräten sowohl im Echtzeit-Kontext als auch im Standard-Betriebssystem.

Statt strikter Trennung der Interrupts von Echtzeit- und Nicht-Echtzeit-Geräten bietet die Echtzeit-Erweiterung KemroRT flexible Prioritäten und Interrupt-Management. Das heißt: Das System ist offen für alle Interrupts, die Prioritäten lassen sich je nach Anforderung frei vergeben.

Konkret wurde für die Keba-Echtzeit-Erweiterung ein spezielles Interrupt-System entwickelt, welches übergreifend mit Shared Interrupts zurechtkommt. Jeder Interrupt wird vor der Rückkehr aus dem Interrupt-System analysiert und einer Nachbehandlung unterzogen. So stellt das Betriebssystem fest, ob die Benachrichtigung durch den Interrupt echtzeitrelevant ist oder nicht. KemroRT nutzt also bei der Interrupt-Behandlung quasi eine Rückkopplungsschleife zwischen den verschiedenen Tasks, um über deren Echtzeit-Relevanz zu entscheiden. Diese zusätzliche Funktion hebt letztlich die strikte Trennung zwischen der Steuerung und zeitlich unkritischen Applikationen auf.

Kommunikationskarten in IPC-Systemen lassen sich auf diese Weise steckplatzunabhängig betreiben, ohne dass Überschneidungen der Interrupt-Ressourcen zu zeitkritischen Beeinflussungen führen (siehe Bild 2).

Was bringt eine solche Lösung in der Praxis? Zum Beispiel ermöglichen die Eigenschaften der freien Interruptund Prioritätenvergabe die Nutzung einer USB-Tastatur als Standard-Eingabegerät für die Windows-Visualisierung (nicht echtzeitrelevant) und gleichzeitig das Verfahren der Maschine oder des Roboters in Echtzeit unter Verwendung des Windows-USB-Treibers. Damit ist vermeidbar, dass für wenige echtzeitrelevante Bedientasten – etwa Start/Stop – eine zusätzliche echtzeit-fähige Kommunikationsverbindung vom Bedienpanel zur Steuerung vorgesehen werden muss.

Im Falle von Steuerungsanwendungen mit hohem Vernetzungsgrad funktionieren uneingeschränkt mehrere Kommunikationskarten (Sercos-III-Master, Profibus-Slave, ASi-Master, serielle Schnittstellenkarte) ohne durch Shared Interrups mit Standard-PC-Schnittstellen Steckplatzabhängigkeiten berücksichten zu müssen. Ein Umstieg auf die nächste IPC-Generation oder die Zusammenarbeit mit einem neuen Hardware-Lieferanten führen somit zu keinerlei Software-Änderungen mit nachgeschalteter aufwendiger Stabilisierung und Verifikation.

Diese Offenheit ermöglicht eine weitgehende Unabhängigkeit des Software-Systems von der zur Verfügung stehenden Hardware und die Nutzung der vielfältigen Treiber-Infrastruktur eines modernen Standard-Betriebssystems. Der Anwender ist damit in der Lage, ohne Portierungsaufwand auf die nächste Generation von Steuerungshardware umzusteigen, sich aus der Herstellerabhängigkeit vom Hardware-Lieferanten zu lösen und auch noch neue Technologien, die in den meisten Fällen in Echtzeit-Systemen nicht oder mit großer zeitlicher Verzögerung unterstützt werden, einzusetzen.

Oder anders ausgedrückt: Den Maschinenbauern steht mit KemroRT eine Echtzeit-Erweiterung zur Verfügung, die komplett in einer Standard-Entwicklungsumgebung programmierbar ist, für die es hervorragende Entwicklungswerkzeuge gibt und welche die komplette Funktionalität von PCProgrammen wie Visual Studio oder Eclipse auch an der Maschine bietet. Darüber hinaus sind vom Treiber über den Steckplatz bis zum Netzwerkkabel Standard-PC-Komponenten einsetzbar, wodurch die volle Portierbarkeit der Hardware- und Software-Komponenten auf das „Next Generation Board“ und ein langfristiger Investitionsschutz sichergestellt sind.

Autor: Andreas Reinhardt ist Leiter der Abteilung Steuerungsentwicklung bei der Firma Keba in Linz, Österreich.