Figure 7.7: Platform Health Management and the environment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Komponentendiagramm (cmp PHM_Interfaces).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Platform Health Management (ara::phm).
• Technischer Zweck: Darstellung der statischen Schnittstellen- und Abhängigkeitsbeziehungen des PHM-Kernclusters zu überwachten Entitäten (Applikationen, Plattform-Services), Konfigurationsquellen (Manifests), übergeordneter Zustandssteuerung (State Management), Fehlerbehandlung (Diagnostic Management) und der Hardware-Absicherung (Watchdog).

2. Komponenten, Entitäten & Schnittstellen

Komponenten

• Platform Health Management: Zentraler Plattform-Dienst (Daemon), der Alive-, Deadline- und Logical-Supervision sowie zustandsbasierte Integritätsüberwachungen ausführt.
• Applications or Clusters/Services: Überwachte Prozesse im POSIX-User-Space. Enthalten logische Überwachungsinstanzen.
• Manifest: Machine-, Execution- und Service-Instance-Manifeste zur deklarativen Parametrierung von Überwachungsregeln und Checkpoints.
• State Manager (ara::sm): Systemkoordinator für Function Group States (FGS). Nimmt Recovery-Triggern entgegen und initiiert Systemreaktionen.
• Diagnostic Manager (ara::diag): Dritter Funktionscluster für Fehlerspeicherung/DTCs; Schnittstelle ist explizit als „not defined yet“ annotiert (kein standardisierter direkter Standard-C++-API-Pfad in den Releases R21-11 bis R23-11).
• HW Watchdog: Physikalische Hardware-Überwachungseinheit (externer PMIC/ASIC oder interner SoC-Watchdog).

Schnittstellen & Stereotypen

• «ara::phm» ReportCheckpoint:
  • API: + ReportCheckpoint(Checkpoint)
  • Beziehung: Provided Port am PHM (ReportCheckpoint), Required Port an der Applikation (SupervisedEntity).
• «ara::phm» ReportHealthStatus:
  • API: + ReportHealthStatus(HealthStatus)
  • Beziehung: Provided Port am PHM (ReportHealthStatus), Required Port an der Applikation (HealthChannel).
• «ara::phm» RecoveryAction:
  • APIs: + Offer(), + RecoveryHandler(), + StopOffer(), + GetGlobalSupervisionStatus()
  • Beziehung: Bidirektionale Interaktionspunkte mit dem State Manager. Der State Manager registriert sich als Handler via Offer()/StopOffer(), PHM benachrichtigt ihn bei Supervision-Verletzung via RecoveryHandler(), und der SM kann den aggregierten Status via GetGlobalSupervisionStatus() aktiv abfragen.
• «ara::phm» HealthChannelAction:
  • APIs: + Offer(), + RecoveryHandler(), + StopOffer()
  • Beziehung: Analoge Steuerung für Health-Channel-basierte Fehlerauslösungen zwischen PHM und State Manager.
• «External Interface» WatchdogInterface:
  • APIs: + FireWatchdogReaction(), + AliveNotification()
  • Beziehung: PHM triggert die Servicing-API (AliveNotification) bzw. fordert bei Systemversagen aktiv den Hardware-Reset an (FireWatchdogReaction). Die Anbindung an den HW Watchdog ist als „Hardware specific“ typisiert (BSP/Treiber-Ebene, typischerweise Kernel-Space oder Safe-MCU-Brücke).
• Konfigurationsabhängigkeit:
  • Abhängigkeitspfeile Configure vom Manifest sowohl auf Applications or Clusters/Services als auch auf Platform Health Management.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Registrierungsphase:
   • Applikationen und PHM instanziieren ihre Laufzeitkonfiguration aus den Manifesten (Supervision Entities, Grenzwerte, Min-/Max-Toleranzen, Transitionsgraphen).
   • Der State Manager signalisiert seine Empfangsbereitschaft für Wiederherstellungsaktionen über RecoveryAction::Offer() und HealthChannelAction::Offer().
2. Nominaler Überwachungszyklus:
   • Applikationsprozesse triggern im Normalbetrieb zyklisch oder ereignisbasiert ReportCheckpoint(Checkpoint) an ihren definierten Checkpoints.
   • Diskrete funktionale Einheiten melden den Status via ReportHealthStatus(HealthStatus).
   • Bei Erfüllung aller Alive-, Deadline- und Logical-Supervision-Bedingungen triggert PHM zyklisch WatchdogInterface::AliveNotification() zum Bedienen des Hardware-Watchdogs.
3. Fehler- & Eskalationspfad (Supervision Failure):
   • Bei Verletzung (z. B. Deadline überrannt, ungültige Transition, fehlender Alive-Zyklus) geht die entsprechende Überwachungsregel in den Zustand Expired / Failed.
   • Soft-Recovery: PHM ruft den Callback RecoveryHandler() am State Manager auf. Der State Manager leitet die hinterlegte Recovery-Strategie ein (z. B. Neustart der betroffenen Function Group, Umschalten in einen Safe State / Degraded Mode).
   • Hard-Recovery / Watchdog-Eskalation: Scheitert die Wiederherstellung oder tritt ein fataler Systemzustand ein, unterlässt PHM entweder das AliveNotification()-Servicing (Watchdog läuft ab) oder ruft deterministisch WatchdogInterface::FireWatchdogReaction() auf, um einen unmittelbaren Hardware-Reset/Safe-State zu erzwingen.

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler:
  • ara::phm::SupervisedEntity::ReportCheckpoint ist latenzkritisch und muss im jeweiligen Thread nicht-blockierend (noexcept, lock-frei implementiert) aufgerufen werden.
  • Das Einfügen von Checkpoints erfordert die exakte Modellierung im ARXML-Manifest; zusätzliche oder ausgelassene Aufrufe verletzen die logische Supervision und führen unmittelbar zum Failure-State.
• State-Manager- & Integrations-Entwickler:
  • Der State Manager muss RecoveryAction::Offer() zwingend vor Beginn der Überwachungszyklen ausführen, da sonst Recovery-Benachrichtigungen verworfen werden oder unhandled bleiben.
  • Das Mapping von RecoveryHandler()-Events auf konkrete Function-Group-Zustandsübergänge muss im Machine-/Execution-Manifest vollständig geschlossen sein.
• BSP- & Plattform-Entwickler:
  • WatchdogInterface ist ein systemspezifischer Abstraktionslayer («External Interface»). Die Implementierung muss garantieren, dass FireWatchdogReaction() auch bei hängendem Betriebssystem/Kernel ausgeführt werden kann (z. B. via dedizierten Kernel-Driver /dev/watchdog oder IPC zu einem abgesicherten Safety-Core/PMIC).
• Diagnose-Stack (Diagnostic Manager):
  • Da der Pfad zwischen PHM und Diagnostic Manager als „not defined yet“ markiert ist, dürfen keine standardisierten direkten AUTOSAR-AP-Aufrufe erwartet werden. Fehler, die diagnosefähig sein müssen, müssen über den Umweg des State Manager bzw. über plattformspezifische Integrationsbrücken in den ara::diag-Stack überführt werden.