namespace ara::phm

Der Namespace ara::phm stellt Mechanismen zur Laufzeitüberwachung von Software-Entitäten bezüglich Lebenszeichen, Fristen und Kontrollfluss auf der Adaptive Platform bereit [SWS_PHM_01138]. Erkannte Anomalien durchlaufen eine mehrstufige Fehlerqualifizierung von der Entprellung bis zur Systemstilllegung [SWS_PHM_01137]. Bei nicht durch das State Management auflösbaren Fehlern übernimmt das Modul die Fehlerreaktion und steuert den System-Watchdog an [SWS_PHM_01240].

mehr ›

Kontext

Der Namespace ara::phm stellt die C++-Schnittstelle des Platform Health Managements (PHM) innerhalb der AUTOSAR Adaptive Platform dar. Seine zentrale Aufgabe ist die funktionale Überwachung von Software-Einheiten zur Gewährleistung der Systemintegrität. Als primäre Entitäten fungieren SupervisedEntity, welche überwachte funktionale Abläufe repräsentieren, sowie die abstrakte Klasse RecoveryAction, über die applikative Wiederherstellungsmaßnahmen definiert werden können. Die Überwachung wird über die Enumeration TypeOfSupervision [SWS_PHM_01138] in drei grundlegende Mechanismen unterteilt: die zyklische Lebenszeichenprüfung (kAliveSupervision), die Einhaltung zeitlicher Grenzen zwischen Kontrollpunkten (kDeadlineSupervision) sowie die Überprüfung der korrekten Ausführungsreihenfolge (kLogicalSupervision).

Im Gesamtsystem interagiert ara::phm nicht nur mit den anwendenden Prozessen, sondern kommuniziert eng mit dem PHM-Daemon und dem State Management (SM). Kann das State Management eine notwendige Wiederherstellung nicht durchführen, eskaliert das Platform Health Management die Fehlerbehebung direkt an den Hardware- oder System-Watchdog [SWS_PHM_01240].

Kontextdiagramm: Zusammenspiel von SupervisedEntity, PHM-Daemon, State Management, RecoveryAction und Watchdog. Quellen: [SWS_PHM_01138], [SWS_PHM_01240]

Lebenszyklus

Das Lebenszyklus- und Zustandsmodell des Platform Health Managements ist zweistufig aufgebaut und unterscheidet zwischen elementaren und globalen Überwachungszuständen. Eine einzelne Überwachungsfunktion nimmt Zustände gemäß ElementarySupervisionStatus [SWS_PHM_01358] an: Im inaktiven Zustand verbleibt sie in kDeactivated, nach der Aktivierung ohne Fehler in kOK. Tritt eine Anomalie auf, wechselt sie zunächst in kFailed, solange der Fehler noch innerhalb konfigurierter Toleranzen oder Entprellungszeiten (Debouncing) liegt. Erst nach Ablauf der Entprellung gilt der Fehler als qualifiziert und der Status wechselt nach kExpired [SWS_PHM_01358].

Die Gesamtbewertung mehrerer elementarer Überwachungen wird in GlobalSupervisionStatus [SWS_PHM_01137] aggregiert. Sind sämtliche zugeordneten Überwachungen inaktiv, befindet sich der globale Zustand in kDeactivated. Sobald mindestens eine Überwachung kOK meldet und keine fehlerhaft ist, ist der Gesamtstatus kOK. Befindet sich mindestens eine Überwachung in kFailed und keine in kExpired, spiegelt sich dies im globalen Zustand kFailed wider. Erreicht eine Überwachung den qualifizierten Fehlerzustand kExpired, verbleibt der globale Status in kExpired, solange die definierte Toleranzzeit nicht verstrichen ist. Nach Ablauf dieser Toleranzfrist geht das System in den finalen Zustand kStopped über [SWS_PHM_01137].

Zustandsdiagramm: Zustandsübergänge der globalen Überwachung in Abhängigkeit von Fehlererkennung und Toleranzzeiten. Quellen: [SWS_PHM_01137], [SWS_PHM_01358]

Nutzungspfad

In einer typischen Integrationsreihenfolge bindet eine Anwendung die Klassen des Namespace über #include "ara/phm/supervised_entity.h" oder den Weiterleitungs-Header #include "ara/phm/phm_fwd.h" ein [SWS_PHM_01358]. Die Anwendung instanziiert und verwaltet ein Objekt von SupervisedEntity, das die zu sichernde Funktionsausführung abbildet. Interpretation: Über dieses Objekt meldet die Anwendung im regulären Betrieb ihre Lebenszeichen oder Kontrollflussereignisse an das Platform Health Management. Frage (offen)

Der PHM-Daemon gleicht die gemeldeten Ereignisse kontinuierlich mit den parametrierten Kriterien für kAliveSupervision, kDeadlineSupervision oder kLogicalSupervision ab [SWS_PHM_01138]. Solange alle Signale frist- und regelgerecht eingehen, verbleibt die Auswertung im Zustand kOK [SWS_PHM_01358]. Werden Grenzwerte verletzt, durchläuft die Überwachung die Fehlerqualifizierung und leitet bei Erreichen von kExpired oder kStopped [SWS_PHM_01137] die konfigurierte Wiederherstellung ein. Hierbei kommt die Schnittstelle RecoveryAction zum Einsatz, vermutlich um anwendungsindividuelle Gegenmaßnahmen strukturiert auszuführen, bevor eine Eskalation an das State Management erfolgt. Frage (offen)

Fehlerszenarien

Spezifische Fehlerzustände innerhalb des Moduls werden über die Fehlerdomäne PhmErrorDomain sowie die Enumeration PhmErrc standardisiert [SWS_PHM_01240]. Die Enumeration definiert folgende Fehlercodes:

• PhmErrc::kOfferFailed (= 2): Der Dienst konnte aufgrund fehlgeschlagener Kommunikation mit dem PHM-Daemon nicht angeboten werden [SWS_PHM_01240].
• PhmErrc::kSMCanNotHandleRecovery (= 3): Das State Management kann die geforderte Wiederherstellung nicht bewältigen; das Platform Health Management übernimmt daraufhin die Wiederherstellung und löst den Watchdog aus [SWS_PHM_01240].
• PhmErrc::kServiceNotReady (= 4): Eine Anforderung kann nicht ausgeführt werden, da bereits eine Aktivierungs- oder Deaktivierungsanfrage (Enable/Disable) aktiv ist [SWS_PHM_01240].

Zur Erzeugung passender Fehlerobjekte stellt der Namespace die Hilfsfunktion MakeErrorCode bereit, welche aus einem PhmErrc und herstellerspezifischen Zusatzdaten ein ara::core::ErrorCode konstruiert [SWS_PHM_01244]. Die Referenz auf die globale Fehlerdomäne kann über GetPhmDomain bezogen werden [SWS_PHM_01251]. Beide Funktionen sind als constexpr und noexcept deklariert und garantieren Ausnahme- sowie Threadsicherheit [SWS_PHM_01244], [SWS_PHM_01251]. Im synchronen Fehlerfall oder bei Ausnahmen im Modul kommt zudem der Ausnahmetyp PhmException zur Anwendung.