<![CDATA[
<BODY>
<H1>www.aud24.net : D. Brook: "Entwicklung von Embedded-Software mit dem OSEK Echtzeit-Betriebssystem"</H1>
<P> <BR>
[<A href="/">www.aud24.net</A>] [<A href="../index.html">back</A>]
</P>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich >
Redaktion
> <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD>
<TD ALIGN=right VALIGN=bottom CLASS=detailDatum>05.03.2001</TD>
</TR>
</TABLE>
</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailFirma ID=topSpace>Metrowerks Europe:</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailTitel>D. Brook: "Entwicklung von Embedded-Software mit dem OSEK Echtzeit-Betriebssystem"</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailSubtitel></TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top CLASS=detailContent>Der OSEK/VDX Real-Time Operating System Standard (RTOS - Echtzeit-Betriebssystem) etabliert sich momentan in der Automobilindustrie. Diejenigen Automobilhersteller, die OSEK bisher noch nicht einsetzen, sind sich zumindest in hohem Maße dessen Existenz bewusst und viele Firmen sind dabei, es zu evaluieren. Die Existenz eines stabilen und offenen Standards für Embedded-Echtzeit-Betriebssysteme hat Auswirkungen auf die gesamte Entwicklung von Embedded-Software, und dies weit über die Automobilindustrie hinaus. Firmen mit einer einheitlichen, auf einer standardisierten Applikationsumgebung basierenden Entwicklungsstrategie profitieren nun von einem kürzeren Entwicklungszyklus für Software, verbesserter Qualität innerhalb der Applikationen, Portabilität zwischen verschiedenen Applikationen und Plattformen, erhöhter Flexibilität sowie Modularität und vielem mehr. In welchem Ausmaß diese Zielsetzungen erreicht werden können, hängt jedoch von weit mehr als von der Einbindung eines Echtzeit-Betriebssystems wie OSEK ab.<BR><BR>Einleitung<BR><BR>OSEK ist ein offener Standard für ein ereignisgesteuertes Echtzeit-Betriebssytem, der von Automobilherstellern und ihren Zulieferern erarbeitet wurde. OSEK nutzt robuste und bewährte RTOS-Technologien, um einen in hohem Maße steuer- und skalierbaren Satz von Systemdiensten zu implementieren. Dabei ist nichts an OSEK lediglich automobilindustriespezifisch. Vielmehr wurde ein Echtzeit-Betriebssystem geschaffen, das auf jedem ‚Embedded‘-System mit beliebigem Microcontroller läuft und in vielerlei verschiedenen Applikationsbereichen eingesetzt werden kann. Die Größe kann gänzlich an Geschwindigkeits- und Speicherbedarf der Zielplattform und der Applikation angepasst werden. Es ist klein genug, um auf einer 8-bit MCU wie der Motorola M68HC08-Familie (ein Footprint von weniger als 1 kB ROM ist möglich) oder auf 32-bit Prozessoren wie dem Motorola MPC555 lauffähig zu sein.<BR>Die OSEK-Spezifikation hat sich über die letzen Jahre weiterentwickelt, ist nun stabil und wird von einer ganzen Reihe von Konformitätstests unterstützt, welche die Befolgung der Spezifikation garantieren. Die OSEK-Produkte von Motorola, die vor kurzem an deren Software-Tochter Metrowerks übergeben wurden, werden nun schon seit über 3 Jahren in der Applikationsentwicklung eingesetzt und gehören zu den ersten vollumfänglich OSEK-konformen Komponenten und bringen ihren Anwendern dadurch erhöhtes Vertrauen und Sicherheit.<BR>Der Nutzen für Entwickler, bei ihrer nächsten Applikation ein Echtzeit-Betriebssystem einzusetzen dürfte auf eine einzelne Applikation bezogen wahrscheinlich eher beschränkt sein; um die Vorteile eines RTOS zu erkennen, sollten Entwickler stattdessen den gesamten Design-Prozess in Betracht ziehen. Während der ersten Einsätze eines kompakten und effizienten RTOS wie OSEK innerhalb einer gesamten Projektentwicklung findet ein Lernprozess statt. Die Erfahrung hat gezeigt, dass die Implementierung von OSEK für erfahrende C-Programmierer dennoch keinen großen Schritt darstellt, und dass eventuell auftretende Probleme eher philosophischer Natur sind, z.B. hinsichtlich der Frage, wie ein Design mit einem andersartigen Programmier-Modell vonstatten gehen soll. So basiert das von Entwicklern benutzte Programmier-Modell sehr oft auf einem Schleifenmodell mit zyklischer Ausführung, wohingegen das gegenwärtige OSEK-RTOS ein ereignisgesteuertes, preemptives (verdrängendes) und prioritätsbasiertes Multitasking-Betriebssystem darstellt.<BR><BR><BR>Bisherige Szene<BR>In einer zyklischen Schleife wird die Priorität einer Task durch denjenigen Punkt innerhalb der Schleife bestimmt, an dem sie ausgeführt wird. Prioritäten können durch die Verwendung von größeren oder kleineren Zyklen und Interrupts realisiert werden. Auf den ersten Blick scheint dies ein solides System zu sein: Der Overhead ist gering, die Performance ist leicht zu analysieren, die Ausführung in Echtzeit ist bekannt und die Implementation einfach. Zwar kann in begrenztem Maße auch Portabilität erzielt werden, jedoch führt eine auf diesem Programmier-Modell basierende Standardisierung auch zu Problemen. So wird das System in einer zyklischen Applikation mit wenigen sporadischen Ereignissen oder Interrupts mit gedrängten Deadlines zwar funktionieren, jedoch führt die harmonische Natur dieser zyklischen Aktivität auch dazu, dass Zyklen verschwendet und das System dadurch ineffizient wird. Um eine Applikation an veränderte Timing-Ansprüche anpassen zu können, muss sie auseinandergenommen und neu kompiliert werden. Wenn ein System nun eine Menge häufig vorkommender Ereignisse mit gedrängten Deadlines enthält, wird es ineffizient und schnelles Polling wird nötig. Der negativste Aspekt dieses Systemtyps ist jedoch die mühsame Systempflege: der Code muss hierzu oft abgespalten werden. Zudem bedeutet schon eine kleine Abänderung oft riskante und komplexe Eingriffe.<BR><BR><BR>Vorteile mit OSEK<BR>OSEK teilt Tasks auf der Basis von Systemereignissen ein, der Scheduler verwaltet deren Ausführung aufgrund von festgelegten Task-Prioritäten und Preemptivität. Der Benutzer wird hierdurch befähigt, die Applikation von der Hardware zu trennen, dies speziell dann, wenn ein Standard-Kommunikationsprotokoll und ein Interface für Peripherie-Treiber zusammen verwendet werden. Software-Entwickler erhalten ein standardisiertes Set von System-Services, API (Application Programming Interface - Programmierschnittstelle), Konfigurationsmethodik und ein klar definiertes, voraussehbares Verhalten, auf dem Applikationen aufgebaut werden können. Die Möglichkeit, bereits entwickelte Software zu rekonfigurieren, ist ausserordentlich wichtig und sollte dementsprechend als Vorteil für den gesamten Entwicklungsprozess gesehen werden. Ein weiteres erwähnenswertes Feature ist die Tatsache, dass die gesamte Konfiguration von OSEK statisch ist und vom Entwickler vor Erstellen der Laufzeit-Version festgelegt wird. Kein einziges Attribut von Systemobjekten wie Task-Prioritäten, Preemtivität, Stacks usw. wird dynamisch zugeordnet. Hierdurch wird eine Umgebung für ein in höchstem Maße stabiles und effizientes System geschaffen.<BR>Der OSEK Scheduler passt Applikations-Tasks an die verfügbare Zeit an, indem er Prioritäten und Preemptivität verwaltet, was wiederum dem Designer ermöglicht, Aufgaben auf verschiedene Systeme, Plattformen und Applikationen zu portieren. Das Design-Team kann bereits bestehende und getestete Sets aus Funktionen und Applikationen wiederverwenden, was sich positiv auf die Qualität zukünftiger Applikationen und auf die Entwicklungsgeschwindigkeit auswirkt. Dennoch muss ein Entwickler einige Schwierigkeiten überwinden, wenn er ein RTOS einsetzt. Gleichzeitiger Zugriff auf gemeinsam genutzte Resourcen, Deadlock, Inversion oder Blockierung der Prioritäten sind vielfach dokumentierte Problematiken bei RTOS-Systemen, sind aber auch gut erfasst worden . Um derlei Probleme zu vermeiden, benutzt OSEK eine bestimmte Form von ‚Priority Inheritance Protocol‘ für die Resourcen-Verwaltung. Der Forderung nach einer steuerbaren Zeiteinteilung für Applikationen muss auch in einem komplexen System nachgekommen werden: es muss dafür gesorgt werden, dass jede Task zu jedem Zeitpunkt und in ausreichendem Zeitrahmen Zugriff auf die CPU erhält, um ihre spezifischen Deadlines einzuhalten. Im Zweifelsfall kann die Zeiteinteilung für bestimmte Systeme mit zwischenzeitlich allgemein erhältlichen Tools unter Verwendung von Techniken wie ‚Rate Monotonic Analysis‘ (RMA) oder ‚Deadline Monotonic Analysis‘ (DMA) analysiert werden.<BR><BR>Zielsetzung bei OSEK-Einsatz<BR><BR>Standardisierte Softwarekernel oder Betriebssyteme müssen die ständig wachsende Komplexität von Embedded-Applikationen und die verkürzte Entwicklungszeit meistern. Die einzige Alternative wäre, jede Applikation jedesmal von Grund auf neu zu schreiben. In den letzten Jahren fand in der Automobilindustrie hinsichtlich der Entwicklung von Embedded-Applikationen eine Abkehr von Low Level Assembler-Sprachen zugunsten von C statt, nun verschiebt sich dieser Prozess hin zu standardisierten RTOSs - wegen der genannten Vorteile.<BR>Da ein RTOS fähig sein muss, auf der gewählten Plattform zu laufen und den Anforderungen an die Systemleistung gerecht zu werden, stellt sich die Frage nach den Systemresourcen. Die verschiedenen Anforderungen und die Leistungsbandbreite sind in Tabelle 1 einander gegenübergestellt.<BR>Hochleistungssysteme in der Automobilelektronik wie z.B. die Getriebesteuerung erfordern eine sehr schnelle Aktivierung von Tasks und ‚Context Switching‘-Zeiten. Diesen Anforderungen genügen Systeme wie z.B. das OSEK turbo von Metrowerks mit ‚Context Switching‘-Zeiten von bis zu 2,5 µs in einer typischen MPC555-OSEK-Applikation mit 10 Tasks und 40 Mhz, bei einem Speicherbedarf von lediglich 3k ROM und 500 bytes RAM.<BR>Die Verwendung eines RTOS muss sich also nicht hemmend auf die Applikations-Leistung auswirken, sie stellt vielmehr die Flexibilität zur Verfügung, welche die stetig wachsenden Ansprüche an Qualität und Geschwindigkeit in der Software-Entwicklung fordern. Ein RTOS ist lediglich eine Komponente eines ausgereiften Ansatzes zum Software-Design. OSEK spielt in diesem gesamten Prozess eine kleine, aber dennoch sehr wichtige Rolle.<BR></TD>
</TR>
<TR>
<TD CLASS=detailQuelle> </TD>
</TR>
</TABLE>
</TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top></TD>
</TR>
<TR>
<TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD>
</TR>
</TABLE>
<P><I>Diese Seite wurde am 22.09.2006, 13:54 Uhr aktualisiert</I></P>
</BODY>
]]>