interface de service UpdateRequest

La méthode de service PrepareRollback de l'interface de service UpdateRequest est appelée par Update and Configuration Management afin de préparer l'annulation des modifications pour les groupes de fonctions d'un cluster de logiciels transmis dans le paramètre functionGroupList [SWS_SM_91105]. L'appel s'effectue sans sémantique « fire and forget », de sorte que State Management renvoie le résultat de la préparation à l'appelant [SWS_SM_91105].

Des conditions strictes s'appliquent à l'appel et au traitement des erreurs :

• Contexte de session : l'appel n'est autorisé qu'au sein d'une session de mise à jour active. S'il a lieu en dehors d'une session active, State Management rejette l'opération avec l'erreur kOperationRejected [SWS_SM_00213].
• Erreur d'application : outre kOperationRejected en cas d'état interne invalide, la méthode peut renvoyer kOperationFailed si la préparation échoue [SWS_SM_91105].

Dans le modèle d'état, l'appel de méthode a des répercussions directes sur les machines à états impliquées :

• Les machines à états gérant l'un des groupes de fonctions transmis sont marquées comme ImpactedByUpdate par le processus de commande [SWS_SM_00654].
• Si une machine à états de type Agent est marquée, ce statut est également transmis par transitivité au Controller de niveau supérieur [SWS_SM_00655].
• Pour les machines à états identifiées comme ImpactedByUpdate, les erreurs d'exécution signalées (ExecutionErrorEvent::executionError) ne sont pas traitées par une récupération, mais sont ignorées et simplement journalisées [SWS_SM_00664].

Utilisation

La méthode de service PrepareUpdate est appelée par l'Update and Configuration Management (UCM) pour demander au State Management de préparer la mise à jour d'un ensemble de groupes de fonctions [SWS_SM_00206], [SWS_SM_91103]. Elle est fournie via l'interface de service UpdateRequest et reçoit en paramètre d'entrée la liste functionGroupList de type FunctionGroupListType, qui spécifie les groupes de fonctions à mettre à jour au sein du cluster de logiciels [SWS_SM_91103]. Comme Fire & Forget est désactivé, l'appel possède une sémantique de réponse synchrone avec acquittement à l'appelant [SWS_SM_91103].

Conditions d'ordonnancement et concurrence

Un appel n'est autorisé qu'au sein d'une session de mise à jour préalablement initiée avec succès par RequestUpdateSession [SWS_SM_91103]. Durant l'appel, le processus de contrôle marque comme ImpactedByUpdate toutes les machines d'état qui gèrent l'un des groupes de fonctions transmis [SWS_SM_00654]. Si cela concerne une machine d'état de type Agent, la machine d'état Controller de niveau supérieur est aussi automatiquement marquée comme ImpactedByUpdate [SWS_SM_00655]. Tant que cet état persiste, les transitions d'état externes sont bloquées : chaque appel de RequestTransition reçoit comme réponse kUpdateInProgress [SWS_SM_00649]. De plus, les demandes de récupération en cas d'erreurs d'exécution (ExecutionErrorEvent::executionError) sont ignorées et simplement journalisées [SWS_SM_00664].

Gestion des erreurs

Deux erreurs applicatives spécifiques sont définies pour la méthode [SWS_SM_91103] :

• kOperationRejected : est renvoyée si l'appel a lieu en dehors d'une session de mise à jour active [SWS_SM_00213] ou si l'état interne du State Management rejette l'opération [SWS_SM_91103].
• kOperationFailed : indique que la préparation demandée des groupes de fonctions a échoué [SWS_SM_91103].

Interprétation : la méthode ne devrait retourner qu'après l'initiation ou l'achèvement des transitions d'état internes des groupes de fonctions, car aucun mécanisme de confirmation asynchrone distinct n'est défini dans l'interface. Question Q-9994d886fd5504d8 (ouverte)

La méthode de service RequestUpdateSession de l'interface UpdateRequest est appelée sans paramètre (Fire & Forget: false) et sert de point d'entrée à Update and Configuration Management pour initier une mise à jour logicielle [SWS_SM_91102]. L'appel engage la transition vers une session de mise à jour active, qui dure jusqu'à l'achèvement de la mise à jour [SWS_SM_00210] [SWS_SM_00213].

Par machine, au maximum un port peut être typé avec l'interface UpdateRequest [SWS_SM_CONSTR_00020], qui ne peut être fournie que par un processus contrôlant une StateMachine de type Controller [SWS_SM_00629]. Pour garantir la cohérence de la plateforme, une seule session de mise à jour peut être active à un instant donné [SWS_SM_00210]. De plus, State Management persiste l'état de session afin que celui-ci puisse être lu après un redémarrage de la machine [SWS_SM_00204].

L'acceptation réussie de la session constitue une condition d'ordonnancement stricte : des méthodes ultérieures telles que PrepareUpdate [SWS_SM_91103], ResetMachine [SWS_SM_91100] ou StopUpdateSession [SWS_SM_91101] présupposent que RequestUpdateSession a été préalablement appelée avec succès [SWS_SM_00213].

En cas d'erreur, deux erreurs spécifiques à l'application sont définies [SWS_SM_91102] : si la méthode est appelée pendant une session déjà en cours, elle renvoie kNotAllowedMultipleUpdateSessions [SWS_SM_00209]. Si la vérification (par exemple via l'interface UpdateAllowed) indique que la machine n'autorise actuellement pas de mise à jour, la demande est rejetée avec l'erreur kOperationRejected [SWS_SM_00630].

La méthode de service ResetMachine dans l'interface de service UpdateRequest est appelée par l'Update and Configuration Management (UCM) pour demander un redémarrage de la machine pendant une session de mise à jour en cours [SWS_SM_91100]. La méthode ne possède aucun paramètre d'entrée et est déclarée avec une sémantique « fire-and-forget » [SWS_SM_91100].

Avant d'effectuer le redémarrage, toutes les informations internes à la machine doivent être enregistrées de manière persistante [SWS_SM_91100]. Le State Management sauvegarde à cet effet les données de la session de mise à jour active afin qu'UCM puisse reprendre de manière cohérente le processus de mise à jour après le redémarrage de la machine [SWS_SM_00204]. Lors de l'appel de la méthode, le processus de contrôle fait passer la StateMachine de type Controller à l'état Restart [SWS_SM_00658]. Une fois le redémarrage de la machine effectué, le Controller passe à l'état ContinueUpdate pour reprendre la mise à jour SWS StateManagement §7.2 « ResetMachine notification ».

Pour la synchronisation et le suivi de l'exécution, le State Management met à disposition le champ ResetMachineNotifier [SWS_SM_00211] [SWS_SM_91106], dont la valeur initiale est kIdle [SWS_SM_00212]. ResetMachine étant conçu comme un appel « fire-and-forget », UCM devrait principalement surveiller le résultat du redémarrage de manière asynchrone via ce notificateur (interprétation). Question Q-732913d75d024929 (ouverte)

Si aucune session de mise à jour n'a été préalablement établie avec succès via RequestUpdateSession, l'appel est rejeté et renvoie l'erreur kOperationRejected [SWS_SM_91100]. En cas d'appel en dehors d'une session de mise à jour, le processus définit en outre la valeur du champ ResetMachineNotifier sur kRejected [SWS_SM_00661].

Le champ de service ResetMachineNotifier du type UpdateStatusType [SWS_SM_91027] appartient à l'interface de service UpdateRequest et sert à permettre à l'Update and Configuration Management (UCM) de suivre l'état de la méthode ResetMachine pendant et après son exécution [SWS_SM_00211] [SWS_SM_91106]. Le champ fournit un getter ainsi qu'un notifieur, mais ne possède aucun setter [SWS_SM_91106]. UCM devrait typiquement s'abonner au notifieur afin de recevoir les changements d'état de manière asynchrone sans scrutation (polling) après le redémarrage de la machine. Question Q-122f44b23cd76238 (ouverte)

Le cycle de vie du champ comprend les états et transitions d'état suivants :

• Valeur initiale : La valeur par défaut du champ est kIdle [SWS_SM_00212].
• Rejet hors session : Si un appel de ResetMachine a lieu en dehors d'une session de mise à jour active, le processus de contrôleur modélisé définit la valeur du champ sur kRejected [SWS_SM_00661].
• Redémarrage et poursuite : Au sein d'une session de mise à jour, ResetMachine entraîne une transition vers l'état Restart [SWS_SM_00658]. Après le démarrage de la machine, State Management et UCM se synchronisent à nouveau. En cas de succès de la transition vers ContinueUpdate, le champ est défini sur kSuccessful [SWS_SM_00662].
• Cas d'erreur : Si l'exécution de la transition vers ContinueUpdate échoue, la valeur du champ bascule sur kFailed [SWS_SM_00663].

Si la session de mise à jour est terminée via StopUpdateSession, la State Machine bascule dans l'état AfterUpdate [SWS_SM_00646], et State Management réinitialise le champ ResetMachineNotifier à la valeur par défaut kIdle [SWS_SM_00660].

La méthode de service StopUpdateSession de l'interface de service UpdateRequest ([SWS_SM_91101]) est appelée par l'Update and Configuration Management dès que la mise à jour est terminée et que la Machine se trouve dans un état stable. L'appel s'effectue sans paramètre et possède une sémantique de requête-réponse synchrone ou asynchrone (le mode Fire & Forget est false).

Conditions d'appel et gestion des erreurs

L'exécution requiert une session de mise à jour préalablement démarrée avec succès. Si l'appel de StopUpdateSession a lieu en dehors d'une session de mise à jour active, la requête est rejetée et renvoie l'erreur kOperationRejected ([SWS_SM_00213], [SWS_SM_91101]).

Comportement du système et transitions d'état

L'appel met fin à la session de mise à jour en cours (AUTOSAR_AP_SWS_StateManagement p. 90). Dans le State Management, cela déclenche plusieurs actions coordonnées :

• Le processus modélisé qui contrôle la StateMachine de type Controller la fait passer à l'état AfterUpdate ([SWS_SM_00646]).
• Le champ ResetMachineNotifier est réinitialisé à sa valeur par défaut ([SWS_SM_00660]).
• Pour les instances de StateMachine de type Controller, le blocage de RequestTransition est levé ; les appels subséquents ne répondent plus par kUpdateInProgress ([SWS_SM_00647]).
• Le marquage ImpactedByUpdate est retiré des instances de StateMachine concernées ([SWS_SM_00656]), ce qui libère à nouveau les transitions d'état régulières et les Recovery Actions.

Utilisation et contexte d'appel

La méthode de service VerifyUpdate est appelée par Update and Configuration Management (UCM) via l'interface de service UpdateRequest pour charger State Management de la vérification de groupes de fonctions mis à jour [SWS_SM_00207]. En guise de paramètre, functionGroupList (type FunctionGroupListType) est transmis, qui contient la liste des groupes de fonctions à vérifier dans le SoftwareCluster concerné [SWS_SM_91104]. La méthode n'étant pas définie en tant que Fire-and-Forget (Fire & Forget: false), l'appelant attend un retour synchrone ou disponible après l'achèvement [SWS_SM_91104].

Ordre d'exécution et traitement des erreurs

L'appel est soumis à de strictes conditions d'état : il n'est autorisé qu'au sein d'une session de mise à jour active et présuppose que State Management a autorisé la mise à jour et que la phase PrepareUpdate s'est auparavant achevée avec succès [SWS_SM_91104].

• kOperationRejected : est renvoyé lorsque l'appel a lieu en dehors d'une session de mise à jour active [SWS_SM_00213] ou lorsque l'état interne de State Management ou des machines d'état concernées refuse la vérification (par exemple si PrepareUpdate n'a pas abouti) [SWS_SM_91104].
• kOperationFailed : indique que l'opération de vérification demandée a échoué [SWS_SM_91104].

Interaction et concurrence

Pendant le traitement, le processus modélisé de contrôle d'une StateMachine de type Controller marque comme ImpactedByUpdate chaque machine d'état dont les groupes de fonctions gérés sont répertoriés dans functionGroupList [SWS_SM_00654]. Si cela concerne une StateMachine de type Agent, le Controller associé est également marqué indirectement comme ImpactedByUpdate [SWS_SM_00655]. Tant que cet état est actif, les erreurs d'exécution signalées (ExecutionErrorEvent::executionError) provenant de Platform Health Management ou d'Execution Management sont ignorées et simplement journalisées [SWS_SM_00664]. Les machines d'état concernées sont vraisemblablement placées pendant cette étape dans l'état VerifyUpdate, qui compte parmi les cinq états obligatoires de toute StateMachine AUTOSAR_AP_SWS_StateManagement §7.7.1 « StateMachine introduction ». Question Q-cd5deaf13acfc2f5 (ouverte)