AUTOSAR IIII Software-Entwicklung

www.elektroniknet.de Elektronik automotive 5.2006 47

Als skalierbares Highspeed-Kommunikationssystem mitdeterministischem Verhaltenist FlexRay die passende Lösung alsData-Backbone für verteilte Regelun-gen oder sicherheitsrelevante Anwen-dungen im Automobil-Bereich. Im Ge-gensatz zur ereignisgesteuerten Kom-munikation über CAN werden alle Bot-schaften einem festen Kommunika-tionsraster zugeordnet. Daraus ergibtsich für jedes beteiligte Steuergerät ei-ne zeitlich eindeutige Verfügbarkeitder Eingangsdaten. Der Entwurf einesFlexRay-Netzwerkes erfordert bereitsin einer sehr frühen Entwicklungspha-se grundlegende Festlegungen wieBaudrate, Zykluslänge, Anzahl undLänge der Slots im statischen und dy-namischen Segment bzw. Macrotick-Dauer für alle beteiligten Netzwerk-knoten. Diese Planung der Kommuni-kationsabläufe ist in den kommunika-tionsspezifischen Software-Kompo-nenten abgebildet, sie kann aber auchEinfluss auf die zeitliche Gestaltungder Anwendungs-Software haben.

Das Betriebssystem (OS) sorgt fürdas Zusammenspiel aller beteiligtenSoftware-Komponenten. Zur Verfü-gung stehen ereignisgesteuerte (eventtriggered) oder zeitgesteuerte (time trig-gered) Betriebssysteme mit jeweils un-terschiedlichen Diensten. Als weitereOption sind Betriebssysteme mit Spei-cherschutz verfügbar. Bei der Auswahldes optimalen Betriebssystems fürFlexRay-basierte Anwendungen stelltsich insbesondere die Frage, ob ein zeit-gesteuertes Betriebssystem für die syn-chronisierte Kommunikation über Flex-Ray zwingend erforderlich ist.

Ereignisgesteuerte und zeit-gesteuerte Betriebssysteme

Bisher wurden im Automobilbereichmeist ereignisgesteuerte Betriebssys-teme eingesetzt. Dabei genießt dasOSEK/VDX-OS [1], das künftig auchin einer ISO-Norm vorliegen soll, die

breiteste Akzeptanz. Ziel eines Be-triebssystems ist es, unter optimalerNutzung der verwendeten Hardwareeine zusätzliche Laufzeitumgebungzur Verwaltung von Funktionsein-heiten bereitzustellen. Definierte Be-triebssystem-Dienste bieten dieseFunktionalität an. Beim Design einerAnwendung werden zunächst zeitlichunabhängige Teilaufgaben definiert.Die daraus resultierenden Tasks oderInterrupts konkurrieren gemäß demScheduling-Algorithmus des Betriebs-systems um die Laufzeitzuweisung:

Tasks werden durch Alarme oder Er-eignisse (Events) ausgelöst. Dabei wer-den Extended Tasks und Basic Tasksunterschieden. Extended Tasks zeich-nen sich durch die Fähigkeit aus, aufEreignisse warten zu können.

Interrupt Services Routinen (ISR)sind Hardware-spezifisch und werdendurch die Hardware-Peripherie getrig-gert. Sie haben höhere Priorität alsTasks und sollen deshalb nur für Teil-aufgaben reserviert werden, die einemöglichst schnelle Reaktionszeit er-fordern.

Bei einem zeitgesteuerten Betriebs-system sind sämtliche Abläufe undAktionen unter der Kontrolle des Be-

triebssystems ausschließlich abhängigvon der Zeit. Für die Applikation er-gibt sich damit ein streng determinis-tisches Zeitverhalten.

AUTOSAR-OS

AUTOSAR hat das OSEK-OS als Ba-sis genommen und erweitert, so dassauch zeitgesteuerte Funktionalitätenunterstützt werden können. In vierAusbaustufen, den so genannten Scala-bility Classes (SC), werden die spezi-fischen Eigenschaften des AUTOSAR-OS [2] zur Verfügung gestellt. Tabel-le 1 stellt einen Überblick ihrer Zuord-nung zu den Scalability Classes dar.

Kriterien zur Betriebssystem-Auswahl für zeitkritischeAnwendungen

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.

Von Pascale Morizur, Dirk Grossmann und Winfried Janz

Das optimale Betriebssystemfür FlexRay

I Das AUTOSAR-OS bietet vier Ausbaustufen mit den für FlexRayrelevanten Eigenschaften.

SC1 X – – – Ereignisorientiert

SC2 X X X – Weiterentwicklung von OSEKtime

SC3 X – – X Weiterentwicklung von HIS-Protected OS

SC4 X X X X –

Scal

abili

ty C

lass

Sche

dule

Tab

les

Zeitü

berw

achu

ng

Glob

alze

it/Sy

nchr

onis

ieru

ng

Spei

cher

schu

tz

Kommentar

Software-Entwicklung IIII AUTOSAR

48 Elektronik automotive 5.2006 www.elektroniknet.de

Es sind nur die Eigenschaften einge-tragen, die im Zusammenhang mit ei-ner FlexRay-basierten Anwendung vonBedeutung sind. Die derzeit verfügba-ren Spezifikationen von BSW (BasicSoftware) und RTE (Runtime En-vironment) decken Speicherschutznoch nicht ab. Dies wird in zukünf-tigen Versionen der BSW- und RTE-Spezifikationen nachgezogen.

Schedule Tables

Das Betriebssystem verwaltet mehrereSchedule Tables. Jede Schedule Tablebesteht aus einer Liste von zeitlich de-finierten Aktionen, die entweder Tasksaktivieren oder Events an Tasks ver-schicken.

Zeitüberwachung

Bei einem Echtzeit-System kommt esdarauf an, alle Aufgaben rechtzeitig ab-zuarbeiten. In der Entwurfsphase wer-den Teilaufgaben festen Zeitfensternzugeordnet. Damit zur Laufzeit keineVerzögerung entsteht, darf eine Aufga-be die CPU nicht länger in Anspruchnehmen, als im Design vorgegeben.Deshalb überwacht das Betriebssystemdie Laufzeit jeder einzelnen Task bzw.jedes Interrupts. OSEKtime [3] siehtdafür ein klassisches Deadline Monito-ring vor: Tasks müssen fertig sein, be-vor ihre zugeordnete Deadline erreichtist. Liegt eine Verletzung vor, löst dasgesamte System ein Reset aus. Bei Ex-tended Tasks, die auf Events warten

können, ist diese Art von Überwachungnicht ausreichend. Deshalb hat die AUTOSAR-OS-Arbeitsgruppe eineLaufzeitüberwachung für jede einzelneTask und jeden Interrupt definiert. Siewird mit unterschiedlichen Parameternim Konfigurator festgelegt.

Für jede Task wird der Timeframe(Überwachungszeitraum) und das Exe-cution Time Budget (maximale Aus-führungszeit pro Überwachungszeit-raum) definiert. Soll im Konfiguratordes Betriebssystems die Mehrfachak-tivierung einer Basic Task zugelassensein, beinhaltet das Execution Budgetdie gesamte Laufzeit aller Aktivierun-gen der betroffenen Task. Bei Exten-ded Tasks sind grundsätzlich keineMehrfachaktivierungen möglich.

Für jeden Interrupt sind der Überwa-chungszeitraum, die „Worst Case Exe-

cution Time per Execution“ und diemaximale Anzahl von Interrupts proÜberwachungszeitraum zu definieren.Je Timeframe können mehrere Inter-rupts zugelassen werden, die WorstCase Execution Time bezieht sich abernur auf einen einzigen Durchlauf.

Bei Verletzung eines Überwa-chungsparameters leitet das Betriebs-system je nach Konfiguration entwe-der ein „Reset_OS“, „Kill_Applica-tion“, „Kill_Task“ oder „Kill_Inter-rupt“ als Fehlerreaktion ein.

Bild 1 zeigt die Überwachung einerAnwendung, bestehend aus einer Ex-tended Task, die von einem Interruptmehrmals unterbrochen wird. Wegeneiner längeren Laufzeit der ExtendedTask, z.B. für die Behandlung desEvents 1 (Ev1) kann es zur Fehlerbe-handlung kommen (Bild 2). Diese be-trifft ausschließlich den Verursacher.Die Zeitüberwachung garantiert jenach Budget Tasks und Interrupts mitniedriger Priorität den Zugang zumProzessor für die Abwicklung ihrerAufgabe.

Sollte wie in Bild 3 ein Interrupt zulange dauern, wird dieser abgebrochendamit die Extended Task weiterlaufenkann. Die Bilder 1 bis 3 stellen einAUTOSAR-OS der Scalability Class 2mit Zeitüberwachungs-Tasks und In-terrupts dar.

Synchronisierung über Globalzeit

Verteilte Regelungen, die eine Syn-chronisierung von Tasks über Steuer-

I Bild 2. Die längere Laufzeit einzelner Tasks kann zur Fehlerbehandlung führen.

I Bild 1. Wird eine Task nicht innerhalb ihres Überwachungszeitraumes abgeschlossen oder durchmehrere Interrupts unterbrochen, muss nicht zwangsläufig ein Fehler ausgelöst werden.

AUTOSAR IIII Software-Entwicklung

www.elektroniknet.de Elektronik automotive 5.2006 49

geräte-Grenzen hinweg erfordern,benötigen die Unterstützung einer Glo-balzeit, die regelmäßig dem Betriebs-system zur Verfügung gestellt wird.Die Synchronisierung der Applikationauf diese Globalzeit kann entwederschrittweise erfolgen („smooth“) oderdurch ein einmaliges, vollständigesAnpassen („hard“).

Speicherschutz

Mechanismen zum Speicherschutzsind erforderlich, um die Störung durchandere Module frühzeitig zu erkennenund zu unterbinden. Für den Fall, dassin einem Steuergerät Software-Moduleverschiedener Hersteller integriertwerden, lassen sich damit zur Laufzeitdie unterschiedlichen Software-Paketebezüglich ihrer Speicherbereiche tren-nen. Dazu ist ein Prozessor mit Hard-ware-Unterstützung notwendig. Ersollte zudem über einen großen Spei-cher und hohe Verarbeitungsgeschwin-digkeit verfügen, da die Speicher-schutz-Mechanismen die Betriebssys-

tem-Dienste durchschnittlich um denFaktor 1,5 bis 2 verlangsamen.

Datenaustausch zwischenFlexRay und Anwendungs-Software

Hinsichtlich der Serienimplementie-rung sind Kosten und Nutzen von Sche-

dule Tables, Zeitüberwachung, Syn-chronisierung und Speicherschutz ab-zuwägen. Dabei muss berücksichtigtwerden, dass das gewählte OS die Syn-chronisation des Datenaustauschs zwi-schen FlexRay und Applikation op-timal unterstützt.

Beim FlexRay-Protokoll sind biszu 64 Grundzyklen in einer sich stän-

I Bild 4. Beim Da-tenaustauschzwischen derFlexRay-Hard-ware und derSoftware-Appli-kation mit ei-nem OSEK-OSführt eine man-gelhafte Syn-chronisierung zu einer verspä-teten Abarbei-tung.

I Bild 3. Interrupts, die zu viel Zeit in Anspruch nehmen, werden zu Gunsten der Extended Task abgebrochen.

Software-Entwicklung IIII AUTOSAR

50 Elektronik automotive 5.2006 www.elektroniknet.de

dig wiederholenden Runde zusam-mengefasst.

Jeder Grundzyklus enthält Framesmit verschiedenen Prozessdaten be-ziehungsweise Signale für unter-schiedliche Applikations-Tasks. DasFlexRay-Protokoll liefert mit einerGlobalzeit die Grundlage für den syn-chronisierten Datenaustausch. Sobaldsich der Datenverbund synchronisierthat, steht diese jedem Communica-tion Controller (CC) des Verbundszur Verfügung.

Bei einer ver-teilten Regelungwird eine Funk-tion über mehrereSteuergeräte imNetzwerkverbundverteilt. Die Tot-

zeit, verursacht durch die Signallauf-zeit von Senderapplikation zu Emp-fängerapplikation, kann dabei einenentscheidenden Einfluss auf die Regel-güte haben. Grundsätzlich wirkt sicheine geringe Totzeit günstig aus.

Bei ereignisgesteuerten Kommuni-kationssystemen wird der Datenaus-tausch zwischen CC und Host grund-sätzlich per Interrupt gesteuert; beimZugriff auf den Bus entstehen gegebe-nenfalls Wartezeiten. Die Signallauf-zeit lässt sich nicht genau vorhersagen,es wird daher typischerweise eineWorst-Case-Abschätzung durchge-führt. Erst durch die Bereitstellung einer globalen Zeit des FlexRay-Protokolls wird es dem Betriebssystemermöglicht, Dienste zur Synchronisati-on auf diese Zeit anzubieten. Durch

das TDMA-VerfahrenTime Division Multip-le Access) ist allen be-teiligten Steuergeräten der genaue Sende-bzw. Empfangszeit-punkt jeder Botschaftim statischen Bereichdes FlexRay-Zyklusbekannt. Diese beidenEigenschaften mini-mieren die Unschärfebezüglich der Signal-laufzeit einer Flex-Ray-basierten Anwen-dung.

Für die Synchro-nisierung des Daten-austauschs bei einerF lexRay-bas i e r t enAnwendung lassensich je nach Bedarfund verfügbaren Be-triebssystem-Eigen-schaften mehrere Lö-sungsansätze realisie-ren. Die Kommuni-kations-Tasks solltengrundsächlich mitdem FlexRay-Timerdes CC getriggertwerden. Die Aktivie-rung der Applika-tions-Tasks könntehingegen durch einenbeliebigen Timer er-folgen. Hieraus erge-ben sich vier möglicheLösungsansätze:

Alarme, die am OS-System-Timerhängen, triggern die Applikations-Tasks. Am Anfang jedes Grundzykluswird der „FlexRay-Cycle Start Inter-rupt“ durch den FlexRay-Controllerausgelöst. Die Kommunikations-Taskwird sofort aktiviert. Die Kette vonApplikations-Tasks wird unabhängigdavon vom Betriebssystem-Timer an-gestoßen. Bild 4 stellt vereinfacht mitnur einer Applikations- und einerKommunikations-Task diesen Lö-sungsansatz dar. Zu beachten ist, dasseine spätere Auslösung eines CycleStart Interrupts, zum Beispiel durcheine Drift zwischen CC- und Host-Quarz verursacht, eine verspätete Ab-arbeitung der übertragenen FlexRay-Daten (z.B. aus Frame 2) von ΔtOS =1 ms als Konsequenz hat. Erwartet

I Bild 5. Die Einführung einer globalen Zeitbasis und der Schedule Tables führt zu einer stabilen Verbindung zwischen FlexRay-Hardwareund AUTOSAR-OS (SC1).

AUTOSAR IIII Software-Entwicklung

www.elektroniknet.de Elektronik automotive 5.2006 51

die Applikation keine längere Reakti-onszeit, ist dafür ein OSEK-OS aus-reichend.

Erfordert die Regelung eine kürzereAntwortzeit (weniger als 1 ms), dannist für die Auslösung der Applikations-Tasks ein High Resolution Timer (Auf-lösung ca. 10 μs) beim OSEK-OS not-wendig. Dafür wird allerdings ein ge-eigneter Timer benötigt.

Falls das Steuergerät nicht über ei-nen High Resolution Timer verfügt,kann der FlexRay-Timer zusätzlich fürdie Aktivierung der zeitkritischen Ap-plikations-Tasks benutzt werden(Bild 5). FlexRay-unabhängige Taskskönnen weiterhin an den OS-System-Timer gehängt werden. Beim Aufstart-verhalten ist zu beachten, dass derFlexRay-Timer und damit die durchihn aktivierten Tasks erst zur Verfü-gung stehen, nachdem der FlexRay-Controller sich erstmalig auf das Netz-werk synchronisiert hat. Sollte an-schließend die Synchronisierung ver-loren gehen, kann der FlexRay-Timerauf Basis seiner lokalen Zeit weiterhinarbeiten, falls der FlexRay-Controllerentsprechend konfiguriert wurde. EinAUTOSAR-OS der Scalability Class 1mit Schedule Tables ist dazu ausrei-chend. Diese Lösung erlaubt eine übermehrere Steuergeräte verteilte Rege-lung, da die FlexRay-Globalzeit dieSynchronisierung über alle Steuergerä-te sicherstellt.

Falls in obigen Fällen zusätzlich dieEinhaltung der Task- und Interrupt-Laufzeiten überwacht werden soll, istein AUTOSAR-OS der ScalabilityClass 2 oder 4 erforderlich. Damit wer-den Laufzeitüberschreitungen verhin-dert; ein zeitlich deterministisches Ver-halten wird erreicht.

Eine FlexRay-basierte Anwendungerfordert nicht zwingend ein zeitge-steuertes Betriebssystem. Die Festle-gung des geeigneten Betriebssystemssollte unter Berücksichtigung der An-wendung und Architektur individuellfür jedes Steuergerät erfolgen. Dazuist eine Analyse in Bezug auf Steuer-geräte-übergreifende Synchronität, Si-cherheitsanforderungen, Antwortzeitund Zeitüberwachung notwendig. Füralle FlexRay-Anwendungen bietetVector Informatik dem Entwickler einentsprechendes Betriebssystem: dasnach dem OSEK/VDX-Standard zer-tifizierte osCAN mit oder ohne HighResolution Timer oder osCAN AUTO-SAR, das die Scalability Classes SC1-SC4 gemäß AUTOSAR-OS V2.0 ab-deckt. Die Vector-FlexRay-Software-komponenten arbeiten mit jeder dieserOS-Varianten zusammen. Der osCANTimingAnalyzer analysiert hierbei dieEinplanbarkeit von Tasks mit einerWorst-Case-Betrachtung.

Für die durchgängige Entwicklungvon FlexRay-Systemen bis zum Se-

rieneinsatz unterstützt Vector den An-wender mit Softwarekomponenten undindividueller Dienstleistung. Ausge-reifte und aufeinander abgestimmteTools wie der DaVinci Network De-signer für alle FlexRay-typischen Ent-wurfsaufgaben oder CANoe.FlexRay5.2 für Simulation und Stimulation ei-nes Netzwerkes, Integrationstests undRestbussimulation sowie Analyse desfertigen FlexRay-Netzwerks erleich-tern die Entwicklung. Der Zugriff aufalle internen Parameter des FlexRay-Steuergerätes über das standardisierteMess- und Kalibrierprotokoll „XCP onFlexRay“ erfolgt mit CANape 6.0. Fürdie erste, schnelle und flexible Imple-mentierung eines FlexRay-Netzwerkssorgt das FlexRay Evaluation Bundle.Diese integrierte Umgebung aus Soft-warekomponenten und Werkzeugenbeinhaltet auch eine Beispielanwen-dung für ein FlexRay-System mit zweiKnoten. sj

Literatur

[1] OSEK/VDX Operating System, Version2.2.2. www.osek-vdx.org

[2] AUTOSAR – Specification of ModuleOperating System V2.0.www.autosar.org

[3] OSEKtime – OSEK/VDX Time-TriggeredOperating System, Version 1.0.www.osek-vdx.org

Dipl.-Ing. Pascale Morizurstudierte Physik-Elektronik an der Grande Ecole ICPI in Lyon (F). Nach ihrem Abschluss1986 arbeitete sie zehn Jahre bei MAN-Nutz-fahrzeuge in der Vorentwicklung im BereichCAN, J1939 und Diagnose. Sie ist bei Vector alsProduct Management Engineer im BereichFlexRay-Embedded-Softwarekomponententätig.pascale.morizur@vector-informatik.de

Dipl.-Ing. Winfried Janzstudierte an der Universität Stuttgart Elektro-technik. Nach vier Jahren in der Software-Entwicklung für Embedded Controller in derRegelungs- und Automatisierungstechnik kamer 1995 zu Vector. Hier ist er seit 1997 alsTeamleiter und Produktmanager für die Ent-wicklung von OSEK-Echtzeit-Betriebssystemenzuständig. Er hat in den Arbeitskreisen OSEKund AUTOSAR die Spezifikationen Betriebs-system und Konfiguration mitgestaltet.winfried.janz@vector-informatik.de

Dipl.-Ing. Dirk Grossmannstudierte Elektrotechnik an der UniversitätStuttgart. Nach seinem Abschluss 1997 arbei-tete er zunächst in der Betriebssystem-Ent-wicklung der ETAS GmbH, bevor er für zweiJahre als Produktmanager Nordamerika denBereich Betriebssystem verantwortete. Seit2003 ist er bei Vector als Teamleiter für dieEntwicklung der FlexRay-Embedded-Soft-warekomponenten verantwortlich.dirk.grossmann@vector-informatik.de

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles false /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /DocumentCMYK /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice