Platform Types (Platform_Types)

Platform_Types.h fournit les types de base dépendants de la plateforme de la Classic Platform : types entiers de largeur fixe de uint8 à sint64, types *_least optimisés, float32/float64, boolean avec TRUE/FALSE ainsi que les pointeurs de tampon VoidPtr et ConstVoidPtr. De plus, CPU_TYPE, CPU_BIT_ORDER et CPU_BYTE_ORDER caractérisent la largeur de registre et l'endianness de la cible [SWS_Platform_00046]. boolean ne doit être utilisé qu'avec TRUE et FALSE et sans opérateurs arithmétiques ou au niveau du bit [SWS_Platform_00034]. Le header ne doit pas être étendu, sous peine de perdre la conformité AUTOSAR.

plus ›

Platform_Types.h constitue la base de types dépendante de la plateforme de la Classic Platform. Le header encapsule les largeurs de mot et l'endianness de la cible derrière des noms uniformes et ne doit pas être étendu, car toute extension annule la conformité AUTOSAR [SWS_Platform_00002]. Dans la vue du modèle, les types se trouvent sous un chemin fixe tel que /AUTOSAR_Platform/ImplementationDatatypes/uint8 TPS StandardizationTemplate p. 77.

Le header met à disposition les groupes de types suivants :

• Types entiers de largeur fixe de uint8 à sint64 [SWS_Platform_00013] [SWS_Platform_00067] ; pour les types signés, seul le complément à deux s'applique [SWS_Platform_00061].
• Types optimisés *_least avec largeur minimale, par exemple pour les compteurs de boucle [SWS_Platform_00020].
• float32 et float64 selon IEEE 754-2008 [SWS_Platform_00041].
• Les pointeurs de tampon VoidPtr pour les données destinées à l'appelant et ConstVoidPtr pour les données destinées à l'appelé [SWS_Platform_91001] [SWS_Platform_91002].

Diagramme d'activité : le choix du type de plateforme approprié suit les questions relatives aux pointeurs de tampon, valeurs booléennes, nombres à virgule flottante, largeur minimale ou exacte. Sources : [SWS_Platform_91001], [SWS_Platform_00026], SWS PlatformTypes p. 17

boolean est implémenté dans R20-11 comme le type entier non signé nativement supporté le plus court, généralement 8 bits [SWS_Platform_00027]. Les versions ultérieures s'en écartent et utilisent _Bool SWS PlatformTypes p. 18. Le type doit pouvoir être pointé [SWS_Platform_00060] et ne doit être utilisé qu'avec TRUE et FALSE. Les opérateurs arithmétiques et au niveau du bit sont interdits [SWS_Platform_00034], et les redéfinitions des symboles doivent être évitées au moyen d'un contrôle conditionnel [SWS_Platform_00054].

Trois symboles doivent en outre être définis par plateforme : CPU_TYPE pour la largeur de registre [SWS_Platform_00045], CPU_BIT_ORDER avec MSB_FIRST ou LSB_FIRST [SWS_Platform_00048] [SWS_Platform_00049] et CPU_BYTE_ORDER avec HIGH_BYTE_FIRST ou LOW_BYTE_FIRST [SWS_Platform_00050] [SWS_Platform_00051]. Les noms de bits et le poids ne doivent pas être confondus, car le MSB se trouve toujours à gauche dans l'accumulateur SWS PlatformTypes p. 15. Interprétation : le module ne connaît pas d'erreurs d'exécution ; les affectations erronées n'apparaissent que lors de l'intégration ou du contrôle de conformité. Question (ouverte)

Diagramme d'activité : la largeur de registre, l'ordre des bits et l'ordre des octets de la cible sont chacun mis en correspondance avec exactement une valeur de symbole. Sources : [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00050]

plus ›

Rôle de Platform_Types.h : la base de types dépendante de la plateforme

Le module n'est pas un composant exécutable, mais un header. Tous les types et symboles spécifiés sont « Available via Platform_Types.h », par exemple uint8 [SWS_Platform_00013] ou CPU_TYPE [SWS_Platform_00064]. Le header masque les propriétés du microcontrôleur cible et du compilateur derrière des noms uniformes : largeurs de mot, ordre des bits et ordre des octets. Il fait ainsi partie de l'abstraction du microcontrôleur avec interface standardisée vers les couches supérieures requise dans SRS_BSW_00161 SRS BSWGeneral p. 88. C'est précisément à cette exigence amont que renvoient également les règles relatives à l'ordre des octets SWS PlatformTypes p. 16.

La frontière du système est strictement définie. Le header ne doit pas être étendu, car toute extension annule la conformité AUTOSAR [SWS_Platform_00002]. Les types de retour pour le succès ou l'échec d'un appel d'API se trouvent en revanche dans Std_Types.h SRS BSWGeneral p. 68. Dans la vue du modèle, les types de plateforme sont enregistrés en tant que blueprints, par exemple sous /AUTOSAR/Platform/ImplementationDatatypes_Blueprint/uint8. Ils sont implémentés sous /AUTOSAR_Platform/ImplementationDatatypes/uint8, de sorte que les fournisseurs de composants puissent les atteindre via un chemin prévisible TPS StandardizationTemplate p. 77.

Diagramme de contexte : la plateforme cible détermine le contenu de Platform_Types.h, dont les types se trouvent sous un chemin fixe dans la vue du modèle et sont utilisés par de nombreux modules BSW. Les exemples d'utilisateurs proviennent de releases ultérieures. Sources : [SWS_Platform_00038], TPS StandardizationTemplate p. 77, SWS BFXLibrary p. 19, SWS CRCLibrary p. 41, SWS BSWMulticoreLibrary p. 16, SWS KeyManager p. 111, SWS CANStateManager p. 83

Types entiers et à virgule flottante à largeur garantie

Le cœur du module est constitué de types non signés et signés de largeur fixe de 8 à 64 bits ainsi que de deux types à virgule flottante. De manière normative, les exigences fixent la largeur et la plage de valeurs, par exemple « 32 bit unsigned » pour uint32 [SWS_Platform_00015]. Les typedefs C du catalogue d'API, par exemple typedef unsigned long uint32;, sont probablement à interpréter comme une mise en correspondance typique pouvant varier selon le compilateur (interprétation). Question Q-d0ca377fc1abd98a (ouverte)

Type	Largeur / format	Plage de valeurs	Référence
uint8	8 bits, non signé	0..255	[SWS_Platform_00013]
uint16	16 bits, non signé	0..65535	[SWS_Platform_00014]
uint32	32 bits, non signé	0..4294967295	[SWS_Platform_00015]
uint64	64 bits, non signé	0..18446744073709551615	[SWS_Platform_00066]
sint8	8 bits, signé	-128..+127	[SWS_Platform_00016]
sint16	16 bits, signé	-32768..+32767	[SWS_Platform_00017]
sint32	32 bits, signé	-2147483648..+2147483647	[SWS_Platform_00018]
sint64	64 bits, signé	-9223372036854775808..9223372036854775807	[SWS_Platform_00067]
float32	IEEE 754-2008 binary32	-3.4028235e+38..+3.4028235e+38	[SWS_Platform_00041]
float64	IEEE 754-2008 binary64	±1.7976931348623157e+308	[SWS_Platform_00042]

Pour les types signés, AUTOSAR prend en charge exclusivement l'arithmétique en complément à deux pour le compilateur et la cible. Il en résulte les plages de valeurs asymétriques du tableau [SWS_Platform_00061]. D'autres spécifications présupposent systématiquement ces types. La bibliothèque CRC définit par exemple uint8 Crc_CalculateCRC8(const uint8*, uint32, uint8, boolean) SWS CRCLibrary p. 41. COM doit prendre en charge la conversion d'endianness pour uint16 à float64 RS COM p. 14. Ces deux passages proviennent de releases ultérieures et ne font qu'illustrer l'utilisation.

Types optimisés *_least pour les compteurs et les états

Outre les types à largeur exacte, le module définit six types optimisés. Ils ne garantissent qu'une largeur minimale et sont dérivés de uint ou sint :

• uint8_least [SWS_Platform_00020]
• uint16_least [SWS_Platform_00021]
• uint32_least [SWS_Platform_00022]
• sint8_least [SWS_Platform_00023]
• sint16_least [SWS_Platform_00024]
• sint32_least [SWS_Platform_00025]

L'implémentation peut donc choisir une représentation plus large. Les signatures du catalogue mappent les six types sur unsigned int ou signed int [SWS_Platform_00020].

Comme exemples d'utilisation, la spécification mentionne les compteurs de boucle (au maximum 124 itérations ⇒ uint8_least) et les arguments de switch (17 états ⇒ uint8_least). Pour les détails, elle renvoie au chapitre « AUTOSAR Integer Data Types » des exigences générales BSW SWS PlatformTypes p. 17.

Utiliser boolean, TRUE et FALSE conformément aux règles

boolean a pour plage de valeurs FALSE = 0 et TRUE = 1 et ne doit être utilisé qu'avec ces définitions [SWS_Platform_00026]. Pour R20-11 : boolean est implémenté sous forme d'un type entier non signé avec la longueur de bit la plus courte supportée nativement par la plateforme, généralement 8 bits [SWS_Platform_00027]. Un passage documentaire issu de R24-11/R25-11 formule le même identifiant différemment : boolean y est implémenté via le type C99 _Bool, et AUTOSAR ne fixe plus la taille exacte SWS PlatformTypes p. 18. Pour R20-11, cette version ultérieure n'est pas normative.

boolean doit en outre être mappé sur un type vers lequel des pointeurs peuvent pointer, afin que les paramètres puissent être transmis par API. Les types de bits efficaces de certains matériels ne peuvent pas être pointés et sont donc exclus [SWS_Platform_00060]. Trois règles s'appliquent aux symboles TRUE et FALSE :

• Ils sont définis comme 1 et 0 avec une protection #ifndef [SWS_Platform_00056].
• Si le compilateur fournit déjà les symboles, une redéfinition doit être évitée au moyen d'un contrôle conditionnel [SWS_Platform_00054].
• Ils ne doivent être utilisés qu'avec boolean [SWS_Platform_00055].

Lors des affectations à des variables boolean, les opérateurs arithmétiques et au niveau du bit sont interdits : +, ++, -, --, *, /, %, <<, >>, ~ et &. Seule est autorisée l'affectation de TRUE ou FALSE ainsi que des résultats de relations, d'opérations logiques et de tests d'(in)égalité. Les comparaisons ne se font qu'avec == ou != par rapport à TRUE/FALSE ou via if (var) ou if (!var) [SWS_Platform_00034]. Les modules consommateurs suivent ce modèle. Ainsi, Bfx_GetBit renvoie expressément le résultat d'un test de bit sous forme de TRUE ou FALSE SWS BFXLibrary p. 19.

Diagramme d'activité : pour les variables boolean, seules les formes d'affectation et de comparaison listées sont autorisées, pas les opérateurs arithmétiques et de bits. Sources : [SWS_Platform_00034], [SWS_Platform_00026]

Pointeurs de tampon non typés : VoidPtr et ConstVoidPtr

Les deux types de pointeurs se distinguent par la direction du flux de données :

• VoidPtr est un void* pour les tampons contenant des données renvoyées à l'appelant [SWS_Platform_91001].
• ConstVoidPtr est un const void* pour les tampons transmis à l'appelé [SWS_Platform_91002].

La direction du flux de données est ainsi déjà contenue dans le nom du type SWS PlatformTypes p. 27 SWS PlatformTypes p. 28.

Le Key Manager montre comment cela se présente dans les interfaces. KeyMServiceCertificateByCertId transmet RequestData en tant que ConstVoidPtr conjointement avec une longueur de type uint32. La réponse est reçue dans ResponseData de type VoidPtr ; ResponseDataLength (INOUT) indique alors la longueur de tampon disponible SWS KeyManager p. 111. Autres exemples :

• KeyM_CertDataType référence des données de certificat dans la zone de données locale de l'appelant via un VoidPtr SWS KeyManager p. 97.
• Le Crypto Service Manager transmet le seed sous forme de ConstVoidPtr SWS CryptoServiceManager p. 124.

Dans les trois exemples, la longueur est transmise en tant que paramètre uint32 propre ou en tant qu'élément de structure propre, car un pointeur non typé ne transporte aucune information de longueur.

Diagramme de séquence : lors d'un appel de service, le ConstVoidPtr transporte la requête vers l'appelé, le VoidPtr reçoit la réponse pour l'appelant. Sources : SWS KeyManager p. 111, [SWS_Platform_91001], [SWS_Platform_91002]

Diagramme d'activité : le choix du type suit les questions relatives aux pointeurs de tampon, valeurs booléennes, nombres à virgule flottante, largeur minimale ou exacte. Sources : [SWS_Platform_91001], [SWS_Platform_91002], [SWS_Platform_00026], [SWS_Platform_00041], [SWS_Platform_00020], SWS PlatformTypes p. 17

Identification de plateforme : CPU_TYPE, CPU_BIT_ORDER, CPU_BYTE_ORDER

Pour chaque plateforme, trois propriétés doivent être définies dans le header :

• Largeur de registre via CPU_TYPE [SWS_Platform_00044], avec l'une des valeurs CPU_TYPE_8, CPU_TYPE_16, CPU_TYPE_32 ou CPU_TYPE_64 [SWS_Platform_00045] [SWS_Platform_00064].
• Ordre des bits au niveau du registre via CPU_BIT_ORDER [SWS_Platform_00043].
• Ordre des octets en mémoire via CPU_BYTE_ORDER [SWS_Platform_00046].

Les deux symboles d'ordre sont des #defines qui portent exactement l'une des valeurs autorisées [SWS_Platform_00038] [SWS_Platform_00039].

Diagramme d'activité : lors du portage sur une cible, la largeur de registre, l'ordre des bits et l'ordre des octets sont déterminés et mis en correspondance chacun avec exactement une valeur de symbole. Sources : [SWS_Platform_00045], [SWS_Platform_00048], [SWS_Platform_00049], [SWS_Platform_00050], [SWS_Platform_00051]

Pour l'ordre des bits big-endian, CPU_BIT_ORDER = MSB_FIRST s'applique ; pour little-endian, LSB_FIRST s'applique [SWS_Platform_00048] [SWS_Platform_00049]. Les noms de bits et le poids doivent être strictement séparés. Le MSB se trouve toujours tout à gauche dans l'accumulateur, indépendamment du type de CPU. Sur les architectures Motorola (Big Endian Bit Order), Bit0 désigne le bit de poids le plus fort, sur toutes les autres le bit de poids le plus faible SWS PlatformTypes p. 15 SWS PlatformTypes Fig. 7.1 p. 14.

Diagramme structurel selon la fig. 7.1 : le poids des bits de registre est fixe, seule la numérotation de Bit0 dépend de CPU_BIT_ORDER. Sources : SWS PlatformTypes Fig. 7.1 p. 14, SWS PlatformTypes p. 15

Pour l'ordre des octets big-endian, CPU_BYTE_ORDER = HIGH_BYTE_FIRST s'applique : l'octet de poids le plus fort d'une valeur de 16 bits se trouve à l'adresse n, le plus faible à n+1. Pour little-endian, LOW_BYTE_FIRST s'applique avec une disposition inversée [SWS_Platform_00050] [SWS_Platform_00051]. Les désignations Byte0 et Byte1 ne servent qu'à l'illustration et peuvent différer dans la documentation de référence d'un fabricant SWS PlatformTypes p. 16.

Diagramme structurel selon la fig. 7.2/7.3 : le même uint16 est mappé sur les adresses n et n+1 avec des octets inversés selon CPU_BYTE_ORDER. Sources : SWS PlatformTypes Fig. 7.2 p. 16, SWS PlatformTypes Fig. 7.3 p. 15, [SWS_Platform_00039]

D'autres spécifications justifient pourquoi ces indications sont nécessaires. La représentation en mémoire des données dépend fortement de l'architecture du processeur et des paramètres du compilateur. C'est pourquoi SOME/IP exige un algorithme de sérialisation convertissant vers une représentation réseau commune RS SOMEIPProtocol p. 21. De telles conversions s'appuient probablement dans les implémentations sur CPU_BYTE_ORDER ; la charge utile ne l'établit toutefois pas expressément. Question Q-87e212e9eb2a2047 (ouverte)

Comportement en cas d'erreur

Interprétation : étant donné que Platform_Types.h ne fournit que des types et des symboles, le module ne connaît aucune erreur d'exécution ni aucun code d'erreur. Question Q-e504d08b84d7ff70 (ouverte) Les anomalies se manifestent lors de la compilation, de l'intégration ou du test de conformité. Les exigences indiquent les causes typiques [SWS_Platform_00002] :

• Les extensions de l'en-tête ne sont pas autorisées ; toute extension annule la conformité [SWS_Platform_00002].
• Les définitions en double de TRUE/FALSE en cas de prise en charge existante par le compilateur doivent être évitées par une vérification conditionnelle [SWS_Platform_00054] [SWS_Platform_00056].
• Des symboles d'ordonnancement mal assignés violent [SWS_Platform_00048] à [SWS_Platform_00051]. Le mélange des noms de bits issus de la documentation du fabricant avec le poids binaire SWS PlatformTypes p. 15 est particulièrement sujet aux erreurs.
• Un boolean ne pouvant pas être pointé viole [SWS_Platform_00060], car les paramètres ne peuvent alors pas être transmis par l'API.
• Les opérations arithmétiques ou bit à bit sur boolean sont interdites, de même que les formes de comparaison autres que celles énumérées [SWS_Platform_00034].
• Le code qui présuppose le complément à un ou des plages de valeurs symétriques n'est pas couvert, car seul le complément à deux est pris en charge [SWS_Platform_00061].
• Lors d'un changement de version, il convient de respecter la consigne pour boolean : R20-11 [SWS_Platform_00027] et les versions ultérieures SWS PlatformTypes p. 18 diffèrent. Le code qui suppose une taille fixe de boolean doit donc être vérifié avant la transition.

Preuves détaillées supplémentaires

• Types entiers de largeur fixe : [SWS_Platform_00013] à [SWS_Platform_00018] ainsi que [SWS_Platform_00066] et [SWS_Platform_00067] fixent la largeur et la plage de valeurs.
• Types optimisés : [SWS_Platform_00020] à [SWS_Platform_00025], avec des exemples d'utilisation dans SWS PlatformTypes p. 17.
• Types à virgule flottante selon IEEE 754-2008 : [SWS_Platform_00041], [SWS_Platform_00042].
• Valeurs booléennes : [SWS_Platform_00026], [SWS_Platform_00027], [SWS_Platform_00034], [SWS_Platform_00055], [SWS_Platform_00056], [SWS_Platform_00060].
• Pointeurs de tampon : [SWS_Platform_91001], [SWS_Platform_91002], avec application dans SWS KeyManager p. 111.
• Symboles de plateforme : [SWS_Platform_00043] à [SWS_Platform_00046], [SWS_Platform_00064], [SWS_Platform_00038], [SWS_Platform_00039]. L'affectation de l'endianness est régie par [SWS_Platform_00048] à [SWS_Platform_00051], illustrée dans SWS PlatformTypes p. 16.
• Règles générales : [SWS_Platform_00002] (pas d'extensions), [SWS_Platform_00054] (pas de redéfinitions), [SWS_Platform_00061] (complément à deux). [SWS_Platform_00063] déclare un groupe d'exigences comme non applicable ; le texte abrégé n'indique pas lesquelles sont visées.