CAN UDS-диагностика в TSMaster: руководство. Часть 1 — модуль, ISO TP, Seed&Key

TSMaster позволяет построить процесс диагностики почти без кода: достаточно понимать сам диагностический процесс, чтобы связать воедино разработку, производство и after-sales. Функция UDS-диагностики TSMaster поддерживает CAN и LIN, а также DoIP по Ethernet. В первой части руководства разбираем создание диагностического модуля, настройку транспортного уровня CAN UDS и базовую конфигурацию диагностики.

Ключевые слова: UDS, базовая диагностика, диагностические системные переменные.

1. Создание UDS-диагностического модуля в TSMaster

Шаг 1. Диагностические модули находятся в главном меню: «Приложение» → «Диагностические модули» (рис. 1-1).

Рис. 1-1. Диагностический модуль

Шаг 2. Добавьте модуль «Базовая диагностика». Можно добавить несколько модулей базовой диагностики CAN (рис. 1-2).

Рис. 1-2. Добавление модуля базовой диагностики CAN

TSMaster поддерживает несколько диагностических модулей одновременно: через многоканальные CAN-интерфейсы TOSUN их можно привязать к разным каналам и вести диагностику нескольких ЭБУ параллельно — вплоть до синхронной прошивки нескольких ECU.

2. Настройка транспортного уровня CAN UDS

TSMaster позволяет настроить транспортный уровень диагностики под задачу: тип шины, ID запроса и ответа, переменная скорость CAN FD, алгоритм безопасности и другие параметры.

2.1. Транспортный уровень диагностики

Транспортный уровень CAN-диагностики — ISO TP — включает параметры транспортного и сервисного уровней (рис. 2-1).

Рис. 2-1. Настройка транспортного уровня ISO TP

Тип шины. Для UDS on CAN/CAN FD выбирается CAN или CAN FD из выпадающего списка (рис. 2-2).

Рис. 2-2. Тип диагностической шины CAN/CAN FD

Канал — логический канал, который использует данный диагностический модуль. TSMaster допускает одновременную работу нескольких модулей (рис. 2-3).

Рис. 2-3. Выбор канала транспортного уровня

ID запроса — диагностический ID запроса со стороны ПК (тестера).
Тип ID запроса — 0: стандартный кадр (11 бит), 1: расширенный (29 бит) (рис. 2-4).

Рис. 2-4. Выбор типа ID запроса

ID ответа и тип ID ответа — аналогично для ответов ЭБУ.
Функциональный ID и его тип — для функциональной адресации.
Байт-заполнитель. Если полезных байт меньше, чем вмещает кадр CAN, остаток заполняется байтом-заполнителем. Пример: полезные данные [0x02, 0x10, 0x02], заполнитель 0xAA — на шине будет [0x02, 0x10, 0x02, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA].
Интервал приёма кадров — минимальный интервал (мс) между consecutive frame при приёме; модуль диагностики сообщает это значение клиенту. 0 — приём с минимально возможным интервалом.
Пользовательский интервал отправки — минимальный интервал между отправляемыми consecutive frame задаётся вручную.
Интервал отправки кадров — значение этого минимального интервала.
Размер блока отправки (BS) — сколько кадров отправляется до ожидания Flow Control. 0 — блок любого размера за один раз.
Интервал после FC-кадра — максимальная пауза между отправкой Flow Control и первым consecutive frame.
FD max DLC — максимальный DLC для кадров FD; действует только при типе шины CAN FD (рис. 2-5).

Рис. 2-5. Максимальный DLC кадра FD

Переменная скорость FD (BRS) — включение режима переменной битовой скорости.
Максимальная длина — максимальная длина пакета сервисного уровня; для классического CAN/LIN не используется.

При многокадровой передаче с DLC = 8 байт размер пакета кодируется 12 битами (младшие 4 бита байта 0 + байт 1) — максимум 4095 байт. В CAN FD при DLC > 8 байт под длину блока можно использовать байты 2–5 (32 бита), то есть теоретически передать до 4 ГБ за одну передачу; фактический предел настраивается пользователем.

Примечание: старшие 4 бита байта 0, равные 1, обозначают First Frame — и в CAN FD, и в классическом CAN.

2.2. Сервисный уровень диагностики

Параметры сервисного уровня: активация маршрутизации, таймеры S3 и P2, загрузка Seed&Key для Security Access (рис. 2-6).

Рис. 2-6. Параметры сервисного уровня

2.2.1. Таймеры P2

P2 timeout — минимальное время, за которое ЭБУ должен ответить на запрос. Для тестера это таймаут ожидания ответа: если за время P2 ответ не пришёл, запрос считается неудачным.

P2 extended — если ЭБУ не успевает ответить за P2, он отправляет кадр 7F XX 78 (response pending) и переводит ожидание на расширенное время; тестер, получив такой кадр, также переключается на P2 extended.

Оба параметра можно посмотреть на схеме через кнопку «Подробнее» (рис. 2-7).

Рис. 2-7. Настройка таймеров P2

2.2.2. Tester Present (диагност онлайн)

S3 server — время, по истечении которого ЭБУ, переведённый из Default Session в другую сессию, автоматически вернётся в сессию по умолчанию. S3 client — интервал, с которым тестер отправляет кадры TesterPresent.

Схемы обоих параметров доступны через кнопку «Подробнее» (рис. 2-8).

Рис. 2-8. Настройка таймеров S3

В диагностическом модуле TSMaster можно включить команду «Диагност онлайн» (рис. 2-9): при включении над модулем появляется переключатель, и кадры отправляются с интервалом S3 client.

Рис. 2-9. Настройка «диагност онлайн»

Байты Tester Present настраиваются тремя способами: стандартный сервис (0x3E 0x80), выбор из базовой конфигурации (готовая команда 3E) и пользовательские байты.

2.2.3. Seed&Key

TSMaster предлагает два способа работы с Seed&Key: загрузка готовой DLL с алгоритмом и встроенный редактор, позволяющий написать исходный код SeedKey и сохранить его как DLL.

Загрузка DLL. Поддерживаются DLL на C/C++, Delphi, а также на платформе .NET (C#, VB.Net) — это упрощает совместимость с библиотеками безопасности, собранными на разных платформах (рис. 2-10).

Рис. 2-10. Загрузка DLL

Иконки слева направо: [1] загрузить DLL; [2] удалить DLL; [3] открыть проверщик DLL — позволяет убедиться, что интерфейс DLL корректен, а алгоритм соответствует требованиям: выберите уровень Seed, введите значение Seed и нажмите GenKey; при совпадении интерфейса с шаблоном появится «Generate Key Success», а Key можно сверить с эталоном (рис. 2-11). [4] открыть папку с шаблонным проектом Seed&Key в каталоге установки TSMaster.

Рис. 2-11. Проверщик SeedKey

В каталоге установки TSMaster есть шаблонные проекты для упаковки алгоритма Seed&Key — GenerateKeyEx, GenerateKeyExOpt, ASAP1A_CCP_ComputeKeyFromSeed. Разработанная на их основе DLL загружается напрямую. Поддерживаемые сигнатуры функций:

// Интерфейс 1
unsigned int GenerateKeyEx(
  const unsigned char* ipSeedArray,   /* массив seed [in] */
  unsigned int iSeedArraySize,        /* длина массива seed [in] */
  const unsigned int iSecurityLevel,  /* уровень безопасности [in] */
  const char* ipVariant,              /* имя активного варианта [in] */
  unsigned char* iopKeyArray,         /* массив для ключа [in, out] */
  unsigned int iMaxKeyArraySize,      /* максимальная длина ключа [in] */
  unsigned int& oActualKeyArraySize); /* длина ключа [out] */

// Интерфейс 2: GenerateKeyExOpt — то же + параметр iPara
// Интерфейс 3:
bool ASAP1A_CCP_ComputeKeyFromSeed(
  const unsigned char* ipSeedArray,
  unsigned short iSeedArraySize,
  unsigned char* iopKeyArray,
  unsigned short iMaxKeyArraySize,
  unsigned short* opSizeKey);

Совместимость с другими интерфейсами. Если у вас уже есть своя SeedKey DLL с несовместимой сигнатурой, её можно обернуть вторичной упаковкой в DLL, загружаемую в TSMaster (рис. 2-12).

Рис. 2-12. Процесс вторичной упаковки

Пример: есть UserSeedKey.DLL с функциями GetKeyFromSeed01/03/11(byte* ASeed, byte* AKey) для уровней 1, 3 и 11. Поскольку сигнатуры не совпадают с тремя стандартными, делаем обёртку на базе шаблона GenerateKeyEx:

через LoadLibrary динамически подгружаем существующую DLL;
по входному параметру Level через GetProcAddress получаем указатель на нужную функцию вычисления Key;
если указатель получен — передаём Seed и вычисляем Key (рис. 2-13).

Рис. 2-13. Пример вторичной упаковки проекта GenerateKeyEx

После сборки TSMaster загружает DLL проекта GenerateKeyEx. Важно: исходную UserSeedKey.DLL нужно скопировать в корневой каталог TSMaster или рядом с GenerateKeyEx.DLL — иначе при выполнении не найдётся зависимость и разблокировка завершится ошибкой.

Написание кода SeedKey во встроенном редакторе (рис. 2-14):

Рис. 2-14. Встроенный редактор алгоритмов

[1] выбор функции алгоритма SeedKey; [2] проверщик алгоритма; [3] окно редактора кода; [4] экспорт кода в DLL; [5] выбор сигнатуры интерфейса (с расширением под пользовательские); [6] рабочая область редактирования исходника.

Если нужна своя форма интерфейса — обратитесь в поддержку TOSUN, её добавят в список. Все интерфейсные функции возвращают s32: 0 — успех, иные значения — коды ошибок. Поэтому последней строкой кода обязательно должен быть return с кодом возврата (рис. 2-15) — иначе система посчитает выполнение алгоритма неудачным.

Рис. 2-15. return с кодом возврата

3. Базовая конфигурация диагностики TSMaster

Модуль базовой диагностики включает базовые диагностические сервисы и составные (комбинированные) сервисы. Команды, выполняемые независимо, живут в базовых сервисах; команды скачивания файлов $34, $36 и $37 — в составных (рис. 3-1).

Рис. 3-1. Базовая конфигурация диагностики

3.1. Добавление и удаление сервисных команд

Наведите курсор на нужную команду и нажмите правую кнопку мыши — в контекстном меню доступно добавление или удаление сервиса (рис. 3-2).

Рис. 3-2. Добавление/удаление сервисных команд

3.2. Настройка параметров базовой диагностики

На примере Diagnostic Session Control (рис. 3-3):

Рис. 3-3. Настройка параметров базовой диагностики

[1] имя сервиса — произвольное, для удобства управления;
[2] функциональный идентификатор — отправлять ли запрос по функциональному адресу;
[3] проверка ответа — анализировать ли содержимое ответа;
[4] тип подсервиса — например, DiagnosticSessionType для Session Control;
[5] порядок байт списка параметров — Motorola или Intel;
[6] список параметров — помимо ID сервиса и подсервиса, в запрос можно добавить параметры (рис. 3-4).

Рис. 3-4. Добавление/удаление параметров

Для разных сервисов настраиваются свои ID-параметры: например, в запросе сессии тип сессии обязателен, а список параметров опционален. После изменения конфигурации вверху интерфейса в реальном времени показывается пример диагностического сообщения: запрос [10 01 xx xx] (xx — изменяемые данные) и ожидаемый ответ [50 01 xx] (рис. 3-5).

Рис. 3-5. Настройка параметров запроса и ответа

3.3. Типы параметров диагностических сервисов

Поддерживаются 7 типов данных (рис. 3-6):

Рис. 3-6. Типы параметров диагностического модуля

UInt — беззнаковое целое, длина кратна 8 и не превышает 32 бит (8/16/24/32);
Int — знаковое целое с теми же ограничениями;
Single — число с плавающей точкой, 32 бита;
Double — число с плавающей точкой, 64 бита;
HexArray — шестнадцатеричный массив, длина кратна 8 битам;
ASCII — строка ASCII, перед отправкой конвертируется в hex;
SystemVar — системная переменная TSMaster (UInt, Int, Single, Double, массивы, HexArray, String и др.); тип определяется определением самой переменной.

3.4. Настройка составных сервисов

Составной сервис ($34/$36/$37 — скачивание файла) включает общую конфигурацию, настройку стирания Flash, настройку запроса и передачи данных, настройку завершения передачи, а также расширенные и вспомогательные параметры.

3.4.1. Общая конфигурация

Поддерживается загрузка файлов hex/bin/s19/mot/srec/vdf и др.; можно менять число байт под стартовый адрес и длину данных, порядок байт контрольной суммы, импортировать свой CRC-алгоритм, а также просматривать содержимое файла во встроенном просмотрщике (рис. 3-7).

Рис. 3-7. Общая конфигурация

[1] имя сервиса;
[2] файл — загрузка исполняемого файла (hex, bin, s19, mot, srec, vdf…);
[3] hex viewer — встроенный редактор-просмотрщик TSHexViewer для анализа загруженного файла (рис. 3-8);
[4] идентификаторы адреса и длины — число байт под адрес и длину;
[5] контрольная сумма — порядок байт Intel/Motorola; для контроля целостности при скачивании в составной сервис встроены основные CRC-алгоритмы, а пользовательский алгоритм подключается в виде DLL (рис. 3-9).

Рис. 3-8. Просмотр загруженного файла

Рис. 3-9. Импорт и правка пользовательского CRC-алгоритма

После загрузки файла и выбора алгоритма модуль вычисляет контрольные суммы каждого блока данных и файла целиком (рис. 3-10).

Рис. 3-10. Контрольные суммы файла и блоков

Вычисленные значения автоматически превращаются в системные переменные (рис. 3-11), которые можно подставить в параметры сервиса. Например, для проверки целостности файла настраивается сервис Routine Control $31 с такой переменной в параметрах (рис. 3-12).

Рис. 3-11. Контрольные суммы как системные переменные

Рис. 3-12. Системная переменная контрольной суммы в параметрах сервиса

3.4.2. Настройка стирания Flash

Варианты: без автоматического стирания; стирание диапазона адресов Hex; стирание соответствующего блока перед скачиванием каждого блока. Ожидаемый ответ заполняется по фактическому ответу ЭБУ (рис. 3-13).

Рис. 3-13. Настройка стирания Flash

3.4.3. Настройка запроса и передачи данных

Можно изменить формат данных команды передачи (например, с 00 на AA) и задать максимальную длину блока передачи: по умолчанию 0x202, то есть 514 байт на пакет транспортного уровня (рис. 3-14).

Рис. 3-14. Настройка запроса и передачи данных

3.4.4. Настройка завершения передачи

Варианты проверки при завершении (рис. 3-15): без проверки; проверка на стороне ЭБУ ($37 + контрольная сумма блока); пользовательская; проверка на стороне ПК ($37 + контрольная сумма блока); выбор типа контрольной суммы — без проверки или проверка каждого блока.

Рис. 3-15. Настройка завершения передачи

3.4.5. Расширенные параметры

Можно подключить файл подписи или особый CRC-алгоритм. В отличие от импорта CRC в общей конфигурации, здесь поддерживаются файлы любого формата (рис. 3-16).

Рис. 3-16. Расширенная конфигурация

3.4.6. Вспомогательные параметры

Файл скачивания можно разбить на блоки по непрерывным адресам — например, по 0x1000 (рис. 3-17).

Рис. 3-17. Настройка разбиения файла

Продолжение — во второй части: руководство по CAN UDS-диагностике в TSMaster, часть 2.