Figure 7.14: ErrorRecoveryTable

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Tabellarisches Konfigurations- und Zuordnungsmodell (Lookup-/Mapping-Tabelle für Zustandsübergänge).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) (AUTOSAR_SWS_StateManagement, Kapitel 7 Functional Specification).
• Technischer Zweck: Definition deterministischer, unbedingter Fehler-Wiederherstellungsübergänge (unconditional recovery transitions) innerhalb einer SM-Zustandsmaschine (StateMachine). Die Tabelle verknüpft platform- bzw. prozessseitig detektierte Laufzeitfehler (gemeldet durch Execution Management / EM oder Platform Health Management / PHM) direkt mit definierten Folgezuständen (z. B. Notlauf, Degradierung, Prozess-Restart, Safe State).

2. Komponenten, Entitäten & Schnittstellen

• Dargestellte Datenstruktur:
  • ErrorRecoveryTable: Konfigurations-Artefakt im State-Management-Metamodell zur Abbildung von Fehlerereignissen auf Zielzustände.
  • Execution Error (Spalte 1): Diskrete numerische Fehlerbezeichner (uint32/Integer-Werte), die spezifische Fehlerursachen oder Exit-Zustände von Prozessen bzw. Function Groups abbilden (im Schaubild: 11, 12, 111, 23, 24, 244). Im Metamodell korrespondieren diese mit Attributen des Typs ProcessExecutionError.executionError.
  • Next State (Spalte 2): Zielzustands-Identifikatoren bzw. Indizes der Zustandsmaschine (0, 2, 3, 4, 5), die nach Auftreten des zugehörigen Fehlers eingenommen werden müssen.
• Beziehungen & Kardinalitäten:
  • N : 1-Relation: Mehrere disjunkte Fehlerursachen können auf denselben Folgezustand abgebildet werden (z. B. führen sowohl Fehler 11 als auch 111 zu Next State = 2).
  • 1 : 1-Eindeutigkeit: Jedem definierten Execution Error ist innerhalb der Tabelle genau ein deterministischer Next State zugewiesen (Injektivität vom Fehler auf den Folgezustand; keine Mehrdeutigkeit/Nicht-Determinismus).

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlerdetektion & Signalisierung (Trigger): Ein Prozess terminiert fehlerhaft, verletzt Watchdog-/Deadline-Vorgaben oder meldet einen Ausfall an PHM/EM. EM/PHM meldet das resultierende ExecutionError-Ereignis asynchron an den State Management Cluster.
2. Tabellen-Lookup: SM fängt das Ereignis ab und evaluiert die ErrorRecoveryTable der betroffenen Zustandsmaschine anhand des empfangenen numerischen Fehlercodes.
3. **Unbedingter Zustandsübergang (Unconditional Transition):**
   • Wird ein passender Eintrag gefunden, feuert der Zustandsübergang priorisiert und unmittelbar – reguläre Transition-Guards oder Einträge aus der TransitionRequestTable werden umgangen.
   • Das System wechselt in den konfigurierten Next State.
4. Folgeaktionen: SM leitet Aktionen zur Fehlerbehebung ein (z. B. Anforderung neuer Function-Group-Zustände via ara::exec, Herunterfahren kompromittierter Prozesse oder System-Fallback nach State 0).
5. Abbruch-/Fehlerfall: Trifft ein Execution Error ein, der in der ErrorRecoveryTable nicht hinterlegt ist, greift das plattformspezifische Default-Verhalten (z. B. Übergang in einen globalen Machine-Safe-State oder System-Reset).

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration im Execution- & SM-Manifest (ARXML):
  • Systemintegratoren müssen alle relevanten Exit-Codes und Health-Fehler (ProcessExecutionError) lückenlos auf gültige ModeDeclaration-Zustände mappen.
  • Lücken in der Tabelle führen bei nicht abgefangenen Fehlern zu undefiniertem Verhalten oder unkontrollierten Platform-Resets.
• Prioritätsmodell gegenüber TransitionRequestTable:
  • Einträge der ErrorRecoveryTable besitzen strikten Vorrang vor regulären externen Zustandsanfragen (z. B. von der SMControlApplication oder via Network Management).
• Vermeidung von Reset-/Restart-Schleifen (Safety-Design nach ISO 26262):
  • Applikations- und Stack-Entwickler müssen sicherstellen, dass wiederkehrende Fehler nicht in unendlichen Übergangszyklen enden (z. B. ständiges Wiederanlaufen über denselben Folgezustand). Zustandsmaschinen müssen Zähler- oder Eskalationsstrategien für persistente Fehler vorsehen.
• API-Vertrag:
  • Adaptive Applications müssen ihre internen Fehlerbehandlungsroutinen und Prozess-Rückgabewerte auf die numerischen Definitionen der Execution Error-Tabelle der jeweiligen Machine- und Function-Group-Konfiguration abstimmen.