module ara::phm — Platform Health Management

En tant que démon central, Platform Health Management surveille la sécurité fonctionnelle et l'intégrité à l'exécution des applications et des services de plateforme conformément à AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Les entités surveillées signalent leurs points de contrôle au système de manière cyclique ou événementielle, lequel évalue les échéances, les cycles de vie (Alive) ainsi que les flux de contrôle logiques. En cas d'erreurs détectées, le module notifie State Management afin d'engager des actions de récupération ciblées via [SWS_PHM_01142]. En l'absence de rétablissement ou en cas de défaillance des instances centrales, un déclenchement du watchdog force l'état sûr de la machine.

plus ›

Platform Health Management (PHM) constitue le service d'arrière-plan central de l'AUTOSAR Adaptive Platform destiné à garantir la sécurité fonctionnelle et l'intégrité logicielle selon l'ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Il surveille aussi bien les processus d'application que ceux de la plateforme par le biais de notifications déterministes de points de contrôle et sécurise le matériel via des déclenchements cycliques du watchdog AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Diagramme de contexte : intégration architecturale du démon PHM en interaction avec les applications surveillées, State Management, Execution Management, le watchdog et l'IdsM. Sources : AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

La surveillance fonctionnelle s'appuie sur l'interface ara::phm::SupervisedEntity, par laquelle les processus signalent des points de contrôle via ReportCheckpoint() ([SWS_PHM_01123], [SWS_PHM_01127]). Le PHM structure la vérification en trois types de surveillance [SWS_PHM_01138] :

• Alive Supervision pour le contrôle de fréquence cyclique AUTOSAR_FO_ASWS_HealthMonitoring p. 22,
• Deadline Supervision pour la surveillance des délais d'exécution maximaux AUTOSAR_AP_SWS_PlatformHealthManagement p. 15,
• Logical Supervision pour le respect des graphes de flux de contrôle définis AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Ces résultats élémentaires sont agrégés par Function Group en un état global GlobalSupervisionStatus ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39).

En cas de violations détectées, le PHM délègue le traitement des erreurs à State Management via le RecoveryHandler() de l'interface RecoveryAction, après que ce dernier a signalé sa disponibilité opérationnelle par Offer() ([SWS_PHM_01142], [SWS_PHM_01143]). Si State Management ne peut pas corriger l'erreur ou si des démons centraux échouent eux-mêmes, l'escalade de sécurité intervient : le PHM déclenche une réinitialisation matérielle immédiate via le WatchdogInterface natif avec FireWatchdogReaction() ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagramme de séquence : escalade d'erreurs vers State Management via le RecoveryHandler avec branchement vers le déclenchement du watchdog en cas d'erreur. Sources : [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

plus ›

Limites système et intégration fonctionnelle du Health Management

Au sein de l'AUTOSAR Adaptive Platform, Platform Health Management (PHM) constitue l'instance fonctionnelle centrale pour la surveillance de l'intégrité de l'exécution, de la disponibilité des services et de la sécurité fonctionnelle selon l'ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. En tant que service d'arrière-plan autonome (fondé sur un démon), le module implémente la vérification déterministe des flux de contrôle temporels et logiques dans les processus critiques pour la sécurité AUTOSAR_AP_EXP_SWArchitecture p. 128. Les limites du système englobent trois axes d'interaction essentiels : la réception des notifications de points de contrôle des unités logicielles surveillées, l'escalade des erreurs vers State Management ainsi que le déclenchement cyclique de signaux de présence destinés à un watchdog proche du matériel AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Les obligations de surveillance ne se limitent pas exclusivement aux applications utilisateur classiques (Adaptive Applications). Au contraire, des services de plateforme fondamentaux tels qu'Execution Management, State Management, le Diagnostic Manager ainsi que la synchronisation temporelle sont également soumis à la surveillance par le PHM, en agissant eux-mêmes comme des entités surveillées et en transmettant des points de contrôle au Health Management AUTOSAR_AP_EXP_SWArchitecture p. 130. Pour ses fonctions auxiliaires internes, le démon PHM s'appuie sur des interfaces d'Execution Management (ExecutionClient pour la notification de l'état des processus) et du sous-système de journalisation (Logger de Log and Trace) AUTOSAR_AP_EXP_SWArchitecture p. 131.

Diagramme de contexte : intégration architecturale du démon PHM en interaction avec les applications surveillées, State Management, Execution Management, le watchdog et l'IdsM. Sources : AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

Instrumentation et cycle de vie des entités surveillées

Une unité de surveillance logique au sein d'un processus est représentée par l'interface ara::phm::SupervisedEntity [SWS_PHM_01123]. L'instanciation s'effectue explicitement en indiquant un identifiant typé de type ara::core::InstanceSpecifier, qui référence le chemin de port configuré dans le manifeste système AUTOSAR_TPS_ManifestSpecification p. 141. Afin de protéger l'intégrité de l'instance, le constructeur par copie ainsi que l'opérateur d'assignation par copie sont supprimés ([SWS_PHM_01212], [SWS_PHM_01213]) ; les instances peuvent toutefois être déplacées ([SWS_PHM_01214], [SWS_PHM_01215]). Lors de la suppression, le destructeur nettoie l'entité [SWS_PHM_01211].

Le logiciel instrumenté signale l'atteinte de points de programme définis via l'appel synchrone ReportCheckpoint() [SWS_PHM_01127]. Une énumération typée de points de contrôle, générée à partir de l'en-tête d'interface, sert de paramètre ([SWS_PHM_00424], [SWS_PHM_00425]). Le démon PHM vérifie les autorisations du processus à chaque notification ; si un processus non modélisé dans le manifeste appelle la méthode, une violation d'accès est détectée [SWS_PHM_01127]. En cas d'anomalies critiques pour la sécurité, le PHM peut transmettre l'erreur d'accès à l'Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture p. 236.

La surveillance d'une entité peut être commandée à l'exécution en fonction de l'état : Enable() active la surveillance, pour autant que l'état actuel du Function Group associé le permette [SWS_PHM_01130]. Disable() permet de suspendre à nouveau la surveillance [SWS_PHM_01380]. Les deux méthodes renvoient un ara::core::Future<void> et signalent les erreurs de mise à disposition asynchrones, par exemple PhmErrc::kServiceNotReady [SWS_PHM_01130].

Diagramme de séquence : déroulement de la notification de point de contrôle via SupervisedEntity avec contrôle des droits et surveillance de la sécurité par l'IdsM. Sources : [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture p. 236.

Types de surveillance et agrégation d'état multiniveau

Platform Health Management distingue trois types principaux de surveillance élémentaire ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture p. 128) :

• Alive Supervision (kAliveSupervision) : vérifie si les parties de programme cycliques émettent un nombre minimal et maximal configuré de notifications de points de contrôle dans des fenêtres temporelles définies AUTOSAR_FO_ASWS_HealthMonitoring p. 22.
• Deadline Supervision (kDeadlineSupervision) : surveille la durée d'exécution entre deux points de contrôle afin de garantir le respect de délais minimaux et maximaux configurés AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.
• Logical Supervision (kLogicalSupervision) : valide l'ordre d'exécution à l'aide d'un graphe de transition modélisé afin d'identifier les sauts non autorisés ou les divergences de flux de contrôle AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Chaque surveillance individuelle possède sa propre machine à états pour son statut élémentaire (ElementarySupervisionStatus) [SWS_PHM_01358]. Au démarrage du PHM, toutes les machines à états élémentaires sont initialisées à l'état kDEACTIVATED et les compteurs d'erreurs sont mis à zéro SWS_PlatformHealthManagement p. 31. Après l'activation, la surveillance passe à kOK tant que tous les critères de vérification sont remplis. Si une violation survient, l'état passe à kFailed [SWS_PHM_01358].

Diagramme d'états : transitions d'état de la surveillance élémentaire (ElementarySupervisionStatus) de kDEACTIVATED à kFailed via kOK. Sources : [SWS_PHM_01358], SWS_PlatformHealthManagement p. 31.

Plusieurs surveillances élémentaires sont regroupées en une surveillance globale de niveau supérieur SWS_PlatformHealthManagement p. 24. Selon la spécification, il existe exactement un GlobalSupervisionStatus par Global Supervision configurée, qui est strictement lié à un seul Function Group et ne doit pas s'étendre sur plusieurs Function Groups ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39). Le statut global agrège les résultats à travers les états kDEACTIVATED, kOK, kFAILED, kEXPIRED et kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement p. 39. L'état kOK suppose qu'au moins une surveillance associée fonctionne sans erreur et qu'aucune ne se trouve dans un état d'erreur [SWS_PHM_01137].

Diagramme d'états : modèle d'états du statut de surveillance globale (GlobalSupervisionStatus) avec kDEACTIVATED, kOK, kFAILED, kEXPIRED et kSTOPPED. Sources : [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement p. 39, SWS_PlatformHealthManagement p. 39.

Gestion cyclique du watchdog et sécurisation matérielle

Afin de sécuriser la capacité d'exécution de l'ensemble de l'unité de calcul contre les blocages ou les plantages système fatals, le PHM intègre le sous-système de watchdog proche du matériel via l'interface apext::phm::WatchdogInterface [SWS_PHM_01255]. Cette extension de plateforme native (Platform Extension) n'est pas mise en œuvre via un middleware de service, mais exécutée sous la forme d'un appel de pilote natif déterministe AUTOSAR_AP_EXP_SWArchitecture p. 130.

Selon un cycle configurable, le PHM vérifie en interne toutes les métriques de surveillance actives et envoie un signal de présence au watchdog via AliveNotification() si l'état global est positif ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233). Si ce signal n'est pas émis dans la fenêtre temporelle configurée — par exemple parce que le démon PHM est bloqué ou qu'une surveillance critique échoue —, l'interface du watchdog déclenche de manière autonome une réaction de sécurité matérielle [SWS_PHM_01255].

Diagramme de séquence : évaluation périodique des résultats de surveillance et signalisation de vie (Alive) vers l'interface du watchdog. Sources : [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233, AUTOSAR_AP_EXP_SWArchitecture p. 130.

Coordination des actions de récupération avec State Management

Si le PHM détecte une violation des conditions de surveillance, il n'engage pas la correction de l'erreur de manière unilatérale, mais délègue la mesure à State Management en tant qu'instance de régulation centrale (AUTOSAR_AP_EXP_SWArchitecture p. 129, AUTOSAR_AP_EXP_SWArchitecture p. 220). Ce découplage préserve le principe architectural selon lequel les décisions relatives aux états fonctionnels du système et aux redémarrages de processus incombent à State Management AUTOSAR_AP_SWS_StateManagement p. 28.

State Management enregistre sa disponibilité pour la prise en charge des erreurs via l'interface de port ara::phm::RecoveryAction [SWS_PHM_01141]. L'appel de Offer() arme la réception des notifications d'erreurs [SWS_PHM_01143] ; avec StopOffer(), State Management peut désactiver à nouveau la disponibilité du service [SWS_PHM_01144]. Afin d'exclure les conditions de concurrence critiques et les comportements indéfinis dus à un appel de rappel prématuré avant la construction complète des classes dérivées, les opérations de copie et de déplacement sont explicitement interdites pour RecoveryAction ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

En cas d'erreur, le PHM appelle la fonction de rappel purement virtuelle RecoveryHandler() de State Management en lui transmettant l'événement d'erreur ara::exec::ExecutionErrorEvent ainsi que le type de surveillance violée TypeOfSupervision [SWS_PHM_01142]. State Management détermine ensuite l'état suivant du Function Group et demande à Execution Management de modifier l'état ou de redémarrer les processus concernés (AUTOSAR_AP_EXP_SWArchitecture p. 169, AUTOSAR_AP_EXP_SWArchitecture p. 220).

Diagramme de séquence : escalade d'erreurs vers State Management via le RecoveryHandler avec branchement vers le déclenchement du watchdog en cas d'erreur. Sources : [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

Comportement en cas d'erreur et voies d'escalade multiniveaux

Platform Health Management met en œuvre une stratégie d'escalade graduée pour maîtriser les erreurs d'exécution AUTOSAR_AP_EXP_SWArchitecture p. 200. Lorsqu'une erreur de surveillance survient, la voie primaire est d'abord empruntée : la surveillance signale l'erreur à State Management, qui effectue une reconfiguration contrôlée via RecoveryHandler() [SWS_PHM_01142].

Si State Management ne peut pas exécuter la récupération (acquittée par exemple par le code d'erreur PhmErrc::kSMCanNotHandleRecovery) ou si le délai de réponse expire, la voie d'escalade secondaire intervient ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture p. 220). Dans ce cas, le PHM contourne la couche logicielle et force une réaction d'urgence immédiate proche du matériel via FireWatchdogReaction() (réinitialisation du système ou passage à l'état sûr) ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 201).

La défaillance des démons centraux de la plateforme eux-mêmes est particulièrement critique : en cas de défaillance d'Execution Management ou de State Management, une récupération coordonnée au niveau du système d'exploitation n'est plus possible (AUTOSAR_AP_EXP_SWArchitecture p. 235, AUTOSAR_AP_EXP_SWArchitecture p. 235). Le PHM détecte cet état par des points de contrôle incorrects ou absents de ces démons et déclenche sans délai la réaction du watchdog [SWS_PHM_01256].

Toutes les situations d'erreur dans l'API C++ sont typées via le domaine d'erreur ara::phm::PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]). Les codes d'erreur sont regroupés dans l'énumération PhmErrc ([SWS_PHM_01240], [SWS_PHM_01245]). Pour les interfaces synchrones et les exceptions, des fonctions d'assistance telles que MakeErrorCode() [SWS_PHM_01244] ainsi que le type d'exception PhmException sont disponibles ([SWS_PHM_01243], [SWS_PHM_01250]).

Modélisation de manifeste, synchronisation d'ID et instanciation

L'association correcte entre le code applicatif et le démon PHM repose sur une synchronisation stricte des ID dans le manifeste AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 566. Dans la conception de l'application, l'entité est modélisée sous forme de PhmSupervisedEntityInterface avec des éléments PhmCheckpoint agrégés AUTOSAR_AP_TPS_ManifestSpecification p. 208. Pour le déploiement au niveau de la machine, un SupervisionCheckpoint est généré par instance de processus, lequel résout la référence d'instance vers le port et le contexte d'exécution (Process) TPS_ManifestSpecification p. 568.

Si le même type de composant logiciel est instancié plusieurs fois — que ce soit au sein du même processus ou à travers plusieurs processus —, la configuration du manifeste génère un InstanceSpecifier unique pour chaque port AUTOSAR_AP_SWS_PlatformHealthManagement p. 51. Cela permet au démon PHM d'associer sans ambiguïté des ID de points de contrôle identiques issus du code source à l'instance de composant et à l'identité de processus respectives AUTOSAR_AP_TPS_ManifestSpecification p. 566. Interprétation : la communication interprocessus entre l'espace utilisateur de l'application et le démon PHM devrait être optimisée spécifiquement pour le système d'exploitation (par exemple via de la mémoire partagée ou des sockets de domaine POSIX), étant donné que la classe C++ SupervisedEntity encapsule les détails de transport de manière transparente [SWS_PHM_01123]. Question (ouverte)

Du côté du traitement des erreurs, le manifeste modélise des éléments RecoveryNotification qui sont associés à un PPortPrototype de State Management AUTOSAR_AP_TPS_ManifestSpecification p. 587. Une valeur de délai d'attente (recoveryNotificationTimeout) est également définie ici, à l'expiration de laquelle le traitement de l'erreur est considéré comme ayant échoué AUTOSAR_AP_TPS_ManifestSpecification p. 587.

Preuves détaillées supplémentaires

La définition normative contraignante de Platform Health Management dans la version R25-11 s'appuie en particulier sur les points d'ancrage de spécification suivants :

• Éléments centraux de la surveillance : [SWS_PHM_01123] et [SWS_PHM_01127] définissent la classe C++ SupervisedEntity et le mécanisme de notification ReportCheckpoint() ; [SWS_PHM_01130] ainsi que [SWS_PHM_01380] régissent l'activation et la désactivation.
• Modèles d'état : [SWS_PHM_01358] spécifie les états élémentaires (kDEACTIVATED, kOK, kFailed) ; [SWS_PHM_01137] ancre l'agrégation globale d'états par groupe de fonctions SWS_PlatformHealthManagement p. 39.
• Rétablissement et escalade : [SWS_PHM_01141], [SWS_PHM_01142] et [SWS_PHM_01143] contrôlent la mise à disposition et l'exécution du RecoveryHandler() dans le State Management ; [SWS_PHM_01256] sécurise l'escalade d'urgence via le watchdog matériel.
• Domaine d'erreur et exceptions : [SWS_PHM_01240] introduit les codes d'erreur (PhmErrc) qui sont transportés via PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) et PhmException [SWS_PHM_01243].