module ara::exec — Execution Management

En tant que démon central de la plateforme, le module Execution Management gère le cycle de vie déterministe des processus POSIX sur l'AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement p. 18). Il reçoit les états d'exécution via le ExecutionClient ([SWS_EM_02003]) et met en œuvre de manière asynchrone les transitions de groupes de fonctions demandées par State Management en démarrant et en arrêtant des processus ([SWS_EM_02278]). Les contraintes essentielles sont l'interdiction de dépendances de démarrage entre groupes de fonctions ainsi que l'escalade stricte des erreurs en cas de dépassement d'échéance (SWS ExecutionManagement p. 65).

plus ›

Le cluster fonctionnel Execution Management (EM) constitue le démon central de plateforme de l'AUTOSAR Adaptive Platform pour la gestion déterministe des processus et le contrôle du cycle de vie dans l'espace utilisateur POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). Il sépare strictement la prise de décision (Policy) de l'application technique (Mechanism) : tandis que State Management définit les états cibles, EM contrôle la création des processus, les séquences et le traitement des signaux (AUTOSAR AP EXP SWArchitecture p. 56). Via le [SWS_EM_02562] ExecutionClient, les applications et les services de plateforme signalent leur état [SWS_EM_02000] kRunning par [SWS_EM_02003] ReportExecutionState(), tandis que State Management demande des changements d'état via le [SWS_EM_02276] StateClient (AUTOSAR AP EXP SWArchitecture p. 48).

Diagramme de contexte : intégration d'Execution Management en tant que démon central entre State Management, le système d'exploitation POSIX et les processus clients. Sources : AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Après son démarrage par le système d'exploitation, EM initialise State Management et synchronise celui-ci via [SWS_EM_02279] GetInitialMachineStateTransitionResult() sur l'état machine Startup (AUTOSAR AP SWS ExecutionManagement p. 52). Les transitions ultérieures d'états de [SWS_EM_02586] FunctionGroup sont déclenchées de manière asynchrone avec [SWS_EM_02278] SetState() : EM termine de manière ordonnée les processus qui ne sont plus nécessaires via SIGTERM, démarre les processus suivants en respectant les dépendances locales de démarrage et résout le Future résultant dès que tous les processus sont opérationnels (AUTOSAR AP SWS ExecutionManagement p. 53, SWS ExecutionManagement p. 71).

Diagramme de séquence : changement d'état réussi d'un groupe de fonctions avec arrêt ordonné et redémarrage de processus. Sources : AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Pour garantir les exigences temps réel, EM prend en charge le pré-mappage déterministe des processus afin d'éviter les défauts de page (SWS ExecutionManagement p. 82) ainsi que des pools de workers et des mécanismes de synchronisation déterministes (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 92). Si un processus ne respecte pas sa fenêtre temporelle de démarrage, le traitement des erreurs intervient : EM arrête le processus, place le groupe de fonctions dans un Undefined State, appelle le callback enregistré ([SWS_EM_02276]) et fournit les détails de l'erreur via [SWS_EM_02542] GetExecutionError() et le domaine d'erreur du module [SWS_EM_02281] ExecErrc (AUTOSAR AP SWS ExecutionManagement p. 54).

plus ›

Limites du système et rôle fonctionnel d'Execution Management

Le module exec (Execution Management, EM) constitue le service central de plateforme de l'AUTOSAR Adaptive Platform pour la gestion déterministe des processus et du cycle de vie dans l'espace utilisateur basé sur POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). La séparation stricte entre la décision de contrôle (Policy) et l'application technique (Mechanism) structure son architecture : alors que le cluster fonctionnel State Management prend les décisions relatives aux modes de fonctionnement de niveau supérieur et aux transitions, Execution Management agit comme l'entité d'exécution pour l'allocation des processus, les ordres de démarrage, la surveillance et l'arrêt (AUTOSAR AP EXP SWArchitecture p. 56).

Execution Management met en œuvre des interfaces d'exécution C++ natives pour deux rôles complémentaires : via la classe [SWS_EM_02562] ara::exec::ExecutionClient, les processus applicatifs ainsi que les démons internes à la plateforme (tels que Diagnostic Management, Platform Health Management ou Communication Management) signalent leur état d'exécution au démon (AUTOSAR AP EXP SWArchitecture p. 48, AUTOSAR AP SWS CommunicationManagement p. 34). Via l'interface [SWS_EM_02276] ara::exec::StateClient, State Management interagit avec le démon pour demander des transitions de groupes de fonctions et de machine, et pour interroger des messages d'état (AUTOSAR AP SWS ExecutionManagement p. 17).

Diagramme de contexte : intégration d'Execution Management en tant que démon central entre State Management, le système d'exploitation POSIX et les processus clients. Sources : AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Architecture d'états et modèle de cycle de vie à plusieurs niveaux

La gestion des états dans Execution Management opère sur trois niveaux hiérarchiques corrélés : les états de groupe de fonctions de niveau supérieur (Function Group States), les états de cycle de vie externes du système d'exploitation du point de vue du démon (Process States) ainsi que les états internes aux processus (Execution States) (AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 62). Au niveau du démon, un processus configuré parcourt typiquement la chaîne Idle, Starting, Running, Terminating et Terminated (AUTOSAR AP SWS StateManagement p. 32).

Pour la vue interne au processus, le module définit l'énumération [SWS_EM_02000] ara::exec::ExecutionState. L'état pouvant être signalé de manière normative à Execution Management est kRunning via la fonction membre [SWS_EM_02003] ReportExecutionState(). Les phases préalables telles que Initializing sont, pour Execution Management, des états implicites qui débutent immédiatement avec le premier ordonnancement du processus POSIX, avant l'exécution du code utile ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines p. 11). Les modes applicatifs de fonctionnement et d'énergie (PowerModes) ne constituent pas des états du système d'exploitation, mais sont logiquement couplés à la phase active du cycle de vie Running (AUTOSAR AP SWS StateManagement p. 32).

Diagramme d'états : corrélation entre les états des groupes de fonctions, les phases du cycle de vie dans Execution Management et les états internes des processus. Sources : AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 32, [SWS_EM_02000].

Démarrage déterministe de la plateforme et initialisation

Le démarrage de l'AUTOSAR Adaptive Platform s'effectue selon une séquence strictement coordonnée à partir du noyau du système d'exploitation (AUTOSAR EXP SWArchitecture p. 148). Le système d'exploitation démarre Execution Management via son point d'entrée de programme main() (AUTOSAR AP SWS ExecutionManagement p. 52). Immédiatement après son auto-initialisation, Execution Management crée le processus de State Management (AUTOSAR AP SWS StateManagement p. 25).

Dès que State Management est initialisé, il signale qu'il est opérationnel avec [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) via ExecutionClient à Execution Management (AUTOSAR AP SWS ExecutionManagement p. 52). Ensuite, State Management se synchronise via [SWS_EM_02279] GetInitialMachineStateTransitionResult() sur l'achèvement de la transition initiale de la machine vers l'état Startup ; cette méthode renvoie un ara::core::Future<void> ([SWS_EM_02279], AUTOSAR EXP SWArchitecture p. 151). Ce n'est qu'après la résolution réussie de ce future que State Management demande le passage aux états de groupe de fonctions suivants (AUTOSAR AP SWS StateManagement p. 24).

Diagramme de séquence : démarrage de la plateforme depuis l'initialisation par le système d'exploitation jusqu'à la libération de l'état suivant, en passant par le lancement de State Management. Sources : AUTOSAR AP SWS ExecutionManagement p. 52, AUTOSAR AP SWS StateManagement p. 25, [SWS_EM_02279], [SWS_EM_02003].

Contrôle des groupes de fonctions et transitions d'état asynchrones

Les changements d'état sont modélisés au niveau applicatif par des représentants des classes [SWS_EM_02586] ara::exec::FunctionGroup et [SWS_EM_02324] ara::exec::FunctionGroupState. Afin de garantir une gestion déterministe des ressources, FunctionGroup n'est pas copiable ([SWS_EM_02322], [SWS_EM_02327]), mais exclusivement déplaçable ([SWS_EM_02328], [SWS_EM_02329]) et évaluable par comparaison d'instances ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState associe un Function Group à un état cible ([SWS_EM_02324]) et prend en charge aussi bien la sémantique de copie que celle de déplacement ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

State Management initie une transition en appelant [SWS_EM_02278] StateClient::SetState(), ce qui renvoie de manière synchrone un ara::core::Future<void> (AUTOSAR AP SWS StateManagement p. 31). Execution Management exécute ensuite la chaîne de transition : les processus en cours d'exécution qui ne sont plus configurés dans l'état cible reçoivent un signal SIGTERM (AUTOSAR AP SWS ExecutionManagement p. 53). Après leur terminaison, EM démarre les processus prévus pour l'état cible et attend leur notification d'état via [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement p. 26, AUTOSAR SWS ExecutionManagement p. 49). Ce n'est que lorsque tous les processus concernés ont démarré avec succès que le future de SetState() est résolu positivement (AUTOSAR AP SWS ExecutionManagement p. 53).

Les dépendances d'exécution (Execution Dependencies) ne doivent jamais être définies au-delà des limites d'un seul Function Group ni même à travers des états différents (SWS ExecutionManagement p. 65). Lors des changements d'état, Execution Management effectue la résolution des dépendances de démarrage strictement pour les processus de l'état cible demandé (RequestedState) (SWS ExecutionManagement p. 71). Si les configurations de démarrage d'un processus diffèrent entre l'état initial et l'état cible, Execution Management force son redémarrage (SWS ExecutionManagement p. 65).

Diagramme de séquence : changement d'état réussi d'un groupe de fonctions avec arrêt ordonné et redémarrage de processus. Sources : AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Configuration des processus, allocation de mémoire et pré-mappage

Dans les systèmes réels, il existe, aux côtés des applications standard, des processus sans notification d'état intégrée (Non-reporting Processes). De tels processus passent automatiquement après le démarrage à l'état d'exécution Running (SWS ExecutionManagement p. 44). Afin de sécuriser néanmoins les chaînes de dépendance, un processus compagnon spécifique au projet (Companion Process) peut être placé en amont afin d'évaluer la disponibilité fonctionnelle du processus non déclarant et de notifier [SWS_EM_02003] kRunning par procuration avant que les processus dépendants suivants ne soient démarrés (SWS ExecutionManagement p. 44, SWS ExecutionManagement p. 48).

Concernant les besoins en ressources, le paramètre resourceConsumption.memoryUsage limite la mémoire centrale allouable par le processus lui-même, ce qui est généralement mis en œuvre sur les systèmes POSIX via RLIMIT_AS (SWS ExecutionManagement p. 82, SWS ExecutionManagement p. 104). Pour garantir le déterminisme temporel et la sécurité de fonctionnement, Execution Management prend en charge le pré-mappage (Pre-mapping) : si Process.preMapping est activé dans le manifeste, EM pré-mappe intégralement le code et les zones de données du processus dans la mémoire physique (SWS ExecutionManagement p. 82). Cela évite les retards dus au chargement à la demande (demand-loading) lors du premier accès, garantit la disponibilité permanente des routines de traitement d'erreurs critiques pour la sécurité et protège contre les erreurs ultérieures causées par des systèmes de fichiers corrompus (SWS ExecutionManagement p. 82).

Temps d'exécution déterministe et modèles de synchronisation

Pour les applications critiques en temps réel, Execution Management met à disposition des mécanismes d'exécution déterministe (SWS ExecutionManagement p. 79). Les processus cycliques interagissent avec le client via une API de point d'attente qui contrôle des modes tels que la découverte de services, l'initialisation, l'exécution et la terminaison (SWS ExecutionManagement p. 79). Le traitement parallèle des données est abstrait par des pools de threads de travail (worker pools) : afin de garantir le déterminisme des données, tout échange de données entre instances concurrentes de WorkerRunnable est interdit (SWS ExecutionManagement p. 86).

Pour synchroniser plusieurs processus redondants ou distribués, le DeterministicSyncMaster est utilisé (SWS ExecutionManagement p. 92). En cas d'activation événementielle, une règle configurable (telle qu'une décision majoritaire M parmi N) détermine le moment où les réponses de synchronisation sont envoyées (SWS ExecutionManagement p. 92). Lors d'une activation périodique, une synchronisation unique a lieu au début, après quoi un tampon global d'horodatage définit le cycle de démarrage et les cycles suivants sont gérés de manière autonome par des compteurs locaux et une surveillance des délais d'expiration (SWS ExecutionManagement p. 92). Le maître de synchronisation peut soit être déployé en tant que processus autonome, soit être intégré sous forme de bibliothèque dans le cadre d'un framework de lockstep logiciel (SWS ExecutionManagement p. 94, SWS ExecutionManagement p. 95).

Comportement en cas d'erreur

En cas d'erreur, l'architecture se divise selon le schéma général de tolérance aux pannes en détection d'erreurs (Error Detection) puis en reprise sur erreur (Error Recovery) (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 107). Si un délai d'expiration au démarrage (start-up timeout) survient lors d'un changement d'état de Function Group – par exemple parce qu'un processus qui démarre n'émet pas de [SWS_EM_02003] ReportExecutionState(kRunning) dans le délai paramétré –, Execution Management interrompt le déroulement normal (AUTOSAR AP SWS ExecutionManagement p. 54).

L'escalade interne devrait dans ce cas inclure la terminaison forcée du processus défaillant via SIGKILL ; après épuisement des tentatives de redémarrage configurées, le Function Group concerné passe dans un état indéfini (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02542]). Question Q-5a8b6ad2e9e22eb4 (ouverte) Lors de l'entrée dans un état indéfini, Execution Management déclenche le callback undefinedStateCallback transmis lors de l'instanciation de StateClient ([SWS_EM_02276], [SWS_EM_02561]). State Management peut ensuite interroger via [SWS_EM_02542] GetExecutionError() l'événement associé ara::exec::ExecutionErrorEvent, qui fournit le Function Group défaillant ([SWS_EM_02546]) et le code d'erreur [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) ([SWS_EM_02542]). Si le Function Group se trouve à nouveau dans un état défini, GetExecutionError() échoue ([SWS_EM_02542]).

Diagramme de séquence : Traitement d'erreur lors du délai d'expiration de démarrage d'un processus pendant une transition d'état. Sources : AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

Pour un traitement d'erreur uniforme, le module dispose du domaine d'erreur [SWS_EM_02286] ara::exec::ExecErrorDomain (accessible via [SWS_EM_02290] GetExecErrorDomain(), nom d'identification via [SWS_EM_02287] Name(), messages textuels via [SWS_EM_02288] Message()). Les erreurs d'exécution spécifiques sont représentées par le code d'énumération [SWS_EM_02281] ExecErrc (comme kNoCommunication) et construites via [SWS_EM_02291] MakeErrorCode(). Lorsque la gestion des exceptions est activée, les erreurs peuvent être levées via [SWS_EM_02289] ThrowAsException() sous la forme de [SWS_EM_02283] ExecException. De plus, le destructeur [SWS_EM_02002] ~ExecutionClient() garantit que les gestionnaires précédemment pris en charge pour SIGTERM sont réinitialisés à leur valeur d'origine, tandis que les callbacks d'interruption transmis lors de la création du processus s'appliquent lors de la réception d'un signal de fin ([SWS_EM_02560], [SWS_EM_02562]). Des actions de récupération plus étendues (Recovery Actions telles que le redémarrage de processus ou le passage en mode dégradé) sont orchestrées en coopération avec Platform Health Management (AUTOSAR SWS ExecutionManagement p. 54).

Preuves détaillées supplémentaires

L'aperçu suivant associe les exigences clés de la spécification et les références documentaires aux domaines thématiques traités :

Domaine thématique	Références essentielles	Signification fonctionnelle
Notification d'état de processus	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Définit ExecutionState, la création de ExecutionClient et la notification de kRunning.
Contrôle des groupes de fonctions	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Transition d'état asynchrone via SetState(), instanciation de FunctionGroup et FunctionGroupState.
Démarrage de la plateforme	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Synchronisation de State Management sur l'état initial de la machine Startup.
Traitement d'erreur & callbacks	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Enregistrement de undefinedStateCallback, interrogation de ExecutionErrorEvent, domaine d'erreur ExecErrc.
Déterminisme de la mémoire	SWS ExecutionManagement S. 82	Pré-mappage complet des processus pour éviter les latences causées par le chargement à la demande.