AUTOSAR Classic General & Standard Types

Le cluster de modules General & Standard Types fournit, via les en-têtes Platform_Types.h, Std_Types.h et ComStack_Types.h, la base indépendante du matériel pour tous les types de données, retours de statut et tampons de communication de la Classic Platform (AUTOSAR_SRS_BSWGeneral p. 62). Il normalise des caractéristiques architecturales fondamentales telles que les modèles de boutisme, des valeurs de retour standardisées comme Std_ReturnType et des structures de communication comme PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Comme il s’agit de pures définitions d’en-têtes sans code exécutable, le cluster ne requiert aucune configuration à l’exécution et ne possède ni tâches propres ni traitement actif des erreurs (SWS_StandardTypes p. 27).

plus ›

Le cluster de modules General & Standard Types comprend les trois en-têtes de base platform (Platform_Types.h), std (Std_Types.h) et comstack (ComStack_Types.h). En tant que pures définitions de types, ils ne contiennent aucun code exécutable et ne nécessitent aucune configuration (SWS_StandardTypes p. 27). Ils constituent le fondement à l’échelle de la plateforme pour un typage indépendant du matériel, unifient les particularités des compilateurs et du matériel, et alimentent tous les modules BSW ainsi que la RTE avec des structures de données cohérentes (AUTOSAR_SRS_BSWGeneral p. 62).

Diagramme d’architecture : architecture statique des couches et d’inclusion du cluster de modules « General & Standard Types » avec interfaces de types exportées. Sources : AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

La hiérarchie d’inclusion s’articule de manière progressive : Platform_Types.h encapsule des propriétés spécifiques à la plateforme telles que le type C99 boolean ([SWS_Platform_00027]), des pointeurs de tampon universels comme ConstVoidPtr ([SWS_Platform_91002]) ainsi que des symboles pour l’ordre des bits dans les registres CPU_BIT_ORDER ([SWS_Platform_00038]) et l’ordre des octets en mémoire CPU_BYTE_ORDER ([SWS_Platform_00039]). En se fondant là-dessus, Std_Types.h met à disposition des constantes standard universelles comme STD_ON/STD_OFF ([SWS_Std_00010]), des structures de versions de module via Std_VersionInfoType ([SWS_Std_00015]) ainsi que le système de statut fondamental Std_ReturnType avec E_OK et E_NOT_OK ([SWS_Std_00005], [SWS_Std_00006]).

Pour la pile de communication AUTOSAR, ComStack_Types.h définit l’ensemble des types d’interfaces indépendants des protocoles tels que PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) et la structure centrale de tampon PduInfoType ([SWS_COMTYPE_00008]). Dans les protocoles de transport segmentés (par exemple CanTp ou DoIP), le type de retour BufReq_ReturnType pilote, conjointement avec RetryInfoType, la réservation synchrone de tampons et la copie de données entre couches BSW (SWS_DiagnosticCommunicationManager p. 291, [SWS_COMTYPE_00012]).

Diagramme de séquence : chemin de réception segmentée et de tampon d’un protocole de transport à l’aide de ComStack_Types (PduInfoType, BufReq_ReturnType). Sources : SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Bien que le cluster ne possède ni gestion propre des erreurs ni messages DET (SWS_StandardTypes p. 27), Std_ReturnType structure la gestion des erreurs du système global : les bits 0 à 5 (0x00 à 0x3F) sont réservés aux erreurs standard et d’application, tandis que les bits 6 et 7 sont occupés exclusivement par la RTE ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Toutes les définitions de types sont spécifiées pour une utilisation réentrante dans des contextes multitâches et d’interruption (SWS_CANInterface p. 87).

plus ›

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

Le cluster de modules General & Standard Types constitue le fondement typologique et d’abstraction matérielle essentiel de l’AUTOSAR Classic Platform dans la version R20-11. Il se compose des trois modules de pures en-têtes platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) et comstack ([SWS_COMTYPE_00005]). Conformément à l’architecture BSW, ces modules ne fournissent aucun code C exécutable propre et ne font appel à aucun autre pilote BSW (SWS_StandardTypes p. 27). Leur fonction principale consiste à encapsuler les dépendances vis-à-vis du compilateur et du processeur, à fournir des types de base uniformes à l’échelle de la plateforme et à établir des structures de données standardisées pour les couches de communication.

La hiérarchie des couches suit un ordre d’inclusion strict et unidirectionnel : le fichier Platform_Types.h abstrait les propriétés de l’architecture du microcontrôleur sous-jacent (telles que l’organisation des registres et de la mémoire ainsi que les types élémentaires C99), tandis que Std_Types.h repose sur lui et définit des valeurs de retour universelles ainsi que des constantes d’état (AUTOSAR_SRS_BSWGeneral p. 62). S’appuyant là-dessus, ComStack_Types.h déclare l’ensemble des types de données indépendants des bus et des protocoles pour des réseaux tels que CAN, FlexRay, LIN et Ethernet ainsi que pour des protocoles de transport selon l’ISO 15765-2 et des protocoles de diagnostic selon l’ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Ce découplage garantit que les couches supérieures telles que l’environnement d’exécution (RTE) et les composants logiciels applicatifs (SWCs) demeurent entièrement portables (SWS_RTE p. 818).

Diagramme d’architecture : architecture statique des couches et d’inclusion du cluster de modules « General & Standard Types » avec interfaces de types exportées. Sources : AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

Interaction & voies d'interaction entre les modules

L’interaction au sein du cluster repose sur une chaîne d’inclusion statique : ComStack_Types.h inclut Std_Types.h, qui intègre lui-même Platform_Types.h (RS_BSWGeneral p. 60). Le module platform définit des grandeurs fondamentales comme boolean, qui doit obligatoirement être mappé sur le type de base C99 _Bool ([SWS_Platform_00027]), et régit son affectation stricte de valeurs via les littéraux TRUE et FALSE ([SWS_Platform_00034]). De plus, des pointeurs de tampon génériques tels que ConstVoidPtr sont spécifiés, utilisés pour des tampons de transmission immuables vers des interfaces de fonctions appelées ([SWS_Platform_91002]).

En outre, platform harmonise les boutismes matériels via des symboles de préprocesseur standardisés : pour l’ordre des bits dans les registres, CPU_BIT_ORDER est fixé à MSB_FIRST ou LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). L’ordre des octets dans la mémoire physique est contrôlé par CPU_BYTE_ORDER, en distinguant HIGH_BYTE_FIRST (gros-boutiste / Big Endian, MSB à une adresse inférieure) de LOW_BYTE_FIRST (petit-boutiste / Little Endian, LSB à une adresse inférieure) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Diagramme structurel : mappage mémoire de valeurs multi-octets scalaires en gros-boutiste (HIGH_BYTE_FIRST) vs petit-boutiste (LOW_BYTE_FIRST). Sources : AUTOSAR_CP_SWS_PlatformTypes p. 16, AUTOSAR_CP_SWS_PlatformTypes p. 15, [SWS_Platform_00050], [SWS_Platform_00051]

Au niveau d’abstraction suivant, le module std définit des symboles universels pour les états de commutation et les niveaux logiques : STD_HIGH (0x01u) et STD_LOW (0x00u) pour les niveaux de tension physique ([SWS_Std_00007]), STD_ON (0x01u) et STD_OFF (0x00u) pour les modes d’activation ([SWS_Std_00010]) ainsi que STD_ACTIVE (0x01u) et STD_IDLE (0x00u) pour les états d’exécution logique ([SWS_Std_00013]). Pour les protocoles de messages et les transformateurs, std fournit également Std_MessageTypeType avec les littéraux STD_MESSAGETYPE_REQUEST (0x00) et STD_MESSAGETYPE_RESPONSE (0x01) ([SWS_Std_91001], [SWS_Std_00017]), ainsi que le type de pointeur de fonction Std_ExtractProtocolHeaderFieldsType pour l’extraction des en-têtes de protocole ([SWS_Std_91003]).

Le module comstack utilise à son tour les types de base de platform et std pour structurer l’ensemble de l’échange de tampons et de données au sein de la pile de communication. La structure d’interface centrale est PduInfoType, qui regroupe le pointeur de données SduDataPtr (uint8*), le pointeur de métadonnées MetaDataPtr ainsi que la longueur de tampon SduLength du type PduLengthType ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). L’identification des I-PDU s’effectue via PduIdType ([SWS_COMTYPE_00005]). Pour la gestion de canaux de communication complets et de sous-réseaux, comstack définit l’identifiant de canal NetworkHandleType ([SWS_COMTYPE_00038]) ainsi que l’identifiant de sous-réseau PNCHandleType ([SWS_COMTYPE_00036]), utilisés par exemple dans le Synchronized PNC Shutdown de ComM et Nm (SWS_COMManager p. 171).

Lors des transmissions de protocoles de transport (TP) segmentées, la négociation de tampon est prise en charge via les types de retour BufReq_ReturnType et la structure RetryInfoType ([SWS_COMTYPE_00012]). Lors d’appels de copie synchrones tels que CopyTxData ou CopyRxData entre des modules tels que CanTp, PduR, DCM, DoIP ou SecOC, BUFREQ_OK signale la réussite de l’opération de copie, tandis que BUFREQ_E_BUSY indique qu’un tampon temporairement insuffisant est disponible et qu’une nouvelle tentative peut avoir lieu (SWS_DiagnosticCommunicationManager p. 291, SWS_SecureOnboardCommunication p. 76). Au moyen de RetryInfoType doté de paramètres tels que TP_CONFPENDING ou TP_DATACONF, il est garanti que les données restent dans le tampon pour d’éventuelles réémissions ou qu’elles soient libérées après confirmation (SWS_IntrusionDetectionSystemManager p. 49).

Diagramme de séquence : chemin de réception segmentée et de tampon d’un protocole de transport à l’aide de ComStack_Types (PduInfoType, BufReq_ReturnType). Sources : SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Synchronisation, réentrance et contextes de tâches

Comme les modules platform, std et comstack sont de purs fichiers d'en-tête sans fichiers objets exécutables, ils n'implémentent naturellement aucune MainFunctions cyclique et ne possèdent pas leurs propres contextes de tâche (SWS_StandardTypes p. 27). Ils définissent cependant les signatures et les conventions de types pour les fonctions appelées au-delà des limites de couches. L'ensemble des définitions de types est conçu pour pouvoir être transmis de manière totalement réentrante et sans état (SWS_CANInterface p. 87).

L'utilisation pratique des types s'effectue dans des environnements hautement asynchrones et concurrents. Les callbacks de réception de données tels que CanIf_RxIndication ou Dcm_CopyRxData, qui utilisent PduInfoType et PduIdType, peuvent être explicitement exécutés en contexte d'interruption (SWS_CANInterface p. 164, SWS_DiagnosticCommunicationManager p. 274). En revanche, les décisions de routage, les allocations de tampons ou les transmissions cycliques sont traitées dans des tâches périodiques des couches supérieures (par ex. SoAd_MainFunction) (SWS_SocketAdaptor p. 104). Comme des structures de pointeurs telles que PduInfoType peuvent être partagées entre le niveau interruption et le niveau tâche, la synchronisation thread-safe au moyen de zones exclusives (protection contre la concurrence) incombe aux modules BSW appelants et implémentants.

Cycles de vie et modes de fonctionnement typiques

Les pures définitions de types ne sont soumises à aucun cycle de vie à l'exécution et ne possèdent ni fonctions d'initialisation ni fonctions d'arrêt (SWS_StandardTypes p. 27). Elles doivent être incluses statiquement au moment de la compilation avant tous les modules effectuant des traitements. Elles constituent toutefois le cadre normatif pour la représentation et la surveillance du cycle de vie d'autres modules BSW : pour l'interrogation standardisée des versions, std spécifie la structure Std_VersionInfoType, qui contient vendorID, moduleID ainsi que les états de version logicielle (sw_major_version, sw_minor_version, sw_patch_version) ([SWS_Std_00015]).

De plus, des types tels que NetworkHandleType et PNCHandleType prennent en charge la gestion globale du réseau et des modes lors des changements de modes de fonctionnement comme le démarrage (Startup), le mode normal, l'état de veille (Sleep) et le réveil (Wakeup) ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). Ainsi, le ComM pilote des arrêts coordonnés et des changements d'état au sein du sous-réseau sur la base de ces identifiants (SWS_COMManager p. 171, SWS_NetworkManagementInterface p. 106).

Traitement des erreurs, traçage DET et codage d'état

Le cluster de modules ne fournit pas de traitement actif des erreurs propre et ne signale ni erreurs de développement au DET ni erreurs de production au DEM (SWS_StandardTypes p. 27). À la place, il normalise le format de retour à l'échelle de la plateforme : le type fondamental Std_ReturnType repose sur uint8 et sert, à travers toutes les couches, de résultat standard pour les appels synchrones ([SWS_Std_00005], BSWUMLModelModelingGuide p. 28). Par défaut, E_OK (0x00u) représente une exécution réussie et E_NOT_OK (0x01u) une erreur générique ([SWS_Std_00006]). Pour des raisons de compatibilité avec l'ISO 17356-3 (OSEK OS), E_OK est protégé contre les définitions multiples au moyen d'un contrôle de protection (STATUSTYPEDEFINED) (AUTOSAR_SRS_BSWGeneral p. 62).

L'agencement des bits de Std_ReturnType suit un partitionnement défini de manière fixe : les bits 0 à 5 (plage 0x00 à 0x3F) sont réservés aux valeurs de retour standardisées et spécifiques aux modules ou aux codes ApplicationError propres à l'application dans les opérations client/serveur ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Les extensions spécifiques aux modules sont gérées dans les modèles UML sous forme de classe avec le stéréotype «extra_literals» (BSWUMLModelModelingGuide p. 33). Les bits 6 et 7 (plage de valeurs 0x40, 0x80, 0xC0) sont strictement réservés aux états d'erreur d'infrastructure de la RTE (AUTOSAR_CP_SWS_StandardTypes p. 15). Pour les transformations de données dans la RTE, std déclare en outre la structure Std_TransformerError, constituée de errorCode ([SWS_Std_00022]) et transformerClass ([SWS_Std_00021]), ce qui permet de retracer sans discontinuité les chaînes d'erreurs lors de la sérialisation ou de la sécurisation E2E.