Figure 7.11: 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: 11, 12, 111, 23, 24) sowie das Wildcard-Schlüsselwort ANY zur Erfassung beliebiger sonstiger oder nicht explizit aufgeführter Fehlerursachen. Im Metamodell korrespondieren die numerischen Fehlercodes mit Attributen des Typs ProcessExecutionError.executionError.
  • Next State (Spalte 2): Zielzustands-Identifikatoren der Zustandsmaschine in symbolischer Namensform (Recovery, Startup, Suspend, Off, Shutdown), 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 = Recovery).
  • Default-/Catch-All-Zuordnung: Der Eintrag ANY erfasst alle nicht gesondert definierten Fehlercodes und weist ihnen deterministisch den Zielzustand Shutdown zu.
  • 1 : 1-Eindeutigkeit: Jedem definierten Execution Error sowie dem Sammelbegriff ANY ist innerhalb der Tabelle genau ein deterministischer Next State zugewiesen.

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):**
   • Stimmt der Fehlercode mit einem spezifischen Tabelleneintrag überein (11, 12, 111, 23, 24), feuert der Zustandsübergang unmittelbar in den zugehörigen symbolischen Zielzustand (Recovery, Startup, Suspend, Off).
   • Ist der gemeldete Fehlercode nicht explizit hinterlegt, greift der Sammel- bzw. Wildcard-Eintrag ANY, und das System wechselt unmittelbar in den Zustand Shutdown.
   • Reguläre Transition-Guards oder Einträge aus der TransitionRequestTable werden dabei umgangen.
4. Folgeaktionen: SM leitet Aktionen zur Fehlerbehebung bzw. Stilllegung ein (z. B. Anforderung neuer Function-Group-Zustände via ara::exec, gezielter Neustart oder kontrolliertes Herunterfahren).
5. Abbruch-/Fehlerfall: Nur falls weder ein passender spezifischer Fehlercode noch ein ANY-Eintrag vorhanden 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.