OBD II o CANopen

Soy relativamente nuevo en CAN Bus y he estado investigando un nuevo sistema que tenemos que desarrollar para monitorear un compresor móvil. Este compresor se remolca detrás de un camión o, a veces, se deja en el sitio del proyecto. Siendo nuevo en CAN Bus, estoy tratando de averiguar cuál de los estándares CAN se ajustaría mejor al requisito: ¿OBD-II o CANopen? Los datos del compresor (móvil) deben registrarse y publicarse en la nube. El compresor móvil tiene una ECU a bordo. De mi estudio sobre el bus CAN durante los últimos días, tengo cierta comprensión de SAE J1939, OBD-II y CANopen. El primero específico para maquinaria pesada, autobuses, camiones, etc. El OBD-II para aplicaciones principalmente de automoción. Y el CANopen para aplicaciones industriales. Todavía estoy tratando de elegir entre OBD-II y CANopen. Los datos que se recopilan del compresor/ECU no son mucho: son principalmente las lecturas de temperatura, presión y nivel de aceite, y probablemente se envían una vez cada pocos segundos, excepto por cualquier falla del compresor que deba transmitirse más rápido. Cualquier sugerencia sería de gran ayuda. ¿CAN v2.0 A/B a 125 Kbps o algo así? Estoy investigando desde todos los ángulos posibles antes de tomar una decisión y unas pocas palabras de alguien con experiencia pueden ayudar mucho. Gracias una vez más. Por favor, avíseme si se necesita más información.

ingrese la descripción de la imagen aquí

¿Cómo propone sacar los "datos" de la ECU? Puede o no tener esa capacidad para empezar. A menos que esté planeando construir un sistema de adquisición de datos y luego vincularlo a un bus, y luego vincularlo a un "servidor" que transmite a una nube. Si esa es su ruta, la cuestión del "autobús" es bastante discutible. Podría ser RS-422 o USB serie o cualquier cantidad de protocolos que serían lo suficientemente rápidos.
La ECU tiene 2 interfaces CAN Bus libres (2 x CAN, 125 kbit/s hasta 1 Mbit/s). Tengo algo que decir sobre cómo el otro lado puede o debe programar (usa CodeSys 2.3) la ecu. Tiendo a inclinarme un poco hacia OBD-II porque también está diseñado para informar, telemática (¿telemetría?) Estaba pensando en Fault Tolerant CAN (ISO 11898-3) a una velocidad de aproximadamente máx. 125 KBit/s o algo así. Pero, de nuevo, esto es bastante nuevo para mí. Así que cada pieza de información que recopile podría resultar valiosa.
Por cierto, el dispositivo que estoy programando (para enviar los datos a la nube) tiene una interfaz CAN (V2.0 A/B) y la configuración GSM/GPRS necesaria. Incluso he programado el sistema para enviar algunos datos (simulados) al servidor. Usé un simulador simple para imitar el comportamiento general del sistema.
Todavía no estoy seguro de cómo obtiene el flujo de datos (si es que hay uno) "fuera" de la ECU. Ciertamente necesitarías saber más sobre esa arquitectura. Tal vez sea algún artículo de Bosch listo para usar que tenga una interfaz de este tipo, en alguna parte. O tal vez es un control industrial básico rudimentario patentado que no tiene tal capacidad, ya que nunca se anticipó que necesitaría tal cosa. Tenga en cuenta que las emisiones no son relevantes. Yo especularía que si el compresor tiene algún tipo de interfaz de diagnóstico, podría tener suerte. Si no, vuelve a su propio hardware de adquisición de datos.
Estoy agregando información que recibí sobre la ECU. Actualmente han estado programando la ECU usando CodeSys 2.3, C/C++. Encontré algunos ejemplos de código para hacer una comunicación CAN Bus en esas ECU. Por lo tanto, definitivamente es 'programable' para fines personalizados, especialmente porque tiene 2 puertos CAN Bus sin usar esperando ser usados. Por cierto, las emisiones no son un problema en absoluto porque esta ECU está conectada a un subsistema que monitorea otros parámetros y no el escape del motor, etc. Es puramente un requisito interno para ellos y no necesita cumplir con ningún estándar de emisión. Gracias
El dispositivo que está recibiendo estos datos, ¿cuál es? ¿Qué tipo de interfaz tiene?
@ user28910 He agregado algunas especificaciones. Tiene 2 interfaces CAN 1Mbit/s no utilizadas

Respuestas (1)

Para mí, estás pensando demasiado en esto. En general, RS232, CAN y LIN son solo las interfaces que permiten transferir bytes entre dispositivos, pero no definen cómo interpretar esos bytes. Ahí es donde entran en juego OBD-II, CANopen, etc. Esos son estándares con bastantes especificaciones y requieren mucho conocimiento y tiempo de programación en ambos lados. Entonces, implementarlos también es una cuestión de costos. (Y no estoy seguro si necesita licencias para desarrollar el software CANopen/ODB-II)

Como escribió, la ECU aún no tiene ninguna capacidad CAN, solo tiene el hardware y necesita ser programada. Y su dispositivo aún no ha implementado ninguna funcionalidad CAN.

También es cuestionable si realmente necesita CAN y no puede cambiar a RS232. Sí, carece de la confiabilidad de las líneas de señal diferencial, pero si su dispositivo se coloca cerca de la ECU, esto no importa. Y carece de la alta calidad de datos debido a la suma de verificación integrada, pero puede implementar su propia suma de verificación y transmitirla como datos normales. Ah, y RS232 es solo para dos dispositivos, no es un bus. Pero no necesitas esa función, ¿verdad? Un gran beneficio es que una interfaz RS232 para una PC cuesta unos cuantos dólares en comparación con una interfaz CAN, y puede escribir fácilmente algún software para emular su dispositivo o la ECU, sin tener que lidiar con bibliotecas especiales.

Entonces, implementaría mi propio protocolo simple, algo así:

Mando T<CR><LF>a pedir temperatura, y la ecu responde con T<temperatureHighbyte><temperatureLowbyte><CRC-checksum><CR><LF>. Usted lee hasta el <CR><LF>, calcula la suma de verificación usted mismo y la compara con la enviada. Si son iguales, recibió el mensaje correctamente y puede enviar el valor de temperatura recibido.

Tendrá una solución funcional de esta manera, incluso antes de tener una primera comprensión más profunda de CANopen y similares.

Muchas gracias swebber. Mi preferencia inicial era RS232 (o RS485, en caso de que sea necesario agregar varios dispositivos en algún momento), ¡los cuales me encantan! Pero he oído que, en el futuro, es posible que deseen que esta cosa de adquisición de datos funcione con otros dispositivos, todos los cuales tienen interfaces CAN. Esa fue la razón principal por la que comencé a mirar hacia CAN. Inicialmente estaba pensando en hacer RS232 al estilo NMEA ... oración del hablante con el prefijo, la suma de verificación, etc.
Y gracias por la idea de implementación propia. Inicialmente lo pensé, pero los pensamientos sobre la interoperabilidad, la expansión futura del sistema, la tolerancia a fallas del bus CAN, etc. me hicieron alejarme de él. Pero pensándolo bien, parece ser una buena idea repensar RS232.
OBD II o CANopen
RespuestasAquíPolítica de privacidad1y, 0v