DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_OS FIG-98eb12554c817d89 745 × 681 px 1 Release(s)

Figure 9.2: Error Hook sequence chart The above sequence chart shows the sequence of error hook calls in case a service does not return with E_OK. Note that in this case the general error hook and the OS-Application specific error hook are called.

SHA-256 Inhalts-Fingerabdruck: 98eb12554c817d891ac81dccf6451e3f4e0d312ee8f3388066580334fa01eb5f
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm (sd Interactions) zur Spezifikation des Fehlerbehandlungsmechanismus im AUTOSAR Operating System (Classic Platform, BSW OS). Es veranschaulicht das Zusammenspiel zwischen einer aufrufenden OS-Application (OS-Appl. <App>) und dem Betriebssystemkern (operating system) beim synchronen Aufruf von OS-Systemdiensten und dem zweistufigen Aufruf von zentralen sowie anwendungsspezifischen Error-Hooks im Fehlerfall.

2. Komponenten, Entitäten & Schnittstellen

Lebenslinien:

  • OS-Appl. <App>: Aufrufende OS-Application (speicher- und partitionsgeschützter Kontext <App>).
  • operating system: AUTOSAR OS Kernel als Ausführungsinstanz der Systemdienste und Dispatcher der Hook-Routinen.

Bedingungen und Guards:

  • Notiz-Vorbedingung (condition: <System service> is called outside an Error Hook AND both the system-/appl,-specific Error Hook are configured): Der Systemdienst wird außerhalb eines bereits aktiven Error-Hooks aufgerufen, und sowohl der systemweite Error-Hook als auch der anwendungsspezifische Error-Hook sind im OS konfiguriert (OsErrorHook = TRUE und OsAppErrorHook = TRUE).
  • Äußerer alt-Block mit Guard [condition]: Kapselt den gesamten Ablauf unter Einhaltung der genannten Vorbedingung.
  • Innerer alt-Block mit Guard [return != E_OK]: Selektiert den Fehlerbehandlungspfad, wenn der aufgerufene Dienst einen Fehlerstatus ungleich E_OK meldet.

Nachrichten und Schnittstellen:

  • Synchroner Aufruf: <system service> which returns a value of type StatusType von OS-Appl. <App> an operating system.
  • Lokale Hook-Aktivierung: ErrorHook (<Error>) als Self-Message auf operating system (Aufruf des globalen System-Error-Hooks mit Fehlerparameter <Error>).
  • Anwendungsbezogene Hook-Aktivierung: ErrorHook_<App> (<Error>) vom operating system an OS-Appl. <App> (Aufruf des partitionsspezifischen Error-Hooks).
  • Rückkehr aus partitioniertem Hook: gestrichelte Antwortnachricht ohne Parameter von OS-Appl. <App> an operating system.
  • Dienst-Rückgabewert: gestrichelte Antwortnachricht StatusType value vom operating system an OS-Appl. <App>.

3. Dynamisches Verhalten & Sequenzablauf

  1. Eine Task oder ISR innerhalb der OS-Application <App> ruft synchron einen Systemdienst auf (<system service>), dessen Funktionssignatur einen Rückgabewert des Typs StatusType deklariert.
  2. Das Betriebssystem verarbeitet die Dienstanforderung und ermittelt den Rückgabestatus.
  3. Ergibt die Überprüfung einen Fehlerstatus (return != E_OK): a) Das Betriebssystem ruft zunächst synchron den globalen System-Error-Hook ErrorHook (<Error>) auf. b) Nach Beendigung des globalen Hooks ruft das Betriebssystem den anwendungsspezifischen Error-Hook ErrorHook_<App> (<Error>) im Kontext der betroffenen OS-Application auf. c) Der anwendungsspezifische Hook wird ausgeführt und kehrt zum Betriebssystem zurück.
  4. Nach Abschluss der Hook-Verarbeitung (bzw. direkt bei fehlerfreiem Status E_OK) liefert das Betriebssystem den ermittelten StatusType value an den Aufrufer in OS-Appl. <App> zurück.

4. Normative Relevanz & Entwickler-Hinweise

  • Rekursionsschutz: Systemaufrufe innerhalb eines Error-Hooks dürfen im Fehlerfall keinen weiteren Error-Hook auslösen (called outside an Error Hook), um Rekursionskaskaden und Stack-Überläufe zu unterbinden.
  • Hook-Priorisierung und Reihenfolge: Der systemweite ErrorHook wird stets strikt vor dem anwendungsspezifischen ErrorHook_<App> ausgeführt.
  • Kontextschnittstelle & Diagnose: Innerhalb der Hooks kann über AUTOSAR-Makros (z. B. OSErrorGetServiceId() und parameterbezogene Makros) auf den auslösenden Service und die Parameter zugegriffen werden.
  • Fehlerfortpflanzung: Die Hook-Ausführung unterdrückt nicht die reguläre Rückgabe des Fehlercodes an den aufrufenden Kontext; der Aufrufer erhält weiterhin den konkreten StatusType-Fehlercode (z. B. E_OS_ID, E_OS_VALUE, E_OS_STATE) zur lokalen Auswertung.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R3.2.3 → R4.0.3 keine inhaltliche Änderung Vorgänger: FIG-ccac37a52e87c3ad

Keine inhaltlichen Änderungen erkennbar.

R4.0.3 → R4.1.3 keine inhaltliche Änderung Nachfolger: FIG-475a8a0c9c4137ac

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

sd Interactions | OS-Appl. | alt | [condition] | <App> | operating | system | condition: <System service> is called outside an Error Hook AND both the system-/appl,-specific Error Hook are configured | <system service> which returns a value of type StatusType | alt | [return != E_OK] ErrorHook (<Error>) | ErrorHook_<App> (<Error>) | StatusType value

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.0.3 AUTOSAR_SWS_OS S. 170 9.2 Figure 9.2: Error Hook sequence chart The above sequence chart shows the sequence of error hook calls in case a service does not return with E_OK. Note that in this case the general error hook and the OS-Application specific error hook are called.