Le CAN FD : le CAN à haut débit
Le bus CAN a structuré la communication automobile pendant trente ans. Il devient étroit face aux calculateurs actuels, dont les logiciels se comptent en mégaoctets. Le CAN FD est la réponse à cette limite, sans renier l'acquis du CAN.
D'où vient le CAN, et pourquoi il ne suffit plus
Le bus CAN est né chez Bosch : développement lancé en 1983, présentation publique au congrès SAE de Détroit en 1986, première voiture de série en 1991 avec la Mercedes-Benz W140, normalisation ISO 11898 en 1993. Il fait dialoguer les calculateurs sur une paire torsadée, par des trames courtes de huit octets de données au maximum, à un débit plafonné à 1 Mbit/s sur une quarantaine de mètres et jusqu'à une trentaine de nœuds. Cette robustesse a fait sa longévité, mais deux contraintes deviennent gênantes : huit octets par trame, et un débit unique pour toute la trame.
Le problème saute aux yeux dès qu'il faut transporter du volume. Une lecture ou une écriture de calculateur, ce sont des mégaoctets à faire passer huit octets à la fois. Sur un CAN classique, une reprogrammation complète se compte en longues minutes, pendant lesquelles le calculateur reste en session ouverte et la tension d'alimentation doit rester parfaitement stable.
Les deux verrous que lève le CAN FD
Le CAN FD — pour Flexible Data-rate, intégré à l'ISO 11898-1 depuis 2015 — garde le principe, le câblage, les identifiants (11 ou 29 bits) et le mécanisme d'arbitrage du CAN, mais desserre deux limites :
- La charge utile passe de 8 à 64 octets par trame. Une trame transporte huit fois plus de données pour un en-tête quasiment identique, donc bien moins de surcoût protocolaire par octet transmis.
- Le débit devient variable à l'intérieur de la trame. L'arbitrage — le moment où les calculateurs se disputent le bus — reste à la vitesse robuste et éprouvée du CAN. Une fois le maître de la trame désigné, la phase de données bascule à un débit bien supérieur, jusqu'à 8 Mbit/s : c'est le principe de commutation de débit (bit rate switch). Lent et sûr pour trancher les conflits d'accès, rapide pour transporter la donnée.
Le résultat combiné est spectaculaire : plus de données par trame, et ces données envoyées plus vite. Le même réseau, sur le même câblage à deux fils, fait passer un multiple d'informations dans le même temps. Le CAN FD embarque en outre un contrôle d'intégrité renforcé — un CRC plus long — nécessaire pour protéger des trames devenues bien plus grandes, sans lequel le gain de taille se paierait en fiabilité.
Ce que ça change pour la reprogrammation
Pour qui reprogramme, l'incidence est directe. Une écriture, c'est un transfert de plusieurs mégaoctets ; le CAN FD réduit fortement la durée de l'opération. Moins de temps en session de programmation, c'est moins d'exposition au risque d'une coupure au mauvais moment, et une batterie sous maintien de charge moins sollicitée.
Mais le CAN FD impose une compatibilité matérielle. Une interface ou un outil de type PassThru pensés uniquement pour le CAN classique ne dialoguent pas avec un calculateur qui n'expose que du CAN FD : ni l'émetteur-récepteur de ligne, ni les drivers, ni le firmware ne savent gérer la phase de données rapide. C'est un point à vérifier avant d'acquérir un outil ou d'accepter un véhicule récent — le boîtier doit annoncer explicitement le CAN FD. Beaucoup de gestions récentes, notamment les plateformes MD1 et MG1, en dépendent, et un matériel un peu ancien s'y arrête net.
En atelier, deux réflexes évitent les mauvaises surprises. D'abord, identifier le réseau avant d'intervenir : un outil correctement à jour annonce s'il communique en CAN classique ou en CAN FD avec le calculateur, et refuse proprement plutôt que de tenter une écriture qui échouera. Ensuite, maintenir la tension pendant toute l'opération, car un transfert plus rapide reste un transfert de plusieurs mégaoctets, sensible à la moindre chute. Le CAN FD accélère l'écriture ; il ne dispense d'aucune des précautions du travail en OBD, bench ou boot.
CAN FD et OBD : deux plans à ne pas confondre
Une nuance importante : le CAN FD n'est pas le CAN de la prise OBD réglementaire. Le diagnostic d'émissions normalisé (ISO 15765-4) reste cantonné au CAN classique, à 250 ou 500 kbit/s et trames de huit octets. Le CAN FD sert surtout aux communications internes du véhicule et au diagnostic constructeur en UDS, là où le volume l'exige. Au-dessus du transport, la segmentation reste assurée par l'ISO-TP (ISO 15765-2), qui reconstitue les messages plus longs qu'une trame : un VIN, une liste de codes défaut, un bloc de flash. Un même calculateur peut donc parler CAN classique pour l'OBD générique et CAN FD pour ses échanges internes et sa reprogrammation.
La place du CAN FD dans la hiérarchie des réseaux
Le CAN FD illustre la logique d'ensemble des réseaux embarqués : on garde ce qui fonctionne, on lève la contrainte devenue critique. Il s'insère entre le CAN classique, qu'il prolonge, et l'étage supérieur : quand même 64 octets à 8 Mbit/s ne suffisent plus — mises à jour massives, calculateurs à logiciel volumineux — le relais est pris par Ethernet et le DoIP. Entre ces réseaux qui ne parlent ni la même langue ni au même rythme, c'est la passerelle qui route et traduit.
Voir aussi le bus CAN, le DoIP et la passerelle.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
