Das Beste zweier Welten: OSEK/VDX und Windows CE auf einem Mikrocontroller

Transkript

1 Das Beste zweier Welten: OEK/VDX und auf einem Mikrocontroller Jochen choof, Markus Zetlmeisl 3OFT GmbH, Erlangen Einleitung Die Elektronik hat in den vergangenen Jahren auf breiter Front Einzug in Kraftfahrzeuge gehalten. Moderne Fahrzeuge nutzen heute eine Vielzahl von Mikroprozessoren für verschiedenste Aufgaben. o gibt beispielsweise PA an, der aktuelle Peugeot 607 nutze ebensoviel Elektronik und oftware wie der Airbus A310 von Die elektronischen Geräte lassen sich grob in zwei Gruppen aufteilen. Dies sind der teuergeräte-ektor auf der einen und der nfotainment- oder Telematik-Bereich auf der anderen eite (Bild 1). Beispiele für teuergeräte sind etwa elektronische Fensterheber, verstellbare Außenspiegel und Airbags sowie die Motor- oder Fahrwerk-teuerung. Zu den nfotainment-diensten gehört der klassische Bordcomputer mit Tacho- Funktionen und pritverbrauchs- Berechnung ebenso wie moderne Navigationssysteme, nternet-radios oder die Einbindung externer Geräte wie PDAs. teuergeräte und nfotainment- ysteme Diese beiden Gruppen von Geräten unterscheiden sich nicht nur in den Funktionen, sondern auch bei Hardund oftware deutlich. n teuergeräten können kleine und kostengünstige Controller zum Einsatz kommen, während nfotainment-geräte schon auf Grund der Anforderungen an die Darstellung der nformationen mit leistungsfähigen Prozessoren und vergleichsweise viel peicher ausgerüstet sind. Das typische teuergerät im Fahrzeug-nnenraum nutzt heute einen 16-Bit Mikrocontroller mit 64 Kilobyte ROM und 2 Kilobyte RAM, der für niedrige einstellige Euro- Beträge zu haben ist. Etwas mehr Leistung ist bei Motor- und Fahrwerk- teuerung anzutreffen. Hier kommen bereits 32-Bit ysteme zum Einsatz. Der peicher bewegt sich zwischen 256 und 512 Kilobyte. Ganz anders sieht es im nfotainment-bereich aus: Hier werden ysteme eingesetzt, die den Vergleich mit zu Beginn der neunziger Jahre handelsüblichen PCs nicht zu scheuen brauchen. 32-Bit Prozessoren sind die Regel und der peicher wird meist in Megabyte gemessen. G G nfotainment-geräte mit Bus (z.b. MOT) Gateway zur Verknüpfung zweier Busse teuergeräte mit Bus (z.b. CAN) Bild 1: Ein Fahrzeug-Netzwerk mit nfotainment- und teuergeräten Entsprechend unterscheidet sich die oftware für die Gerätegruppen. Für den nfotainment-bereich steht eine größere Zahl erprobter Betriebssysteme zur Verfügung, die die Applikationsentwicklung erleichtern. Zu nennen sind hier insbesondere von Microsoft, VxWorks von WindRiver und QNX von QNX oftware. Für die in teuergeräten eingesetzten Prozessoren gab es vor wenigen

2 Jahren entweder gar keine kommerziellen Betriebssystem oder diese waren nur für einzelne Controller verfügbar. Daher schuf die Automobilindustrie als einer der Hauptanwender dieser Prozessoren einen eigenen Betriebssystem- tandard, der speziell auf diese Hardware ausgerichtet war. Unter dem Namen OEK/VDX ist dieser tandard heute marktbekannt und wird inzwischen von vielen Herstellern als Basis der teuergeräte-oftware zwingend vorgeschrieben. Da es sich um einen offenen tandard handelt, gibt es eine ganze Reihe von Anbietern entsprechender Betriebssysteme. Die tatsächliche Übereinstimmung mit den Vorgaben des tandards wird durch eine eigens geschaffene Zertifizierung überprüft. Nur bei Bestehen dieser Zertifizierung darf sich ein Produkt OEK/VDXkonform nennen. tatus Quo Wir finden heute also die ituation vor, dass zwar für die eher kleineren Geräte ein tandard durchgesetzt ist, bei den leistungsfähigeren Geräten aber einige konkurrierende Ansätze marktpräsent sind. Kurzfristig kann hier auch kaum mit einer Änderung gerechnet werden. Es gibt zwar auch hier tandardisierungsbemühungen, doch setzen diese meist oberhalb des Betriebssystems an. Hinzu kommen noch tandardisierungen, die beide Gruppen betreffen. Typisches Beispiel hierfür ist die fahrzeugweite Kommunikation der verschiedenen Geräte über normierte Protokolle. n jüngster Zeit ist wieder deutlich ein Trend zur Konzentration von Funktionen zu verspüren. Es wird nicht mehr für jede neue Aufgabe ein neues teuergerät entwickelt. Vielmehr ist man bestrebt, freie Kapazitäten auf ohnehin vorhandenen Geräten bestmöglich auszunutzen. Bedingt durch die benötigten Hardware- Ressourcen ist die dee naheliegend, die Funktionen kleinerer teuergeräte auf einem leistungsfähigen nfotainment-gerät unterzubringen, das noch nicht ausgelastet ist. Häufig ist diese oftware aber bereits für den Einsatz mit einem OEK/VDXkonformen Betriebssystem entworfen und implementiert. Wie kann man nun diese beiden Welten zusammenbringen? Zwei Welten auf einem Mikrocontroller Diese Frage wurde am Beispiel der Kombination mit näher untersucht. Eine Umsetzung mit den anderen zuvor genannten Betriebssystemen ist ebenso denkbar. Als OEK/VDX-ystem wurde ProOEK aus dem Hause 3OFT benutzt. Dieses zertifizierte OEK hat seine Tauglichkeit für den praktischen Einsatz in der neuen 7er-Reihe von BMW unter Beweis gestellt, wo es in der Mehrzahl der teuergeräte als Basis des BMW tandard Core zum Einsatz kommt. Als zweites Betriebssystem wurde for Automotive 3.5, d.h. die Variante von 3.0 für den Automobilbereich gewählt. Zunächst muss man sich über die Anforderungen an das Zusammenspiel der beiden ysteme klar werden. Für die ntegration standen die folgenden Vorgaben im Vordergrund: volle Funktionalität beider Betriebssysteme Echtzeitfähigkeit Entkopplung aus Anwenderund ystemsicht Einfache Portierung von Anwendungen minimaler Overhead durch Parallelisierung einfache Portierbarkeit des Gesamtsystems

3 ntegration in die ProOEK- Entwicklungsumgebung Definition einer chnittstelle zur Kooperation/ynchronisation Vorgehen bei der ntegration Eine einfache Lösung wäre die mplementierung eines so genannten Wrappers. Dabei handelt es sich um eine ammlung von Funktionen, die die AP von OEK/VDX nachbilden, die Funktionalität aber einfach aus entsprechenden Routinen von beziehen. Mit diesem Ansatz würden aber wesentliche Vorteile von OEK/VDX verloren gehen. Außerdem sind einzelne spezielle Funktionen so nicht ohne weiteres nachbildbar. Ein weiterer Ansatz wäre der Betrieb von auf OEK/VDX, d.h. läuft als dle-task von ProOEK, ähnlich den Realtime- Erweiterungen für Linux oder Windows NT. Zwar benötigt Windows CE einen Prozessor mit MMU (peicherschutz). Da OEK/VDX diesbezüglich aber keine Anforderungen hat, können beide Betriebssysteme parallel betrieben werden, ohne sich zu stören. Diese Lösung bietet eine optimale Trennung beider ysteme, ist jedoch stark hardware-abhängig. Für jeden Prozessor und jede Plattform ist zum Beispiel neu anzupassen, wie nterrupts von OEK/VDX an Windows CE zur Bearbeitung weitergereicht werden. Da derartige Anpassungen mit erheblichem Aufwand verbunden sein können, wurde diese Variante nicht weiterverfolgt. Daher wurde eine Vorgehensweise ausgewählt, die ProOEK im wesentlichen für auf beliebigen Plattformen nutzbar macht. Das bedeutet, dass das gesamte ProOEK-ystem als ein Windows CE-Prozess läuft. Mit einigen speziellen Mechanismen wurde aber sicher gestellt, dass trotzdem keine Dominanz von über ProOEK auftritt, die die Echtzeitfähigkeit von ProOEK-Tasks gefährdet. Dazu hat ProOEK die Möglichkeit, in bestimmten ituationen zu umgehen. interne Prozesse gemischte OEK/VDX cheduler OEK/VDX Tasks interne OEK/VDX Bild 2: Verschmelzen der seperaten von WindowsCE und OEK/VDX zu einer gemeinsamen Liste Dies ist auch erforderlich, da einige vom OEK/VDX-tandard geforderte Vorgehensweisen keine direkten Äquivalente unter haben. Deshalb mussten an einigen tellen neue Lösungsansätze gefunden werden, um das kooperative Miteinander der beiden ysteme sicherzustellen. Ein Beispiel hierfür ist die Kombination der Task- bzw. Prozess- beider ysteme. Da nicht ein ystem generell bevorzugt werden soll, wird aus den getrennten Prioritätslisten eine einzelne entwickelt (Bild 2). Auf diese Weise kann der oftware-entwickler eine sehr genaue Abstimmung zwischen Prozessen und Tasks vornehmen. Dabei wird die Rolle des OEK/VDX-chedulers, der normalerweise keine explizite Priorität besitzt, ein wenig verändert. o wird es möglich, Prozesse sowohl oberhalb als auch unterhalb des chedulers zu platzieren. Des weiteren lag ein besonderes Augenmerk auf der ynchronisation und Kommunikation zwischen den

4 beiden ystemen. o ist es problemlos möglich, in OEK/VDX-Tasks Dienste von zu nutzen. Es ist lediglich darauf zu achten, dass keine das OEK/VDX-ystem blockierenden Aufrufe getätigt werden. nsbesondere können OEK/VDX-Events für Prozesse erzeugt werden, um mit diesen zu kommunizieren. Umgekehrt wird aber auch Prozessen die Möglichkeit geboten, selbst OEK/VDX-Events an Tasks zu versenden. Prozesse virtuelle Kommunikation tatsächliche Kommunikation nterne Kommunikation Externe Kommunikation OEK/VDX-COM AP OEK/VDX Tasks einzelner Controller Controller- Netzwerk z.b. CAN-Bus Bild 3: Kommunikation zwischen Prozessen und Tasks über OEK/VDX-COM Library Da OEK/VDX-Events nur binäre Werte übermitteln können, wurde schließlich noch die interne Kommunikation gemäß OEK/VDX- COM so nachgebildet, dass Messages zwischen Prozessen und Tasks ausgetauscht werden können (Bild 3). Auf diese Weise wird eine echte Kooperation der beiden Betriebssysteme möglich. Gleichzeitig bleibt OEK-seitig die Transparenz der Kommunikation erhalten, was die Portierung bestehender Lösungen stark vereinfacht. Es konnte eine völlige ntegration in die ProOEK-Entwicklungsumgebung erreicht werden, die sich so darstellt, dass als eines der möglichen Zielsysteme neben vielen marktüblichen Mikrocontrollern angeboten wird. Damit wird die Portierung bestehender Applikationen in ein Mischsystem sehr einfach. Es ist wichtig festzuhalten, dass die bei dieser ntegration eingesetzten Mechanismen grundsätzlich auch die Kooperation von ProOEK mit anderen Betriebssystemen als erlauben. Einige spezielle Lösungsansätze müssten zwar angepasst werden, doch liegen hierfür schon Überlegungen vor. Leistungsdaten Es stellt sich schließlich die Frage nach der Leistungsfähigkeit des kombinierten ystems. Hierbei soll insbesondere die OEK/VDX- Applikation betrachtet werden, die erfahrungsgemäß die zeitlich kritischere ist. Verglichen werden ein reines ProOEK-ystem auf einem Motorola 68HC912DG128 mit 8MHz und ein kombiniertes /ProOEK- ystem auf einem ntel Pentium mit 200 MHz. Auf letzterem liefen parallel zu der OEK/VDX-Applikation gängige Dienste. Das wesentliche Leistungsmerkmal ist die für einen Taskwechsel benötigte Zeit. Hier wurde eine Reihe unterschiedlicher zenarien betrachtet (Tabelle 1). Während diese Werte beim reinen ProOEK statisch sind, unterliegen sie in der Kombination der ysteme gewissen chwankungen. n Extremfällen ist eine Verdoppelung der angegebenen Werte möglich. Allerdings bleiben auch dies Zeiten noch im Rahmen der auf einem HC12 erreichbaren Ergebnisse. Wichtig ist, dass es trotz der Einbettung in möglich bleibt, das Worst-Case-Verhalten anzugeben und damit ein deterministisches ystem zu gewährleisten.

5 Die Latenzzeiten für nterrupts werden in einem typischen OEK/VDXkonformen ystem mit den Taskswitch-Zeiten vergleichbar sein. Dies liegt daran, dass große Teile der Taskumschaltung unter nterruptsperre erfolgen müssen. Bei der für die ntegration gewählten Vorgehensweise ist dies nicht erforderlich. Dadurch gelten für und ProOEK gleiche nterrupt-latenzen. Es spielt also keine Rolle für die Verarbeitungsgeschwindigkeit, welches ystem einen nterrupt behandelt. Es wird deutlich, dass ein basiertes Gerät die Aufgaben eines typischen teuergerätes übernehmen kann. Das Zeitverhalten ist besser als das eines weit verbreiteten teuergeräte-controllers. Auch die Problematik der unterschiedlichen Behandlung von nterrupts je nach bearbeitendem ystem tritt nicht auf. Fazit Das wesentliche Ergebnis des Experiments ist die grundsätzliche Kombinierbarkeit zweier so unterschiedlicher Betriebssysteme wie OEK/VDX und auf einem einzigen Prozessor. Wichtig ist dabei, dass es sich nicht etwa um eine Emulation von OEK/VDX oder die Bereitstellung von Wrapper-Funktionen mit OEK/VDX-konformer AP, sondern um ein echtes ProOEK für WinCE-Zielsysteme handelt. Zwischen den beiden Betriebssystemen ist eine für den Anwender völlig transparente Kommunikation ebenso möglich wie die direkte Zusammenarbeit von Windows-Prozessen und OEK/VDX- Tasks. Man hat es also nicht mit zwei streng getrennten Lösungen sondern mit einem kooperationsfähigen Gesamtsystem zu tun. Wo liegen nun Einsatzmöglichkeiten für diese Lösung? Ein recht interessanter Einsatzbereich könnte in der Einbindung der Funktionalität kleinerer teuergeräte in ein nfotainment-gerät bestehen. Bereits vorhandene Lösungen auf OEK/VDX- Basis ließen sich mit vergleichsweise geringem Aufwand weiterverwenden. Es sind aber auch ganz neue Ansätze für teuergeräte auf der Basis zweier kooperierender Betriebssysteme möglich. ProOEK OEK + CE Autoren: Task1 aktiviert Task2 (mit Verdrängung) 47 µs 14 µs elbstaktivierung von Task2 15 µs 8 µs R aktiviert Task2 (ohne Verdrängung) 24 µs 18 µs R aktiviert Task2 (mit Verdrängung) 47 µs 19 µs Tabelle 1: Leistungsvergleich von normalem ProOEK und dem unter WindowsCE laufenden ProOEK Markus Zetlmeisl ist seit 2000 für 3OFT in Erlangen tätig. Die im Artikel geschilderten Untersuchungen waren Bestandteil seiner 2001 an der Universität Erlangen vorgelegten Diplomarbeit. Dr. Jochen choof leitet bei 3OFT die chulungs- und Consulting-Aktivitäten zum Themenbereich OEK/VDX. 3OFT GmbH, Frauenweiherstr. 14, Erlangen, Tel.: 09131/7701-0, Fax: 09131/ nternet: info@3oft.de