> 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/es/vehicle-telematics-technology/can-and-obdii/intra-vehicle-communication-can-flexray-and-most.md). # Comunicación intravehicular: CAN, FlexRay y MOST Las redes a bordo usan CAN, FlexRay, MOST y Ethernet para la comunicación de la ECU. Cada protocolo apunta a distintas necesidades de velocidad, confiabilidad y ancho de banda. CAN, FlexRay y MOST son todos protocolos de comunicación automotriz que se utilizan para conectar unidades de control electrónico (ECU), unidades de control de la transmisión (TCU) y módulos controlados por la carrocería (BCM) en vehículos: * **CAN**\ Un protocolo basado en mensajes que originalmente fue diseñado para ahorrar cobre al multiplexar el cableado eléctrico en los automóviles. CAN tiene un ancho de banda de alrededor de 125 kpbs. * **FlexRay**\ Un protocolo de comunicación serial de alta velocidad, tolerante a fallas y determinista que puede transferir datos a velocidades de hasta 10 Mbits por segundo a través de dos cables trenzados. FlexRay se usa con frecuencia en aplicaciones críticas para la seguridad, como los módulos del tren motriz. Las cargas útiles de FlexRay, o tramas de datos, pueden tener hasta 127 palabras (254 bytes) de longitud, lo que es más de 30 veces más largo que las cargas útiles de CAN. * **MOST**\ Un estándar de bus para redes multimedia vehiculares que permite la transferencia de audio, video y datos de alta calidad. MOST está disponible en tres velocidades de transmisión: MOST25, MOST50 y MOST150. CAN (Controller Area Network) es actualmente la red vehicular más utilizada. Sin embargo, con el desarrollo continuo de los vehículos autónomos y la tecnología relacionada, hay una alta demanda de mayor ancho de banda y conectividad. En este documento, describimos brevemente CAN y otras opciones de conectividad vehicular, incluida CAN inalámbrico, MOST, FlexRay y ethernet automotriz. ## Bus CAN: algunos principios subyacentes En un sentido amplio, el CAN-bus (bus de Controller Area Network) es en realidad un conjunto de estándares que permiten que distintos dispositivos se comuniquen entre sí. Es un sistema de bus serial asíncrono (desfasado en el tiempo), desarrollado en 1983 por Robert Bosch GmbH con un objetivo de interconectar unidades de control electrónico (ECU) en vehículos motorizados. CAN se dividió en varias capas, siguiendo el modelo ISO/OSI para lograr flexibilidad y transparencia de diseño. Para la comunicación en la práctica, el bus CAN utiliza dos cables dedicados: CAN low y CAN high, por medio de los cuales el controlador CAN se conecta a todos los componentes de la red. CAN permite sustituir un cableado bastante complejo por un bus de dos cables. CAN utiliza una señal diferencial, que lo hace más resistente al ruido, con dos estados lógicos: recesivo y dominante. Hoy en día, el bus CAN se usa prácticamente en todo, desde máquinas de café hasta [Gestión de flotas](https://navixy.com/en/fleet-management/) y aplicaciones espaciales. A continuación describimos brevemente los principios de funcionamiento del bus CAN. El protocolo de comunicación CAN ISO-11898: 2003 explica cómo se transmite la información entre dispositivos en una red basada en un modelo de Interconexión de Sistemas Abiertos (OSI) que se presenta como un conjunto de capas en la figura siguiente. Las dos capas inferiores del modelo OSI/ISO de siete capas son las capas física y de enlace de datos. La capa física define la comunicación entre dispositivos conectados por el medio físico. ![CAN y alternativas](https://3386484127-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 capa de enlace de datos, entre otras cosas, también se encarga de organizar los bits en tramas e incluye dos protocolos: el CAN clásico (cuyo primer uso se remonta a 1988) y CAN FD (lanzado en 2012). La capa de aplicación es esencialmente una capa de usuario final y proporciona acceso a los recursos de la red. Hay dos tipos de formatos de mensajes/tramas: estándar y extendido. Se diferencian entre sí solo por la longitud del identificador: uno estándar es de 11 bits, mientras que uno extendido es de 29 bits. Una estructura de mensaje estándar podría dividirse en 8 partes, como se muestra en la figura siguiente. Esas partes son: Inicio de trama (SOF: inicio de la transmisión de la trama), CAN-ID (identificador de trama, identificación de prioridad del mensaje), Solicitud de transmisión remota (RTR, indica si un nodo solicita datos de otro nodo o envía datos), Control (informa la longitud de los datos en bytes), Datos (valores reales de los datos que necesitan escalarse o convertirse), La comprobación de redundancia cíclica (CRC, garantiza la integridad de los datos), ACK (acuse de recibo, indica si los datos se están recibiendo correctamente) y EOF (Fin de trama), que marca el final del mensaje/trama CAN. ![CAN y alternativas](https://3386484127-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) El bus CAN utiliza una forma invertida de lógica con dos estados: dominante y recesivo. La figura anterior muestra un diagrama simplificado de entrada-salida de un transceptor CAN: flujo de bits que va hacia/desde un controlador CAN y/o microcontrolador. Cuando el controlador envía una secuencia de bits, estos se complementan y se colocan en la línea CANH. La línea CANL es siempre el complemento de CANH. CAN debe monitorear tanto lo que está actualmente en el bus como lo que está enviando. Para las aplicaciones, ambos extremos del bus CAN deben terminarse, ya que cualquier nodo en el bus puede transmitir datos. Cada extremo del enlace tiene una resistencia de terminación igual a la impedancia característica del cable. Por lo general, el valor recomendado para las resistencias de terminación es de 120 Ω (en un rango de 100 Ω - 130 Ω). No debe haber más de dos resistencias de terminación en la red, ya que terminaciones adicionales colocan carga extra en los controladores. La imagen siguiente muestra un bus de prueba CAN. Los nodos podrían representar el envío de mensajes desde tecnología de detección inteligente y un controlador de motor. Una aplicación típica podría ser un sensor de temperatura. ![CAN y alternativas](https://3386484127-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 otro nodo sensor necesita enviar un mensaje simultáneamente, el arbitraje garantiza que el mensaje se envíe. Por ejemplo, el nodo A termina de enviar su mensaje mientras los nodos B y C confirman que se está recibiendo correctamente un mensaje. Los nodos B y C, a su vez, inician el arbitraje y, si el nodo C gana el arbitraje, entonces envía un mensaje. Los nodos A y B confirman el mensaje del nodo C, y luego el nodo B continúa con su mensaje. Debe tenerse en cuenta la polaridad opuesta de la entrada y salida del controlador en el bus. Hoy en día, el bus CAN está ampliamente distribuido en los automóviles. Está presente prácticamente en todos los vehículos que se fabrican. Los automóviles en el mundo moderno son esencialmente un producto del mercado global, por lo que todos los vehículos tienden a tener un bus CAN. Se accede al bus CAN a través del puerto OBD, que se muestra en la figura siguiente junto con un ejemplo de una resistencia de terminación de 120 Ω, soldada al conector DB9 con el cableado CAN, ubicado en la carcasa del conector DB9. Para cablear el puerto OBD a un dispositivo CAN DB9 se necesita un cable que puede comprarse o fabricarse. Para obtener uno hecho por usted mismo, se requieren un zócalo D-sub de 9 pines (hembra) y un conector OBD (macho). El zócalo DB9 debe coincidir con el conector del dispositivo CAN. ![CAN y alternativas](https://3386484127-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 ejemplo de cableado del conector OBD al DB9 CAN, incluida también la resistencia de terminación opcional, se muestra en los esquemas a continuación. ![CAN y alternativas](https://3386484127-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) Para construir una red de sensores, conectarse a un bus CAN y ver las señales CAN de los vehículos, hay muchas opciones. Varios microcontroladores actualmente admiten el protocolo CAN y podrían conectarse a CAN mediante un chip transceptor CAN. También existen soluciones como Raspberry Pi, Texas Instruments Launchpad y Arduino, y pueden conectarse a CAN por medio de algunos complementos. La red de comunicación CAN en los vehículos modernos podría proporcionar un gran volumen de datos que puede aprovecharse para [Gestión de flotas](https://navixy.com/en/fleet-management/) aumentar la seguridad del conductor, reducir los gastos generales, mejorar los procesos de mantenimiento y apoyar la responsabilidad ambiental. Habilitar los datos del bus CAN brinda a los propietarios de flotas diversas oportunidades para acceder a diversa información, incluida el consumo de combustible, las lecturas del odómetro, las revoluciones por minuto, la posición del acelerador, la carga/par del motor, la temperatura del motor y el nivel de combustible. ## CAN inalámbrico CAN sobre un par trenzado de cables de cobre se convirtió en un estándar ISO en 1994. La creciente demanda de mayor conectividad impulsa el desarrollo de tecnologías alternativas y complementarias. Por ejemplo, algunas opciones para la transmisión inalámbrica de CAN se basan en estándares de radio basados en protocolos, como WLAN o Bluetooth. En tal escenario, los datos CAN en el transmisor deben convertirse al protocolo inalámbrico y restablecerse en el receptor. De este modo no es posible una transmisión transparente y en tiempo real en el sentido de la red CAN. La conexión de radio funciona así como una puerta de enlace entre dos redes CAN. ![CAN y alternativas](https://3386484127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-364944e1412069e50e4b64a745a959920a8b82de%2Fwireless-can-diagram.png?alt=media) El CAN inalámbrico basado en radio de modo dual permite integrar de forma inalámbrica a los participantes CAN en una red CAN, lo que aumenta la seguridad y la usabilidad. Sin embargo, un sistema de este tipo requiere antenas especiales que necesitan espacio y una alineación particular que limita la radiación omnidireccional. ## MOST, FlexRay y ethernet automotriz en breve Una alternativa prometedora a CAN es ethernet automotriz. Algunas estimaciones prevén que el mercado de ethernet automotriz crecerá más de 21.6 % durante el período de pronóstico 2019-2026. Los principales beneficios de ethernet para la conectividad vehicular son el alto ancho de banda y la eficiencia de costos. Ethernet emplea la estrategia de Acceso Múltiple con Detección de Portadora y Detección de Colisiones (CSMA/CD). La colisión puede ignorarse mediante la división en las redes vehiculares. Algunos desafíos de ethernet automotriz son la cantidad significativa de ruido de RF, la incapacidad de proporcionar una latencia del orden de microsegundos y la falta de una forma de sincronizar el tiempo entre dispositivos. MOST (Media Oriented System Transport) es un sistema de comunicación serial para transmitir datos de control, video y audio por medio de fibra óptica [http://cables.It](http://cables.it) proporciona un intercambio punto a punto de información de sonido y video con velocidades de 24.8 Mbps. MOST, creado por la asociación MOST, define las capas de protocolo, software y hardware necesarias para permitir el transporte eficiente y de bajo costo de datos de control, en tiempo real y por paquetes usando un solo medio / capa física. Una red MOST podría presentarse esquemáticamente en forma de anillo que puede incluir hasta 64 dispositivos MOST. Gracias a su funcionalidad plug\&play, agregar o quitar un dispositivo MOST debería ser bastante sencillo. FlexRay, por su parte, es esencialmente un estándar de red automotriz basado en un sistema de bus flexible, determinista, tolerante a fallas y de alta velocidad con una alta tasa de datos. Se utiliza como parte de la topología en estrella o en línea con cobre o fibra óptica. Las configuraciones de doble canal de FlexRay ofrecen una mayor tolerancia a fallas y/o un mayor ancho de banda. Las características de la red de comunicaciones FlexRay la hacen favorable para las industrias automotrices de próxima generación. ![CAN y alternativas](https://3386484127-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIgDb43gtyXcm1Av4h1np%2Fuploads%2Fgit-blob-e4b95247fd9568333d6e0f8ea1f3299162d25d40%2Fflexray_wiring.jpg?alt=media) Las redes FlexRay de primera generación normalmente emplean un solo canal para reducir los costos de cableado, pero el desarrollo posterior de las aplicaciones y los requisitos de seguridad asociados llevarán a un mayor uso de dos canales. Los factores que limitan el uso generalizado de FlexRay son el precio, los niveles de voltaje operativo más bajos y la asimetría de los flancos, lo que lleva a desafíos para extender la longitud de la red. Algunas características clave de los protocolos enumerados en comparación con las características de CAN se presentan en la tabla siguiente. ![CAN y alternativas](https://3386484127-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 comparación directa de los protocolos de conectividad enumerados muestra que existe una compensación clara entre ancho de banda y tolerancia a fallas frente a los costos promedio y la complejidad del sistema. Aunque CAN y MOST siguen siendo una especie de protocolos fundamentales, FlexRay y Ethernet son soluciones más prometedoras para satisfacer las demandas crecientes del mercado y de las aplicaciones de alta carga. En los vehículos modernos, esos protocolos suelen utilizarse como soluciones complementarias. ## Propósito de los protocolos de comunicación vehicular El bus CAN es, sin duda, un estándar de conectividad vehicular bien conocido y consolidado. Se utiliza para el tren motriz, el chasis, la red troncal y los sistemas de carrocería. Ethernet, por su parte, se usa comúnmente como protocolo de diagnóstico para las unidades de control electrónico del motor, el chasis y la carrocería utilizadas para conexiones de red. FlexRay actualmente constituye la base del desarrollo tecnológico activo en todo el mundo, y sus muchas aplicaciones incluyen sistemas X-by-Wire de próxima generación y sistemas troncales. MOST es un estándar de bus para redes multimedia vehiculares diseñado para permitir la transferencia de audio, video y datos de alta calidad. Permite la interconexión sencilla de varios componentes multimedia del vehículo. Todos los protocolos y tecnologías mencionados arriba satisfacen la mayoría de los requisitos de diagnóstico y comunicación multimedia para la comunicación vehicular moderna y de vehículo a vehículo, y podrían utilizarse para sistemas avanzados de manejo autónomo. Sin embargo, la integración precisa de esas tecnologías al mismo tiempo que se satisfacen las restricciones en tiempo real sigue siendo una parte desafiante. --- # 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/es/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.