Un ordenador de a bordo con bus CAN hace mucho más que simplemente exponer un par de terminales CAN. Debe recibir los mensajes correctos en el momento preciso, transmitir datos seleccionados a una aplicación, coexistir con dispositivos serie y enlaces inalámbricos, y mantener su fiabilidad en todas las condiciones eléctricas y ambientales del vehículo.
Para los fabricantes de equipos originales (OEM), la parte difícil comienza después de seleccionar el tamaño de la pantalla. Los equipos de integración deben acordar la arquitectura del bus, las definiciones de mensajes, la interfaz del sistema operativo, el comportamiento del servicio y las pruebas de aceptación. Esta guía proporciona una lista de verificación práctica para convertir un terminal CAN Bus en un subsistema de producción reproducible.
Ilustración de la integración del sistema PDS. El cableado, los protocolos y el comportamiento del software deben validarse en el vehículo de destino.
Defina la arquitectura del ordenador del vehículo con bus CAN antes de elegir el hardware.
Una red CAN es un bus diferencial compartido. Varias unidades de control electrónico intercambian tramas, y cada nodo receptor decide si una trama es relevante. La capa física, la velocidad de bits, la terminación, la política de conectores y el protocolo de mensajes deben coincidir con el diseño del vehículo. CSS Electronics ofrece una útil introducción al bus CAN para equipos que necesitan un vocabulario común.
La primera decisión del fabricante de equipos originales (OEM) es qué funciones puede desempeñar el ordenador del vehículo con bus CAN. Puede limitarse a monitorizar datos, solicitar un conjunto limitado de acciones, actuar como puerta de enlace o participar en una red privada. Esta función debe especificarse en el documento de control de la interfaz. Un terminal de monitorización y un controlador con capacidad de comando requieren pruebas y medidas de ciberseguridad diferentes.
Identifique también todos los autobuses conectados a la terminal. Los vehículos comerciales suelen tener redes CAN separadas para el sistema de propulsión, la carrocería, los implementos, el diagnóstico y las redes privadas. Mezclarlas sin una estrategia de aislamiento o puerta de enlace puede generar tráfico no deseado, comportamientos de activación o propagación de fallos.
| Capa de integración | Decisión de diseño | Se requiere evidencia |
|---|---|---|
| Físico | Velocidad de bits, topología, terminación, cable, conector y aislamiento | Diagrama del cableado, captura de osciloscopio o analizador y plan de compatibilidad electromagnética (CEM). |
| Protocolo | Formato CAN sin procesar, J1939, CANopen, ISO-TP, UDS o formato propietario. | Base de datos de mensajes, identificadores, diagramas de temporización y de estados. |
| Sistema operativo | Controlador, API, permisos, prioridad de proceso y recuperación | Documentación del SDK, código de ejemplo y resultados de la inyección de fallos. |
| Solicitud | Decodificación, filtrado, registro, visualización y lógica de negocio. | Casos de prueba de extremo a extremo con datos de vehículos registrados |
| Ciclo vital | Control de versiones, actualizaciones, diagnósticos y servicio técnico. | Línea base de configuración, proceso de lanzamiento y procedimiento de recuperación |
Complete una lista de verificación de la computadora del vehículo CAN Bus RS232 RS485
Los proyectos de los fabricantes de equipos originales (OEM) suelen combinar CAN con equipos seriales tradicionales. Una lista de verificación para la computadora del vehículo (CAN Bus, RS232, RS485) debe documentar cada interfaz por separado y luego probar la ruta de datos completa.
Autobús CAN
Confirme el número de canales independientes, la compatibilidad con CAN FD, las velocidades de bits, el método de terminación, el aislamiento, el comportamiento de activación y la configuración de pines del conector. Verifique si el terminal debe recibir solo tramas específicas o también transmitir mensajes. Capture la carga del bus y la latencia en el peor de los casos con el arnés completo del vehículo.
RS232 y RS485
Para un ordenador de a bordo con RS232, especifique los niveles de voltaje, la velocidad de transmisión, el control de flujo, el conector, la longitud del cable y el protocolo. RS232 suele ser punto a punto. RS485 puede utilizar operación semidúplex o dúplex completo con múltiples nodos, por lo que deben definirse los requisitos de terminación y polarización. No asuma que la misma configuración de velocidad de transmisión garantiza la compatibilidad del protocolo.
Solicite una prueba de bucle o a nivel de dispositivo antes de la instalación en el vehículo. A continuación, pruebe el tráfico simultáneo a través de CAN, ambos canales serie, USB y la conexión inalámbrica. La carga compartida del procesador y el manejo de interrupciones pueden revelar problemas que no se manifiestan en las demostraciones con una sola interfaz.
Ilustración de la integración de PDS OEM. El comportamiento de la interfaz debe confirmarse con la configuración del producto indicada.
Controlar la base de datos de mensajes y el modelo de datos.
La aplicación no debe decodificar tramas hexadecimales sin procesar en todo el código. Defina una base de datos de mensajes (DBC), asigne valores físicos y unidades, y genere una capa de decodificación probada. Incluya frecuencias de actualización, comportamiento de tiempo de espera, manejo de valores no válidos, orden de bytes, escalado y rangos de señal.
Versiona la base de datos con el software del vehículo, no solo con la aplicación del terminal. Si una ECU agrega un mensaje o modifica una señal, el equipo de integración debe saber qué terminales, modelos en la nube y casos de prueba se ven afectados. Almacena registros CAN representativos para que los cambios de decodificación puedan reproducirse sin necesidad de un vehículo.
Si el proyecto utiliza SAE J1939 , documente las direcciones de origen, los grupos de parámetros, el comportamiento de las solicitudes y el manejo de diagnósticos. Para CANopen o un protocolo propietario, proporcione máquinas de estados y definiciones de errores equivalentes.
Seleccione el sistema operativo y la API CAN.
Un ordenador de a bordo con bus CAN que ejecuta Linux puede exponer sus interfaces a través del subsistema SocketCAN del kernel. El equipo de software puede utilizar operaciones de sockets estándar, filtros y herramientas de red. Confirme la versión del kernel, el controlador CAN, la configuración del búfer de recepción y los permisos en la imagen de distribución, en lugar de hacerlo únicamente en una placa de desarrollo.
En Android, el proveedor puede ofrecer una API Java, Kotlin, nativa o JNI. Pregunte cómo reciben las aplicaciones las tramas, cómo se controla el acceso de transmisión y qué sucede cuando se reinicia el servicio. El plan de integración debe incluir un mecanismo de supervisión o comprobación de estado que permita recuperarse de un proceso detenido, una interfaz desconectada o un estado de bus pasivo ante errores.
Los proyectos de OpenHarmony deben contar con una definición de interfaz igualmente específica. Evite aceptar una declaración genérica que indique que CAN es compatible. El fabricante de equipos originales (OEM) necesita la interfaz de programación de aplicaciones (API) real, un proyecto de ejemplo, los permisos, el comportamiento del ciclo de vida y la capacidad de depuración.
Agregue GNSS y 4G LTE sin debilitar la interfaz del vehículo.
Un terminal GNSS para vehículos con bus CAN puede combinar datos de posición, movimiento y estado del vehículo. Defina la precisión requerida, la frecuencia de actualización, el formato de coordenadas, la fuente de tiempo y el servicio de corrección. Pruebe la ubicación de la antena con el techo, la cabina, la zona de carga y el equipo de radio cercano. Mantenga la pérdida de señal GNSS y el tiempo de espera del bus CAN como estados independientes para que una fuente no disponible no invalide la otra.
Un ordenador 4G LTE instalado en un vehículo extiende esos flujos de datos a una plataforma de flota, pero no se debe considerar que el enlace ascendente esté siempre disponible. Especifique las bandas compatibles, los perfiles de operador, el comportamiento de itinerancia, el aislamiento de antena, los límites de datos y el tiempo de reconexión. Utilice el almacenamiento en búfer local para los registros importantes y defina qué campos se envían de inmediato, periódicamente o solo después de un evento.
Delimite la propiedad y el acceso a los datos. Los propietarios de vehículos pueden requerir control sobre la ubicación, el diagnóstico, el conductor y los datos operativos. La plataforma de terminal y la nube necesitan políticas claras de autenticación, autorización, retención y control remoto.
Proteja la alimentación, las señales y el perímetro del software.
La alimentación del vehículo incluye la reducción de potencia durante el arranque, la descarga de carga, el arranque auxiliar y la conmutación de accesorios. La computadora del vehículo con bus CAN debe especificarse con un rango de entrada, un estándar transitorio, un fusible, una conexión a tierra y un comportamiento de encendido adecuados para la clase de vehículo en cuestión. Los puertos CAN y seriales también pueden requerir aislamiento o protección galvánica al conectarse a equipos externos.
Considere CAN como una interfaz de confianza únicamente después de que el fabricante de equipos originales (OEM) defina dicha confianza. Restrinja los identificadores de transmisión, valide las longitudes y rangos recibidos, limite la velocidad de los comandos e impida que una aplicación acceda a canales de bus no relacionados. Registre los cambios de configuración relevantes para la seguridad y admita actualizaciones de software firmadas o verificadas.
El arnés de cables debe facilitar el mantenimiento. Etiquete los conectores, documente la asignación de pines, proteja los puertos no utilizados y especifique el par de apriete cuando sea necesario. Un terminal que supera las pruebas de banco puede fallar si un arnés pesado ejerce presión sobre un conector o crea un cortocircuito que perturba el bus.
Utilice una matriz de aceptación para la liberación de producción.
| Área de prueba | Ejemplo de criterio de aceptación |
|---|---|
| Salud del autobús | No se producen errores no deseados durante las secuencias normales, de inicio, de activación y de apagado. |
| Precisión de los datos | Las señales decodificadas coinciden con las mediciones de referencia en todo el rango de funcionamiento. |
| Estado latente | Los datos críticos llegan a la aplicación dentro del plazo previsto para el proyecto. |
| Recuperación | Los servicios CAN, seriales, GNSS y celulares se recuperan después de fallas en el cable, la energía y la red. |
| Ciclos de potencia | La configuración y los datos almacenados en búfer se conservan incluso en los escenarios de encendido y batería requeridos. |
| Actualizar y revertir | Una actualización fallida puede devolver la unidad a una versión que se sabe que funciona. |
Antes de la producción, un ordenador de a bordo con bus CAN debe superar una matriz homologada de pruebas de bus, latencia, recuperación y actualización. PDS ofrece soporte para la integración con fabricantes de equipos originales (OEM) y fabricantes de diseño original (ODM) en terminales robustas para vehículos, y puede alinear las interfaces con el plan de software del proyecto. El fabricante de equipos originales (OEM) seguirá siendo el propietario de la especificación de la interfaz a nivel de vehículo y deberá aprobar el plan de validación final.
Ilustración de validación de la ficha técnica del producto (PDS). Los criterios de aceptación y el equipo de prueba deben acordarse antes del inicio de la producción.
Preguntas frecuentes
¿Qué necesita un ordenador de a bordo con bus CAN para recibir los datos del vehículo?
Requiere una interfaz CAN física compatible, la velocidad de bits y la terminación correctas, acceso al bus correspondiente, una base de datos de mensajes y software para decodificar las señales necesarias. El terminal también debe gestionar tiempos de espera, valores no válidos y fallos del bus.
¿Puede un ordenador de vehículo utilizar CAN, RS232 y RS485 simultáneamente?
Muchos ordenadores para vehículos robustos pueden admitir estas interfaces simultáneamente, pero el número exacto de canales y el nivel de aislamiento dependen del modelo. Pruebe todo el tráfico necesario al mismo tiempo y confirme que el sistema operativo expone cada interfaz de forma fiable.
¿Es J1939 lo mismo que CAN Bus?
J1939 es un protocolo de capa superior utilizado en redes CAN, principalmente en vehículos pesados. Un terminal puede admitir CAN físicamente sin admitir los mensajes J1939 específicos ni el comportamiento de diagnóstico requerido por el proyecto.
¿Los datos CAN deben procesarse en el terminal o en la nube?
Utilice la terminal para filtrado, visualización, alertas y almacenamiento en búfer con información sensible al tiempo. Envíe registros resumidos o basados en eventos a la nube cuando la disponibilidad de la red y la política de datos lo permitan. La división debe ajustarse a los requisitos de latencia, privacidad, costo y funcionamiento sin conexión.
Contáctanos
📧Correo electrónico: [email protected]
📞Tel:+86 13421822024
🌐Sitio web: www.szpds.com
Descargo de responsabilidad
La información de este artículo es solo de referencia. PDS Technology Co., Ltd. no se responsabiliza de errores, omisiones ni de la idoneidad del contenido para aplicaciones específicas. Las especificaciones del producto están sujetas a cambios sin previo aviso. Los compradores deben verificar todos los detalles técnicos con nuestro equipo antes de usar el producto.
Acerca de PDS Technology
PDS Technology es un fabricante líder de equipos originales (OEM) y diseño y fabricación de equipos originales (ODM) de terminales GNSS RTK de alta precisión y ordenadores para vehículos, que presta servicios a los sectores agrícola, de la construcción, minero, del taxi y de la logística desde 2011.
Con más de 15 años de experiencia en I+D para el sector automotriz, ofrecemos dispositivos robustos y multi-OS (Android/Linux/OpenHarmony) con posicionamiento RTK de precisión centimétrica, protección IP66 y compatibilidad con IA. Nuestras fábricas, con certificación IATF16949, han producido más de 100 000 unidades distribuidas globalmente, lo que representa más del 30 % del mercado chino de terminales de dirección automática para maquinaria agrícola. Exportamos a Japón, Estados Unidos, Reino Unido, Turquía, Rusia y otros países.
