DER INDUSTRIESTANDARD FÜR EINGEBETTETE SYSTEME IN AUTOMOBILANWENDUNGEN WIRD ERWEITERT UND VERBESSERT OSEK auf der Überholspur Die OSEK/VDX OS-Arbeitsgruppe veröffentlichte kürzlich den Entwurf zur Version 2.1 des Betriebssystems. Öffentliche Kommentare werden von der Arbeitsgruppe vor dem endgültigen Release der 2.1-Spezifikation im Sommer 2000 angenommen. Die neue Spezifikation kommt mit einer Reihe von Verbesserungen gegenüber der früheren Version 2.0 und bewahrt soweit wie möglich eine Rückwärtskompatibilität. DER AUTOR Prof. Dr. Ken Tindell ist Chief Technical Officer von Realogy und Chairman von NR- TA und beschäftigte sich in den letzten Jahren besonders mit dem Design von elektronischen Systemen für den Automobilbereich. Er leitete das Multiplex-Projekt- Team von Volvo bei der Entwicklung der neuen Generation verteilter Elektroniksysteme für den S80. Dr. Tindell ist Mitglied der OSEK OS Working Group, die für die Definition eines Betriebssystem-Standards in der Automobilindustrie verantwortlich ist. Er hat mehr als 30 Beiträge zu Echtzeitthemen verfaßt und ist per Email unter ktindell@realogy.com erreichbar. Die immer höheren Kosten für die Entwicklung, die Integration und den Produktionstest von Embedded Software für Automobilanwendungen haben sich innerhalb der letzten Jahre zu einem immer grösseren Problem entwickelt. Daraufhin wurde von der europäischen Automobilindustrie ein Standard initiiert, um offene Systemschnittstellen für die Fahrzeugelektronik zu produzieren. Das Projekt läuft unter der Bezeichnung OSEK/ VDX. OSEK ist ein Kürzel für Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug, VDX basiert auf einem französischen Standard (Vehicle Distributed executive) und wurde kürzlich mit OSEK verschmolzen. Das OSEK-Konsortium wird von einem Steering Committee geleitet, dem Vertreter der Firmen BMW, Bosch, DaimlerChrysler, Opel, Peugot, Renault, Siemens und Volkswagen sowie die Universität Karlsruhe angehören. Ein wesentliches Ziel dieser Aktivitäten ist es, die Entwicklung von kommerziellen Produkten zu fördern, die zu Industriestandards konform sind. Den Herstellern der elektronischen Steuereinheiten (ECUs) wird damit die Möglichkeit eröffnet, die nicht zu ihrem Kerngeschäft zählenden Tätigkeiten auszulagern und so Kosten zu sparen. Eine weitere Motivation ist die Beseitigung von Inkompatibilitäten bei der 78
THEMA Kommunikation zwischen den verschiedenen Steuergeräten, denn verschiedene Hersteller verwenden unterschiedliche Protokolle für den Informationstransfer über einen Kfz-internen Bus. Der Automobilhersteller muss jedoch für ein bestimmtes Modell eine Reihe von unterschiedlichen Steuergeräten zu einem einzigen Netzwerk integrieren. Für ihn ist es wichtig, aus dem Produktangebot einer möglichst grossen Anzahl an Zulieferanten auswählen zu können. OSEK-Strategie Das langfristige Ziel von OSEK ist es, die Portabilität und Wiederverwendbarkeit von Softwarekomponenten über eine Vielzahl von Projekten zu ermöglichen. Anbieter könnten sich dann auf sogenannte Automobil IPs (IP - Intellectual Property) spezialisieren, also auf reine Softwarelösungen, die dann auf jeder OSEK-kompatiblen ECU ablauffähig sind. Doch um dieses Ziel zu erreichen, sind sehr detaillierte Spezifikationen der einzelnen Schnittstellen erforderlich, die zu jeder nicht-anwendungsspezifischen Komponente gehören. Die OSEK-Standards beinhalten daher eine Anwendungsprogrammierschnittstelle (API), die die einzelnen Softwarekomponenten von der jeweiligen spezifischen Hardware und der Netzwerkkonfiguration im Automobil entkoppelt. Derzeit gibt es drei verschiedene OSEK- Standard-Spezifikationen: OSEK-NM, OSEK-COM und OSEK-OS (Bild 1). In OSEK-NM (Network Management) sind die Protokolle für die Verwaltung der Netzwerke im Automobil definiert. In Automobilanwendungen ist keine der ECUs eine Insellösung; der OSEK-COM-Standard berücksichtigt dies und soll garantieren, dass alle ECUs zusammen in einem effizienten System zusammenwirken. Eine Reihe von Firmen haben bereits OSEK-COM-konforme Kommunikations- Bild 1: Derzeit gibt es drei verschiedene OSEK- Standard-Spezifikationen: OSEK-NM, OSEK-COM und OSEK-OS. OSEK-COM (derzeitiger Releasestand 2.1 V2.2, veröffentlicht als Draft für Kommentare) definiert ein Protokoll für die Kommunikation zwischen den ECUs in Netzwerken, typischerweise auf der Basis von CAN. 79
Bild 2: Anwendungen und das erforderliche Zeitverhalten werden in einer Konfigurationsdatei beschrieben; diese wird dann von dem Analyseund Konfigurations-Tool (Time Compiler) interpretiert, der dann den Anwendungs-Code und die zugehörigen Datenstrukturen generiert. Der so erstellte Code und die entsprechenden Daten werden dann compiliert und mit der SSX5 Runtime Library gelinkt, um eine ausführbare Anwendung zu generieren. Treiber entwickelt. Dazu zählt z.b. die optionale COM-Treiberunterstützung für die Real-Time Architect Development und Deployment Suite von Realogy. Diese Implementierung der OSEK-Netzwerkunterstützung basiert auf der Software Volcano von der schwedischen Firma VCT und bietet das CAN-Multiplexing unter harten Echtzeitanforderungen. Die OSEK-COM-Software ergänzt damit den OSEK-OS-Kern in Realogy s Real-Time Architect. OSEK-OS Das OSEK-OS definiert eine Standard-Betriebssystemschnittstelle für Steuergeräte- Anwendungen im Automobil. Zusätzlich zur OSEK-OS-Spezifikation gibt es die standardisierte OSEK Implementation Language (OIL), mit deren Hilfe der Entwickler Details seiner Anwendung in einer speziellen Konfigurationsdatei spezifizieren kann. Ein OIL-Tool konfiguriert das Betriebssystem dann entsprechend der spezifizierten Anwendungsstruktur, so dass es auf die Anforderungen der Applikation zugeschnitten ist. Durch dieses Verfahren ergibt sich eine bessere Ausnutzung von ROM anstatt von RAM, denn die entsprechenden Daten werden offline berechnet und nicht zur Laufzeit. Dieses Feature ist ein wichtiger Faktor in Automobilanwendungen, da bei den hier eingesetzten Controllern im Verhältnis die RAM-Kosten sehr viel stärker als die ROM-Kosten berücksichtigt werden müssen. Die OSEK-OS-Spezifikation definiert vier sogenannte Konformitätsklassen, um das Betriebssystem entsprechend den Anforderungen der Anwendung skalieren zu können. Die Basis-Konformitätsklassen BCC1 und BCC2 (Basic Conformance Classes) entsprechen den Anforderungen von tief 80
THEMA WESENTLICHE ÄNDERUNGEN ZWISCHEN OSEK 2.0 UND 2.1 Das Betriebssystem ruft Error-Hooks nicht mehr rekursiv auf. Die Grundidee des Error-Hooks besteht in einem Aufruf, sobald das Betriebssystem einen Fehler erkennt (typischerweise einen Fehler in den Parametern eines API Calls). Damit kann der Hook korrigierend tätig werden und danach wird das Programm fortgesetzt. Auf diese Weise ist eine sehr gute Methode zum Auffangen von Fehlern definiert, da der Programmierer nicht den Return-Code jedes einzelnen API-Call testen muss. In der Spezifikation 2.0 war noch definiert, dass ein Fehler in der Code-Ausführung eines Error-Hooks selbst zu einem neuen Error-Hook-Call führt. Dies konnte rekursiv zu einer unendlichen Kette von Aufrufen führen. Interrupt Service Routinen (ISRs) nach Kategorie 3 sind nicht mehr vorgeschrieben. Die ISRs nach Kategorie 3 können auch OS- Calls ausführen. Grundsätzlich ist damit der Programmierer verantwortlich für die Vektorierung des Interrupts zu dem jeweiligen Handlercode in den OS-Aufrufen. Auf einigen Plattformen ist jedoch eine korrekte Implementierung unmöglich, da weder der EnterISR noch der LeaveISR anzeigen können, ob die ISR bereits einen anderen ISR unterbrochen hat oder nicht. Die neue Spezifikation 2.1 adressiert diesen Punkt durch die Definition, dass ISRs nach Kategorie 3 nicht vorgeschrieben sind. Wenn die Plattform die Kategorie 3-ISRs nicht sicher unterstützen kann, dann braucht der Anbieter des Betriebssystems die EnterISR und LeaveISR Calls nicht zu implementieren. Ein neuer und schneller Disable/Enable-Mechnismus für Interrupts wurde eingeführt. Erweiterungen der Interrupt API erlauben eine effizientere Implementierung des Interrupt Handlings auf einer Reihe von Prozessoren, die unterschiedliche Modelle für die Interrupt- Steuerung besitzen. Tasks und ISRs können sich nun Ressourcen teilen. Eine allgemeine Anforderung in jeder Applikation ist die gemeinsame Nutzung von Daten durch ISRs und Tasks. Nach Spezifikation 2.0 musste der Programmierer unterschiedlichen Code schreiben, je nachdem ob Daten nur von Tasks oder von Tasks und ISRs verwendet wurden. Das wird dann problematisch, wenn der Programmierer nicht weiss, ob später ein Task, eine ISR oder beide die von ihm definierten Daten benutzen werden. Die Spezifikation 2.1 sagt aus, dass Ressourcen von Tasks und ISRs genutzt werden können. Im Priority Ceiling Protocol wurde die Broken Lock -Gefahr eliminiert. Die Spezifikation 2.0 beinhaltete eine effiziente Variante des Priority Ceiling Protocols: Immediate Inheritance. Ein Nachteil bei der Spezifikation 2.0 besteht darin, dass durch eine verschachtelte Blockade von Ressourcen im Innern manchmal die äussere Blockade verloren gehen konnte. Die Spezifikation 2.1 beseitigt diese Gefahr durch die Festlegung, das der Aufruf der GetResource niemals die Priorität des aufrufenden Tasks herabsetzt. Diese Verbesserungen in der OSEK-Spezifikation 2.1 führen dazu, dass Entwickler von Betriebssystemen bessere Implementierungsstrategien einsetzen können, die zu erheblichen Gewinnen in der Laufzeiteffizienz führen und damit den Einsatz von Echtzeitbetriebssystemen auch in Low-End Systemen erlauben. Weiterhin fördert die neue Spezifikation die Produktion von OSEK-kompatiblen Produkten mit hoher Leistung auch für die harte Echtzeit ein kritischer Faktor in vielen Automobilanwendungen. eingebetteten ECUs in Automobilanwendungen, während die zwei erweiterten Konformitätsklassen ECC1 und ECC2 (Extended Conformance Classes) für die Unterstützung von anspruchsvollen Systemen wie z.b. Satelliten-Navigation entwickelt wurden, bei denen die Nutzung der Ressourcen (RAM, ROM und CPU-Zeit) nicht so kritisch ist. Jede der Konformitätsklassen kommt in zwei Ausprägungen: im standardmässigen und im erweiterten Status. Der Unterschied zwischen beiden liegt in der Anzahl der Laufzeit-Checks, die das Betriebssystem durchführt. Erweiterte Zustands-Checks sind sinnvoll während der frühen Entwicklungsphase, wenn die zusätzlichen Overheads solcher Laufzeit-Checks noch toleriert werden können. Im späteren Entwicklungsstand, nachdem alle Fehler in der Anwendung entfernt wurden, kann dann die standardmässige Zu- 81
standsüberprüfung eingesetzt werden. Sie ergibt die geringsten Overheads im System beim Übergang in die Massenproduktion und reduziert somit die gesamten Produktionskosten im Vergleich zum erweiterten Zustands-Check. OSEK Version 2.1 Die OSEK/VDX OS-Arbeitsgruppe veröffentlichte jetzt den Entwurf zur Version 2.1, die mit einer Reihe an Verbesserungen gegenüber der früheren Version 2.0 aufwartet, so z.b. die Verbesserungen der Effizienz des Systems sowie die Programmierung. Das erste Echtzeit-Betriebssystem, das zu OSEK 2.1 konform und auch verfügbar ist, wird als Teil des Real-Time Architect (RTA) von Realogy geliefert. Dieses Entwicklungstool für eingebettete Anwendungen setzt sich zusammen aus Offline-Tools und dem RTOS SSX5, einem Echtzeitkern, der zusammen mit der Applikation in die Zielhardware integriert wird. Die RTA-Tools unterstützen den Aufbau und die Analyse von Anwendungen, die auf diesem Laufzeitkern basieren. Der Entwicklungsprozess läuft als grober Überblick wie in Bild 2 dargestellt ab. Zwei OSEK-spezifische Komponenten gehören zu Real-Time Architect: ein OIL- Konfigurationstool sowie eine C-Quellcode-Bibliothek zur Implementierung der OSEK API. Die OSEK API von Realogy unterstützt die Konformitätsklasse BCC1 des OSEK OS basierend auf einer RAM-sparenden Single Stack Execution. Die OSEK API wurde mit der Vorgabe entwickelt, dass OS Aufrufe den Systemspeicher und die Prozessortaktzyklen extrem effizient nutzen und dass die Anwendungen zusätzlich auf korrektes Zeitverhalten hin analysiert werden können. Das OIL Konfigurationstool analysiert die OIL-Eingangsdateien und gibt kompakte Datenstrukturen als Repräsentation der definierten Objekte aus. Das Konfigurationstool optimiert auch den Code aus der C- Quellcode-Bibliothek für die jeweilige Anwendung, indem der Code auf die gestellten Anforderungen hin abgestimmt wird. Diese offline-konfiguration vermeidet redundanten Code und garantiert optimierten Speicherbedarf und minimale Overheads bei der Programmausführung. Realogy hat die OIL-Syntax erweitert, um die Nutzung aller Features des RTA Time Compilers zu ermöglichen. Dieses leistungsfähige Tool erzeugt hocheffiziente Anwendungssoftware mit voll verifiziertem Echtzeit-Verhalten. Mit Hilfe des Time Compilers ist es möglich, worst-case Antwortzeiten für jeden Task und alle Interrupt Handler in der Anwendung zu berechnen, und dabei werden auch Faktoren wie die Overheads des Betriebssystems, Blockierungen aufgrund von gesperrten Ressourcen oder Interrupt-Manipulation sowie Interferenzen von höher priorisierten Objekten berücksichtigt. Die Resultate lassen sich dann mit den vom Anwender definierten Deadlines vergleichen und alle potenziell nicht eingehaltenen Deadlines werden angezeigt. Die Zusammenarbeit zwischen der OSEK OS API und auch der nativen SSX5 API von Realogy wird unterstützt. Damit können zum einen reine OSEK/VDX-Softwaremodule erstellt werden oder aber auch solche mit einer erweiterten Funktionalität und Performance auf Basis der nativen Syntax des Time Compilers und der SSX5 API Calls. Entwickler haben damit einen hohen Grad an Flexibilität beim Abwägen zwischen Portabilität und Leistungsfähigkeit. Abschließend sei gesagt, dass die OSEK/ VDX-Standards einen wichtigen Schritt vorwärts in der Automobilelektronik markieren. In den kommenden Jahren wird die Anzahl an elektronischen Systemen im Automobil auf Basis von ECUs stark ansteigen. Jeder Standard, der die Wiederverwendung sowie die einfache Kommunikation zwischen ECUs ermöglicht und fördert, hilft der Industrie entscheidend weiter. Der Standard allein ist jedoch nicht ausreichend: Jedes den OSEK-Standards entsprechende Produkt muss auch effizient und zuverlässig sein, um in der Massenproduktion für Automobilsysteme eingesetzt zu werden. Die neue Spezifikation 2.1 kann von der OSEK/VDX-Webseite unter www.osekvdx.org heruntergeladen werden Weitere Informationen zu den Entwicklungstools von Realogy erhalten Sie über die Kennziffer. 331 82