Реверс-инжиниринг RS-485: как мы получили данные с Hyundai R1250-9

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

Именно с такой задачей мы столкнулись на большом карьерном экскаваторе Hyundai R1250-9.

Задача

Клиенту требовалось видеть в MRA полноценную картину работы машины: какие функции активны, какие давления формируются в гидросистеме, когда машина поворачивает, двигается и копает, как меняются параметры под нагрузкой. Не «ещё один трекер на экскаваторе», а инженерный доступ к данным машины.

Что показал CAN

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

Для типовой телематической системы история на этом бы закончилась: нужных параметров в CAN нет — значит, «не читается».

Где на самом деле были данные

Разбирая архитектуру машины дальше, мы выяснили: ключевая информация передаётся в обмене между монитором машины и главным блоком управления — и не по CAN, а по интерфейсу RS-485. Это принципиально другая задача: вместо широковещательного обмена с идентификаторами кадров — последовательный протокол, где важны структура пакета, тайминги, контрольные суммы и логика «запрос-ответ».

Как шёл реверс-инжиниринг

Для захвата и анализа сигнала использовался логический анализатор Saleae Logic Pro 8. Работа шла поэтапно:

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

Так из потока байтов шаг за шагом складывается инженерная картина.

Результат

Задача решена: в MRA выведен набор параметров, которые были недоступны по CAN:

• пилотные давления по функциям;
• давления основных гидравлических насосов;
• температура гидравлики;
• состояния функций в логике «вкл/выкл»;
• рабочие сигналы по движению машины и активности отдельных контуров.

Клиент видит не просто «машина включена», а что она делает и в каком режиме работает в конкретный момент времени.

Что это значит для клиентов MRA

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

Если у Вас есть техника, с которой «ничего не считать» — напишите нам, разберёмся.