Kriterien zur Betriebssystem-Auswahl für zeitkritische Anwendungen
Das optimale Betriebssystem für FlexRay
FlexRay wird je nach Anwendung wegen des deterministischen Verhaltens oder wegen der schnellen Datenübermittlung eingeführt. Die Nutzung für sicherheitsrelevante Anwendungen spielt derzeit nur eine geringe Rolle. Für die Entscheidung, welches Betriebssystem in Verbindung mit FlexRay eingesetzt werden soll, sind neben Deterministik und Performance weitere Kriterien wie Speicherschutz oder Zeitüberwachung zu berücksichtigen. Der Beitrag erläutert, worauf es bei der Wahl des Betriebssystems ankommt, und zeigt konkrete Lösungen, die Vector Informatik auch im Rahmen von AUTOSAR anbietet.
Kriterien zur Betriebssystem-Auswahl für zeitkritische Anwendungen
FlexRay wird je nach Anwendung wegen des deterministischen Verhaltens oder wegen der schnellen Datenübermittlung eingeführt. Die Nutzung für sicherheitsrelevante Anwendungen spielt derzeit nur eine geringe Rolle. Für die Entscheidung, welches Betriebssystem in Verbindung mit FlexRay eingesetzt werden soll, sind neben Deterministik und Performance weitere Kriterien wie Speicherschutz oder Zeitüberwachung zu berücksichtigen. Der Beitrag erläutert, worauf es bei der Wahl des Betriebssystems ankommt, und zeigt konkrete Lösungen, die Vector Informatik auch im Rahmen von AUTOSAR anbietet.
Jobangebote+ passend zum Thema
Als skalierbares Highspeed-Kommunikationssystem mit deterministischem Verhalten ist FlexRay die passende Lösung als Data-Backbone für verteilte Regelungen oder sicherheitsrelevante Anwendungen im Automobil-Bereich. Im Gegensatz zur ereignisgesteuerten Kommunikation über CAN werden alle Botschaften einem festen Kommunikationsraster zugeordnet. Daraus ergibt sich für jedes beteiligte Steuergerät eine zeitlich eindeutige Verfügbarkeit der Eingangsdaten. Der Entwurf eines FlexRay-Netzwerkes erfordert bereits in einer sehr frühen Entwicklungsphase grundlegende Festlegungen wie Baudrate, Zykluslänge, Anzahl und Länge der Slots im statischen und dynamischen Segment bzw. Macrotick-Dauer für alle beteiligten Netzwerkknoten. Diese Planung der Kommunikationsabläufe ist in den kommunikationsspezifischen Software-Komponenten abgebildet, sie kann aber auch Einfluss auf die zeitliche Gestaltung der Anwendungs-Software haben.
Das Betriebssystem (OS) sorgt für das Zusammenspiel aller beteiligten Software-Komponenten. Zur Verfügung stehen ereignisgesteuerte (event triggered) oder zeitgesteuerte (time triggered) Betriebssysteme mit jeweils unterschiedlichen Diensten. Als weitere Option sind Betriebssysteme mit Speicherschutz verfügbar. Bei der Auswahl des optimalen Betriebssystems für FlexRay-basierte Anwendungen stellt sich insbesondere die Frage, ob ein zeitgesteuertes Betriebssystem für die synchronisierte Kommunikation über FlexRay zwingend erforderlich ist.
Ereignisgesteuerte und zeitgesteuerte Betriebssysteme
Bisher wurden im Automobilbereich meist ereignisgesteuerte Betriebssysteme eingesetzt. Dabei genießt das OSEK/VDX-OS [1], das künftig auch in einer ISO-Norm vorliegen soll, die breiteste Akzeptanz. Ziel eines Betriebssystems ist es, unter optimaler Nutzung der verwendeten Hardware eine zusätzliche Laufzeitumgebung zur Verwaltung von Funktionseinheiten bereitzustellen. Definierte Betriebssystem-Dienste bieten diese Funktionalität an. Beim Design einer Anwendung werden zunächst zeitlich unabhängige Teilaufgaben definiert. Die daraus resultierenden Tasks oder Interrupts konkurrieren gemäß dem Scheduling-Algorithmus des Betriebssystems um die Laufzeitzuweisung:
- Tasks werden durch Alarme oder Ereignisse (Events) ausgelöst. Dabei werden Extended Tasks und Basic Tasks unterschieden. Extended Tasks zeichnen sich durch die Fähigkeit aus, auf Ereignisse warten zu können.
- Interrupt Services Routinen (ISR) sind Hardware-spezifisch und werden durch die Hardware-Peripherie getriggert. Sie haben höhere Priorität als Tasks und sollen deshalb nur für Teilaufgaben reserviert werden, die eine möglichst schnelle Reaktionszeit erfordern.
Bei einem zeitgesteuerten Betriebssystem sind sämtliche Abläufe und Aktionen unter der Kontrolle des Betriebssystems ausschließlich abhängig von der Zeit. Für die Applikation ergibt sich damit ein streng deterministisches Zeitverhalten.
AUTOSAR-OS
AUTOSAR hat das OSEK-OS als Basis genommen und erweitert, so dass auch zeitgesteuerte Funktionalitäten unterstützt werden können. In vier Ausbaustufen, den so genannten Scalability Classes (SC), werden die spezifischen Eigenschaften des AUTOSAR-OS [2] zur Verfügung gestellt. Die Tabelle stellt einen Überblick ihrer Zuordnung zu den Scalability Classes dar. Es sind nur die Eigenschaften eingetragen, die im Zusammenhang mit einer FlexRay-basierten Anwendung von Bedeutung sind. Die derzeit verfügbaren Spezifikationen von BSW (Basic Software) und RTE (Runtime Environment) decken Speicherschutz noch nicht ab. Dies wird in zukünftigen Versionen der BSW- und RTE-Spezifikationen nachgezogen.
Schedule Tables
Das Betriebssystem verwaltet mehrere Schedule Tables. Jede Schedule Table besteht aus einer Liste von zeitlich definierten Aktionen, die entweder Tasks aktivieren oder Events an Tasks verschicken.
Bei einem Echtzeit-System kommt es darauf an, alle Aufgaben rechtzeitig abzuarbeiten. In der Entwurfsphase werden Teilaufgaben festen Zeitfenstern zugeordnet. Damit zur Laufzeit keine Verzögerung entsteht, darf eine Aufgabe die CPU nicht länger in Anspruch nehmen, als im Design vorgegeben. Deshalb überwacht das Betriebssystem die Laufzeit jeder einzelnen Task bzw. jedes Interrupts. OSEKtime [3] sieht dafür ein klassisches Deadline Monitoring vor: Tasks müssen fertig sein, bevor ihre zugeordnete Deadline erreicht ist. Liegt eine Verletzung vor, löst das gesamte System ein Reset aus. Bei Extended Tasks, die auf Events warten können, ist diese Art von Überwachung nicht ausreichend. Deshalb hat die AUTOSAR-OS-Arbeitsgruppe eine Laufzeitüberwachung für jede einzelne Task und jeden Interrupt definiert. Sie wird mit unterschiedlichen Parametern im Konfigurator festgelegt.
- Für jede Task wird der Timeframe (Überwachungszeitraum) und das Execution Time Budget (maximale Ausführungszeit pro Überwachungszeitraum) definiert. Soll im Konfigurator des Betriebssystems die Mehrfachaktivierung einer Basic Task zugelassen sein, beinhaltet das Execution Budget die gesamte Laufzeit aller Aktivierungen der betroffenen Task. Bei Extended Tasks sind grundsätzlich keine Mehrfachaktivierungen möglich.
- Für jeden Interrupt sind der Überwachungszeitraum, die „Worst Case Execution Time per Execution“ und die maximale Anzahl von Interrupts pro Überwachungszeitraum zu definieren. Je Timeframe können mehrere Interrupts zugelassen werden, die Worst Case Execution Time bezieht sich aber nur auf einen einzigen Durchlauf.
Bei Verletzung eines Überwachungsparameters leitet das Betriebssystem je nach Konfiguration entweder ein „Reset_OS“, „Kill_Application“, „Kill_Task“ oder „Kill_Interrupt“ als Fehlerreaktion ein.
Bild 1 zeigt die Überwachung einer Anwendung, bestehend aus einer Extended Task, die von einem Interrupt mehrmals unterbrochen wird. Wegen einer längeren Laufzeit der Extended Task, z.B. für die Behandlung des Events 1 (Ev1) kann es zur Fehlerbehandlung kommen (Bild 2). Diese betrifft ausschließlich den Verursacher. Die Zeitüberwachung garantiert je nach Budget Tasks und Interrupts mit niedriger Priorität den Zugang zum Prozessor für die Abwicklung ihrer Aufgabe.
Sollte wie in Bild 3 ein Interrupt zu lange dauern, wird dieser abgebrochen damit die Extended Task weiterlaufen kann. Die Bilder 1 bis 3 stellen ein AUTOSAR-OS der Scalability Class 2 mit Zeitüberwachungs-Tasks und Interrupts dar.
- Das optimale Betriebssystem für FlexRay
- Synchronisierung über Globalzeit
- Das optimale Betriebssystem für FlexRay
