IX

Inhalt

Vorwort ......................................................................................................................... V

Anwendung von Bussystemen und Protokollen ................................................ 1

1.1 Überblick .......................................................................................................... 2

1.2 Kfz-Bussysteme, Protokolle und Standards ..................................................... 5

1.3 Standardisierung bei Kfz-Bussystemen und Software ..................................... 7

2 Grundkonzepte und einfache Kfz-Bussysteme ................................................... 9

2.1 Grundlagen ....................................................................................................... 9 2.1.1 Elektrotechnische Grundlagen ............................................................... 9 2.1.2 Topologie und Kopplung von Bussystemen ......................................... 12 2.1.3 Botschaften, Protokollstapel, Dienste (Services) .................................. 14 2.1.4 Kommunikationsmodelle, Adressierung ............................................... 16 2.1.5 Zeichen- und Bitstrom-basierte Übertragung, Nutzdatenrate ............... 20 2.1.6 Buszugriffsverfahren, Fehlererkennung und Fehlerkorrektur ............... 22 2.1.7 Jitter und Latenz bei der Datenübertragung ......................................... 25

2.2 K-Line nach ISO 9141 und ISO 14230 ........................................................... 26 2.2.1 Entwicklung von K-Line und KWP 2000 ............................................... 26 2.2.2 K-Line Bus-Topologie und Physical Layer ........................................... 27 2.2.3 Data Link Layer .................................................................................... 29 2.2.4 Einschränkungen für emissionsrelevante Komponenten (OBD) .......... 33 2.2.5 Schnittstelle zwischen Protokoll-Software und Kommunikations-

Controller ............................................................................................. 33 2.2.6 Ältere K-Line-Varianten ........................................................................ 34 2.2.7 Zusammenfassung K-Line- Layer 1 und 2 ......................................... 35

2.3 SAE J1850 ..................................................................................................... 36

2.4 Sensor-Aktor-Bussysteme .............................................................................. 39 2.4.1 SENT- Single Edge Nibble Transmission nach SAE J2716 ............... 39 2.4.2 PSI 5- Peripheral Sensor Interface 5 .................................................. 40 2.4.3 ASRB 2.0- Automotive Safety Restraint Bus (ISO 22898) ................. 41 2.4.4 DSI - Distributed Systems Interface .................................................... 43

2.5 Normen und Standards .................................................................................. 44

3 Kfz-Bussysteme- Physical und Data Link Layer .. ........................................... 45

3.1 Controller Area Network CAN nach ISO 11898 .............................................. 45 3 .1.1 Entwicklung von CAN ........................................................................... 45 3.1.2 Bus-Topologie und Physical Layer ....................................................... 46 3.1.3 CAN Data Link Layer ............................................................................ 48 3.1.4 Fehlerbehandlung ................................................................................ 50 3.1.5 Einsatz von CAN- Höhere Protokolle ................................................. 50 3.1.6 Schnittstelle zwischen Protokoll-Software und CAN-Controller ............ 52

X Inhalt

3.1.7 Zeitverhalten von CAN-Systemen, Wahl der Botschaftspriorität.. ........ 54 3.1.8 Time-Triggered-CAN (TTCAN)- Deterministischer Buszugriff ............ 60 3.1.9 Zusammenfassung CAN- Layer 1 und 2 ............................................ 62

3.2 Locallnterconnect Network LIN ..................................................................... 63 3.2.1 Überblick .............................................................................................. 63 3.2.2 Data Link Layer .................................................................................... 64 3.2.3 Neue Botschaftstypen bei LIN V2.0 ..................................................... 67 3.2.4 LIN Transportschicht und ISO Diagnose über LIN ............................... 68 3.2.5 LIN Gonfiguration Language ................................................................ 69 3.2.6 Dynamische Konfiguration von LIN-Siave-Steuergeräten .................... 73 3.2.7 LIN Application Programming Interface (API) ....................................... 74 3.2.8 Zeitverhalten von LIN-Systemen .......................................................... 76 3.2.9 Zusammenfassung LIN- Layer 1 und 2 .............................................. 78

3.3 FlexRay .......................................................................................................... 79 3.3.1 Bus-Topologie und Physical Layer ....................................................... 79 3.3.2 Data Link Layer .................................................................................... 81 3.3.3 Netzwerk-Start und Takt-Synchronisation ............................................ 85 3.3.4 Fehlerbehandlung, Bus Guardian ........................................................ 87 3.3.5 Konfiguration und übergeordnete Protokolle ........................................ 88 3.3.6 Zeitverhalten von FlexRay-Systemen, Beispiel-Konfiguration .............. 89 3.3.7 Schnittstelle zum FlexRay-Controller ................................................... 94 3.3.8 Weiterentwicklung FlexRay 3.0 ............................................................ 98 3.3.9 Zusammenfassung FlexRay - Layer 1 und 2 ....................................... 98

3.4 Media Griented Systems Transport MOST .................................................... 99 3.4.1 Bus-Topologie und Physical Layer ....................................................... 99 3.4.2 Data Link Layer .................................................................................. 100 3.4.3 Kommunikationscontroller .................................................................. 105 3.4.4 Network Services und Funktionsblöcke ............................................. 106 3.4.5 Netzmanagement ............................................................................... 110 3.4.6 Höhere Protokollschichten ................................................................. 112 3.4.7 Beispiel für Systemstart und Audioverbindung ................................... 112 3.4.8 Neuere Entwicklungen: MOST150 ..................................................... 114 3.4.9 Zusammenfassung MOST ................................................................. 116

3.5 Normen und Standards ................................................................................ 117

4 Transportprotokolle ........................................................................................... 119

4.1 Transportprotokoll ISO TP für CAN nach ISO 15765-2 ................................ 119 4.1.1 Botschaftsaufbau ................................................................................ 120 4.1.2 Flusssteuerung, Zeitüberwachung und Fehlerbehandlung ................ 121 4.1.3 Dienste für die Anwendungsschicht (Application Layer Services) ...... 123 4.1.4 Protokoll-Erweiterungen ..................................................................... 124 4.1.5 Adressierung bei KWP 2000/UDS- Zuordnung von CAN ldentifiern .. 124

4.2 Transportprotokoll für FlexRay nach ISO 10681-2 ....................................... 125 4.2.1 Botschaftsaufbau und Adressierung .................................................. 125 4.2.2 Verbindungsarten und Übertragungsablauf ....................................... 126 4.2.3 Bandbreitensteuerung ........................................................................ 128 4.2.4 Fehlerbehandlung und lmplementierungshinweise ............................ 128

Inhalt XI

4.3 Transportprotokoll TP 2.0 für CAN ............................................................... 130 4.3.1 Adressierung und CAN Message ldentifier ........................................ 130 4.3.2 Broadcast-Botschaften ....................................................................... 131 4.3.3 Dynamischer Kanalaufbau und Verbindungsmanagement ................ 132 4.3.4 Datenübertragung .............................................................................. 134

4.4 Transportprotokoll TP 1.6 für CAN ............................................................... 136 4.4.1 Botschaftsaufbau ................................................................................ 136 4.4.2 Dynamischer Kanalaufbau ................................................................. 136 4.4.3 Datenübertragung und Datenrichtungswechsel ................................. 137

4.5 Transportprotokoll SAE J 1939/21 für CAN ................................................... 138 4.5.1 Übertragungsarten, Adressierung und CAN Message ldentifier ........ 138 4.5.2 Segmentierte Datenübertragung (Multi Packet) ................................. 141

4.6 Transportprotokoll DoiP nach ISO 13400 ..................................................... 143 4.7 Normen und Standards ................................................................................ 147

5 Diagnoseprotokolle- Application Layer ......................................................... 149 5.1 Diagnoseprotokoll KWP 2000 (ISO 14230-3) ............................................... 151

5.1.1 Überblick ............................................................................................ 151 5.1.2 Diagnosesitzungen (Diagnostic Managemen\) ................................... 154 5.1.3 Adressierung der Steuergeräte nach KWP 2000 und UDS ................ 156 5.1.4 Bussystem-abhängige Dienste (Network Layer Protocol Control) ..... 158 5.1.5 Fehlerspeicher lesen und löschen (Stored Data Transmission) ......... 159 5.1.6 Daten lesen und schreiben (Data Transmission), Ansteuern von

Steuergeräte-Ein- und Ausgängen (Input/Output Control) ................. 160 5.1.7 Speicherblöcke auslesen und speichern (Upload, Download) ........... 161 5.1.8 Start von Programmen im Steuergerät (Remote Routine Activation). 162 5.1.9 Erweiterte Dienste (Extended Services) ............................................. 163

5.2 Unified Diagnostic Services UDS nach ISO 14229115765-3 ........................ 163 5.2.1 Unterschiede zum KWP 2000 Diagnoseprotokoll .............................. 163 5.2.2 Überblick über die UDS-Diagnosedienste .......................................... 164 5.2.3 Response on Event Dienst ................................................................. 171

5.3 On-Board-Diagnose OBD nach ISO 15031 I SAE J1979 ............................. 173 5.3.1 Überblick OBD-Diagnosedienste ........................................................ 173 5.3.2 Auslesen des Fehlerspeichers und von Steuergerätewerten ............. 175 5.3.3 Abfrage der Testergebnisse für abgasrelevante Komponenten ......... 178 5.3.4 OBD-Fehlercodes ............................................................................... 179 5.3.5 Data Link Security .............................................................................. 181 5.3.6 Pass-Through-Programmierung ......................................................... 181 5.3.7 Beispiel ............................................................................................... 182

5.4 Weiterentwicklung der Diagnoseschnittstellen ............................................. 184

5.5 Normen und Standards ................................................................................ 185

6 Anwendungen für Messen, Kalibrieren und Diagnose (ASAM AE MCD) ...... 187 6.1 Einführung .................................................................................................... 187 6.2 Busprotokolle für Aufgaben in der Applikation (ASAM AE MCD 1MC) ......... 191

6.2.1 CAN Calibration Protocol CCP ........................................................... 192 6.2.2 Extended Calibration Protocol XCP ................................................... 200

XII Inhalt

6.2.3 AML-Konfigurationsdateien für XCP und CCP ................................... 215 6.2.4 Interface zwischen Busprotokolltreiber und Applikationssystem

ASAM MCD 1b ................................................................................... 217

6.3 Field Bus Exchange Format FIBEX ......................................................... 221

6.4 Überblick über ASAM AE MCD 2 und MCD 3 .............................................. 231

6.5 Applikationsdatensätze nach ASAM MCD 2 MC .......................................... 232 6.5.1 ASAP2/A2L-Applikationsdatensätze .................................................. 232 6.5.2 Calibration Data Format CDF und Meta Data Exchange Format MDX236

6.6 ODX-Diagnosedatensätze nach ASAM AE MCD 2D ................................... 238 6.6.1 Aufbau des ODX-Datenmodells ......................................................... 239 6.6.2 DIAG-LAYER: Hierarchische Diagnosebeschreibung ........................ 241 6.6.3 VEHICLE-INFO-SPEC: Fahrzeugzugang und Bustopologie .............. 244 6.6.4 COMPARAM-SPEC und COMPARAM-SUBSET: Busprotokoll. ........ 247 6.6.5 DIAG-COMM und DIAG-SERVICE: Diagnosedienste ........................ 249 6.6.6 Einfache und komplexe Datenobjekte ................................................ 254 6.6.7 SINGLE-ECU-JOB und MULTIPLE-ECU-JOB: Diagnoseabläufe ...... 262 6.6.8 STATE-CHART: Diagnosesitzungen .................................................. 264 6.6.9 ECU-CONFIG: Beschreibung der Steuergeräte-Konfiguration .......... 265 6.6.1 0 ECU-MEM: Beschreibung der Flash-Programmierung .................... 266 6.6.11 FUNCTION-DICTIONARY: Funktionsorientierte Diagnose .............. 268 6.6.12 Packaged ODX und ODX-Autorenwerkzeuge .................................. 269 6.6.13 ODX Version 2.2 .............................................................................. 269

6. 7 ASAM AE MCD 3-Server ......................................................................... 270 6.7.1 Funktionsgruppe M- Messen ............................................................ 271 6.7.2 Funktionsgruppe C- Kalibrieren ........................................................ 273 6.7.3 Funktionsgruppe D- Diagnose .......................................................... 273

6.8 MVCI-Schnittstelle für Diagnosetester nach ISO 22900 ............................... 275

6.9 OTX-Beschreibung von Testabläufen nach ISO 13209 ............................... 278

6.10 Normen und Standards .............................................................................. 279

7 Software-Standards: OSEK, HIS, AUTOSAR ................................................... 281

7.1 Einführung .................................................................................................... 281

7.2 OSEKIVDX ................................................................................................... 284 7.2.1 Ereignisgesteuerter Betriebssystemkern OSEKIVDX OS .................. 285 7.2.2 Kommunikation in OSEKIVDX COM .................................................. 295 7.2.3 Netzmanagement mit OSEKIVDX NM ............................................... 299 7.2.4 Zeitgesteuerter Betriebssystemkern OSEK Time, Fehlertoleranz

OSEK FTCOM und Schutzmechanismen Proteeted OSEK ............... 304 7.2.5 Scheduling, Taskprioritäten und Zeitverhalten bei OSEK OS

und AUTOSAR OS ............................................................................. 307

7.3 Hardware-Ein- und Ausgabe (HIS 10 Library, 10 Driver) .............................. 310

7.4 HIS Hardwaretreiber für CAN-Kommunikationscontroller (HIS CAN Driver) 312

7.5 HIS Flash-Lader ........................................................................................... 312

7.6 AUTOSAR .................................................................................................... 313 7 .6.1 Überblick über die AUTOSAR-Basissoftware ..................................... 315

Inhalt XIII

7.6.2 Betriebssystem AUTOSAR OS .......................................................... 326 7.6.3 Kommunikationsstack AUTOSAR COM und Diagnose DCM ............ 330 7.6.4 Netzmanagement AUTOSAR NM ...................................................... 342 7.6.5 Virtual Function Bus VFB, Runtime Environment AUTOSAR RTE

und AUTOSAR-Softwarekomponenten .............................................. 346 7.6.6 Ausblick .............................................................................................. 352

7.7 Normen und Standards ................................................................................ 353

8 Werkzeuge, Anwendungen und Einsatzgebiete .............................................. 355

8.1 Softwarekomponenten für Steuergeräte ....................................................... 355

8.2 Entwurf und Test der On-Board-Kommunikation .......................................... 355 8.2.1 Entwicklungsprozess mit CANoe von Vector Informatik ..................... 356 8.2.2 Netzwerkdesign mit dem Network Designer ...................................... 356 8.2.3 Simulation des Gesamtsystems in CANoe ......................................... 360 8.2.4 Restbussimulation als Entwicklungsumgebung für Steuergeräte ....... 361 8.2.5 Integration des Gesamtsystems ......................................................... 363 8.2.6 Einfluss von AUTOSAR auf das Netzwerkdesign .............................. 363 8.2.7 Test von AUTOSAR Softwarekomponenten ...................................... 365

8.3 Werkzeuge zur Applikation von Steuergeräten ............................................ 365 8.3.1 Steuergeräte-Applikation mit CANape von Vector Informatik ............. 367

8.4 Flash-Programmierung von Steuergeräten .................................................. 370 8.4.1 Rahmenbedingungen ......................................................................... 371 8.4.2 Flash-Speicher ................................................................................... 374 8.4.3 Flash-Programmierprozess ................................................................ 376 8.4.4 Beispiel eines Flash-Laders: ADLATUS von SMART Electronic ........ 384 8.4.5 Test und Freigabe von Flash-Ladern und Busprotokollen .................. 390

8.5 Diagnosewerkzeuge in Entwicklung und Fertigung ...................................... 394 8.5.1 Beispiel für Diagnosewerkzeuge: samDiavon Samtee Automotive ... 395

8.6 Autorenwerkzeuge für Diagnosedaten ......................................................... 405 8.7 Diagnose-Laufzeitsysteme und OTX Diagnose-Sequenzen ........................ 407

8.7.1 Einsatz des Open Test Sequence Exchange Datenformats OTX ...... 408 8.7.2 Open Diagnostic Framework von Emotive als OTX Werkzeug .......... 410

8.8 Echtzeitverhalten von Steuergeräten mit Bussystemen ............................... 412 8.8.1 Echtzeitanalyse mit SymTA/S von Symtavision ................................. 413

9 Kommunikation zwischen Fahrzeugen ............................................................ 415

9.1 Mautsysteme ................................................................................................ 415

9.2 Car2Car-Konsortium .................................................................................... 416

9.3 Normen und Standards ................................................................................ 418

Literaturverzeichnis .................................................................................................. 419

Webseite zu diesem Buch ....................................................................................... 420

Web-Adressen ......................................................................................................... 421

Abkürzungen ............................................................................................................ 423

Sachwertverzeichnis ................................................................................................ 429

132 4 Transportprotokolle

4.3.3 Dynamischer Kanalaufbau und Verbindungsmanagement Für die eigentliche Datenübertragung zwischen zwei Geräten müssen zunächst eine logische Verbindung, ein so genannter Kanal, aufgebaut und die für die spätere Über­tragung verwendeten CAN-Identifier ausgehandelt werden. Der dynamische Kanal­aufbau erfolgt wiederum mit dem Eröffnungs-JD als CAN Message ldentifier und stellt einen Spezialfall der Broadcast-Botschaften dar (Bild 4.3.2).

Sender

Channel Setup: COh Request DOh Positive Response 06 ... 08h Negative Response

Channel Setup Request mit CAN ID: Eröffnungs-ID RX-KanaiiD: ungültig

Bit 7 ... 4: 10 ... Oh gültig 1h ungültig

TX·KanaiiD : neue KanaliO des Senders

Channel Setup Response mit CAN 10: Eröffnungs-ID RX-Kanal 10: Kopie der Kanal 10 des Senders TX-KanaiiD: neue Kanal 10 des Empfängers

Bild 4.3.2: Botschaften für den dynamischen Kanalaufbau bei TP 2.0

Empfänger

Die beiden CAN-ID Felder RX ID und TX ID lassen nur Platz für 11 bit-CAN ldentifier, 29 bit-ldentifier werden gegenwärtig nicht unterstützt. Die unteren 8 Bit des ldentifiers werden in Byte 3 bzw. Byte 5 gesendet, die oberen 3 Bit in der unteren Hälfte der Bytes 4 bzw. 6. Die oberen 4 bit dieser beiden Bytes zeigen mit dem Wert Oh an, dass die CAN-Identifier gültig sind, mit dem Wert 1h, dass der jeweilige CAN-Identifier un­gültig ist. Dies ist für den Handshake-Ablaut beim Verbindungsaufbau notwendig:

• Der Sender sendet einen Channel Setup Request (Opcode COh) mit derjenigen CAN-ID im Feld TX ID, mit der er zukünftig Daten empfangen will. Das Feld RX ID markiert er als ungültig.

• Der Sender antwortet, falls er die Kanaleröffnung akzeptiert, mit einer positiven Channel Setup Response (Opcode DOh), wobei er im Feld TX ID jetzt diejenige CAN-ID zurücksendet, mit der er zukünftig Daten empfangen will. Außerdem wie­derholt er im Feld RX ID die CAN-ID. die ihm der Sender gerade als seine zukünf­tige Kanai-ID mitgeteilt hat. Das Vertauschen der Werte in den RX ID und TX ID Feldern erscheint zunächst verwirrend. Es ist aber leicht zu verstehen, wenn man sich vergegenwärtigt, dass im TX ID Feld stets diejenige CAN ID steht, an die der

4.3 TP 2.0 für CAN 133

jeweilige Empfänger seine Antworten oder eigenen Botschaften an den anderen Partner senden (TX ... transmit) muss.

• Falls der Empfänger die Verbindung ablehnt, sendet er die Channel Setup Re­sponse mit einem der Opcodes D6h ... D8h, um eine dauerhafte oder zeitweise Ablehnung der Verbindung zu signalisieren. Der Timeout beim Verbindungsaufbau beträgt 50 ms. Der Sender darf den Verbindungsversuch bis zu 10mal wiederho­len. Im Feld Application Type wird definiert, welche Anwendungsfunktion des Steuergerätes angesprochen werden soll. Der Wert 01h spezifiziert bei VW/Audi beispielsweise die KWP 2000-Diagnose.

Nach erfolgreichem Verbindungsaufbau werden alle weiteren Botschaften bis zum Verbindungsabbau dann mit den beiden ausgehandelten Kanal-/Os übertragen.

Als nächstes werden die Verbindungsparameter für den neuen Kanal ausgehandelt. Dazu sendet der Sender eine Connection Setup Request Botschaft mit den Verbin­dungsparametern des Senders (Bild 4.3.3).

CAN Message ID

Kanal ID

Connection Setup: AOh Request A 1 h Response

Byte 3 Byte 4 Byte 5 Byte S

Timing Parameter T1 ... T4

Bild 4.3.3: Parametrierung von Verbindungskanälen bei TP 2.0

Das Byte 2 enthält dabei die Blockgröße, d. h. die Anzahl der CAN-Botschaften, die hintereinander empfangen werden sollen, bevor der Empfang durch eine ACK­Botschaft (siehe unten) bestätigt werden muss. Zulässige Blockgrößen sind 1 ... 15. Die Bytes 3 bis 6 enthalten diverse Timeout-Parameter, z. B. die maximal zulässige Zeit T1 zwischen der letzten CAN-Botschaft eines Blocks und der zugehörigen Bestä­tigung durch die ACK-Botschaft, oder die minimal notwendige Zeit T3 zwischen zwei aufeinander folgenden CAN-Botschaften. Die Zeiten werden mit 6 bit Auflösung sowie einem 2 bit Skalierungsfaktor übertragen, der angibt, ob der Wert mit 100 IJS, 1 ms, 10 ms oder 100 ms multipliziert werden muss. Die Zeiten T2 und T4 sind für Erweite­rungen vorgesehen und werden im Normalfall als FFh übertragen. Der Empfänger antwortet in der Connection Setup Response Botschaft mit den entsprechenden Wer­ten für seine Seite. Anschließend ist der Kanal bereit für die eigentliche Datenübertra­gung, die im folgenden Abschnitt beschrieben wird.

Der abschließende Abbau der Verbindung erfolgt durch eine Disconnect Botschaft (Bild 4.3.4). Der Abbau wird durch den Empfänger bestätigt, in dem er seinerseits mit einer Disconnect Botschaft antwortet. Anschließend dürfen keine Botschaften mehr mit den dieser Verbindung zugeordneten Kanal-/Os gesendet und empfangen werden.

ln komplexen Fahrzeugen werden häufig Gateways zur Anbindung des Diagnosetes­ters sowie zur Verbindung mehrerer Bussysteme eingesetzt. Da diese Gateways in

322 7 Software-Standards: OSEK, HIS, AUTOSAR

triebszustands des Steuergerätes (ECU State Manager) vom Einschalten (Start up) über Stromsparzustände (S/eep, Wake up), den Notlaufbetrieb im Fehlerfall (Limp Horne) bis zum Abschalten (Shutdown) . Die Überwachung des zeitlichen Ablaufs der Anwendungssoftware erfolgt durch den Watchdog Manager.

Bibliotheken mit Hilfstunktionen

Funktionen, die Algorithmen für Regler, Interpolationen und sonstige Fest- und Gleitkommaberechnungen (IFL, MFL), Authentifizierungs-, Kompressions- und Verschlüsselungsverfahren (CAL, CSM), Prüfsummenberechnung (CRC) sowie Biomanipulation (BFX) implementieren.

Fehlerspeicher, Funktionssteuerung und Diagnoseschnittstelle

Fehler, die in den Anwendungen und Modulen der Basissoftware auftreten, wer­den an ein zentrales Modul, den Diagnostic Event Manager (DEM) gemeldet, das einen Fehlerspeicher verwaltet und Schnittstellen zum Diagnosemodul (DCM) so­wie zur Funktionssteuerung (FIM) aufweist.

ECU Boolloader y G lnil Sequence 1 Startup ~----, Off

State SlartOS() Resel Manager lnil Sequence 2 Power On

Rle_Siart()

Wakeup lnit Sequence P~W,:'

( Wakeup )t------+

Deinil Sequence 1

Resel

Bild 7.6.6: Betriebszustände des Steuergerätes (vereinfacht)

Rte_Siop() Deinil Sequence 2

NvM_WrlleA/1() ShuldownOS()

Deinil Sequence 3

Das AUTOSAR-Steuergerät kann sich in einem der im Bild 7.6.6 dargestellten Zu­stände befinden. Die Zustände werden vom ECU State Manager (EcuM) verwaltet, der für die lnitialisierung des Steuergerätes, der Basissoftware und den Start des Be­triebssystems sowie dessen geordnetes Abschalten zuständig ist. Dauerhaft ist das Gerät entweder abgeschaltet (Off), eingeschaltet (Run) oder in einem Stromspar­modus (S/eep), die übrigen Zustände werden nur kurzzeitig beim Übergang zwischen diesen drei Grundzuständen durchlaufen. Unmittelbar nach dem Reset wird zunächst der Flash-Lader (Boot/oader) aktiviert, dessen Aufbau und Funktionsweise von AUTO­SAR derzeit nicht spezifiziert wird. ln der Regel wird dort geprüft, ob sich ein gültiges Programm im Flash-ROM befindet und dieses dann gestartet. Danach beginnt im

7.6 AUTOSAR 323

Zustand Startup die Grundinitialisierung des Mikrocontrollers mit der Funktion EcuM -Init () und das Betriebssystem (AUTOSAR OS) wird über den bereits von OSEK OS bekannten Aufruf Startos () gestartet. Bereits unter Kontrolle des Betriebssys­tems erfolgt dann in dessen erster Task EcuM MainFunction () die weitere lnitiali­sierung des Steuergerätes. Am Ende dieser mehrstufigen Startphase sind die Basis­software mit dem Betriebssystem, den Kommunikationsschnittstellen, den Hardware­treibern sowie das Runtime Environment RTE vollständig funktionsfähig und das Sys­tem geht in den Zustand Run über. Für die lnitialisierung stellen die Treiber in der Regel eine Funktion ModuleName Init () zur Verfügung, die vom EcuM aufgerufen wird. ln welcher Reihenfolge dies für die einzelnen Module geschieht, muss bei der Konfiguration des Systems festgelegt werden.

Das Steuergerät verbleibt im Zustand Run, wenn mindestens eine Anwendungskom­ponente den Zustand mit EcuM Reques tRUN () dauerhaft anfordert. Der Übergang in den Zwischenzustand Shutdown erfolgt, wenn alle Komponenten, die den Zustand Run angefordert haben. ihn durch EcuM ReleaseRUN () wieder freigegeben. Ob das Steuergerät von dort aus vollständig abgeschaltet wird (Zustand Off), ein Software­Reset ausgelöst oder in den Stromsparmodus (Zustand Sleep) umgeschaltet wird, hängt davon ab, welcher Zielzustand von der Anwendung mit Hilfe der Funktion EcuM SelectShutdownTarget () eingestellt wurde. Welche Softwarekomponenten die genannten Funktionen überhaupt verwenden und den Zustand des Steuergerätes beeinflussen dürfen, wird bei der Konfiguration des Systems festgelegt und zur Lauf­zeit überprüft.

Beim Abschalten werden in mehreren Stufen Softwaremodule und Hardwaretreiber deinitialisiert, das Runtime Environment RTE angehalten, Fehlerspeicher- und andere persistente Daten in den nicht-flüchtigen Speicher geschrieben, das Betriebssystem gestoppt und schließlich das Steuergerät abgeschaltet bzw. über einen Reset ein Neustart ausgelöst. Beim Übergang in den Zustand Sleep werden diejenigen Hard­warekomponenten, die das Gerät wieder aufwecken sollen, entsprechend initialisiert. ln der Regel lösen diese Komponenten, z. B. Bedienschalter, Zeitgeber oder Kommu­nikationscontroller, die eine Datenbotschaft empfangen, einen Hardwareinterrupt aus, in diesem Zusammenhang als Wakeup Event bezeichnet. Welche Baugruppen des Gerätes bzw. Mikrocontrollers durch Abschalten der Takt- oder Spannungsversorgung in den Stromsparmodus geschickt werden, ist gerätespezifisch.

Die vorliegende Darstellung ist stark vereinfacht. Alle beschriebenen Zustände enthal­ten mehrere Unterzustände. Beim Übergang zwischen den Zuständen werden prak­tisch stets sogenannte Callout- und Callback-Funktionen aufgerufen. Callout-Funktio­nen sind Funktionen, in denen die Entwickler steuergerätespezifische Funktionen im­plementieren können. Über Callback-Funktionen (Notifications) werden die anderen Softwaremodule über die Zustandsänderungen informiert.

Mit AUTOSAR 4.0 wurde alternativ zum oben beschriebenen ECU State Manager mit seinen fest vordefinierten Zuständen und Zustandsübergängen (Fixed State Machine) die Möglichkeit eingeführt, die Zustände und Übergänge frei zu wählen. Dieser neue ECU State Manager behandelt nur noch die frühe Startup und die späte Shutdown Phase nach dem von AUTOSAR vordefinierten Konzept und übergibt die weitere Be­handlung, insbesondere den Ablauf der Run bzw. S/eep-Zustände an andere Mana­ger, die vom Hersteller frei definiert werden dürfen.