¿Qué es el bus CAN (red de área del controlador) y cómo se compara con otras redes de bus de vehículos?

¿Qué es el protocolo de bus CAN?

La red de área del controlador: el bus CAN es un protocolo basado en mensajes diseñado para permitir que las unidades de control electrónico (ECU) que se encuentran en los automóviles actuales, así como otros dispositivos, se comuniquen entre sí de manera confiable y basada en prioridades. Todos los dispositivos de la red reciben mensajes o "tramas", lo que no requiere una computadora host. CAN está respaldado por un amplio conjunto de estándares internacionales bajo ISO 11898.

¿Qué es el CAN FD?

CAN FD es una versión de "datos flexibles (velocidad)" del bus CAN. La longitud estándar de cada mensaje se ha incrementado en un 800% a 64 bytes, y la velocidad máxima de datos se ha incrementado de forma similar de 1 Mbps a 8 Mbps. La parte "flexible" se refiere al hecho de que las ECU pueden cambiar dinámicamente sus velocidades de transmisión y seleccionar tamaños de mensajes más grandes o más pequeños, según los requisitos en tiempo real.

A pesar de todos estos avances, CAN FD sigue siendo completamente retrocompatible con CAN 2.0 estándar. Hoy en día, CAN FD se encuentra en vehículos de muy alto rendimiento, pero se espera que eventualmente migre a todos o la mayoría de los vehículos.

Este video ofrece una excelente información básica sobre los buses de datos de vehículos, incluido CAN:

Ventajas del bus CAN

El estándar de bus CAN es ampliamente aceptado y se utiliza en prácticamente todos los vehículos y muchas máquinas. Esto se debe principalmente a los siguientes beneficios clave:

• Sencillo y de bajo costo: las ECU se comunican a través de un único sistema CAN en lugar de a través de complejas líneas directas de señales analógicas, lo que reduce los errores, el peso, el cableado y los costos. Los chipsets CAN están fácilmente disponibles y son asequibles.

• Totalmente centralizado: el bus CAN proporciona un punto de entrada para comunicarse con todas las ECU de la red, lo que permite el diagnóstico central, el registro de datos y la configuración.

• Extremadamente robusto: el sistema es robusto frente a perturbaciones eléctricas e interferencias electromagnéticas, ideal para aplicaciones críticas para la seguridad (p. Ej., Vehículos)

• Eficiente: las tramas CAN se priorizan por números de identificación. Los datos de máxima prioridad obtienen acceso inmediato al bus, sin interrumpir otras tramas.

• Reducción del peso del vehículo: mediante la eliminación de kilómetros de cables eléctricos fuertemente aislados y su peso del vehículo.

• Implementación sencilla: un estándar probado con un rico ecosistema de soporte.

• Resistente a EMI: esto hace que CAN sea ideal para aplicaciones críticas en vehículos.

CAN tiene excelentes capacidades de control y detección de fallas. La detección de un error se realiza fácilmente y, por lo tanto, los datos transmitidos llegan a donde deben ir.

Es un protocolo ideal cuando se requiere el control distribuido de un sistema complejo. Reduce el cableado pesado y, por lo tanto, el costo y el peso. El costo de los chips es bajo y la implementación de CAN es relativamente fácil debido al diseño limpio del protocolo.

Otra ventaja de usar CAN es que las dos primeras capas: la capa física y la capa de enlace de datos, se implementan en microchips económicos, disponibles en varias configuraciones.

Aplicaciones populares de bus CAN

Hoy en día, las aplicaciones de CAN están dominadas por el mundo de la automoción y el automóvil, pero no se limitan a eso. CAN se encuentra en prácticamente todas las industrias. Puede encontrar el protocolo CAN que se utiliza en:

• Todo tipo de vehículos: motos, automóviles, camiones ...

• Telemática de flotas de servicio pesado

• Aviones

• Ascensores

• Plantas de fabricación de todo tipo

• Buques

• Equipo medico

• Sistemas de mantenimiento predictivo

• Lavadoras, secadoras y otros electrodomésticos.

Una breve historia del bus CAN

Cuando acciona un interruptor en su casa para encender las luces, la electricidad fluye a través del interruptor hacia las luces. Como resultado, los interruptores y el cableado deben ser lo suficientemente pesados y aislados para manejar la corriente máxima esperada. Las paredes de su casa están llenas de este cableado pesado y aislado.

Los autos y camiones solían estar conectados exactamente de la misma manera: desde que Henry Ford tuvo la idea de agregar luces y una bocina eléctrica a sus autos en 1915, la electricidad fluía desde la batería a través de interruptores a las luces y otros dispositivos. En la década de 1960, había miles de cables pesados en todos los vehículos. Cada poco de peso adicional reduce la eficiencia de combustible de un vehículo.

Tras los embargos de petróleo de la década de 1970, hubo una presión creciente sobre los fabricantes de automóviles para mejorar su eficiencia de combustible. Entonces comenzaron a buscar formas de reducir el peso de los autos que estaban fabricando.

A principios de la década de 1980, los automóviles tenían cada vez más ECU (unidades de control electrónico) dentro de ellos, y empresas como la empresa alemana Robert Bosch buscaban un tipo de sistema de comunicación de bus que pudiera usarse como un sistema de comunicación entre múltiples ECU y sistemas de vehículos. . Buscaron en el mercado pero no pudieron encontrar exactamente lo que necesitaban, por lo que comenzaron a desarrollar la "Red de área de controladores" en asociación con el fabricante de automóviles Mercedes-Benz y el fabricante de semiconductores Intel®, y varias universidades en Alemania.

En 1986, Bosch presentó el estándar CAN en el Congreso SAE en Detroit. Un año después, Intel Corporation comenzó a distribuir los primeros chips controladores CAN y el mundo de la automoción cambió para siempre. Mirando hacia atrás, el ahorro de peso que resultó del desarrollo de CAN fue casi un subproducto afortunado, pero muy real de todos modos.

¿Cómo funciona la mensajería CAN?

Los dispositivos en un bus CAN se denominan "nodos". Cada nodo consta de una CPU, un controlador CAN y un transceptor, que adapta los niveles de señal de los datos enviados y recibidos por el nodo. Todos los nodos pueden enviar y recibir datos, pero no al mismo tiempo.

Los nodos no pueden enviarse datos directamente entre sí. En cambio, envían sus datos a la red, donde están disponibles para cualquier nodo al que se hayan dirigido. El protocolo CAN no tiene pérdidas y utiliza un método de arbitraje bit a bit para resolver disputas en el bus.

Todos los nodos están sincronizados para que todos muestren datos en la red simultáneamente. Sin embargo, los datos no se transmiten con datos de reloj (hora), por lo que CAN no es realmente un bus síncrono, como EtherCAT, por ejemplo.

Con CAN, todos los datos se envían en tramas y hay cuatro tipos:

• Los marcos de datos transfieren datos a uno o varios nodos receptores

• Los marcos remotos solicitan datos de otros nodos

• Los marcos de error informan errores

• Los marcos de sobrecarga informan sobre las condiciones de sobrecarga

Hay dos variantes de la longitud del mensaje: estándar y extendido. La verdadera diferencia es el identificador adicional de 18 bits en el campo de arbitraje.

Estructura del mensaje de datos CAN (trama CAN)

El campo de arbitraje contiene el número de identificación del mensaje y el bit de solicitud de transmisión remota. Los mensajes más importantes tienen números de identificación más bajos.

Si varios nodos transmiten al mismo tiempo, inician un arbitraje simultáneo. El nodo con el número de ID de mensaje más bajo tiene prioridad. Los bits dominantes sobrescriben los bits recesivos en el bus CAN.

El identificador de mensaje puede ser de 11 bits (CAN estándar, 2048 identificadores de mensaje diferentes) o de 29 bits de longitud (CAN extendido, 537 millones de identificadores de mensaje diferentes). El bit de solicitud de transmisión remota es dominante e indica que se están transmitiendo datos.

En la mayoría de los sistemas, el 1 lógico representa un valor alto y el 0 lógico un valor bajo. Pero esto es al revés en el bus CAN. Por lo tanto, los transceptores CAN suelen utilizar un pull-up en las entradas del controlador y las salidas del receptor, de modo que los dispositivos se han predeterminado en un estado de bus recesivo.

Variaciones del bus CAN

El estándar ISO 11898 define varias versiones de CAN. Los tipos de CAN dominantes utilizados en la industria del automóvil son:

• CAN de baja velocidad

• CAN de alta velocidad

• CAN FD (CAN con velocidad de datos flexible)

CAN de baja velocidad

Se utiliza para sistemas tolerantes a fallas que no requieren altas tasas de actualización. La velocidad máxima de transferencia de datos es de 125 kbps, pero el cableado es, por tanto, más económico que el CAN de alta velocidad. En aplicaciones automotrices, la CAN de baja velocidad se utiliza para diagnósticos, controles y pantallas del tablero de instrumentos, ventanas eléctricas, etc.

CAN de alta velocidad

Se utiliza para comunicaciones entre subsistemas críticos que requieren altas tasas de actualización y alta precisión de datos (por ejemplo, sistema de frenos antibloqueo, control electrónico de estabilidad, bolsas de aire, unidades de control del motor, etc.). Las velocidades de transferencia de datos de CAN de alta velocidad varían de 1 kbit a 1 Mbit por segundo.

La CAN de alta velocidad es más rápida que la de baja velocidad, pero el requisito de ancho de banda de las nuevas aplicaciones automotrices aumenta cada año, por lo que los fabricantes de equipos originales (OEM) de automóviles están instalando CAN FD en automóviles nuevos. CAN FD se ha descrito irónicamente como "CAN con esteroides".

CAN FD (Velocidad de datos flexible CAN)

La última versión de CAN presenta una tasa de datos flexible, más datos por mensaje y transmisiones de mayor velocidad. La longitud de datos dentro de cada mensaje CAN estándar (baja y alta velocidad) es de 8 bytes, pero con CAN FDhttps://en.wikipedia.org/wiki/CAN_FD

esto se ha aumentado un 800% a 64 bytes de datos. Además, la velocidad de datos máxima también se ha incrementado drásticamente de 1 Mbps a 8 Mbps.

CAN FD también es compatible con versiones anteriores y admite el protocolo de comunicación CAN 2.0, así como protocolos especiales como SAE J1939, donde CAN out se usa como solo lectura. CAN FD es esencialmente una extensión del estándar CAN original como se especifica en ISO 11898-1, y es totalmente compatible con los sistemas CAN clásicos.

CAN FD es un importante paso adelante porque permite que las ECU cambien dinámicamente sus velocidades de transmisión y seleccionen tamaños de mensajes más grandes o más pequeños, según los requisitos en tiempo real. Ahora se encuentra en vehículos de alto rendimiento, pero a medida que aumenta el rendimiento de la ECU y disminuyen los costos de hardware de CAN FD, es solo cuestión de tiempo antes de que CAN FD llegue a prácticamente todos los vehículos.

Estándares y protocolos CAN adicionales

¿Por qué necesitamos estándares y protocolos adicionales “por encima” de CAN? Es simplemente porque, si bien CAN es un protocolo elegante y confiable, eso es realmente todo. Es un sistema de mensajería, pero no incluye ninguna forma de analizar o comprender los datos dentro de los mensajes. Es por eso que varias empresas han creado estándares y protocolos adicionales que se ejecutan dentro o encima de CAN, tienen funcionalidades adicionales. Los más conocidos de estos incluyen:

SAE J1939 en CAN

El protocolo SAE J1939 se desarrolló originalmente para ser utilizado por camiones pesados y camiones con remolque en los EE. UU. Hoy en día lo utilizan los fabricantes de motores diésel de todo el mundo. J1939 es un protocolo de nivel superior que se ejecuta en la capa física CAN. Proporciona algunas funciones útiles específicas para camiones pesados, como camiones de 18 ruedas.

El protocolo tiene algunas restricciones que se implementaron intencionalmente para promover la mayor confiabilidad posible, incluida la limitación del identificador del mensaje a 29 bits y la limitación de la velocidad del bus a 250 o 500 kbps.

El software DewesoftX permite al ingeniero seleccionar la decodificación J1939 a través de una casilla de verificación en la pantalla de configuración de CAN para cualquier puerto CAN disponible. Por supuesto, esto supone que los mensajes en el bus CAN están formateados de acuerdo con el estándar J1939. Los mensajes de datos tienen la misma longitud que el estándar CAN ampliado.

El campo de arbitraje contiene una dirección adicional de origen y destino, y la velocidad en baudios está limitada a 250 kbps o 500 kbps, según la versión estándar J1939 que se utilice. J1939 es una selección en la pantalla de configuración estándar de Dewesoft X CAN; no se requiere hardware o software adicional.

Aprende más:

• Configuración de CAN, incluidos los datos J1939, con DewesoftX

OBD II (también conocido como "OBD 2")

Este puerto de diagnóstico a bordo se encuentra en todos los automóviles fabricados desde 1989. Por lo general, ubicado a 2 pies (0,61 metros) del volante, es una interfaz que permite a los talleres de reparación de automóviles y a los propietarios de vehículos diagnosticar problemas del vehículo conectando un escaneo. herramienta a su conector de 16 pines. (En la foto, debajo del volante del Toyota 4Runner 2016).

Las herramientas de escaneo pueden leer el DTC (códigos de diagnóstico de fallas) reportados por el vehículo. La interfaz OBD II es necesaria para transportar docenas de canales de datos en tiempo real, como RPM, velocidad del vehículo, temperatura del refrigerante y más. Las interfaces CAN Dewesoft se pueden conectar a este conector OBD II como se muestra a continuación, y pueden leer, mostrar y registrar cualquiera o todos estos canales en sincronización con los demás datos que se están grabando.

La decodificación, visualización y grabación de mensajes ODB II en sistemas Dewesoft requieren un complemento de software ODB II adicional. Puede escanear DTC (códigos de diagnóstico de problemas) y mucho más con este sistema.

Aprende más:

• OBD II en el software Dewesoft

XCP / CCP en CAN y Ethernet

El Protocolo universal de medición y calibración (XCP) fue diseñado para conectar ECU a sistemas de calibración. El "universal" en su nombre se refiere al hecho de que puede ejecutarse en la parte superior del bus CAN, CAN FD, FlexRay, Ethernet y más. Es el sucesor del CAN Calibration Protocol (CCP) original desarrollado en la década de 1990.

Dewesoft admite los protocolos XCP / CCP a través de los complementos XCP / CCP Master y XCP / CCP Slave que se ejecutan en el software DewesoftX DAQ. Se puede utilizar hardware de interfaz estándar Dewesoft CAN (y ethernet).

Además de estos complementos XCP esclavo y maestro, los sistemas de adquisición de datos SIRIUS XHS e IOLITE LX de Dewesoft pueden servir datos de forma nativa a través de XCP en Ethernet sin la necesidad de ningún software adicional. Mire este breve video introductorio para obtener más información sobre los sistemas de adquisición de datos XCP de Dewesoft y los registradores de datos XCP:

Aprende más:

• XCP Slave DewesoftX Manual

• Manual de XCP Master DewesoftX

CANopen

CANopen es un protocolo de capa superior que se utiliza para aplicaciones de control integradas. Debido a que se basa en el protocolo de mensajería CAN, los sistemas DAQ y los registradores de datos que pueden leer y registrar datos CAN también pueden acceder a los datos de CANopen.

CANopen se inventó para proporcionar una fácil interoperabilidad entre dispositivos en sistemas de control de movimiento. La comunicación entre dispositivos se implementa a un alto nivel y también se admite la configuración de dispositivos. Se utiliza mucho en aplicaciones de control de movimiento, robótica y control de motores.

CANopen está gestionado por la organización internacional CAN in Automation - CiA. Establecido en Alemania en 1992, CiA es un grupo internacional de usuarios / fabricantes sin fines de lucro para CAN. Se enorgullecen de ser una plataforma imparcial para el desarrollo del protocolo CAN y para promover la imagen de la tecnología CAN.

CANopen proporciona varios conceptos adicionales, que incluyen:

Tres modelos básicos de comunicación

• Maestro / esclavo: donde un nodo es el "maestro" y todos los demás son esclavos.

• Cliente / Servidor: algo similar a maestro / esclavo, excepto que los nodos son servidores de datos cuando se solicitan a un nodo cliente.

• Productor / Consumidor: donde ciertos nodos están configurados para producir ciertos tipos de datos automáticamente, mientras que otros nodos están configurados para consumirlos.

Dos protocolos de comunicación básicos

• SDO para la configuración de nodos

• PDO para enviar datos en tiempo real

Perfiles de dispositivos

• Módulos de entrada / salida CiA 401

• Control de movimiento CiA 402 para independencia del proveedor

Diccionario de objetos

Hay un OD (Diccionario de objetos) para cada dispositivo en la red. El OD tiene una configuración estándar para los datos que define la configuración de cada dispositivo en la red.

Estados del dispositivo

Un nodo maestro es capaz de cambiar o restablecer el estado de los dispositivos en la red.

Hojas de datos electrónicos (EDS)

El EDS es un formato de archivo estándar para entradas OD, que permite, por ejemplo, herramientas de servicio para actualizar dispositivos

Buses de comunicación relacionados

Además de CAN y los protocolos que se ejecutan en él descritos en las secciones anteriores, existen otros buses de comunicación que se utilizan para aplicaciones de vehículos:

• MOST (transporte de sistemas orientados a medios)

• Ethernet automotriz

• SENT SAE-J2716

• FlexRAY

• Bus LIN: red de interconexión local

Today's modern vehicles use a combination of multiple data buses. Let's take a look at each one of these and see how they compare to a CAN bus.

MOST (transporte de sistemas orientados a medios)

Todos esperan que su nuevo automóvil tenga un sistema de entretenimiento mejor y más capaz que su automóvil anterior. La radio AM / FM anticuada que era estándar durante más de 50 años se ha transformado para aceptar medios extraíbles, desde los viejos tiempos de casetes y cintas de 8 pistas hasta discos compactos (CD) y medios flash extraíbles. Hoy en día, la atención se centra en la transmisión de contenido desde dispositivos móviles y radio satelital (SIRIUS / XM® en Norteamérica).

El transporte de sistemas orientados a los medios (MOST) es un autobús estándar que se utiliza para interconectar los sistemas de información y entretenimiento de vehículos desarrollados por una asociación de fabricantes de automóviles llamada MOST Cooperación. Ofrece velocidades de datos de 25, 50 y 150 Mb / s. Pero debe tenerse en cuenta que se trata de tarifas agregadas que se dividen entre todos los nodos del bus.

MOST se utiliza en casi todas las marcas de automóviles del mundo. Se pueden conectar hasta 64 dispositivos a una red MOST en anillo, lo que permite que los dispositivos se conecten o desconecten fácilmente. También son posibles otras topologías, incluidas las estrellas virtuales. Hay varias versiones de MOST, que incluyen:

• MOST25 ofrece una velocidad de transmisión máxima de 23 MB, que en realidad está limitada a unos 10 kB / s debido a la sobrecarga del protocolo y otras limitaciones.

• MOST50 duplica el ancho de banda de MOST25.

• MOST150 triplica el ancho de banda de MOST50 y agrega una capa física que permite agregar Ethernet.

MOST se enfrenta a una competencia cada vez mayor de Automotive Ethernet, que se analiza a continuación.

Ethernet automotriz

Las nuevas tecnologías como la asistencia al conductor e incluso las funciones de vehículos autónomos / autónomos requieren un ancho de banda cada vez mayor para funcionar. Esta necesidad de velocidad, junto con el bajo costo del hardware Ethernet, ha sido un factor importante en la promoción de Ethernet automotriz entre los fabricantes de automóviles. Otras motivaciones para ethernet automotriz incluyen las tasas de transferencia necesarias para LIDAR y otros sensores, datos de cámara sin procesar, datos de GPS, datos de mapas y pantallas planas de resolución cada vez más alta.

Pero a diferencia de nuestros cómodos entornos domésticos y de oficina, un vehículo está sujeto a una gama mucho más amplia de temperaturas, golpes y vibraciones continuas. Además, hay EMI y RFI que deben bloquearse para que no se interfiera con los datos críticos, especialmente los relacionados con la asistencia al conductor y la prevención de colisiones.

El término "Ethernet automotriz" no se refiere a un estándar específico per se. Incluye cualquier red basada en Ethernet utilizada dentro de los vehículos. También está destinado a hacer referencia al estándar OPEN Alliance BroadR-Reach desarrollado por Broadcom y a IEEE 802.3bw-2015 también conocido como 100Base-T1.

A pesar de sus obvias ventajas de velocidad y popularidad mundial, hasta los últimos años ethernet solo se usaba para aplicaciones de diagnóstico en automóviles, en otras palabras, cuando el automóvil estaba en servicio y no se movía. ¿Por qué? Debido a su susceptibilidad a EMI (interferencia electromagnética) y RFI (interferencia de radiofrecuencia), falta de sincronización de tiempo determinista inherente y susceptibilidad a fallas del conector debido a la vibración. Los conectores CAT5 estándar, por ejemplo, no pueden sobrevivir en automóviles con un uso normal.

Sin embargo, estos problemas están siendo abordados por los grupos de trabajo de IEEE 802.3 y 802.1. Mientras tanto, el fabricante de chips Broadcom ha desarrollado BroadR-Reach ™, que adapta la tecnología Ethernet para uso automotriz. BroadR-Reach proporciona una velocidad de 100 Mb / s utilizando cableado de par trenzado sin blindaje de hasta 15 metros, o hasta 40 metros cuando se agrega un blindaje a los cables.

Algunos fabricantes de automóviles han adoptado BroadR-Reach para sistemas de información y entretenimiento, asistencia al conductor, diagnósticos a bordo e incluso aplicaciones ADAS. Ofrece velocidades de datos de 100 Mbps por puerto, que es mucho más alta que la velocidad total de 150 Mbps de MOST, por ejemplo.

El estándar BroadR-Reach está supervisado por OPEN (One-Pair Ether-Net) Alliance, que aboga por la adopción de Ethernet automotriz.

Ethernet AVB (puente de audio y video) es el estándar IEEE AVB1.0. Se está moviendo hacia la aceptación para su uso con cámaras y sistemas multimedia. AVB2.0 está destinado a aplicaciones de control de vehículos. AVB es promovido por AVnu Alliance.

Ethernet TSN (redes sensibles al tiempo) es el estándar IEEE 802.1 diseñado para permitir la mensajería determinista a través de Ethernet estándar. No es un protocolo en sí, TSN es un estándar implementado en la Capa 2 de Ethernet OSI, es decir, la capa de Datos (AVB también es un estándar de Capa 2).

Como una extensión de Ethernet AVB descrita anteriormente, TSN se enfoca en el tipo de sincronización de tiempo, programación y modelado de paquetes que son necesarios para las aplicaciones de vehículos autónomos. Debido a que TSN tiene que ver con el “tiempo”, se han seleccionado los protocolos de tiempo de precisión (PTP) IEEE 802.1AS e IEEE 802.1ASRev para proporcionar un concepto compartido de tiempo entre dispositivos.

Aprende más:

• Automotive Ethernet OPEN Alliance

• IEEE TSN/AVB Standards

• BroadR-Reach

• Ethernet TSN (includes AVB)

Según Gartner, en 2017 hubo un total de 19,3 millones de puertos ethernet instalados en vehículos de consumo. Para 2020, esto ha aumentado a 122,8 millones, una cifra que se prevé que se duplique para 2023.

SENT SAE-J2716

SENT SAE-J2716 (Transmisión nibble de un solo borde) fue diseñado para ser una alternativa de protocolo de bajo costo a CAN o LIN. Es un protocolo de transmisión unidireccional que permite a los sensores enviar sus datos a las ECU.

Los datos se codifican mediante modulación de código de impulsos (PCM) y se transmiten por un solo cable. Hay tres cables en total: señal, tierra y alimentación. Los datos se codifican en "nibbles" de 4 bits.

Un mensaje SENT típico es de 32 bits (8 nibbles), compuesto por:

• Datos de señal: 24 bits (6 nibbles)

• Detección de error CRC: 4 bits (1 nibble)

• Información de estado: 4 bits (1 nibble)

También es posible configurar mensajes de 20 bits (5 nibbles), donde los datos son solo de 12 bits (3 nibbles).

Debido a su diseño de datos modulados, SENT es ideal para su uso en entornos eléctricamente ruidosos.

Los sistemas Dewesoft admiten datos ENVIADOS SAE-J2716 utilizando canales de contador para leer una señal ENVIADA que está siendo transmitida por un sensor. Dos canales rápidos y cualquier número de canales lentos, que se pueden detectar automáticamente. Los ingenieros pueden decodificar señales SENT de múltiples sensores simultáneamente donde cada sensor usa un contador diferente, agregando múltiples ventanas de módulo. Los canales ENVIADOS están disponibles como canales Dewesoft.

Aprende más:

• Canales ENVIADOS en el software DewesoftX

FlexRAY

FlexRAY es un protocolo utilizado para aplicaciones automotrices dinámicas como el control de chasis. Fue creado en 2005 por el Consorcio FlexRAY, pero desde entonces ha sido estandarizado bajo ISO 17458-1 a 17458-5.

FlexRAY transmite datos a través de uno o dos cables de par trenzado sin blindaje. Funciona a 10 Mbps y admite configuraciones de uno o dos cables. Se admiten topologías de red de bus, estrella e híbridas, a velocidades de hasta 10 Mbps. La señalización diferencial mantiene el ruido bajo sin la necesidad de cables blindados, lo que agrega costo y peso.

Al igual que con CAN, solo un nodo puede escribir en un bus FlexRAY al mismo tiempo. CAN usa un bit de arbitraje para determinar qué datos tienen prioridad y pueden continuar. FlexRAY, por otro lado, utiliza un método de acceso múltiple por división de tiempo (TDMA) en el que cada nodo sincronizado en el tiempo debe esperar su turno para enviar un mensaje. Esto evita colisiones y permite un mayor rendimiento general de datos a través del bus debido a la alta velocidad de datos general del bus.

FlexRAY se implementa a menudo en la topología multipunto clásica compartida por LIN y CAN; sin embargo, también se puede configurar en una topología en estrella. La topología en estrella tiene la ventaja de no permitir que una falla de cableado afecte a más de un nodo. FlexRAY también se puede implementar en una topología mixta, como se muestra a continuación.

FlexRAY se utiliza con mayor frecuencia para aplicaciones de control de chasis activo, seguridad y tren motriz de alto rendimiento. FlexRAY es más caro que una implementación de bus CAN.

Sin embargo, cuando se utilizan pares duales de líneas de datos paralelas, esto proporciona redundancia: cuando una línea está dañada, la segunda línea puede asumir el control. Esto es importante en aplicaciones de misión crítica como la dirección y el frenado. Las aplicaciones FlexRAY que no son de misión crítica suelen utilizar un solo par trenzado.

Los sistemas Dewesoft pueden adquirir fácilmente datos FlexRAY utilizando la opción de importación de la biblioteca FIBEX. Hay un complemento de software disponible para admitir todas las tarjetas de interfaz Vector FlexRay.

LIN Bus - Red de interconexión local

LIN bus es una alternativa económica al bus CAN. Es muy simple pero necesariamente se limita a un maestro y 15 nodos esclavos. LIN es un sistema de mensajería unidireccional en serie, donde los esclavos escuchan identificadores de mensajes dirigidos a ellos.

Debido a su menor ancho de banda y limitaciones de recuento de nodos, LIN se usa normalmente para controlar pequeños motores y controles eléctricos. LIN está limitado a una velocidad de datos de 19,2 kbps o 20 kbps.

LIN es una red de un solo cable definida por ISO 9141. Se utiliza para aplicaciones de bajo ancho de banda como ventanas eléctricas, luces, cerraduras de puertas, sistemas de entrada con tarjeta, espejos eléctricos, asientos eléctricos y similares.

El complemento de bus LIN para DewesoftX permite a los ingenieros conectarse y escuchar la comunicación en múltiples redes LIN. Utilizando hardware LIN BUS de la marca Vector, imita a los esclavos de solo escucha que escuchan toda la transmisión de datos en el bus. La decodificación se puede realizar de tres formas diferentes:

• Datos analógicos con amplias opciones de escalado

• Datos discretos

• Una mezcla de ambos

El complemento admite la importación de la configuración desde archivos de descripción LIN (LDF). Para leer el bus LIN, se requiere una tarjeta Vector LIN BUS.

Comparación de CAN con otros autobuses de vehículos

Notas: * UTP = par trenzado sin blindaje

Al igual que con cualquier sistema de red e interoperable, la elección del bus automotriz se basa mejor en los requisitos de la aplicación, sin perder de vista los costos y los requisitos y tendencias proyectados de la industria. Claramente, los fabricantes de automóviles no quieren implementar autobuses viejos en nuevos diseños, cuando hay mejores autobuses disponibles a un costo de implementación equivalente o mejor.

Sistemas DAQ de bus CAN Dewesoft

Las interfaces de bus CAN proporcionadas como estándar u opcionales con los sistemas Dewesoft proporcionan un alto nivel de capacidad, así como también extensibilidad a protocolos adicionales.

Todas las interfaces CAN de Dewesoft están aisladas galvánicamente, lo que protege el instrumento y los dispositivos conectados de bucles de tierra y otras perturbaciones eléctricas. Todas las interfaces CAN de Dewesoft utilizan el estándar CAN 2.0b de alta velocidad. Dewesoft también ofrece un dispositivo CAN FD.

Todas las interfaces CAN de Dewesoft pueden leer y escribir mensajes CAN, lo que permite a los ingenieros colocar mensajes en el bus para solicitar datos de dispositivos CAN en la red y más.

Toda la interfaz CAN de Dewesoft se puede configurar en segundos, porque el software de adquisición de datos DewesoftX incluido puede importar archivos DBC. Los archivos DBC son un formato estándar que permite a los ingenieros analizar el flujo de datos en canales individuales con nombres, escalas, unidades de ingeniería adecuadas y más.

Al hacer clic en el botón "Configuración" en el extremo derecho de cualquier fila de mensajes, se abre la pantalla de configuración del canal CAN que se muestra a continuación:

DewesoftX hace que sea extremadamente fácil configurar los canales CAN. El software puede importar y exportar archivos CAN DBC o XML. Los archivos DBC son archivos comunes para la definición de canales y mensajes CAN. Después de la importación, el software configurará automáticamente todos los canales CAN disponibles y decodificará los mensajes CAN.

Capacidades del software DewesoftX CAN

• Grabación, almacenamiento y análisis avanzados de CAN

• Monitoreo y decodificación en línea de mensajes CAN

• Decodificación de mensajes CAN fuera de línea

• Pantalla visual para mostrar datos CAN

• Análisis matemático en línea y fuera de línea de canales CAN

• Importación y exportación de archivos CAN DBC

• Compatibilidad con OBDII en CAN, J1939 y XCP / CCP

• PUEDE transmitir funcionalidad

Interfaces de bus CAN Dewesoft

Dewesoft fue uno de los primeros fabricantes de sistemas DAQ en implementar completamente interfaces de bus CAN con su sistema de adquisición de datos analógicos. Casi todos los sistemas DAQ de Dewesoft tienen al menos una interfaz de bus CAN incorporada de serie, y se puede agregar una interfaz CAN dedicada adicional internamente, externamente o ambas, mientras se mantiene una sincronización perfecta.

Ya en 2008, se introdujo el DEWE-43 original, con dos interfaces de bus CAN de alta velocidad como característica estándar. Algo muy importante que debe saber es que los datos CAN que ingresan a estos puertos están totalmente sincronizados por hardware con los datos analógicos, así como con los datos del contador / entrada digital. La interfaz CAN de Dewesoft también está aislada galvánicamente, lo que protege tanto al instrumento como al bus de los bucles de tierra y otros problemas eléctricos.

Menos de un año después de su presentación, el DEWE-43 fue galardonado con el producto elegido por los lectores del año de la NASA TECH BRIEFS por sus innovaciones en la combinación de la potencia y la capacidad de DAQ en un instrumento increíblemente pequeño.

En la actualidad, Dewesoft ofrece soporte para varias interfaces automotrices estándar para analizar e inspeccionar datos de buses de vehículos. Los datos se pueden capturar de todas las interfaces compatibles y sincronizar con otras fuentes como analógicas, video y otras.

Sistemas DAQ Dewesoft con interfaces CAN incorporadas

Como se mencionó anteriormente, casi todos los sistemas DAQ Dewesoft tienen al menos un puerto CAN integrado como estándar, y todos los sistemas pueden equiparse con CAN si no es estándar, de acuerdo con esta tabla:

Interfaces CAN externas sincronizables

Además de los puertos CAN integrados en casi todos los sistemas DAQ Dewesoft, se encuentran disponibles interfaces CAN independientes sincronizables de 2, 4 y 8 puertos. Estos se conectan a una computadora con Windows que ejecuta el software Dewesoft X oa un sistema DAQ Dewesoft a través de USB y un cable de sincronización.

Módulo KRYPTONi-1xCAN-FD

El último miembro de la familia de buses CAN Dewesoft es el KRYPTONi-1xCAN-FD. Este es un dispositivo CAN FD de un solo puerto que se conecta al sistema DAQ a través de EtherCAT®. Admite velocidades de datos CAN de alta velocidad de hasta 8 Mbps. Además, CAN FD admite el protocolo de comunicación CAN 2.0, así como protocolos especiales como J1939.

KRYPTONi-1xCAN-FD tiene líneas de comunicación aisladas galvánicamente y un suministro de sensor aislado de +5 V y +12 V. El límite de potencia del suministro del sensor es de 1,4 vatios.

Debido a que este módulo es miembro de la galardonada línea de productos KRYPTON ONE, puede soportar condiciones ambientales extremas, como un rango de temperatura de funcionamiento de -40 ° C y +85 ° C (-40 a + 185 ° F), y Sellado contra polvo y líquidos según IP67.

KRYPTONi-1xCAN-FD se suministra en un chasis KRYPTON ONE estándar con un conector de entrada DSUB9.