AUTOSAR Classic Runtime Environment (RTE)

Le cluster de modules Runtime Environment (RTE) concrétise le Virtual Functional Bus AUTOSAR sur le calculateur et fournit des API standardisées pour la communication typée Sender-Receiver et Client-Server des composants logiciels [SWS_Rte_01091], [SWS_Rte_01102]. Il intègre le Basic Software Scheduler (SchM) pour l'ordonnancement cyclique des modules de la Basic Software et se connecte à l'OS/IOC ainsi qu'à la pile de communication (COM, LdCom) [SWS_Rte_01376], [SWS_Rte_04546]. Ce faisant, la RTE garantit la cohérence des données et des transitions de mode déterministes grâce à des sections critiques configurables, à la mise en mémoire tampon et à des séquences de transition définies en 10 étapes [SWS_Rte_02665], [SWS_Rte_03504].

plus ›

Le cluster de modules Runtime Environment (RTE) constitue la réalisation du Virtual Functional Bus (VFB) au niveau de l'ECU. Il découple entièrement les composants logiciels AUTOSAR (SWC) de la Basic Software sous-jacente et coordonne, via le Basic Software Scheduler (SchM), l'ordonnancement des modules BSW [SWS_Rte_04546], [SWS_Rte_05165]. Le cluster prend en charge aussi bien les accès intra-partition que les flux de données inter-partitions via l'IOC de l'OS ainsi que le bus du calculateur via les modules COM et LdCom [SWS_Rte_01376], [SWS_Rte_02736], SWS_RTE p. 106.

Diagramme de contexte : intégration du cluster RTE et SchM entre la couche applicative (SWC), l'OS/IOC et les services de la Basic Software. Sources : [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

La communication repose sur des modèles Sender-Receiver et Client-Server : les données S/R sont transmises de manière implicitement cohérente via des copies de tampons (`Rte_IRead`/`Rte_IWrite`) ou de manière explicite, directe et tamponnée (`Rte_Read`/`Rte_Write`/`Rte_Receive`) [SWS_Rte_01091], [SWS_Rte_02521], [SWS_Rte_06000]. En cas de défaillance ou de présence de signaux invalides, des mécanismes tels que la substitution par `initValue` ou les stratégies `handleInvalid` interviennent [SWS_Rte_05030], [SWS_Rte_06009]. Les appels Client-Server (`Rte_Call`, `Rte_Result`) sont synchronisés, en cas d'exécution asynchrone, via des files d'attente FIFO côté serveur et côté client, et sont associés de manière univoque au moyen de descripteurs de transaction [SWS_Rte_01102], [SWS_Rte_02527], [SWS_Rte_02649].

Dans la gestion des tâches et du cycle de vie, la RTE garantit la réentrance par le partage de code (code-sharing) et protège les sections critiques à l'aide de mécanismes de verrouillage configurables tels que le masquage d'interruptions, les ressources de l'OS ou les spinlocks de l'OS [SWS_Rte_03015], [SWS_Rte_03504]. Les changements de mode suivent une séquence stricte en 10 étapes allant des activations OnExit et OnTransition jusqu'à OnEntry, et s'achèvent de manière ordonnée par des événements d'acquittement [SWS_Rte_02665], [SWS_Rte_02679].

plus ›

Architecture système & rôle du cluster de modules

Le cluster de modules de la Runtime Environment (RTE) constitue l'épine dorsale fonctionnelle et communicative d'AUTOSAR Classic Platform. Il représente la réalisation concrète du Virtual Functional Bus (VFB) sur un calculateur et découple entièrement les composants logiciels (SWC) de la Basic Software (BSW) sous-jacente ainsi que du matériel microcontrôleur SWS_RTE p. 106. Au sein du cluster, la RTE proprement dite prend en charge l'acheminement de la communication applicative inter- et intra-ECU, tandis que le Basic Software Scheduler (SchM) intégré gère le contrôle d'exécution, la garantie de cohérence et l'ordonnancement cyclique des modules BSW [SWS_Rte_04546], [SWS_Rte_05165].

L'architecture déploie des interfaces standardisées entre les SWC d'application, les composants capteurs/actionneurs et les couches BSW. Pour l'interconnexion à l'échelle du véhicule, le cluster RTE s'appuie directement sur la pile de communication : les messages orientés signal sont transmis au module COM, tandis que les volumes importants de données sont traités via le module LdCom (Large Data COM) [SWS_Rte_01376], [SWS_Rte_04527]. L'isolation des processus et de la mémoire par-delà les frontières de partitions et de cœurs est assurée par le système d'exploitation AUTOSAR (OS) et son mécanisme de communication entre applications de l'OS (IOC) [SWS_Rte_02736]. Les données de calibration et les blocs de mémoire se raccordent au NVRAM Manager (NvM) et aux outils de calibration via des descripteurs standardisés [SWS_Rte_03961], [SWS_Rte_05118].

Diagramme de contexte : intégration du cluster RTE et SchM entre la couche applicative (SWC), l'OS/IOC et les services de la Basic Software. Sources : [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

Interaction & voies d'interaction entre les modules

L'interaction au sein du cluster RTE distingue strictement la communication Sender-Receiver (S/R) de la communication Client-Server (C/S). Pour la communication S/R, la RTE prend en charge les sémantiques de lecture et d'écriture implicites ainsi qu'explicites : lors d'un accès implicite (`Rte_IRead`, `Rte_IWrite`), la RTE crée au début de l'exécution de la runnable une copie locale maintenue cohérente tout au long du temps d'exécution [SWS_Rte_06000], [SWS_Rte_03744]. Lors d'un accès explicite (`Rte_Read`, `Rte_Write`, `Rte_Send`, `Rte_Receive`), l'échange de données s'effectue directement de manière synchrone ou par le biais de files d'attente [SWS_Rte_01091], [SWS_Rte_01092]. Pour les événements avec files d'attente (`swImplPolicy = queued`), la RTE configure des files FIFO côté récepteur ; si un tel tampon déborde, l'élément est rejeté et un état d'erreur est positionné [SWS_Rte_02521], [SWS_Rte_02523].

Si le chemin de données traverse les frontières d'un calculateur (inter-ECU), la RTE transforme et sérialise les structures de données composites et appelle `Com_SendSignal` ou `Com_SendSignalGroup` afin de garantir la transmission atomique de la PDU dans le module COM [SWS_Rte_04527]. Pour les grands tableaux de données, la RTE a recours de manière alternative à `LdCom_Transmit` et verrouille, dans le cas des protocoles de transport (TP), le tampon associé jusqu'à confirmation par des callbacks [SWS_Rte_01377], [SWS_Rte_01379]. Côté récepteur, la RTE reçoit les données de manière asynchrone via des callbacks COM et en déduit des événements d'activation pour les runnables d'application [SWS_Rte_03530], [SWS_Rte_03531]. Si aucune donnée de bus n'est encore parvenue, la RTE fournit les valeurs initiales configurées [SWS_Rte_06009], [SWS_Rte_06010].

Diagramme de séquence : flux de données explicite Sender-Receiver par-delà les frontières de calculateurs avec mise en tampon et délivrance de valeurs initiales. Sources : [SWS_Rte_06010], [SWS_Rte_04527], [SWS_Rte_03530], AUTOSAR_SWS_RTE p. 148.

Pour la communication Client-Server, la RTE génère `Rte_Call` pour les appels synchrones, et des API d'appel et d'interrogation distinctes (`Rte_Call`, `Rte_Result`) pour les appels asynchrones [SWS_Rte_01102], [SWS_Rte_01111]. Dès lors que les appels ne peuvent pas être résolus directement sous forme de fonction C dans le même contexte, la RTE met en tampon les requêtes au niveau du serveur dans des files FIFO et les réponses au niveau du client dans une file d'attente de profondeur 1 [SWS_Rte_02527], [SWS_Rte_02528]. Pour les appels C/S traversant des partitions ou des calculateurs, la RTE utilise des descripteurs de transaction composés d'un ID de client et d'un compteur de séquence, afin d'associer avec précision les réponses à l'appelant d'origine [SWS_Rte_02649], [SWS_Rte_03885].

Synchronisation, réentrance et contextes de tâches

L'exécution du code de programme dans le cluster RTE a lieu au sein de tâches de l'OS ou de contextes d'ISR. La RTE distingue les runnables simples (catégorie 1 sans appels bloquants de l'OS) des runnables étendues (catégorie 2 avec points d'attente), qui sont réveillées de l'état `WaitPoint` par des événements tels que `DataReceivedEvent` ou des callbacks COM [SWS_Rte_03532], SWS_RTE p. 304. L'activation concurrente d'une même instance d'une Runnable Entity est strictement interdite, à moins que l'attribut `canBeInvokedConcurrently` ne soit explicitement défini à `TRUE` [SWS_Rte_03523]. Pour les SWC multi-instanciés, AUTOSAR s'appuie résolument sur le partage de code (code-sharing) : plusieurs instances partagent le même code exécutable, mais accèdent à des données distinctes et à la mémoire par instance (PIM) via des descripteurs spécifiques à chaque instance [SWS_Rte_02002], [SWS_Rte_03015], [SWS_Rte_02301].

Pour sécuriser les sections critiques, la RTE génère ce que l'on appelle des Exclusive Areas (`Rte_Enter`, `Rte_Exit`). Le mécanisme de synchronisation sous-jacent est configuré via le paramètre `RteExclusiveAreaImplMechanism` [SWS_Rte_03504]. Cinq stratégies définies sont alors disponibles :

• ALL_INTERRUPT_BLOCKING : masquage global de toutes les interruptions matérielles [SWS_Rte_03504].
• OS_INTERRUPT_BLOCKING : masquage sélectif des interruptions spécifiques à l'OS (catégorie 2) [SWS_Rte_03504].
• OS_RESOURCE : utilisation des ressources du système d'exploitation OSEK/AUTOSAR avec protocole de plafond de priorité [SWS_Rte_03504].
• OS_SPINLOCK : synchronisation multicœur via des spinlocks de l'OS pour la coordination entre tâches et ISR de différents cœurs [SWS_Rte_03504].
• NONE : renonciation aux verrous internes, dès lors que la cohérence des données est déjà garantie par une priorisation stricte des tâches ou par l'ordonnancement [SWS_Rte_03504].

Si des données sont transmises entre différentes partitions de protection mémoire, la RTE vérifie les paramètres de pointeur afin d'empêcher les accès mémoire non autorisés provenant de partitions non sécurisées [SWS_Rte_02752], [SWS_Rte_02753].

Cycles de vie et modes de fonctionnement typiques

Le cycle de vie du système est soumis à une division stricte en phases entre initialisation, fonctionnement régulier et arrêt contrôlé. Lors du démarrage du système, la partie SchM est d'abord initialisée : l'EcuM appelle `SchM_Start` sur chaque cœur de processeur avant que des modules BSW tels que le BswM ne soient démarrés [SWS_Rte_04546], [SWS_Rte_04548]. Ensuite, `SchM_StartTiming` active les événements BSW périodiques et les MainFunctions [SWS_Rte_04549], [SWS_Rte_04551]. Conformément à la contrainte de conception, `SchM_Start` et `SchM_StartTiming` ne doivent être appelés qu'une seule fois par cœur SWS_RTE p. 928. Ensuite, `Rte_Start` active la RTE d'application ; si l'allocation interne des ressources échoue, l'initialisation s'interrompt avec `RTE_E_LIMIT` [SWS_Rte_01261], [SWS_Rte_01262].

Les modes de fonctionnement sont représentés via des groupes de déclarations de mode (Mode-Declaration-Groups). Si un Mode Manager déclenche un changement de mode via `Rte_Switch`, celui-ci est déposé dans une file d'attente FIFO [SWS_Rte_02631], [SWS_Rte_02718], [SWS_Rte_02719]. Chaque machine de mode passe, pendant la commutation, par une séquence obligatoire en 10 étapes [SWS_Rte_02665] : tout d'abord, les désactivations de mode pour le mode cible sont rendues effectives et l'achèvement des entités en cours d'exécution est attendu (étapes 1–2). Viennent ensuite l'exécution séquentielle et la terminaison des entités exécutables (Executable Entities) OnExit (étapes 3–4), OnTransition (étapes 5–6) et OnEntry (étapes 7–8). Enfin, la désactivation du mode précédent est levée et le nouveau mode est activé (étape 9), avant que le changement de mode ne soit acquitté via `ModeSwitchedAckEvent` ou `Rte_SwitchAck` (étape 10) [SWS_Rte_02665], [SWS_Rte_02679], [SWS_Rte_02725]. Via `RteModeToScheduleTableMapping`, les modes de fonctionnement peuvent en outre être directement couplés à des tables d'ordonnancement de l'OS (Schedule Tables) [SWS_Rte_05146].

Diagramme de séquence : déroulement standardisé en 10 étapes d'un changement de mode AUTOSAR avec acquittement. Sources : [SWS_Rte_02665], [SWS_Rte_02679], EXP_ModeManagementGuide p. 16.

La désinitialisation s'effectue au début de la phase d'arrêt via `Rte_Stop`. Après cet appel, la RTE bloque l'activation, le démarrage ou la libération de nouveaux runnables sur le cœur concerné [SWS_Rte_02538]. Les données S/R entrantes ainsi que les requêtes C/S sont rejetées et ignorées lorsque la RTE est à l'état arrêté [SWS_Rte_02535], [SWS_Rte_02536].

Traitement des erreurs, surveillance de l'état et validation des données

Les états d'erreur et les statuts d'interface sont transmis de manière uniforme à l'appelant dans la RTE via le type scalaire `Std_ReturnType` [SWS_Rte_01034], SWS_RTE p. 586. La RTE fait la distinction entre les erreurs d'application (valeurs d'erreur 1–63), les erreurs d'infrastructure directes (valeurs 128–255) ainsi que les bits de statut superposés tels que la perte de données (`RTE_E_LOST_DATA = 64`) ou l'obsolescence (`RTE_E_MAX_AGE_EXCEEDED = 64`) SWS_RTE p. 586. Les valeurs de retour d'infrastructure typiques comprennent la communication arrêtée (`RTE_E_COM_STOPPED = 128`), les dépassements de délai (timeouts) de communication et de réponse (`RTE_E_TIMEOUT = 129`), les données manquantes (`RTE_E_NO_DATA = 131`) et les dépassements de capacité de ressources (`RTE_E_LIMIT = 130`) [SWS_Rte_01060], [SWS_Rte_01061], [SWS_Rte_01064]. Lorsque le contrôle de plage de valeurs est actif, la RTE signale les dépassements de plage avec `RTE_E_OUT_OF_RANGE` [SWS_Rte_03845], [SWS_Rte_03846].

Pour le traitement des signaux non plausibles ou erronés, la RTE met à disposition des mécanismes d'invalidation des données. Du côté de l'émission, `Rte_Invalidate` marque le signal avec une valeur de remplacement définie [SWS_Rte_01206], [SWS_Rte_05024]. Du côté de la réception, l'attribut `handleInvalid` pilote la stratégie de remplacement : avec `keep`, la valeur précédente est conservée et un `DataReceiveErrorEvent` est déclenché, tandis qu'avec `replace`, une substitution automatique par la valeur `initValue` a lieu [SWS_Rte_05030], [SWS_Rte_05049]. Les pannes de communication au niveau du réseau sont surveillées via `aliveTimeout` ; si le délai de surveillance expire, le module COM signale un timeout de réception à la RTE via `Rte_COMCbkRxTOut`, à la suite de quoi les composants dépendants sont informés ou des valeurs de repli sont activées [SWS_Rte_08061].