CAN Interface (CanIf)

CanIf constitue la couche indépendante du matériel entre les pilotes ou transceivers CAN et les modules de communication supérieurs. Il mappe les demandes d'émission sur Can_Write(), met en mémoire tampon lorsque le matériel est occupé et transmet les confirmations ainsi que les réceptions filtrées aux callbacks configurés [SWS_CANIF_00318]. Il commande les modes de contrôleur et de transceiver pour le compte de CanSm et signale en retour les BusOff ainsi que les changements de mode. Les modes de canal de PDU activent et désactivent séparément la voie d'émission et la voie de réception. L'émission n'a lieu que si le contrôleur est en CAN_CS_STARTED et que la voie d'émission est débloquée [SWS_CANIF_00317].

plus ›

Le CAN Interface (CanIf) prend en charge toutes les tâches indépendantes du matériel de la communication CAN. Celles-ci comprennent les demandes d'émission, les confirmations, les indications de réception, les notifications d'erreurs ainsi que le démarrage et l'arrêt des contrôleurs CAN SWS CanIf p. 13. CanIf n'accède aux tampons matériels que par l'intermédiaire des services de CanDrv [SWS_CANIF_00023]. Il s'adresse aux contrôleurs et transceivers de plusieurs pilotes au moyen d'identifiants abstraits [SWS_CANIF_00653]. La configuration détermine quels callbacks sont appelés dans PduR, CanNm, CanTp, CanSm ou EcuM [SWS_CANIF_00011] [SWS_CANIF_00724].

Diagramme de contexte : CanIf entre les modules de communication supérieurs, la gestion des modes et les pilotes pour contrôleurs et transceivers. Sources : [SWS_CANIF_00012], [SWS_CANIF_00358], SWS CanIf p. 21

EcuM initialise CanIf avec CanIf_Init(). Ensuite, chaque canal est à CANIF_OFFLINE [SWS_CANIF_00864], et jusque-là, les services rejettent les requêtes avec E_NOT_OK [SWS_CANIF_00661]. Le démarrage du contrôleur via CanIf_SetControllerMode() s'exécute de manière asynchrone. L'achèvement est signalé par CanIf_ControllerModeIndication(), que CanIf transmet à CanSm [SWS_CANIF_00003] [SWS_CANIF_00711]. Ce n'est qu'ensuite que CanIf_SetPduMode() accepte des requêtes [SWS_CANIF_00874]. Les modes de canal de PDU activent et désactivent séparément la voie d'émission et la voie de réception. Les événements de contrôleur tels que SLEEP, STOPPED ou BusOff les forcent [SWS_CANIF_00865] [SWS_CANIF_00866].

Diagramme d'états : Les quatre modes de canal de PDU et leurs transitions par CanIf_SetPduMode() et par des événements de contrôleur. Sources : [SWS_CANIF_00137], [SWS_CANIF_00866], SWS CanIf Fig. 7.8 p. 61

Lors de l'émission, CanIf_Transmit() appelle Can_Write() [SWS_CANIF_00318]. Si le matériel est occupé, CanIf met la L-PDU en mémoire tampon, pour autant qu'un tampon soit configuré [SWS_CANIF_00381]. À la confirmation suivante, il émet l'entrée ayant la priorité la plus élevée [SWS_CANIF_00668]. Les L-PDU reçues passent par un filtrage logiciel et une vérification de longueur avant que CanIf ne les transmette à <User_RxIndication> [SWS_CANIF_00389] [SWS_CANIF_00056].

En cas d'erreur, un BusOff fait passer le canal à CANIF_TX_OFFLINE et est signalé à CanSm [SWS_CANIF_00724]. Lors de l'arrêt d'un contrôleur, CanIf confirme toutes les demandes d'émission en attente avec E_NOT_OK [SWS_CANIF_00739]. Les erreurs de paramètres et d'exécution sont transmises au DET [SWS_CANIF_91006] [SWS_CANIF_91007].

plus ›

Rôle : plaque tournante indépendante du matériel entre les pilotes CAN et la pile de communication

Le CAN Interface (CanIf) prend en charge toutes les tâches indépendantes du matériel de la communication CAN d'un ECU. Les pilotes CAN sous-jacents ne s'occupent plus que de leur matériel concret. CanIf traite les demandes d'émission, les confirmations d'émission, les indications de réception et les notifications d'erreurs, et démarre ou arrête les contrôleurs CAN SWS CanIf p. 13. Il n'accède aux tampons matériels qu'exclusivement par les services du CanDrv [SWS_CANIF_00023]. Les services de commande opèrent avec un ControllerId abstrait qui numérote les contrôleurs de toutes les instances de CanDrv à partir de 0 [SWS_CANIF_00653]. Il en va de même pour les transceivers avec le TransceiverId [SWS_CANIF_00655].

Vers le bas, CanIf regroupe les API de plusieurs pilotes CanTrcv en une interface uniforme, mais ne contient lui-même aucune logique de transceiver SWS CanIf p. 21. Même en présence de plusieurs CanDrv, chaque callback n'existe qu'une seule fois. CanIf reconnaît le pilote appelant grâce au ControllerId dans Can_HwType SWS CanIf p. 68.

Vers le haut, CanIf appelle des callbacks configurables tels que <User_TxConfirmation> et <User_RxIndication> [SWS_CANIF_00011] [SWS_CANIF_00012]. La configuration détermine le destinataire concret, par exemple PduR_CanIfRxIndication [SWS_CANIF_00442] ou CanTp_TxConfirmation [SWS_CANIF_00550]. CanIf signale le BusOff et les changements de mode à CanSm ou à un CDD [SWS_CANIF_00724] [SWS_CANIF_00711]. Les validations de réveil sont transmises à EcuM [SWS_CANIF_00563].

Diagramme de contexte : CanIf assure l'intermédiation entre les modules de communication supérieurs, la gestion des modes (CanSm, EcuM) et les pilotes pour contrôleurs et transceivers CAN. Les notifications d'erreurs, de sécurité et de mise en miroir vont vers DET, IdsM et Mirror. Sources : [SWS_CANIF_00011], [SWS_CANIF_00724], [SWS_CANIF_00358], [SWS_CANIF_00905], [SWS_CANIF_00913], SWS CanIf p. 13

L'étendue des fonctionnalités dépend fortement de la configuration. CanIf_Init() lit notamment le nombre de contrôleurs et l'affectation des HTH/HRH à partir des conteneurs de configuration SWS CanIf p. 22. Le HTH et le HRH sont des handles vers des objets logiques d'émission ou de réception [SWS_CANIF_00291] [SWS_CANIF_00292]. De nombreux services peuvent être désélectionnés par des commutateurs de précompilation, par ex. CanIf_ReadRxPduData() [SWS_CANIF_00330] ou CanIf_SetBaudrate() [SWS_CANIF_00871]. Si aucun nom n'est configuré pour un callback non obligatoire, l'appel est omis SWS CanIf p. 133. En revanche, <User_ControllerBusOff> doit toujours être configuré [SWS_CANIF_00524].

De l'initialisation au contrôleur démarré

EcuM appelle CanIf_Init() [SWS_CANIF_00001]. Ce faisant, CanIf initialise les variables, les drapeaux et les tampons [SWS_CANIF_00085] ainsi que tous les tampons de L-PDU d'émission [SWS_CANIF_00387]. Chaque canal démarre en CANIF_OFFLINE [SWS_CANIF_00864]. Les contrôleurs restent ensuite dans le mode STOPPED, dans lequel il n'y a ni émission ni réception. EcuM initialise CanDrv et CanTrcv séparément SWS CanIf p. 40. Avant l'initialisation, tous les services sauf CanIf_Init() et CanIf_GetVersionInfo() renvoient E_NOT_OK [SWS_CANIF_00661]. L'entité qui appelle CanIf_DeInit() [SWS_CANIF_91002] doit s'assurer qu'aucun transfert n'est encore en cours SWS CanIf p. 81.

Le démarrage du contrôleur s'exécute de manière asynchrone. CanIf_SetControllerMode() [SWS_CANIF_00003] appelle Can_SetControllerMode() [SWS_CANIF_00308]. Le pilote signale le changement effectué plus tard avec CanIf_ControllerModeIndication() [SWS_CANIF_00699], et CanIf transmet la notification à CanSm [SWS_CANIF_00711]. En mode scrutation (polling), Can_MainFunction_Mode() détecte le changement SWS CanIf p. 152. Ce n'est qu'en CAN_CS_STARTED que CanIf_SetPduMode() accepte des requêtes [SWS_CANIF_00874].

Diagramme de séquence : La demande de démarrage est acquittée immédiatement, mais le changement de mode n'est indiqué que plus tard. Les voies de PDU peuvent ensuite être débloquées. Sources : [SWS_CANIF_00308], [SWS_CANIF_00711], [SWS_CANIF_00874], SWS CanIf p. 156

Modes de canal de PDU : commuter séparément la voie d'émission et la voie de réception

Chaque canal d'un contrôleur possède un mode de type CanIf_PduModeType [SWS_CANIF_00137]. Les couches supérieures le définissent avec CanIf_SetPduMode() et le lisent avec CanIf_GetPduMode() [SWS_CANIF_00008] [SWS_CANIF_00009]. Détail des modes SWS CanIf p. 58 :

• CANIF_OFFLINE : Les demandes d'émission sont rejetées avec E_NOT_OK et les tampons sont vidés. Les indications et confirmations sont supprimées [SWS_CANIF_00073].
• CANIF_TX_OFFLINE : Seule la voie d'émission est bloquée, la réception reste active [SWS_CANIF_00489].
• CANIF_TX_OFFLINE_ACTIVE : Les demandes d'émission sont immédiatement confirmées sans être transmises à CanDrv [SWS_CANIF_00072].
• CANIF_ONLINE : L'émission et la réception sont pleinement actives [SWS_CANIF_00075].

Les événements de contrôleur forcent le mode de canal. CAN_CS_SLEEP entraîne CANIF_OFFLINE [SWS_CANIF_00865]. CAN_CS_STOPPED et BusOff entraînent CANIF_TX_OFFLINE [SWS_CANIF_00866].

Diagramme d'états : Les quatre modes de canal de PDU avec les transitions par CanIf_SetPduMode() et par les événements de contrôleur. Les trois modes restreints sont regroupés en un super-état comme dans la spécification. Sources : [SWS_CANIF_00864], [SWS_CANIF_00865], [SWS_CANIF_00866], [SWS_CANIF_00874], SWS CanIf Fig. 7.8 p. 61

Voie d'émission : CanIf_Transmit, mise en mémoire tampon et Trigger Transmit

CanIf_Transmit() [SWS_CANIF_00005] détermine le HTH et appelle Can_Write(). Le swPduHandle transmis revient plus tard dans CanIf_TxConfirmation() [SWS_CANIF_00318]. Auparavant, CanIf positionne les deux bits de poids le plus fort du CanId [SWS_CANIF_00243]. Si Can_Write() renvoie E_OK, cela s'applique également à la demande d'émission [SWS_CANIF_00162].

Une demande n'est acceptée que sous les conditions suivantes :

• Le contrôleur est démarré et la voie d'émission est online ou offline active [SWS_CANIF_00317].
• Lorsque PnTxFilter est actif, seuls les CanIfTxPduPnFilterPdu passent [SWS_CANIF_00750].
• Les données trop longues sont tronquées avec CanIfTxPduTruncation [SWS_CANIF_00894], sinon rejetées [SWS_CANIF_00900].

Des passages documentaires plus récents mentionnent en plus CanXL_Write() SWS CanIf p. 87. Pour R20-11, seul Can_Write() est normatif.

Diagramme d'activités : C'est ainsi que CanIf_Transmit() arbitre entre rejet, confirmation simulée, émission directe et mise en mémoire tampon. Interprétation : L'ordre des vérifications est choisi pour la lisibilité. Sources : [SWS_CANIF_00317], [SWS_CANIF_00382], [SWS_CANIF_00072], [SWS_CANIF_00381], [SWS_CANIF_00837], SWS CanIf Fig. 7.5 p. 51

Si Can_Write() signale CAN_BUSY et que CanIfPublicTxBuffering est actif [SWS_CANIF_00063], CanIf tente de mettre la L-PDU en mémoire tampon [SWS_CANIF_00381]. Cela suppose une taille de tampon supérieure à zéro [SWS_CANIF_00835]. Si la même L-PDU se trouve déjà dans le tampon, elle est écrasée [SWS_CANIF_00068]. Si le tampon est plein, une nouvelle L-PDU est rejetée avec E_NOT_OK [SWS_CANIF_00837]. Une L-PDU ne réside toujours qu'à un seul endroit : dans l'objet matériel ou dans le tampon de CanIf SWS CanIf p. 43.

Lors de CanIf_TxConfirmation() [SWS_CANIF_00007], CanIf notifie l'utilisateur concerné via <User_TxConfirmation> avec E_OK [SWS_CANIF_00383]. Dans le même appel, il vérifie les tampons du HTH libéré [SWS_CANIF_00386]. Il transmet à Can_Write() l'entrée en attente ayant la priorité la plus élevée [SWS_CANIF_00668] [SWS_CANIF_00070]. Lors de E_OK, il supprime immédiatement l'entrée du tampon [SWS_CANIF_00183]. Des passages documentaires plus récents nomment le callback LSduR_CanIfTxConfirmation() SWS CanIf p. 157. Dans R20-11, <User_TxConfirmation> fait foi.

Diagramme de séquence : Lorsque le matériel est occupé, la L-PDU est mise en mémoire tampon. La confirmation d'une demande antérieure déclenche ensuite l'émission différée depuis le tampon. Sources : [SWS_CANIF_00381], [SWS_CANIF_00386], [SWS_CANIF_00668], [SWS_CANIF_00183], SWS CanIf p. 138, SWS CanIf p. 143

Lors d'une Triggered Transmission, l'utilisateur ne transmet pas de données, mais un SduDataPtr NULL [SWS_CANIF_00882]. Si le matériel est libre, le pilote récupère les données via CanIf_TriggerTransmit() [SWS_CANIF_00883]. CanIf transmet l'appel à <User_TriggerTransmit> et renvoie son résultat [SWS_CANIF_00885]. Si le matériel est occupé, CanIf ne met en mémoire tampon que la Transmit Request [SWS_CANIF_00881]. Le CanId des L-PDU dynamiques peut être modifié avec CanIf_SetDynamicTxId() [SWS_CANIF_00189]. Alternativement, il provient des MetaData [SWS_CANIF_00855] SWS CanIf p. 34.

Diagramme de séquence : Avec Trigger Transmit, le pilote ne récupère les données auprès de l'utilisateur que lorsque l'objet matériel est libre. Sources : [SWS_CANIF_00882], [SWS_CANIF_00885], [SWS_CANIF_00881], SWS CanIf Fig. 9.6 p. 137

Voie de réception : filtrer, vérifier la longueur, transmettre

Après une réception, le pilote appelle CanIf_RxIndication() avec Mailbox et les données [SWS_CANIF_00006]. Le traitement se déroule en trois étapes :

• Filtrage logiciel : Pour les HRH BasicCAN, CanIf filtre par logiciel [SWS_CANIF_00663] SWS CanIf p. 39. Un rejet met fin au traitement [SWS_CANIF_00389].
• Vérification de longueur : Elle suit, si configurée [SWS_CANIF_00390], et accepte au moins la longueur configurée [SWS_CANIF_00026].
• Transmission : Les L-PDU acceptées vont vers le <User_RxIndication> configuré [SWS_CANIF_00056] [SWS_CANIF_00135]. Pour les L-SDU dynamiques, le CanId aboutit dans CAN_ID_32 [SWS_CANIF_00848].

Diagramme d'activités : Le filtrage logiciel et la vérification de longueur décident si une L-PDU reçue est indiquée. Les effets secondaires dépendants de la configuration sont représentés en parallèle. Sources : [SWS_CANIF_00421], [SWS_CANIF_00389], [SWS_CANIF_00168], [SWS_CANIF_00199], [SWS_CANIF_00392], SWS CanIf Fig. 7.6 p. 51

De manière complémentaire, CanIf propose des services d'interrogation. CanIf_ReadRxPduData() lit des données depuis son propre tampon de réception [SWS_CANIF_00194] [SWS_CANIF_00198], mais n'est pas conçu pour la réception par plage [SWS_CANIF_00329]. CanIf_ReadTxNotifStatus() et CanIf_ReadRxNotifStatus() réinitialisent l'état lors de la lecture [SWS_CANIF_00393] [SWS_CANIF_00394]. Ce « read-and-consume » garantit qu'au moins un événement est survenu depuis le dernier appel SWS CanIf p. 55. CanIf_GetTxConfirmationState() regroupe les confirmations de tout un contrôleur [SWS_CANIF_00734].

Transceiver, réveil et Partial Networking

CanIf transmet les services de transceiver directement au pilote CanTrcv. CanIf_SetTrcvMode() appelle CanTrcv_SetOpMode() [SWS_CANIF_00358], CanIf_GetTrcvMode() appelle CanTrcv_GetOpMode() [SWS_CANIF_00363]. CanIf transmet les changements de mode du transceiver à CanSm [SWS_CANIF_00712].

Pour le réveil, CanIf_CheckWakeup() interroge les contrôleurs et les transceivers sur la source de réveil [SWS_CANIF_00395] SWS CanIf p. 56. Pour la validation, CanIf enregistre la première réception valide d'un contrôleur démarré [SWS_CANIF_00286]. CanIf_CheckValidation() la signale ensuite via <User_ValidateWakeupEvent> [SWS_CANIF_00179].

Si le Partial Networking est actif, un PnTxFilter applique une couche supplémentaire sur les modes de canal par contrôleur [SWS_CANIF_00747]. Il est activé lors de CAN_CS_SLEEP [SWS_CANIF_00749] et désactivé à nouveau avec la première confirmation ou indication [SWS_CANIF_00751] [SWS_CANIF_00896] SWS CanIf p. 70.

Comportement en cas d'erreur

BusOff : Le pilote signale l'erreur avec CanIf_ControllerBusOff() [SWS_CANIF_00218]. CanIf fait alors passer le canal à CANIF_TX_OFFLINE [SWS_CANIF_00866] et signale le BusOff à CanSm [SWS_CANIF_00724] SWS CanIf Fig. 9.11 p. 147. CanSm pilote le rétablissement via CanIf_SetControllerMode() SWS CanIf p. 160.

Diagramme de séquence : Déroulement depuis la détection du BusOff jusqu'au redémarrage du contrôleur en passant par la notification à CanSm. Sources : [SWS_CANIF_00218], [SWS_CANIF_00866], [SWS_CANIF_00724], [SWS_CANIF_00918], SWS CanIf p. 154, SWS CanIf p. 160

Contrôleur arrêté : Lors de l'entrée dans CAN_CS_STOPPED, CanIf vide les tampons d'émission [SWS_CANIF_00485]. Il confirme toutes les demandes d'émission en attente avec E_NOT_OK [SWS_CANIF_00739]. Ainsi, chaque PDU acceptée reçoit une confirmation, positive ou négative SWS CanIf p. 54.

Notifications d'erreurs : CanIf signale les paramètres invalides comme erreurs de développement, par ex. CANIF_E_PARAM_CONTROLLERID [SWS_CANIF_00311] [SWS_CANIF_91006]. Les erreurs d'exécution comprennent notamment CANIF_E_INVALID_DATA_LENGTH [SWS_CANIF_00168] et CANIF_E_STOPPED [SWS_CANIF_00382] [SWS_CANIF_91007]. Une demande d'émission perdue ne se manifeste que par la valeur de retour ou par l'absence de confirmation Error Description p. 22. CanIf signale les événements de sécurité tels que CANIF_SEV_ERRORSTATE_PASSIVE à l'IdsM [SWS_CANIF_00913] [SWS_CANIF_00917].

Preuves détaillées supplémentaires

• Initialisation et cycle de vie : [SWS_CANIF_00001], [SWS_CANIF_00661], SWS CanIf p. 40
• Voie d'émission et mise en mémoire tampon : [SWS_CANIF_00318], [SWS_CANIF_00836], SWS CanIf p. 46
• Chaîne de réception : [SWS_CANIF_00415], SWS CanIf p. 50
• Callbacks configurables : [SWS_CANIF_00532], SWS CanIf p. 133