namespace apext::sm

L'espace de noms apext::sm fournit des interfaces d'extension de plateforme normatives afin d'harmoniser les états d'énergie entre l'AUTOSAR Adaptive State Management et le système d'exploitation hôte SWS StateManagement §C.1 « Header: apext/sm/power_state_interface.h ». L'énumération apext::sm::PowerState permet de représenter de manière typée les modes d'économie d'énergie spécifiques à Linux [SWS_SM_71002]. De plus, le callback apext::sm::WakeUpHandler permet au système d'exploitation de déclencher une sortie autonome des états de repos dans le State Management sans application de commande en amont [SWS_SM_71004], cet appel n'étant pas conçu pour être thread-safe.

plus ›

Contexte

L'espace de noms apext::sm fournit des interfaces d'extension de plateforme normatives (Platform Extension Interfaces) pour le cluster fonctionnel State Management au sein de l'AUTOSAR Adaptive Platform SWS StateManagement §C.1 « Header: apext/sm/power_state_interface.h ». Alors que les interfaces standard du State Management servent principalement à coordonner les états d'application, les groupes de fonctions et les modes d'exécution au-delà des frontières du modèle, apext::sm s'adresse au couplage proche du matériel. Les interfaces d'extension sont conçues pour être utilisées ou fournies par des constructeurs (OEM) ou des intégrateurs afin d'étendre la fonctionnalité de la plateforme et de concrétiser une interaction coordonnée avec le système d'exploitation sous-jacent (OS) SWS StateManagement §C.1 « Header: apext/sm/power_state_interface.h ».

Le composant central de l'espace de noms est la classe PowerStateInterface, qui sert à coordonner les états d'énergie avec le système d'exploitation. Conjointement, l'en-tête apext/sm/power_state_interface.h définit des énumérations typées et des alias de callback qui font office de lien entre les pilotes du système d'exploitation, les sources de réveil externes et la gestion d'état interne. Outre le système d'exploitation, ces interfaces sont conceptuellement en relation avec le Controller du State Management ainsi qu'avec des instances de niveau supérieur telles que la SMControlApplication ou l'Update and Configuration Management (UCM), qui peuvent également influer sur les transitions d'état SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state ».

Diagramme de contexte : interaction entre le système d'exploitation, les interfaces apext::sm et le State Management. Sources : SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state », SWS StateManagement §C.1 « Header: apext/sm/power_state_interface.h ».

Cycle de vie

Le cycle de vie dans le cadre de apext::sm est marqué par les états d'énergie discrets modélisés dans l'énumération apext::sm::PowerState sur la base de std::uint32_t [SWS_SM_71002]. Ces états dérivent directement de la perspective du noyau des systèmes d'exploitation Linux :

• kPmSuspendToIdle (= 1) : dérivé de l'état PM_SUSPEND_TO_IDLE [SWS_SM_71002].
• kPmSuspendToRam (= 2) : dérivé de l'état PM_SUSPEND_TO_RAM [SWS_SM_71002].
• kPmHibernation (= 3) : Dérivé de l'état PM_HIBERNATION (Suspend-to-Disk) [SWS_SM_71002].
• kPmOff (= 4) : Dérivé de l'état PM_OFF (arrêt complet) [SWS_SM_71002].

Interprétation : la classe PowerStateInterface devrait servir de point d'ancrage principal par l'intermédiaire duquel l'intégrateur interroge ces états cibles ou les transmet au système d'exploitation hôte. Question Q-800acae699828764 (ouverte) Pendant le maintien dans un état d'économie d'énergie tel que kPmSuspendToRam, le traitement normal est suspendu jusqu'à ce qu'un événement de réveil initie la transition inverse vers le mode de fonctionnement actif.

Parcours d'utilisation

Un cas d'utilisation central de l'espace de noms est le réveil autonome de l'ensemble du système à partir d'un état de veille (Autonomous wake-up from suspend state) SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state ». Alors qu'une SMControlApplication peut demander explicitement la sortie du mode Suspend-to-RAM, State Management est en outre en mesure de réagir de manière autonome à des signaux de réveil.

Si le système d'exploitation signale un événement de réveil via l'interface apext::sm::WakeUpHandler – pour autant que celle-ci soit implémentée –, State Management initie de manière autonome une séquence de réveil SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state ». apext::sm::WakeUpHandler est un alias de fonction de type std::function<void(void)> [SWS_SM_71004]. En appelant ce gestionnaire, State Management fait passer la machine à états Controller de son état Suspend à l'état LeaveSuspend spécifiquement modélisé à cet effet [SWS_SM_CONSTR_00036]. Dans cet état, le contrôleur exécute obligatoirement l'élément d'action LeaveSuspendToRam, ce qui permet à l'activité régulière de la plateforme de reprendre sans intervention préalable d'une application de contrôle [SWS_SM_CONSTR_00037], SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state ».

Diagramme de séquence : déroulement du réveil autonome via le WakeUpHandler. Sources : SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state », [SWS_SM_71004], [SWS_SM_CONSTR_00036], [SWS_SM_CONSTR_00037].

Scénarios d'erreur

Lors de l'utilisation et de l'intégration de apext::sm, il convient de respecter les contraintes spécifiques au système et les risques de concurrence :

• Absence de sécurité des threads : selon la spécification, le type d'appel apext::sm::WakeUpHandler n'est expressément pas sûr pour les threads (not thread-safe) [SWS_SM_71004]. Si le système d'exploitation ou un contexte d'interruption déclenche des signaux multiples ou parallèles, l'intégrateur doit prévoir des mécanismes de synchronisation appropriés afin d'éviter les courses aux données et les transitions d'état incohérentes dans State Management.
• Gestionnaire non implémenté : si le WakeUpHandler n'est pas implémenté dans le système cible, aucun réveil autonome ne peut avoir lieu via le système d'exploitation ; dans ce cas, le système reste à l'état de veille jusqu'à ce que des demandes externes (par exemple par UCM via RequestUpdateSession) ou des requêtes explicites d'applications surviennent SWS StateManagement §7.7.15.1 « Autonomous wake-up from suspend state ».
• Erreur de modélisation dans le manifeste : si l'état LeaveSuspend pour le Controller [SWS_SM_CONSTR_00036] fait défaut dans le manifeste de déploiement, ou si celui-ci ne contient pas l'élément obligatoire LeaveSuspendToRam [SWS_SM_CONSTR_00037], la transition automatisée échoue et la plateforme ne peut pas reprendre son fonctionnement conformément aux prescriptions après l'état de veille.