Modul ara::phm — Platform Health Management

Das Platform Health Management überwacht als zentraler Daemon die funktionale Sicherheit und Laufzeitintegrität von Anwendungen und Plattform-Diensten gemäß AUTOSAR_AP_SWS_PlatformHealthManagement S. 15. Überwachte Entitäten melden ihre Kontrollpunkte zyklisch oder ereignisgesteuert an das System, welches Deadlines, Alive-Zyklen sowie logische Kontrollflüsse auswertet. Bei erkannten Fehlern benachrichtigt das Modul das State Management zur Einleitung gezielter Wiederherstellungsaktionen über [SWS_PHM_01142]. Bleibt eine Erholung aus oder versagen zentrale Instanzen, erzwingt ein Watchdog-Trigger den sicheren Maschinenzustand.

mehr ›

Das Platform Health Management (PHM) bildet den zentralen Hintergrunddienst der AUTOSAR Adaptive Platform zur Absicherung der funktionalen Sicherheit und Software-Integrität nach ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement S. 15. Es überwacht sowohl Anwendungs- als auch Plattform-Prozesse über deterministische Kontrollpunktmeldungen und sichert die Hardware über zyklische Watchdog-Trigger ab AUTOSAR_AP_SWS_PlatformHealthManagement S. 46.

Kontextdiagramm: Architektonische Einbettung des PHM-Daemons im Zusammenspiel mit überwachten Applikationen, State Management, Execution Management, Watchdog und IdsM. Quellen: AUTOSAR_AP_SWS_PlatformHealthManagement S. 46, AUTOSAR_AP_SWS_PlatformHealthManagement S. 15, AUTOSAR_AP_EXP_SWArchitecture S. 131.

Die funktionale Überwachung stützt sich auf die Schnittstelle ara::phm::SupervisedEntity, über die Prozesse Kontrollpunkte via ReportCheckpoint() melden ([SWS_PHM_01123], [SWS_PHM_01127]). Das PHM gliedert die Verifikation in drei Überwachungsarten [SWS_PHM_01138]:

• Alive Supervision zur zyklischen Frequenzkontrolle AUTOSAR_FO_ASWS_HealthMonitoring S. 22,
• Deadline Supervision zur Überwachung maximaler Ausführungsfristen AUTOSAR_AP_SWS_PlatformHealthManagement S. 15,
• Logical Supervision zur Einhaltung definierter Kontrollflussgraphen AUTOSAR_AP_SWS_PlatformHealthManagement S. 15.

Diese elementaren Ergebnisse werden pro Funktionsgruppe zu einem aggregierten Status GlobalSupervisionStatus verdichtet ([SWS_PHM_01137], SWS_PlatformHealthManagement S. 39).

Bei erkannten Verletzungen delegiert das PHM die Fehlerbehebung an das State Management über den RecoveryHandler() der Schnittstelle RecoveryAction, nachdem dieses seine Dienstbereitschaft per Offer() gemeldet hat ([SWS_PHM_01142], [SWS_PHM_01143]). Kann das State Management den Fehler nicht bereinigen oder versagen zentrale Daemons selbst, greift die Sicherheitseskalation: Das PHM triggert über das native WatchdogInterface mit FireWatchdogReaction() einen unmittelbaren Hardware-Reset ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture S. 220).

Sequenzdiagramm: Fehlereskalation an das State Management über den RecoveryHandler mit Verzweigung zur Watchdog-Auslösung im Fehlerfall. Quellen: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture S. 234, AUTOSAR_AP_EXP_SWArchitecture S. 220, AUTOSAR_AP_EXP_SWArchitecture S. 220.

mehr ›

Systemgrenzen und funktionale Einbettung des Health Managements

Das Platform Health Management (PHM) bildet innerhalb der AUTOSAR Adaptive Platform die zentrale funktionale Instanz zur Überwachung der Ausführungsintegrität, Dienstverfügbarkeit und funktionalen Sicherheit nach ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement S. 15. Als eigenständiger Hintergrunddienst (daemon-based) implementiert das Modul die deterministische Verifikation von zeitlichen und logischen Kontrollflüssen in sicherheitsrelevanten Prozessen AUTOSAR_AP_EXP_SWArchitecture S. 128. Die Systemgrenzen umfassen drei wesentliche Interaktionsachsen: die Aufnahme von Kontrollpunktmeldungen überwachter Softwareeinheiten, die Fehlereskalation an das State Management sowie das zyklische Auslösen von Lebenszeichenmeldungen an einen hardwarenahen Watchdog AUTOSAR_AP_SWS_PlatformHealthManagement S. 46.

Die Überwachungspflichten beschränken sich nicht ausschließlich auf reguläre Benutzeranwendungen (Adaptive Applications). Vielmehr unterliegen auch fundamentale Plattformdienste wie das Execution Management, das State Management, der Diagnostic Manager sowie die Zeitsynchronisation der Überwachung durch das PHM, indem sie selbst als überwachte Entitäten fungieren und Checkpoints an das Health Management übermitteln AUTOSAR_AP_EXP_SWArchitecture S. 130. Für interne Hilfsfunktionen stützt sich der PHM-Daemon auf Schnittstellen des Execution Managements (ExecutionClient zur Prozessstatusmeldung) und des Logging-Subsystems (Logger aus Log and Trace) AUTOSAR_AP_EXP_SWArchitecture S. 131.

Kontextdiagramm: Architektonische Einbettung des PHM-Daemons im Zusammenspiel mit überwachten Applikationen, State Management, Execution Management, Watchdog und IdsM. Quellen: AUTOSAR_AP_SWS_PlatformHealthManagement S. 46, AUTOSAR_AP_SWS_PlatformHealthManagement S. 15, AUTOSAR_AP_EXP_SWArchitecture S. 131.

Instrumentierung und Lebenszyklus überwachter Entitäten

Eine logische Überwachungseinheit innerhalb eines Prozesses wird durch die Schnittstelle ara::phm::SupervisedEntity abgebildet [SWS_PHM_01123]. Die Instanziierung erfolgt explizit unter Angabe eines typisierten Bezeichners vom Typ ara::core::InstanceSpecifier, welcher den konfigurierten Port-Pfad im Systemmanifest referenziert AUTOSAR_TPS_ManifestSpecification S. 141. Zum Schutz der Instanzintegrität ist der Copy-Konstruktor sowie der Copy-Zuweisungsoperator gelöscht ([SWS_PHM_01212], [SWS_PHM_01213]); Instanzen dürfen jedoch verschoben werden ([SWS_PHM_01214], [SWS_PHM_01215]). Beim Abbau räumt der Destruktor die Entität auf [SWS_PHM_01211].

Die instrumentierte Software meldet das Erreichen festgelegter Programmpunkte über den synchronen Aufruf ReportCheckpoint() [SWS_PHM_01127]. Als Parameter dient eine typisierte Checkpoint-Enumeration, die aus dem Schnittstellen-Header generiert wird ([SWS_PHM_00424], [SWS_PHM_00425]). Der PHM-Daemon verifiziert bei jeder Meldung die Prozessberechtigung; ruft ein nicht im Manifest modellierter Prozess die Methode auf, wird eine Zugriffsverletzung erkannt [SWS_PHM_01127]. Bei sicherheitskritischen Anomalien kann das PHM den Zugriffsfehler an den Intrusion Detection System Manager (IdsM) weiterleiten AUTOSAR_AP_EXP_SWArchitecture S. 236.

Die Überwachung einer Entität kann zur Laufzeit zustandsabhängig gesteuert werden: Über Enable() wird die Überwachung aktiviert, sofern der aktuelle Zustand der zugehörigen Funktionsgruppe dies gestattet [SWS_PHM_01130]. Mit Disable() kann die Überwachung wieder ausgesetzt werden [SWS_PHM_01380]. Beide Methoden liefern ein ara::core::Future<void> zurück und signalisieren asynchrone Bereitstellungsfehler, beispielsweise PhmErrc::kServiceNotReady [SWS_PHM_01130].

Sequenzdiagramm: Ablauf der Kontrollpunktmeldung über SupervisedEntity mit Rechteprüfung und Sicherheitsüberwachung durch das IdsM. Quellen: [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture S. 236.

Überwachungsarten und mehrstufige Statusaggregation

Das Platform Health Management unterscheidet drei primäre elementare Überwachungsarten ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture S. 128):

• Alive Supervision (kAliveSupervision): Prüft, ob zyklische Programmteile innerhalb definierter Zeitfenster eine konfigurierte Mindest- und Höchstanzahl an Checkpoint-Meldungen absetzen AUTOSAR_FO_ASWS_HealthMonitoring S. 22.
• Deadline Supervision (kDeadlineSupervision): Überwacht die Ausführungsdauer zwischen zwei Kontrollpunkten auf Einhaltung konfigurierter Minimal- und Maximalfristen AUTOSAR_AP_SWS_PlatformHealthManagement S. 15.
• Logical Supervision (kLogicalSupervision): Validiert die Ausführungsreihenfolge anhand eines modellierten Übergangsgraphen, um unzulässige Sprünge oder Kontrollflussverzweigungen zu identifizieren AUTOSAR_AP_SWS_PlatformHealthManagement S. 15.

Jede einzelne Überwachung besitzt eine eigene Zustandsmaschine für ihren elementaren Status (ElementarySupervisionStatus) [SWS_PHM_01358]. Beim Start des PHM werden sämtliche elementaren Zustandsmaschinen im Zustand kDEACTIVATED initialisiert und Fehlerzähler auf null gesetzt SWS_PlatformHealthManagement S. 31. Nach der Aktivierung wechselt die Überwachung in kOK, solange alle Prüfkriterien erfüllt sind. Tritt eine Verletzung auf, wechselt der Status in kFailed [SWS_PHM_01358].

Zustandsdiagramm: Zustandsübergänge der elementaren Überwachung (ElementarySupervisionStatus) von kDEACTIVATED über kOK bis kFailed. Quellen: [SWS_PHM_01358], SWS_PlatformHealthManagement S. 31.

Mehrere elementare Überwachungen werden zu einer übergeordneten globalen Überwachung zusammengefasst SWS_PlatformHealthManagement S. 24. Gemäß Spezifikation existiert pro konfigurierter Global Supervision genau ein GlobalSupervisionStatus, der strikt an eine einzelne Funktionsgruppe (Function Group) gebunden ist und sich nicht über mehrere Funktionsgruppen erstrecken darf ([SWS_PHM_01137], SWS_PlatformHealthManagement S. 39). Der globale Status aggregiert die Ergebnisse über die Zustände kDEACTIVATED, kOK, kFAILED, kEXPIRED und kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement S. 39. Der Zustand kOK setzt voraus, dass mindestens eine zugehörige Überwachung fehlerfrei arbeitet und keine einzige im Fehlerzustand verweilt [SWS_PHM_01137].

Zustandsdiagramm: Zustandsmodell des globalen Überwachungsstatus (GlobalSupervisionStatus) mit kDEACTIVATED, kOK, kFAILED, kEXPIRED und kSTOPPED. Quellen: [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement S. 39, SWS_PlatformHealthManagement S. 39.

Zyklische Watchdog-Bedienung und Hardware-Absicherung

Um die Lauffähigkeit der gesamten Recheneinheit gegen Hänger oder fatale Systemabstürze abzusichern, bindet das PHM das hardwarenahe Watchdog-Subsystem über die Schnittstelle apext::phm::WatchdogInterface an [SWS_PHM_01255]. Diese native Plattform-Erweiterung (Platform Extension) wird nicht über Service-Middleware realisiert, sondern als deterministischer nativer Treiberaufruf ausgeführt AUTOSAR_AP_EXP_SWArchitecture S. 130.

In einem konfigurierbaren Zyklus prüft das PHM intern alle aktiven Überwachungsmetriken und setzt bei positivem Gesamtstatus über AliveNotification() eine Lebenszeichenmeldung an den Watchdog ab ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture S. 233). Bleibt diese Meldung innerhalb des konfigurierten Zeitfensters aus — beispielsweise weil der PHM-Daemon blockiert ist oder eine kritische Überwachung scheitert —, leitet das Watchdog-Interface eigenständig eine Hardware-Sicherheitsreaktion ein [SWS_PHM_01255].

Sequenzdiagramm: Periodische Auswertung der Überwachungsergebnisse und Alive-Signalisierung an das Watchdog-Interface. Quellen: [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture S. 233, AUTOSAR_AP_EXP_SWArchitecture S. 130.

Koordination von Recovery-Aktionen mit dem State Management

Erkennt das PHM eine Verletzung von Überwachungsbedingungen, leitet es die Fehlerbehebung nicht eigenmächtig ein, sondern delegiert die Maßnahme an das State Management als zentrale Regulierungsinstanz (AUTOSAR_AP_EXP_SWArchitecture S. 129, AUTOSAR_AP_EXP_SWArchitecture S. 220). Diese Entkopplung wahrt das Architekturprinzip, dass Entscheidungen über funktionale Systemzustände und Prozess-Neustarts beim State Management verbleiben AUTOSAR_AP_SWS_StateManagement S. 28.

Das State Management registriert seine Bereitschaft zur Fehlerübernahme über die Port-Schnittstelle ara::phm::RecoveryAction [SWS_PHM_01141]. Durch den Aufruf von Offer() wird die Entgegennahme von Fehlermeldungen scharfgeschaltet [SWS_PHM_01143]; mit StopOffer() kann das State Management die Dienstbereitschaft wieder deaktivieren [SWS_PHM_01144]. Um fatale Rennbedingungen und undefiniertes Verhalten durch vorzeitigen Callback-Aufruf vor vollständiger Konstruktion abgeleiteter Klassen auszuschließen, sind Copy- und Move-Operationen für RecoveryAction explizit unterbunden ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

Im Fehlerfall ruft das PHM die rein virtuelle Rückruffunktion RecoveryHandler() des State Managements auf und übergibt dabei das Fehlerereignis ara::exec::ExecutionErrorEvent sowie die Art der verletzten Überwachung TypeOfSupervision [SWS_PHM_01142]. Das State Management ermittelt daraufhin den Folgezustand der Funktionsgruppe und veranlasst das Execution Management zur Zustandsänderung oder zum Neustart betroffener Prozesse (AUTOSAR_AP_EXP_SWArchitecture S. 169, AUTOSAR_AP_EXP_SWArchitecture S. 220).

Sequenzdiagramm: Fehlereskalation an das State Management über den RecoveryHandler mit Verzweigung zur Watchdog-Auslösung im Fehlerfall. Quellen: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture S. 234, AUTOSAR_AP_EXP_SWArchitecture S. 220, AUTOSAR_AP_EXP_SWArchitecture S. 220.

Verhalten im Fehlerfall und mehrstufige Eskalationspfade

Das Platform Health Management implementiert eine abgestufte Eskalationsstrategie zur Beherrschung von Laufzeitfehlern AUTOSAR_AP_EXP_SWArchitecture S. 200. Tritt ein Überwachungsfehler auf, wird zunächst der primäre Pfad beschritten: Die Überwachung meldet den Fehler an das State Management, welches über RecoveryHandler() eine kontrollierte Rekonfiguration durchführt [SWS_PHM_01142].

Kann das State Management die Erholung nicht ausführen (beispielsweise quittiert mit dem Fehlercode PhmErrc::kSMCanNotHandleRecovery) oder läuft die Beantwortung in einen Timeout, greift der sekundäre Eskalationspfad ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture S. 220). In diesem Fall umgeht das PHM die Software-Ebene und erzwingt über FireWatchdogReaction() eine sofortige hardwarenahe Notfallreaktion (System-Reset oder Übergang in den Safe State) ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture S. 201).

Besonders kritisch ist der Ausfall der zentralen Plattform-Daemons selbst: Versagt das Execution Management oder das State Management, ist eine koordinierte Wiederherstellung auf Betriebssystemebene nicht mehr möglich (AUTOSAR_AP_EXP_SWArchitecture S. 235, AUTOSAR_AP_EXP_SWArchitecture S. 235). Das PHM erkennt diesen Zustand über fehlerhafte oder ausbleibende Checkpoints dieser Daemons und feuert ohne Verzögerung die Watchdog-Reaktion [SWS_PHM_01256].

Alle Fehlersituationen im C++-API werden über die Fehlerdomäne ara::phm::PhmErrorDomain typisiert ([SWS_PHM_01247], [SWS_PHM_01251]). Die Fehlercodes sind im Enum PhmErrc zusammengefasst ([SWS_PHM_01240], [SWS_PHM_01245]). Für synchrone Schnittstellen und Ausnahmen stehen Hilfsfunktionen wie MakeErrorCode() [SWS_PHM_01244] sowie der Ausnahmetyp PhmException zur Verfügung ([SWS_PHM_01243], [SWS_PHM_01250]).

Manifest-Modellierung, ID-Synchronisation und Instanziierung

Die korrekte Verknüpfung zwischen Applikationscode und PHM-Daemon basiert auf einer strengen ID-Synchronisation im AUTOSAR-Manifest AUTOSAR_AP_TPS_ManifestSpecification S. 566. Im Anwendungsdesign wird die Entität als PhmSupervisedEntityInterface mit aggregierten PhmCheckpoint-Elementen modelliert AUTOSAR_AP_TPS_ManifestSpecification S. 208. Für das Deployment auf Maschinenebene wird pro Prozessinstanz ein SupervisionCheckpoint erzeugt, der die Instanzreferenz auf den Port und den Ausführungskontext (Process) auflöst TPS_ManifestSpecification S. 568.

Wird derselbe Softwarekomponententyp mehrfach instanziiert — sei es innerhalb desselben Prozesses oder über mehrere Prozesse hinweg —, erzeugt die Manifest-Konfiguration für jeden Port einen eindeutigen InstanceSpecifier AUTOSAR_AP_SWS_PlatformHealthManagement S. 51. Dadurch kann der PHM-Daemon identische Kontrollpunkt-IDs aus dem Quellcode eindeutig der jeweiligen Komponenteninstanz und Prozessidentität zuordnen AUTOSAR_AP_TPS_ManifestSpecification S. 566. Interpretation: Die Interprozesskommunikation zwischen Anwendungs-User-Space und PHM-Daemon dürfte betriebssystemspezifisch optimiert sein (etwa über Shared Memory oder POSIX-Domain-Sockets), da die C++-Klasse SupervisedEntity die Transportdetails transparent kapselt [SWS_PHM_01123]. Frage Q-f6147469f30f4299 (offen)

Auf Seiten der Fehlerbehandlung modelliert das Manifest RecoveryNotification-Elemente, die einem PPortPrototype des State Managements zugeordnet sind AUTOSAR_AP_TPS_ManifestSpecification S. 587. Hierbei wird auch ein Timeout-Wert (recoveryNotificationTimeout) definiert, nach dessen Ablauf die Fehlerbehandlung als gescheitert eingestuft wird AUTOSAR_AP_TPS_ManifestSpecification S. 587.

Weiterführende Detailbelege

Die verbindliche normative Ausgestaltung des Platform Health Managements im Release R25-11 stützt sich insbesondere auf folgende Spezifikationsanker:

• Kernelemente der Überwachung: [SWS_PHM_01123] und [SWS_PHM_01127] definieren die C++-Klasse SupervisedEntity und den Meldemechanismus ReportCheckpoint(); [SWS_PHM_01130] sowie [SWS_PHM_01380] regeln Aktivierung und Deaktivierung.
• Zustandsmodelle: [SWS_PHM_01358] spezifiziert die elementaren Zustände (kDEACTIVATED, kOK, kFailed); [SWS_PHM_01137] verankert die globale Statusaggregation pro Funktionsgruppe SWS_PlatformHealthManagement S. 39.
• Wiederherstellung und Eskalation: [SWS_PHM_01141], [SWS_PHM_01142] und [SWS_PHM_01143] steuern die Bereitstellung und Ausführung des RecoveryHandler() im State Management; [SWS_PHM_01256] sichert die Notfall-Eskalation via Hardware-Watchdog ab.
• Fehlerdomäne und Exceptions: [SWS_PHM_01240] führt die Fehlercodes (PhmErrc) ein, die über PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) und PhmException [SWS_PHM_01243] transportiert werden.