Figure 6.5: Multiple Checkpoints for Alive Supervision in one SupervisedEntity for a given Supervision Mode

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Struktur- und Konfigurationsdiagramm (UML-Objekt-/Metamodell-Abstraktion) der AUTOSAR Adaptive Platform (SWS Platform Health Management - PHM).
• Technischer Zweck: Spezifikation der Mehrfachüberwachung von Checkpoints mittels Alive Supervision innerhalb einer einzelnen SupervisedEntity (SE3) für einen spezifischen Überwachungsmodus (SupervisionMode).
• Funktionale Einordnung: Das PHM realisiert die funktionale Sicherheitsüberwachung (ISO 26262) für Adaptive Applications. Die Alive-Supervision verifiziert zur Laufzeit, ob periodische Funktionen oder Threads innerhalb deterministischer zeitlicher Frequenzkorridore ausgeführt werden.

2. Komponenten, Entitäten & Schnittstellen

• SupervisedEntity (SE3):
  • Logische Gruppierungseinheit für sicherheitsrelevante Ausführungspfade innerhalb eines Prozesses der Adaptive Application.
  • Kapselt einen oder mehrere diskrete Überwachungspunkte.
• Checkpoint (CP3-1, CP3-2):
  • Eindeutig identifizierbare Kontrollpunkte im Applikationscode, die über die Schnittstelle ara::phm::SupervisedEntity::ReportCheckpoint(CheckpointId) getriggert werden.
  • Kardinalität: 1 : N zwischen SupervisedEntity und Checkpoint.
• Konfigurationsparameter je Checkpoint (Metamodell-Attribute):
  • ExpectedAliveIndications: Soll-Anzahl der Checkpoint-Meldungen innerhalb eines Bewertungsintervalls.
  • MinMargin: Maximal zulässige negative Abweichung (Unterschreitung der Soll-Aufrufe).
  • MaxMargin: Maximal zulässige positive Abweichung (Überschreitung der Soll-Aufrufe).
  • AliveReferenceCycle: Länge des Referenzüberwachungsfensters (ausgedrückt in Zyklen des PHM-Auswertungstakts).
  • FailedReferenceCyclesTolerance: Anzahl konsekutiv fehlerhafter Referenzzyklen, bevor ein Zustandstransfer nach ALIVE_FAILED bzw. ALIVE_EXPIRED ausgelöst wird.

3. Dynamisches Verhalten & Sequenzablauf

• Meldungsphase (Asynchron / Event-getrieben):
  • Die Applikation durchläuft den Kontrollfluss und meldet das Erreichen von CP3-1 bzw. CP3-2 via IPC an den PHM-Daemon (ReportCheckpoint).
• Evaluierungsphase (Periodisch / Synchroner PHM-Zyklus):
  • Jeder Checkpoint wird unabhängig voneinander nach Ablauf seines jeweiligen AliveReferenceCycle bewertet.
  • Gültigkeitsbedingung für einen fehlerfreien Zyklus: $$\text{ExpectedAliveIndications} - \text{MinMargin} \le \text{ActualIndications} \le \text{ExpectedAliveIndications} + \text{MaxMargin}$$
• Fehlerakkumulation & Statusübergang:
  • Schlägt ein Zyklus fehl, wird der zyklische Fehlerzähler inkrementiert.
  • Überschreitet der Zähler FailedReferenceCyclesTolerance, degradiert der Alive-Status des betroffenen Checkpoints (ALIVE_OK → ALIVE_FAILED).
  • Der lokale Zustand der SupervisedEntity wird reevaluiert und fließt in die globale Zustandsmaschine des PHM ein (Auslösung konfigurierter Recovery-Aktionen via State Management / Execution Management).

4. Normative Relevanz & Entwickler-Hinweise

• Unabhängige Parametrierung:
  • Mehrere Checkpoints innerhalb derselben SupervisedEntity können disjunkte Ausführungsfrequenzen überwachen (z. B. CP3-1 für eine 10-ms-Regelschleife, CP3-2 für eine 100-ms-Diagnoseübertragung).
• Jitter & Scheduling-Toleranz:
  • MinMargin und MaxMargin müssen unter Berücksichtigung von OS-Scheduling-Latenzen, Thread-Präemption und Ausführungs-Jitter gewählt werden, um False Positives zu verhindern.
• Konfigurationsbindung an SupervisionMode:
  • Alive-Supervision-Parameter sind an den jeweiligen SupervisionMode gebunden. Bei Moduswechseln können Parametersätze ausgetauscht oder einzelne Checkpoints inaktiv geschaltet werden.
• API-Vertrag:
  • Entwickler müssen sicherstellen, dass ReportCheckpoint nicht aus Interrupt-Kontexten mit blockierendem IPC aufgerufen wird und die übergebene CheckpointId exakt der im ARXML-Manifest deklarierten ID entspricht.