namespace ara::sm::s2r

Le namespace ara::sm::s2r coordonne le mécanisme Suspend-to-RAM afin d'optimiser les temps d'arrêt et de démarrage dans l'AUTOSAR Adaptive Platform (SWS StateManagement §7.5 « Interaction with Suspend-to-RAM Functionality »). Via le composant central S2RHub et des instances de S2RSatellite enregistrées, les processus compatibles S2R sont notifiés avant l'entrée dans l'état de veille du système d'exploitation et sont ramenés au fonctionnement normal lors du réveil. En tant que contrainte essentielle, l'utilisation via l'approche interne StateMachine exclut strictement l'accès via l'API C++, tandis que des vérifications IAM sécurisent l'ensemble des contextes de processus impliqués ([SWS_SM_00684]).

plus ›

Contexte

Le namespace ara::sm::s2r fournit des fonctionnalités pour la coordination du Suspend-to-RAM (S2R) au sein du module State Management. L'objectif de ce mécanisme est d'optimiser les temps d'arrêt et de démarrage de la machine en utilisant un état de veille du système d'exploitation basé sur la RAM au lieu d'un arrêt complet et d'un démarrage à froid (SWS StateManagement §7.5 « Interaction with Suspend-to-RAM Functionality »). Avant le passage à l'état de suspension du système d'exploitation, les entités fonctionnelles sans prise en charge de S2R doivent être désactivées et les processus dont l'exécutable est marqué comme suspendToRamAware doivent être notifiés à temps (SWS StateManagement §7.5 « Interaction with Suspend-to-RAM Functionality »).

La plaque tournante centrale est constituée par la classe S2RHub, qui contrôle la communication avec les instances de la classe abstraite S2RSatellite (SWS StateManagement §7.5.1 « S2R Hub »). L'orchestration du S2RHub peut s'effectuer soit en interne via l'approche StateMachine de State Management, soit en externe via une API C++ (par exemple dans une SMControlApplication) ; les deux approches s'excluent strictement mutuellement ([SWS_SM_00684], SWS StateManagement p. 96). Les accès au hub et l'enregistrement des satellites sont sécurisés par Identity and Access Management (IAM) ([SWS_SM_00706], [SWS_SM_00714], [SWS_SM_00715]).

Diagramme de contexte : interaction entre State Management, S2RHub, S2RSatellite et IAM. Sources : SWS StateManagement §7.5.1 « S2R Hub », [SWS_SM_00684], [SWS_SM_00715].

Cycle de vie

L'instanciation de ara::sm::s2r::S2RHub dépend de l'approche architecturale : en mode StateMachine, l'instance est créée automatiquement par State Management dès que les éléments de liste d'actions EnterSuspendToRam, EnterSuspendToRamOS ou LeaveSuspendToRam sont terminés ([SWS_SM_00690]). Lors de l'appel du constructeur ara::sm::s2r::S2RHub::S2RHub, l'IAM vérifie si le contexte de processus actuel correspond à la configuration SuspendToRamHubMapping.process ([SWS_SM_00706]). Seuls les processus autorisés peuvent effectuer l'instanciation ([SWS_SM_00714]).

Les satellites sont initialisés via la méthode de fabrique ara::sm::s2r::S2RSatellite::Create ([SWS_SM_00716]). S2RSatellite étant une classe abstraite, une dérivation spécifique à l'application devrait être implémentée afin de fournir les réactions concrètes (interprétation). Question Q-e4747345883235e0 (ouverte) L'enregistrement auprès du hub s'effectue activement par l'appel de ara::sm::s2r::S2RSatellite::Offer ([SWS_SM_00710]). Le hub valide le contexte de processus du satellite à l'aide de SuspendToRamSatelliteMapping.process ([SWS_SM_00715]). Un satellite reste dans l'état d'enregistrement actif jusqu'à ce qu'il se désenregistre via ara::sm::s2r::S2RSatellite::StopOffer ([SWS_SM_00710], [SWS_SM_00713]).

Concernant le cycle de vie des machines à états, il existe une contrainte selon laquelle les états responsables de l'état de suspension ne doivent pas être configurés avec l'élément de liste d'actions LeaveSuspendToRam ([SWS_SM_CONSTR_00035]). Cet élément est exclusivement réservé à la phase de retour lors du réveil (SWS StateManagement p. 98).

Parcours d'utilisation

L'utilisation typique du namespace se divise en l'enregistrement, la préparation de l'état de veille, la suspension du système d'exploitation ainsi que le réveil ultérieur :

1. Enregistrement : l'application compatible S2R crée son satellite et appelle ara::sm::s2r::S2RSatellite::Offer pour s'enregistrer auprès du hub ([SWS_SM_00710]). La notification entre le hub et les satellites s'effectue vraisemblablement via une communication inter-processus interne à la plateforme (interprétation). Question (ouverte)
2. Demander la suspension : le niveau de contrôle appelle ara::sm::s2r::S2RHub::RequestToEnterSuspendMode ([SWS_SM_00701]). Dans l'approche StateMachine, cela est déclenché par l'élément EnterSuspendToRam, sa valeur de configuration maxActionItemDuration étant passée comme paramètre de timeout ([SWS_SM_00689]).
3. Notifier les satellites : le hub adresse tous les satellites enregistrés et déclenche l'exécution du callback ara::sm::s2r::S2RSatellite::EnterSuspendMode ([SWS_SM_00701], [SWS_SM_00711]). RequestToEnterSuspendMode retourne dès que tous les satellites ont réagi, ont été désenregistrés ou qu'un timeout est survenu ([SWS_SM_00702]).
4. Suspendre le système d'exploitation : l'état de veille effectif du système d'exploitation est initié par l'appel de ara::sm::s2r::S2RHub::EnterSuspendToRamOs (ou via l'élément de liste d'actions EnterSuspendToRamOs) ([SWS_SM_00692]).
5. Coordonner le réveil : après le redémarrage, ara::sm::s2r::S2RHub::RequestToLeaveSuspendMode est appelé ([SWS_SM_00703], [SWS_SM_00691]). Le hub donne pour instruction aux satellites d'exécuter le callback ara::sm::s2r::S2RSatellite::LeaveSuspendMode ([SWS_SM_00703], [SWS_SM_00711]).
6. Désenregistrement : si un processus ne souhaite plus participer, il se désenregistre via ara::sm::s2r::S2RSatellite::StopOffer ([SWS_SM_00710], [SWS_SM_00713]).

Diagramme de séquence : ordre des appels pour la préparation et la fin du Suspend-to-RAM. Sources : [SWS_SM_00701], [SWS_SM_00702], [SWS_SM_00703], [SWS_SM_00707], [SWS_SM_00710], [SWS_SM_00711].

Scénarios d'erreur

Des conditions d'erreur spécifiques surviennent lors de l'interaction entre les classes :

• Violation IAM lors de la création du hub : si le contexte de processus lors de l'appel du constructeur ne correspond pas à SuspendToRamHubMapping.process, la violation InsufficientPermissionsViolation est déclenchée et l'événement de sécurité SEV_ACCESS_CONTROL_SM_IAM_ACCESS_DENIED</a> est signalé ([SWS_SM_00706]).
• Rejet de satellites non authentifiés : si le contexte de S2RSatellite diffère du processus défini dans SuspendToRamSatelliteMapping, le hub rejette l'enregistrement ([SWS_SM_00715]).
• Exigence d'authentification sur le satellite : si la configuration Force IAM switch est activée, ara::sm::s2r::S2RSatellite::Create échoue avec le code d'erreur kAuthenticationRequired ([SWS_SM_00716]).
• Dépassement du délai de communication : si un satellite adressé ne répond pas dans le délai timeout pendant la phase de suspension ou de réveil, l'opération renvoie le code d'erreur kCommunicationTimeout ([SWS_SM_00707]).
• Problèmes lors de la sortie du mode de suspension : si au moins un satellite répond négativement avec kRejected à la demande de sortie du mode de suspension, RequestToLeaveSuspendMode acquitte le résultat global par kAtLeastOneHadIssuesToLeave ([SWS_SM_00707]).
• Utilisation concurrente de l'API : l'utilisation simultanée de l'API C++ de S2RHub en parallèle de l'approche interne StateMachine est interdite et conduit à des incohérences ([SWS_SM_00684]).