Figure 5.3: StateMachine ErrorTable

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Tabellarische Fehler-Zustandsübergangsmatrix (Error Transition Table / StateMachine ErrorTable) bzw. deklarative Lookup-Tabelle für deterministische endliche Zustandsautomaten (Finite State Machine, FSM).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R23-11), Spezifikationsleitfaden AUTOSAR_AP_EXP_InterfacesGuidelines, Kapitel 5 (State Management Architecture & State Machine Design Patterns).
• Technischer Zweck: Komplementäre Ergänzung zur regulären Anforderungstabelle (Transition Request Table). Definiert das deterministische Fehlerbehandlungs- und Reaktionsmodell für zustandsbehaftete Komponenten (z. B. Adaptive Applications, Service Provider oder State Management Engines). Jeder auftretende Ausführungsfehler (Execution Error) wird unmittelbar und deterministisch auf einen definierten Folgezustand (Next State – Fail-Safe, Degraded Mode oder Reset) abgebildet.

2. Komponenten, Entitäten & Schnittstellen

• Tabellenstruktur & Datenfelder:
  • Execution Error (Spalte 1): Diskreter Fehler-Identifikator bzw. Fehlerklasse (numerische Codierung oder Wildcard).
    • Spezifizierte Werte: 11, 12, 111, 23, 24, ANY.
  • Next State (Spalte 2): Zielzustand des Zustandsautomaten nach Auftreten des Fehlers als symbolischer Modusbezeichner (ModeDeclaration bzw. stark typisiertes enum class State).
    • Spezifizierte Zielzustände: Off, Recovery, Startup, Suspend, Shutdown.
• Kardinalitäten & Relationen:
  • Funktionale Abbildung: $\delta_{\text{error}}: \text{Execution Error} \rightarrow \text{Next State}$.
  • n:1-Konsolidierung (Fehlerbündelung): Sowohl Fehler 11 als auch 111 führen in denselben Folgezustand Recovery.
  • Spezifische Fehlerreaktionen: Fehler 12 → Startup, Fehler 23 → Suspend, Fehler 24 → Off.
  • Universelle Fehlerbehandlung (Wildcard/Catch-All): Die Bedingung ANY fängt alle übrigen Fehler ab und überführt die State Machine deterministisch in den Zustand Shutdown.

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlererfassung & Triggering:
   • Ein Subsystem oder interner Thread signalisiert einen Ausführungsfehler (z. B. via negativer ara::core::Result<T> mit spezifischem ErrorCode oder Meldevektor an die State-Machine-Engine).
2. Lookup in der ErrorTable:
   • Die State-Machine-Engine vergleicht den empfangenen Fehleridentifikator mit den deklarierten Werten der Spalte Execution Error.
3. Deterministischer Zustandsübergang (Error Transition):
   • Bei Übereinstimmung mit einem spezifischen Code (11, 12, 111, 23, 24) wird unmittelbar in den zugeordneten Folgezustand gewechselt (Recovery, Startup, Suspend, Off).
   • Laufende Aktionen des Ausgangszustands werden abgebrochen (Exit Actions), gefolgt von den Entry Actions des neuen Zustands.
4. Catch-All-Behandlung via ANY:
   • Ist der gemeldete Fehlercode nicht explizit tabelliert, greift die Auffangregel ANY, wodurch das System kontrolliert in den Zustand Shutdown überführt wird.
5. Signalisierung & Notifizierung:
   • Der neue Zustand wird über die Service-Schnittstelle publiziert (z. B. StateMachineNotification::CurrentState), geloggt (ara::log) und bei Bedarf an ara::phm oder ara::diag gemeldet.

4. Normative Relevanz & Entwickler-Hinweise

• Deklaratives Design statt Kontrollfluss-Verschachtelung:
  • Trennung von Fehlererkennung und Fehlerreaktion. Vermeidung hardcodierter try-catch-Blöcke oder tiefer switch-case-Verzweigungen im Applikationscode zugunsten einer zentral wartbaren, tabellengesteuerten Fehlerstrategie.
• Funktionale Sicherheit (ISO 26262 & FHTI):
  • Sicherheitskritische Funktionen (ASIL) fordern ein deterministisches Verhalten im Fehlerfall. Die Tabelle garantiert, dass das System innerhalb des definierten Fehlertoleranz-Zeitintervalls (Fault Handling Time Interval, FHTI) in einen sicheren Zustand (Safe State 0 oder definierter Degraded State) übergeht.
• Implementierungs-Richtlinien (C++14/C++17 im Adaptive Stack):
  • Allokationsfreie Umsetzung: Zur Gewährleistung harter Echtzeit und Vermeidung von Heap-Fragmentierung im Fehlerpfad ist die Tabelle als constexpr std::array<std::pair<ErrorCode, State>, N> oder flache, sortierte Compile-Time-Lookup-Struktur zu implementieren (O(1) bzw. deterministisches $O(\log N)$).
  • Thread-Safety: Fehler-Lookup und Zustandswechsel müssen atomar oder mutex-geschützt erfolgen, um Race Conditions bei simultan eintreffenden Fehlern aus mehreren Threads zu verhindern.
• Manifest-Konsistenz:
  • Die numerischen Zustände und Fehlercodes müssen strikt mit den im ARXML-Manifest definierten ModeDeclarationGroup-Zuständen und den zugeordneten ErrorDomain-Spezifikationen übereinstimmen.

Die Analyse zu Figure 5.4: StateMachine ErrorTable aus AUTOSAR_AP_EXP_InterfacesGuidelines (R23-11) ist vollständig und schließt direkt an die zuvor referenzierte Transition Request Table (Figure 5.3) an.

Gibt es weitere Schaubilder oder Spezifikationsabschnitte aus dem Cluster State Management (ara::sm) oder Execution Management (ara::exec), die vertieft analysiert werden sollen?