CAN

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

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

Чем CAN-логгер отличается от диагностического сканера

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

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

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

CAN-логгер, CAN-USB и осциллограф — не одно и то же

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

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

Осциллограф показывает электрическую форму сигналов CAN-H и CAN-L. Он нужен для поиска проблем физического уровня: искажений, отражений, помех, нарушений фронтов и других электрических дефектов. Обычный журнал CAN содержит цифровые кадры и служебные признаки, поддерживаемые конкретным устройством, но не заменяет измерение формы сигнала.

Что именно записывается в журнал CAN

Минимальная запись обычно связывает кадр с временной меткой. В зависимости от формата и оборудования журнал может содержать:

• номер CAN-канала;
• стандартный или расширенный идентификатор кадра;
• длину полезных данных;
• байты данных;
• точное время приема относительно начала записи или общей шкалы времени;
• направление передачи, если логгер поддерживает не только прием;
• признаки CAN FD и другие флаги кадра;
• error frames и состояние контроллера, если это предусмотрено устройством.

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

Сырые кадры и понятные параметры

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

В стандартизованных протоколах часть этой структуры известна. Например, в J1939 сообщения группируются по PGN, а отдельные параметры описываются через SPN. Подробнее об этом рассказано в статье НСЭ о J1939.

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

Почему логгер полезен при плавающей неисправности

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

Короткий осмотр после события показывает уже восстановившуюся систему. Длительная запись сохраняет контекст:

• какие параметры менялись перед отклонением;
• какой блок первым перестал передавать ожидаемое сообщение;
• появились ли необычные идентификаторы или error frames;
• возникали ли задержки или пропуски периодических сообщений;
• как остальные блоки отреагировали на событие;
• вернулся ли обмен к норме самостоятельно.

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

Непрерывная запись, фильтры и триггеры

Есть три распространенных подхода к сбору данных.

Непрерывная запись сохраняет весь доступный поток. Она удобна, когда момент события неизвестен, но создает большой объем данных.

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

Запись по триггеру запускается или отмечается при заданном условии: появлении сообщения, значении сигнала, error frame или внешнем событии. Некоторые логгеры умеют сохранять интервал до триггера и после него. Тогда инженер получает контекст вокруг сбоя, а не только данные после срабатывания.

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

Как подготовить запись до выезда техники

Полезный журнал начинается не с кнопки «Запись», а с плана проверки.

1. Опишите симптом. Что именно видит оператор, при каких условиях и как система восстанавливается.
2. Определите точку подключения. Уточните, к какой из CAN-шин машины относится нужное оборудование. Диагностический разъем не всегда дает доступ ко всем внутренним сетям.
3. Проверьте тип сети. Согласуйте CAN или CAN FD, скорость и другие параметры контроллера. Несовпадение настроек может привести к ошибкам или отсутствию данных.
4. Выберите режим подключения. Для наблюдения за работающей сетью обычно стремятся исключить передачу кадров со стороны регистратора. Возможность пассивного режима и его ограничения проверяют по документации логгера.
5. Оцените объем. Учитывайте загрузку шины, число каналов, длительность поездки и емкость накопителя.
6. Настройте время. Решите, с чем будут сопоставляться метки: часами оператора, видео, координатами или другим журналом.
7. Продумайте отметку события. Оператор может записать точное время, нажать внешнюю кнопку или выполнить заранее определенное действие.
8. Сделайте контрольную запись. До выезда убедитесь, что файлы создаются, открываются и содержат трафик нужного канала.

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

Как разбирать журнал после события

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

Практический порядок анализа:

1. Найдите метку события и выберите интервал до и после нее.
2. Сравните этот интервал с участком штатной работы в похожем режиме.
3. Проверьте пропуски периодических сообщений и изменение частоты передачи.
4. Отметьте новые идентификаторы, error frames и резкие изменения декодированных параметров.
5. Разделите первое наблюдаемое отклонение и последующие реакции системы.
6. Сопоставьте CAN-данные с питанием, механическими событиями, GPS, видео и другими доступными измерениями.
7. Сформулируйте проверяемую гипотезу и повторите испытание в контролируемых условиях.

Если сбой не попал в журнал, это тоже дает полезную информацию: нужно проверить выбранную сеть, фильтры, момент запуска, объем памяти и синхронизацию времени.

Как выбрать CAN-логгер под задачу

Сравнивайте не только число каналов. Для полевой диагностики важны:

• поддерживаемые CAN и CAN FD, скорости и типы кадров;
• автономная работа и способ питания;
• пассивный режим;
• точность и синхронизация временных меток;
• запись error frames;
• фильтры, триггеры и интервалы до/после события;
• объем памяти, формат файлов и поведение при заполнении;
• защита корпуса и допустимые условия эксплуатации;
• доступное программное обеспечение для просмотра и экспорта;
• возможность декодировать нужный протокол или подключить свою базу сигналов;
• удобство установки и извлечения данных.

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

CAN-логгер НСЭ

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

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

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

Коротко

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

Назад к списку

Что такое J1939 – простое введение

SAE J1939 — это набор стандартов, которые определяют, как ЭБУ (Электронные Блок Управления) обмениваются данными по CAN шине в автомобилях большой грузоподъемности.

Большинство автомобилей сегодня используют сеть Controller Area Network (CAN) для связи с ЭБУ. Однако CAN шина обеспечивает только «основу» для связи, а не «язык» для общения.

Во многих большегрузных автомобилей таким языком является стандарт SAE J1939, определенный SAE International.

Говоря более техническим языком, J1939 представляет собой протокол более высокого уровня, основанный на CAN (подробнее об этом позже).

Но что это значит?   

Единый стандарт для большегрузных автомобилей  

Проще говоря, J1939 предлагает стандартизированный метод обмена данными между ЭБУ, или, другими словами:

J1939 обеспечивает общий язык для всех производителей.

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

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

Примеры применения J1939

Тяжелые транспортные средства (например, грузовики и автобусы) – одна из наиболее известных областей применения. Однако сегодня SAE J1939 используется и в ряде других ключевых отраслей либо напрямую, либо через производные стандарты (например, ISO 11783, MilCAN, NMEA 2000, FMS):

• Лесозаготовительная техника (например, сучкорезы, форвардеры, трелевочные тракторы);
• Горнодобывающая техника (например, бульдозеры, драглайны, экскаваторы, …);
• Военные транспортные средства (например, танки, транспортировочные машины, …);
• Сельское хозяйство (например, тракторы, комбайны, …);
• Строительство (например, мобильная гидравлика, краны, …);
• Пожарная и спасательная техника (например, машины скорой помощи, пожарные машины, …);
• Прочее (например корабли, электробусы, электрогенераторы, …).

Роль SAE International

SAE International (ранее известная как Society of Automotive Engineers) — это глобальная организация по стандартизации, базирующаяся в США. Организация играет важную роль в разработке и поддержании стандарта J1939. Например, организация обеспечивает обновление протокола в ответ на такие разработки, как электрификация транспортных средств и появление CAN FD.

4 ключевые характеристики J1939

Протокол J1939 имеет набор определяющих характеристик, описанных ниже:

Скорость передачи данных 250 Кбод и 29-битный расширенный идентификатор

Скорость передачи данных J1939 обычно составляет 250 Кбод (хотя в последнее время поддерживается и 500 Кбод), а идентификатор расширен до 29 бит (CAN 2.0B).

Широковещательная передача + данные по запросу

Большинство сообщений J1939 передаются по CAN шине, хотя некоторые данные доступны только при запросе по CAN шине.

Идентификаторы PGN и параметры SPN

Сообщения J1939 идентифицируются 18-битными номерами групп параметров (PGN), тогда как сигналы J1939 называются номерами подозрительных параметров (SPN).

Многобайтовые переменные и мультипакеты

Многобайтовые переменные отправляются первым наименьшим байтом (порядок байтов Intel). PGN с размером до 1785 байт поддерживаются транспортным протоколом J1939.

Дополнительные характеристики J1939

Ниже приведен набор дополнительных характеристик протокола J1939:

• Зарезервировано: J1939 включает в себя большой диапазон стандартных PGN, хотя PGN с 00FF00 по 00FFFF зарезервированы для собственного использования;
• Особые значения: Байт данных 0xFF (255) отражает данные N/A, тогда как 0xFE (254) отражает ошибку;
• Утверждение адреса J1939: Стандарт SAE J1939 определяет процедуру назначения исходных адресов ЭБУ J1939 после инициализации сети через 8-битный адрес динамическим способом;

История J1939

• 1985: SAE инициировало разработку протокола J1939;
• 1994: Выпущены первые документы (J1939-11,J1939-21,J1939-31);
• 2000: Опубликован первый документ верхнего уровня;
• 2000: CAN официально включен как часть стандарта J1939;
• 2001: J1939 начинает заменять прежние стандарты SAE J1708/J1587;
• 2013: Выпущено цифровое приложение J1939 (J1939 Digital Annex), оцифровывающее данные PGN/SPN;
• 2020-21: Выпущены J1939-17 и J1939-22 (J1939 на CAN FD).

Будущее j1939

Мы видим ряд тенденций, влияющих на протокол:

• Проблема пропускной способности: Потребность в большей пропускной способности может привести к переходу на J1939-22 (J1939 на CAN-FD), увеличению использования отдельных сетей J1939 для каждого транспортного средства и/или потенциальному переходу на автомобильный Ethernet;
• Право на ремонт: Движение за «Право на ремонт» особенно актуально для дорогостоящих тяжёлых транспортных средств, включая, например, известное оборудование John Deere и военную технику. В то же время OEM-производители коммерчески мотивированы предлагать всё более закрытые телематические системы на основе J1939, что может способствовать усилению использования проприетарного кодирования PGN/SPN;
• 1939 для электромобилей: Рост количества электрических тяжёлых транспортных средств создаёт риск для стандартизации J1939, а также для смешанных телематических систем в автопарках. Это связано как с отсутствием законодательных требований по измерению выбросов, так и с тем, что разработка электротранспорта у OEM-производителей иногда опережает внедрение новых стандартов кодирования PGN/SPN для J1939;

Стандарты J1939 (протокол верхнего уровня)

J1939 основан на CAN, который определяет физический уровень (ISO 11898-2) и уровень канала передачи данных (ISO 11898-1) в модели OSI. В этом контексте CAN является «протоколом нижнего уровня», который описывает средства связи, такие как провода и кадры CAN, но не более того.

J1939 — это «протокол верхнего уровня», который добавляет конкретный язык для обеспечения более продвинутой коммуникации. Существуют и другие протоколы, основанные на CAN, такие как OBD2, UDS и CANopen.

Чтобы лучше понять J1939, мы рассмотрим некоторые из его подстандартов (или разделов) в следующих частях.

Разъем J1939 [J1939-13]

Стандарт J1939-13 описывает «внешний диагностический разъём», также известный как разъём J1939 или 9-контактный разъём Deutsch. Это стандартизированный метод подключения к сети J1939 большинства тяжёлых транспортных средств — см. выше схему распиновки разъёма J1939.

Несколько сетей J1939

Как было показано, разъём J1939 Deutsch предоставляет доступ к сети J1939 через контакты C (CAN high) и D (CAN low). Это облегчает подключение к сети J1939 большинства тяжёлых транспортных средств.

Однако в некоторых случаях вы также можете получить доступ ко вторичной сети J1939 через контакты F и G или контакты H и J (где H — это CAN H, а J — CAN L).

Многие современные тяжёлые транспортные средства имеют 2 или более параллельных сети CAN, и в некоторых случаях как минимум две из них будут доступны через один и тот же разъём J1939. Это также означает, что вы не обязательно получите доступ ко всем данным J1939, если попытаетесь подключиться только через «стандартные» контакты C и D.

Другие сверхпрочные соединители

Хотя разъём J1939 Deutsch является наиболее распространённым способом подключения к сети J1939 тяжёлых транспортных средств, существуют и другие разъёмы. Ниже приведены некоторые примеры:

• J1939 Backbone Connector: Это 3-контактный разъём Deutsch, который предоставляет контакты для CAN H/L и экрана CAN (без питания и заземления);
• Разъём CAT: Промышленный разъём Caterpillar — серый 9-контактный разъём Deutsch. Однако его распиновка отличается от разъёма J1939 (A: питание, B: заземление, F: CAN L, G: CAN H), и разъём физически блокирует доступ стандартных разъёмов J1939 типов 1 и 2;
• Разъём OBD2 типа B: В тяжёлых транспортных средствах разъём OBD2 типа B (SAE J1962) иногда предоставляет прямой доступ к сети J1939 через контакты 6 и 14;
• Разъём OBD2 Volvo 2013: Этот вариант соответствует разъёму OBD2 типа B, но также предоставляет доступ к J1939 high через контакт 3 и J1939 low через контакт 11.

Черный тип 1 vs зеленый тип 2

Обратите внимание, что разъем J1939 Deutsch производится в двух вариантах: оригинальный черный разъем (тип 1) и новый зеленый разъем (тип 2), который начал выпускаться в 2013-14 годах.

Зеленые кабели-адаптеры J1939 типа 2 можно использовать как с черными, так и с зелеными разъемами, поскольку они обратно совместимы.

Почему два типа разъемов?

Разъёмы “мама” J1939 типа 2 физически обратно совместимы, тогда как разъёмы “мама” типа 1 подходят только для разъёмов “папа” типа 1. Разъём типа 2 был разработан для стандарта SAE J1939-14, который добавляет поддержку скоростей передачи данных 500 Кбод. Цель блокировки разъёмов типа 1 – предотвратить подключение старого оборудования (предположительно использующего скорость 250 Кбод) к сетям J1939 типа 2 с битрейтом 500K. Блокировка осуществляется за счёт меньшего отверстия для контакта F в разъёмах “папа” типа 2.

Ниже приведён пример адаптерного кабеля DB9-J1939 (тип 2):

J1939 PGN и SPN [J1939-21/71]

В следующем разделе мы объясним PGN и SPN стандарта J1939.

Parameter Group Number (PGN)

PGN J1939 представляет собой 18-битное подмножество 29-битного расширенного идентификатора CAN. PGN служит уникальным идентификатором кадра в рамках стандарта J1939, что означает, что правила декодирования необработанных данных J1939 определяются на уровне PGN, а не на уровне 29-битного идентификатора.

В результате несколько сообщений CAN с уникальными идентификаторами CAN могут соответствовать одному и тому же PGN и интерпретироваться одинаково.

Подробное разбиение PGN J1939

Рассмотрим процесс перехода от CAN ID к PGN более подробно. В частности, 29-битный идентификатор CAN состоит из приоритета (3 бита), PGN J1939 (18 бит) и исходного адреса (8 бит).

PGN, в свою очередь, можно разделить на следующие части:

• Зарезервированный бит (RES) (1 бит);
• Страница данных (Data Page) (1 бит);
• Формат PDU (PDU Format) (8 бит);
• Специфика PDU (DPU Specific) (8 бит).

PDU обозначает Protocol Data Unit (единица протокольных данных). Подробная иллюстрация PGN также включает примерные значения для каждого поля в двоичной, десятичной и шестнадцатеричной формах.

J1939 PGN PDU1 vs PDU2

Распространённая путаница в PGN J1939 касается различий между PDU1 и PDU2.

Большинство пользователей, вероятно, более знакомы с PGN PDU2, так как они составляют около 95% PGN в Цифровом приложении J1939. Сообщения PDU2 являются «широковещательными», что означает, что они передаются без конкретного назначения — все узлы CAN решают, использовать данные или игнорировать их. Сообщения PDU1 являются «адресуемыми», и идентификатор CAN содержит «адрес назначения», который позволяет нацеливаться на конкретный узел в шине.

Чтобы увидеть это на практике, рассмотрим два PGN: 61444 (EEC1) и 11264 (HVESP3C1). На изображении ниже мы ввели три отдельных 29-битных идентификатора CAN для обоих PGN в наш конвертер J1939 PGN:

Обратите внимание, что EEC1 является PDU2, так как формат PDU равен 240, в то время как HVESP3C1 является PDU1, поскольку формат PDU равен 44 (и, следовательно, ниже 240). Для EEC1 поле спецификации PDU (PS) всегда равно 4, что будет верно для любого 29-битного идентификатора CAN, который соответствует PGN EEC1. Здесь значение 4 отражает расширение группы. Напротив, поле спецификации PDU (PS) варьируется среди трёх 29-битных идентификаторов CAN, соответствующих PGN HVESP3C1. Разные значения PS отражают различные адреса назначения.

Различие между PDU1 и PDU2, например, актуально при использовании масок PGN J1939 в настройке фильтров идентификаторов. Здесь маска 3FFFF00 может быть использована для PDU2, в то время как для PDU1 должна использоваться маска 3FF0000.

Suspect Parameter Number (SPN)

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

Примерами SPN являются частота вращения двигателя, скорость вращения колес транспортного средства, уровень топлива 1 и температура масла  в двигателе 2.

J1939 PGN и SPN [J1939-21/71]

Как было сказано выше, практическое декодирование данных J1939 осуществляется с помощью программного обеспечения CAN/API-инструментов и файла J1939 DBC. Однако полезно понимать, что происходит “под капотом”.

Предположим, вы записали необработанный фрейм J1939, как показано ниже:

CAN-идентификатор —> 0x0CF00401
Байты данных —> 0xFF FF FF 68 13 FF FF FF

Сначала необходимо определить J1939 PGN, например, с помощью нашего конвертера PGN. 29-битный CAN ID 0x0CF00401 преобразуется в J1939 PGN 0xF004 (61444), также известный как EEC1 (Электронный Контроллер Двигателя 1). Из J1939-71 DA мы узнаём, что PGN EEC1 содержит 8 SPN, включая частоту вращения двигателя. Далее мы расшифруем значение скорости двигателя. В J1939 DA можно найти правила декодирования и выполнить следующие шаги:

1. Извлекаем необработанные биты: Необработанные данные находятся в байтах 4 и 5, то есть 0x6813;
2. Используем Intel-формат: Меняем порядок байтов, получаем 0x1368;
3. Преобразуем в десятичное: Необработанные данные в десятичной форме — 4968;
4. Применяем масштаб/смещение: Умножаем на 0,125 и смещаем на 0, получаем 621 об/мин.

Диапазоны сигнала J1939

Согласно стандарту J1939-71, некоторые значения сигналов имеют специальные интерпретации. Если у электронного блока управления (ECU) возникает ошибка датчика или он полностью лишён определённой функции, может использоваться «диапазон ошибки» или «диапазон недоступности» для передачи этой информации. Пример практического использования значений «недоступно» можно увидеть в приведённых ниже данных J1939.

Действительный vs рабочий диапазон

Обратите внимание, что J1939 DA определяет «рабочий диапазон» для многих сигналов, который является более ограниченным, чем «действительный диапазон». В файл J1939 DBC мы включаем минимальные/максимальные значения для всех сигналов, используя рабочий диапазон, если он доступен, а в противном случае – «действительный диапазон».

В отношении 2-битных сигналов

Для 2-битных дискретных сигналов J1939-71 указывает, что значение 2 отражает ошибку, а значение 3 — недоступно. Однако, по нашему опыту, это, кажется, противоречит описаниям SPN в J1939 Digital Annex, где несколько 2-битных сигналов используют полный набор из 4 возможных значений для передачи корректных данных. По этой причине мы не включаем длину 2-битного сигнала в таблицу, и рекомендуем обращаться непосредственно к J1939 Digital Annex.

Пример: Данные грузовика J1939 – Необработанные vs. Декодированные

Ниже мы приводим пример необработанных и декодированных данных J1939.

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

Необработанные данные J1939

Необработанные данные J1939 состоят из CAN ID с 29-битной меткой времени и 8-байтных полезных данных. Эти данные можно фильтровать и искать, но, например, их нельзя отображать в виде временных рядов.

Декодированные данные J1939

При декодировании необработанных данных J1939 с использованием DBC-файла J1939, мы сопоставляем 85 из 142 CAN ID (остальные являются проприетарными). Декодированный файл содержит SPN J1939, сгруппированные по PGN, готовые для анализа.

Запрос сообщения [J1939-21]

Большинство сообщений J1939 передаются по шине CAN с фиксированной периодичностью, но некоторые передаются только «по запросу» (например, при опросе диагностическим инструментом или регистратором данных J1939). Примером могут служить диагностические сообщения J1939, такие как DM2, которое содержит диагностические коды неисправностей (DTC). См. также наш DBC-файл J1939-73. Для отправки запроса J1939 по шине CAN используется специальное «сообщение-запрос» (PGN 59904), которое является единственным сообщением J1939 с всего 3 байтами данных. Эти байты содержат запрашиваемый PGN в формате байтов Intel.

Чтобы показать, как это работает, рассмотрим реальный пример. Здесь инженер использует устройство для запроса данных по PGN HOURS (количество часов) (0xFEE5, т.е. 65253), который включает SPN «Общее время работы двигателя» (часто используется, например, в телематике). Для отправки запроса инженер настраивает устройство на передачу кадра CAN с полезной нагрузкой 0xE5FE00 (PGN HOURS в формате байтов Intel).

Для 29-битного CAN ID рассмотрены два случая:

• Пример 1: Здесь адрес получателя 0xFF (глобальный запрос), что заставляет все ЭБУ (ECU) ответить, если у них есть данные;
• Пример 2: Здесь адрес получателя 0x00 (специфический запрос), что обеспечивает ответ только от ЭБУ с SA 0x00.

Подробнее о 29-битном запросе CAN ID

На практике вы, как правило, не будете знать адрес источника (SA) ЭБУ, от которого хотите запросить данные. Например, если вам нужно получить данные HOURS с пяти разных грузовиков, самым простым решением будет использование глобального запроса с адресом 0xFF — по крайней мере на этапе начального исследования.

Многие практические шины J1939 используют фиксированные адреса источников, что позволяет применять двухэтапный процесс: сначала вы определяете адрес источника всех ЭБУ, которые отвечают на глобальный запрос, а затем, узнав адрес, переключаетесь на метод специфического запроса. Это предпочтительнее, например, если на глобальный запрос несколько ЭБУ отвечают одинаковыми данными. Использование специфических запросов помогает уменьшить нагрузку на шину и сократить размер лог-файлов.

Также обратите внимание, что в примере трассировки для устройства мы используем адрес источника 0xFA. Это выбор условный: отраслевые стандарты рекомендуют, чтобы сторонние инструменты использовали адреса источников из «верхнего диапазона» (например, 0xFA-0xFF), хотя стандарт J1939 не предписывает конкретного адреса. Адрес источника, используемый в ID запроса, не влияет на результаты, но в целях наилучшей практики рекомендуется использовать уникальный адрес источника, если это возможно.

Запросы J1939 и соответствие гарантийным требованиям

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

Транспортный протокол J1939 (TP) [J1939-21]

Некоторые полезные нагрузки сообщений превышают 8 байт — например, обновления программного обеспечения ЭБУ, конфигурации транспортных средств или диагностические коды неисправностей (DM1). Для передачи таких данных необходимо разделить их на несколько CAN кадров. Затем принимающий узел должен заново собрать отдельные пакеты данных.

J1939 определяет, как это можно сделать с помощью двух альтернативных транспортных протоколов:

Одноранговый (RTS/CTS)

Передающий узел инициирует соединение с помощью сообщения Request To Send (RTS). Дальнейшая передача управляется принимающим узлом с помощью сообщений Clear To Send (CTS), а завершается сообщением End of Message Acknowledge (EoMA).

Широковещательный (BAM)

Передающий узел инициирует передачу с помощью сообщения Broadcast Announce Message (BAM, PGN 0xEC00, то есть 60416), за которым следует несколько сообщений Data Transfer (DT, PGN 0xEB00, то есть 60160). Принимающий узел не осуществляет никакого контроля.

J1939 в решениях НСЭ

Для управления оборудованием по CAN и SAE J1939 применяются модули АСУ НСЭ. Для записи данных шины предназначен Саёратех логгер, а состав решения с передачей данных на сервер описан на странице мониторинга транспорта. Возможности каждого устройства нужно проверять по актуальной карточке и документации.

Назад к списку