> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md).

# Communication intra-véhicule : CAN, FlexRay et MOST

Le CAN, FlexRay et MOST sont tous des protocoles de communication automobile utilisés pour connecter des unités de contrôle électronique (ECU), des unités de commande de transmission (TCU) et des modules de commande de carrosserie (BCM) dans les véhicules :

* **CAN**\
  Un protocole fondé sur les messages, conçu à l’origine pour économiser du cuivre en multiplexant le câblage électrique dans les voitures. Le CAN a une bande passante d’environ 125 kbit/s.
* **FlexRay**\
  Un protocole de communication série à grande vitesse, tolérant aux pannes et déterministe, capable de transférer des données à des vitesses allant jusqu’à 10 Mbit/s sur deux fils torsadés. FlexRay est souvent utilisé dans des applications critiques pour la sécurité, comme les modules de groupe motopropulseur. Les charges utiles FlexRay, ou trames de données, peuvent atteindre 127 mots (254 octets), soit plus de 30 fois plus longues que les charges utiles CAN.
* **MOST**\
  Une norme de bus pour les réseaux multimédias embarqués qui permet le transfert d’audio, de vidéo et de données de haute qualité. MOST est disponible en trois vitesses de transmission : MOST25, MOST50 et MOST150.

Le CAN (Controller Area Network) est actuellement le réseau embarqué le plus largement utilisé. Cependant, avec le développement continu des véhicules autonomes et des technologies associées, la demande de bande passante et de connectivité accrues est forte. Dans ce document, nous décrivons brièvement le CAN et d’autres options de connectivité embarquée, notamment le CAN sans fil, MOST, FlexRay et Ethernet automobile.

## Bus CAN : quelques principes sous-jacents

Dans un sens large, le CAN-bus (Controller Area Network-bus) est en réalité un ensemble de normes qui permettent à différents appareils de communiquer entre eux. C’est un système de bus série asynchrone (décalé dans le temps), développé en 1983 par Robert Bosch GmbH dans le but d’interconnecter des unités de contrôle électronique (ECU) dans les véhicules à moteur.

Le bus CAN a été divisé en différentes couches, selon le modèle ISO/OSI, afin d’obtenir de la flexibilité et de la transparence de conception. Pour la communication en pratique, le bus CAN utilise deux fils dédiés : CAN low et CAN high, grâce auxquels le contrôleur CAN est connecté à tous les composants du réseau. Le CAN permet de remplacer un câblage assez complexe par un bus à deux fils. Le CAN utilise un signal différentiel, ce qui le rend plus résistant au bruit, avec deux états logiques : récessif et dominant. Aujourd’hui, le bus CAN est utilisé à peu près partout, des machines à café jusqu’aux [opérations de Gestion de Flotte](https://www.navixy.com/fleet-management/features/) et les applications spatiales. Nous décrivons brièvement plus loin les principes de fonctionnement du bus CAN.

Le protocole de communication CAN ISO-11898: 2003 explique comment les informations sont transmises entre des appareils sur un réseau basé sur un modèle d’interconnexion de systèmes ouverts (OSI) qui est présenté sous forme d’un ensemble de couches dans la figure ci-dessous. Les deux couches inférieures du modèle OSI/ISO à sept couches sont la couche physique et la couche liaison de données. La couche physique définit la communication entre les appareils connectés par le support physique.

![CAN et alternatives](/files/4d8eac577cb403f3a31352991a0d9f41745facf5)

La couche liaison de données, entre autres, se charge aussi d’organiser les bits en trames et comprend deux protocoles : le CAN classique (dont la première utilisation remonte à 1988) et le CAN FD (lancé en 2012).

La couche application est essentiellement une couche pour l’utilisateur final et donne accès aux ressources du réseau. Il existe deux types de formats de messages/trames : standard et étendu. Ils ne diffèrent que par la longueur de l’identifiant – 11 bits pour le standard, 29 bits pour l’étendu.

Une structure de message standard peut être divisée en 8 parties, comme montré sur la figure ci-dessous. Ces parties sont : Début de trame (SOF - le début de la transmission de trame), CAN-ID (identifiant de trame, identification de la priorité du message), Demande de transmission à distance (RTR, indique si un nœud demande des données à un autre nœud ou en envoie), Contrôle (indique la longueur des données en octets), Données (valeurs réelles des données qui doivent être mises à l’échelle/converties), Contrôle de redondance cyclique (CRC, garantissant l’intégrité des données), ACK (accusé de réception, indique si les données sont reçues correctement) et EOF (fin de trame) qui marque la fin du message/de la trame CAN.

![CAN et alternatives](/files/bf6737093afef4e157f3c20dfa7a057db580405a)

Le bus CAN utilise une logique inversée avec deux états : dominant et récessif. La figure ci-dessus montre un schéma entrée-sortie simplifié d’un émetteur-récepteur CAN : un flux de bits allant vers/depuis un contrôleur CAN et/ou un microcontrôleur. Lorsque le contrôleur envoie un flux de bits, ceux-ci sont complémentés et placés sur la ligne CANH.

La ligne CANL est toujours le complément de CANH. Le CAN doit surveiller à la fois ce qui se trouve actuellement sur le bus et ce qu’il envoie. Pour les applications, les deux extrémités du bus CAN doivent être terminées, car n’importe quel nœud du bus peut transmettre des données.

Chaque extrémité de la liaison possède une résistance de terminaison égale à l’impédance caractéristique du câble. En général, la valeur recommandée pour les résistances de terminaison est de 120 Ω (dans une plage de 100 Ω à 130 Ω). Il ne devrait pas y avoir plus de deux résistances de terminaison dans le réseau, car des terminaisons supplémentaires imposent une charge supplémentaire aux pilotes.

L’image ci-dessous montre un bus de test CAN. Les nœuds pourraient représenter l’envoi de messages provenant d’une technologie de détection intelligente et d’un contrôleur moteur. Une application typique pourrait être un capteur de température.

![CAN et alternatives](/files/abcc4298ffacc774d0ea37e6f43c8d544a7b7ef4)

Si un autre nœud capteur doit envoyer un message simultanément, l’arbitrage garantit que le message est envoyé. Par exemple, le nœud A termine l’envoi de son message pendant que les nœuds B et C confirment la bonne réception du message. À leur tour, les nœuds B et C commencent l’arbitrage et si le nœud C le remporte, il envoie un message. Les nœuds A et B accusent réception du message du nœud C, puis le nœud B poursuit l’envoi de son message.

Il convient de garder à l’esprit la polarité opposée de l’entrée et de la sortie du pilote sur le bus. Le bus CAN est aujourd’hui largement répandu dans les voitures. Il est présent dans pratiquement tous les véhicules fabriqués. Dans le monde moderne, les voitures sont essentiellement un produit du marché mondial, de sorte que tous les véhicules ont tendance à être équipés d’un bus CAN. Le bus CAN est accessible via le port OBD, présenté sur la figure ci-dessous avec un exemple de résistance de terminaison de 120 Ω soudée sur le connecteur DB9 avec le câblage CAN, situé dans le boîtier de la prise DB9.

Pour câbler le port OBD à un appareil CAN DB9, il faut un câble qui peut être acheté ou fabriqué. Pour en fabriquer un soi-même, une prise D-sub à 9 broches (femelle) et une fiche OBD (mâle) sont nécessaires. La prise DB9 doit correspondre à la fiche de l’appareil CAN.

![CAN et alternatives](/files/017e2a54b6d61e7362384a90ed73c935dc0d3bb4)

Un exemple de câblage de la fiche OBD vers le DB9 CAN, y compris une résistance de terminaison optionnelle, est également présenté sur les schémas ci-dessous.

![CAN et alternatives](/files/1329758adca5f199d3768ef32feda56d4fd74b0d)

Pour construire un réseau de capteurs, interfacer un bus CAN et visualiser les signaux CAN des véhicules, il existe de nombreuses options. Divers microcontrôleurs prennent actuellement en charge le protocole CAN et peuvent être reliés au CAN via une puce émetteur-récepteur CAN.

Des solutions comme Raspberry Pi, Texas Instruments Launchpad et Arduino existent également et peuvent être interfacées au CAN au moyen de certains modules complémentaires. Le réseau de communication CAN dans les véhicules modernes peut fournir un volume de données énorme qui peut être exploité pour [opérations de Gestion de Flotte](https://www.navixy.com/fleet-management/features/) accroître la sécurité des conducteurs, réduire les dépenses globales, améliorer les processus d’entretien et soutenir la responsabilité environnementale.

L’activation des données du bus CAN offre aux propriétaires de flotte diverses possibilités d’accéder à différentes informations, notamment la consommation de carburant, les relevés du compteur kilométrique, les tours par minute, la position du papillon des gaz, la charge/le couple moteur, la température du moteur et le niveau de carburant.

## CAN sans fil

Le CAN sur une paire torsadée de fils de cuivre est devenu une norme ISO en 1994. La demande croissante de connectivité accrue favorise le développement de technologies alternatives et complémentaires. Par exemple, certaines options de transmission CAN sans fil reposent sur des normes radio fondées sur des protocoles tels que WLAN ou Bluetooth.

Dans un tel scénario, les données CAN dans l’émetteur doivent être converties vers le protocole sans fil et rétablies dans le récepteur. Une transmission transparente et en temps réel au sens du réseau CAN n’est donc pas possible de cette manière. La liaison radio fonctionne ainsi comme une passerelle entre deux réseaux CAN.

![CAN et alternatives](/files/ac857cca0133731c2345d7b0fa28546e806a34f3)

Le CAN sans fil basé sur une radio bi-mode permet d’intégrer sans fil les nœuds CAN dans un réseau CAN, ce qui accroît la sécurité et la facilité d’utilisation. Cependant, un tel système nécessite des antennes spéciales qui prennent de la place et un alignement particulier, ce qui limite le rayonnement omnidirectionnel.

## MOST, FlexRay et Ethernet automobile en bref

Une alternative prometteuse au CAN est Ethernet automobile. Certaines estimations prévoient que le marché de l’Ethernet automobile croîtra de plus de 21,6 % sur la période de prévision 2019-2026.

Les principaux avantages d’Ethernet pour la connectivité des véhicules sont une bande passante élevée et un bon rapport coût-efficacité. Ethernet utilise la stratégie d’accès multiple avec écoute de porteuse et détection de collision (CSMA/CD). La collision peut être ignorée grâce à la division dans les réseaux embarqués. Parmi les défis de l’Ethernet automobile figurent une quantité importante de bruit RF, l’incapacité à fournir une latence jusqu’à la plage de la microseconde basse et l’absence de moyen de synchroniser le temps entre les appareils.

MOST (Media Oriented System Transport) est un système de communication série pour transmettre les données de contrôle, la vidéo et l’audio au moyen de câbles à fibres optiques. [Il](http://cables.it) fournit un échange point à point d’informations sonores et vidéo à un débit de 24,8 Mbit/s. Créé par l’association MOST, MOST définit les couches de protocole, logicielles et matérielles nécessaires pour permettre un transport efficace et peu coûteux des données de contrôle, en temps réel et par paquets, en utilisant un seul support / une seule couche physique. Un réseau MOST peut être représenté schématiquement sous la forme d’un anneau pouvant inclure jusqu’à 64 appareils MOST. Grâce à sa fonctionnalité plug\&play, l’ajout ou le retrait d’un appareil MOST devrait être assez simple.

FlexRay, quant à lui, est essentiellement une norme de réseau automobile basée sur un système de bus flexible, à haut débit, déterministe, tolérant aux pannes et à grande vitesse. Il est utilisé dans le cadre de topologies en étoile ou en ligne avec du cuivre ou de la fibre optique. Les configurations bi-canal de FlexRay offrent une tolérance aux pannes renforcée et/ou une bande passante accrue. Les caractéristiques du réseau de communication FlexRay le rendent favorable à l’industrie automobile de nouvelle génération.

![CAN et alternatives](/files/93c406a17b458c9d237be0e982b2a8674ccfbcef)

La plupart des réseaux FlexRay de première génération utilisent normalement un seul canal afin de réduire les coûts de câblage, mais le développement ultérieur des applications et les exigences de sécurité qui en découlent conduiront à une utilisation accrue de deux canaux. Les facteurs limitants de la diffusion de FlexRay sont le prix, des niveaux de tension de fonctionnement plus faibles et l’asymétrie des fronts, ce qui complique l’extension de la longueur du réseau. Certaines caractéristiques clés des protocoles listés, comparées aux caractéristiques du CAN, sont présentées dans le tableau ci-dessous.

![CAN et alternatives](/files/d41384c9c6d3cd2e5f9fe08c2c509a969b47e549)

La comparaison directe des protocoles de connectivité listés montre qu’il existe un compromis clair entre bande passante et tolérance aux pannes, d’une part, et coûts moyens et complexité du système, d’autre part. Bien que CAN et MOST restent en quelque sorte des protocoles fondamentaux, FlexRay et Ethernet constituent des solutions plus prometteuses pour satisfaire les demandes croissantes du marché et des applications à forte charge. Dans les véhicules modernes, ces protocoles sont souvent utilisés comme solutions complémentaires.

## Objectif des protocoles de communication embarqués

Le bus CAN est en effet une norme de connectivité automobile bien connue et établie. Il est utilisé pour le groupe motopropulseur, le châssis, le réseau dorsal et les systèmes de carrosserie. Ethernet, quant à lui, est couramment utilisé comme protocole de diagnostic pour les unités de commande électroniques du moteur, du châssis et de la carrosserie utilisées pour les connexions réseau.

FlexRay constitue actuellement la base du développement technologique actif dans le monde entier, et ses nombreuses applications incluent les systèmes X-by-Wire de nouvelle génération et les systèmes dorsaux. MOST est une norme de bus pour les réseaux multimédias embarqués conçue pour permettre le transfert d’audio, de vidéo et de données de haute qualité. Elle permet d’interconnecter facilement divers composants multimédias du véhicule.

Tous les protocoles et technologies mentionnés ci-dessus satisfont à la plupart des exigences de diagnostic et de communication multimédia pour les communications modernes embarquées et véhicule à véhicule, et pourraient être utilisés pour des systèmes avancés de conduite autonome. Cependant, l’intégration précise de ces technologies tout en respectant les contraintes de temps réel demeure une tâche difficile.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
