Протокол UDS (Unified Diagnostic Services)

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

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

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

 

 

Содержание

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

2. Типы кадров.

3. Фрейм UDS.

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

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

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

 

 

Описание транспортного протокола 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 =1014. 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 определяет количество SF фреймов, которые готовы принять получателю. У некоторых может быть ноль и протокол будет все равно работать.
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 – Номер запрашиваемого параметра. Пример 2206 – запрос уровня топлива.

Ответ 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 = 2206
• Байт 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

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

 

 

 

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

 

 

Оригінал.