Протокол 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. Довжина поля даних 0×14 або 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 – Номер запитуваного параметра. Приклад 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

У таблиці представлені послуги закладені в протокол. Не всі блоки керування підтримують повний набір послуг.

 

 

 

Таблиця кодів відмови у виконанні команди

 

 

Оригінал