j1939

Что такое 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). Принимающий узел не осуществляет никакого контроля.

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