Figure 7.4: Elementary Supervision Status

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsautomat (State Machine Diagram) gemäß OMG UML 2.5.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Platform Health Management (PHM, Spezifikationsdokument ID 851, R22-11 bis R25-11).
• Funktionaler Zweck: Modellierung des normativen Zustandsverhaltens einer einzelnen Elementary Supervision (ara::phm::ElementarySupervisionStatus) für die drei Überwachungsmechanismen:
  • Alive Supervision: Frequenz- und Zyklusüberwachung periodischer Abarbeitungen.
  • Deadline Supervision: Latenz- und Laufzeitüberwachung zwischen zwei Checkpoints (Min-/Max-Grenzen).
  • Logical Supervision: Sequenzielle Kontrollflussüberwachung (Graph gültiger Checkpoint-Übergänge).
• Systemeinordnung: Bildet die Basisebene der Fehlererkennung im PHM. Der aggregierte Status mehrerer Elementary Supervisions fließt in Global Supervisions bzw. Health Channels ein, triggert Recovery Actions über das Execution Management (EM) und informiert das State Management (SM).

2. Komponenten, Entitäten & Schnittstellen

• Zustände (ara::phm::ElementarySupervisionStatus):
  • kDEACTIVATED: Initialer Ruhezustand; die Überwachung ist passiv (z. B. Prozess noch nicht in kRunning oder Überwachungsmodus inaktiv).
  • kOK: Nominalbetrieb; Checkpoint-Meldungen erfüllen alle parametrierten Timing- und Pfadkriterien.
  • kFAILED: Temporärer Fehlerzustand; ausschließlich für Alive Supervision gültig (SWS_PHM_01343). Signalisiert Grenzwertverletzung innerhalb der tolerierten Zyklen (failedSupervisionCyclesTolerance).
  • kEXPIRED: Fataler Fehlerzustand; irreversible Kriterienverletzung im laufenden Betrieb. Löst übergeordnete Recovery Actions aus.
• Pseudozustände & Strukturelemente:
  • Initial State (gefüllter Kreis): Startpunkt der Zustandsmaschine bei Initialisierung des PHM.
  • Choice / Decision Pseudostate (Raute): Dynamische Verzweigung ausgehend von kOK basierend auf Überwachungstyp und Toleranzkonfiguration.
• Assoziierte Entitäten & Schnittstellen:
  • Applikations-Schnittstelle: ara::phm::ReportCheckpoint() zur Erfassung von Checkpoint-IDs aus der überwachten Software-Komponente (Supervised Entity).
  • Execution Management (EM): Zustandsmeldungen via POSIX-Signale (SIGTERM) bzw. Prozessstatuswechsel (kRunning, abrupte Beendigung).
  • Metamodell-Entitäten (AUTOSAR ARXML): AliveSupervision, DeadlineSupervision, LogicalSupervision, SupervisedEntityInterface, SupervisionModeCondition.

3. Dynamisches Verhalten & Sequenzablauf

Die Transitionen (1) bis (10) bilden das deterministische Regelwerk der Überwachung ab:

• (1) Initialisierung [SWS_PHM_01344]: Startup des PHM setzt alle Zustandsautomaten auf kDEACTIVATED. Zähler für fehlgeschlagene Alive-Referenzzyklen wird genullt.
• (2) kOK → kEXPIRED [SWS_PHM_01346]:
  • Deadline Supervision: Über-/Unterschreitung der parametrierten Min-/Max-Laufzeit.
  • Logical Supervision: Unzulässiger Kantenübergang im Kontrollflussgraph.
  • Alive Supervision: Toleranz überschritten oder Fehlertoleranz = 0 konfiguriert.
• (3) kOK → kFAILED [SWS_PHM_01347]:
  • Nur Alive Supervision: Checkpoint-Anzahl im Referenzzyklus außerhalb [minMargin, maxMargin], während der Fehlzykluszähler ≤ failedSupervisionCyclesTolerance bleibt.
• (4) kEXPIRED → kDEACTIVATED [SWS_PHM_01355]:
  • Reset-Pfad: Notification von EM, dass der betroffene Prozess terminiert wird (SIGTERM) oder abgestürzt ist.
• (5) kFAILED → kOK [SWS_PHM_01349]:
  • Selbstheilung (nur Alive Supervision): Checkpoint-Frequenz im nachfolgenden Evaluierungsintervall wieder im Sollbereich; Fehlzykluszähler fällt auf 0 zurück.
• (6) kFAILED → kEXPIRED [SWS_PHM_01350]:
  • Eskalation (nur Alive Supervision): Fehlzykluszähler überschreitet failedSupervisionCyclesTolerance. Die Überwachung wird gestoppt.
• (7) kOK → kDEACTIVATED [SWS_PHM_01351]:
  • Deaktivierung durch Transition des zugeordneten SupervisionMode oder Prozessbeendigung.
• (8) kFAILED → kDEACTIVATED [SWS_PHM_01352]:
  • Deaktivierung oder Prozessbeendigung aus dem Vorfehler-Zustand; Alive-Fehlerzähler wird genullt.
• (9) kDEACTIVATED → kOK [SWS_PHM_01354]:
  • Aktivierung: Wechsel in aktiven SupervisionMode und Vorliegen des Prozessstatus kRunning.
• (10) kDEACTIVATED → kEXPIRED [SWS_PHM_01357]:
  • Kaltstartfehler (spezifisch Logical Supervision): Der allererste gemeldete Checkpoint nach Deaktivierung stellt keinen gültigen Initial-Checkpoint des definierten Teilgraphen dar.

4. Normative Relevanz & Entwickler-Hinweise

• Fehlende Fehlertoleranz bei Deadline & Logical Supervision: Für Deadline- und Logical-Überwachungen existiert kein kFAILED-Status. Jeder Timing- oder Sequenzfehler führt unmittelbar und unumkehrbar zu kEXPIRED.
• Keine In-Session-Recovery aus kEXPIRED: Ein Wiederanlauf aus kEXPIRED erfordert zwingend einen Prozess-Neustart via Execution Management oder einen Moduswechsel (kEXPIRED → kDEACTIVATED → kOK). Ein einfacher Aufruf weiterer Checkpoints heilt kEXPIRED nicht.
• Checkpoint-Initialisierungsfalle (Transition 10): Applikationen müssen garantieren, dass nach Aktivierung einer Logical Supervision ausnahmslos ein als Quelle deklarierter Start-Checkpoint aufgerufen wird. Ein unvorhergesehener Einstieg führt sofort zu kEXPIRED.
• Timing- und Jitter-Konfiguration: Zur Vermeidung von Spurious Failures bei Alive Supervisions in POSIX-Mehrkern-Umgebungen muss failedSupervisionCyclesTolerance > 0 gewählt werden, um OS-Scheduling-Jitter und Preemptions abzufangen, bevor Transition (6) schlägt.