Standard Types (Std_Types)

Le module std fournit via Std_Types.h des types et constantes uniformes à l'échelle de la plateforme, mais ne contient ni code ni configuration. L'élément central est Std_ReturnType (uint8) avec E_OK et E_NOT_OK. Les modules ne peuvent définir leurs propres valeurs que dans la plage 0x02–0x3F avec un préfixe de module, car le bit 7 et le bit 8 sont réservés à la RTE [SWS_Std_00011]. De plus, le module fournit les constantes STD_HIGH/STD_LOW, STD_ON/STD_OFF et STD_ACTIVE/STD_IDLE, le type Std_VersionInfoType pour l'interrogation de version ainsi que des types de transformeur et de message pour la communication client-serveur. Dans R20-11, l'en-tête inclut également Compiler.h SRS BSWGeneral p. 62.

plus ›

Le module std est un en-tête de types pur. Via Std_Types.h, il met à disposition des types et des symboles, mais aucune fonction [SWS_Std_00005]. Dans R20-11, l'en-tête inclut Platform_Types.h et Compiler.h et définit Std_ReturnType ainsi que les valeurs E_OK/E_NOT_OK et les constantes STD_*. Tout module qui utilise ces types l'inclut SRS BSWGeneral p. 62. Selon une version ultérieure de la spécification, il n'y a ni configuration ni gestion d'erreurs propre ; cela devrait également s'appliquer à R20-11 (interprétation) SWS StandardTypes p. 27. Question (ouverte)

Diagramme de contexte : Std_Types.h comme base de types commune pour les modules BSW, les CDD, la RTE et les transformeurs. Sources : SRS BSWGeneral p. 62, CDD Guideline p. 14

Le cœur du module est Std_ReturnType (uint8) avec les valeurs E_OK (0) et E_NOT_OK (1). La plage 0x02–0x3F est réservée aux erreurs spécifiques aux modules avec préfixe de module ; les bits 7 et 8 sont définis par la spécification de la RTE [SWS_Std_00011]. Des exemples de telles extensions sont CAN_BUSY et Csm_ReturnType BSWUML Guide p. 29. E_OK est protégé via STATUSTYPEDEFINED en raison d'OSEK [SWS_Std_00006].

Diagramme de contexte (structure des types) : valeurs standard, plage spécifique aux modules et bits réservés à la RTE de Std_ReturnType. Sources : [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15

S'y ajoutent trois paires de constantes valant chacune 0x01u/0x00u : STD_HIGH/STD_LOW pour les niveaux physiques, STD_ON/STD_OFF comme commutateurs et STD_ACTIVE/STD_IDLE pour les états logiques ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]). Std_VersionInfoType transporte l'identifiant fournisseur (Vendor ID), l'identifiant de module et la version logicielle pour la fonction synchrone et réentrante <Ma>_GetVersionInfo [SWS_Std_00015].

Pour la transformation des données, std définit deux types pour les erreurs de transformeur : Std_TransformerError, une structure composée d'un code d'erreur et d'une classe de transformeur, et Std_TransformerClass [SWS_Std_00021]. La RTE transmet cette erreur via le paramètre optionnel transformerError SWS RTE p. 731. Pour la communication client-serveur, Std_MessageTypeType et Std_MessageResultType encodent requête/réponse et OK/ERROR. Un pointeur de fonction de type Std_ExtractProtocolHeaderFieldsType lit ces deux valeurs à partir d'un en-tête de transformeur [SWS_Std_91003]. Les types Forward sont encore à l'état de projet dans R20-11 [SWS_Std_00029].

plus ›

Rôle et frontière système : un en-tête de types pur sans comportement à l'exécution

Le module std (Standard Types) ne contient aucune fonction. Il fournit exclusivement des types et des symboles qui sont disponibles via Std_Types.h. Chaque exigence du module mentionne cet en-tête comme source de référence, par exemple [SWS_Std_00005] et [SWS_Std_00015]. La spécification stipule expressément : l'en-tête ne fournit aucun code et ne requiert aucun autre module BSW, il ne possède aucune configuration ni gestion d'erreurs propre SWS StandardTypes p. 27. Ces formulations sont issues de la version à partir de R23-11. La même chose devrait s'appliquer à R20-11, car les exigences de R20-11 ne contiennent que des définitions de types et de symboles (interprétation). Question Q-8e4c66ae80752d38 (ouverte)

L'objectif est d'assurer un accès uniforme et à l'échelle de la plateforme aux types standards. L'exigence BSW relative à l'en-tête de types standard exige par conséquent : tout module qui utilise des types d'entiers AUTOSAR ou le type de retour standard inclut Std_Types.h SRS BSWGeneral p. 62. Le type de retour Std_ReturnType est expressément partagé entre la RTE et les modules BSW [SWS_Std_00005]. Dans la méthodologie, les types standards sont en outre décrits sous la forme d'un artefact ARXML « AUTOSAR Standard Types » Methodology p. 400.

Diagramme de contexte : Std_Types.h inclut les en-têtes de plateforme et de compilateur et est utilisé par les modules BSW, les CDD, la RTE et les transformeurs comme base de types commune. Sources : SRS BSWGeneral p. 62, CDD Guideline p. 14, [SWS_Std_00005], [SWS_Std_00021]

Structure de Std_Types.h et intégration dans l'arborescence des en-têtes

Pour R20-11, l'exigence BSW définit ce que Std_Types.h doit fournir SRS BSWGeneral p. 62 :

• inclure l'en-tête de types spécifique à la plateforme Platform_Types.h,
• inclure l'en-tête spécifique au compilateur Compiler.h,
• définir Std_ReturnType,
• définir les valeurs pour E_OK, E_NOT_OK, STD_ON, STD_OFF, STD_HIGH, STD_LOW, STD_ACTIVE et STD_IDLE.

Dans la version ultérieure de cette même exigence, l'inclusion de Compiler.h est absente RS BSWGeneral p. 60. Cela concorde avec l'historique des modifications : dans R22-11, l'abstraction de compilateur obsolète a été retirée d'une exigence Std, et NULL_PTR n'a été ajouté qu'avec R21-11 SWS StandardTypes p. 1. Pour R20-11, Compiler.h fait donc bien partie de la chaîne d'inclusion, contrairement à un NULL_PTR issu de Std_Types.h.

Une particularité concerne E_OK. Le symbole est déjà défini dans OSEK et doit donc être partagé. [SWS_Std_00006] prescrit une protection via STATUSTYPEDEFINED : à l'intérieur de cette protection, E_OK (0x00u) et StatusType sont définis, tandis que E_NOT_OK (0x01u) se trouve à l'extérieur. L'exigence BSW contient la même note d'implémentation avec une référence à l'ISO 17356-3 SRS BSWGeneral p. 62. Le schéma sur la structure d'en-tête des CDD montre comment un Complex Device Driver intègre l'en-tête dans son arborescence d'inclusions CDD Guideline p. 14.

Std_ReturnType : Plage de valeurs, disposition des bits et extensions spécifiques aux modules

Std_ReturnType est dérivé de uint8. Les valeurs standard sont E_OK (0) et E_NOT_OK (1) ; la plage 0x02–0x3F est disponible pour les erreurs spécifiques à l'utilisateur [SWS_Std_00005]. [SWS_Std_00011] précise cette règle :

• Le type est normalement utilisé avec E_OK ou E_NOT_OK.
• Si ces valeurs ne suffisent pas, des valeurs personnalisées peuvent être définies dans les six bits de poids faible, nommées avec le préfixe du module.
• Les bits 7 et 8 sont réservés. Ils sont fixés, tout comme l'agencement global, par la spécification de la RTE.

Le schéma relatif à l'agencement illustre précisément cette répartition SWS StandardTypes p. 15.

La spécification de la RTE décrit Std_ReturnType comme le type des valeurs d'état et d'erreur des fonctions d'API ; la valeur 0 est réservée pour « aucune erreur survenue » SWS RTE p. 675. D'après le guide de modélisation BSW, il s'agit du seul type de retour autorisé dans les opérations client-serveur des interfaces de service BSWUML Guide p. 28. Un exemple d'extension spécifique à un module est CAN_BUSY (0x02) du pilote CAN. Can_Write() renvoie cette valeur lorsqu'aucun objet d'émission n'est disponible SWS CANDriver p. 54.

Diagramme de contexte (structure des types) : Std_ReturnType est divisé en valeurs standard, une plage spécifique au module 0x02–0x3F et deux bits réservés par la RTE ; les extensions de module telles que Csm_ReturnType ou CAN_BUSY n'occupent que la plage libre. Sources : [SWS_Std_00005], [SWS_Std_00011], SWS StandardTypes p. 15, BSWUML Guide p. 29, SWS CANDriver p. 54

Dans le modèle UML de la BSW, une telle extension est modélisée sous forme de classe <Ma>_ReturnType avec le stéréotype «extra_literals». Ses valeurs portent le préfixe du module et se situent dans la plage 0x02–0x3f BSWUML Guide p. 28. L'exemple Csm_ReturnType avec CSM_E_BUSY, CSM_E_SMALL_BUFFER et CSM_E_ENTROPY_EXHAUSTION illustre ce modèle BSWUML Guide p. 29. Si plusieurs modules d'une même pile nécessitent la même extension, celle-ci n'a pas besoin d'être définie séparément pour chaque module BSWUML Guide p. 33. La version R23-11 prévoit à cet effet une classe générique avec «generic_type», dont dérivent les extensions spécifiques aux modules TR BSWUML Guide p. 37.

Diagramme d'activité : décision indiquant si et comment un module étend Std_ReturnType avec ses propres valeurs. Sources : [SWS_Std_00011], BSWUML Guide p. 28, BSWUML Guide p. 33, TR BSWUML Guide p. 37

Constantes symboliques pour niveaux, commutateurs et états

Outre les valeurs de retour, Std_Types.h définit trois paires de constantes. Toutes trois utilisent les valeurs numériques 0x01u et 0x00u, mais sont commentées différemment ([SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013]) :

Paire	Valeurs	Signification selon la définition
STD_HIGH / STD_LOW	0x01u / 0x00u	état physique 5 V ou 3,3 V / 0 V
STD_ON / STD_OFF	0x01u / 0x00u	Marche/Arrêt, sans autre commentaire
STD_ACTIVE / STD_IDLE	0x01u / 0x00u	état logique actif / idle

Un utilisateur typique de STD_HIGH/STD_LOW est le pilote DIO : son service de lecture renvoie exactement l'un de ces deux niveaux SWS DIO p. 37. STD_ON/STD_OFF servent de commutateurs de précompilation. Un exemple est EEP_21_LDEXT_VERSION_INFO_API STD_ON dans la spécification générale du BSW SWS BSWGeneral p. 76, un autre correspond aux commutateurs d'API optionnels du pilote GPT SWS GPT p. 48.

Interrogation de la version via Std_VersionInfoType

Std_VersionInfoType est une structure comportant les éléments suivants : vendorID et moduleID (chacun de type uint16) ainsi que sw_major_version, sw_minor_version et sw_patch_version (chacun de type uint8). Elle permet, via <Module name>_GetVersionInfo(), d'interroger la version d'un module BSW [SWS_Std_00015]. La spécification générale du BSW définit pour cette fonction SWS BSWGeneral p. 76 :

• Elle fonctionne de manière synchrone et est réentrante.
• Elle possède exactement un paramètre de ce type.
• Sa disponibilité est configurée par module au moment de la précompilation via <Ma>VersionInfoApi.

La règle de nommage GetVersionInfo cite l'exigence BSW avec l'exemple Eep_21_LDExt_GetVersionInfo SRS BSWGeneral p. 60.

Des implémentations concrètes existent dans de nombreux modules. Lorsque la détection des erreurs de développement est activée, Can_GetVersionInfo rejette un pointeur nul avec CAN_E_PARAM_POINTER SWS CANDriver p. 57. Adc_GetVersionInfo vérifie de manière correspondante la présence de ADC_E_PARAM_POINTER SWS ADCDriver p. 80. Le gestionnaire NVRAM présente l'appel sous la forme d'un échange synchrone simple entre l'utilisateur et le module SWS NvM p. 158.

Diagramme de séquence : un utilisateur interroge la version d'un module de manière synchrone ; en cas de pointeur nul et si la détection des erreurs de développement est active, le module signale une erreur, sinon il renseigne Std_VersionInfoType. Sources : [SWS_Std_00015], SWS BSWGeneral p. 76, SWS CANDriver p. 57, SWS NvM p. 158

Types de transformeurs et de messages pour la transformation de données

Pour les chaînes de transformeurs, std met à disposition plusieurs types. Dans R20-11, Std_TransformerError est une structure composée de errorCode (uint8) et de transformerClass de type Std_TransformerClass [SWS_Std_00021]. Std_TransformerClass est dérivé de uint8 et comporte cinq valeurs [SWS_Std_00024] : STD_TRANSFORMER_UNSPECIFIED (0x00), STD_TRANSFORMER_SERIALIZER (0x01), STD_TRANSFORMER_SAFETY (0x02), STD_TRANSFORMER_SECURITY (0x03) et STD_TRANSFORMER_CUSTOM (0xFF).

La signature courte dans le répertoire d'API répertorie Std_TransformerError sous le nom typedef uint8. La définition de structure de l'exigence fait toutefois foi. Des versions ultérieures typent errorCode sous la forme d'un type propre Std_TransformerErrorCode, dont la signification est définie par chaîne de transformeurs SWS StandardTypes p. 17.

La RTE transmet ce type comme paramètre OUT optionnel transformerError à ses API, par exemple pour Rte_Call SWS RTE p. 731, Rte_Read SWS RTE p. 720 et Rte_Result SWS RTE p. 750. Les interfaces de plug-in le décrivent comme l'erreur survenue lors de l'exécution de la chaîne de transformeurs SWS RTE p. 969.

Std_TransformerForward et Std_TransformerForwardCode sont marqués comme brouillon (draft) dans R20-11. Le code de transfert (forward) connaît E_OK, E_SAFETY_INVALID_REP, E_SAFETY_INVALID_SEQ et E_SAFETY_INVALID_CRC ([SWS_Std_00027], [SWS_Std_00029]). Dans les versions ultérieures, Rte_Send accepte un forwardedCode optionnel de ce type SWS RTE p. 704. Il sert probablement à reproduire à nouveau lors du transfert les erreurs de sécurité (safety) reçues, comme le décrivent les fonctions de transfert E2E SWS E2ELibrary p. 107 (interprétation). Selon l'historique des modifications, la structure Std_TransformerForward a été supprimée dans R22-11 SWS StandardTypes p. 1. Question Q-f0d374b3b793c868 (ouverte)

Diagramme de séquence : une erreur de transformeur parvient au SW-C, en plus du Std_ReturnType, sous forme de Std_TransformerError avec code d'erreur et classe de transformeur. Sources : [SWS_Std_00021], [SWS_Std_00024], SWS RTE p. 731, SwCluster Guideline p. 245, SWS RTE p. 774

Pour la communication client-serveur, il existe deux types de codage pour lesquels 0x02–0x3F sont respectivement réservés à des valeurs futures :

• Std_MessageTypeType distingue la requête (STD_MESSAGETYPE_REQUEST, 0x00) et la réponse (STD_MESSAGETYPE_RESPONSE, 0x01) ([SWS_Std_91001], [SWS_Std_00017]).
• Std_MessageResultType code le résultat d'une réponse : STD_MESSAGERESULT_OK (0x00) ou STD_MESSAGERESULT_ERROR (0x01) ([SWS_Std_91002], [SWS_Std_00019]).

Le type de pointeur de fonction Std_ExtractProtocolHeaderFieldsType décrit une fonction synchrone et réentrante. Elle extrait les deux valeurs de l'en-tête de protocole d'un transformeur dans un tampon et fournit un Std_ReturnType [SWS_Std_91003]. Les transformeurs reçoivent optionnellement un tel pointeur comme argument de leur fonction inverse ASWS TransformerGeneral p. 40. Avec SomeIpXf_ExtractProtocolHeaderFields, le transformeur SOME/IP fournit une implémentation appropriée SWS SOMEIPTransformer p. 61. Les profils E2E 4m, 7m, 8m et 44m évaluent les deux valeurs dans leurs fonctions de vérification SWS E2ELibrary p. 108.

Diagramme de séquence : pour les profils PXXm, le transformeur E2E extrait le type et le résultat du message via le pointeur de fonction transmis et ne poursuit la vérification qu'en cas de E_OK. Sources : [SWS_Std_91003], ASWS TransformerGeneral p. 40, SWS E2ETransformer p. 45, SWS SOMEIPTransformer p. 61, SWS E2ELibrary p. 108

Comportement en cas d'erreur

Le module lui-même ne détecte ni ne signale aucune erreur. La version à partir de R23-11 constate que les types standard ne prévoient aucun traitement d'erreur et ne prennent en charge aucun événement de sécurité SWS StandardTypes p. 27 ; la même chose devrait s'appliquer à R20-11 (interprétation). Question (ouverte) Le comportement en cas d'erreur ne naît donc que dans les modules qui utilisent ces types. Le signal de base est E_NOT_OK [SWS_Std_00006] ; sa signification concrète est définie par chaque API. Pour Adc_ReadGroup, il signifie « aucun résultat disponible ou erreur de développement » SWS ADCDriver p. 61, pour CanIf_Transmit « demande d'émission non acceptée » SWS CANInterface p. 87.

Des profils d'erreur plus précis sont signalés via des valeurs spécifiques aux modules dans la plage 0x02–0x3F [SWS_Std_00011], par exemple CAN_BUSY SWS CANDriver p. 54. Les appelants doivent donc s'attendre à ce qu'un Std_ReturnType prenne plus de deux valeurs. Un cas particulier concerne les rappels routés en tant que services AUTOSAR via la RTE : bien que l'appelant puisse supposer E_OK, de tels rappels peuvent échouer, par exemple dans des systèmes partitionnés SWS BSWGeneral p. 69.

Dans les chaînes de transformeurs, une erreur est signalée en plus de la valeur de retour via Std_TransformerError avec code d'erreur et classe de transformeur [SWS_Std_00021]. La RTE ne génère le paramètre optionnel transformerError que si le traitement d'erreurs transformerErrorHandling est configuré pour le port SWS RTE p. 774. Si l'extraction des champs d'en-tête échoue, SomeIpXf_ExtractProtocolHeaderFields renvoie E_NOT_OK, par exemple en cas de version de protocole incorrecte ou de tampon trop court SWS SOMEIPTransformer p. 61. La logique de transformateur E2E ne poursuit la vérification qu'en cas de E_OK SWS E2ETransformer p. 45.

Preuves détaillées supplémentaires

• [SWS_Std_00005], [SWS_Std_00006], [SWS_Std_00011] : type de retour, valeurs standard avec protection OSEK, disposition des bits et règle d'extension.
• [SWS_Std_00007], [SWS_Std_00010], [SWS_Std_00013] : les trois paires de constantes pour niveaux physiques, commutateurs et états logiques.
• [SWS_Std_00015] conjointement avec SWS BSWGeneral p. 76 : structure de version et règles pour GetVersionInfo.
• [SWS_Std_00021], [SWS_Std_00024], [SWS_Std_00027], [SWS_Std_00029] : types d'erreur de transformeur et de transfert (forward) ; les deux derniers sont draft.
• [SWS_Std_91001], [SWS_Std_91002], [SWS_Std_91003], [SWS_Std_00017], [SWS_Std_00019] : types de messages et extraction d'en-tête pour la communication C/S.
• SRS BSWGeneral p. 62 : contenu et chaîne d'inclusion de Std_Types.h dans R20-11.
• SWS StandardTypes p. 27 et SWS StandardTypes p. 1 : absence de configuration et de traitement d'erreurs ainsi qu'historique des modifications (versions ultérieures).