В прошлом году при настройке системы управления автопарком для логистической компании клиент захотел в режиме реального времени отслеживать расход топлива, обороты двигателя и температуру охлаждающей жидкости для каждого грузовика. Данные должны были не просто храниться локально, а передаваться на облачную платформу, чтобы диспетчеры могли следить за состоянием автомобиля.

Звучит достаточно просто. Но когда мы приступили к работе, оказалось, что извлечь данные из автомобиля гораздо сложнее, чем ожидалось. Вся информация о транспортном средстве передается по шине CAN, но форматы сообщений у разных моделей автомобилей сильно различаются. Считывание оборотов двигателя с грузовика FAW и грузовика Dongfeng означает работу с совершенно разными идентификаторами сообщений CAN, позициями полей данных и коэффициентами преобразования.

В итоге для решения этой проблемы мы использовали двойной автомобильный шлюз 5G. Шлюз подключается к шине автомобиля через CAN-интерфейсы, анализирует все сообщения, а затем загружает все через сеть 5G в облако. Этот проект дал мне глубокое понимание того, как автомобильные шлюзы и шина CAN должны работать вместе.

Что делает шина CAN в транспортных средствах

Давайте начнем с того, что же на самом деле представляет собой шина CAN. CAN расшифровывается как Controller Area Network (сеть контроллеров). Компания Bosch разработала эту коммуникационную шину для использования в автомобилях еще в 1980-х годах.

Зачем нам нужна шина CAN? Современные автомобили оснащены десятками и даже сотнями электронных блоков управления. ЭБУ двигателя, ЭБУ трансмиссии, ЭБУ ABS, ЭБУ комбинации приборов, ЭБУ управления кузовом - список можно продолжать. Этим ЭБУ необходимо взаимодействовать. Если бы вы прокладывали отдельные провода между каждой парой ЭБУ, жгут проводов превратился бы в кошмар.

Шина CAN соединяет все ЭБУ в одну общую шину. Подумайте об этом как о линии метро - все станции расположены на одном маршруте. Любой ЭБУ может отправлять сообщения, которые получают все остальные ЭБУ. Каждый ЭБУ выборочно обрабатывает сообщения, относящиеся к его функции.

Коммерческие автомобили обычно используют 2-3 отдельные шины CAN. CAN трансмиссии соединяет двигатель, трансмиссию, ABS и другие ЭБУ трансмиссии, обычно работая на скорости 500 или 250 кбит/с. CAN кузова управляет светом, замками, климат-контролем и системами комфорта, обычно на скорости 125 кбит/с. Также может присутствовать специальная диагностическая шина CAN.

Автомобильные шлюзы должны подключаться к этим шинам CAN, чтобы считывать данные. Возьмем, к примеру, SV910 - он оснащен 3 портами CAN, которые могут одновременно подключаться к нескольким автомобильным шинам CAN.

Процесс чтения данных CAN

 

 

Как именно считывать эти данные? В качестве примера рассмотрим чтение оборотов двигателя.

Шаг первый - физическая связь. Подключите CAN-интерфейс шлюза к диагностическому порту OBD автомобиля или непосредственно к шине CAN. Коммерческие автомобили, как правило, имеют стандартные порты OBD, обычно расположенные под приборной панелью или рядом с водительским сиденьем. Разъем имеет трапециевидную форму с 16 контактами.

В шине CAN используется дифференциальная сигнализация с двумя проводами: CAN_H и CAN_L. На разъеме OBD контакт 6 - это CAN_H, а контакт 14 - CAN_L. Интерфейс CAN шлюза имеет соответствующие провода - просто совместите их. Важное замечание: для предотвращения отражения сигнала на концах шины CAN необходимы согласующие резисторы 120 Ом. В некоторых шлюзах согласующие резисторы встроены внутрь и настраиваются с помощью программного обеспечения.

Шаг второй - настройка скорости передачи данных. Скорость передачи данных по шине CAN должна совпадать, иначе вы не получите никаких данных. CAN трансмиссии коммерческих автомобилей обычно работает на скорости 250 или 500 кбит/с - сначала необходимо проверить. Обратитесь к руководству по обслуживанию автомобиля или проверьте с помощью профессионального CAN-анализатора.

Настройте CAN-интерфейс шлюза на ту же скорость передачи данных. Такие шлюзы, как SV910, поддерживают несколько скоростей передачи данных, настраиваемых с помощью конфигурационных файлов или интерфейсов управления.

Третий этап - мониторинг и разбор сообщений CAN. Данные по шине CAN передаются в виде кадров. Каждый кадр содержит несколько частей: идентификатор сообщения, длина данных, содержание данных, контрольная сумма.

Идентификатор сообщения - это ключ к определению того, что содержит каждое сообщение. Для оборотов двигателя такие стандарты, как GB/T 27930 и SAE J1939, определяют идентификаторы. Стандарт J1939 распространен для коммерческих автомобилей - для RPM двигателя используется идентификатор 0x0CF00400 с данными в байтах 4 и 5.

Шлюз непрерывно контролирует шину CAN, перехватывает кадры с определенными идентификаторами, а затем извлекает значения оборотов из байтов данных. Извлеченное значение - это необработанные данные, которые необходимо преобразовать в фактическое число оборотов по формуле. В стандарте J1939 разрешение оборотов двигателя составляет 0,125 об/мин/бит, поэтому умножьте необработанное значение на 0,125 для получения истинных оборотов.

Четвертый этап - упаковка и загрузка данных. После разбора значения RPM шлюз упаковывает его в соответствующий формат для загрузки через сеть 5G в облако. К распространенным форматам относятся JSON, Protobuf и сообщения MQTT.

Частота загрузки зависит от требований. Мониторинг в режиме реального времени может требовать обновления каждую секунду, в то время как для общего управления автопарком могут использоваться интервалы в 10 или 30 секунд. Более высокая частота означает более высокую стоимость данных.

Проблема различных моделей автомобилей

 

В теории звучит просто. Реальность же такова, что адаптация к различным моделям автомобилей вызывает наибольшую головную боль.

Национальный стандарт GB/T 32960 определяет форматы данных для новых энергетических транспортных средств, но распространяется только на EV. Традиционные коммерческие автомобили с топливным двигателем в основном следуют стандарту SAE J1939, однако конкретные реализации все еще различаются.

Еще сложнее то, что многие автопроизводители используют собственные сообщения CAN, не ограничиваясь стандартными определениями. Некоторые марки помещают коды неисправностей и напоминания о техническом обслуживании в личные сообщения с недокументированными форматами. Для чтения этих данных требуется обратная разработка или получение технической документации от автопроизводителя.

В ходе проектов мы адаптируемся к каждой модели автомобиля индивидуально. Сначала соберите документацию по протоколу CAN для данной модели. Если документация недоступна, используйте CAN-анализатор для записи данных шины и ручного анализа форматов сообщений. Затем настраиваем соответствующие правила разбора в шлюзе.

Такие шлюзы, как SV910, поддерживают гибкую конфигурацию. Вы можете определить пользовательские правила разбора, указав, какие байты в идентификаторе сообщения представляют те или иные данные и какую формулу преобразования следует применить. Для разных моделей автомобилей нужны разные конфигурационные файлы, никаких изменений в коде не требуется.

Мы создали базу данных моделей автомобилей, хранящую конфигурации протоколов CAN для различных марок и моделей. Новые проекты начинаются с проверки того, существуют ли уже конфигурации. Если нет, мы адаптируем одну, а затем добавляем ее в базу данных. Сейчас в библиотеке хранятся конфигурации для сорока-пятидесяти моделей автомобилей.

Обеспечение производительности в режиме реального времени и точности данных

Чтение данных CAN с помощью автомобильных шлюзов требует хорошей производительности в реальном времени. Особенно в сценариях автономного вождения или ADAS задержки данных могут повлиять на безопасность.

Сама по себе шина CAN имеет очень низкую задержку, измеряемую микросекундами. Но обработка, упаковка и загрузка данных шлюзом вносят дополнительную задержку. Как это контролировать?

Во-первых, минимизируйте этапы обработки. После получения CAN-кадров сразу же разбирайте их в обработчиках прерываний или высокоприоритетных задачах, а не ставьте в очередь. После разбора поместите их непосредственно в буфер передачи и отправьте по сети 5G.

Во-вторых, используйте аппаратное ускорение. Некоторые современные автомобильные шлюзы интегрируют контроллеры CAN с аппаратной фильтрацией. Настройте правила фильтрации на аппаратном уровне, чтобы принимать только интересующие идентификаторы сообщений, отбрасывая остальные. Это снижает нагрузку на процессор и увеличивает скорость обработки.

В-третьих, тщательно управляйте временными метками. Каждый CAN-кадр должен получить временную метку сразу после приема шлюзом. Эта временная метка должна иметь микросекундную точность. Данные, загружаемые в облако, должны содержать эту временную метку, чтобы облако знало, когда были собраны данные.

SV910 поддерживает протоколы синхронизации времени PTP/GPTP, обеспечивая высокоточную синхронизацию часов между шлюзом и другими устройствами. Это очень важно для сценариев, требующих координации работы нескольких устройств.

Точность данных также должна быть гарантирована. Хотя шина CAN имеет встроенную проверку на ошибки, время от времени поврежденные данные все же появляются. Шлюзы нуждаются во вторичной проверке. Например, обороты двигателя в нормальном режиме не могут внезапно скакать с 1000 до 5000 об/мин и обратно. Отмечайте такие аномальные данные как подозрительные, а не используйте их напрямую.

Решайте также ситуации с молчанием шины. Если определенное сообщение не поступает в течение длительного времени, возможно, соответствующий ЭБУ вышел из строя или шина отключилась. Шлюзы должны обнаружить это состояние и сообщить об аномалии.

Преимущества двойной архитектуры 5G

В SV910 реализована архитектура dual 5G с двумя модулями 5G. Почему именно двойной 5G?

Первая причина - резервное копирование. Коммерческие автомобили на дальних маршрутах могут проезжать через районы с плохим сигналом. При использовании одиночного 5G потеря сигнала означает отсутствие передачи данных. В Dual 5G используются SIM-карты разных операторов связи - China Telecom и China Unicom или China Mobile и China Unicom. Когда сигнал одного из них ухудшается, переключитесь на другого.

Переключение может быть автоматическим. Шлюз отслеживает уровень сигнала и задержку на обоих каналах 5G в режиме реального времени и использует тот из них, который имеет лучшее качество. Или использовать оба канала одновременно для агрегации каналов, удваивая пропускную способность.

Вторая причина - распределение трафика.. Автомобильные приложения обычно используют несколько потоков данных - данные шины CAN, видео с камер, данные позиционирования, связь V2X. Эти типы данных имеют разные характеристики и разные требования к пропускной способности/задержке.

Направляйте критически важные данные управления по одному каналу 5G, а видео с высоким трафиком - по другому. Это предотвращает помехи и обеспечивает доставку критически важных данных в режиме реального времени.

Третья причина - изоляция безопасности.. Некоторые платформы управления автопарком требуют физического разделения каналов управления транспортным средством и каналов сбора данных для обеспечения безопасности. Dual 5G идеально удовлетворяет этому требованию. Для передачи команд управления используются выделенные каналы, а для сбора данных - другой. Даже если хакеры скомпрометируют канал передачи данных, они не смогут подменить команды управления.

Интеграция с платформами управления автопарком

После сбора данных автомобильные шлюзы загружают их в платформы управления автопарком. Платформы обычно представляют собой облачные сервисы, обеспечивающие мониторинг транспортных средств, воспроизведение маршрутов, статистические отчеты, предупреждения о неисправностях и другие функции.

Для загрузки данных существует несколько вариантов протоколов. MQTT является наиболее распространенным. Это легкий протокол очередей сообщений, разработанный специально для IoT. Шлюзы выступают в роли клиентов MQTT, подключаясь к облачным MQTT-серверам и периодически публикуя сообщения.

MQTT поддерживает различные уровни QoS (Quality of Service). QoS 0 - не более одного раза - отправь и забудь, возможна потеря. QoS 1 - не менее одного раза - гарантированная доставка, но возможны дубликаты. QoS 2 - ровно один раз - гарантированная доставка без дублирования. Выберите подходящий QoS в зависимости от важности данных.

Также широко используется HTTP/HTTPS. Шлюзы периодически упаковывают собранные данные и загружают их с помощью HTTP POST-запросов в облачные API. Этот подход является простым и прямым, с хорошей совместимостью. Недостатком является то, что накладные расходы на HTTP превышают расходы на MQTT, что менее подходит для высокочастотной передачи небольших данных.

Существуют также некоторые специализированные протоколы. Например, JT/T 808 - это стандартный протокол связи Министерства транспорта для терминалов спутниковой системы позиционирования автотранспортных средств. Многие платформы управления парком коммерческих автомобилей используют этот стандарт. Поддержка JT/T 808 требует реализации полного стека протоколов.

Формат данных должен быть согласован с платформой. Распространен JSON - человекочитаемый и простой для отладки. Но JSON занимает много места, поэтому, если стоимость данных очень важна, используйте бинарные форматы, например Protobuf, или собственные компактные форматы.

Реализация диагностических функций

Помимо считывания данных в режиме реального времени, автомобильные шлюзы могут выполнять диагностику.

Автомобильные ЭБУ генерируют диагностические коды неисправностей (DTC). При неисправности двигателя он выдает коды типа P0001, P0002. Эти коды хранятся в ЭБУ и могут быть считаны через шину CAN.

Стандартными диагностическими протоколами являются ISO 14229 (UDS - Unified Diagnostic Services) и SAE J1939-73. Шлюз выступает в роли диагностического клиента, отправляя диагностические запросы на ЭБУ, которые возвращают коды неисправностей и соответствующую информацию.

После считывания кодов неисправностей переведите их в удобочитаемые описания. Что означает P0001? Цепь управления регулятором объема топлива/обрыв. Для такого перевода требуется база данных кодов неисправностей. Шлюзы могут хранить описания распространенных кодов внутри системы или загружать их в облако для перевода.

Благодаря кодам неисправностей платформы управления автопарком могут обеспечить раннее предупреждение. Например, обнаружение кода высокой температуры охлаждающей жидкости немедленно оповещает водителей и отделы технического обслуживания, предотвращая повреждение двигателя от перегрева.

Передовые приложения выполняют прогнозируемое техническое обслуживание. Анализируйте тенденции изменения различных параметров автомобиля, чтобы предсказать потенциальные неисправности. Например, постепенное снижение давления масла в двигателе еще не привело к появлению кодов неисправностей, но показывает предупреждающие признаки - это побуждает водителя проверить масло.

Уроки реальных проектов

После многочисленных проектов мы столкнулись с множеством трудностей.

Первый урок: правильная защита шины CAN. Автомобильная шина CAN является критически важной. Если при сбоях в работе шлюза на шину подается низкий уровень напряжения или передаются ошибочные сообщения, это может повлиять на нормальную работу автомобиля.

Шлюзовые CAN-интерфейсы нуждаются в электрической изоляции для предотвращения распространения неисправностей. Схемы защиты шины должны автоматически отключаться при перенапряжении или перегрузке по току. Программному обеспечению также необходимы механизмы защиты - прекращение передачи данных при обнаружении аномалий во избежание помех на шине.

Второй урок: модификации автомобиля должны соответствовать правилам. Установка автомобильных шлюзов на коммерческие автомобили представляет собой модификацию транспортного средства. Она должна соответствовать национальным и местным нормативным требованиям без ущерба для безопасности транспортного средства. В некоторых регионах после внесения изменений требуется регистрация в органах управления транспортными средствами.

Третий урок: безопасность данных и защита конфиденциальности имеют огромное значение. Маршруты движения и поведение транспортных средств предполагают конфиденциальность. Шифруйте передачу данных, анонимизируйте хранение. Доступ к облачным платформам нуждается в контроле разрешений - нельзя допускать случайных утечек третьим лицам.

В целом, считывание данных с автомобиля по шине CAN с помощью автомобильных шлюзов составляет основу приложений для подключенных автомобилей. Сама технология не является сложной, но для ее успешного применения требуется внимание ко многим деталям. Адаптация различных моделей автомобилей, обеспечение производительности в реальном времени, точность данных, надежность связи - каждый аспект требует тщательной доработки для обеспечения стабильной и надежной работы.