Les systèmes de bus et de réseau sont des domaines complexes impliquant une variété de protocoles, d'architectures et d'algorithmes utilisés pour développer, tester et valider les communications de bus et de réseau. Découvrez tout, des concepts fondamentaux aux dernières avancées dans les technologies de bus et de réseau - de CAN et LIN à l’Ethernet automobile avec SOME/IP et DDS.
L'importance de la communication en véhicule
Les véhicules actuels sont des systèmes complexes de calculateurs interconnectés qui gèrent tout, des fonctions de base aux systèmes avancés d'aide à la conduite et de conduite autonome. Ces systèmes s'appuient sur des réseaux de communication en véhicule robustes pour échanger des données en temps réel, de manière fiable et sécurisée. Au fil des ans, les protocoles de bus ont évolué, passant de solutions simples à faible débit telles que LIN ou CAN à des technologies hautes performances telles que l’Ethernet automobile. Cette évolution est la conséquence de la demande croissante de bande passante, de sécurité et d'efficacité, d'autant plus que les véhicules sont de plus en plus définis par logiciel et dotés de nombreuses fonctionnalités.
Les architectures ont également changé : les conceptions traditionnelles basées sur les domaines cédant la place à des architectures zonales, qui réduisent la complexité du câblage et supportent les plateformes de véhicules modulaires. Ces architectures zonales constituent une évolution majeure dans la manière dont les véhicules sont conçus et fabriqués. Au lieu de répartir les calculateurs dans le véhicule ou de les regrouper par fonction, les conceptions zonales divisent le véhicule en zones physiques. Chaque zone est gérée par un contrôleur zonal, qui communique avec des unités de calcul hautes performances (HPC) qui gèrent la majeure partie de la logique logicielle du véhicule. Malgré cette consolidation au sein d'architectures zonales, les besoins de communication varient selon le type de véhicule - les véhicules électriques, les flottes commerciales et les engins tout terrain ont chacun des exigences particulières. Il est essentiel de comprendre ces protocoles et architectures pour construire des systèmes automobiles fiables et évolutifs.
CAN - L'infrastructure principale de la communication automobile embarquée
Le réseau CAN (Controller Area Network) est l'un des protocoles de communication les plus reconnus et plus largement utilisés dans l'industrie automobile. Développé à l'origine par Bosch dans les années 1980, le CAN a été conçu pour permettre une communication en temps réel robuste entre les calculateurs (ECU) sans nécessiter d'ordinateur central. Depuis, il est devenu une norme mondiale non seulement pour les véhicules de tourisme, mais aussi pour les engins hors route, les équipements agricoles, les systèmes aéronautiques et l'automatisation industrielle. Il permet l'échange de signaux de mesure et de commande et offre une grande tolérance aux pannes grâce à des mécanismes intégrés de détection et de traitement des erreurs.
La mise en œuvre physique du CAN nécessite un contrôleur CAN, un émetteur-récepteur ainsi qu'un microprocesseur. Le CAN est un protocole de communication orienté message qui utilise un système de diffusion où les messages sont identifiés par des « identifiants de message ». Les récepteurs décident d'accepter ou non un message en fonction de son identifiant. Les identifiants déterminent également la priorité des messages lors de l'arbitrage du bus à l'aide de la méthode CSMA/CR (Carrier Sense Multiple Access with Collision Resolution). Tout calculateur peut démarrer la transmission si le bus est inactif après un intervalle de trois bits. En cas de collision, c'est le message ayant la priorité la plus élevée qui « l'emporte ». La priorité est déterminée par l'identifiant du message (un nombre inférieur signifie une priorité plus élevée). Le message le plus prioritaire continue alors sans délai, tandis que les autres se retirent et réessayent une fois que le bus est libre.
Couches de protocole et variantes
Le CAN classique est défini par la norme ISO 11898. Trois normes CAN importantes définissent le bus :
- La norme ISO 11898-1 définit la couche de liaison de données conformément à la spécification originale CAN 2.0A et CAN 2.0B. Pour répondre aux nouvelles exigences en matière de bande passante, des variantes telles que CAN FD (Flexible Data Rate) ou CAN XL (eXtended Layer) étendent cette norme en augmentant la taille des charges utiles et en améliorant considérablement les débits de données.
- Les normes ISO 11898-2 (haut débit) et ISO 11898-3 (bas débit/tolérance aux pannes) couvrent la couche physique du modèle OSI. Elles prennent en charge des débits de données allant jusqu'à 1 Mbit/s (haut débit) et 125 kbit/s (bas débit).
- La norme ISO 11898-4 représente une extension de la couche de liaison de données pour la communication déterministe de messages critiques, appelée « Time Triggered CAN » (CAN à déclenchement temporel).
Contrairement à d'autres bus, la spécification originale ne couvre que les deux niveaux inférieurs du modèle ISO/OSI. Par conséquent, bien que le CAN lui-même ne définisse pas de couche d'application, plusieurs protocoles de couche supérieure sont apparus pour combler cette lacune, notamment SAE J1939 pour les véhicules utilitaires, CANopen pour l'automatisation industrielle et ISOBUS pour les applications agricoles. Les normes ISO 11898 ne spécifient aucun mécanisme de sécurité. Les mesures de protection telles que l'authentification, l'intégrité et la confidentialité sont mises en œuvre dans les couches supérieures du protocole.
Format de la trame CAN
Les messages CAN sont transmis dans des trames structurées contenant des éléments d'en-tête, de charge utile et de fin. Les deux principaux types sont les suivants :
- Format de la trame de base : Identifiant de 11 bits
- Format de trame étendue : Identifiant de 29 bits
Les trames standard (identifiants de 11 bits) et les trames étendues (identifiants de 29 bits) peuvent coexister sur le même réseau CAN. Outre les trames de données, CAN supporte également les trames d'erreur et les trames de surcharge, qui permettent de gérer l'intégrité et le timing de la communication.
Chaque message commence par un bit de début suivi de l'identifiant. Comme un message peut avoir une longueur de charge utile variable allant jusqu'à huit octets pour le CAN classique, la longueur exacte est spécifiée dans les « bits de commande ». La charge utile est ensuite suivie d'un « contrôle de redondance cyclique » pour la reconnaissance des erreurs, ainsi que d'un nombre variable de bits de remplissage à des fins de synchronisation. Enfin, tous les ECU connectés au bus donneront une confirmation positive dans les champs d'accusé de réception (ACK) et de fin de trame (EOF) ou une trame d'erreur (EF) conduira tous les destinataires à ignorer les données reçues. Cela garantit la cohérence des données au sein du réseau.
Topologie du réseau
Les réseaux CAN utilisent généralement une topologie de bus, où tous les nœuds sont connectés en parallèle à une ligne différentielle à deux fils (CAN_H et CAN_L). Le bus doit être terminé aux deux extrémités par l'impédance caractéristique de la ligne à deux fils, généralement 120 Ω. La dynamique de signal du niveau de tension différentiel est d'environ 2 V. Bien que d'autres topologies telles que l'étoile ou l'arbre soient techniquement possibles, le bus linéaire offre des performances et une intégrité de signal optimales.
LIN - Le réseau léger pour les applications sensibles aux coûts
Le LIN (Local Interconnect Network) a été introduit comme une alternative économique au CAN, spécialement conçu pour les applications qui ne nécessitent pas une grande largeur de bande ou des performances en temps réel. Il est largement utilisé dans l'industrie automobile pour commander des actionneurs et des capteurs simples, tels que les lève-vitres, les dispositifs de réglage des sièges, les systèmes de climatisation et l'éclairage intérieur. Sa simplicité et son faible coût en font un outil idéal pour ces applications non critiques.
La mise en œuvre physique utilise un bus série monofilaire dans un réseau de diffusion qui suit un modèle de communication maître-esclave, où un nœud maître commande jusqu'à 15 nœuds esclaves. Le maître initie toutes les communications en envoyant des en-têtes de message périodiques conformément à un tableau de programmation LIN défini de manière statique. Les calculateurs esclaves ne répondent que lorsqu'ils sont adressés. Cette programmation déterministe élimine le besoin de mécanismes d'arbitrage complexes. Comme dans le cas du CAN, l'identifiant LIN marque le contenu de chaque message et les récepteurs décident d'accepter ou non un message en fonction de son identifiant Le calculateur maître sert souvent de passerelle vers des réseaux de niveau supérieur tels que CAN ou Automotive Ethernet.
Couches de protocole et caractéristiques
Le LIN fonctionne au niveau des couches physique, de liaison de données et d'application du modèle ISO/OSI. Contrairement au CAN, qui nécessite un matériel plus complexe, le LIN utilise un matériel UART/SCI standard avec des trames 8N1 et un débit en bauds fixe allant jusqu'à 19,2 kbit/s. La longueur typique des bus peut atteindre 40 mètres. Développé à l'origine par le Consortium LIN, le LIN est aujourd'hui normalisé sous la norme ISO 17987. La gestion des erreurs est limitée à des mécanismes simples, tels que des bits de parité dans l'identifiant et des checksums dans le champ de données. Il n'y a pas de procédures intégrées de retransmission ou de correction. Par conséquent, la récupération des erreurs doit être gérée au niveau de l'application.
Structure de trame
Une trame LIN se compose de deux parties :
- En-tête du maître : Après que le bus a été inactif, l'ECU maître envoie une pause de synchronisation (au moins 13 bits dominants suivis d'un bit récessif). Cette séquence de bits est le seul caractère qui n'est pas conforme à la norme UART et qui peut donc être clairement identifié comme le début d'un message par n'importe quel récepteur. Elle est suivie d'un octet de synchronisation utilisé pour la synchronisation du cycle d'horloge du récepteur et de l'identifiant LIN, qui détermine le message de données que les esclaves doivent utiliser pour répondre.
- Réponse de l'esclave : Un seul calculateur esclave répond avec 2 à 8 octets de données et un octet de checksum. LIN supporte deux types de checksum : Classique (données uniquement) et Amélioré (données + identifiant).
LIN supporte plusieurs types de trames, notamment :
- Trames inconditionnelles : Elles sont utilisées pour l'échange standard de données tel que décrit ci-dessus.
- Trames déclenchées sur événement : Elles sont utilisées pour les mises à jour asynchrones et permettent à plusieurs calculateurs esclaves de répondre au même message. Dans la pratique, seuls les calculateurs pour lesquels la valeur demandée a changé répondront. Si plusieurs esclaves répondent simultanément, des collisions peuvent se produire, que LIN ne peut pas résoudre. Par conséquent, chaque calculateur doit également disposer d'un identifiant unique pour le même message.
- Trames sporadiques : Elles permettent à plusieurs messages de partager le même créneau horaire, les priorités statiques déterminant le message à envoyer.
- Trames de diagnostic et trames définies par l'utilisateur : Pour la configuration et les fonctions spéciales.
- Cette flexibilité permet à LIN de gérer efficacement la communication périodique et déclenchée sur événement.
Topologie du réseau
Les réseaux LIN utilisent généralement une topologie bus ou guirlande, tous les nœuds étant connectés à un seul fil. Le nœud maître fournit le timing et la synchronisation, éliminant ainsi le besoin d'arbitrage. La terminaison est généralement réalisée par des résistances de polarisation à l’alimentation vers la tension de la batterie.
Ethernet automobile - Le réseau haut débit évolutif pour le véhicule défini par logiciel
Alors que les véhicules évoluent vers des systèmes définis par logiciel complexes, les technologies de bus traditionnelles telles que CAN et LIN atteignent leurs limites en termes de bande passante, d'évolutivité et de flexibilité. L'Ethernet automobile s'est imposé comme l’infrastructure principale de nouvelle génération pour la communication en véhicule - offrant des débits de données élevés, une communication basée sur IP et une intégration transparente avec les architectures logicielles modernes. Il active des fonctionnalités avancées telles que les mises à jour OTA (Over-The-Air), la fusion de capteurs haute résolution pour les systèmes d'assistance au conducteur (ADAS) et l'échange de données en temps réel pour la conduite autonome.
L'implémentation physique utilise un réseau Ethernet commuté qui suit une topologie point à point ou multipoint, en fonction de la norme de la couche physique. Contrairement à CAN ou LIN, la communication Ethernet est en duplex intégral et s'appuie sur des commutateurs Ethernet pour gérer le trafic et éviter les collisions. Chaque calculateur est équipé d'un contrôleur Ethernet (MAC), d'un émetteur-récepteur PHY et d'un microprocesseur. La communication est basée sur des trames Ethernet standard et l'adressage est effectué à l'aide d'adresses MAC et IP plutôt que d'identifiants de messages. Les commutateurs permettent la segmentation, l'isolation basée sur les VLAN et la qualité de service (QoS) pour le trafic à criticité mixte. Dans les architectures zonales, Ethernet sert souvent d’infrastructure principale, reliant les passerelles zonales aux calculateurs à haute performance. Ces passerelles assurent également la traduction des protocoles vers les réseaux existants tels que CAN ou LIN. Afin de garantir une communication déterministe pour les applications critiques, Ethernet permet des extensions TSN (Time-Sensitive Networking), qui assurent la synchronisation temporelle, la mise en forme du trafic et une latence limitée.
Couches de protocole et normes physiques
L'Ethernet, développé à l'origine pour les réseaux informatiques standard, a été adapté pour répondre aux exigences strictes de l'environnement automobile, telles que la compatibilité électromagnétique, la robustesse et la rentabilité. Ces adaptations ont conduit à l'élaboration de plusieurs normes spécifiques à l'automobile qui spécifient différentes couches du modèle ISO/OSI :
Couche physique |
Il existe une série de normes différentes qui spécifient la sous-couche de codage physique (PCS), l'attachement au support physique (PMA), le support physique dépendant (PMD) et l'interface dépendante du support (MDI) de l'Ethernet automobile. Ces normes s'étendent de la bande passante relativement faible à la bande passante élevée et présentent chacune des caractéristiques différentes. La couche physique utilise une combinaison de modulation d'amplitude d'impulsion, de correction d'erreur directe et d'annulation d'écho pour atteindre le débit de données requis sur des câbles de qualité automobile. Les différents PHY utilisent des techniques de plus en plus complexes. Ils spécifient la manière dont les données sont transmises sur le support physique. Les plus importantes sont les suivantes :
|
Couche liaison de données |
Tous les différents PHY combinés à l'Ethernet automobile ont généralement tendance à utiliser la couche MAC (Media Access Control) pour gérer la manière dont les dispositifs partagent l'accès au support de transmission physique et assurer une livraison fiable des données au sein d'un segment de réseau local. Ses principales fonctions consistent à encadrer les données avec les adresses MAC source et destination, à contrôler l'accès au support, à détecter les erreurs de transmission via la séquence de contrôle des trames (FCS) et à supporter le contrôle du flux pour éviter les embouteillages. La couche MAC est divisée en deux sous-couches : la sous-couche LLC (Logical Link Control), qui assure l'interface avec la couche réseau, gère l'identification du protocole, la vérification des erreurs et le contrôle du flux ; et la sous-couche MAC, qui encapsule les trames, gère l'adressage et applique les règles d'accès aux supports. |
Couche Réseau |
Elle utilise Ethernet et le protocole Internet (IP) pour permettre la communication au-delà des réseaux locaux. La transmission normalisée est assurée par des paquets IP, qui permettent l'adressage global des nœuds. Il existe deux versions IP : IPv4, qui utilise des adresses de 32 bits en notation décimale pointée et permet des plages d'adresses privées, et IPv6, développé pour surmonter les limitations d'IPv4, représentant les adresses au format hexadécimal séparées par des deux points. D'autres protocoles, tels que DHCP, supportent l’IP en attribuant automatiquement des adresses et en intégrant de nouveaux appareils dans les réseaux existants. |
Couche Transport |
La couche 4 du modèle OSI comprend deux protocoles de transport : TCP et UDP. Le TCP permet une transmission orientée connexion, tandis qu'UDP offre une approche sans connexion. Les deux protocoles divisent les données en unités plus petites, appelées segments pour le TCP et datagrammes pour l'UDP, afin d'assurer une transmission efficace. Le TCP est un protocole orienté connexion qui établit une liaison fiable entre deux nœuds à l'aide d'un établissement de liaison à trois voies et garantit la transmission de données sans erreur grâce à la retransmission et aux contrôles d'intégrité. En revanche, UDP est sans connexion, offrant une transmission simple et rapide de datagrammes sans garantie de livraison ou de correction d'erreur. Les avantages de l'UDP sont notamment une faible latence, car aucun accusé de réception n'est nécessaire, et la prise en charge de la multidiffusion et de la diffusion, ce qui le rend efficace pour l'envoi de données à de multiples récepteurs. Le TCP, cependant, ne supporte pas la multidiffusion ou la diffusion et est utilisé lorsque la fiabilité et la livraison ordonnée sont essentielles. |
Couche Session, Présentation et Application |
Les couches inférieures permettent une communication adressable et routable entre les calculateurs et les systèmes externes. Toutefois, pour que l'Ethernet soit adapté aux cas d'utilisation automobile critiques en temps réel, un middleware spécialisé est nécessaire. Ces couches de middleware permettent l'abstraction des services, la sérialisation des messages et la gestion des communications. Les exemples les plus courants sont les suivants :
Ces technologies permettent une communication orientée service, des modèles de publication-abonnement, et une distribution efficace des données - des éléments clés pour la conduite autonome, les mises à jour OTA et l'informatique centralisée. L'Ethernet automobile introduit des surfaces d'attaque basées sur IP. Les mesures de sécurité comprennent MACsec pour le chiffrement de la couche liaison de données, IPsec pour la protection de la couche réseau et TLS pour la sécurité de la couche Transport. |
Structure de trame
L'unité de base de la communication est la trame Ethernet, qui encapsule les données de charge utile et les informations de contrôle pour la transmission sur le support physique. Le paquet commence par un préambule et le délimiteur de trame de départ. Ils ont été introduits à l'origine pour aider à synchroniser les données entrantes lorsque l'Ethernet était encore utilisé en mode CSMA/CD. Les normes modernes requièrent l'utilisation d’un codage plus complexe du signal qui permet de déployer des symboles spéciaux pour détecter le début et la fin d'un paquet. Pour assurer une compatibilité descendante, les champs préambule et SFD font toujours partie de la trame. Chaque nœud Ethernet se voit attribuer un numéro de série unique de 48 bits, souvent appelé adresse MAC. Après le préambule, chaque paquet contient des informations sur la destination du paquet et sur son origine grâce à ces adresses MAC. Au départ, seule l'adresse de destination est évaluée pour déterminer si un paquet est destiné au nœud. Si l'adresse de destination du paquet correspond, le paquet est lu intégralement ; dans le cas contraire, il est ignoré. Le champ suivant indique la longueur du paquet ou l’EtherType. L’EtherType indique le type de données à attendre en ce qui concerne les couches supérieures. Ethernet ayant été conçu comme un conteneur pour tout type de données, plusieurs variantes d'Ethernet ont leur propre EtherType (par exemple, Profinet, EtherCat). La charge utile a une taille minimale de 46 octets. Si les données sont plus courtes que la charge utile minimale, les octets restants sont complétés avec du remplissage. La longueur maximale est de 1500 octets. Le paquet se termine par un contrôle de redondance cyclique (CRC) pour vérifier l'intégrité des différents bits du paquet.
Topologie du réseau
L'Ethernet automobile utilise généralement une topologie point à point, avec des commutateurs formant n'importe quel configuration de réseau viable. Les choix les plus courants sont, par exemple, un réseau en étoile ou en guirlande. Dans les architectures zonales, Ethernet peut également être utilisé dans des configurations multipoints (par exemple, avec 10BASE-T1S) pour réduire la complexité du câblage.
FlexRay - Communication déterministe pour les systèmes de sécurité critiques
Lorsque les systèmes automobiles ont commencé à exiger une plus grande fiabilité, une plus grande tolérance aux pannes et des performances en temps réel, FlexRay est apparu comme une solution robuste. Notamment dans les domaines critiques, tels que les applications X-by-Wire (X = freinage, direction, ...), où ce protocole présentait des avantages. Développé par un consortium de constructeurs et d'équipementiers automobiles de premier plan, FlexRay a été conçu pour surmonter les limites de CAN et LIN en offrant une communication haut débit déterministe, avec redondance intégrée.
L'implémentation physique consiste en un contrôleur FlexRay, un émetteur-récepteur et un microprocesseur. Un gardien de bus optionnel veille au respect de la planification des communications, empêchant les nœuds défectueux de perturber le réseau. FlexRay supporte les configurations à canal unique ou à double canal. Le second canal peut être utilisé pour la redondance dans les systèmes critiques ou pour l'agrégation de la bande passante. Le fonctionnement à double canal et le gardien de bus améliorent la fiabilité. Contrairement aux protocoles déclenchés sur événement, FlexRay utilise un système TDMA (Time Division Multiple Access) déterministe. Les droits et messages de transmission sont attribués à des créneaux horaires fixes au sein d'un cycle de communication. Le segment statique utilise des créneaux de longueur fixe pour les messages critiques, tandis que le segment dynamique utilise des mini-créneaux et un arbitrage basé sur la position pour les messages déclenchés sur événement. Cette approche hybride garantit un timing prévisible tout en offrant une certaine souplesse pour les données moins critiques.
Couches de protocole et caractéristiques
FlexRay fonctionne sur la couche physique et la couche de liaison de données du modèle ISO/OSI. Il est spécifié dans la norme ISO 17458, dont les parties 2 et 3 couvrent la liaison de données et les parties 4 et 5 la couche physique. Le protocole de transport FlexRay (FrTp) de la norme AUTOSAR couvre également la couche Transport. FlexRay supporte des débits de données allant jusqu'à 10 Mbit/s par canal. Lorsque l'on utilise les deux canaux pour l'agrégation de la bande passante, le débit de données est doublé. Le protocole assure une synchronisation temporelle globale entre tous les nœuds, organisée en cycles de communication et en macrocycles, ce qui garantit une exécution déterministe entre les calculateurs. FlexRay ne fournit pas de chiffrement ou d'authentification en mode natif. Des mesures de sécurité telles que AUTOSAR SecOC ou le filtrage au niveau de la passerelle sont nécessaires.
Structure de trame
FlexRay supporte les segments statiques (pour les messages basés sur le temps) et les segments dynamiques (pour la communication déclenchée sur événement), offrant ainsi une approche hybride qui concilie déterminisme et flexibilité. Le nombre total de slots pour les parties statique et dynamique est limité à 2047.
- Le segment statique : Utilise un nombre prédéfini de slots, chaque slot étant suffisamment long pour transporter un message FlexRay complet. Les messages contenus dans le segment statique sont synchronisés pour les deux canaux. Les droits de diffusion sont accordés à un seul calculateur à la fois afin d'éviter les collisions. Chaque calculateur compte le slot de chaque cycle de communication. Le compteur de slots indique le calculateur qui détient actuellement l'accès au bus.
- Le slot dynamique : Il utilise également des slots prédéfinis, mais il est divisé en mini-slots, qui sont plus courts que les slots du segment dynamique. Pendant ces slots, un seul calculateur est autorisé à diffuser sur chaque canal de manière indépendante. La longueur des messages peut varier (jusqu'à 254 octets), mais la longueur totale du segment dynamique est fixe. Dans ce cas, le compteur de slots indique la priorité du message. Si un message avec un compteur de slots élevé ne peut être transmis au cours d'un cycle de communication, il est reporté au cycle suivant.
Un message FlexRay commence par un en-tête. Cet en-tête est initialisé par cinq bits de commande et comprend l'ID de la trame, la longueur de la charge utile, un CRC d'en-tête désigné et le nombre de cycles. L'ID de la trame est le numéro du créneau horaire en cours. La longueur de la charge utile est transmise sous forme de nombre de mots de données de 16 bits. Le CRC de l'en-tête protège contre les erreurs de transmission et le nombre de cycle final transmet le nombre de cycles de communication que le réseau a incrémenté depuis son initialisation. Il est suivi par les données de charge utile réelles ainsi que par un CRC de fin pour la détection des erreurs de charge utile.
Topologie du réseau
Les réseaux FlexRay utilisent généralement une topologie de ligne à deux canaux où le second canal est utilisé pour augmenter la redondance dans les systèmes critiques. Des résistances de terminaison sont nécessaires aux extrémités du bus ou au niveau des calculateurs qui s'y trouvent. La distance maximale entre deux calculateurs est généralement de 24 mètres. L'utilisation d'une topologie en étoile à canal unique est possible mais peu courante.
Tableau comparatif
Critère |
CAN |
LIN |
FlexRay |
Ethernet automobile |
Objectif principal |
Communication temps réel robuste pour les calculateurs | Communication à faible coût pour des actionneurs/capteurs simples | Communication déterministe pour les systèmes de sécurité critiques | Communication haut débit évolutive pour les véhicules définis par logiciel |
Applications types |
Groupe motopropulseur, châssis, contrôle de la carrosserie, diagnostique | Fonctions de confort (vitres, climatisation, sièges) | X-by-Wire (freinage, direction), domaines de sécurité | ADAS, infodivertissement, fusion de capteurs, mises à jour OTA, infrastructure de communication principale |
Topologie |
Bus (différentiel à 2 fils) | Bus/Guirlande (fil unique) | Étoile ou ligne (possibilité d'utiliser un ou deux fils) | Point à point (étoile commutée), multipoint (10BASE-T1S) |
Déterminisme |
Déclenché sur événement (avec gestion des priorités) | Maître-esclave avec un programme statique | Basé sur le temps (TDMA, segments statiques + dynamiques) | Déterministe avec TSN (Time-Sensitive Networking) |
Largeur de bande |
Jusqu'à 1 Mbit/s (Classic) jusqu'à 8 Mbit/s (CAN FD), >10 Mbit/s (CAN XL) | Jusqu'à 19,2 kbit/s | 10 Mbit/s par canal (20 Mbit/s agrégés) | 10 Mbit/s - 10 Gbit/s (10BASE-T1S à MultiGBASE-T1) |
Charge utile |
8 octets (Classic), 64 octets (CAN FD), >64 octets (CAN XL) | 2-8 octets | Jusqu'à 254 octets | Jusqu'à 1500 octets (trame standard) |
Gestion des erreurs |
CRC, surveillance des bits, confinement des défauts | Bit de parité, checksum, pas de correction | CRC, Bus Guardian, redondance à double canal |
CRC, FEC (pour le haut débit), VLAN/QoS pour isolation du trafic |
Sécurité |
Protection de couche supérieure (par exemple, SecOC) | Pas de sécurité native | Protection de couche supérieure (par exemple, SecOC) | MACsec, IPsec, TLS ou SecOC requis |
Standardisation |
ISO 11898 | ISO 17987 | ISO 17458 | IEEE 802.3 + TSN (IEEE 802.1) |
Coût et complexité |
Faible | Très faible | Élevé | Moyen à élevé |
Perspectives futures |
Reste pertinent pour les calculateurs locaux | Reste pertinent pour les fonctions de confort | En déclin ; remplacé par Ethernet | Rôle central dans les architectures zonales |
1. Pourquoi la communication en véhicule est-elle importante ?
2. Quels sont les principaux types de protocoles de bus utilisés dans les véhicules ?
Les protocoles les plus courants sont les suivants :
- CAN (Controller Area Network) - Communication en temps réel et tolérante aux pannes pour les calculateurs.
- LIN (Local Interconnect Network) - Protocole économique pour les actionneurs et les capteurs simples.
- FlexRay - Communication haut débit déterministe pour les systèmes de sécurité critiques.
- Ethernet automobile - Réseau à large bande passante et évolutif pour les véhicules définis par logiciel.
3. Quelle est la différence entre les architectures basées sur les domaines et les architectures zonales ?
4. Comment le protocole CAN gère-t-il la priorité des messages et les collisions ?
5. Quelles sont les principales améliorations apportées aux variantes CAN telles que CAN FD et CAN XL ?
CAN FD améliore le protocole CAN traditionnel en augmentant à la fois la taille de la charge utile et le débit de données pour une transmission de données plus rapide et plus efficace. Sur cette base, le CAN XL élargit encore la bande passante disponible et est conçu pour supporter des applications plus complexes et plus exigeantes.
6. À quoi le protocole LIN est-il le mieux adapté ?
7. En quoi l'Ethernet automobile diffère-t-il des systèmes de bus traditionnels ?
L'Ethernet automobile supporte la communication en duplex intégral, l'adressage IP et les débits de données élevés (jusqu'à 10 Gbit/s). Il offre des fonctionnalités avancées telles que les mises à jour OTA et la fusion de capteurs pour les systèmes d'assistance au conducteur (ADAS) et la conduite autonome.
8. Que sont SOME/IP et DDS dans le contexte d'Ethernet ?
9. Quelles sont les mesures de sécurité utilisées dans l'Ethernet automobile ?
10. Qu'est-ce que FlexRay et où est-il utilisé ?
11. Différents protocoles de bus peuvent-ils coexister dans un véhicule ?
12. Quels sont les outils offerts par dSPACE pour le développement et les tests de communication par bus ?
dSPACE fournit une chaîne d'outils complète comprenant les éléments suivants :
- Outils de configuration de bus tels que Bus Manager, pour modéliser et manipuler la communication CAN/LIN/Ethernet/FlexRay
- SCALEXIO pour le mapping et la simulation des signaux
- SystemDesk et VEOS pour la génération et les tests des V-ECU
- Supports de formation Adaptive AUTOSAR pour la compréhension des architectures orientées services
