classe ara::sm::s2r::S2RHub

Dans State Management, la classe ara::sm::s2r::S2RHub coordonne l'entrée et la sortie de l'état Suspend-to-RAM pour les applications satellites enregistrées (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 « Interfaces for Suspend-to-Ram Notifications »). Elle permet à une application de commande de demander la préparation des satellites avant de faire passer le système d'exploitation en veille, puis de les ramener en fonctionnement normal après le réveil ([SWS_SM_00701], [SWS_SM_81112]). L'utilisation de l'API C++ exclut strictement l'approche interne StateMachine et nécessite des droits IAM vérifiés ([SWS_SM_00684], [SWS_SM_00706]).

plus ›

Contexte

La classe ara::sm::s2r::S2RHub constitue l'interface centrale de State Management pour la coordination des transitions Suspend-to-RAM sur l'Adaptive Platform (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 « Interfaces for Suspend-to-Ram Notifications »). Afin d'optimiser la durée d'arrêt et de démarrage de la machine, un Suspend-to-RAM peut être utilisé à la place d'un redémarrage complet du système (AUTOSAR_AP_SWS_StateManagement §7.5 « Interaction with Suspend-to-RAM Functionality »). La tâche principale du hub consiste à solliciter toutes les instances satellites activement enregistrées (ara::sm::s2r::S2RSatellite) afin d'initier une préparation ordonnée avant de faire passer le système d'exploitation à l'état suspend, puis de coordonner la reprise du fonctionnement après le réveil ([SWS_SM_00701], [SWS_SM_00703]).

L'utilisation de la classe S2RHub est réservée aux applications de commande dédiées telles que SMControlApplication et n'est pas destinée aux Adaptive Applications standard (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 « Interfaces for Suspend-to-Ram Notifications »). L'accès à la fonctionnalité de hub peut s'effectuer soit via l'API C++, soit en interne via l'approche StateMachine ; les deux variantes s'excluent mutuellement de manière stricte afin d'éviter les situations de compétition (race conditions) et les incohérences d'état (AUTOSAR_AP_SWS_StateManagement §7.5.1 « S2R Hub », AUTOSAR_AP_SWS_StateManagement §7.7.15 « Mutual exclusivity of StateMachine approach and S2RHub API usage », [SWS_SM_00684]). L'interaction avec les processus et les satellites est à cette occasion sécurisée par Identity and Access Management (IAM) ([SWS_SM_00706], [SWS_SM_00714], [SWS_SM_00715]).

Diagramme de contexte : intégration de S2RHub entre l'application de commande, les satellites et le système d'exploitation. Sources : AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4, AUTOSAR_AP_SWS_StateManagement §7.5.1, [SWS_SM_81112].

Cycle de vie

Une instance de ara::sm::s2r::S2RHub est explicitement créée via un ara::core::InstanceSpecifier ([SWS_SM_81103]). Lors de la construction, un contrôle obligatoire des autorisations IAM a lieu, durant lequel le contexte du processus appelant est validé par rapport au mappage de modèle (SuspendToRamHubMapping.process) ([SWS_SM_00706], [SWS_SM_00714]). Les opérations de copie sont totalement interdites pour la classe ([SWS_SM_81107], [SWS_SM_81109]). La classe prend toutefois en charge la sémantique de déplacement via un constructeur de déplacement et un opérateur d'affectation par déplacement ([SWS_SM_81106], [SWS_SM_81108]).

En matière de concurrence, le constructeur paramétré ainsi que les opérations de déplacement sont spécifiés comme étant sûrs pour les threads (thread-safe) ([SWS_SM_81103], [SWS_SM_81106], [SWS_SM_81108]). Le destructeur virtuel ~S2RHub() ainsi que les méthodes opérationnelles de coordination de la mise en veille ne sont en revanche pas sûrs pour les threads ([SWS_SM_81105], [SWS_SM_81110], [SWS_SM_81111], [SWS_SM_81112]). Les appelants doivent par conséquent s'assurer que la destruction et l'exécution des transitions se déroulent de manière séquentielle et sans appels concurrents.

Parcours d'utilisation

Le déroulement standard pour initier et terminer le Suspend-to-RAM s'articule en trois phases successives :

1. Préparation de l'état suspend : avant de suspendre le système d'exploitation, les groupes de fonctions comportant des processus non compatibles doivent être arrêtés (AUTOSAR_AP_SWS_StateManagement §7.5). L'application de commande appelle ensuite RequestToEnterSuspendMode() sur le hub ([SWS_SM_81110]). Le hub notifie tous les satellites enregistrés via Offer au moyen de EnterSuspendMode ([SWS_SM_00701], [SWS_SM_00710], [SWS_SM_00711]). La méthode renvoie un ara::core::Future<void>, qui ne se termine que lorsque tous les satellites adressés ont répondu, se sont désinscrits ou ont atteint un délai d'expiration (timeout) ([SWS_SM_00702], [SWS_SM_81110]).
2. Déclenchement du suspend système : après confirmation positive de tous les satellites, l'appelant déclenche le système d'exploitation via la fonction synchrone EnterSuspendToRamOs() afin de basculer la machine en mode Suspend-to-RAM ([SWS_SM_81112]).
3. Reprise après le réveil (wake-up) : dès que le système d'exploitation se réveille, l'application de commande initie la reprise du fonctionnement normal via RequestToLeaveSuspendMode() ([SWS_SM_81111]). Le hub invite tous les satellites actifs, via leur fonction de rappel, à quitter le mode suspend ([SWS_SM_00703], [SWS_SM_00711]). Le future renvoyé est résolu positivement lorsque tous les satellites acquittent positivement ou se désinscrivent via StopOffer ([SWS_SM_00707], [SWS_SM_81111]).

Diagramme de séquence : ordre d'appel typique pour la préparation de la mise en veille, l'exécution du suspend de l'OS et la réactivation consécutive. Sources : [SWS_SM_00701], [SWS_SM_00702], [SWS_SM_00703], [SWS_SM_00707], [SWS_SM_81110], [SWS_SM_81111], [SWS_SM_81112].

Scénarios d'erreur

Selon la phase, les conditions d'erreur sont signalées dans S2RHub via des violations d'architecture ou via des codes d'erreur dans ara::core::Future :

• Erreurs de construction et violations : si la vérification des autorisations du processus appelant échoue, la violation InsufficientPermissionsViolation ainsi que l'événement de sécurité SEV_ACCESS_CONTROL_SM_IAM_ACCESS_DENIED sont déclenchés ([SWS_SM_00706], [SWS_SM_81103]). Les autres violations définies comprennent InstanceSpecifierMappingIntegrityViolation (invalidité de l'identifiant de modèle), PortInterfaceMappingViolation (type d'interface incompatible), ProcessMappingViolation (affectation de processus manquante), InstanceSpecifierAlreadyInUseViolation (utilisation multiple dans le même processus) et AraNotInitializedViolation (initialisation manquante de l'Adaptive Platform) ([SWS_SM_81103]).
• Erreurs lors de l'entrée dans l'état suspend : si la communication échoue sur les couches inférieures, le future de RequestToEnterSuspendMode() échoue avec SmErrc::kCommunicationFailed ([SWS_SM_81110]). Si au moins un satellite ne répond pas dans la fenêtre temporelle configurable (par défaut : 1000 ms), cela se traduit par SmErrc::kCommunicationTimeout ([SWS_SM_81110]). Les deux erreurs possèdent une sémantique de retour arrière (rollback). Si au moins un satellite signale le refus de la transition, le future fournit l'erreur SmErrc::kAtLeastOneRejected sans sémantique de retour arrière ([SWS_SM_81110]).
• Erreurs lors de la sortie de l'état suspend : de manière analogue, des problèmes de communication ou des timeouts au niveau de RequestToLeaveSuspendMode() entraînent respectivement SmErrc::kCommunicationFailed ou SmErrc::kCommunicationTimeout ([SWS_SM_00707], [SWS_SM_81111]). Si un satellite répond avec kRejected, le future signale le code d'erreur SmErrc::kAtLeastOneHadIssuesToLeave ([SWS_SM_00707], [SWS_SM_81111]).
• Enregistrement de satellite rejeté : les tentatives d'enregistrement de satellites sont rejetées par le hub si le contexte de leur processus ne correspond pas à la configuration du modèle ([SWS_SM_00715]).