CAN Transport Layer (CanTp)

Le CAN Transport Layer découpe les messages qui ne tiennent pas dans une trame CAN, gère le flux de données par Flow Control et réassemble les segments reçus selon ISO 15765-2 [SWS_CanTp_00033]. Il s'intercale entre PduR et CanIf, ne possède pas de tampon propre pour les données utiles et copie les données d'émission et de réception segment par segment via les services de copie de la couche supérieure [SWS_CanTp_00298]. Il conclut chaque transmission acceptée par une notification à la couche supérieure, avec succès via E_OK, ou en cas de timeout ou d'interruption via E_NOT_OK. Tout cela nécessite CanTp_Init ; la MainFunction cyclique surveille les timeouts.

plus ›

CanTp est le CAN Transport Layer. Il découpe les longs messages en trames CAN, contrôle le flux de données et réassemble les segments reçus ; il suit pour cela l'ISO 15765-2, dans la mesure où la spécification n'en dispose pas autrement [SWS_CanTp_00033]. Le module s'intercale entre PduR et CanIf et ne dispose pas de son propre tampon pour les données utiles. Il copie les données segment par segment via les services de copie de la couche supérieure [SWS_CanTp_00298] [SWS_CanTp_00216].

Diagramme de contexte : les interfaces de CanTp vers PduR, CanIf, la gestion des modes, l'ordonnanceur et le DET. Sources : [SWS_CanTp_00216], SWS CanTp p. 17

Après la mise sous tension, CanTp se trouve dans CANTP_OFF [SWS_CanTp_00168]. CanTp_Init avec CanTp_ConfigType [SWS_CanTp_00208] place toutes les connexions à l'état de repos [SWS_CanTp_00030] ; ensuite, CANTP_ON s'applique [SWS_CanTp_00170]. CanTp_Shutdown ferme toutes les connexions sans notifier personne [SWS_CanTp_00202] [SWS_CanTp_00200]. Les canaux de connexion fonctionnent indépendamment les uns des autres avec leurs propres timers [SWS_CanTp_00122]. Si un canal d'émission est occupé, CanTp rejette les nouvelles requêtes avec E_NOT_OK [SWS_CanTp_00123].

Lors de l'émission, CanTp_Transmit évalue uniquement la longueur (et le cas échéant MetaData) [SWS_CanTp_00225]. Selon la longueur, un SF ou une session segmentée s'ensuit [SWS_CanTp_00232]. Pour chaque segment, CanTp récupère les données avec PduR_CanTpCopyTxData [SWS_CanTp_00086] et attend un Flow Control après le FF et chaque bloc sous N_Bs [SWS_CanTp_00315]. Interprétation : l'appel ne signale que l'acceptation ; la fin du transfert intervient de manière asynchrone via PduR_CanTpTxConfirmation [SWS_CanTp_00176] [SWS_CanTp_00204]. Question (ouverte)

Lors de la réception, CanTp demande d'abord un tampon avec PduR_CanTpStartOfReception [SWS_CanTp_00079]. Ensuite, il copie chaque CF avec PduR_CanTpCopyRxData [SWS_CanTp_00269]. Si le tampon est insuffisant, CanTp l'interroge à nouveau dans chaque MainFunction et émet au maximum WFTmax FC(WAIT) [SWS_CanTp_00222] [SWS_CanTp_00223]. À la fin se trouve PduR_CanTpRxIndication [SWS_CanTp_00084]. La fonction cyclique CanTp_MainFunction surveille les expirations de délai [SWS_CanTp_00164].

Diagramme de séquence : réception segmentée avec négociation de tampon et Flow Control CTS/WAIT. Sources : [SWS_CanTp_00269], [SWS_CanTp_00222], SWS CanTp p. 38

CanTp traite les erreurs de trois manières. Il signale les erreurs de développement au DET et renvoie E_NOT_OK [SWS_CanTp_00294]. Les erreurs de protocole telles que les timeouts interrompent la session et sont transmises avec E_NOT_OK à PduR [SWS_CanTp_00205] [SWS_CanTp_00311]. Il en va de même pour les annulations sur demande via les services de cancel [SWS_CanTp_00255] [SWS_CanTp_00263]. Pour les ID invalides dans les services de cancel, R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254], tandis que des versions plus récentes mentionnent d'autres codes.

plus ›

Rôle dans la pile CAN : protocole de transport entre PduR et CanIf

CanTp est le CAN Transport Layer. Il découpe les messages qui ne tiennent pas dans une trame CAN individuelle en segments, contrôle le flux de données et réassemble les segments reçus (SWS CanTp p. 24, SWS CanTp p. 17). La base est l'ISO 15765-2 : chaque recommandation de cette norme s'applique, à moins que la spécification ne l'exclue expressément [SWS_CanTp_00033]. CanTp n'exécute la segmentation et le réassemblage que dans l'état CANTP_ON [SWS_CanTp_00238].

Vers le haut, CanTp met à la disposition du PduR les services suivants : CanTp_Transmit [SWS_CanTp_00212], CanTp_CancelTransmit [SWS_CanTp_00246] et CanTp_CancelReceive [SWS_CanTp_00257]. Vers le haut, CanTp appelle lui-même PduR_CanTpStartOfReception, PduR_CanTpCopyRxData, PduR_CanTpCopyTxData, PduR_CanTpRxIndication et PduR_CanTpTxConfirmation, et vers le bas CanIf_Transmit [SWS_CanTp_00216]. La couche inférieure signale les trames reçues via CanTp_RxIndication [SWS_CanTp_00078] et les confirmations d'émission via CanTp_TxConfirmation [SWS_CanTp_00076]. Les deux fonctions doivent pouvoir être appelées dans le contexte d'interruption [SWS_CanTp_00235] [SWS_CanTp_00236]. Des passages documentaires plus récents désignent le L-SDU Router (LSduR) comme appelant (SWS CanTp p. 27). Les exigences de R20-11 mentionnent quant à elles le CAN Interface, par exemple [SWS_CanTp_00031] et [SWS_CanTp_00335].

CanTp ne dispose pas de son propre tampon pour les données utiles. Il récupère directement les données d'émission auprès de la couche supérieure [SWS_CanTp_00298] et copie les données reçues immédiatement dans la mémoire de celle-ci (SWS CanTp p. 35). Il en résulte des délais de verrouillage pour la couche supérieure (SWS CanTp p. 35) :

• Elle maintient le tampon d'émission verrouillé dès que CanTp_Transmit retourne avec E_OK, jusqu'à ce que PduR_CanTpTxConfirmation arrive.
• Elle maintient le tampon de réception verrouillé dès qu'elle a fourni BUFREQ_OK à PduR_CanTpStartOfReception, jusqu'à ce que PduR_CanTpRxIndication arrive.

Diagramme de contexte : CanTp se situe entre PduR et CanIf. Il est initialisé par le gestionnaire de mode, déclenché cycliquement par le planificateur et signale les erreurs à DET. Sources : [SWS_CanTp_00216], [SWS_CanTp_00217], [SWS_CanTp_00164], SWS CanTp p. 17, Mode Management Guide p. 54

Cycle de vie : CANTP_OFF, CanTp_Init et canaux de connexion indépendants

CanTp connaît les états CANTP_OFF et CANTP_ON [SWS_CanTp_00027]. Après la mise sous tension, le module est dans CANTP_OFF [SWS_CanTp_00168] ; ce n'est que là que la configuration post-build peut être mise à jour [SWS_CanTp_00169].

CanTp_Init reçoit un pointeur vers CanTp_ConfigType [SWS_CanTp_00208] [SWS_CanTp_00340]. La fonction initialise toutes les variables globales et place chaque connexion à l'état de repos CANTP_RX_WAIT ou CANTP_TX_WAIT [SWS_CanTp_00030] ; ensuite, CANTP_ON [SWS_CanTp_00170] s'applique. L'environnement doit appeler CanTp_Init avant toute utilisation ultérieure [SWS_CanTp_00199]. Dans le guide de gestion des modes, une règle BswM s'en charge après NvM_ReadAll (Mode Management Guide p. 54). Un nouvel appel dans CANTP_ON annule toutes les connexions en cours et ramène à l'état de repos [SWS_CanTp_00273] [SWS_CanTp_00111].

CanTp_Shutdown ferme toutes les connexions ouvertes, libère les ressources et définit CANTP_OFF [SWS_CanTp_00202]. Ce faisant, CanTp n'avertit personne des transmissions interrompues [SWS_CanTp_00200] (SWS CanTp p. 58).

Dans CANTP_ON, plusieurs connexions s'exécutent simultanément [SWS_CanTp_00096] :

• Chaque N-SDU est assignée statiquement à un canal de connexion. Chaque canal possède ses propres temporisateurs, tampons et sa propre machine d'état [SWS_CanTp_00121] [SWS_CanTp_00122].
• Les canaux ne sont visibles qu'en interne [SWS_CanTp_00285]. L'outil de configuration détermine leur nombre [SWS_CanTp_00289].
• Si un canal d'émission est dans CANTP_TX_PROCESSING, CanTp rejette les nouvelles requêtes via CanTp_Transmit avec E_NOT_OK [SWS_CanTp_00123]. La même règle s'applique à une N-SDU qui se trouve déjà dans une session en cours [SWS_CanTp_00206].
• Si plusieurs N-SDU partagent un canal et qu'aucun canal libre n'est disponible, CanTp refuse l'émission ou interrompt la réception [SWS_CanTp_00288] (SWS CanTp p. 42).

Diagramme d'état : après CanTp_Init, les canaux de réception et d'émission commutent indépendamment les uns des autres entre WAIT et PROCESSING ; CanTp_Shutdown ramène à CANTP_OFF. Sources : [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00170], [SWS_CanTp_00202], SWS CanTp p. 27

Émission : de CanTp_Transmit à la confirmation

CanTp_Transmit reçoit TxPduId et PduInfoPtr [SWS_CanTp_00212]. Sans MetaData, CanTp n'évalue que la longueur totale SduLength et n'accède pas au tampon de données [SWS_CanTp_00225] [SWS_CanTp_00299]. Avec MetaData, il stocke en plus les informations d'adressage pour tous les SF, FF et CF [SWS_CanTp_00334]. Si les données tiennent dans une N-PDU, CanTp transmet une SF, sinon il ouvre une session multi-trames [SWS_CanTp_00232] (SWS CanTp p. 60). La longueur maximale d'émission (TX_DL) découle de PduLength dans EcuC [SWS_CanTp_00354]. Interprétation : l'appel signale de manière synchrone uniquement si la requête est acceptée ; le transfert proprement dit s'exécute de façon asynchrone [SWS_CanTp_00176]. Question Q-b6d13590324e2906 (ouverte) Après acceptation, CanTp signale dans tous les cas la fin via PduR_CanTpTxConfirmation [SWS_CanTp_00177] [SWS_CanTp_00204].

Pour chaque segment (SF, FF, CF), CanTp appelle PduR_CanTpCopyTxData [SWS_CanTp_00086] ; le temporisateur N_Cs s'exécute jusqu'au premier appel [SWS_CanTp_00167]. Si la couche supérieure retourne BUFREQ_E_BUSY, CanTp réessaie ultérieurement [SWS_CanTp_00184]. CanTp définit toujours le paramètre de réessai sur NULL, car ISO 15765-2 n'admet aucune répétition [SWS_CanTp_00272].

Après le FF et après le dernier CF de chaque bloc, CanTp attend une trame de contrôle de flux sous N_Bs [SWS_CanTp_00315]. Grâce à elle, le récepteur libère des CF supplémentaires ou les retarde [SWS_CanTp_00282]. Si la session est terminée avec succès, PduR_CanTpTxConfirmation suit avec E_OK [SWS_CanTp_00090]. La même séquence en mode pull est illustrée par l'exemple de 50 octets (SWS CanTp p. 37) et par le chemin allant de DCM à CanTp (SWS PduR p. 104).

Diagramme de séquence : CanTp demande les données segment par segment auprès de PduR, attend le Flow Control après le FF et chaque bloc, et confirme à la fin avec E_OK. Sources : [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00315], [SWS_CanTp_00090], SWS CanTp p. 73

Réception : négociation de tampon, Flow Control et réassemblage

À chaque SF ou FF entrant, CanTp signale le début de réception avec PduR_CanTpStartOfReception [SWS_CanTp_00079]. La taille de tampon disponible est renvoyée via un paramètre de sortie et peut être inférieure à la N-SDU [SWS_CanTp_00080]. Lors d'un FF, CanTp démarre préalablement le temporisateur N_Br [SWS_CanTp_00166]. Il n'envoie le Flow Control que lorsque le résultat est disponible ; son contenu dépend de ce résultat [SWS_CanTp_00064] [SWS_CanTp_00277]. Tous les FC d'une session de réception portent les mêmes valeurs pour BS et STmin [SWS_CanTp_00067]. Un FC suit respectivement après BS Consecutive Frames [SWS_CanTp_00278].

Après chaque CF, CanTp transmet les données utiles avec PduR_CanTpCopyRxData et prend connaissance à cette occasion du tampon restant [SWS_CanTp_00269]. Pour CAN 2.0, cela représente six ou sept octets par CF. Si le tampon restant après le dernier CF d'un bloc ne suffit pas pour le bloc suivant, CanTp démarre le temporisateur N_Br [SWS_CanTp_00325] [SWS_CanTp_00082]. Tant que ce temporisateur tourne :

• CanTp interroge le tampon à chaque exécution de la MainFunction, et ce avec une longueur de 0 et NULL_PTR [SWS_CanTp_00222] ;
• CanTp envoie au maximum WFTmax FC(WAIT) consécutifs [SWS_CanTp_00223] (SWS CanTp p. 38).

Si la session prend fin, avec succès ou non, CanTp appelle PduR_CanTpRxIndication [SWS_CanTp_00084]. Avec ou sans padding, CanTp ne remonte vers le haut que les octets de données réellement utilisés [SWS_CanTp_00116].

Diagramme de séquence : réception segmentée avec négociation de tampon, contrôle de flux par blocs et phase d'attente en cas de tampon restreint. Sources : [SWS_CanTp_00079], [SWS_CanTp_00269], [SWS_CanTp_00222], [SWS_CanTp_00084], SWS CanTp p. 76

Diagramme d'activité : voici comment CanTp décide, lors d'une SF ou d'un FF entrant, en fonction de l'état du canal et du résultat de PduR_CanTpStartOfReception. Sources : [SWS_CanTp_00124], [SWS_CanTp_00337], [SWS_CanTp_00081], [SWS_CanTp_00318], [SWS_CanTp_00353], SWS CanTp p. 67

Adressage, MetaData et padding

L'adressage fonctionnel (1:n) n'est autorisé que pour les SF [SWS_CanTp_00092]. CanTp rejette toute session segmentée via un descripteur fonctionnel et signale CANTP_E_INVALID_TATYPE [SWS_CanTp_00093] (SWS CanTp p. 39). En cas d'adressage étendu (Extended) ou mixte (Mixed), CanTp détermine la N-SDU à partir de N_TA ou N_AE dans le premier octet de données [SWS_CanTp_00095] [SWS_CanTp_00284] [SWS_CanTp_00283]. Pour l'affectation des identifiants (SWS CanTp p. 44) :

• Chaque NSduId est affectée à exactement un LSduId [SWS_CanTp_00035].
• Le LSduId d'un FC identifie, conjointement avec N_TA ou N_AE, exactement un NSduId [SWS_CanTp_00094].
• Plusieurs N-SDU ne sont autorisées à référencer la même N-PDU qu'en cas d'adressage étendu/mixte ou avec MetaData [SWS_CanTp_00328].

Les connexions génériques fonctionnent avec MetaData. CanTp enregistre les informations d'adressage issues de la SF ou du FF [SWS_CanTp_00330], les transmet à PduR_CanTpStartOfReception [SWS_CanTp_00331] et vérifie les CF suivants par rapport à celles-ci [SWS_CanTp_00333]. Si le canal est déjà en cours de réception, CanTp ignore toute autre SF ou FF avec MetaData [SWS_CanTp_00337].

Le padding est activé par N-SDU (SWS CanTp p. 43). La valeur de remplissage est CANTP_PADDING_BYTE [SWS_CanTp_00059]. Pour les trames ayant au maximum 8 octets de charge utile :

• Avec le Rx-padding, CanTp n'accepte la SF et le dernier CF qu'avec 8 octets [SWS_CanTp_00344] et émet les FC avec 8 octets [SWS_CanTp_00347].
• Avec le Tx-padding, CanTp complète la SF et le dernier CF à 8 octets [SWS_CanTp_00348].

Si une longueur d'émission ne correspond à aucun DLC valide, CanTp remplit jusqu'à la valeur valide immédiatement supérieure [SWS_CanTp_00351]. CanTp déduit la longueur de réception RX_DL de la première CAN_DL reçue [SWS_CanTp_00350].

Surveillance temporelle, paramètres d'exécution et annulation sur demande

CanTp_MainFunction [SWS_CanTp_00213] est appelée cycliquement. Elle surveille N_As, N_Bs, N_Cs, N_Ar, N_Br, N_Cr ainsi que STmin [SWS_CanTp_00164] (SWS CanTp p. 63). Sa cadence dépend de CanTpMainFunctionPeriod [SWS_CanTp_00300]. Cette valeur doit correspondre à la période de cycle de la tâche appelante (SWS CanTp p. 77). À titre d'exemple, l'analyse temporelle mentionne une tâche de 5 ms (TR Timing Analysis p. 117).

Deux services accèdent au moment de l'exécution aux paramètres de réception BS et STmin d'une N-SDU : CanTp_ChangeParameter les modifie [SWS_CanTp_00302], CanTp_ReadParameter les lit [SWS_CanTp_00323]. Tous deux n'existent que si CanTpChangeParameterApi = TRUE (SWS CanTp p. 61). BS n'est qu'une valeur maximale dont CanTp a le droit de descendre en dessous pour des raisons de tampon [SWS_CanTp_00091]. Entre le FF et le dernier CF d'une session de réception en cours, CanTp rejette toute modification avec E_NOT_OK [SWS_CanTp_00303] [SWS_CanTp_00304]. Pour les connexions génériques, une modification s'applique à toutes [SWS_CanTp_00338].

Les transmissions en cours peuvent être annulées sur demande :

• Émission : la fonction est activée statiquement via CanTpTc [SWS_CanTp_00242] et déclenchée avec CanTp_CancelTransmit [SWS_CanTp_00274]. Avec E_OK, CanTp interrompt la transmission [SWS_CanTp_00243] [SWS_CanTp_00256] et signale PduR_CanTpTxConfirmation avec E_NOT_OK [SWS_CanTp_00255]. De l'autre côté, cela entraîne un timeout (SWS CanTp p. 26).
• Réception : CanTp_CancelReceive met fin à une réception commencée avec un FF [SWS_CanTp_00261] et signale PduR_CanTpRxIndication avec E_NOT_OK [SWS_CanTp_00263]. Dans le cas d'une SF ou lorsqu'il ne reste plus que le dernier CF en attente, CanTp refuse l'annulation [SWS_CanTp_00262] (SWS CanTp p. 60).

Comportement en cas d'erreur

Erreurs de développement. Si la détection est active, CanTp signale l'erreur à DET et fournit E_NOT_OK [SWS_CanTp_00294] [SWS_CanTp_00217] (SWS CanTp p. 49). Les codes sont définis par [SWS_CanTp_00293]. Cas typiques :

• CANTP_E_UNINIT : une fonction autre que CanTp_GetVersionInfo est utilisée avant CanTp_Init [SWS_CanTp_00031].
• CANTP_E_PARAM_POINTER : un pointeur est NULL [SWS_CanTp_00319] [SWS_CanTp_00321] [SWS_CanTp_00322].
• CANTP_E_PARAM_ID : CanTp_ReadParameter reçoit des paramètres non valides [SWS_CanTp_00324].

Divergence entre les versions : pour un PduId non valide lors des services d'annulation, R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254] [SWS_CanTp_00260]. Des passages de documents plus récents indiquent à la place CANTP_E_INVALID_TX_ID ou CANTP_E_INVALID_RX_ID (SWS CanTp p. 59). Pour R20-11, l'exigence fait foi.

Erreurs d'exécution. Elles sont transmises au Default Error Tracer [SWS_CanTp_00352] :

• CANTP_E_PADDING : une trame est trop courte malgré le padding [SWS_CanTp_00345] [SWS_CanTp_00346] [SWS_CanTp_00349].
• CANTP_E_OPER_NOT_SUPPORTED : une annulation concerne une N-SDU sans transmission en cours [SWS_CanTp_00254].
• Pour les erreurs de protocole, le passage de document cite en outre CANTP_E_COM, CANTP_E_RX_COM et CANTP_E_TX_COM (SWS CanTp p. 52).

Erreurs de protocole. Elles mettent fin à la session avec E_NOT_OK vers la couche supérieure [SWS_CanTp_00205] :

• Côté émission (signalement via PduR_CanTpTxConfirmation) : manque de données lors de la copie [SWS_CanTp_00087], expiration de N_Cs [SWS_CanTp_00280], N_As [SWS_CanTp_00310] ou N_Bs [SWS_CanTp_00316], FC avec OVFLW ou FS non valide [SWS_CanTp_00309] [SWS_CanTp_00317]. Après N_As, la N-PDU reste verrouillée jusqu'à ce que la TxConfirmation arrive [SWS_CanTp_00075].
• Côté réception (signalement via PduR_CanTpRxIndication) : expiration de N_Ar [SWS_CanTp_00311] ou N_Cr [SWS_CanTp_00313], copie refusée [SWS_CanTp_00271].
• Interruption sans notification : si PduR_CanTpStartOfReception renvoie BUFREQ_E_NOT_OK, CanTp s'interrompt ; il ne s'ensuit ni FC ni indication [SWS_CanTp_00081].
• CanTp traite les N-PDU inattendues d'après un tableau [SWS_CanTp_00057] (SWS CanTp p. 45).

Le PduR transmet la confirmation négative à l'utilisateur, par exemple au DCM, qui se charge ensuite du rétablissement (Error Description p. 29, Error Description p. 28). Dem traite les erreurs de production via FiM [SWS_CanTp_00291].

Diagramme d'activité : toutes les causes d'interruption aboutissent pour chaque direction à une notification négative adressée à PduR. Sources : [SWS_CanTp_00205], [SWS_CanTp_00343], [SWS_CanTp_00355], [SWS_CanTp_00342], [SWS_CanTp_00223], [SWS_CanTp_00084], Error Description p. 28

Preuves détaillées supplémentaires

• Cycle de vie et canaux : [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00122] ; automate d'état dans SWS CanTp p. 27.
• Émission : [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00204] ; exemple de déroulement dans SWS CanTp p. 37.
• Réception et tampons : [SWS_CanTp_00079], [SWS_CanTp_00222] ; exemple de 49 octets dans SWS CanTp p. 38.
• Surveillance temporelle : [SWS_CanTp_00164], [SWS_CanTp_00300].
• Adressage et padding : [SWS_CanTp_00092], [SWS_CanTp_00330], [SWS_CanTp_00344] ; contexte dans SWS CanTp p. 43.
• Codes d'erreur : [SWS_CanTp_00293] (erreurs de développement), [SWS_CanTp_00352] (erreurs d'exécution) ; tableau des N-PDU inattendues dans [SWS_CanTp_00057].