Протокол UDS

Протокол UDS – это “язык” на котором общается диагностическое оборудование. Протокол  UDS может работать на различных физических шинах: K-Line, CAN, Ethernet, FlexRay. В этой статье мы рассмотрим механизм работы протокола UDS на шине CAN, как самый распространенный вариант в настоящее время. Рассматривать вопрос будем с практической точки зрения для быстроты восприятия материала.  Подробно протокол описан в стандарте  ISO-15765.

По протоколу UDS возможно не только считать\стереть коды ошибок – DTC, но и запросить текущие параметры датчиков и блоков управления (ECU), а так же давать команды исполнительным механизмам (например открыть\закрыть центральный замок).
Кроме того с помощью этого протокола осуществляется прошивка блоков управления.

В своей базе протокол UDS строится на транспортном протоколе TP. Транспортном не в смысле его применения на транспорте, а в том смысле что протокол предназначен для транспортировки данных по некоторому каналу передачи.

Описание транспортного протокола TP

Фрейм транспортного протокола строится по следующей схеме:

TA – Target Address или адрес получателя фрейма
SA – Source address или адрес отправителя фрейма
PCI – Поле в котором кодируется количество передаваемых байт и тип фрейма.

В реализации протокола UDS работающего поверх CAN шины  адрес источника не указывается в заголовке фрейма, а адресом получателя является CAN ID всего фрейма.
Например в CAN сообщении 0x7E0 02 09 02 00 00 00 00 00 00  адресатом будет блок управления двигателем, адрес которого равен =0x7E0.

Типы фреймов

Single Frame SF – Однократный фрейм. Фрейм вся информация которого умещается в один CAN пакет.

Пример:  0x7E0   02 09 02 00 00 00 00 00 .
Поле PCI в этом случае = 0x02. Оно указывает на то, что фрейм будет один и его длина 2 байта: 09 02

First Frame FF – Первый фрейм из серии фреймов

Поле PCI занимает два байта: Нулевой и первый. 7 бит первого байта и 3 первых бита нулевого байта определяют длину сообщения – максимум 2048 байта.
Четвертый бит нулевого байта равный 1 указывает на то что это First Frame.

Пример:   0x7E8   10 14 49 02 01 57 41 55
PCI = 10 14.  First frame. Длина поля данных 0x14 или 20 байт.
DATA: 49 02 01 57 41 55  – шесть байт
Таким образом после этого фрейма должно быть отправлено еще 2 фрейма с нагрузкой по 7 байт данных на каждый, чтобы получилось суммарно 20 байт.

Consecutive Frame  CF – последующий фрейм. Каждый фрейм следующий за First Frame от одного отправителя.

Поле PCI занимает нулевой байт. Старшая половина байта =0x2 и указывает на то что перед нами CF фрейм. Младшая половина указывает порядковый номер CF фрейма от 0x0 до 0xF.
Пример:  0x7E8   21 5A 5A 5A 38 45  37 37
PCI=0x21. Тип фрейма – CF, номер фрейма =1

Flow control Frame – FC – фрейм управления потоком. Отправляется получателем в ответ на First Frame

FC фрейм служит для управления потоком в случае если используется поток фреймов First Frame-Consicutive Frames.
 PCI занимает три байта: Нулевой, первый, второй.
Заголовок 0x3 в заголовке поля PCI указывает что это FC фрейм.
Flow Status говорит отправителю First Frame о статусе получателя 00- Готов к приему CF фреймов, 01- Жди, 02 – Переполнение.
Block Size определяет количество СF фреймов которые готов принять получателю. В некоторых может быть равно нулю и протокол все равно будет работать.
Minimum Separation Time в миллисекундах, задает минимальное время между передаваемыми CF фреймов.

Пример 1: 0x7E0   30 02 00 00 00 00 00 00
FC фрейм.
Готов принять 2 CF фрейма.
С минимальным временем между CF фреймами = 0 миллисекунд.

Пример 2: 0x778   30 08 05 AA AA AA AA AA
FC фрейм
Готово принять 8 CF фреймов
С минимальной задержкой 5 миллисекунд

Обмен с использованием  Single Frame со стороны отправителя и получателя будет выглядеть как простой обмен пакетами.  Обмен с использованием FF, CF, FC фреймов будет выглядеть сложнее, этот процесс удобнее изобразить на схеме ниже. Обратите внимание на то, что после серии Consecutive Frame -ов может следовать Flow control фрейм если передаваемые данные не умещаются в 16 блоков. А может и не следовать, это уже зависит от конкретной программной реализации протокола. Очень часто разработчики программного обеспечения автомобильных блоков управления отходят от формального описания протокола.

Такой же пример на конкретных данных.
ID Отправителя = 0x7CE
ID Получателя = 0x7C6
Отправитель передает массив данных размером 0xB5 или 181  байт получателю. На изображении представлен НЕ весь массив!

 

Фрейм UDS

Фреймы диагностического протокола UDS строятся поверх транспортных фреймов и выглядят так:

Где – SID – идентификатор сервиса. (запрос DTC, запрос текущих параметров, команды…)
PID\LEV – Номер запрашиваемого параметра или номер вызываемой функции.

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

Пример
Запрос
CAN ID=0x714  DLC=8  DATA: 03 22 22 06 00 00 00 00
SID = 0x22
PID = 22 06
Положительный ответ
CAN ID=0x77E  DLC=8  DATA:  04 62 22 06 9A 00 00 00
SID+0x40 = 0x62
PID = 22 06
Response parameter =0x9A 

 

Подробный разбор конкретных примеров использования протокола UDS

Пример 1.  Запрос VIN номера

1 Диагностический прибор: ID=0x7E0  DLC=8  DATA: 02 09 02 00 00 00 00 00
2 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  10 14 49 02 01 57 41 55            “WAU”
3 Диагностический прибор: ID=0x7E0  DLC=8  DATA: 30 02 00 00 00 00 00 00
4 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  21 5A 5A 5A 38 45  37 37         “ZZZ8E77”
5 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  22 41 30 37 37 37 37  32          “A077772”


Запрос от диагностического прибора
ID=0x7E0 DLC=8 DATA: 02 09 02 00 00 00 00 00

  • Байт 0:  02 – Single Frame SF длиной 2 байта
  • Байт 1: Service ID – SID – Номер требуемого сервиса. Пример: 09 – запрос текущих параметров.
  • Байт 2: Parameter ID – PID – Номер запрашиваемого параметра. Пример 02 – запрос VIN номера.

Ответ ECU: ID=0x7E8 DLC=8 DATA: 10 14 49 02 01 57 41 55

  • Байт 0: 0x10 – FF First Frame или первый фрейм из группы последующих CF фреймов.
  • Байт 1: Длина сообщения в байтах. Пример 0x14 – Будет передано 20 байт в нескольких фреймах.
  • Байт 2: Service ID SID +0x40. Пример SID в запросе =0x09, а в ответе =0x49. Если сервис не поддерживается, то Байт 2 примет значение =0x7F.
  • Байт 3: Parameter ID PID = 0x02
  • Байты 4…7:  Возвращаемое значение запрашиваемого параметра.  01 57 41 55

Запрос от диагностического прибора ID=0x7E0 DLC=8 DATA: 30 02 00 00 00 00 00 00

Байт 0:  0x30 – Flow control. Команда блоку управления выдать все байты данных запрашиваемого параметра блоком из двух CF фреймов с минимальной задержкой 0 миллисекунд.

Ответ ECU: ID=0x7E8 DLC=8 DATA: 21 5A 5A 5A 38 45  37 37
Ответ ECU: ID=0x7E8 DLC=8 DATA: 22 30 37 37 37 37  37 32

Затем блок управления отдает все байты данных запрашиваемого параметрах, которые упакованы в необходимое число CF фреймов. В описываемом примере таких фрейма два.

Байт 0:  0x21, 0x22   – номера CF фреймов в серии.

Байты 1…7: Байты данных запрашиваемого параметра.

 

Пример 2. Запрос уровня топлива

Рассмотрим более простой пример – запрос уровня топлива по протоколу UDS у панели приборов автомобиля VW Touareg NF.

1 Диагностический прибор: ID=0x714  DLC=8  DATA: 03 22 22 06 00 00 00 00
2 Ответ автомобиля:               ID=0x77E  DLC=8  DATA:  04 62 22 06 9A 00 00 00

Запрос от диагностического прибора ID=0x714 DLC=8 DATA: 03 22 22 02 00 00 00 00

  • Байт 0: Тип передаваемого сообщения и его длина. Пример: 03 – Single Frame SF длиной 3 байта
  • Байт 1: Service ID – SID – Номер требуемого сервиса. Пример: 22 – запрос текущих параметров.
  • Байты  2, 3: Parameter ID – PID – Номер запрашиваемого параметра. Пример 22 06 – запрос уровня топлива.

Ответ ECU: ID=0x77E  DLC=8  DATA:  04 62 22 06 9A 00 00 00

  • Байт 0:  0x04 – Single Frame. Длина сообщения 4 байта.
  • Байт 1: SID+0x40 = 0x62.
  • Байт 3,4: PID = 22 06
  • Байт 4:  Возвращаемое значение запрашиваемого параметра = 0x4B – Уровень топлива = 75 литра.

 

Пример 3. Команда активации исполнительного механизма

В качестве примера команды активации исполнительного механизма рассмотрим управление приводом центрального замка автомобилей Renault.

  1. Диагностический прибор: ID=0x745  DLC=8  DATA: 02 10 C0 00 00 00 00 00     Открытие диагностической сессии
  2.  Ответ автомобиля:              ID=0x765  DLC=8  DATA:  02 50 C0 01 00 00 88 00   Подтверждение открытия диагностической сессии
  3.  Диагностический прибор: ID=0x745  DLC=8  DATA: 04 30 01 00 00 00 00 00   Команда – Закрыть центральный замок
  4.  Ответ автомобиля:              ID=0x765  DLC=8  DATA:  03 70 01 01 00 00 88 00   Команда –  Закрытие центрального замка выполнена успешно.

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

Если бы мы отправили команду на закрытие замка без команды открытия сессии, то ответ был бы такой: ID=0x765  DLC=8  DATA:  03 7F 30 01 00 00 00 00 , где 7F – говорит о том, что команда не может быть выполнена. 

 

Таблица сервисов доступных в протоколе UDS

В таблице представлены сервисы которые заложены в протокол. Не все блоки управления поддерживают полный набор сервисов.

Таблица кодов отказа в исполнении команды