Figure 3: Det_ReportError with configured hook

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit synchronem Aufrufmuster, konfigurierter Bedingungsnotiz und globalem Abbruch-/Zustands-Invarianten-Block (HALT).
• Architektur-Kontext: AUTOSAR Classic Platform (Release 4.3.1), Services Layer (Basic Software / BSW).
• Technischer Zweck: Spezifikation des Kontrollflusses im Modul Det (Default Error Tracer) bei Detektion eines Entwicklungsfehlers (Development Error), wenn über den BSW-Konfigurationsparameter mindestens ein Integrator-Hook (DetNotification bzw. DetErrorHook) aktiviert ist. Das Diagramm demonstriert das für Entwicklungs-/Debug-Phasen typische Trap-Verhalten, bei dem nach Abarbeitung des Hooks keine Rückkehr zum Aufrufer erfolgt, sondern das Gesamtsystem gezielt angehalten wird (HALT).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • Det User: Beliebiges BSW-Modul (z. B. Can, Spi, Com) oder eine Software-Komponente (SW-C), welche Entwicklungsfehler prüft und meldet.
  • «module» Det: Das standardisierte AUTOSAR BSW-Basissystem-Modul (Service Component) Default Error Tracer.
  • Integrator Code: OEM- oder projektspezifischer Callout-Code / Callback-Handler (z. B. Trace-Buffer-Schreiber, Hardware-Debugger-Trap).
• Schnittstellen & Parameter:
  • Det_ReportError(return, ModuleId, InstanceId, ApiId, ErrorId):
    • Standardisierte synchrone C-Funktionsschnittstelle:

      Std_ReturnType Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId);

    • ModuleId (uint16): Eindeutige Kennung des meldenden BSW-Moduls gemäß AUTOSAR BSW Module ID Allocation.
    • InstanceId (uint8): Index der Modulinstanz (wichtig bei Multi-Channel- oder Multi-Core-Instanziierung).
    • ApiId (uint8): Eindeutige Funktions-ID der aufrufenden Service-Funktion innerhalb des Moduls.
    • ErrorId (uint8): Modulspezifischer Fehlercode (Development Error Code).
    • return: Formaler Rückgabewert (Std_ReturnType), der im Normalfall E_OK liefert.
  • <User_ErrorHooks>(return, ModuleId, InstanceId, ApiId, ErrorId):
    • Konfigurierbare Funktionszeiger-Tabelle / Callout-Schnittstelle (DetNotification Container).
    • Übernimmt die vollständigen Metadaten des Fehlers unverändert.
    • Rückgabewert :E_OK quittiert die Abarbeitung des Hooks an den DET.
• Bedingung / Annotierung:
  • <Det_Notification> configured: Statische Vorbedingung in der Modulkonfiguration (DetNotification / DetErrorHook aktiv).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Det User stellt eine ungültige Parameterübergabe, Nullpointer-Referenzierung oder einen falschen Zustand fest und setzt einen synchronen Aufruf von Det_ReportError(...) ab.
2. Hook-Dispatch: Der DET prüft die Konfiguration (<Det_Notification> configured) und leitet den Fehlerkontext unverzüglich und synchron an den konfigurierten Hook weiter: <User_ErrorHooks>(...).
3. Hook-Ausführung & Return: Der Integrator Code führt seine Aktionen aus (z. B. Logging im RAM-Puffer, Triggern von GPIOs für Logikanalysator) und kehrt synchron mit :E_OK in den DET zurück.
4. Zustandsübergang HALT (Kein Return zum Caller):
   • Es existiert explizit keine Return-Kante zurück zum Det User.
   • Die Ausführung mündet in den terminalen Zustand HALT (z. B. while(1), __BKPT() oder kontrollierter Reset/Watchdog-Trap).
   • Der vollständige Stacktrace (Det User → Det → Hook) bleibt im Core-Dump/Debugger unverändert erhalten.

4. Normative Relevanz & Entwickler-Hinweise

• Debug- vs. Release-Konfiguration (DEV_ERROR_DETECT):
  • Test/Debug-Build: Das dargestellte HALT-Verhalten ist gewollt, um das "Fail-Fast"-Prinzip sicherzustellen und Fehler unmittelbar am Entstehungsort ohne Seiteneffekte per Hardware-Debugger einzufrieren.
  • Serien-Build (Production Code): In Serien-ECUs muss das Trap-Verhalten zwingend unterbunden werden (Verfügbarkeits- und ASIL-Risiko). Det_ReportError wird entweder über Pre-Compile-Schalter komplett wegoptimiert (((void)0)) oder über Ringpuffer ohne Systemstopp protokolliert, woraufhin die Funktion regulär mit E_OK an den Aufrufer zurückkehrt.
• Kontext- & Reentrancy-Restriktionen:
  • Det_ReportError ist reentrant und darf aus Task- sowie Interrupt-Kontexten (CAT1/CAT2 ISRs) aufgerufen werden.
  • Der in Integrator Code hinterlegte Hook muss zwingend ISR-fest, nicht-blockierend und frei von rekursiven DET-Aufrufen sein (Verhinderung von Endlos-Kaskaden).
  • Ein HALT in einer High-Priority-ISR blockiert das Gesamtsystem einschließlich Betriebssystem-Scheduler und FTTM-Überwachung (Watchdog).
• API-Vertrag:
  • BSW-Module dürfen nach Absetzen von Det_ReportError niemals davon ausgehen, dass der Fehler automatisch "korrigiert" wird. Im Fall einer Rückkehr muss das meldende Modul die fehlerhafte Ausführung sicher abbrechen (z. B. mit return E_NOT_OK;).