Communication Stack Types (ComStack_Types)

Le module comstack fournit via ComStack_Types.h les types communs avec lesquels toutes les couches de la pile de communication Classic adressent et échangent des PDU : PduIdType en tant que handle, PduLengthType en tant que longueur et PduInfoType avec pointeur de données utiles, pointeur de métadonnées et longueur ([SWS_COMTYPE_00011]). Les protocoles de transport copient les PDU volumineuses par segments via StartOfReception, CopyRxData et CopyTxData. Ils signalent l'état du tampon avec BufReq_ReturnType, tandis que RetryInfoType contrôle l'acquittement et la répétition ([SWS_COMTYPE_00012]). Principale contrainte : la largeur de PduIdType et PduLengthType dépend de la configuration EcuC et est générée.

plus ›

Le module comstack définit l'ensemble de types communs de la pile de communication Classic. En font partie PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType ainsi que des identifiants de canaux et de sous-réseaux, tous disponibles via ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Les interfaces de bus, les protocoles de transport, le PduR, les modules de diagnostic et la RTE utilisent les mêmes types ; la RTE les importe expressément (SWS RTE p. 833).

Diagramme de contexte : un ensemble de types pour toutes les couches, dimensionné via la configuration EcuC. Sources : [SWS_COMTYPE_00005], SWS RTE p. 833

Les handles et les longueurs dépendent de la configuration. PduIdType est uint8 ou uint16, PduLengthType est uint8, uint16 ou uint32 ; tous deux sont générés à partir de la configuration EcuC ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Chaque module fournissant un service choisit lui-même ses ID de handle. Ils ne doivent être uniques que par API ; le PduR les traduit le long du chemin de routage (ECU Configuration p. 156).

PduInfoType regroupe le pointeur de données utiles, le pointeur de métadonnées et la longueur. La structure prend ainsi en charge les ordres d'émission, les indications de réception et Trigger Transmit. Les PDU volumineuses sont copiées morceau par morceau : le protocole de transport appelle à plusieurs reprises CopyTxData de la couche supérieure via le PduR (SWS PduR p. 109). La réception commence par StartOfReception et se poursuit avec CopyRxData.

Diagramme de séquence : le protocole de transport extrait les données d'émission du DCM dans une boucle ; l'acquittement suit à la fin. Sources : SWS PduR p. 109

BufReq_ReturnType signale les erreurs et les congestions ([SWS_COMTYPE_00012]) :

• BUFREQ_E_BUSY : temporairement aucun tampon ou trop peu de données ; l'appel peut être répété.
• BUFREQ_E_OVFL : aucun tampon de la longueur requise.
• BUFREQ_E_NOT_OK : abandon.

L'acquittement et la répétition lors de l'émission TP sont commandés par RetryInfoType avec TP_DATACONF, TP_CONFPENDING et TP_DATARETRY ainsi que l'offset TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

D'autres types d'identifiants complètent l'ensemble. NetworkHandleType (uint8) désigne un canal de communication. TPParameterType sélectionne STmin, Block Size ou le contrôle de bande passante en vue d'une modification ([SWS_COMTYPE_00031]). PNCHandleType est dérivé de uint8 dans R20-11 ([SWS_COMTYPE_00036]) ; la version R23-11 indique différemment uint16 (SWS ComStackTypes p. 17).

plus ›

Rôle : ensemble de types communs de la pile de communication

Le module comstack ne fournit aucun service propre. Il définit les types de données par lesquels les modules de la pile de communication Classic communiquent entre eux. En font partie PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType et PNCHandleType. Ils sont disponibles via ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Interprétation : le module ne possède donc lui-même aucun comportement à l'exécution. Question Q-766338989232e06a (ouverte) Les déroulements, états et réactions aux erreurs ne surviennent que dans les modules qui utilisent ces types dans leurs interfaces.

La frontière système traverse donc l'ensemble de la pile. Les mêmes types sont utilisés par :

• les interfaces de bus telles que CanIf et les protocoles de transport tels que CanTp (SWS CanIf p. 87),
• le PDU Router et les modules de diagnostic tels que le DCM (SWS PduR p. 109),
• SecOC (SWS SecOC p. 110),
• la RTE, qui importe expressément BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType et RetryInfoType depuis ComStack_Types.h (SWS RTE p. 833).

Diagramme de contexte : toutes les couches, de l'interface de bus jusqu'à la RTE, s'appuient sur le même ensemble de types issu de ComStack_Types.h ; ses dimensions sont générées à partir de la configuration EcuC. Sources : [SWS_COMTYPE_00005], SWS RTE p. 833, SWS PduR p. 33, SWS ComM p. 171

Handles et longueurs de PDU : identité et taille d'une PDU

PduIdType est un entier basé sur zéro compris dans la plage 0…<PduIdmax>. Sa largeur (uint8 ou uint16) dépend du nombre maximal de PDU gérées par un module logiciel individuel. L'outil générateur la produit à partir de la valeur configurée dans la couche virtuelle EcuC dans ComStack_Cfg.h ([SWS_COMTYPE_00005]). Le paramètre associé PduIdTypeEnum définit la règle : UINT8 suffit tant qu'aucun module ne traite plus de 256 PDU, sinon UINT16 est nécessaire (ECU Configuration p. 153).

De manière analogue, PduLengthType est configuré selon le cas comme uint8, uint16 ou uint32. L'élément déterminant est la longueur maximale des PDU qu'un calculateur émet ([SWS_COMTYPE_00008]). Les protocoles de transport dérivent également des longueurs à partir de l'EcuC : CanTp détermine la longueur d'émission maximale de la N-PDU à partir du paramètre EcuC PduLength (SWS CanTp p. 60).

Les API de la pile combinent deux éléments : un pointeur vers le tampon de données de PDU et un Handle-ID qui définit à quelle PDU appartient ce pointeur. Le module fournisseur choisit librement la valeur du Handle-ID. Ainsi, la même PDU peut être transmise par Com au PduR avec l'ID 5, puis par le PduR à CanIf avec l'ID 19. L'ID ne doit être unique que dans le périmètre de validité de l'API respective (ECU Configuration p. 156). Pour que deux modules puissent référencer la même PDU, la configuration de module virtuelle EcuC contient la EcucPduCollection indépendante des modules (ECU Configuration p. 154). Le PduR identifie un chemin de routage via l'ID source et les ID de destination, convertit les ID et transmet la valeur PduInfoType sans modification (SWS PduR p. 33).

Diagramme de collaboration : chaque interface possède ses propres Handle-ID ; le PduR les convertit pendant que la PDU commune est référencée via l'EcucPduCollection. Sources : ECU Configuration p. 156, ECU Configuration p. 154, SWS PduR p. 33

PduInfoType : données utiles, métadonnées et longueur dans une structure

PduInfoType regroupe trois éléments ([SWS_COMTYPE_00011]) :

• SduDataPtr pointe vers les données utiles.
• MetaDataPtr pointe vers des métadonnées telles que le CAN-ID, le Socket-ID ou des adresses de diagnostic. Leur longueur et leur type sont configurés statiquement pour chaque PDU ; les éléments de plus de 8 bits respectent l'ordre des octets de la plateforme.
• SduLength de type PduLengthType indique la longueur de la SDU en octets.

La même structure prend en charge plusieurs formes d'interaction :

• Demande d'émission : <Mod>_Transmit(TxPduId, const PduInfoType*) transmet la longueur, le pointeur de données ainsi que le pointeur de métadonnées et renvoie E_OK ou E_NOT_OK (SWS CanIf p. 87).
• Indication de réception : <Mod>_RxIndication(RxPduId, const PduInfoType*). Avec CanNm, le pointeur de données n'est valide que jusqu'au retour de l'indication (SWS CanNm p. 73).
• Trigger Transmit : PduInfoPtr sert d'entrée et de sortie. Lors de l'appel, SduLength contient la taille de tampon disponible, et au retour, la longueur des données copiées (SWS CanIf p. 107). Dans la demande d'émission précédente, la couche supérieure ne transmet que la longueur ; SduDataPtr pointe alors vers NULL (SWS CanIf p. 158).
• Interfaces de copie TP : StartOfReception, CopyRxData et CopyTxData avec valeur de retour BufReq_ReturnType (SWS PduR p. 93).

Tampons du protocole de transport : copie par segments au lieu d'une transmission en bloc

Les grandes PDU ne sont pas transmises en un seul bloc. L'émetteur récupère les données au fur et à mesure : DCM déclenche CanTp_Transmit via le PduR. CanTp appelle ensuite de manière répétée PduR_CanTpCopyTxData, qui est relayé à Dcm_CopyTxData. Le processus se termine par PduR_CanTpTxConfirmation et Dcm_TpTxConfirmation (SWS PduR p. 109). Les règles suivantes s'appliquent aux paramètres de CopyTxData :

• info fournit le tampon de destination et le nombre d'octets à copier.
• Un SduLength de 0 signale uniquement un changement d'état dans le paramètre retry ou interroge la quantité de données disponible ; SduDataPtr peut alors être NULL_PTR (SWS PduR p. 93).
• availableDataPtr signale les données d'émission restantes. Les modules TP avec une longueur de charge utile dynamique, tels que FrIsoTp, s'y basent pour dimensionner les Consecutive Frames suivants (SWS LdCom p. 34).

Diagramme de séquence : lors d'une émission TP, le protocole de transport extrait les données de la couche supérieure dans une boucle via le PduR ; la confirmation n'intervient qu'après le dernier segment. Sources : SWS PduR p. 109, SWS PduR p. 93, [SWS_COMTYPE_00012]

La réception se déroule en trois étapes :

1. StartOfReception ouvre la connexion. info transporte les données du First Frame ou du Single Frame avec leurs métadonnées, ou vaut NULL_PTR si aucun des deux n'est présent. TpSduLength indique la longueur totale. Via bufferSizePtr, le récepteur signale son espace tampon disponible ; le protocole de transport en déduit la Block Size (SWS PduR p. 92).
2. Chaque appel de CopyRxData fournit le segment suivant de l'I-PDU et met à jour l'espace tampon restant (SWS PduR p. 91).
3. Une RxIndication conclut la réception.

Si une PDU TP fait en plus l'objet d'un routage de passerelle, le PduR la met lui-même en tampon, car le DCM n'a pas connaissance de ce routage (SWS PduR p. 112).

Diagramme de séquence : la réception TP commence par une négociation de tampon, se poursuit par segments et se termine par l'indication. Sources : SWS PduR p. 112, SWS PduR p. 92, SWS PduR p. 91

Confirmation et répétition : RetryInfoType et TpDataStateType

RetryInfoType contient deux champs ([SWS_COMTYPE_00037]) :

• TpDataState décrit l'état du tampon TP.
• TxTpDataCnt indique le décalage à partir de la position actuelle, qui détermine le nombre d'octets à réémettre.

TpDataStateType prend trois valeurs possibles ([SWS_COMTYPE_00027]) :

• TP_DATACONF : toutes les données copiées jusqu'ici sont confirmées et peuvent être retirées du tampon TP. Les données copiées lors de cet appel en sont exclues.
• TP_DATARETRY : les données déjà copiées sont copiées à nouveau afin de corriger une erreur. TxTpDataCnt indique le décalage de départ.
• TP_CONFPENDING : les données copiées jusqu'ici doivent rester dans le tampon TP pour la correction d'erreur.

Si retry est lui-même NULL_PTR, les données peuvent être libérées immédiatement après la copie (SWS PduR p. 93).

Diagramme d'activité : un appel de CopyTxData évalue d'abord le paramètre retry, puis décide d'effectuer la copie ou de retourner BUFREQ_E_BUSY. Sources : SWS PduR p. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

Le schéma relatif au protocole de transport J1939 illustre concrètement cette interaction :

• Pour chaque bloc, le premier paquet est demandé avec TP_DATACONF, et les suivants avec TP_CONFPENDING.
• Si un TP.DT est perdu, la transmission recommence au premier paquet du bloc. Pour cela, TP_DATARETRY est défini et TxTpDataCnt contient le décalage par rapport au début du bloc (SWS J1939Tp p. 55).

Tous les utilisateurs n'évaluent pas ce paramètre : avec LdCom, selon la spécification, retry n'est traité ni par LdCom ni par sa couche supérieure (SWS LdCom p. 34).

Diagramme de séquence : transmission par blocs avec états de confirmation et retour au début du bloc en cas de paquet de données perdu. Sources : SWS J1939Tp p. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Canaux, sous-réseaux et paramètres TP

NetworkHandleType est un uint8 avec une plage basée sur zéro de 0..255. Il stocke l'identifiant d'un canal de communication ([SWS_COMTYPE_00038]). Exemples issus de versions ultérieures :

• Bus Mirroring signale une trame LIN avec le canal ComM affecté au canal LIN (SWS Mirror p. 80).
• J1939Dcm transmet le canal sur lequel une requête a été reçue (SWS J1939Dcm p. 67).

PNCHandleType stocke l'identifiant d'un Partial Network Cluster et dérive de uint8 dans R20-11 ([SWS_COMTYPE_00036]). Le passage du document issu de R23-11 mentionne en revanche uint16 (SWS ComStackTypes p. 17). Pour R20-11, l'exigence fait foi. Le contexte d'utilisation des identifiants PNC est illustré notamment par l'arrêt synchronisé de PNC dans ComM (SWS ComM p. 171).

TPParameterType désigne le paramètre du protocole de transport dont la valeur doit être modifiée ([SWS_COMTYPE_00031]) :

• TP_STMIN : Separation Time,
• TP_BS : Block Size,
• TP_BC : contrôle de bande passante du protocole de transport FlexRay.

Block Size et STmin apparaissent par exemple dans la trame Flow Control du protocole de transport FlexRay-AR (SWS FrArTp p. 47).

Comportement en cas d'erreur

BufReq_ReturnType décrit le résultat d'une demande de tampon ([SWS_COMTYPE_00012]) :

• BUFREQ_OK (0) : succès.
• BUFREQ_E_NOT_OK (1) : le tampon n'est pas accessible.
• BUFREQ_E_BUSY (2) : aucun tampon n'est disponible temporairement ; le demandeur doit réessayer pendant un certain temps.
• BUFREQ_E_OVFL (3) : aucun tampon de la longueur requise ne peut être fourni.

Les interfaces associent ces valeurs comme suit :

• CopyTxData : si les données d'émission ne suffisent pas, rien n'est copié et BUFREQ_E_BUSY est renvoyé ; la couche inférieure peut réitérer l'appel (SWS PduR p. 93). Dans le déroulement Paged Buffer de DCM, BUFREQ_E_BUSY alterne avec la préparation de la page suivante (SWS DCM p. 481).
• StartOfReception : BUFREQ_E_NOT_OK refuse la connexion et interrompt la réception ; bufferSizePtr reste inchangé. BUFREQ_E_OVFL interrompt le traitement car aucun tampon de la longueur requise n'est disponible. En cas de BUFREQ_OK sans tampon de la taille demandée, une taille de tampon de 0 est signalée (SWS DCM p. 273).
• CopyRxData : BUFREQ_E_NOT_OK signifie que rien n'a été copié en raison d'une erreur (SWS PduR p. 91).
• Erreur de transmission dans le TP : la correction s'effectue via TP_DATARETRY avec le décalage TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit : E_NOT_OK signifie que rien n'a été copié. PduInfoPtr ne doit alors pas être utilisé, car il peut être NULL ou invalide (SWS CanIf p. 107).

D'autres vérifications sont définies par les modules utilisateurs eux-mêmes. Exemples :

• DoIP_SoAdTpCopyRxData vérifie, lorsque la détection d'erreurs de développement est activée, si DoIP_Init a été appelé au préalable (SWS DoIP p. 77).
• Dans l'état FRIF_STATE_OFFLINE, FrIf_Transmit renvoie la valeur E_NOT_OK (SWS FrIf p. 68).
• Beaucoup de ces fonctions ne sont réentrantes que pour des ID de PDU différents, pas pour le même (SWS DoIP p. 75).

Preuves détaillées supplémentaires

La vue d'ensemble suivante classe les principales références ([SWS_COMTYPE_00005] à [SWS_COMTYPE_00038]) :

Référence	Classification
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Largeur dépendante de la configuration de PduIdType et PduLengthType, générée à partir d'EcuC
[SWS_COMTYPE_00011]	Structure de PduInfoType incluant les métadonnées
[SWS_COMTYPE_00012]	Codes de résultat de toutes les demandes de tampon TP
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Logique de confirmation et de répétition lors de l'émission TP
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	Sélection des paramètres TP, identifiants PNC et identifiants de canaux
ECU Configuration S. 156	Concept de Handle-ID : valeurs librement choisies par module, uniques par API
SWS PduR S. 93, SWS PduR S. 92	Sémantique de référence des interfaces de copie TP
SWS J1939Tp S. 55	Schéma de gestion des répétitions (également indiqué pour R20-11)