CAN classique vs CAN FD : comparatif en 7 points essentiels

CAN classique vs CAN FD : le CAN classique transporte jusqu’à 8 octets par trame, avec un débit maximal de 1 Mbit/s. Le CAN FD porte cette charge utile jusqu’à 64 octets et peut accélérer la phase de données grâce au BRS. Il conserve l’arbitrage du CAN, mais ses trames ne sont pas comprises par les contrôleurs CAN classiques. Pour choisir entre les deux, il faut donc examiner le volume de données, le matériel et la compatibilité du réseau, pas seulement une vitesse annoncée.

Ce comparatif concerne le CAN classique et le CAN FD, pour l’automobile, les bancs de test et l’industrie. FD signifie Flexible Data Rate : ce n’est ni le CAN FT « fault tolerant », ni le CAN XL. Pour découvrir le câblage et le décodage des messages J1939, commencez par notre guide du bus CAN et de J1939. Ici, l’objectif est de comprendre les différences et de préparer une migration sans perturber les équipements existants.

Photo à la une : carte CAN BUS Shield V2, illustration du matériel CAN sans revendication de compatibilité FD. Photo : Seeed Wiki / Wikimedia Commons, CC BY-SA 4.0. Image non modifiée, hors variantes de taille automatiques.

CAN classique vs CAN FD : 7 points essentiels à comparer

Le tableau résume les différences. Les débits désignent des débits de bits sur le bus, et non la quantité nette de données applicatives transférée par seconde.

Principales différences entre CAN classique et CAN FD

Critère	CAN classique	CAN FD
Données par trame	0 à 8 octets	0 à 64 octets
Débit nominal	Jusqu’à 1 Mbit/s	Jusqu’à 1 Mbit/s pour l’arbitrage
Phase de données	Même débit	Débit supérieur possible avec BRS
Identifiants	11 ou 29 bits	11 ou 29 bits
CRC	15 bits	17 ou 21 bits
Trames distantes RTR	Prises en charge	Pas de trame distante au format FD
Contrôleur classique	Lit les trames classiques	Ne peut pas décoder les trames FD

8 ou 64 octets : ce qui change dans les messages

Une trame CAN classique contient au maximum 8 octets de données, hors identifiant et champs de contrôle. Cette taille suffit pour de nombreux états, consignes et mesures. Quand une information dépasse cette capacité, l’application ou un protocole de transport doit la répartir sur plusieurs trames, puis la reconstituer à la réception.

Une trame CAN FD accepte jusqu’à 64 octets. Le DLC vaut directement le nombre d’octets de 0 à 8. Les valeurs DLC 9, 10, 11, 12, 13, 14 et 15 codent respectivement 12, 16, 20, 24, 32, 48 et 64 octets. Si les données applicatives n’occupent pas toute la longueur choisie, le logiciel ou le protocole supérieur doit définir le remplissage et permettre au récepteur de distinguer les données utiles.

Exemple : transmettre un bloc de mesures

Imaginons 24 octets de mesures, sans en-tête de protocole supérieur. En CAN classique, leur contenu nécessite au minimum trois trames de 8 octets. En CAN FD, il tient dans le champ de données d’une seule trame de 24 octets, avec DLC = 12. Avec un protocole de transport, il faut aussi compter ses en-têtes et ses éventuelles trames de contrôle ; le nombre réel de trames dépend donc du protocole. Le CAN FD peut simplifier la gestion des fragments, sans garantir un transfert trois fois plus rapide : les champs de protocole, le CRC, le bourrage, l’arbitrage et les débits retenus interviennent aussi.

À l’inverse, pour un état de quelques octets envoyé peu souvent, une trame plus grande n’apporte pas forcément de bénéfice. Il faut dimensionner les messages en fonction du besoin réel, pas remplir systématiquement 64 octets.

Débit CAN FD : arbitrage, phase de données et BRS

Pourquoi conserver un débit nominal ?

Le CAN utilise un arbitrage bit à bit : lorsque plusieurs nœuds commencent à émettre, les bits dominants et récessifs permettent de départager les messages sans détruire la trame gagnante. Les nœuds doivent observer le bus à temps, ce qui impose de tenir compte des délais de propagation et de la topologie. Le CAN FD conserve ce mécanisme au débit nominal.

Après l’arbitrage, un seul émetteur poursuit l’envoi de la trame. Avec BRS récessif, la bascule vers le débit de données intervient au point d’échantillonnage du bit BRS, pour Bit Rate Switch. Ce débit s’applique ensuite notamment aux données et à la séquence CRC. En transmission normale, le retour au débit nominal intervient au point d’échantillonnage du délimiteur CRC, avant l’acquittement ACK. Toute la trame ne circule donc pas au débit rapide.

Quelle vitesse peut-on réellement utiliser ?

Il n’existe pas de vitesse CAN FD universelle garantie pour tous les réseaux. Le débit réalisable dépend notamment du transceiver, des contrôleurs, des oscillateurs, de la longueur du câble, des dérivations, des connecteurs et des réglages temporels. Une valeur maximale de composant n’est pas une validation du faisceau complet.

Par exemple, une configuration de laboratoire peut choisir 500 kbit/s au nominal et 2 Mbit/s en données. Ce sont deux paramètres à configurer sur les nœuds concernés, pas une négociation automatique. Cet exemple n’est pas une recommandation applicable à tout véhicule ou machine. Sans BRS, une trame FD reste possible au débit nominal tout en conservant sa capacité de données étendue.

Pour évaluer le débit utile et la latence, ajoutez aux données les champs de protocole, les bits de bourrage, les intervalles entre trames et les retransmissions éventuelles. Une longue trame déjà commencée ne peut pas être interrompue par un message devenu prioritaire : le choix des tailles influence aussi le temps d’attente.

Compatibilité CAN FD : peut-on mélanger les équipements ?

La compatibilité fonctionne dans un seul sens pour les formats de trame : un contrôleur CAN FD sait gérer des trames classiques, mais un contrôleur uniquement classique ne sait pas recevoir des trames FD. Sur un bus commun limité aux trames classiques, des contrôleurs FD correctement configurés peuvent donc travailler avec des contrôleurs classiques.

En revanche, si des trames FD apparaissent devant un nœud classique non tolérant au FD, celui-ci peut les interpréter comme des erreurs et émettre des trames d’erreur. Le problème ne se résout pas avec un filtre logiciel sur les identifiants : la vérification du format intervient dans le contrôleur.

Une migration progressive consiste à conserver temporairement le format classique, puis à activer le FD seulement lorsque tous les nœuds exposés le permettent. Une autre solution sépare les segments classique et FD par une passerelle adaptée. Les cas de contrôleurs explicitement « FD tolerant » doivent être vérifiés dans leur documentation : tolérer une trame n’est pas savoir la décoder.

Enfin, vérifiez la variante du protocole : les premières implémentations non-ISO CAN FD ne sont pas interchangeables avec l’ISO CAN FD pour les trames FD. Privilégiez une chaîne cohérente ISO CAN FD, outils de diagnostic compris.

Identifiants et CRC : ce qui reste, ce qui évolue

Les deux formats acceptent des identifiants de 11 ou 29 bits. Passer au CAN FD ne force donc pas l’utilisation d’un identifiant étendu. L’identifiant participe à l’arbitrage et son interprétation applicative dépend du protocole supérieur ; il ne décrit pas à lui seul la signification des octets.

Le CAN classique utilise un CRC de 15 bits. En CAN FD, le CRC est de 17 bits pour les charges utiles jusqu’à 16 octets, puis de 21 bits pour celles de 20 à 64 octets. Le CAN FD utilise des bits de bourrage fixes dans le champ CRC. La version ISO ajoute notamment un compteur de bits de bourrage protégé par un bit de parité pour renforcer la détection d’erreurs ; les bits de bourrage fixes existaient déjà dans la version non-ISO.

Ce contrôle d’intégrité ne constitue ni un chiffrement ni une authentification. Il ne protège pas à lui seul contre l’injection volontaire de messages. De même, un protocole applicatif existant ne devient pas compatible FD simplement parce que son identifiant est conservé : les formats de données et les règles de communication doivent rester cohérents.

Migration vers CAN FD : les points à vérifier

1. Contrôleur : confirmer la prise en charge ISO CAN FD. Une mise à jour logicielle ne transforme pas un contrôleur uniquement classique en contrôleur FD.
2. Transceiver : contrôler son aptitude au débit visé, les délais et les tensions logiques. Remplacer seulement le transceiver ne suffit pas à changer le protocole du contrôleur.
3. Timing : configurer débit nominal, débit de données, points d’échantillonnage et tolérances d’horloge. Vérifier la compensation du délai d’émission lorsque le contrôleur et le débit retenu l’exigent.
4. Câblage et terminaison : privilégier un bus linéaire avec dérivations courtes. Sur un réseau haute vitesse à impédance nominale de 120 Ω, terminer les deux extrémités de façon adaptée, pas chaque nœud. Ne pas ajouter aveuglément de résistance sur un réseau déjà terminé.
5. Logiciel et outils : adapter buffers, DLC, pilotes, analyseur et fichiers de description des messages. Vérifier la prise en charge des grandes charges utiles.
6. Validation : tester le réseau réel sous charge, avec les longueurs, températures et perturbations prévues. Observer erreurs, pertes et latences avant déploiement.

Automobile ou industrie : lequel choisir ?

En maintenance automobile, le réseau du véhicule impose le choix. Une interface classique ne suffit pas pour décoder un segment FD ; inversement, une interface FD doit encore être configurée pour le segment observé. Travaillez d’abord sur banc, puis en écoute seule lorsque le matériel et la procédure l’autorisent. N’émettez jamais de trames expérimentales sur un véhicule en circulation.

Dans l’industrie, le CAN classique reste pertinent pour des échanges courts sur un réseau existant satisfaisant. Le CAN FD devient intéressant pour regrouper des mesures, transférer des paramètres ou accompagner une architecture nouvelle. Il faut néanmoins vérifier le protocole applicatif : CANopen et CANopen FD, par exemple, ne se confondent pas.

Pour un prototype, distinguez bien le module CAN classique à MCP2515 d’un module à contrôleur MCP2518FD compatible CAN FD. Le connecteur ou l’interface SPI ne prouve pas la compatibilité FD. Vérifiez aussi alimentation, niveaux logiques, bibliothèque et transceiver avant de choisir.

Questions fréquentes sur CAN classique et CAN FD

Le CAN FD est-il toujours plus rapide ?

Non. Le débit de données peut être supérieur avec BRS, mais le gain utile dépend de la taille des messages, du trafic et de la qualité du réseau. Sans BRS, une trame FD n’utilise pas de phase accélérée.

Un module MCP2515 peut-il lire le CAN FD ?

Non. Le MCP2515 est un contrôleur CAN classique. Pour décoder des trames FD, il faut un contrôleur compatible FD et une chaîne matérielle et logicielle adaptée.

Peut-on envoyer 8 octets en CAN FD ?

Oui. Le CAN FD n’oblige pas à transmettre 64 octets. Une trame FD de 8 octets reste toutefois une trame FD, illisible par un contrôleur classique.

Faut-il obligatoirement remplacer le câble ?

Pas systématiquement. Un faisceau existant peut convenir, mais l’augmentation du débit exige de vérifier son intégrité de signal, ses dérivations et sa terminaison. La compatibilité ne se déduit pas du câble seul.

À retenir avant de choisir

Gardez le CAN classique si ses messages courts et son débit répondent au besoin. Envisagez le CAN FD pour des données plus volumineuses, en validant tous les nœuds, le timing et le réseau physique. Chez Djenni, comparez les caractéristiques des modules selon votre protocole et votre câblage ; la bonne interface est celle qui correspond au réseau réel.

Références techniques

• CAN in Automation : principe du CAN FD — formats, BRS et charge utile.
• CAN in Automation : CRC des trames CAN — CRC 15, 17 et 21 bits, ISO et non-ISO.
• Kvaser : CAN FD Protocol Tutorial — DLC, timing et couche physique.
• Kvaser : migration et coexistence CAN / CAN FD — contraintes des contrôleurs classiques.
• Texas Instruments : introduction au CAN, transcription technique — bus différentiel et terminaison.