Figure 7.16: General Fault Tolerance scheme.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Kausalitäts- und Fehlertoleranz-Modell (Dependability-Kette nach der Avizienis/Laprie-Taxonomie, adaptiert auf das Laufzeit- und Zustandsmodell der AUTOSAR Adaptive Platform).
• Technischer Zweck: Formale Definition der Fehlerfortpflanzung (Fault-Error-Failure-Kette) und des Interventionspfads innerhalb des Execution Management (EM, SWS_EM_02032, RS_EM_00150). Es illustriert, wie zustandsabhängig aktivierte Defekte durch Erkennungs- und Wiederherstellungsmechanismen (Detection/Recovery) abgefangen werden, um eine Kaskadierung in nachfolgende Systemausfälle zu verhindern und das System in einen definierten, sicheren Maschinen- oder Funktionsgruppenzustand zurückzuführen.

2. Komponenten, Entitäten & Schnittstellen

• Machine/FG State (Initialzustand, links): Der aktuelle Laufzeitkontext, definiert durch den Zustand der Maschine (MachineState) oder einer Funktionsgruppe (FunctionGroupState). Bildet den Ausführungskontext, in dem eine latente Schwachstelle existiert.
• Fault (Defekt / Ursache): Latente Anomalie, Software-/Hardwaredefekt (z. B. Memory Leak, ungültige Konfiguration, Race Condition, Bitflip).
• Error (Fehlerzustand): Die durch Aktivierung manifestierte interne Fehlfunktion bzw. der ungültige Systemzustand (z. B. korrumpierter Prozessspeicher, inkonsistente Zählerstände).
• Failure (Ausfall / Fehlwirkung): Nach außen sichtbare Nichterfüllung des spezifizierten Dienstes (z. B. Prozessabsturz via SIGSEGV, Deadlock, verletzte Deadline-Supervision).
• Fault (Kaskadiert, rechts): Der Ausfall einer Komponente/eines Prozesses fungiert kausal als neuer latenter Defekt (Fault) für abhängige Softwarekomponenten oder übergeordnete Systemebenen.
• Detection/Recovery (Interventionsinstanz): Aktive Überwachungs- und Wiederherstellungslogik, primär realisiert durch Execution Management (Prozessüberwachung via POSIX-Signale wie SIGCHLD, Exit-Codes) in Kooperation mit Platform Health Management (PHM: Alive-, Deadline-, Logical-Supervision) und State Management (SM).
• Machine/FG State (Wiederhergestellter Zustand, rechts unten): Definierter Folgezustand (z. B. Fallback-Zustand, degradierter Funktionsgruppenmodus oder Übergang in den sicheren Zustand / SafeState).

3. Dynamisches Verhalten & Sequenzablauf

[Machine/FG State (Fault)] --(activation)--> [Error] --(propagation)--> [Failure] --(causation)--> [Fault ...]
                                                |
                                                +--(detection)--> [Detection/Recovery] 
                                                                         |
                                                                         +--(transition)--> [Machine/FG State (Safe/Fallback)]

1. Aktivierung (activation): Der Betrieb im oder der Wechsel in einen spezifischen Machine/FG State aktiviert den latenten Fault (z. B. Allokation von Ressourcen bei Erreichen einer Betriebsgrenze).
2. Fehlermanifestation: Der Defekt führt zu einem internen Error.
3. Ungeschützter Pfad (Kaskadierung):
   • Ohne rechtzeitige Fehlererkennung propagiert der Error (propagation) und führt zum Failure des Prozesses/Subsystems.
   • Durch Kausalität (causation) induziert dieser Ausfall Folgefehler bei konsumierenden Prozessen oder blockiert nachfolgende State Transitions.
4. Fehlertoleranter Pfad (Detection & Recovery):
   • Erkennung: Der Error wird abgefangen, bevor er zum unkontrollierten Ausfall führt (z. B. durch PHM-Supervision, POSIX-Signal-Monitoring im EM oder Rückgabewerte der ara::exec-APIs).
   • Wiederherstellung (Recovery): EM initiiert definierte Gegenmaßnahmen:
     • Lokale Recovery: Prozess-Neustart gemäß der im Execution Manifest konfigurierten restartAttemptCounter-Strategie.
     • Zustandsbasierte Recovery: Signalisierung an das State Management (SM) zur Einleitung eines Zustandswechsels in einen degradierten FunctionGroupState.
   • Eskalation in den Unrecoverable State (SWS_EM_02032): Kann der Fehler nicht behoben werden und das System kann seine Sicherheitsziele nicht mehr gewährleisten, wechselt EM in den Unrecoverable State. Hierbei führt EM zwingend die konfigurierte Pre-Cleanup Action aus (geordnetes Beenden aller verwalteten Prozesse per SIGTERM/SIGKILL, Freigabe kritischer Ressourcen), bevor die Plattform angehalten oder ein Hardware-Reset ausgelöst wird.

4. Normative Relevanz & Entwickler-Hinweise

• SWS_EM_02032 / RS_EM_00150 Einhaltung: Entwickler müssen sicherstellen, dass Prozesse auf Terminierungsanforderungen während der Pre-Cleanup Action innerhalb des konfigurierten timeout-Fensters reagieren, um Deadlocks bei der Eskalation in den Unrecoverable State zu vermeiden.
• Manifest-Konfiguration (ExecutionManifest):
  • recoveryAction: Präzise Festlegung, ob ein fehlerhafter Prozess isoliert neu gestartet werden darf (restartProcess) oder direkt einen State-Fallback im SM erzwingen muss.
  • StartupConfig: Exakte Definition von Abhängigkeiten (ExecutionDependency), damit im Recovery-Fall keine ungültigen Startreihenfolgen entstehen.
• Applikations-Design (ara::exec::ExecutionClient):
  • Applikationen müssen ihren internen Lebenszyklus über ReportExecutionState(kRunning) deterministisch an das EM melden.
  • Interne Fehler müssen über definierte Fehlercodes an das PHM gemeldet werden, um den Recovery-Pfad zu aktivieren, bevor unkontrollierte Prozessabstürze (Failure) ausgelöst werden.
• Ressourcenbereinigung: Da die Umschaltung auf einen neuen Machine/FG State fehlerhafte Prozesse beendet, müssen geteilte POSIX-Objekte (Shared Memory, Named Semaphores, IPC-Sockets) so verwaltet werden, dass beim Neustart keine verwaisten Locks das Recovery blockieren.