Figure 7.29: Overview for the StateMachine ErrorCodes handling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Ursache-Wirkungs- / Fehlerklassifikations-Diagramm (UML-basiertes Kontext- und Anwendungsfalldiagramm mit Akteuren und Fehlerereignisknoten).
• Technischer Zweck: Systematische Aggregation aller externen und internen Fehlerursachen, die innerhalb des AUTOSAR Adaptive Platform (AP) Functional Clusters State Management (SM) zur Generierung und Auswertung standardisierter ErrorCode-Instanzen führen.
• Funktionale Einordnung: Dient als Bindeglied zwischen Laufzeitüberwachung (Platform Health Management, PHM), Prozess- und Zustandsausführung (Execution Management, EM) sowie der internen Regelausführung im State Management zur Gewährleistung deterministischer Übergänge in sichere Zustände (Safe State / Degraded Mode).

2. Komponenten, Entitäten & Schnittstellen

• Akteure (UML Actors / Functional Clusters):
  • Platform Health Management (PHM): Meldet Integritäts- und Überwachungsverletzungen von Prozessen (Alive-, Deadline-, Logical-Supervision).
  • Execution Management (EM): Führt Zustandswechselanfragen für Funktionsgruppen aus und meldet Prozesslebenszyklus-Zustände.
  • State Management (SM): Zentrale Instanz zur Definition, Steuerung und Überwachung von System-, Maschinen- und Funktionsgruppenzuständen.
• Zentrale Entität:
  • ErrorCode (dargestellt als UML-Komponente): Abstraktion der Fehlerereignisse bzw. ara::core::ErrorCode, welche als Trigger für transitionsbezogene Fehlerbehandlungsroutinen (ErrorActionLists) im Zustandsautomaten dienen.
• Fehlerquellen & Schnittstellen (Klassifikationsknoten):
  • Extern induzierte Fehlerpfade:
    • Process failed:
      • Schnittstelle zu PHM: Benachrichtigung über RecoveryHandler bei Fehlschlag eines überwachten Prozesses.
      • Schnittstelle zu EM: Abfrage/Meldung über GetExecutionError und undefinedStateCallback bei unerwartetem Prozesstod oder Inkonsistenz.
    • FunctionGroup transition request failed:
      • Schnittstelle zu EM: Scheitern einer synchronen/asynchronen Zustandsanforderung via SetState (z. B. Nichterreichen des Zielzustands durch Prozessstartfehler).
  • SM-intern induzierte Fehlerpfade:
    • Processing Agent ActionList failed: Fehler bei der Abarbeitung einer Aktionsliste, die einem spezifischen internen Agenten zugeordnet ist.
    • Start or stop of an Agent failed: Scheitern der Instanziierung, Aktivierung oder Beendigung eines SM-internen Agenten.
    • Processing ActionList times out: Überschreitung des konfigurierten Watchdog-/Timeout-Intervalls während der synchronen oder asynchronen Abarbeitung einer Aktionssequenz.
    • Processing EnterSuspendToRam or LeaveSuspendToRam fails: Scheitern der hardwarenahen Power-Management-Übergänge für Low-Power-Zustände (Suspend-to-RAM bzw. Resume).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering & Fehlerdetektion:
   • Asynchroner Health-Event: PHM stellt eine Regelverletzung fest und ruft den registrierten RecoveryHandler des SM auf.
   • Asynchroner Execution-Event: EM meldet via undefinedStateCallback den Ausfall eines Prozesses oder signalisiert per GetExecutionError die Nichterfüllung einer Prozessabhängigkeit.
   • Synchrone/Future-basierte Anforderung: SM fordert via SetState einen Funktionsgruppen-Wechsel an; EM antwortet mit Fehlerstatus (FunctionGroup transition request failed).
   • Interner Timer-Ablauf: Ein dedizierter Timer für eine laufende ActionList läuft ab, bevor alle Teilaktionen quittiert wurden (Processing ActionList times out).
   • Power-Mode-Fehlschlag: Vorbereitende oder abschließende Aktionen beim Wechsel in/aus SuspendToRAM schlagen fehl.
2. Fehler-Mapping & Propagation:
   • Die spezifische Ursache wird in einen plattformkonformen ErrorCode transformiert.
   • Der ErrorCode wird an die StateMachine-Engine übergeben und fungiert dort als Guard-Bedingung oder Event-Trigger.
3. Reaktionsmuster & Abbruch:
   • Laufende reguläre Aktionslisten werden unverzüglich abgebrochen oder in einen definierten Rollback überführt.
   • Ausführung der im Manifest hinterlegten ErrorActionList zur Wiederherstellung eines stabilen Maschinen- oder Funktionsgruppenzustands (z. B. Notlauf, Neustart betroffener Funktionsgruppen oder Plattform-Reset).

4. Normative Relevanz & Entwickler-Hinweise

• Anforderungsabdeckung:
  • RS_SM_00001 / RS_SM_00005: Gewährleistet konsistente Zustandsführung im Gesamtsystem und deterministische Schnittstellenbedienung in Richtung EM.
  • RS_SM_00402: Erzwingt die deterministische Fehlerbehandlung während Zustandsübergängen ohne undefiniertes Systemverhalten.
  • SWS_SM_00687 / SWS_SM_00688: Normieren die Bereitstellung, Erkennung und das konsistente Mapping aller gelisteten Fehlerbedingungen auf ErrorCode-Typen sowie die Pflicht zur Bereitstellung zugehöriger Fehlerbehandlungsstrategien.
• Konsequenzen für Stack- und Plattform-Entwickler:
  • Mapping-Konsistenz: Rückgabewerte aus ara::exec::ExecErrc und ara::phm-Meldungen müssen verlustfrei und ohne Blockierung des SM-Event-Loops in die interne Fehlerrepräsentation übernommen werden.
  • Agenten-Lifecycle: Für interne SM-Agenten müssen robuste Start-/Stopp-Mechanismen implementiert sein, die auch bei Ressourceneinschränkungen nicht hängen bleiben.
• Konsequenzen für System-Integratoren & Applikations-Entwickler:
  • Timeout-Budgetierung: Die Timeouts für ActionLists müssen in den Manifesten (ARXML) ausreichend groß für Worst-Case-Laufzeiten parametriert sein, jedoch straff genug, um ASIL-relevante Fehlerreaktionszeiten (FHTT) einzuhalten.
  • Applikationsverhalten bei State Transitions: Prozesse einer FunctionGroup müssen auf Terminierungs- und Aktivierungssignale innerhalb der vereinbarten Zeitschranken reagieren; Verzögerungen führen direkt zum globalen Processing ActionList times out und damit zur Auslösung von Plattform-Rückfallstrategien.