> 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 Les réseaux embarqués utilisent CAN, FlexRay, MOST et Ethernet pour la communication des ECU. Chaque protocole répond à des besoins différents en matière de vitesse, de fiabilité et de bande passante. Le CAN, FlexRay et MOST sont tous des protocoles de communication automobile utilisés pour connecter les unités de commande électroniques (ECU), les unités de commande de transmission (TCU) et les modules de commande de carrosserie (BCM) dans les véhicules : * **CAN**\ Un protocole basé sur les messages qui a été conçu à l'origine pour économiser du cuivre en multiplexant le câblage électrique des voitures. Le CAN a une bande passante d'environ 125 kbps. * **FlexRay**\ Un protocole de communication série rapide, tolérant aux pannes et déterministe qui peut transférer des données à des vitesses allant jusqu'à 10 Mbits par seconde sur deux fils torsadés. FlexRay est souvent utilisé dans des applications critiques pour la sécurité, telles que les modules du groupe motopropulseur. Les charges utiles FlexRay, ou trames de données, peuvent atteindre 127 mots (254 octets) de long, soit plus de 30 fois la longueur des 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 plus grande bande passante et de connectivité est élevée. Dans ce document, nous décrivons brièvement le CAN et d'autres options de connectivité véhiculaire, y compris le CAN sans fil, MOST, FlexRay et l'Ethernet automobile. ## Bus CAN : quelques principes de base Au sens large, le bus CAN (Controller Area Network-bus) est en réalité un ensemble de normes qui permettent à différents appareils de communiquer entre eux. Il s'agit d'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 les unités de commande électroniques (ECU) dans les véhicules automobiles. Le CAN a été divisé en différentes couches, suivant 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, au moyen desquels le contrôleur CAN est relié à 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é pratiquement partout, des machines à café [la gestion de flotte](https://www.navixy.com/fleet-management/features/) aux 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 l'information est transmise entre des appareils sur un réseau basé sur un modèle d'interconnexion de systèmes ouverts (OSI) qui est présenté comme un ensemble de couches dans la figure ci-dessous. Les deux couches inférieures du modèle OSI/ISO à sept couches sont les couches physique et de liaison de données. La couche physique définit la communication entre des appareils connectés par le support physique. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-d50f3bc11d78b83e05bfefe9d3ac7d582dec1855%2Fcan-bus-principles-1.jpg?alt=media) La couche de liaison de données, entre autres, se charge également d'organiser les bits en trames et comprend deux protocoles : le CAN classique (première utilisation remontant à 1988) et le CAN FD (lancé en 2012). La couche applicative est essentiellement une couche destinée à 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 l'un de l'autre que par la longueur de l'identifiant : le standard fait 11 bits, tandis que l'étendu en fait 29. Une structure de message standard peut être divisée en 8 parties comme illustré dans la figure ci-dessous. Ces parties sont : Start of Frame (SOF - le début de la transmission de la trame), CAN-ID (identifiant de trame, identification de la priorité du message), Remote Transmission Request (RTR, indique si un nœud demande des données à un autre nœud ou les envoie), Control (indique la longueur des données en octets), Data (valeurs réelles des données qui doivent être mises à l'échelle/converties), The Cyclic Redundancy Check (CRC, garantissant l'intégrité des données), ACK (acquittement, indique si les données sont reçues correctement) et EOF (End of Frame) qui marque la fin du message/de la trame CAN. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-eba86e7aeb438081d966dd3c6b187558c624ddfd%2Fcan-bus-principles-2.png?alt=media) Le bus CAN utilise une forme inversée de logique avec deux états : dominant et récessif. La figure ci-dessus montre un schéma simplifié d'entrée-sortie d'un émetteur-récepteur CAN : 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 tout nœud sur le bus peut transmettre des données. Chaque extrémité de la liaison comporte une résistance de terminaison égale à l'impédance caractéristique du câble. Habituellement, la valeur recommandée pour les résistances de terminaison est de 120 Ω (dans une plage de 100 Ω à 130 Ω). Il ne doit 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 par une technologie de détection intelligente et un contrôleur de moteur. Une application typique pourrait être un capteur de température. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-a5cb2689542e48625d481f44b3a3939a738f7b8f%2Fcan-bus-principles-3.png?alt=media) Si un autre nœud de 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 tandis que les nœuds B et C acquittent la bonne réception d'un message. Les nœuds B et C commencent à leur tour l'arbitrage et si le nœud C gagne l'arbitrage, il envoie un message. Les nœuds A et B acquittent le message du nœud C, puis le nœud B poursuit avec son message. Il faut garder à l'esprit la polarité opposée de l'entrée et de la sortie du pilote sur le bus. De nos jours, le bus CAN est 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 tendent à avoir un bus CAN. On accède au bus CAN via le port OBD, qui est montré sur une figure ci-dessous aux côtés d'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 du DB9. Pour câbler le port OBD à un appareil CAN DB9, il faut un câble qui peut être soit acheté, soit fabriqué. Pour en réaliser 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](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-29b9ba1c692a1a89298cfff4fc27af89c58b318a%2Fcan-bus-principles-4.png?alt=media) Un exemple de câblage du connecteur OBD vers le DB9 CAN, incluant également une résistance de terminaison en option, est également montré sur les schémas ci-dessous. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-dbd222d423e905257463eec2576d2c20fd970e83%2Fcan-bus-principles-5.png?alt=media) 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 reliées au CAN au moyen de certains modules complémentaires. Le réseau de communication CAN dans les véhicules modernes peut fournir un énorme volume de données qui peut être utilisé pour [la 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 à diverses informations, notamment la consommation de carburant, les relevés du compteur kilométrique, le régime moteur, la position du papillon, 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 entraîne le développement de technologies alternatives et complémentaires. Par exemple, certaines options de transmission CAN sans fil reposent sur des normes radio basées sur des protocoles comme WLAN ou Bluetooth. Dans un tel scénario, les données CAN dans l'émetteur doivent être converties au protocole sans fil et reconverties dans le récepteur. Une transmission transparente et en temps réel au sens du réseau CAN n'est pas possible de cette manière. La connexion radio fonctionne donc comme une passerelle entre deux réseaux CAN. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-364944e1412069e50e4b64a745a959920a8b82de%2Fwireless-can-diagram.png?alt=media) Le CAN sans fil basé sur une radio bimode permet d'intégrer sans fil des nœuds CAN dans un réseau CAN, ce qui améliore 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 l'Ethernet automobile en bref Une alternative prometteuse au CAN est l'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 de l'Ethernet pour la connectivité des véhicules sont la grande bande passante et la rentabilité. L'Ethernet emploie la stratégie Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Les collisions peuvent être ignorées grâce à la segmentation 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 des faibles microsecondes 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 la transmission de données de commande, de vidéo et d'audio au moyen de fibre optique [http://cables.It](http://cables.it) permet un échange d'informations sonores et vidéo de point à point à des débits de 24,8 Mbps. MOST, créé par l'association MOST, définit les couches protocole, logiciel et matériel nécessaires pour permettre le transport efficace et à faible coût des données de commande, en temps réel et par paquets en utilisant un support unique / une seule couche physique. Un réseau MOST peut être représenté schématiquement sous forme d'anneau pouvant inclure jusqu'à 64 appareils MOST. Grâce à sa fonctionnalité plug\&play, l'ajout ou la suppression d'un appareil MOST devrait être assez simple. FlexRay, de son côté, est essentiellement une norme de réseau automobile basée sur un système de bus déterministe, tolérant aux pannes et à haut débit, à débit de données flexible. Il est utilisé dans les topologies en étoile ou en ligne avec du cuivre ou de la fibre optique. Les configurations FlexRay à double canal offrent une tolérance aux pannes améliorée et/ou une bande passante accrue. Le réseau de communication FlexRay présente des caractéristiques qui le rendent favorable aux industries automobiles de nouvelle génération. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-e4b95247fd9568333d6e0f8ea1f3299162d25d40%2Fflexray_wiring.jpg?alt=media) Les réseaux FlexRay de première génération emploient normalement un seul canal pour 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 d'une large utilisation du FlexRay sont le prix, des niveaux de tension de fonctionnement plus faibles et l'asymétrie des fronts, qui entraînent des difficultés d'extension de la longueur du réseau. Certaines caractéristiques clés des protocoles énumérés, comparées aux caractéristiques du CAN, sont présentées dans le tableau ci-dessous. ![CAN et alternatives](https://938069364-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-5ab41e0328dddbe4f3671312560eba5fbf5e5f33%2Fmost-flexray-diagram.png?alt=media) La comparaison directe des protocoles de connectivité énuméré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. Alors que le CAN et MOST restent une sorte de protocoles fondamentaux, FlexRay et Ethernet constituent des solutions plus prometteuses pour satisfaire les exigences du marché en croissance 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é véhiculaire bien connue et établie. Il est utilisé pour le groupe motopropulseur, le châssis, le réseau dorsal et les systèmes de carrosserie. L'Ethernet, de son côté, 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 comprennent 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é. Il 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 du diagnostic et de la communication multimédia pour les communications modernes embarquées et de 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 un défi. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/expert-center/fr/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.