FlexRay Transport Layer (FrTp)

FrTp transmet des messages volumineux entre le PduR et FrIf selon l'ISO 10681-2 ([SWS_FrTp_01005]). Il les segmente et les réassemble, contrôle le flux et répartit la bande passante sur des pools de PDU Tx partagés. FrTp_Transmit ne fait qu'accepter une demande d'émission ; le travail proprement dit est exécuté par la FrTp_MainFunction cyclique, qui doit s'exécuter au moins une fois par cycle FlexRay ([SWS_FrTp_01152]). Sont prises en charge les transmissions acquittées et non acquittées ainsi que les messages de longueur inconnue. En cas d'erreurs de protocole ou de segmentation non autorisée, FrTp s'interrompt et signale E_NOT_OK au PduR.

plus ›

FrTp est la couche de transport pour FlexRay selon l'ISO 10681-2. Là où la spécification ne définit rien de spécifique, le module suit cette norme ([SWS_FrTp_01005]). Il découpe les grands N-SDU du PduR en N-PDU, les transmet à FrIf avec FrIf_Transmit et réassemble les trames reçues ([SWS_FrTp_01050], FrTp SWS p. 19). Le traitement n'a lieu que dans l'état FRTP_ON, c'est-à-dire entre FrTp_Init et FrTp_Shutdown ([SWS_FrTp_01032], [SWS_FrTp_01036]). FrTp_MainFunction doit s'exécuter au moins une fois par cycle FlexRay ([SWS_FrTp_01152]).

Diagramme de contexte : FrTp entre le PduR et FrIf, piloté par l'EcuM et le BSW-Scheduler. Sources : [SWS_FrTp_00577], FrTp SWS p. 21

L'émission commence toujours par FrTp_Transmit. L'appel n'occupe qu'un canal et définit TX_SDU_AVAILABLE ([SWS_FrTp_00136], [SWS_FrTp_01039]). La MainFunction se charge du reste : elle récupère les données via PduR_FrTpCopyTxData, alloue le premier PDU de pool libre et décide de la segmentation ([SWS_FrTp_01045], [SWS_FrTp_01048]). En mode « Decoupled Buffer Access », FrIf récupère ultérieurement les données via FrTp_TriggerTransmit ([SWS_FrTp_01060]). PduR_FrTpTxConfirmation suit après chaque demande acceptée ([SWS_FrTp_01058]).

Diagramme de séquence : acceptation de la demande, traitement dans la MainFunction, confirmation pour chaque N-PDU et à la fin vers le PduR. Sources : FrTp SWS p. 44, [SWS_FrTp_01042]

Lors de la réception, FrTp vérifie le RxPduId et les adresses par rapport à la configuration de la connexion ([SWS_FrTp_01069], [SWS_FrTp_01071]). Lors d'une nouvelle connexion, il appelle PduR_FrTpStartOfReception, copie les fragments vers le haut et émet du FlowControl si nécessaire ([SWS_FrTp_01078], [SWS_FrTp_01080]). Six variantes sont prises en charge : non segmentée ou segmentée, avec ou sans acquittement, avec longueur connue ou inconnue ([SWS_FrTp_01007]–[SWS_FrTp_01012]). Plusieurs connexions partagent des pools de PDU Tx et sont servies à tour de rôle ([SWS_FrTp_01020], [SWS_FrTp_01096]).

En cas d'erreur, FrTp s'interrompt dans trois situations et signale E_NOT_OK au PduR : en cas de Flow Status invalide ou interruptif, et en cas de besoin de segmentation sur des connexions 1:n ([SWS_FrTp_01198], [SWS_FrTp_01208]). Les erreurs d'exécution sont FRTP_E_SEG_ERROR et FRTP_E_NO_CHANNEL. Des temporisateurs et des compteurs tels que la limite FC.WAIT bornent les temps d'attente ([SWS_FrTp_01100], [SWS_FrTp_01114]). Les transmissions en cours peuvent être interrompues avec FrTp_CancelTransmit et FrTp_CancelReceive ([SWS_FrTp_01116], [SWS_FrTp_01181]).

plus ›

Rôle dans la pile FlexRay et état du module

FrTp est la couche de transport FlexRay selon l'ISO 10681-2. Là où la spécification ne définit rien de spécifique, le module suit cette norme et prend en charge ses formats de N-PDU ([SWS_FrTp_01005], [SWS_FrTp_01006]). Vers le haut, FrTp dessert le PduR. Le PduR démarre les transmissions avec FrTp_Transmit, les interrompt ou en modifie les paramètres. FrTp renvoie des données et des résultats via PduR_FrTpStartOfReception, PduR_FrTpCopyRxData, PduR_FrTpCopyTxData, PduR_FrTpRxIndication et PduR_FrTpTxConfirmation (FrTp SWS p. 19). Vers le bas, FrTp transmet des N-PDU avec FrIf_Transmit ([SWS_FrTp_01050]). FrIf répond avec FrTp_RxIndication, FrTp_TxConfirmation et FrTp_TriggerTransmit (FrTp SWS p. 21). L'EcuM appelle FrTp_Init et FrTp_Shutdown (FrTp SWS p. 19). Le BSW-Scheduler appelle FrTp_MainFunction ([SWS_FrTp_00162], FrTp SWS p. 81).

Une différence entre les versions : des versions ultérieures intercalent un routeur de L-SDU (LSduR) entre FrTp et FrIf (FrTp SWS p. 19). Pour R20-11, l'interface directe avec FrIf s'applique, telle que définie par [SWS_FrTp_00577] et [SWS_FrTp_01050].

Diagramme de contexte : FrTp est situé entre le PduR et FrIf et est piloté par l'EcuM et le BSW-Scheduler. Sources : FrTp SWS p. 19, FrTp SWS p. 21, [SWS_FrTp_00577]

Le module connaît deux états, FRTP_OFF et FRTP_ON ([SWS_FrTp_01028]). La variable d'état FrTpState consigne celui qui s'applique ([SWS_FrTp_01029], [SWS_FrTp_01106]). Après la mise sous tension, FrTp se trouve dans FRTP_OFF ([SWS_FrTp_01030]). Seul un FrTp_Init réussi avec un pointeur vers FrTp_ConfigType fait basculer vers FRTP_ON ([SWS_FrTp_01032], [SWS_FrTp_00147], [SWS_FrTp_01194]). La segmentation et le réassemblage ne s'exécutent que dans FRTP_ON ([SWS_FrTp_01033]). FrTp_Shutdown met fin à toutes les connexions ouvertes en arrêtant purement et simplement le fonctionnement. Il libère les ressources et ramène vers FRTP_OFF ([SWS_FrTp_00148], [SWS_FrTp_01036]).

Diagramme d'état : FrTp ne traite les données qu'entre FrTp_Init et FrTp_Shutdown. Sources : [SWS_FrTp_01030], [SWS_FrTp_01032], [SWS_FrTp_01036], FrTp SWS p. 38

FrTp_MainFunction planifie le module et constitue le point d'entrée de toutes les tâches de traitement ([SWS_FrTp_00203], [SWS_FrTp_00580]). Elle doit s'exécuter au moins une fois par cycle FlexRay ([SWS_FrTp_01152]). En revanche, les callbacks ne font pour l'essentiel que positionner des drapeaux : TX_SDU_AVAILABLE existe par canal ([SWS_FrTp_00415], [SWS_FrTp_00416]). RX_PDU_AVAILABLE existe pour chaque N-PDU pouvant être reçu et est effacé après le traitement ([SWS_FrTp_00418], [SWS_FrTp_00421]).

Variantes de transmission selon l'ISO 10681-2

FrTp prend en charge six séquences de trames. Elles diffèrent sur trois points : si le message est segmenté, si le récepteur acquitte et si la longueur est connue au début de la transmission (FrTp SWS p. 27, FrTp SWS p. 31) :

Variante	Trames caractéristiques	Référence
non segmentée, sans acquittement, longueur connue	STFU	[SWS_FrTp_01007]
non segmentée, avec acquittement, longueur connue	STFA → FC.ACK	[SWS_FrTp_01008]
segmentée, sans acquittement, longueur connue	STFU, FC.CTS, CF, CFEOB, LF	[SWS_FrTp_01009]
segmentée, avec acquittement, longueur connue	STFA, FC.CTS, CF, CFEOB, LF, FC.ACK	[SWS_FrTp_01010]
segmentée, sans acquittement, longueur inconnue	comme ci-dessus, longueur totale uniquement dans LF	[SWS_FrTp_01011], [SWS_FrTp_01067]
segmentée, avec acquittement, longueur inconnue	comme ci-dessus, avec FC.ACK en plus	[SWS_FrTp_01012]

Dans les variantes segmentées et acquittées, FC.ACK devrait suivre LastFrame et conclure le transfert. Question Q-f3c70b1506e2cde4 (ouverte) Il s'agit d'une interprétation des légendes de figures, dont l'ordre n'est pas univoque (FrTp SWS p. 29). Le diagramme suivant illustre le cas de base segmenté sans acquittement.

Diagramme de séquence : le récepteur libère chaque bloc par FC.CTS, et CFEOB conclut un bloc. Sources : [SWS_FrTp_01009], FrTp SWS p. 28

Transmission avec longueur inconnue :

• Elle est activée par un commutateur de compilation ([SWS_FrTp_01062]).
• Elle est démarrée avec FrTp_Transmit et une longueur de 0 ([SWS_FrTp_01064], [SWS_FrTp_01043]).
• Elle prend fin lorsque le paramètre de longueur signalé est égal à 0 ([SWS_FrTp_01066]).
• Le drapeau TX_SDU_UNKNOWN_MSG_LENGTH maintient l'état pour chaque canal ([SWS_FrTp_01101], [SWS_FrTp_01102]).
• Le récepteur appelle PduR_FrTpStartOfReception avec une longueur attendue de 0 ([SWS_FrTp_01184]).
• Sur une connexion 1:n, FrTp_Transmit rejette de telles demandes avec E_NOT_OK et signale FRTP_E_SEG_ERROR ([SWS_FrTp_01187], FrTp SWS p. 47).

Connexions, canaux et pools de PDU

Chaque relation de communication constitue une FrTpConnection propre. Leur nombre est configurable en post-build ([SWS_FrTp_01014], [SWS_FrTp_01015]). Chaque connexion possède une paire d'adresses unique à l'échelle du module et un FRTP_SDUID unique ([SWS_FrTp_01017], [SWS_FrTp_01018]). Plusieurs connexions peuvent partager un FrTpConnectionControl et un FrTpTxPduPool ([SWS_FrTp_01022], [SWS_FrTp_01020]). À l'exécution, plusieurs FrTpChannel fonctionnent en parallèle ; leur nombre est défini par FrTpChanNum ([SWS_FrTp_00088], [SWS_FrTp_00228]). Pour l'émission et la réception, les canaux basculent respectivement entre « idle » et « busy » ([SWS_FrTp_01117], [SWS_FrTp_01025]).

Diagramme de contexte : un canal semi-duplex référence une connexion Tx et une connexion Rx. Toutes deux référencent des paramètres de contrôle et un pool de PDU Tx. Sources : FrTp SWS p. 39, [SWS_FrTp_01020], [SWS_FrTp_01088]

Adresses :

• Lors de l'émission, FrTp reprend les adresses issues des métadonnées SOURCE_ADDRESS_16 et TARGET_ADDRESS_16. Les FrTpLa/FrTpRa configurés sont alors prioritaires ([SWS_FrTp_01204], [SWS_FrTp_01205]).
• Lors de la réception, FrTp transmet les adresses vers le haut en tant que métadonnées. Il utilise ces mêmes adresses pour le FlowControl ([SWS_FrTp_01206]).

FrTp répartit la bande passante via les pools :

• Les N-PDU Tx d'un pool sont ordonnés selon l'ordonnancement réseau croissant et peuvent être de longueurs différentes ([SWS_FrTp_01088], [SWS_FrTp_01089]).
• Le TxPduPendingCounter d'un canal compte les N-PDU non confirmés ([SWS_FrTp_01091], [SWS_FrTp_01092]). Une connexion n'est traitée que s'il est égal à 0 ([SWS_FrTp_01094]). Ainsi, les Consecutive Frames ne peuvent pas se dépasser (FrTp SWS p. 61).
• Les connexions actives sont traitées à tour de rôle ([SWS_FrTp_01096]).
• En cas de limitation de bande passante, trois règles s'appliquent : StartFrame et FlowControl passent dans le premier PDU du pool ([SWS_FrTp_01174], [SWS_FrTp_01177]). L'émetteur n'utilise que BC.MPPC PDU ([SWS_FrTp_01175]). Les pools peuvent se chevaucher ([SWS_FrTp_01176]).
• FrIf doit planifier les PDU d'une connexion par ordre croissant au sein d'une tâche (FrTp SWS p. 122).

Chemin d'émission : de FrTp_Transmit à PduR_FrTpTxConfirmation

Toute émission commence par FrTp_Transmit ([SWS_FrTp_00136], [SWS_FrTp_00149]). L'appel ne positionne TX_SDU_AVAILABLE que si le TxPduId est valide et qu'un canal est libre ([SWS_FrTp_01039]). Dans le cas contraire, il se termine par E_NOT_OK. Il en va de même si une transmission est déjà en cours pour la même adresse ([SWS_FrTp_01041], [SWS_FrTp_01200]).

Le travail proprement dit est effectué par FrTp_MainFunction :

1. Elle demande la longueur disponible via PduR_FrTpCopyTxData ([SWS_FrTp_01042]).
2. Elle alloue le premier FrTpTxPdu libre ([SWS_FrTp_01045]).
3. Elle décide de la segmentation ([SWS_FrTp_01048]).
4. Elle copie les données à hauteur de la longueur du PDU ([SWS_FrTp_01123]).
5. Elle transmet le N-PDU avec la longueur exacte à FrIf_Transmit ([SWS_FrTp_01051]).

Le déroulement est présenté dans FrTp SWS p. 44.

Diagramme d'activité : décision entre transmission non segmentée et segmentée, y compris interruption sur les connexions 1:n. Sources : [SWS_FrTp_01047], [SWS_FrTp_01048], [SWS_FrTp_01208], FrTp SWS p. 51

Important pour le débit : si aucun PDU n'est libre, FrTp reporte la connexion jusqu'au prochain appel de la MainFunction ([SWS_FrTp_01047]).

Après chaque N-PDU, FrIf appelle FrTp_TxConfirmation. Cela positionne le FrTpTxPdu sur « idle » ([SWS_FrTp_01052], [SWS_FrTp_01054]). Le canal et le drapeau sont libérés dès que trois conditions sont remplies : toutes les données ont été envoyées, confirmées positivement et, si cela est configuré, acquittées ([SWS_FrTp_01056], [SWS_FrTp_01057]). PduR_FrTpTxConfirmation intervient après chaque demande acceptée, avec E_OK uniquement en cas de succès ([SWS_FrTp_01058]). Pour l'émission, il existe deux modes d'accès aux tampons : « Immediate » et « Decoupled Buffer Access » ([SWS_FrTp_01084]). En mode « Decoupled », FrIf récupère ultérieurement les données via FrTp_TriggerTransmit. Cet appel copie les Address Information, le PCI et les données utiles dans le tampon fourni ([SWS_FrTp_01060], [SWS_FrTp_01061], FrTp SWS p. 50).

Diagramme de séquence : la demande arrive de manière synchrone et est traitée de manière asynchrone dans la MainFunction ; TriggerTransmit (Decoupled) suit de manière optionnelle. Sources : FrTp SWS p. 44, FrTp SWS p. 50, [SWS_FrTp_01058]

Chemin de réception et réassemblage

La réception commence par FrTp_RxIndication ([SWS_FrTp_00137]). FrTp ne traite une N-PDU que si deux conditions sont remplies ([SWS_FrTp_01069], [SWS_FrTp_01071]) :

• Le RxPduId est valide.
• L'adresse de destination correspond à FrTpLa et l'adresse source à FrTpRa.

Sinon, la N-PDU est ignorée ([SWS_FrTp_01072]). Si aucun canal Rx n'est libre, le traitement prend fin et FrTp signale FRTP_E_NO_CHANNEL ([SWS_FrTp_01076], [SWS_FrTp_01186]). FrTp stocke une StartFrame dans un tampon local. Ainsi, une passerelle peut la traiter correctement même en cas de manque temporaire de ressources (FrTp SWS p. 56).

Lors d'une nouvelle connexion, FrTp appelle PduR_FrTpStartOfReception. La longueur attendue ainsi que le contenu et la taille de la StartFrame sont transmis ([SWS_FrTp_01078], [SWS_FrTp_01193]). Les diagrammes R20-11 montrent deux variantes pour l'emplacement de cet appel : dans FrTp_RxIndication (FrTp SWS p. 55) et dans FrTp_MainFunction (FrTp SWS p. 86). R23-11 autorise expressément les deux (FrTp SWS p. 54).

Ensuite, FrTp copie les fragments via PduR_FrTpCopyRxData et envoie FlowControl lorsque le protocole l'exige ([SWS_FrTp_01138], [SWS_FrTp_01080]). Il libère le canal lorsque toutes les données ont été reçues et que tous les FlowControls ont été confirmés ([SWS_FrTp_01081]). PduR_FrTpRxIndication suit systématiquement dès que PduR_FrTpStartOfReception a réussi ([SWS_FrTp_01083]).

Diagramme de séquence : le callback vérifie et met en tampon, la MainFunction réassemble et envoie FlowControl. Sources : FrTp SWS p. 55, [SWS_FrTp_01074], [SWS_FrTp_01083]

Annulation et paramètres d'exécution

FrTpTransmitCancellation définit statiquement si l'annulation d'émission est disponible ; elle est déclenchée avec FrTp_CancelTransmit ([SWS_FrTp_01097], [SWS_FrTp_00384]). L'effet dépend de l'avancement :

• Si la demande est acceptée mais pas encore démarrée, la connexion est immédiatement libérée. Le récepteur ne remarque rien ([SWS_FrTp_00385], FrTp SWS p. 63).
• Si la transmission est en cours, FrTp l'arrête avec E_OK ([SWS_FrTp_01116]).
• E_NOT_OK suit si aucune connexion n'est active ou si la dernière N-PDU d'une transmission non acquittée a déjà été transmise à FrIf ([SWS_FrTp_01116]).

Dans le cas segmenté, un timeout expire du côté du récepteur, ce qui met fin à la réception (FrTp SWS p. 59).

Diagramme de séquence : si l'émetteur interrompt une transmission segmentée en cours, le récepteur met fin à la réception par timeout. Sources : [SWS_FrTp_01116], FrTp SWS p. 69

FrTp_CancelReceive interrompt une réception en cours si la RxPduId est valide, puis renvoie E_OK ([SWS_FrTp_01181], [SWS_FrTp_01183]). En cas de réception non segmentée ou de LastFrame en cours, la fonction rejette l'opération ([SWS_FrTp_01182]). FrTp_ChangeParameter modifie au moment de l'exécution les valeurs de BandwidthControl FrTpSCexp et FrTpMaxNbrOfNPduPerCycle ([SWS_FrTp_00242]). La disposition des bits correspond à celle de la trame FC(CTS) ([SWS_FrTp_01195]). L'identifiant de paramètre correspondant est TP_BC (ComStack Types p. 18). Pendant une réception en cours, la modification est rejetée ([SWS_FrTp_01115]). Après une modification réussie, la connexion utilise les nouvelles valeurs ([SWS_FrTp_01156]).

Comportement en cas d'erreur

Les erreurs de développement sont définies dans [SWS_FrTp_01201] :

• FRTP_E_UNINIT : appel sans initialisation ; à l'exclusion de FrTp_Init et FrTp_GetVersionInfo.
• FRTP_E_PARAM_POINTER : pointeur NULL.
• FRTP_E_INVALID_PDU_SDU_ID : ID de SDU ou de PDU non valide.
• FRTP_E_INVALID_PARAMETER : paramètre non valide.
• FRTP_E_UMSG_LENGTH_ERROR : longueur inconnue sans configuration adaptée ([SWS_FrTp_01134]).
• un code d'erreur pour une initialisation ayant échoué.

Les API vérifient les ID et les pointeurs et renvoient E_NOT_OK en cas d'erreur lorsqu'elles possèdent une valeur de retour ([SWS_FrTp_01139], [SWS_FrTp_01145], [SWS_FrTp_01147]). Les erreurs d'exécution sont FRTP_E_SEG_ERROR (0x05) et FRTP_E_NO_CHANNEL (0x07). Elles sont signalées via Det_ReportRuntimeError ([SWS_FrTp_01208], [SWS_FrTp_00577]).

Dans trois cas, l'émetteur interrompt la transmission et signale PduR_FrTpTxConfirmation avec E_NOT_OK :

• Un FlowControl a un Flow Status non valide ou OVFLW/ABT ([SWS_FrTp_01198]).
• ACK_RET pointe vers une position hors du tampon ([SWS_FrTp_01199]).
• Une connexion 1:n devrait être segmentée (FrTp SWS p. 51).

Un FrTp_TxConfirmation avec E_NOT_OK libère le canal des deux côtés ([SWS_FrTp_01056], [SWS_FrTp_01081]). Le drapeau RX_ERROR mémorise une erreur de réception jusqu'à ce que l'envoi de FlowControl soit autorisé. Après la réaction (Retry, acquittement négatif ou annulation), il est effacé ([SWS_FrTp_00429], [SWS_FrTp_00430]). Sur les connexions 1:n, il n'y a ni acquittement ni Retry ([SWS_FrTp_00598]).

Les temporisateurs et les timeouts suivent les tableaux de la spécification ([SWS_FrTp_01099], [SWS_FrTp_01100], FrTp SWS p. 67). La configuration doit respecter les conditions suivantes :

• FRTP_TIMEOUT_BS > FRTP_TIME_BR + FRTP_TIME_AR ([SWS_FrTp_00599])
• FRTP_TIMEOUT_CR > FRTP_TIME_CS + FRTP_TIME_AS ([SWS_FrTp_01153])
• une limite pour l'exposant de cycle de séparation ([SWS_FrTp_00180])

Si le PduR renvoie BUFREQ_E_BUSY lors de l'émission, FrTp réessaie jusqu'à FrTpTimeCs fois ([SWS_FrTp_01196]). Les compteurs sont limités ([SWS_FrTp_01105], [SWS_FrTp_01114]). [SWS_FrTp_01113] définit ce qui se produit lorsqu'une limite est atteinte ; le tableau correspondant n'est pas disponible ici. Si le récepteur manque d'un tampon, il envoie FC.WAIT. FrTpMaxFCWait limite le nombre de ces trames (FrTp SWS p. 69).

Diagramme de séquence : si le tampon manque, le récepteur envoie FC.WAIT jusqu'à ce que la limite du compteur s'applique ; ensuite, FC.CTS reprend la transmission. Sources : [SWS_FrTp_01105], [SWS_FrTp_01114], FrTp SWS p. 70

Preuves détaillées supplémentaires

• Cycle de vie et ordonnancement : [SWS_FrTp_01028], [SWS_FrTp_01152], FrTp SWS p. 88.
• Variantes de protocole : [SWS_FrTp_01007] à [SWS_FrTp_01012] avec les schémas à partir de FrTp SWS p. 27.
• Chemin d'émission et confirmation : [SWS_FrTp_01042], [SWS_FrTp_01058], FrTp SWS p. 85.
• Chemin de réception : [SWS_FrTp_01078], [SWS_FrTp_01083].
• Bande passante et pools : [SWS_FrTp_01096], [SWS_FrTp_01175], FrTp SWS p. 60, FrTp SWS p. 134.
• Scénarios de Retry (répétition d'API par rapport à répétition de PDU) : FrTp SWS p. 106.
• Catalogue d'erreurs : [SWS_FrTp_01201], [SWS_FrTp_01208].