namespace ara::sm

L'espace de noms ara::sm fournit la gestion des erreurs spécifique au domaine et des structures de coordination pour le State Management dans AUTOSAR Adaptive (AUTOSAR_AP_SWS_StateManagement §7.5 p. 34). Il définit via SmErrc, SmErrorDomain et MakeErrorCode des mécanismes standardisés pour consigner les erreurs de communication, les délais d'attente (timeouts) et les rejets lors de transitions d'état synchronisées telles que Suspend-to-RAM ([SWS_SM_81240], [SWS_SM_81244]). Une contrainte déterminante est l'exclusion mutuelle entre la commande automatisée par machine à états et l'accès direct par l'API aux instances de coordination ([SWS_SM_00684]).

plus ›

Contexte

L'espace de noms ara::sm constitue l'interface fondamentale pour la gestion des états (State Management) de l'AUTOSAR Adaptive Platform et fournit des types pour la gestion des erreurs ainsi que pour la commande de configurations d'état à l'échelle de la machine. Outre le domaine d'erreur central SmErrorDomain et le type d'exception associé SmException, le module comprend des mécanismes fonctionnels pour la synchronisation des états du système, en particulier dans le cadre de la fonctionnalité Suspend-to-RAM selon AUTOSAR_AP_SWS_StateManagement §7.5 « Interaction with Suspend-to-RAM Functionality » p. 34. Parmi les partenaires d'interaction déterminants figurent des applications de commande telles que la SMControlApplication, le contrôleur interne StateMachine du démon de State Management ainsi que des processus raccordés via des satellites (AUTOSAR_AP_SWS_StateManagement §7.5.1 « S2R Hub » p. 35).

L'architecture sépare strictement les automates d'état déclaratifs de la commande programmatique : si le système suit l'approche StateMachine, l'instance de commande intègre la coordination en interne, de sorte que l'accès direct à l'API C++ du S2RHub est refusé aux applications externes ([SWS_SM_00684] ; AUTOSAR_AP_SWS_StateManagement §7.7.15 p. 96). Les interactions touchant à la sécurité sont en outre soumises à des contrôles de l'Identity and Access Management (IAM) afin de garantir que seuls les processus autorisés puissent effectuer des enregistrements ou demander des changements d'état ([SWS_SM_00706], [SWS_SM_00714], [SWS_SM_00715]).

Diagramme de contexte : répartition des rôles et voies d'interaction entre l'application de commande, le démon de State Management, les satellites et le domaine d'erreur. Sources : [SWS_SM_00684], [SWS_SM_00701], [SWS_SM_00710], [SWS_SM_81240], [SWS_SM_81251].

Parcours d'utilisation

L'utilisation typique de l'espace de noms se divise en l'enregistrement de processus côté application, le déclenchement de transitions coordonnées et l'évaluation des codes d'erreur résultants. Pour les processus disposant de capacités Suspend-to-RAM, le cycle commence par la mise à disposition de leur interface via Offer ([SWS_SM_00710]). Avant le passage du système d'exploitation à l'état de repos, l'instance de commande envoie au moyen de RequestToEnterSuspendMode une invite à tous les satellites enregistrés, à la suite de quoi leur rappel EnterSuspendMode est déclenché ([SWS_SM_00701], [SWS_SM_00711]).

La fonction coordinatrice bloque ou surveille la transition jusqu'à ce que tous les satellites participants aient répondu ou aient été désenregistrés ([SWS_SM_00702]). Lors du réveil, l'appel de RequestToLeaveSuspendMode s'effectue de manière analogue, rétablissant le fonctionnement normal via LeaveSuspendMode ([SWS_SM_00703], [SWS_SM_00711]). Si des interruptions surviennent lors de la communication ou des changements d'état, le module recourt à la fonction libre MakeErrorCode ([SWS_SM_81244]) pour créer des instances spécifiques de ara::core::ErrorCode sur la base de l'énumération SmErrc et les mettre à la disposition de l'application appelante.

Diagramme de séquence : déroulement typique de la coordination du suspend avec des satellites et gestion des erreurs. Sources : [SWS_SM_00701], [SWS_SM_00702], [SWS_SM_00707], [SWS_SM_81240], [SWS_SM_81244].

Scénarios d'erreur

La gestion des erreurs dans ara::sm est strictement typée et repose sur l'énumération SmErrc ([SWS_SM_81240]). Parmi les codes d'erreur définis figurent :

• kOfferFailed : le service n'a pas pu être proposé car la communication avec le démon de State Management a échoué ([SWS_SM_81240]).
• kCommunicationFailed : erreur sur les couches de transport inférieures lors de la communication avec les satellites ([SWS_SM_81240]).
• kCommunicationTimeout : un satellite sollicité a dépassé le temps de réponse prédéfini ([SWS_SM_81240], [SWS_SM_00707]).
• kAtLeastOneRejected : au moins un satellite n'a pas pu adopter correctement l'état suspend ([SWS_SM_81240]).
• kAtLeastOneHadIssuesToLeave : au moins un satellite a signalé kRejected lors de la sortie du mode suspend ([SWS_SM_81240], [SWS_SM_00707]).
• kAuthenticationRequired : l'authentification IAM est forcée et exige une vérification d'identité explicite du satellite ([SWS_SM_81240], [SWS_SM_00716]).

La mise à disposition du domaine d'erreur global via GetSmDomain ([SWS_SM_81251]) et la création de codes d'erreur via MakeErrorCode ([SWS_SM_81244]) sont déclarées comme noexcept et garantissent la sécurité vis-à-vis des exceptions et des threads. Interprétation : la levée d'une SmException ne devrait trouver d'application principalement que si les appelants souhaitent convertir des codes d'erreur de la SmErrorDomain en flux de contrôle basés sur des exceptions, tandis que les interfaces fonctionnelles renvoient régulièrement ara::core::ErrorCode en cas d'erreur. Question Q-5afcc13f11bdf19b (ouverte)