> 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. CAN, FlexRay et MOST sont tous des protocoles de communication automobile utilisés pour connecter les unités de contrôle électronique (ECU), les unités de contrôle de transmission (TCU) et les modules de carrosserie (BCM) dans les Véhicules : * **CAN**\ Un protocole basé sur les messages, initialement conçu pour économiser du cuivre en multiplexant le câblage électrique dans les voitures. CAN a une bande passante d’environ 125 kpbs. * **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 Mbits par seconde sur deux fils torsadés. FlexRay est souvent utilisé dans des applications critiques pour la Sécurité, telles que les modules de groupe motopropulseur. Les charges utiles FlexRay, ou trames de données, peuvent atteindre 127 mots (254 octets) de long, ce qui est plus de 30 fois plus long que les charges utiles CAN. * **MOST**\ Une norme de bus pour les réseaux multimédias de véhicules 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. CAN (Controller Area Network) est actuellement le réseau embarqué le plus largement utilisé dans les Véhicules. 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 CAN et d’autres options de connectivité véhiculaires, notamment le CAN sans fil, MOST, FlexRay et l’Ethernet automobile. ## Bus CAN : quelques principes sous-jacents Au 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 les unités de contrôle électronique (ECU) dans les véhicules à moteur. 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. En pratique, le bus CAN utilise deux fils dédiés : CAN low et CAN high, au moyen desquels le contrôleur CAN est connecté à tous les composants du réseau. CAN permet de remplacer un câblage assez complexe par un bus à deux fils. 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é presque partout, des machines à café à [Gestion de Flotte](https://navixy.com/en/fleet-management/) et aux applications spatiales. Nous décrivons brièvement ci-dessous les principes de fonctionnement du bus CAN. Le protocole de communication CAN ISO-11898: 2003 explique comment les informations sont échangées entre les appareils sur un réseau basé sur un modèle d’interconnexion de systèmes ouverts (OSI) présenté comme un ensemble de Couches sur la figure ci-dessous. Les deux couches les plus basses 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](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 liaison de données se charge notamment aussi 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 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 – un identifiant standard fait 11 bits, tandis qu’un identifiant étendu en fait 29. La structure d’un message standard peut être divisée en 8 parties, comme indiqué sur la figure ci-dessous. Ces parties sont : Start of Frame (SOF - le début de la transmission de la trame), CAN-ID (identifiant de la 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 en envoie), Control (indique la longueur des données en octets), Data (valeurs réelles des données qu’il faut mettre à l’échelle/converter), 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 logique inversée avec deux états : dominant et récessif. La figure ci-dessus montre un schéma entrée-sortie simplifié d’un transceiver 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étés et placés sur la ligne CANH. La ligne CANL est toujours le complément de CANH. 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 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 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 Conducteurs. 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 du message. Les Nœuds B et C commencent à leur tour l’arbitrage et si le Nœud C le remporte, alors il envoie un message. Les Nœuds A et B acquittent le message du Nœud C, puis le Nœud B poursuit son propre message. La polarité opposée de l’entrée et de la sortie du Conducteur sur le bus doit être gardée à l’esprit. Le bus CAN est aujourd’hui largement répandu dans les voitures. Il est présent dans pratiquement tous les Véhicules fabriqués. Les voitures du monde moderne sont essentiellement un produit du marché mondial, de sorte que tous les Véhicules tendent à avoir un bus CAN. Le bus CAN est accessible via le port OBD, présenté sur la figure ci-dessous, avec un exemple d’une résistance de terminaison de 120Ω, soudée sur le connecteur DB9 avec le câblage CAN, situé dans le boîtier DB9. Pour câbler le port OBD à un appareil CAN DB9, il faut un câble qui peut être acheté ou 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 OBD vers DB9 CAN, y compris la résistance de terminaison optionnelle, est également présenté 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, s’interfacer avec 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 interfacés au CAN via une puce transceiver CAN. Des solutions comme Raspberry Pi, Texas Instruments Launchpad et Arduino existent également et peuvent s’interfacer au CAN au moyen de certains modules complémentaires. Un réseau de communication CAN dans les Véhicules modernes pourrait fournir un énorme volume de données qui peut être utilisé pour [Gestion de Flotte](https://navixy.com/en/fleet-management/) augmenter 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 par minute, la position de l’accélérateur, la charge/le couple du 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 du CAN sans fil reposent sur des normes radio basées sur des protocoles tels que WLAN ou Bluetooth. Dans un tel scénario, les données CAN dans l’émetteur doivent être converties au protocole sans fil et réinitialisées 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 liaison radio fonctionne ainsi 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 double mode permet d’intégrer sans fil les participants CAN dans un réseau CAN, augmentant la Sécurité et la facilité d’utilisation. Cependant, un tel système nécessite des antennes spéciales qui demandent de l’espace et un alignement particulier limitant la radiation omnidirectionnelle. ## MOST, FlexRay et Ethernet automobile en bref Une alternative prometteuse à 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 d’Ethernet pour la connectivité des Véhicules sont une bande passante élevée et une efficacité économique. Ethernet emploie la stratégie Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Les collisions peuvent être ignorées grâce au partage dans les réseaux embarqués. Certains défis de l’Ethernet automobile sont une quantité importante de bruit RF, l’incapacité à fournir une latence jusqu’à la gamme de la faible microseconde 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 contrôle, de vidéo et d’audio au moyen de fibre optique [http://cables.It](http://cables.it) permet un échange point à point d’informations audio et vidéo avec un débit de 24,8 Mbps. MOST a été créé par l’association MOST et définit les Couches de protocole, de logiciel et de matériel nécessaires pour permettre un transport efficace et à faible coût 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 pré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, quant à lui, est essentiellement une norme de réseau automobile basée sur un système de bus flexible à haut débit de données, déterministe, tolérant aux pannes et à grande vitesse. Il est utilisé dans le cadre d’une topologie en étoile ou en ligne avec du cuivre ou de la fibre optique. Les configurations à double canal de FlexRay offrent une meilleure tolérance aux pannes 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) La plupart des 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 de la diffusion à grande échelle de FlexRay sont le prix, des niveaux de tension de fonctionnement plus faibles et l’asymétrie des fronts, ce qui pose des défis pour l’extension de la longueur du réseau. Certaines caractéristiques clés des protocoles répertoriés par rapport 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é répertoriés montre qu’il existe un compromis clair entre la bande passante et la tolérance aux pannes d’une part, et les coûts moyens et la complexité du système d’autre part. Alors que CAN et MOST restent une sorte de protocoles fondamentaux, FlexRay et Ethernet constituent une solution plus prometteuse pour satisfaire les exigences croissantes du marché et des applications à forte charge. Dans un 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. Ethernet, quant à lui, est couramment utilisé comme protocole de diagnostic pour les unités de contrôle de connexion électronique du moteur, du châssis et de la carrosserie utilisées pour les connexions réseau. FlexRay forme 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 de véhicules conçue pour permettre le transfert d’audio, de vidéo et de données de haute qualité. Elle permet l’interconnexion facile de divers composants multimédias des Véhicules. Tous les protocoles et technologies mentionnés ci-dessus satisfont la plupart des exigences de diagnostic et de communication multimédia pour les communications embarquées modernes 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 satisfaisant les contraintes de temps réel reste encore une partie 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 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.