что такое uds 27 service

Security Access Service Identifier (0x27): UDS Protocol

The Security Access Service is used to modify the ECU data stored in memory, before that the user first has to grant access through this service. The purpose of this service is to supply a method to access information and/or diagnostic services that have restricted access for security, emissions, or safety reasons. Diagnostic services for downloading/uploading routines or information into a server and reading specific memory locations from a server square measure things wherever security access could also be needed. Improper routines or information downloaded into a server may doubtless injury the physical science or alternative vehicle elements or risk the vehicle’s compliance to emissions, safety, or security standards. The security construct uses a seed and key relationship.

Remember always the ECU’s are will be in the locked state after power on as default, if any problem is there or you want to write or read any data which is in the locked state by the OEM, then you need to unlock the ECU to change the data by using the Security Access Service Identifier (0x27).

How to Unlock an ECU in a vehicle?

To unlock an ECU in a vehicle, first, the Client will send the seed request. for security access the sub-functions are from 0x00 – 0xFF are available with a different security level. If you are not understanding the security level don’t worry I will explain below for your doubt clear. basically, all the odd values are used for seed request whereas the next even values (Seed request security level + 1) are will be used to send the security key to the ECU to unlock by using the Security Access Service Identifier (0x27)

To prevent that the ECU is modified by unauthorized persons most UDS services are locked. To get access to services that are used to modify the ECU the user first has to grant access through the Security Access Service Identifier (0x27). Only after the security access service has been passed, services like Request Download and Transfer Data can be used. The security concept used is called “Seed and Key”. Security Access Service flow:

Security Access Seed Request Frame

The below table explains how to request seed from client to server for unlocking an ECU as per the above steps. Please remember that the Security Access Service Identifier (0x27) mostly supports in Extended diagnostic session, so before you request it you should know the diagnostic session that how to jump from the default session to the extended diagnostic session. If you want to learn this then please go to my default session tutorial and first learn that and then come to this session. For remind you, it is 10 03

Security Access Service seed Request Frame format

The above table defines what are the data format should be maintained to use the Security Access service in UDS Protocol for requesting a seed. Let me explain you by one example how to request a seed:

Security access Seed Request over CAN data frame

Security Access Seed Response Frame

The response message has a response SID and if it is a positive response the parameter is an echo of the request message parameter. If it is a negative response the parameter is one of eight negative response codes.

Security Access Service seed Response Frame format

The above table defines what are the data format should be maintained to use the Security Access Service Identifier (0x27) in UDS Protocol for getting a seed key response from an ECU. Let me explain to you by one example of how an ECU sends a response frame for the above request seed. Remember I have taken the example as the response seed key is 0x1234, it can be anything as per the OEM algorithm implementation.

Security access Seed Response over CAN data frame

Security Access SendKey Request Frame

When the client will request a seed first to the ECU, the ECU will receive, and as per the ECU behavior, it will send the response as positive or negative. If it is negative then the client should take the decision of what action needs to be done. But if it is positive, then the Client will receive the seed key sent by the server and then the client will generate a security key from that seed key sent by the ECU. So let’s go discuss how the client will send this security key and in which format. Look onto the below table for details:

Security Access Service send key Request Frame format

I hope you already understood the format from the above table as to how to send a generated send key. So let’s go see how it will be in a CAN frame with an example:

Security Access SendKey Response Frame

When the client will send the “sendkey” request message with a valid security key, the server will check to compare that key with the sake key generated by the client and if it will match then the server will unlock the ECU. Then after unlock the ECU will send a positive response message as below table.

Security Access Service seed Response Frame format

If you understood the above table that how the server should send the positive response message, then let’s go see really in CAN data frame how the client is sending the positive response message. Please look at the below table.

Security access Seed Response over CAN data frame

In the above table it defines the CAN “sendkey” response message.

Security Access Negative Response Message

The Security Access Service Identifier (0x27) is having different negative response codes that are used to inform the user if any wrong request or any fault is there in ECU for which the ECU is not able to execute this Security Access Service Identifier (0x27) successfully. Suppose the request message sent by the client is not supported in that ECU or any kind of problem. You might say it is a hardware fault, security mismatch, software fault, timing issue, or sequence issue defined as per the ISO14229 standard or OEM, then the client will send a negative response message with the particular code value. As per this code, the client can understand the problem and it needs to be fixed. Please look at the below table for getting to know all the security access negative response codes (NRC).

Security Access NRC frame format

In the below table, you would have understood the frame, but let me explain to you also how it is as per the below table so that you can do the same in your canalyzer or canoe tool for simulation.

Key points of Security Access Service (0x27)

Once the ECU will get unlocked, then you can able to read or write any authorized data to or from the ECU. but if you will not do any task after unlocking your ECU, automatically the ECU will be locked after some time as per the timing parameter defined by the OEM.

I hope you guys will understand this service ID very well if you have any doubt you can ask your question in my forum website. Please write your comment below if this tutorial helps you in understanding or getting a good job or helping you crack the interview in the Automotive field.

Источник

Хакаем CAN шину авто. Мобильное приложение вместо панели приборов

Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.

По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.

Программный сниффер VCDS

Чтобы узнать по какому протоколу общаются электронные блоки я использовал специальную версию VCDS с программным сниффером в комплекте. В этот раз никаких железных снифферов на Arduino или RPi не пришлось изобретать. С помощью CAN-Sniffer можно подсмотреть общение между VCDS и автомобилем, чтобы затем телефон мог прикинуться диагностической утилитой и отправлять те же самые запросы.

Я собрал некоторую статистику по использованию диагностических протоколов на разных моделях автомобилей:

Протокол UDS

Диагностические данные от двигателя по протоколу UDS (Skoda Octavia A7)

В моей машине (Skoda Octavia A5) приборка использует UDS протокол, это дало мне легкий старт разработки, т.к. данные были в простом формате Single Frame SF (фрейм, вся информация которого умещается в один CAN пакет) и большинство значений легко поддавались расшифровке. Volkswagen не дает документацию на формат значений, поэтому формулу расшифровки для каждого датчика приходилось подбирать методом логического мышления. Про UDS протокол очень хорошо и с подробным разбором фреймов написано на canhacker.ru.

Разбор UDS пакета в формате Single Frame

Пример запроса и ответа температуры моторного масла:

Запрос температуры моторного масла:

Ответ температуры моторного масла:

Первая версия мобильного приложения VAG Virtual Cockpit умела подключаться только к приборной панели по UDS.

VW Transport Protocol 2.0

Т.к. KWP2000 использует сообщения переменной длины, а CAN шина позволяет передавать сообщения не больше 8 байт, то VW TP 2.0 разбивает длинное сообщение KWP2000 на части при отправке по CAN шине и собирает заново при получении.

Диагностические данные от двигателя по протоколу KWP2000 (Skoda Octavia A5)

ЭБУ двигателя моей машины использует протокол VW TP 2.0, поэтому мне пришлось изучить его. Видимо Volkswagen разрабатывала транспортный протокол не только для работы по надежной CAN шине, но и для менее надежных линий связи, иначе нет объяснения для чего требуется такая избыточная проверка целостности данных. Главным источником информации по VW TP 2.0 является сайт https://jazdw.net/tp20.

Разбор протокола VW TP 2.0 на примере подключения к первой группе двигателя:

200 01 C0 00 10 00 03 01

201 00 D0 00 03 40 07 01

740 A0 0F 8A FF 32 FF

Настраиваем ЭБУ на отправку сразу 16 пакетов и выставляем временные параметры

300 A1 0F 8A FF 4A FF

Получили положительный ответ

740 10 00 02 10 89

Получили первый ACK

300 10 00 02 50 89

Мы отправили первый ACK, что получили ответ

740 11 00 02 21 01

Получили второй ACK

300 22 00 1A 61 01 01 C8 13

300 23 05 0A 99 14 32 86 10

300 24 FF BE 25 00 00 25 00

300 15 00 25 00 00 25 00 00

Отправляем ACK. Прибывляем к нашему предыдущему ACK количество полученных пакетов 0xB1 + 0x4 = 0xB5

Запрос KeepAlive, что мы еще на связи

740 A1 0F 8A FF 4A FF

Мы разрываем связь

ЭБУ в ответ тоже разрывает связь

Во второй версии мобильного приложения VAG Virtual Cockpit появилась возможность диагностировать двигатель и трансмиссию по протоколу VW TP 2.0.

Диагностический адаптер ELM327

Для меня некоторое время было вопросом, как получить данные из CAN шины и передать на телефон. Можно было бы разработать собственный шлюз с Wi-Fi или Bluetooth, как это делают производители сигнализаций, например Starline. Но изучив документацию на популярный автомобильный сканер ELM327 понял, что его можно настроить с помощью AT команд на доступ к CAN шине.

Копия диагностического сканера ELM327 Не все ELM327 одинаково полезны

Оригинальный ELM327 от компании elmelectronics стоит порядка 50$, в России я таких не встречал в продаже. У нас продаются только китайские копии/подделки, разного качества и цены 10-30$. Бывают полноценные копии, которые поддерживают все протоколы, а бывают и те которые умеют отвечать только на несколько команд, остальные игнорируют, такие адаптеры не имеют доступ к CAN шине. Я например пользуюсь копией Viecar BLE 4.0, который поддерживает 100% всех функций оригинала.

Для работы с протоколом UDS через ELM327 нужно указать адреса назначения, источника и разрешить длинные 8 байтные сообщения, по умолчанию пропускается максимум 7 байт.

Последовательность ELM327 AT команд для работы с UDS по CAN шине:

Для работы с протоколом KWP2000 через ELM327 нужно только указать адреса назначения и источника.

Последовательность ELM327 AT команд для работы с VW TP 2.0 по CAN шине:

Мобильное приложение VAG Virtual Cockpit

Для разработки мобильного приложения подключаемого к автомобилю требовалось:

Сниффером собрать трафик от диагностической утилиты VCDS

Изучить работу протоколов UDS, VW TP 2.0, KWP2000

Настроить диагностический сканер ELM327 на работу с UDS и VW TP 2.0

Изучить новый для меня язык программирования Swift

Мобильное приложение VAG Virtual Cockpit для iOS

В итоге получилось приложение, которое сочетает в себе функции отображения точных данных панели приборов и диагностика основных параметров двигателя и трансмиссии.

На данный момент приложение показывает следующие параметры:

Приборная панель

Двигатель

Трансмиссия (температура)

1) Какая дверь открыта
2) Скорость
3) Обороты
4) Температура масла
5) Температура ОЖ
6) Топливо в баке в л.
7) Запас хода в км.
8) Средний расход
9) Время в машине
10) Пробег
11) Температура за бортом

1) Обороты
2) Массовый расход воздуха
3) Температура забора воздуха
4) Температура выхлопа (рассчитанная)
5) Критический уровень масла
6) Уровень масла
7) Наддув турбины (реальный)
8) Наддув турбины (ожидаемый)
9) Пропуски зажигания в цилиндрах
10) Углы откатов зажигания в цилиндрах

1) ATF AISIN (G93)
2) DSG6 (G93)
3) Блок управления DSG6 (G510)
4) Масло диска сцепления DSG6 (G509)
5) Мехатроник DSG7 (G510)
6) Процессор DSG7
7) Диск сцепления DSG7

Я стремлюсь чтобы приложение поддерживало как можно больше моделей автомобилей. Пока что поддерживаются производители: Volkswagen, Skoda, Seat, Audi. На разных комплектациях могут отображаться не все параметры, но это поправимо.

Сейчас я провожу тестирование версии 3.0. Приложение доступно только на iOS, после релиза 3.0 перейду к разработке версии для Android.

Если интересно потестировать и есть желание принять участие в проекте, то установить приложение можно по ссылке. Также я веду бортжурнал на drive2.ru, где делюсь полезной информацией и новостями о VAG Virtual Cockpit.

Источник

Протокол 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 пакет.

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 миллисекунд

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

Фрейм UDS

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

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

Пример
Запрос
CAN 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 Диагностический прибор: DLC=8 DATA: 02 09 02 00 00 00 00 00
2 Ответ автомобиля: DLC=8 DATA: 10 14 49 02 01 57 41 55 “WAU”
3 Диагностический прибор: DLC=8 DATA: 30 02 00 00 00 00 00 00
4 Ответ автомобиля: DLC=8 DATA: 21 5A 5A 5A 38 45 37 37 “ZZZ8E77”
5 Ответ автомобиля: 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

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

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

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

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

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

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

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

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

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

1 Диагностический прибор: 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

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

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

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

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

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

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

Источник