module ara::sm — State Management

Le cluster adaptatif State Management gère les modes de fonctionnement à l'échelle du système, les états des groupes de fonctions et les phases de mise à jour logicielle d'une Adaptive Machine, en liaison avec Execution Management et UCM EXP SWArchitecture p. 51. Il traite les déclencheurs de transition de manière déterministe par l'intermédiaire de tables et de listes d'actions configurées, signale les états intermédiaires via StateMachineNotification et orchestre le Suspend-to-RAM au moyen d'un modèle hub-satellite [SWS_SM_91107], [SWS_SM_81110]. Des contraintes telles que la vérification stricte des autorisations de mise à jour et des chemins obligatoires de récupération d'erreurs ANY garantissent le fonctionnement robuste de la plateforme [SWS_SM_91108].

plus ›

Le cluster fonctionnel State Management (SM) fait office, dans l'AUTOSAR Adaptive Platform, de démon de plateforme central pour le contrôle des états de la machine et des groupes de fonctions ainsi que des modes d'exécution EXP SWArchitecture p. 51. Il sépare strictement la logique de décision propre au véhicule dans les applications de commande (SMControlApplication) de la gestion effective des processus par l'Execution Management (EM) EXP PlatformDesign p. 40. En plus des implémentations propriétaires des constructeurs, AUTOSAR fournit une approche standardisée StateMachine, dans laquelle les transitions sont traitées au moyen de métamodèles tabulaires et de listes d'actions configurées SWS StateManagement p. 42.

Les transitions d'état sont initiées via la méthode RequestTransition du StateMachineService [SWS_SM_91107] et validées par rapport à la TransitionRequestTable SWS StateManagement p. 44. Pendant le traitement de la ActionList associée, le champ de notification CurrentState signale la valeur de transition "inTransition" aux applications consommatrices avant que l'état cible ne soit publié après acquittement complet [SWS_SM_91109], SWS StateManagement p. 67.

Diagramme de séquence : déroulement d'une transition d'état régulière via StateMachineService et notification via StateMachineNotification. Sources : [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51

Pour l'exécution des mises à jour logicielles, le State Management met à disposition l'interface UpdateRequest pour l'Update and Configuration Management (UCM) [SWS_SM_91102], EXP SWArchitecture p. 56. Après vérification du champ applicatif UpdateAllowed, le module coordonne les étapes de préparation (PrepareUpdate), de vérification (VerifyUpdate) ou de rollback (PrepareRollback) ainsi que les redémarrages de machine via ResetMachine [SWS_SM_91100], [SWS_SM_91103], [SWS_SM_91108]. Pour les modes d'économie d'énergie tels que Suspend-to-RAM, S2RHub et S2RSatellite synchronisent le gel et le redémarrage des applications et du système d'exploitation [SWS_SM_81010], [SWS_SM_81110], [SWS_SM_71001].

En cas d'erreur, les SmErrorDomain [SWS_SM_81247] ainsi qu'une entrée de repli ANY obligatoire dans la ErrorRecoveryTable garantissent que les erreurs d'exécution imprévues issues de l'Execution Management ou du Platform Health Management sont interceptées de manière déterministe et que les actions en cours basculent immédiatement vers des états de restauration définis SWS StateManagement p. 42.

plus ›

Rôle et limites fonctionnelles du système au sein de la plateforme

Le cluster fonctionnel State Management (SM) constitue, dans l'AUTOSAR Adaptive Platform, l'instance centrale d'orchestration des modes de fonctionnement, des groupes fonctionnels et des cycles de vie des processus à l'échelle du système EXP SWArchitecture p. 51. Exécuté en tant que démon de plateforme autonome, le State Management découple l'exécution d'état interne à la plateforme de la logique de contrôle propre au véhicule et au constructeur, laquelle est généralement encapsulée dans une application de contrôle autonome (SMControlApplication) EXP PlatformDesign p. 40. Tandis que le State Management prend et valide les décisions logiques d'état, il délègue le démarrage, l'arrêt et le basculement physiques des processus à l'Execution Management (EM) via le StateClient SWS StateManagement p. 40.

Sur le plan architectural, le module s'appuie sur une double philosophie d'intégration : les intégrateurs peuvent soit employer l'approche standardisée StateMachine basée sur le manifeste de la pile de plateforme, soit implémenter une logique d'état entièrement propre au constructeur, étant donné que les interfaces vers le State Management sont conservées publiques SWS StateManagement p. 42. Dans l'approche standardisée, le State Management réagit de façon déterministe aux déclencheurs externes provenant des applications de contrôle, aux messages d'erreur du Platform Health Management (PHM) ainsi qu'aux changements d'état réseau du Network Management (NM) SWS StateManagement p. 45. De plus, le State Management constitue l'instance de contrôle déterminante pour les mises à jour logicielles assurées par l'Update and Configuration Management (UCM) EXP SWArchitecture p. 56.

Diagramme de contexte : intégration du cluster fonctionnel State Management au sein de l'ensemble système AUTOSAR Adaptive. Sources : EXP PlatformDesign p. 40, SWS StateManagement p. 28

Transitions d'état et commande via l'interface StateMachineService

Pour initier des changements d'état, le State Management met à disposition le service orienté service StateMachineService pour chaque instance configurée d'une StateMachine SWS StateManagement p. 44. L'application demande une transition par l'intermédiaire de la méthode de service RequestTransition [SWS_SM_91107]. Le State Management vérifie cette requête par rapport à l'état actuel de la machine d'état à l'aide d'une TransitionRequestTable consignée statiquement dans le manifeste SWS StateManagement p. 44. Si la transition est définie, l'exécution de la liste d'actions en cours (ActionList) est arrêtée et le passage vers l'état cible est amorcé SWS StateManagement p. 45.

Dès qu'une transition d'état démarre, le State Management positionne la valeur du champ de service CurrentState de l'interface StateMachineNotification sur "inTransition" [SWS_SM_91109], SWS StateManagement p. 67. Cet état transitoire signale aux Adaptive Applications dépendantes, via ara::com, qu'une reconfiguration du système est en cours EXP SWArchitecture p. 52. Au sein des listes d'actions, des groupes fonctionnels peuvent être synchronisés ou exécutés en parallèle au moyen d'éléments SYNC, afin de refléter fidèlement les dépendances SWS StateManagement p. 56. Ce n'est qu'une fois que tous les ActionListItems ont été entièrement traités et que les résultats ont été collectés que CurrentState prend le nom définitif du nouvel état SWS StateManagement p. 67.

Diagramme de séquence : déroulement d'une transition d'état standard via StateMachineService et notification via StateMachineNotification. Sources : [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51, EXP SWArchitecture p. 219

Diagramme d'état : cycle de vie typique et logique de transition d'une StateMachine basés sur la TransitionRequestTable. Sources : EXP InterfacesGuidelines p. 22, SWS StateManagement p. 44

Orchestration des mises à jour logicielles en interaction avec l'UCM

Dans le cadre des mises à jour logicielles, le State Management assure le rôle d'interface entre l'Update and Configuration Management (UCM) et les états d'exécution de la machine EXP SWArchitecture p. 142. À cet effet, le State Management met à disposition l'interface UpdateRequest, qui ne peut être instanciée au maximum qu'une seule fois par machine et qui est liée de manière exclusive au processus gérant la machine d'état du contrôleur SWS StateManagement p. 79. Une mise à jour est engagée lorsque l'UCM appelle la méthode RequestUpdateSession [SWS_SM_91102]. Le State Management ne prend pas la décision d'admissibilité de façon autonome, mais consulte le champ de service UpdateAllowed du UpdateAllowedService, défini par la logique de contrôle applicative [SWS_SM_91108], SWS StateManagement p. 81.

Si la session est approuvée, le contrôleur marque les automates d'état concernés comme ImpactedByUpdate SWS StateManagement p. 81. Avant l'installation effective, l'UCM appelle PrepareUpdate avec la liste des groupes fonctionnels concernés, à la suite de quoi ceux-ci sont commutés vers des états inactifs [SWS_SM_91103], PlatformDesign p. 58. Si la mise à jour requiert un redémarrage, l'UCM sollicite un reset ordonné via la méthode fire-and-forget ResetMachine, lors duquel toutes les données doivent préalablement être sauvegardées [SWS_SM_91100]. Le State Management informe l'UCM des changements de statut pendant le reset par le biais du champ ResetMachineNotifier [SWS_SM_91106], SWS StateManagement p. 92. Après le redémarrage ou la mise à jour, la vérification suit via VerifyUpdate [SWS_SM_91104], SWS StateManagement p. 87. Si le contrôle échoue, PrepareRollback prépare le retour arrière [SWS_SM_91105], SWS StateManagement p. 88. L'achèvement de l'ensemble du cycle est acquitté par StopUpdateSession [SWS_SM_91101], SWS StateManagement p. 79.

Diagramme de séquence : déroulement des interactions lors d'une session de mise à jour logicielle entre l'UCM, le State Management et la logique de contrôle. Sources : [SWS_SM_91100], [SWS_SM_91102], [SWS_SM_91103], [SWS_SM_91104], SWS StateManagement p. 78

Gestion de l'énergie et Suspend-to-RAM dans l'architecture hub-satellite

Pour les fonctionnalités étendues de gestion de l'énergie telles que le Suspend-to-RAM (S2R), le State Management implémente un patron d'architecture hub-satellite EXP SWArchitecture p. 54. L'instance centrale de commande dans le démon de plateforme utilise la classe S2RHub [SWS_SM_81103], tandis que les Adaptive Applications participantes intègrent des instances de S2RSatellite dans leur propre espace de processus [SWS_SM_81003], [SWS_SM_81014], SWS StateManagement p. 35. Les satellites activent leur disponibilité à recevoir des changements de mode via Offer [SWS_SM_81012] ou la désactivent via StopOffer [SWS_SM_81013]. Ils implémentent les méthodes purement virtuelles EnterSuspendMode [SWS_SM_81010] et LeaveSuspendMode [SWS_SM_81011] en tant que mécanisme de callback pour la préparation et la phase consécutive à l'état de repos.

Lorsqu'une procédure de suspension est engagée, le S2RHub s'adresse à tous les satellites enregistrés de manière asynchrone via RequestToEnterSuspendMode avec un délai d'expiration configurable [SWS_SM_81110]. Dès lors que tous les satellites ont achevé avec succès leurs préparatifs d'état de repos, le hub déclenche via EnterSuspendToRamOs le passage du système d'exploitation dans l'état de maintien de la RAM [SWS_SM_81112], SWS StateManagement p. 101. Au niveau de la couche wrapper d'OS proche du matériel, le State Management s'appuie sur la apext::sm::PowerStateInterface : celle-ci permet de définir des états de fonctionnement proches du matériel via SetPowerState [SWS_SM_71001] selon l'énumération PowerState [SWS_SM_71002] ainsi que d'enregistrer et de désenregistrer des gestionnaires de réveil autonomes via RegisterWakeUpHandler [SWS_SM_71003] et UnregisterWakeUpHandler [SWS_SM_71005] avec le type de fonction WakeUpHandler [SWS_SM_71004], SWS StateManagement p. 105. Après le réveil, le hub requiert via RequestToLeaveSuspendMode le redémarrage coordonné de l'ensemble des satellites [SWS_SM_81111].

Diagramme de séquence : déroulement en deux phases de la mise en Suspend-to-RAM du système et du réveil ultérieur. Sources : [SWS_SM_71001], [SWS_SM_81110], [SWS_SM_81112], SWS StateManagement p. 101

Comportement en cas d'erreur

Pour ses propres erreurs opérationnelles, le module définit la SmErrorDomain [SWS_SM_81247], qui est récupérée via GetSmDomain [SWS_SM_81251] et porte l'identifiant "Sm" [SWS_SM_81248]. Elle fournit des descriptions d'erreur [SWS_SM_81249] et convertit, en cas d'exception, les codes en une ThrowAsException via SmException [SWS_SM_81243], [SWS_SM_81250]. L'énumération SmErrc permet de caractériser des motifs de défaillance spécifiques, notamment kOfferFailed pour les pertes de connexion avec le démon de plateforme et kCommunicationFailed pour les échecs de communication avec les satellites [SWS_SM_81240], générables au moyen de MakeErrorCode [SWS_SM_81244].

Dans le domaine des automates d'état logiques, le State Management impose un traitement sans faille des erreurs au moyen de l'ErrorRecoveryTable SWS StateManagement p. 69. Chaque table doit obligatoirement comporter exactement une entrée ayant la valeur ANY, qui sert de chemin de repli déterministe pour toutes les erreurs d'exécution non mappées explicitement SWS StateManagement p. 42, SWS StateManagement p. 69. Si une erreur est signalée par le Platform Health Management ou l'Execution Management et que la machine d'état concernée n'est pas marquée comme ImpactedByUpdate, elle positionne un drapeau interne de récupération d'erreur en cours, interrompt immédiatement la liste d'actions courante et bascule sans délai vers l'état de restauration paramétré SWS StateManagement p. 42. En cas d'erreurs critiques de l'Execution Management telles que kIntegrityOrAuthenticityCheckFailed, le State Management part du principe que l'intégrité de la plateforme est compromise et que les requêtes subséquentes échoueront, raison pour laquelle les mesures correctives se situent en dehors du cluster SWS StateManagement p. 40.

Diagramme d'activité : déroulement de la décision et du traitement lors de la réception d'erreurs d'exécution et évaluation de l'ErrorRecoveryTable. Sources : SWS StateManagement p. 42, SWS StateManagement p. 69

Preuves détaillées supplémentaires

L'architecture et les voies d'interaction du State Management sont étayées par les exigences normatives et les choix de conception suivants :

• Commande système et transitions : [SWS_SM_91107] définit la demande de transition orientée service, tandis que [SWS_SM_91109] régit le champ de notification destiné au découplage des applications. La commande tabulaire est étayée par SWS StateManagement p. 44.
• Intégration des mises à jour logicielles : les méthodes de gestion de session [SWS_SM_91102], de préparation [SWS_SM_91103], de vérification [SWS_SM_91104], de préparation du rollback [SWS_SM_91105] et de finalisation [SWS_SM_91101] ainsi que les resets de machine [SWS_SM_91100] et les champs d'autorisation [SWS_SM_91106], [SWS_SM_91108] fixent l'interaction avec l'UCM conformément à EXP SWArchitecture p. 56.
• Suspend-to-RAM et gestion de l'énergie : la hiérarchie native de classes et d'interfaces autour de S2RHub [SWS_SM_81103], [SWS_SM_81110], S2RSatellite [SWS_SM_81003], [SWS_SM_81010] et l'interface du système d'exploitation [SWS_SM_71001], [SWS_SM_71003] constituent le socle normatif de l'économie d'énergie EXP SWArchitecture p. 54.
• Espace d'erreur : la conception du domaine d'erreur standardisé avec générateurs d'exceptions et d'ErrorCode s'appuie sur [SWS_SM_81240], [SWS_SM_81244] et [SWS_SM_81247].