> 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 commande électronique (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 dans les voitures. Le CAN a une bande passante d'environ 125 kpbs. * **FlexRay**\ Un protocole de communication série rapide, 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é, comme les modules du groupe motopropulseur. Les charges utiles FlexRay, ou trames de données, peuvent atteindre 127 mots (254 bytes) de longueur, ce qui est plus de 30 fois plus long que les charges utiles CAN. * **MOST**\ Un standard de bus pour les réseaux multimédias de véhicule 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é dans les Véhicules 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 CAN et d'autres options de connectivité véhiculaire, notamment le CAN sans fil, MOST, FlexRay et l'Ethernet automobile. ## Bus CAN : quelques principes de base Dans un sens large, le CAN-bus (Controller Area Network-bus) est en réalité un ensemble de normes permettant à 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 commande électronique (ECU) dans les véhicules motorisés. 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. 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. 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é jusqu'aux [la Gestion de Flotte](https://www.navixy.com/fleet-management/features/) 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 des systèmes ouverts (OSI) présenté comme un ensemble de Couches dans 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 s'occupe également, entre autres, 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 utilisateur final et fournit l'accès aux ressources du réseau. Il existe deux types de formats de message/trame : standard et étendu. Ils ne diffèrent l'un de l'autre que par la longueur de l'identifiant – un standard fait 11 bits, tandis qu'un étendu fait 29 bits. Une structure de message standard peut être divisée en 8 parties comme montré sur la figure ci-dessous. Ces parties sont : Start of Frame (SOF - le début de la transmission de 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 en envoie), Control (indique la longueur des données en octets), Data (valeurs de données réelles qu'il faut convertir), The Cyclic Redundancy Check (CRC, garantissant l'intégrité des données), ACK (acknowledge, indique si les données sont reçues correctement) et EOF (End of Frame) qui marque la fin du message/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 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. Le CAN doit surveiller à la fois ce qui se trouve actuellement sur le bus et ce qu'il envoie. Dans 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 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 sur les 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 accusent réception correcte d'un message. Les Nœuds B et C commencent à leur tour l'arbitrage et si le Nœud C remporte l'arbitrage, il envoie un message. Les Nœuds A et B accusent réception du message du Nœud C, et le Nœud B poursuit ensuite son message. Il faut 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, donc tous les Véhicules ont tendance à avoir un bus CAN. Le bus CAN est accessible via le port OBD, qui est montré 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 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](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 de la fiche OBD vers DB9 CAN, y compris la résistance de terminaison optionnelle, 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, 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. Le réseau de communication CAN dans les Véhicules modernes pourrait fournir un volume de données énorme qui peut être exploité dans [la Gestion de Flotte](https://www.navixy.com/fleet-management/features/) pour accroître la Sécurité du Conducteur, réduire les dépenses globales, améliorer les processus d'Entretien et soutenir la responsabilité environnementale. L'exploitation 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, les tours par minute, la position du papillon, 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 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 vers le 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 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 à double mode permet d'intégrer sans fil les participants au 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 le rayonnement omnidirectionnel. ## MOST, FlexRay et 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é. Ethernet emploie la stratégie Carrier Sense Multiple Access with Collision Detection (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é de fournir une latence allant 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 transmettre des données de commande, de la vidéo et de l'audio au moyen de fibre optique [http://cables.It](http://cables.it) offre un échange point à point d'informations sonores et vidéo à un débit de 24,8 Mbps. MOST, créé par l'association MOST, définit les Couches de protocole, de logiciel et de matériel nécessaires pour permettre un transport efficace et peu coûteux des données de commande, en temps réel et par paquets à l'aide d'un support unique / couche physique. Un réseau MOST pourrait ê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 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, déterministe, tolérant aux pannes et rapide. Il est utilisé dans le cadre d'une topologie en étoile ou en ligne avec du cuivre ou de la fibre optique. Les configurations FlexRay à double canal offrent une tolérance aux pannes renforcée et/ou une bande passante accrue. Les fonctionnalités du réseau de communication FlexRay les rendent favorables 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 utilisent 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 limitant la généralisation 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 fonctionnalités clés des protocoles énuméré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é é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 CAN et MOST restent une sorte de protocoles fondamentaux, FlexRay et Ethernet constituent des solutions plus prometteuses pour satisfaire les demandes 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é des Véhicules 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, 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 de véhicule conçue pour permettre le transfert d'audio, de vidéo et de données de haute qualité. Elle permet une interconnexion facile de divers composants multimédias de véhicule. Tous les protocoles et technologies mentionnés ci-dessus satisfont la plupart des exigences de diagnostic et de communication multimédia pour la communication embarquée moderne et la communication 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 aux contraintes de temps réel reste 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=&goal= ``` `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.