Aller au contenu
AESTECHNO

18 min de lecture Hugues Orgitello

Bus CAN, CAN-FD et CAN-XL : guide d'intégration industrielle

Bus CAN, CAN-FD et CAN-XL pour systèmes industriels : architecture, débits jusqu'à 20 Mbit/s, transceivers, intégration STM32, J1939, UDS. AESTECHNO Montpellier.

Le bus CAN (Controller Area Network), normalisé par ISO 11898 dès 1986 chez Bosch, reste en 2026 le bus de communication industrielle le plus déployé sur la planète. Les évolutions CAN-FD (Flexible Data-rate, jusqu'à 5 Mbit/s) et CAN-XL (jusqu'à 20 Mbit/s) prolongent sa pertinence là où Ethernet reste trop coûteux ou trop énergivore : véhicules, machines agricoles, robotique, automatisme industriel, équipements médicaux mobiles.

Chez AESTECHNO, bureau d'études électronique basé à Montpellier, nous concevons des systèmes embarqués intégrant des bus CAN depuis plus de dix ans, sur microcontrôleurs STM32 (notamment STM32G4 et STM32H7 avec leur périphérique FDCAN intégré), nRF52, ESP32 et plateformes industrielles à base de Xilinx. Cet article couvre l'architecture électrique, les trois variantes du protocole, le choix des transceivers, l'intégration logicielle (CANopen, J1939, UDS) et nos retours terrain sur les pièges les plus fréquents en production.

Projet CAN ou migration CAN-FD / CAN-XL ? Audit gratuit 30 min

Saturation d'un bus CAN classique, montée en débit nécessaire, intégration UDS ou J1939, conformité automobile ou ISO 11898 ? Nos ingénieurs accompagnent vos projets industriels et embarqués :

  • Architecture matérielle : choix transceiver, terminaison, protection ESD
  • Intégration STM32 (FDCAN), nRF52, ESP32 ou plateformes Linux embarqué
  • Pile logicielle : CANopen (CiA 301), J1939, UDS / ISO-TP, autosar
  • Validation et conformité : mesure d'eye diagram, conformité IEC 61000-4 ESD/burst

Réserver un créneau

En résumé

  • CAN classique (ISO 11898-2:2016) plafonne à 1 Mbit/s sur 40 m, payload 8 octets, idéal pour les capteurs et actionneurs simples.
  • CAN-FD bascule en mode haute vitesse pendant la phase de données : jusqu'à 5 Mbit/s, payload 64 octets, et reste rétrocompatible matériellement.
  • CAN-XL (à partir de 2023) atteint 20 Mbit/s et 2048 octets de payload, mais exige un transceiver SIC (Signal Improvement Capability) dédié.
  • Terminaison 120 Ω aux deux extrémités du bus, paire torsadée, charge bus typiquement maintenue sous 70 % pour préserver la latence.
  • Sur STM32, les périphériques FDCAN (STM32G4, H7, U5) gèrent CAN classique et CAN-FD nativement ; CAN-XL passe par un contrôleur externe en 2026.
  • Couches protocolaires courantes : CANopen (industrie), J1939 (poids lourds, agricole), UDS / ISO-TP (diagnostic automobile).

Sommaire

CAN : historique et positionnement industriel

Le bus CAN est un protocole série différentiel multi-maître à arbitrage non destructif, conçu en 1983 par Bosch pour réduire le poids et la complexité du câblage automobile. Son architecture sans nœud maître unique, son arbitrage par identifiant prioritaire et sa tolérance aux fautes en font un standard incontournable hors automobile dès les années 1990.

La spécification CAN 2.0 (1991) sépare CAN 2.0A (identifiants 11 bits) de CAN 2.0B (identifiants étendus 29 bits). La normalisation ISO 11898-1 fige la couche liaison en 1993, ISO 11898-2 la couche physique haute vitesse, et ISO 11898-3 la variante basse vitesse tolérante aux fautes. CAN-FD a été publié par Bosch (2012) puis intégré à ISO 11898-1:2015. CAN-XL est défini dans ISO 11898-1:2024 et arrive en production sur des transceivers SIC commerciaux à partir de fin 2023.

Face à UART / RS-485, CAN apporte l'arbitrage matériel et la détection d'erreur multicouche. Face à Ethernet industriel (ProfiNet, EtherCAT, OPC UA over TSN), CAN reste plus économique en consommation, plus simple à câbler (deux fils) et plus tolérant aux environnements bruités. Face à I²C ou SPI, CAN gagne sur les distances longues (40 m à 1 Mbit/s, 1000 m à 50 kbit/s) et l'immunité aux perturbations électromagnétiques. C'est cette combinaison robustesse, distance, coût qui maintient sa pertinence en 2026 sur les véhicules autonomes, les robots collaboratifs, les machines agricoles connectées et les équipements médicaux mobiles.

Architecture électrique : CAN-H, CAN-L, terminaison 120 Ω

L'architecture électrique du bus CAN est définie par deux fils différentiels (CAN-H et CAN-L) terminés par une résistance de 120 Ω à chaque extrémité. Cette terminaison adapte l'impédance de la ligne à celle de la paire torsadée typique (impédance caractéristique 120 Ω à 1 MHz), évite les réflexions et conditionne les marges de timing. Chaque émetteur voit ainsi une charge équivalente de 60 Ω.

Sur un bus CAN haute vitesse conforme ISO 11898-2, l'état dominant correspond à CAN-H tirée vers 3,5 V et CAN-L tirée vers 1,5 V (différence de 2 V). L'état récessif laisse les deux fils à environ 2,5 V (différence proche de zéro). Cette logique câblée donne la priorité automatique au nœud émettant un identifiant numériquement plus bas pendant la phase d'arbitrage, sans collision destructrice.

Dans notre pratique, les défauts les plus fréquents en production proviennent de trois erreurs : terminaison absente ou mal placée (un seul 120 Ω, ou deux mais positionnés au milieu du bus), section ou couplage inadapté du câble (une paire torsadée non blindée passe à 1 Mbit/s, mais une paire blindée s'impose au-delà de 500 kbit/s en environnement industriel), et oubli de la masse de référence entre nœuds éloignés (un offset de masse au-delà de ±2 V, fréquent sur des châssis non équipotentiels, fait sortir le transceiver de sa plage de mode commun). Pour les projets industriels exposés à la CEM, nous appliquons systématiquement IEC 61000-4-2 (ESD ±8 kV contact / ±15 kV air) et IEC 61000-4-4 (burst), avec des transceivers prévus pour ces niveaux.

Trame CAN classique vs CAN-FD vs CAN-XL

Une trame CAN est une suite de champs binaires délimitée par un Start of Frame (SOF) et un End of Frame (EOF), encodée en NRZ avec bit stuffing. La trame transporte un identifiant (11 ou 29 bits), un champ de contrôle indiquant la longueur du payload, le payload lui-même, un CRC de protection et un acquittement par les nœuds receveurs. La structure varie selon le protocole employé.

Champ CAN classique CAN-FD CAN-XL
Identifiant 11 ou 29 bits 11 ou 29 bits 11 ou 29 bits + Priority ID
Payload 0 à 8 octets 0 à 64 octets 1 à 2048 octets
Débit max (arbitrage) 1 Mbit/s 1 Mbit/s 1 Mbit/s
Débit max (données) 1 Mbit/s 5 Mbit/s (parfois 8 Mbit/s) 20 Mbit/s
CRC 15 bits 17 ou 21 bits 32 bits
Année 1991 (ISO 11898) 2012 (Bosch), 2015 (ISO) 2024 (ISO 11898-1)

La rétrocompatibilité est asymétrique. Un nœud CAN-FD comprend les trames CAN classiques sans surcoût matériel ; un nœud CAN classique placé sur un bus CAN-FD provoquera une erreur dès qu'il rencontrera une trame en mode haute vitesse. CAN-XL exige un transceiver SIC dédié, mais les contrôleurs CAN-XL gèrent encore les trames CAN classique et CAN-FD pour la cohabitation pendant la transition.

Débit et payload : du 1 Mbit/s au 20 Mbit/s

Le débit utile d'un bus CAN dépend du protocole, de la longueur du segment et du taux d'occupation toléré pour préserver la latence. En CAN classique, le débit maximal nominal de 1 Mbit/s impose un câble inférieur à 40 m ; à 250 kbit/s on monte à 250 m, à 50 kbit/s on atteint le kilomètre. En CAN-FD, la phase d'arbitrage reste à 1 Mbit/s, mais la phase de données monte à 5 Mbit/s, parfois 8 Mbit/s avec des transceivers SIC. CAN-XL atteint 20 Mbit/s sur la phase de données.

Le débit utile réel reste très inférieur au débit nominal à cause de l'overhead protocolaire (SOF, identifiant, CRC, ACK, EOF, espacement inter-trames) et du bit stuffing. Pour une trame CAN classique de 8 octets de payload, l'overhead atteint typiquement 50 % : 64 bits de données pour 130 bits transmis. CAN-FD améliore le ratio sur les payloads de 64 octets (overhead autour de 20 %), et CAN-XL sur 2048 octets se rapproche d'un overhead inférieur à 5 %.

La règle de bus loading que nous appliquons sur nos projets industriels limite l'occupation moyenne du bus à 70 % du débit nominal. Au-delà, la latence des trames basse priorité explose et le déterminisme se dégrade. Sur un bus CANopen typique à 500 kbit/s avec 30 nœuds émettant chacun deux PDO périodiques, nous avons constaté qu'au-dessus de 80 % de charge, certaines trames non urgentes étaient retardées de plusieurs cycles complets, ce qui invalide les marges de timing prévues par le cahier des charges.

Transceivers et choix des composants

Le transceiver CAN est l'interface qui convertit les niveaux logiques du contrôleur (TXD / RXD à 3,3 V ou 5 V) en signaux différentiels CAN-H / CAN-L. Il gère également les protections ESD et les modes basse consommation. Le choix dépend du débit cible, du niveau de protection ESD, de la tolérance aux fautes et des modes de veille requis.

Pour CAN classique haute vitesse à 1 Mbit/s, les transceivers de référence restent les NXP TJA1042 et TJA1043, et leurs équivalents Texas Instruments TCAN334 et TCAN1042. Pour CAN-FD jusqu'à 5 Mbit/s, le TJA1463 (NXP), TCAN1043 (TI) et MCP2542FD (Microchip) sont les plus déployés. Pour CAN-XL à 20 Mbit/s, les premiers transceivers SIC commerciaux sont le NXP TJA1463XL et la nouvelle famille TI TCAN4x5x. Selon NXP, la migration TJA1042 vers TJA1463 reste pin-compatible sur la plupart des designs existants, ce qui simplifie les évolutions de gamme. Selon Texas Instruments, le TCAN1043 conserve une compatibilité fonctionnelle avec le TCAN1042 mais demande une revue du timing en phase de données pour les bus dépassant 2 Mbit/s.

Trois critères pèsent fortement sur la sélection en environnement industriel. La protection ESD intégrée doit couvrir IEC 61000-4-2 niveau 4 (±8 kV contact, ±15 kV air) sans diode TVS externe pour limiter la BOM ; les transceivers TJA1042T/3 et TCAN1042 atteignent ce niveau nativement. La tension d'alimentation et le standby current importent pour les projets sur batterie : sur certains de nos produits IoT industriels, nous avons retenu le TCAN1043 pour son courant de veille inférieur à 10 µA, ce qui prolonge l'autonomie batterie de plusieurs mois sur un cycle de duty cycle court. Enfin la disponibilité long terme et la robustesse anti-NRND : nous privilégions systématiquement les références non-NRND avec alternative seconde source identifiée dès la phase de cahier des charges, conformément à notre méthodologie face aux pénuries de composants.

Intégration sur STM32 : périphérique FDCAN

Le périphérique FDCAN est l'unité matérielle dédiée à la gestion CAN sur les microcontrôleurs STM32G4, STM32H7 et STM32U5. Il supporte nativement CAN classique et CAN-FD jusqu'à 5 Mbit/s sans contrôleur externe. La configuration s'effectue via la HAL ou directement les registres, et l'architecture mémoire (Message RAM) demande une attention particulière au moment du portage depuis un STM32 plus ancien équipé de bxCAN.

Le calcul du bit timing reste l'étape la plus délicate. Pour un bus à 500 kbit/s sur un STM32G4 à 170 MHz, nous configurons typiquement un prescaler de 17 avec un Time Quantum de 100 ns, 16 quanta par bit (Sync Segment 1, Phase Segment 1 = 11, Phase Segment 2 = 4) et un Sample Point à 75 %. L'outil STM32CubeMX propose un assistant de bit timing depuis la version 6.10 qui couvre 95 % des cas, mais nous validons systématiquement la configuration au laboratoire avant la première fabrication. Sur CAN-FD à 5 Mbit/s phase de données, le Sample Point typique passe à 80 % et le Synchronization Jump Width est ajusté en conséquence.

Côté Message RAM, le périphérique FDCAN expose une mémoire partagée allouée par le développeur entre les boîtes de filtrage standards et étendues, les FIFO de réception RX0 et RX1, les buffers Tx Event et les buffers Tx dédiés. Une erreur fréquente sur les portages STM32G4 que nous avons accompagnés consistait à laisser la configuration par défaut, qui plafonne la file de réception à 16 trames : sous rafale d'événements industriels, la perte de trames apparaît silencieuse jusqu'à ce qu'une mesure de bus loading la révèle. Nous redimensionnons systématiquement les FIFO à 32 ou 64 trames selon le profil applicatif.

Couches protocolaires : CANopen, J1939, UDS, ISO-TP

Le protocole CAN décrit uniquement la couche liaison de données (couches 1 et 2 du modèle OSI). Les couches supérieures dépendent du domaine applicatif et structurent l'usage du bus en réseau cohérent : CANopen pour l'automatisation industrielle, J1939 pour les véhicules lourds, UDS sur ISO-TP pour le diagnostic automobile.

CANopen, normalisé par CAN in Automation (CiA) via la spécification CiA 301, structure un réseau industriel autour d'un Object Dictionary, de Process Data Objects (PDO) pour les échanges cycliques temps réel et de Service Data Objects (SDO) pour la configuration. Les fichiers EDS (Electronic Data Sheet) décrivent chaque équipement de façon standardisée, ce qui simplifie l'intégration multi-fournisseur. Nous l'utilisons couramment sur les projets robotique et automatisme machine.

J1939, défini par la SAE, sert de standard pour les poids lourds, les bus, les machines agricoles et les engins de chantier. Il fixe un débit à 250 kbit/s (ou 500 kbit/s en J1939-14), structure le réseau autour de Parameter Group Numbers (PGN) et impose un schéma d'adressage des Electronic Control Units (ECU). La complexité réside dans la conformité aux PGN normalisés, particulièrement quand le système doit dialoguer avec des ECU tiers déjà certifiés.

UDS (Unified Diagnostic Services, ISO 14229) couvre les services de diagnostic automobile : lecture de DTC (Diagnostic Trouble Codes), reprogrammation flash, contrôle d'actionneurs en mode service, lecture d'identifiants. UDS s'appuie sur ISO-TP (ISO 15765-2) pour transporter des messages plus longs que les 8 octets natifs du CAN classique, via un mécanisme de segmentation et d'acquittement. Sur nos projets de calculateurs embarqués, nous implémentons typiquement UDS sur ISO-TP au-dessus de CAN-FD, ce qui permet de transporter les messages diagnostic long format dans une seule trame CAN-FD au lieu de plusieurs segments ISO-TP.

Validation, mesure et test de conformité

La validation d'une conception CAN consiste en trois plans complémentaires : couche physique (intégrité du signal, terminaison, immunité), couche protocolaire (conformité ISO 11898, gestion des erreurs) et couche applicative (CANopen, J1939 ou UDS selon le cas). Chaque plan exige un outillage différent et nous le traitons en série dans nos campagnes de tests DVT.

Pour la couche physique, nous mesurons les eye diagrams CAN-H et CAN-L au laboratoire avec notre oscilloscope Tektronix équipé du décodage série CAN-FD, ce qui permet de vérifier les marges de timing, la synchronisation et l'absence de réflexions parasites sur les phases haute vitesse. Sur un signal CAN-FD à 5 Mbit/s, l'ouverture verticale doit dépasser 1,5 V différentiel et l'ouverture horizontale 0,6 UI pour conserver une marge confortable face à la dispersion de production. Pour les tests de conformité réglementaire ESD et burst, nous appliquons les exigences IEC 61000-4-2 et IEC 61000-4-4 en pré-conformité interne avant le passage en laboratoire accrédité.

Selon Bosch, qui maintient la spécification de référence du protocole, le timing bit configurable distingue CAN-FD de la version classique. Dans notre pratique, nous avons mesuré sur un projet récent qu'un Sample Point fixé à 80 % en phase de données améliore la marge de synchronisation d'environ 15 % par rapport au réglage par défaut de 75 %. À l'inverse de l'idée qu'un Sample Point élevé serait toujours préférable, nous avons constaté qu'au-delà de 85 %, les nœuds esclaves perdent de la latitude pour resynchroniser face au jitter. Selon CAN in Automation, la valeur recommandée pour un bus CANopen typique reste comprise entre 75 % et 80 % en phase de données. Le protocole de mesure que nous appliquons systématiquement combine eye diagram, mesure de jitter total et capture des frames d'erreur via le port d'analyse logique du même Tektronix, ce qui donne un retour terrain corrélé sur trois plans en une seule passe.

Pour la couche protocolaire et applicative, nous utilisons PEAK PCAN-USB FD ou Kvaser en interface terrain, avec les outils Vector CANalyzer ou BUSMASTER (open source) pour la capture, le décodage et la simulation. Sur les projets soumis à conformité automotive ou industrielle stricte, nous complétons par les outils CiA Conformance Test Tool (CANopen) ou les test suites SAE J1939.

CAN-XL en 2026 : ce qui change

CAN-XL, normalisé par ISO 11898-1:2024, vise à combler l'écart entre CAN-FD (5 Mbit/s, 64 octets) et l'Ethernet industriel (100 Mbit/s, paquets de 1500 octets). Avec ses 20 Mbit/s nominaux et ses 2048 octets de payload, CAN-XL ouvre des cas d'usage qui étaient hors de portée du CAN-FD : transport de paquets IP encapsulés, agrégation de capteurs haute cadence, mise à jour OTA en mode bloc, télémétrie à granularité fine.

Le changement majeur côté hardware est l'introduction du transceiver SIC (Signal Improvement Capability), qui ajoute une fonction de mise en forme active pendant la phase de données pour maintenir l'intégrité du signal aux 20 Mbit/s. Le câblage reste identique au CAN-FD (paire torsadée, terminaison 120 Ω), mais la longueur de bus exploitable se réduit en proportion du débit. La rétrocompatibilité descendante avec CAN-FD est conservée, donc une migration progressive d'un parc CAN-FD vers CAN-XL reste possible sans rupture totale du réseau existant.

Pour les projets en démarrage en 2026, nous recommandons CAN-FD comme base par défaut sur les nouveaux designs, avec un transceiver compatible SIC quand le profil applicatif laisse entrevoir une évolution CAN-XL à moyen terme. Le surcoût d'un transceiver SIC reste limité (quelques dizaines de centimes par nœud en volume) et offre une trajectoire d'évolution sans re-design hardware.

FAQ : Bus CAN, CAN-FD et CAN-XL

Quelle est la différence pratique entre CAN classique et CAN-FD ?
CAN-FD double l'identifiant en mode étendu et permet jusqu'à 64 octets de payload contre 8 en CAN classique, avec un débit en phase de données qui monte de 1 à 5 Mbit/s. La phase d'arbitrage reste à 1 Mbit/s pour préserver l'arbitrage non destructif. Pour la majorité des applications industrielles, CAN-FD divise par 5 à 10 le nombre de trames nécessaires pour transporter le même volume de données, ce qui réduit la charge bus et la latence des messages prioritaires.

Faut-il systématiquement deux résistances de terminaison de 120 Ω sur un bus CAN ?
Oui, une à chaque extrémité physique du segment, jamais au milieu. Les deux résistances en parallèle vues par chaque émetteur donnent 60 Ω, ce qui correspond à l'impédance caractéristique de la paire torsadée standard. Une seule résistance ou des résistances mal placées génèrent des réflexions qui dégradent l'eye diagram et provoquent des erreurs de bit, même à des débits modérés de 250 ou 500 kbit/s.

Peut-on faire cohabiter CAN classique et CAN-FD sur le même bus physique ?
Non, sauf à passer par un mode de fonctionnement dégradé qui inhibe le mode haute vitesse de CAN-FD. Un nœud CAN classique placé sur un bus CAN-FD générera systématiquement une erreur dès qu'il rencontrera une trame en phase de données rapide, ce qui pollue la statistique d'erreur et peut faire passer le bus en bus-off. La règle pragmatique est de migrer tous les nœuds simultanément, ou d'isoler les sous-réseaux par des passerelles.

Quel STM32 choisir pour démarrer un projet CAN-FD ?
Pour la plupart des projets industriels en 2026, nous recommandons la famille STM32G4 (Cortex-M4 à 170 MHz) qui intègre jusqu'à trois canaux FDCAN, dispose d'une analogie riche pour les capteurs et reste maîtrisée en BOM. Pour les besoins de calcul plus lourds ou les passerelles multi-bus, STM32H7 (Cortex-M7 à 480 MHz) ou STM32U5 (Cortex-M33 basse consommation) sont des alternatives pertinentes. Le périphérique FDCAN est identique sur ces trois familles, ce qui facilite le portage applicatif.

CAN-XL est-il prêt pour la production industrielle en 2026 ?
La spécification ISO 11898-1:2024 est stable et plusieurs transceivers SIC sont disponibles en volume. La maturité de l'écosystème logiciel (drivers, stack protocolaire CANopen-XL et J1939-XL) reste plus hétérogène. Pour un projet livrable en 2026 sur le segment automatisme industriel, CAN-FD reste le choix prudent ; CAN-XL devient pertinent quand le profil applicatif demande des paquets de plus de 64 octets ou quand le coût d'Ethernet TSN est prohibitif. Nous accompagnons les choix architecturaux au cas par cas.

Quelle est la longueur maximale d'un bus CAN-FD à 5 Mbit/s ?
À 5 Mbit/s en phase de données, la longueur exploitable se situe typiquement entre 10 et 20 m sur paire torsadée standard, selon la qualité du câble et le nombre de nœuds. À 2 Mbit/s on monte à 30-40 m, et à 1 Mbit/s on retrouve les 40 m du CAN classique. La règle simple est que le débit utilisable décroît à mesure que la longueur augmente, à cause du temps de propagation aller-retour qui doit rester compatible avec la fenêtre d'arbitrage.

Pourquoi choisir AESTECHNO pour votre projet CAN ?

  • 10+ ans d'expertise en bus CAN, CAN-FD et CAN-XL sur projets industriels
  • 100% de réussite aux certifications CE/FCC
  • 65 projets réalisés à ce jour
  • Bureau d'études français basé à Montpellier (Occitanie)
  • Maîtrise pile complète : du choix transceiver jusqu'à CANopen, J1939 et UDS / ISO-TP
  • Méthodologie EVT/DVT/PVT avec mesure d'eye diagram en interne et pré-conformité IEC 61000-4