Регистрация Войти
Вопрос

OBD-II или CANopen

Я новичок в CAN-шине и изучаю новую систему, которую нам предстоит разработать для мониторинга мобильного компрессора. Этот компрессор буксируется грузовиком или иногда остаётся на строительной площадке. Поскольку я новичок в CAN-шине, я пытаюсь понять, какой стандарт CAN лучше всего подходит для решения этой задачи — OBD-II или CANopen? Данные с (мобильного) компрессора необходимо регистрировать и отправлять в облако. На борту мобильного компрессора есть ЭБУ. За последние пару дней, изучая шину CAN, я немного разобрался в стандартах SAE J1939, OBD-II и CANopen. Первый предназначен специально для тяжёлой техники, автобусов, грузовиков и т. д. OBD-II используется в основном в автомобильной промышленности. А CANopen — в промышленности. Я всё ещё пытаюсь выбрать между OBD-II и CANopen. Данных, которые собирает компрессор/электронный блок управления, не так много — в основном это показания температуры, давления и уровня масла. Вероятно, они отправляются раз в несколько секунд, за исключением случаев, когда необходимо быстрее сообщить о неисправности компрессора. Любые подсказки будут очень полезны. CAN v2.0 A/B со скоростью 125 Кбит/с или что-то в этом роде? Я изучаю вопрос со всех возможных сторон, прежде чем принять решение, и несколько слов от человека с опытом могут мне очень помочь. Ещё раз спасибо. Пожалуйста, дайте мне знать, если потребуется дополнительная информация.



введите описание изображения здесь
Авто и транспорт

Перевод вопроса с Mechanics Stack Exchange
Лицензия: CC BY-SA (2.5–4.0)
Оригинальный вопрос: https://mechanics.stackexchange.com/questions/51727/obd-ii-or-canopen
1
+ Читать

10 Комментариев

  1. На мой взгляд, вы слишком много об этом думаете.
    В целом RS232, CAN и LIN — это просто интерфейсы, позволяющие передавать байты между устройствами, но они не определяют, как интерпретировать эти байты. Здесь в игру вступают OBD-II, CANopen и т. д. Это стандарты с большим количеством спецификаций, которые требуют обширных знаний и времени на программирование с обеих сторон. Таким образом, их внедрение также сопряжено с расходами. (И я не уверен, что вам нужны лицензии для разработки программного обеспечения CANopen/ODB-II)



    Как вы написали, ЭБУ пока не поддерживает CAN, у него есть только аппаратное обеспечение, и его нужно запрограммировать. И в вашем устройстве пока не реализована функция CAN.



    Также сомнительно, что вам действительно нужен CAN и вы не можете переключиться на RS232. Да, ему не хватает надёжности дифференциальных сигнальных линий, но если ваше устройство находится рядом с ЭБУ, это не имеет значения. И ему не хватает высокого качества данных из-за встроенной контрольной суммы, но вы можете реализовать собственную контрольную сумму и передавать её как обычные данные. Да, и RS232 предназначен только для двух устройств, это не шина. Но вам ведь не нужна эта функция, не так ли?
    Одно из главных преимуществ заключается в том, что интерфейс RS232 для ПК стоит несколько долларов по сравнению с интерфейсом CAN, и вы можете легко написать программное обеспечение для эмуляции вашего устройства или ЭБУ без использования каких-либо специальных библиотек.



    Итак, я бы реализовал свой собственный простой протокол, что-то вроде этого:



    Вы отправляете T<CR><LF> запрос на определение температуры, и ЭБУ отвечает T<temperatureHighbyte><temperatureLowbyte><CRC-checksum><CR><LF>.
    Вы считываете данные до <CR><LF>, самостоятельно вычисляете контрольную сумму и сравниваете ее с отправленной. Если они совпадают, значит, вы правильно получили сообщение и можете передать полученное значение температуры.



    Таким образом, у вас будет работающее решение ещё до того, как вы начнёте глубже разбираться в CANopen и подобных системах.
  1. И спасибо за идею собственной реализации. Сначала я думал об этом, но мысли о совместимости, будущем расширении системы, отказоустойчивости шины CAN и т. д. заставили меня отказаться от этой идеи. Но, поразмыслив, я решил, что переосмысление RS232 — хорошая идея.
  1. Большое спасибо, sweber. Изначально я отдавал предпочтение RS232 (или RS485 — на случай, если в какой-то момент потребуется добавить несколько устройств), и мне нравятся оба варианта! Но я слышал, что в будущем они могут захотеть, чтобы эта система сбора данных работала с другими устройствами, у которых есть интерфейсы CAN. Это была основная причина, по которой я начал рассматривать CAN. Изначально я думал о том, чтобы использовать RS232 в стиле NMEA... предложение с префиксом, контрольной суммой и т. д.
  1. @user28910 Я добавил некоторые характеристики. У него есть 2 неиспользуемых интерфейса CAN 1 Мбит/с
  1. Устройство, получающее эти данные, — что это за устройство? Какой у него интерфейс?
  1. Кстати, устройство, которое я программирую (для отправки данных в облако), имеет интерфейс CAN (V2.0 A/B) и необходимую настройку GSM/GPRS. Я даже запрограммировал систему на отправку некоторых (фиктивных) данных на сервер. Я использовал простой симулятор, чтобы имитировать поведение системы в целом.
  1. Я добавляю информацию, которую получил об ЭБУ. В настоящее время ЭБУ программируется с помощью CodeSys 2.3, C/C++. Я наткнулся на несколько примеров кода для подключения к шине CAN на этих ЭБУ. Так что его определенно можно «программировать» для пользовательских целей, тем более что у него есть 2 неиспользуемых порта шины CAN. Кстати, выбросы не являются проблемой, потому что этот ЭБУ подключен к подсистеме, которая отслеживает другие параметры, а не выхлопные газы двигателя и т. д. Это исключительно внутреннее требование компании, и оно не должно соответствовать каким-либо стандартам выбросов. Спасибо
  1. Я до сих пор не понимаю, как вы получаете поток данных (если он вообще есть) «из» ЭБУ. Вам определённо нужно больше знать об этой архитектуре. Возможно, это какой-то готовый продукт Bosch с таким интерфейсом. Или, может быть, это проприетарное рудиментарное базовое промышленное управление, у которого нет такой возможности, поскольку никто не предполагал, что оно понадобится. Имейте в виду, что выбросы не имеют значения. Я бы предположил, что если у компрессора есть какой-то диагностический интерфейс, то вам может повезти. Если нет, то вам придётся использовать собственное оборудование для сбора данных.
  1. ЭБУ имеет 2 свободных интерфейса CAN-шины (2 x CAN, от 125 кбит/с до 1 Мбит/с). Я могу повлиять на то, как другая сторона может или должна программировать ЭБУ (используется CodeSys 2.3). Я склоняюсь к использованию OBD-II, поскольку он также предназначен для передачи данных, телематики (телеметрии?) Я думал о отказоустойчивой сети CAN (ISO 11898-3) со скоростью около 125 кбит/с или около того. Но, опять же, для меня это в новинку. Так что любая информация, которую я соберу, может оказаться полезной.
  1. Как вы предлагаете получать «данные» из ЭБУ? Возможно, у него изначально нет такой функции. Если только вы не планируете создать систему сбора данных, а затем подключить её к шине, а затем к «серверу», который передаёт данные в облако. Если вы выбрали этот путь, то вопрос о «шине» довольно спорный. Это может быть RS-422, последовательный порт USB или любой другой протокол, который будет достаточно быстрым.
Вы уже ответили на этот вопрос