UDP Multicast pour le CAN-over-Ethernet : une mise en réseau évolutive au-delà des limites physiques
Les données CAN peuvent être tunnelisées efficacement sur Ethernet à l'aide d'UDP Multicast, préservant les caractéristiques du CAN tout en s'affranchissant de ses limites physiques et logiques.
Les limites des réseaux CAN classiques
Le CAN CC est conçu pour une communication robuste et temps réel, mais il reste borné par des contraintes physiques et logiques. Quand le débit augmente, la longueur de bus admissible diminue, du fait des délais de propagation et de l'intégrité du signal : à 1 Mbit/s, la limite typique est d'environ 40 mètres. Dans les grands déploiements — des dizaines de nœuds, par exemple 64 équipements — ces contraintes deviennent critiques. Un bus physique unique dépasserait non seulement la longueur admissible, mais introduirait aussi des conflits d'arbitrage si plusieurs équipements émettaient simultanément des identifiants identiques.
Autre défi : l'espace d'identifiants restreint. Tous les nœuds partagent le même espace de noms d'ID. Si plusieurs équipements utilisent des identifiants CAN identiques, des conflits d'arbitrage ou de mauvaises interprétations surviennent — particulièrement problématique avec des ID figés ou codés en dur. Enfin, la charge système croît avec le trafic : chaque trame CAN génère une interruption, ce qui peut fortement solliciter le CPU à haut débit de messages.
| Caractéristique | CAN standard | Solution CAN-over-UDP |
|---|---|---|
| Distance max | ~40 m à 1 Mbit/s | Quasi illimitée (fibre / Ethernet) |
| Nombre de nœuds | Limité par la charge physique | Évolutif (64+ nœuds) |
| Gestion des ID | Doivent être uniques sur le bus | Duplication possible (mappage via IP) |
| Charge CPU | Élevée (1 interruption par trame) | Faible (trames groupées en paquets UDP) |
Tableau 1 — CAN standard vs CAN-over-UDP
Le CAN-over-Ethernet comme approche architecturale
Pour dépasser ces limites, les données CAN peuvent être transportées sur Ethernet. Les trames CAN individuelles sont encapsulées dans des paquets UDP/IP et transmises via une infrastructure Ethernet standard. On crée ainsi un bus CAN virtuel affranchi des limites du bus physique. En pratique, chaque nœud CAN est relié à une passerelle CAN-Ethernet dédiée ; ces passerelles forment un système distribué connecté par un commutateur Ethernet, remplaçant le bus CAN partagé unique par une dorsale virtuelle et évolutive.
UDP comme protocole de transport
UDP est choisi délibérément. Contrairement à TCP, il est sans connexion et évite handshakes, contrôle de flux et retransmissions : d'où une latence plus faible et un comportement plus déterministe, essentiel pour une communication CAN temps réel. Autre avantage : l'efficacité de traitement. Plusieurs trames CAN peuvent être agrégées dans un seul paquet UDP, réduisant le nombre d'interruptions côté récepteur, donc la charge CPU.
Le Multicast pour répliquer la diffusion CAN
Une caractéristique du CAN est son modèle de diffusion (broadcast) : chaque message est visible de tous les nœuds. L'UDP Multicast réplique fidèlement ce comportement : un émetteur transmet un seul paquet à un groupe multicast, reçu par tous les nœuds abonnés. L'infrastructure réseau gère la distribution, allégeant l'émetteur et permettant une communication un-vers-plusieurs efficace, similaire à un bus CAN physique.
Mécanismes de scalabilité et de découplage
Élément clé : la séparation des espaces d'identifiants locaux et globaux. Les identifiants CAN réutilisés localement peuvent être rendus globalement uniques par mappage. En pratique, on intègre un identifiant d'équipement unique dans la trame transmise, ou l'on traduit les identifiants standard 11 bits en identifiants étendus 29 bits uniques pour la dorsale Ethernet. La communication reste sans collision même si tous les nœuds utilisent en interne des ID identiques, par exemple 0x100.
La distribution est par ailleurs sélective : au lieu de tout transmettre à chaque nœud, seules les trames pertinentes le sont, via des tables de filtrage et d'abonnement (« intérêt ») au sein de la passerelle. Chaque nœud ne reçoit que le sous-ensemble de messages dont il a réellement besoin. Enfin, l'agrégation de plusieurs trames CAN dans un seul paquet UDP minimise la surcharge de traitement et optimise l'usage des ressources réseau.
Préserver les caractéristiques du CAN
Il est essentiel de maintenir les propriétés clés du protocole. La priorisation des messages, déterminée par l'identifiant lors de l'arbitrage CAN, peut être mappée sur les mécanismes QoS ou les champs de priorité IP. Le comportement temporel se reconstruit grâce à des horodatages haute résolution intégrés aux paquets UDP, ce qui minimise la gigue. L'intégrité des données est assurée par une protection en couches : au CRC du CAN s'ajoute la somme de contrôle UDP lors de la transmission Ethernet.
Conclusion
La combinaison d'UDP et de Multicast permet d'étendre efficacement les réseaux CAN classiques sur Ethernet : suppression des limites physiques, scalabilité fortement améliorée et préservation des caractéristiques essentielles du CAN. Une base solide pour les architectures distribuées modernes, industrielles et automobiles. Des passerelles dédiées intègrent ces mécanismes — par exemple la passerelle Ixxat CAN@net ou le PCAN-Ethernet Gateway DR.
