> 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 protocolos de comunicación automotriz usados para conectar unidades de control electrónico (ECU), unidades de control de transmisión (TCU) y módulos de control de la carrocería (BCM) en vehículos: * **CAN**\ Un protocolo basado en mensajes que originalmente se diseñó para ahorrar cobre mediante la multiplexación del 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 sobre dos cables trenzados. FlexRay se usa a menudo en aplicaciones críticas para la seguridad, como los módulos del tren motriz. Las cargas útiles de FlexRay, o marcos de datos, pueden tener hasta 127 palabras (254 bytes) de longitud, lo cual es más de 30 veces más que las cargas útiles de CAN. * **MOST**\ Un estándar de bus para redes multimedia de vehículos 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 dentro del vehículo más utilizada. Sin embargo, con el desarrollo continuo de los vehículos autónomos y la tecnología relacionada, existe una gran demanda de mayor ancho de banda y conectividad. En este documento, describimos brevemente CAN y otras opciones de conectividad vehicular, incluyendo CAN inalámbrico, MOST, FlexRay y Ethernet automotriz. ## Bus CAN: algunos principios básicos En sentido amplio, el bus CAN (bus de red de área de controladores) en realidad es un conjunto de estándares que permiten que diferentes 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 el objetivo de interconectar unidades de control electrónico (ECU) en vehículos de motor. CAN se dividió en varias capas, siguiendo el modelo ISO/OSI para lograr flexibilidad y transparencia en el diseño. Para la comunicación en la práctica, el bus CAN utiliza dos cables dedicados: CAN low y CAN high, mediante 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 utiliza prácticamente desde máquinas de café hasta [Gestión de flotas](https://www.navixy.com/fleet-management/features/) y aplicaciones espaciales. A continuación describimos brevemente los principios de funcionamiento del bus CAN. El protocolo de comunicaciones 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 la capa física y la capa 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 bits en tramas e incluye dos protocolos: CAN clásico (primer uso retrodatado a 1988) y CAN FD (lanzado en 2012). La capa de aplicación es esencialmente una capa para el 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: el estándar tiene 11 bits, mientras que el extendido tiene 29 bits. Una estructura de mensaje estándar se puede dividir en 8 partes, como se muestra en la figura siguiente. Esas partes son: Start of Frame (SOF - el inicio de la transmisión de la trama), CAN-ID (identificador de trama, identificación de prioridad del mensaje), Remote Transmission Request (RTR, indica si un nodo solicita datos de otro nodo o envía datos), Control (informa la longitud de los datos en bytes), Data (valores reales de los datos que requieren escalarse/convertirse), La comprobación de redundancia cíclica (CRC, garantiza la integridad de los datos), ACK (acuse de recibo, indica si los datos se reciben correctamente) y EOF (End of Frame), 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 demuestra un diagrama simplificado de entrada-salida de un transceptor CAN: un flujo de bits que va hacia/desde un controlador CAN y/o microcontrolador. Cuando el controlador envía un flujo 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. En aplicaciones, ambos extremos del bus CAN deben terminarse, ya que cualquier nodo del 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 120 Ω (en un rango 100 Ω - 130 Ω). No debe haber más de dos resistencias de terminación en la red, ya que terminaciones adicionales agregan carga extra a los controladores. La imagen siguiente muestra un bus de pruebas 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 la recepción correcta de un mensaje. Los nodos B y C, a su vez, comienzan 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 la 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, ubicada en la carcasa del DB9. Para cablear el puerto OBD a un dispositivo CAN DB9 se necesita un cable que puede comprarse o fabricarse. Para hacer uno usted mismo, se requiere un zócalo D-sub de 9 pines (hembra) y un conector OBD (macho). El conector 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 del cableado del conector OBD al CAN DB9, incluyendo también la resistencia de terminación opcional, se muestra en los esquemas siguientes. ![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 tienen compatibilidad con el protocolo CAN y pueden conectarse a CAN mediante un chip transceptor CAN. También hay soluciones como Raspberry Pi, Texas Instruments Launchpad y Arduino, y pueden conectarse a CAN mediante algunos complementos. La red de comunicación CAN en los vehículos modernos puede proporcionar un gran volumen de datos que se puede aprovechar para [Gestión de flotas](https://www.navixy.com/fleet-management/features/) 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 varias oportunidades para acceder a diversa información, incluido 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 en 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. La transmisión transparente y en tiempo real en el sentido de la red CAN no es posible de esta manera. La conexión de radio, por lo tanto, funciona 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, aumentando la seguridad y la usabilidad. Sin embargo, un sistema así 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 esperan que el mercado de Ethernet automotriz crezca más del 21.6 % durante el período de pronóstico 2019-2026. Los principales beneficios de Ethernet para la conectividad de vehículos son el alto ancho de banda y la eficiencia de costos. Ethernet emplea la estrategia de Acceso Múltiple por Detección de Portadora con Detección de Colisiones (CSMA/CD). La colisión puede ignorarse mediante la división de las redes dentro del vehículo. Algunos desafíos de Ethernet automotriz son la cantidad significativa de ruido de RF, la incapacidad de proporcionar latencia hasta el rango de microsegundos bajos 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 audio 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 se puede presentar 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 de alta tasa de datos, determinista, tolerante a fallas y de alta velocidad. 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 mayor tolerancia a fallas y/o mayor ancho de banda. Las características de la red de comunicaciones FlexRay la hacen favorable para las industrias automotrices de nueva 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) La mayoría de las redes FlexRay de primera generación normalmente emplean un solo canal para reducir los costos de cableado, pero el desarrollo posterior de aplicaciones y los requisitos de seguridad implicados llevarán a un mayor uso de dos canales. Los factores limitantes para el uso generalizado de FlexRay son el precio, los niveles de voltaje de operación más bajos y la asimetría de los bordes, 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 costos promedio y complejidad del sistema. Aunque CAN y MOST siguen siendo una especie de protocolos fundamentales, FlexRay y Ethernet son una solución más prometedora para satisfacer la creciente demanda del mercado y de aplicaciones de alta carga. En los vehículos modernos, esos protocolos a menudo se usan como soluciones complementarias. ## Propósito de los protocolos de comunicación dentro del vehículo El bus CAN es, de hecho, un estándar de conectividad vehicular bien conocido y establecido. Se utiliza para el tren motriz, el chasis, la red troncal y los sistemas de la 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, y para las 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 de vehículos 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 anteriormente satisfacen la mayoría de los requisitos de diagnóstico y comunicación multimedia para la comunicación moderna dentro del vehículo y entre vehículos, 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 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/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 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.