Диагностическая консоль TSMaster — это отладчик диагностических команд: пользователь выбирает отдельную сервисную команду, редактирует отправляемые и принимаемые сервисные сообщения и проводит тестовую проверку. Консоль состоит из пяти рабочих областей: выбор сервисной команды, ручной ввод команд, область отправки/ответа диагностических команд, выполнение диагностики, диагностическая информация/Trace.

Ключевые слова: диагностическая консоль, UDS, Request PDU, Check, ISO 15765-2, Trace.

1. Область выбора сервисных команд

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

Область выбора сервисных команд
Рис. 1. Область выбора сервисных команд

2. Область ручного ввода команд

Если во время теста нужно отправить произвольную диагностическую команду, введите её в области ручного ввода (рис. 2) и нажмите кнопку «Execute» справа — сообщение будет отправлено. Для гибкости теста переключателем можно выбрать отправку диагностического запроса по физическому адресу или по функциональному ID.

Ручной ввод команд
Рис. 2. Область ручного ввода команд

3. Область отправки/ответа диагностических команд

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

Параметры отправки и ответа
Рис. 3. Параметры отправки и ответа сервиса 0x24

3.1. Ввод диагностических параметров

Пример ввода параметров (рис. 4):

Ввод диагностических параметров
Рис. 4. Ввод диагностических параметров

Request PDU — байты диагностического пакета, который отправит модуль; это поле не редактируется: после ввода значений параметров данные формируются автоматически.

Соответствие диагностических параметров:

  1. Para0: тип UInt, длина 8 бит, ввод 12 → байт 0x0C.
  2. Para1: тип Int, длина 8 бит, ввод -1 → байт 0xFF.
  3. Para2: тип Single, длина 32 бита, ввод 3.1 → байты 0x40 0x46 0x66 0x66.
  4. Para3: тип Double, длина 64 бита, ввод 3.2 → байты 0x40 0x09 0x99 0x99 0x99 0x99 0x99 0x9A.
  5. Para4: тип Hex-массив, длина 8 бит, ввод 0x11 → байт 0x11.
  6. Para5: тип ASCII-строка, длина 24 бита, ввод «ASC» → байты 0x43 0x53 0x41.
  7. Para6: тип «системная переменная». Длина определяется значением переменной — 64 бита; имя переменной Diagnostic0.BC_cebal_fw_srf05dbg_StartAddressAndDataLength. При выполнении система автоматически извлекает фактическое значение системной переменной по имени и подставляет его в отправляемое сообщение.

После ввода всех параметров формируется диагностический запрос: 0x24 0x00 0x01 0x0C 0xFF 0x40 0x46 0x66 0x66 0x40 0x09 0x99 0x99 0x99 0x99 0x99 0x9A 0x11 0x43 0x53 0x41 — как на рис. 4.

3.2. Ввод параметров ответа

Значения параметров ответа (рис. 5):

Параметры ответа
Рис. 5. Ввод параметров ответа

Первая часть полностью аналогична вводу диагностических параметров из предыдущего раздела. Но у параметров ответа есть дополнительная опция — флажок проверки (Check). Если Check установлен, ответ ЭБУ должен точно совпасть с заданными параметрами — только тогда диагностический тест считается пройденным. Если флажок снят, модуль не проверяет содержимое этих байт ответа.

  1. Когда Check установлен для всех параметров, тест засчитывается, только если ответ ЭБУ равен: 0x64 0x00 0x01 0x7B 0xFE 0x40 0x4C 0xCC 0xCD 0x40 0x1A 0x00 0x00 0x00 0x00 0x00 0x00 0x12 0x34 0x43 0x53 0x41.
  2. Снимем Check с Para1 и Para2 (рис. 6): теперь ответ должен быть 0x64 0x00 0x01 0x7B 0xXX 0xXX 0xXX 0xXX 0xXX 0x40 0x1A 0x00 0x00 0x00 0x00 0x00 0x00 0x12 0x34 0x43 0x53 0x41, где 0xXX — байты без проверки; остальные байты должны совпасть.
  3. Снимем Check с Para0–Para5 (рис. 7): для прохождения теста достаточно, чтобы ответ ЭБУ начинался с 0x64 0x00 0x01.
Снятие Check с Para1 и Para2
Рис. 6. Check снят с Para1 и Para2
Снятие Check с Para0–Para5
Рис. 7. Check снят с Para0–Para5

4. Выполнение диагностики

На примере CombinedService: во время выполнения показываются уже загруженные области блоков (Block) и время записи каждого блока (рис. 8).

Выполнение диагностики
Рис. 8. Выполнение диагностики: загрузка блоков

5. Область диагностической информации / Trace

5.1. Сравнение Trace сервисов и сырых сообщений

В диагностике встречаются и самые исходные сообщения CAN/CAN FD/LIN, и сообщения сервисного уровня после транспортного протокола. В TSMaster сырые CAN-сообщения видны в базовом модуле Trace, а обработанные транспортным уровнем сервисные сообщения — прямо в области Trace диагностического модуля (рис. 9).

Сравнение Trace
Рис. 9. Сравнение сырого Trace и Trace диагностического модуля

По сравнению видно:

  1. В области сырых сообщений CAN/CAN FD видна информация транспортного уровня: мультифреймы, одиночные кадры, первые кадры и т.д.
  2. Trace диагностического модуля показывает сразу сервисные сообщения. Пользователю достаточно следить за содержимым своих сервисов, не вникая в то, как они разбиваются при передаче. Поэтому при работе с диагностическими сервисами основное внимание — на Trace внутри диагностического модуля.

5.2. Область подсказок по операциям

Здесь отображаются текущие шаги операций в диагностическом модуле. На рис. 10 показан внутренний процесс передачи при загрузке hex-файла.

Подсказки по операциям
Рис. 10. Область подсказок: шаги загрузки hex-файла

Если диагностический сервис не получил положительного ответа или ответа нет вовсе, выводятся сообщения об ошибках (рис. 11).

Сообщения об ошибках
Рис. 11. Ошибки при отсутствии положительного ответа

5.3. Область сервисных сообщений ISO 15765-2

Область показывает подробную информацию сервисного уровня диагностического модуля. Вместе с настроенной диагностической базой данных сырые данные сообщений разбираются в физические сигналы (рис. 12).

Сервисные сообщения ISO 15765-2
Рис. 12. Разбор сервисных сообщений ISO 15765-2