Figure 5.4: 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 analog zu ara::core::ErrorCode::ValueType / AUTOSAR ErrorDomain).
    • Spezifizierte Werte: 11, 12, 111, 23, 24, 244.
  • Next State (Spalte 2): Zielzustand des Zustandsautomaten nach Auftreten des Fehlers (Modellierung über ModeDeclaration oder stark typisierte Enums enum class State : uint8_t).
    • Spezifizierte Zielzustände: 0, 2, 3, 4, 5.
• Kardinalitäten & Relationen:
  • Funktionale Abbildung: $\delta_{\text{error}}: \text{Execution Error} \rightarrow \text{Next State}$.
  • n:1-Konsolidierung (Fehlerbündelung): Mehrere unterschiedliche Fehlerursachen münden in denselben Recovery- oder Degradierungszustand (z. B. führen sowohl Fehler 11 als auch 111 zu Next State = 2).
  • Safe-State-Rückfall: Fehler 24 mappt direkt auf Zustand 0 (Initial-, Standby- oder gesicherter Aus-Zustand).
  • Spezifische Degradierungszustände: Fehler 12 → State 3, Fehler 23 → State 4, Fehler 244 → State 5 (dedizierte Notlauf- oder Diagnosemodi).

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlererfassung & Triggering:
   • Ein interner Worker-Thread, Treiberaufruf oder Subsystem meldet ein Fehlschlagen (z. B. negativer ara::core::Result<T> mit spezifischem ErrorCode, Timeout bei Kommunikation via ara::com, oder Execution-Manager-Fehler via ara::exec).
2. Lookup in der ErrorTable:
   • Die State-Machine-Engine empfängt den Fehlervektor und schlägt den Wert von Execution Error in der Tabelle nach.
3. Zustandsübergang (Error Transition):
   • Reguläre Abläufe des aktuellen Zustands werden abgebrochen.
   • Ausführung atomarer Bereinigungsaktionen (Exit Actions des bisherigen Zustands).
   • Zustandszeiger wird unmittelbar auf den ermittelten Next State gesetzt.
   • Ausführung der Initialisierungsroutinen (Entry Actions) des Zielzustands (z. B. Deaktivierung fehlerhafter Funktionsgruppen, Drosselung von Schnittstellen).
4. Signalisierung & Notifizierung:
   • Publikation des neuen Zustands an registrierte Adaptive Applications über das Service-Interface (z. B. StateMachineNotification::CurrentState).
   • Ggf. Protokollierung via ara::log und Meldung an das Platform Health Management (ara::phm) oder Diagnostic Management (ara::diag).
5. Abbruchbedingung / Undefinierte Fehler:
   • Tritt ein Execution Error auf, der nicht in der Tabelle deklariert ist, greift eine globale Default-Policy (z. B. sofortiger Übergang in den Safe State 0 oder Auslösen eines Platform-Health-Recovery-Triggers).

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?