Figure 17.1: PHM interface with other components

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm (cmp PHM_Interfaces) mit integrierten Schnittstellen-Klassendefinitionen (Lollipop-/Socket-Notation sowie Methoden-/Attributsignaturen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Platform Health Management (PHM).
• Technischer Zweck: Darstellung der strukturellen Einbettung des PHM-Dämons in die Adaptive Core Architecture sowie seiner Interaktion mit überwachten Applikationen (Supervised Entities), dem State Management (SM) zur Einleitung von Recovery-Aktionen, dem Hardware-Watchdog zur Absicherung der Plattform-Integrität, der Manifest-Konfiguration sowie der (in R24-11/R25-11 noch als offen/proprietär markierten) Anbindung an den Diagnostic Manager (DM).

2. Komponenten, Entitäten & Schnittstellen

Komponenten & Akteure

• Platform Health Management (PHM): Zentraler Functional Cluster (Daemon/Prozess) zur Auswertung von lokaler und globaler Überwachung (Alive Supervision, Deadline Supervision, Logical Supervision).
• Applications or Clusters/Services: Adaptive Applications bzw. Plattform-Services, die als Überwachungsziele dienen; kapseln mindestens eine SupervisedEntity mit Checkpoints.
• State Manager (SM): Zentraler Systemkoordinator für Zustandswechsel (Function Groups, Machine States) und Empfänger/Ausführer von Recovery-Aktionen bei Überwachungsfehlern.
• Diagnostic Manager (DM): Diagnose-Cluster (DTC-Handling); über eine gestrichelte gerichtete Assoziation mit dem Vermerk not defined yet angebunden.
• Manifest: ARXML-Modellierungsartefakte (Execution Manifest, Machine Manifest, Service Instance Manifest) zur deklarativen Konfiguration von PHM und Supervised Entities.
• HW Watchdog: Physischer Hardware-Watchdog (MCU/PMIC/SBC) zur Absicherung gegen Hänger auf OS-/Plattformebene.

Schnittstellen & Signaturen

• «ara::phm» ReportCheckpoint:
  • Typ: Standardisierte C++-API (ara::phm::SupervisedEntity).
  • Signatur: + ReportCheckpoint(Checkpoint)
  • Ports: Provide-Port an Platform Health Management, Require-Port an SupervisedEntity (Applications or Clusters/Services).
• «ara::phm» RecoveryAction:
  • Typ: Interaktions-Interface zwischen PHM und State Management.
  • Signaturen:
    • + Offer(): Registriert/aktiviert die Bereitschaft des State Managers zur Übernahme von Recovery-Aktionen.
    • + RecoveryHandler(): Callback/Handler, über den PHM eine Recovery-Aktion an den State Manager signalisiert.
    • + StopOffer(): Deaktiviert die Bereitschaft des State Managers.
    • + GetGlobalSupervisionStatus(): Abfrage des aktuellen aggregierten Überwachungsstatus.
  • Ports:
    • RecoveryAction RecoveryHandler: Provide-Port am PHM, Require-Socket am SM.
    • RecoveryAction Offer: Require-Socket am PHM, Require-Socket/Aufruf über SM.
    • RecoveryAction StopOffer: Require-Socket am PHM, Require-Socket/Aufruf über SM.
    • RecoveryAction GetGlobalSupervisionStatus: Require-Socket am PHM, Require-Socket/Aufruf über SM.
• «External Interface» WatchdogInterface:
  • Typ: Plattform-/Treiberspezifische Schnittstelle zur Hardware-Anbindung.
  • Signaturen:
    • + FireWatchdogReaction(): Erzwingt sofortige Watchdog-Reaktion (Reset/Safe State) bei unrecoverable Platform Faults.
    • + AliveNotification(): Zyklisches Triggern/Servicen des Watchdogs bei fehlerfreiem globalen Überwachungsstatus.
  • Assoziation: Provide-Ports am PHM (WatchdogInterface AliveNotification, WatchdogInterface FireWatchdogReaction); gerichtete Abhängigkeit Hardware specific zum HW Watchdog.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Konfiguration:
   • PHM und Applikationen werden zur Startzeit anhand des Manifest instanziiert und parametriert (Definition von Supervised Entities, Checkpoints, Transitionstoleranzen, Zyklen).
   • Der State Manager ruft RecoveryAction::Offer() auf, um dem PHM mitzuteilen, dass er für die Abwicklung von Fehlerreaktionspfaden bereitsteht.
2. Normalbetrieb (Supervision Cycle):
   • Applikationen/Dienste melden das Erreichen definierter Programmpunkte synchron via ReportCheckpoint(Checkpoint) an das PHM (Alive-, Deadline- oder Logical-Supervision).
   • Verläuft die globale Überwachung positiv, ruft PHM WatchdogInterface::AliveNotification() auf, um den Hardware-Watchdog zurückzusetzen.
3. Fehlerfall & Eskalation:
   • Pfad A (Applikations-/Zustandsfehler): Verletzt eine SupervisedEntity eine Überwachungsregel (z. B. Deadline Timeout oder ungültige Transition), aggregiert PHM den Status und triggert den RecoveryAction::RecoveryHandler() im State Manager. Der State Manager führt die definierte Wiederherstellungsstrategie aus (z. B. Prozess-Neustart via Execution Management oder Umschalten der Function Group State).
   • Pfad B (Kritischer Plattformausfall): Schlägt das Recovery fehl oder tritt ein fataler Fehler im Gesamtsystem/PHM auf, wird WatchdogInterface::AliveNotification() ausgesetzt oder explizit WatchdogInterface::FireWatchdogReaction() ausgelöst. Der HW Watchdog führt den Hardware-Reset durch.
   • Pfad C (Diagnose-Protokollierung): Status not defined yet – standardmäßig keine direkte normative Kopplung PHM ↔ DM im Plattformdesign; Fehlerbehandlung/Fehlerspeichereinträge laufen typischerweise indirekt über State Management oder plattformspezifische DLT/DM-Events.

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler:
  • Einbindung über den C++-Header ara/phm/supervised_entity.h.
  • ReportCheckpoint() muss deterministisch und strikt nicht-blockierend ausgeführt werden, um Deadlocks oder Laufzeitverzerrungen im ausführenden Thread zu vermeiden.
  • Checkpoint-IDs müssen exakt mit den Manifest-Definitionen (SupervisedEntityInterface, Checkpoint) übereinstimmen.
• State-Management-Entwickler:
  • Implementierung des RecoveryAction-Musters: Offer() muss nach Initialisierung des SM vor Beginn überwachter Applikationszyklen aufgerufen werden.
  • RecoveryHandler muss reentrant bzw. threadsicher ausgelegt sein, um auf Health-Events asynchron und mit minimaler Latenz zu reagieren (Reaktionszeit bestimmt die Fault Tolerant Time Interval / FTTI).
• Treiber- & Plattform-Integratoren:
  • WatchdogInterface ist hardwareabhängig zu kapseln (POSIX Timer / Device Driver / SPI-Watchdog).
  • FireWatchdogReaction() erfordert fail-silent bzw. fail-safe Verhalten ohne Abhängigkeit von einem noch funktionsfähigen Betriebssystem-Scheduler.
  • Fehlende Standardisierung der Schnittstelle PHM ↔ DM (not defined yet) bedeutet: DTC-Erzeugung bei PHM-Fehlern muss über State Management (ara::sm) oder herstellerspezifische Brücken realisiert werden.