О том, что можно найти в логах, когда заводской документации нет, а сервисное задание, например для систем мониторинга транспорта есть.

В сервисе тяжёлой и сельскохозяйственной техники привычная ситуация выглядит так: машина в поле, оператор жалуется, что «трансмиссия едет странно», а заводского DBC, A2L и сервисного ПО у заказчика нет. И не будет. Производитель в стране не присутствует или не отвечает, а машину нужно обслуживать сейчас.

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

История первая: «похожее число»

Машина — сельхозтрактор высокой мощности с CVT‑трансмиссией и несколькими CAN‑сетями.

Задача: восстановить сигналы трансмиссии и давление смазки гидроконтура.

На дисплее кабины оператор видит «давление смазки КПП: 0.80 бар». Первая мысль, которая приходит в голову — найти в логе байт, значение которого в какой‑нибудь очевидной интерпретации даёт ~0.8 (например, 80 при масштабе 0.01 или 8 при масштабе 0.1), и считать дело сделанным.

Этот подход — главная ловушка реверс‑инжиниринга. Объясняю, почему.

В CAN нет «значения 0.8». Есть байты с неизвестным коэффициентом, неизвестным смещением, неизвестным порядком байтов, неизвестной фильтрацией и иногда — со значением, которое вообще приходит не из CAN, а считается локально в HMI. Поиск по абсолютному числу — это поиск иголки в стоге сена, причём иголки, которой там может и не быть в принципе.

Тем не менее кандидат «по числу» нашёлся почти сразу: байт, в нужный момент показывающий ~0.8. На графике он оказался почти константой во всём логе, не коррелировал с оборотами двигателя и никак не реагировал на переход Park → Drive. Скорее всего — статусный код, случайно попавший в нужный диапазон.

Реальный сигнал давления нашёлся через другую логику: «как должно вести себя давление смазки в гидроконтуре CVT?» — плавно расти с оборотами, по‑разному вести себя в Park и в Drive, иметь характерный диапазон 0.5–1.5 бар на холостом. Кандидат, который этому соответствовал, лежал в другом сообщении и в другом байте и совпал с показанием HMI после подбора корректного коэффициента.

Урок, который стоит извлечь из истории:

Сигнал — это не число. Сигнал — это поведение во времени.

Когда инженер ищет «похожее значение», он ищет то, чего в логе нет. Когда инженер ищет «правильное поведение», он находит то, что есть.

История вторая: порядок байтов, который чуть всё не похоронил

Другая машина, другой проект. Декодировались обороты ВОМ (вала отбора мощности) — два числа, которые трактор показывает оператору в кабине: целевые (что выставил оператор) и фактические (что реально крутится). Шина с проприетарным OEM‑сегментом, рядом — стандартный J1939.

Соседние J1939-сообщения в этой шине были Intel (little‑endian). По инерции под ту же интерпретацию подобрался множитель порядка 7.4 — при котором цифры «почти сходились» с дисплеем. Почти.

Потом появилась референсная точка сверки — эталонное значение сигнала в известный момент. И всё рассыпалось: при Intel‑интерпретации значения не бились с эталоном (поведение машины из протокола водителя к записям CAN логов) ни при каком разумном масштабе.

Разгадка оказалась банальной и одновременно показательной: проприетарное сообщение этого производителя — Motorola (big‑endian), притом что соседние стандартные сообщения на той же шине — Intel. Производитель волен мешать порядки в пределах одной шины и делает это.

С правильным порядком байтов значения встали на места: на ВОМ-540 показывало ~478 RPM в реале (трактор не новый: неточность оборотов связана с пробуксовкой многодисковой муфты сцепления ВОМ, недостаточным давлением в гидравлической системе управления и физическим износом датчика оборотов), на ВОМ-1000 — ~1000 RPM, всё с правильной динамикой и в правильном диапазоне.

Урок:

То, что соседнее сообщение — Intel, ничего не говорит о других сообщениях. Всегда нужно проверять оба варианта. Это минутная работа. Стоимость пропущенной проверки — дни работы.

Что в итоге было декодировано

После работы по обеим машинам сервисная команда получила рабочие DBC‑фрагменты со следующими функциями:

Фрагмент DBC (нейтральные имена сигналов, проприетарные скрыты — интеллектуальная собственность заказчика):

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

Почему этого нет в J1939

Распространённое заблуждение: «если машина J1939-совместима, всё должно быть в логе и читаться напрямую». На практике публичный слой и проприетарный слой почти у всех OEM делятся примерно одинаково:

На J1939 / FMS производитель отдаёт: двигатель (обороты, температура, нагрузка, расход), скорость ТС, часть диагностики, иногда — обрезанная трансмиссия.

В проприетарном CAN остаётся: логика селектора и блокировка, состояния сцеплений, давления гидростатического контура, координация крутящего момента, внутренняя координация осей, данные отображения для HMI, сервисные параметры.

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

Что из этого следует для владельца техники

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

• Машина продолжает работать и передавать всё нужное по CAN. Данные машины физически принадлежат её владельцу — они присутствуют на шине и доступны для чтения независимо от политики поддержки производителя.

• Сигналы есть. Не все из них в J1939, не все легко читаются, но они физически присутствуют на шине.

• Их можно восстановить. Не всегда быстро и не всегда дёшево, но методично — да.

• Это не одноразовая работа. Реконструированный DBC живёт с парком: его можно использовать для телематики, для сервисной диагностики, для интеграции с системами учёта, для дообучения операторов.