Zuverlässige Echtzeitsysteme
Das RODOS-Framework ist eine Implementierung der netzzentrierten Zentral-Avionik (Network Centric Core Avionics). Es besteht aus mehreren, miteinander abgestimmten Komponenten mit dem Ziel, eine zuverlässige Berechnungseinheit aus unzuverlässigen Komponenten zu implementieren. Diesem Ziel soll mit einem Prinzip begegnet werden, das die Welt längst vergessen hat: Einfachheit.
Einfachheit ist aber nicht gleichzusetzen mit einem Mangel an Funktionalität. Da die Wahrscheinlichkeit für Entwicklungsfehler mit der Komplexität steigt, ist eines der wichtigsten Entwurfsziele des RODOS-Frameworks die unreduzible, d.h. nicht weiter reduzierbare Komplexität. Darunter verstehen wir die kleinstmögliche Komplexität für eine bestimmte Funktionalität. Es ist also nicht mehr möglich, diese Funktionalität einfacher zu implementieren. Im RODOS-Framework ist ein mehrschichtiger Aufbau vorgesehen: Auf der untersten Ebene befinden sich die HW-Ressourcen (CPU, Speicher, …), die vom lokalen Echtzeit-Betriebssystem RODOS (Realtime Onboard Dependable Operating System) verwaltet werden. Darauf aufsetzend läuft die Middleware-Software, die die Kommunikation zwischen den verschiedenen Anwendungen, Komponenten oder sogar Geräten ausführt. Zur Kommunikation mit externen Einheiten, eingebetteten Systemen oder anderen Recheneinheiten bietet jeder Knoten eine Schnittstelle zum Netzwerk, implementiert in einem Gateway.
Das RODOS-Framework wurde in C++ entwickelt und stellt eine integrierte, objektorientierte Schnittstelle zur Ressourcenverwaltung und zum Netzwerk zur Verfügung. Es basiert auf wenigen Basisfunktionen, bei denen versucht wurde, die einfachste und kleinstmögliche Schnittstelle zu den Benutzeranwendungen bereitzustellen, wobei die erforderliche Funktionalität und Flexibilität beibehalten wird. Die in der RODOS-Middleware enthaltenen Verfahren zur Fehlertoleranz ermöglichen es uns, ein zuverlässiges System aus unzuverlässigen Komponenten aufzubauen. Unser Konzept beruht auf der Annahme, dass ein Hardwarefehler keine Ausnahme, sondern ein erwartetes Ereignis ist, das behandelt werden soll. Die interne Redundanzverwaltung unterstützt verschiedene Strategien, um die höchstmögliche Zuverlässigkeit tu implementieren.
Als Entwurfs-Paradigma kommt das Building Blocks- und Komponenten-Konzept zur Anwendung. Mehrere, einfache Building Blocks können in einem Computer- und Gerätenetzwerk mit Hilfe des netzwerkzentrierten Zentral-Avionik Protokolls verteilt und zusammengeschaltet werden. Komplexe Funktionalitäten können dann als ein Netzwerk von einfachen Modulen implementiert werden. Die Building Blocks können dabei unabhängig voneinander implementiert und getestet werden. Außerdem können einzelne Building Blocks ausgetauscht werden, ohne andere Building Blocks oder Schnittstellen modifizieren zu müssen.
In den folgenden Abschnitten werden die einzelnen Komponenten ausführlicher erklärt:
RODOS ist ein eingebettetes Echtzeit-Betriebssystem und wurde für Anwendungen entwickelt, die hohe Anforderungen an die Zuverlässigkeit benötigen. Es unterstützt alle fundamentalen Funktionen, die man von einem modernen Echtzeit-Betriebssystem erwarten kann. Darunter fallen Funktionen zur Ressourcenverwaltung, Threadsynchronisation- und kommunikation, I/O- und Interruptverwaltung. Desweiteren ist ein vollständig preemptiver Scheduler implementiert, der sowohl fixes, prioritätsbasiertes Scheduling als auch Round-Robin für Threads innerhalb derselben Prioritätsstufe unterstützt.
Die auf dem RODOS-Echtzeitkern implementierte Middleware realisiert die Kommunikation zwischen den Anwendungen und sogar zwischen Anwendungen und Hardwarekomponenten. Dabei sind die Software – Hardware und Rechner Grenzen transparent. Die Middleware implementiert ein asynchrones Publisher-Subscriber-Protokoll, wobei die Kommunikation über Nachrichtenaustausch erfolgt. In diesem Protokoll werden Nachrichten von einem Publisher unter einem bestimmten „Topic“ veröffentlicht. Ein Subscriber (0,1…, N) kann ein solches Topic abonnieren und erhält dadurch alle unter dem abonnierten Topic veröffentlichten Nachrichten.
Durch die Kapselung der Kommunikation in die Middleware spielt es keine Rolle, ob die Kommunikationspartner auf demselben oder auf verschiedenen Knoten laufen. Außerdem eines Knotens läuft die Kommunikation zwischen Software und Hardware nach demselben Verfahren ab. Es ist also beispielsweise möglich, dass eine Applikation auf einem Knoten mit einem I/O-Gerät auf einem anderen Knoten kommuniziert, ohne dass dieser Kommunikationspfad von einer lokalen Kommunikation abweicht. Erstere wird über das Netzwerk abgebildet, während letztere auf dem RODOS-Echtzeitkern erfolgt.
Mit diesem Verfahren lassen sich insbesondere auch TMR-Systeme (Triple Modular Redundancy) abbilden. Software auf verschiedenen Knoten können ihre Ergebnisse unter einem bestimmten Topic veröffentlichen. Es ist dabei nicht notwendig, dass die Knoten voneinander wissen. Eine (einfach aufgebaute) Entscheidungseinheit (Voter) kann dieses Topic dann abonnieren, um aus den veröffentlichten Ergebnissen das am wahrscheinlichten richtigen Ergebnis auszuwählen (Majorität).
Für mehr Informationen über das RODOS-Framework wenden Sie sich bitte an rodos@dlr.de