Обзор Автомобильного Протокола UDS [ISO 14229-1] / Habr

UDS (ISO 14229) (Unified Diagnostic Services) это бинарный прикладной протокол. Обычно этот протокол гоняют поверх протокола ISO-TP в CAN шине между ECU. Подробно протокол описан в стандарте ISO-14229. UDS - это диалоговый протокол, то есть работает по принципу запрос - ответ. Получается, что тут есть master и slave узлы. Ещё говорят клиент и сервер. Где клиент - это тестировочное оборудование (обычно LapTop), а сервер - ECU с микроконтроллером внутри. В качестве ECU может выступать контроллер форсунок, автоматическая коробка передач, телематический блок, кузовная электроника, HMI или прочая электронная плата внутри автомобиля.

Бинарные протоколы хороши тем, что они компактные.

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

В тексте представлен дословный перевод спецификации ISO 14229-1 и некоторых других сайтов ��ро UDS.

Если вы хотите в свои прошивки добавлять поддержку протокола UDS, то можете сразу первым делом подготовить встроенные модульные тесты и запустить NVRAM. Без этого говорить о добавлении UDS не имеет смысла. Как ни крути, а сперва надо подготовить зависимости.

Что надо из спецификаций?

Полная спецификация UDS составляет 400+ страниц. Документ называется International Standard ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements

№	Код спеки	Пояснение
1	ISO 14229-1	Спецификация прикладного уровня UDS
2	ISO 11899-2	Controller area network
3	ISO-15765	Transport Layer

Стек протоколов выстраивается в пирамиду.

На самом деле формально ничто не запрещает гонять этот UDS и по другим интерфейсам. Как в случае с протоколом XCP. Например по тому же UART. UDS это же про то как на входной массив байт выдать ответный выходной массив байт. Только и всего... Надо лишь отдельно указать тип адреса: физический или функциональный. Режим UDS over UART весьма полезен для модульных тестов UDS. Чтобы разграничить возможные ошибки в реализаци�� ISO-TP от ошибок в реализации UDS. В связи с этим я бы порекомендовал Вам не приколачивать гвоздями свой код UDS к CAN коду, а добавить возможность переключаться между интерфейсами в зависимости от конфига в экземпляре UDS драйвера. Условно, вы можете объявить три экземпляра UDS. Первый прикрепить к CAN, второй UDS вывести на UART2, а третий просто оставить без интерфейсов чисто как SW экземпляр специально для модульных тестов реализации самого протокола.

Что позволяет протокол UDS?

UDS работает на уровне приложения и на сеансовом уровне модели OSI-7. UDS протоколом можно перезагрузить микроконтроллер, обновлять прошивку, управлять агрегатами автомобиля, считывать результаты модульного тестирования железа и софта, считывать диагностические параметры агрегатов и прочее.

№	Действие
1	Запустить на исполнение модульные тесты (DTC)
2	считать результат исполнения модульных тестов (DTC)
3	Стереть результат прохождения модульных тестов (DTC)
4	запросить текущие параметры датчиков и блоков управления (ECU)
5	Прочитать/прописать физическую память
6	Подменить значения датчиков
7	Обновить прошивку
8	давать команды исполнительным механизмам. Запускать подпрограммы
9	Прописывать калибровочные данные
10	Прописывать и читать конфигурационные данные
11	Перезагрузить устройство

Переменные в этом протоколе (такие как DID) передаются в формате Big-Endian. Контрольная сумма в UDS отсутствует, так как она и так проверяется на канальном уровне, где работает CRC15 от CAN пакетов.

Подпрограммы встроены в саму прошивку ECU и могут быть начаты по UDS команде от клиента. Например UDS подпрограммой можно открыть и закрыть дверной замок.

Вот так может выглядеть обновление и считывание прошивки с ECU. Надо отладить всего 4 пакета: RequestDownload, RequestUpload, TransferData и RequestTransferExit.

Теория (Определения)

Для понимания протокола UDS надо вспомнить cледующие определения:

Массив - непрерывная последовательность байт. Массив обладает размером.
Структура - набор переменных разного типа данных
Пакет - бинарная структура в массиве
UDS cервис - это просто входной пакет, на который спецификацией определён ответный пакет.
Сервер - это ECU. ECU - электронная плата с микроконтроллером, которая решает какую-либо задачу внутри автомобиля. Это может быть плата управления автоматической коробкой переключения передач (АКПП), контроллер бензиновых (или газовых) форсунок, телематический блок, плата управления батареей BMS, плата управления подвеской, плата электро-усилителя руля (Electric Power Steering ), плата управления обогревом и кондиционером, плата управления тяговым инвертором, сигнализация, плата управления парковочной видеокамерой заднего вида, плата управления подушкой безопасности, приборная панель, плата управления АБС, плата управления ESP, кузовная электроника (габаритные огни), парковочный радар, радар круиз контроля, мультимедийная система (infotainment), плата управления подогревом сидений. Всё что угодно. Все эти платы в отдельности являются ECU.

Клиент - LapTop. Тестировочное оборудование с программой UDS-клиента внутри. Мастер UDS сети.
Файл - именованный массив в памяти (обычно энерго независимой). У файла всегда есть имя (иногда метаданные) .( В файла должны храниться метаданные про DTC).
Сессия - это процесс, деятельность, саенс, совещание, заседание. Сессии имеют свойство повторяются. Сессии ограничены во времени.
Идентификатор - имя переменной выражаемое в виде натурального числа
Метаданные - информация о другой информации, или данные, относящиеся к дополнительной информации о содержимом или объекте. Метаданные раскрывают сведения о признаках и свойствах, характеризующих какие-либо сущности, позволяющие автоматически искать и управлять ими в больших информационных потоках.
Параметр - это переменная, которая помимо адреса в памяти, значения и размера несет в себе ещё и метаданные про физическую величину, размерность, тип данных, единицы измерения, множитель, тип доступа, формат записи, допустимый интервал значений и прочее, и прочее.
Примером параметра может служить обороты двигателя. Это физическая переменная угловой скорости, представляется действительным числом, 4 байта, измеряемая в оборотах в секунду. Множитель тысячи (*1000). Её можно только читать. Может принимать только положительные значения. И так далее.

Тест: Тест — это встр��енный алгоритм диагностического программного обеспечения, определяющий состояние неисправности компонента или системы, как правило, в течение одного рабочего цикла. Некоторые тесты выполняются только один раз за рабочий цикл. Другие тесты могут выполняться в каждом цикле программы, с частотой выборки до нескольких миллисекунд. Конечный результат теста представляет собой полностью зрелое/квалифицированное состояние (т.е. пройдено или не пройдено). Это означает, что тест, для которого требуется наличие неисправного состояния в течение определенного времени или оценка дополнительных проверок на правдоподобие, прежде чем компонент будет считаться неисправным, вернет состояние «Не пройдено» только после выполнения всех критериев зрелости. Каждый код неисправности связан с тестом, представляющим обнаруживаемую неисправность или симптом.

diagnostic trouble code (DTC) - числовой общий идентификатор неисправности, выявленной бортовой диагностической системой. Отдельный DTC представляется 3х байтовым числом. Типичные значения показаны в Table D.1.

Confirmed DTC (Подтвержденные упавшие тесты) упавшие несколько раз подряд модульные тесты, которые были автоматически подтверждены и зарегистрированы прошивкой в долговременной файловой системе автомобиля. Когда ECU (Electronic Control Unit) обнаруживает неисправность, он генерирует DTC, который указывает на тип проблемы. Эти коды могут быть временными или постоянными. В случае Confirmed DTC, это означает, что неисправность была зафиксирована прошивкой несколько раз. В этом случае номер этого DTC следует записать в NVRAM. Дальше уже человек будет решать, что с этим делать.

Тестовый отсчёт: - это однобитное число, которое говорит прошел тест или провалился.

Для ЭБУ, поддерживающего счетчик обнаружения неисправностей DTC, тестовый сэмпл, представляющий собой неудачу, увеличит счетчик обнаружения неисправностей DTC на определенную величину, а тестовый образец, представляющий собой успех, уменьшит счетчик обнаружения неисправностей DTC на определенную величину.

Завершено: Завершение означает, что тест смог определить, существует ли неисправность или нет в текущем рабочем цикле (завершение не означает неудачу).

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

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

Отказ: Отказ — это неспособность компонента или системы выполнять свою предполагаемую функцию. Отк��з происходит, когда неисправности обнаруживаются в течение достаточно длительного периода времени, что означает, что тест дал результат «Неудачно». Термины «отказ» и «неисправность» взаимозаменяемы.

Монитор: Монитор представляет собой один или несколько тестов, используемых для определения надлежащего функционирования компонента или системы.

Цикл мониторинга: Цикл мониторинга — это время, в течение которого монитор работает до завершения своих задач. Это

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

Рабочий цикл: Рабочий цикл определяет условия начала и окончания работы мониторов. В течение рабочего цикла может быть завершено несколько циклов мониторинга (независимо от результатов их тестирования). Блок управления двигателем (ЭБУ) может поддерживать несколько рабочих циклов. Для ЭБУ кузова и шасси производитель определяет рабочий цикл (например, время между включением и выключением ЭБУ или между включением и выключением зажигания). Для ЭБУ силового агрегата существуют дополнительные критерии, определяющие рабочий цикл. ЭБУ силового агрегата, связанные с выбросами, используют период работы двигателя или выключения двигателя для определения рабочего цикла, который называется циклом движения. Если условие сброса бита состояния DTC связано с началом рабочего цикла, это также может считаться концом предыдущего цикла (т.е. не всегда возможно отличить начало от конца каждого рабочего цикла).

Ожидание: Статус ожидания для сбоя определяется как результат «Неудачно» теста, полученный в течение текущего рабочего цикла или в течение последнего завершенного рабочего цикла. Как только тест получит результат «Успешно» в течение полного рабочего цикла с этим сбоем, статус ожидания сбрасывается.

Порог старения: Старение кода неисправности определяется как отсутствие результатов «Неудачно» в тесте за заданное количество циклов работы, определенных производителем автомобиля или нормативными актами, и зависит от производителя автомобиля, если соответствующий цикл запускает увеличение счетчика старения в зависимости от того, завершился ли тест полностью или нет в течение цикла. В реализациях может использоваться счетчик старения (см. рис. D.11) в качестве триггера для изменения подтвержденного статуса с 1 на 0 и удаления информации о коде неисправности из энергонезависимой памяти. Счетчик старения подсчитывает количество циклов (например, циклов прогрева), соответствующих ранее упомянутым критериям. Если этот счетчик достигает порогового значения (например, 40 циклов прогрева), бит подтверждения изменяется с 1 на 0.
Seed - номер пароля или своеобразный логин, выраженный в виде натурального числа.
Key - своеобразный пароль выраженный в виде натурального числа.

Что надо из доков?

Полный стандарт UDS - это четыре сотни страниц английской словесности! Спека определяет 26 разных как снежинки пакетов.

#6	Документ	Пояснение	pages
1	ISO 14229	Стандарт описывает уровень приложения для UDS	464

UDS это надстройка над транспортный протоколом ISO-TP (ISO-15765). Про ISO-TP у меня есть отдельный текст: Обзор Протокола ISO-TP [ISO 15765-2] https://habr.com/ru/articles/798489/.

Есть два типа ответов от ECU: положительный и отрицательный. Положительные ответы легко узнать так как они начинаются с запрашиваемого SID + 0x40.

Аппаратная часть

UDS не определяет внешний вид разъёма. Однако скорее всего UDS будет на 6 и 14 пинах разъёма OBD2. К слову, в легковых автомобилях разъём OBD2 реализован в виде гнезда. Поэтому для подключения Вам потребуется ответная часть в виде вилки. Перед установкой вилки обязательно проверьте, что между разъёмами не очутилась всяческая грязь в виде фольги от папиросок или прочих проводников.

Структура UDS совместимых сетей передачи данных

Архитектура UDS протокола подразумевает наличие клиента и сервера.

С сервером USD всё понятно. Это ECU. В качестве клиента в конечном счете будет выступать LapTop.

При этом тестированную утилиту можно написать тоже на Си пере используя значительную часть Си кода прошивки в виде консольного Win приложения.

Что же такое Diagnostic Trouble Code (DTC)?

Протокол UDS в основном работает с diagnostic trouble code (DTC) - это числовой 24-битный общий идентификатор неисправности, выявленной бортовой диагностической системой. Отдельный DTC представляется 3х байтовым числом. Типичные значения показаны в Table D.1. Вот примеры DTC: 0x012345 0xDCBA98 0xFFFFFF.

По UDS можно читать DTC, стирать DTC.

DTC - это по сути своей числовое 24 битное выражение (псевдоним) имени модульного теста (self-test), который не прошел. Условно hash24() от название модульного теста. При этом модульный тест встроен прямо в саму прошивку (причем релизную). Чтобы понять есть ли неисправность или нет конкретной неисправности надо как-то вызвать модульный тест и посмотреть, что он вернёт: true или false. При этом запускать self-test можно пакетами группы RoutineControl (0x31). Комбинаторика 24-битных DTC говорит, что чисто теоретически так можно определить 16 777 216 модульных тестов.

1) Каждый код неисправности (DTC) имеет 8-битное поле состояния (DTC Status), описывающее текущее состояние соответствующей неисправности и ее историю.

2) При этом каждому коду неисправности (DTC) может быть присвоено значение уровня его серьезности (DTC Severity), которое кодирует как его нормативную классификацию, так и степень серьезности. Это значение определяется программным обеспечением ЭБУ или калибровкой и не изменяется во время работы автомобиля. Значение уровня серьезности DTC содержит две части информации: класс DTC GTR (биты 0-4) и степень серьезности (биты 5-7).

3) DTC каждому коду неисправности DTC присваивается 8-битное (со знаком) значение, называемое счетчиком обнаружения неисправностей DTC. Каждый блок управления двигателем (ЭБУ) выполняет самотестирование, предназначенное для обнаружения наличия в данный момент условий отказа, соответствующих его кодам неисправности DTC. Если самотестирование не удается, счетчик увеличивается на величину, зависящую от реализации. Если самотестирование проходит успешно, счетчик уменьшается на величину, зависящую от реализации. Когда счетчик достигает своего максимального значения (127), бит testFailed устанавливается в 1. Когда счетчик достигает своего минимального значения (-128), бит testFailed устанавливается в 0. В начале каждого рабочего цикла счетчик обнаружения неисправностей DTC сбрасывается до 0.

4) Для каждого кода неисправности (DTC) хранится счетчик износа. Он регистрирует количество циклов работы автомобиля с момента последнего возникновения неисправности. Когда счетчик износа достигает порогового значения (обычно после 40 циклов работы), код неисправности считается устаревшим и должен быть удален из памяти. Эта процедура часто называется самовосстановлением.

Итак, подытожим... Что входит в комплект одного единственного DTC?

№	Метаданные	Метаданные	Размер, байт
1	24 битное уникальное имя кода неисправности	DTC	3
2	статус	DTC Status	1
3	уровня его серьезности	DTC Severity	1
4	Счетчик обнаружения неисправностей	DTC Fault Detection Counter	1
5	счетчик износа	DTC Aging Counter	?
6	указатель на ассоциированный модульные тест	self-test	4

Не хило так. Да? При этом вся эта структура для каждого DTC должна храниться, внезапно, в NVRAM! Ибо отвечать на UDS ReadDTC запросы надо мгновенно, а тесты в отдельности могут исполнятся и десятки минут.
Вам уже нравится протокол UDS?

Структура UDS ��акета для запроса

Рассмотрим структуру бинарного пакета для запроса.

Поле #1: SID Service ID [1-Byte]

Поле #2: UDS Sub Function [1-Byte]

Некоторые UDS запросы имеют под функцию а некоторые нет.

Иногда USD пакет может полностью поместиться в 8 байт, как запрос так и ответ.

Поле №3: Data Identifier DID [2 байта]

DID - это переменные ECU, которые можно читать или писать. Физически DID хранятся либо в RAM либо в Flash памяти микроконтроллера (NVRAM). Каждый DID адресуется 16-битным адресом. То есть в ECU может храниться до 65536 переменных. Сами же эти DID переменные могут быть совершенно любого размера, как по 1 байту, так и целые массивы. Чисто теоретически через DID можно прочитать скорость автомобиля, обороты двигателя и прочие переменные ECU. Чтобы прочитать DID надо использовать сервис 0x22-Read Data by Idenvifier (RDBI). Чтобы прописать DID надо использовать сервис 0x2E - Write Data By Identifier (WDBI)

В самом простом случае использования по UDS можно читать данные по их ID. Для этого есть сервис SID=0x22.

DiagnosticSessionControl (0x10) service (Пакет Управление диагностической сессией)

Пакет DiagnosticSessionControl используется для включения различных диагностических сессий на сервере (серверах).

Сеанс диагностики активирует определенный набор диагностических служб и/или функций на ECU. Этот пакет обеспечивает возможность ECU сообщать значения параметров канального уровня, действительные для активированного сеанса диагностики (например, значения параметров синхронизации). Пользователь данного международного стандарта должен определить точный набор служб и/или функций, активированных в каждом сеансе диагностики.

На ECU всегда должна быть активна ровно одна диагностическая сессия. ECU всегда должен запускать диагностическую сессию по умолчанию при включении питания. Если никакая другая диагностическая сессия не запущена, то диагностическая сессия по умолчанию будет работать до тех пор, пока ECU включен.

ECU должен быть способен обеспечивать диагностические функции в нормальных условиях эксплуатации и в других условиях эксплуатации, определенных производителем транспортного средства (например, в режиме аварийной работы).

Если клиент запросил диагностическую сессию, которая уже запущена, то сервер должен отправить положительное ответное сообщение и вести себя так, как показано на рисунке 7, описывающем внутреннее поведение сервера при переходе между сессиями.

На рисунке 7 представлен общий обзор перехода между диагностическими сессиями и того, что должен делать сервер при переходе к другой сессии.

Всякий раз, когда клиент запрашивает новую диагностическую сессию, ECU должен отправить сообщение положительного ответа DiagnosticSessionControl до того, как в сервере активируются временные параметры новой сессии. В некоторых ситуациях может потребоваться, чтобы новая сессия была запущена до отправки положительного ответа, при этом сохраняя старые временные параметры протокола для отправки ответа. Если ECU не может начать запрошенную новую диагностическую сессию, он должен ответить сообщением отрицательного ответа DiagnosticSessionControl, и текущая сессия должна продолжиться (см. определения параметров diagnosticSession для получения дополнительной информации о том, как должны вести себя сервер и клиент). Набор диагностических служб и диагностических функций в нестандартной диагностической сессии (за исключением programmingSession) является надмножеством функциональности, предоставляемой в defaultSession, что означает, что диагностические функции defaultSession также доступны при переключении на любую нестандартную диагностическую сессию. Сессия может включать в себя службы и функции, специфичные для производителя транспортного средства, и которые не являются частью данного документа.

Для начала новой диагностической сессии сервер может запросить выполнение определенных условий. Все такие условия определяются пользователем. Примеры таких условий:

1) Сервер может разрешить запуск новой диагностической сессии только клиенту с определенным идентификатором клиента (адресом диагностики клиента) (например, сервер может потребовать, чтобы расширенную диагностическую сессию мог запустить только клиент с идентификатором клиента 0xF4).

2) Для обеспечения безопасности могут потребоваться определенные условия (например, транспортное средство не должно двигаться или двигатель не должен работать).

В некоторых системах желательно изменять параметры синхронизации связи при запуске новой диагностической сессии. Сущность службы DiagnosticSessionControl может использовать соответствующие сервисные примитивы для изменения параметров синхронизации, заданных для нижележащих уровней, чтобы изменить синхронизацию связи на локальном узле и, возможно, на узлах, с которыми клиент хочет взаимодействовать.

сессия по умолчанию: Когда сервер находится в сессии по умолчанию и клиент запрашивает запуск сессии по умолчанию, сервер должен полностью повторно инициализировать сессию по умолчанию. Сервер должен сбросить все активированные/инициированные/измененные настройки/элементы управления во время активной сессии. Это не включает долгосрочные изменения, запрограммированные в энергонезависимую память.

другая сессия: Когда сервер перехо��ит из defaultSession в любую другую сессию, отличную от defaultSession,

сервер должен останавливать только те события (аналогично stopResponseOnEvent), которые были настроены на сервере через службу ResponseOnEvent (0x86) в течение defaultSession.

та же или другая сессия: Когда сервер переходит из любой диагностической сессии, кроме defaultSession, в

другую сессию, отличную от defaultSession (включая текущую активную диагностическую сессию), сервер должен

(повторно) инициализировать диагностическую сессию, что означает следующее:

–1 Каждое событие, настроенное на сервере через службу ResponseOnEvent (0x86), должно быть остановлено.

–2 Доступ к системе безопасности будет повторно заблокирован. Обратите внимание, что блокировка доступа к системе безопасности приведет к сбросу любой активной диагностической функциональности, которая зависела от разблокировки доступа к системе безопасности (например, активный inputOutputControl DID).

–3 Вся остальная активная диагностическая функциональность, поддерживаемая в новой сессии и не зависящая от доступа к системе безопасности, будет сохранена. Например, любой настроенный периодический планировщик останется активным при переходе от одной сессии, отличной от сессии по умолчанию, к другой или к той же самой сессии, отличной от сессии по умолчанию, и состояния служб CommunicationControl и ControlDTCSetting не будут затронуты, что означает, что обычная связь останется отключенной, когда она отключена в момент переключения сессии.

4) сессия по умолчанию: Когда сервер переходит из любой диагностической сессии, кроме сессии по умолчанию, в сессию по умолчанию, сервер должен остановить каждое событие, настроенное на сервере через службу ResponseOnEvent (0x86), и должна быть включена безопасность. Любая другая активная диагностическая функциональность, которая не поддерживается в сессии по умолчанию, должна быть прекращена. Например, любой настроенный периодический планировщик или управление выводом должны быть отключены, а состояния служб CommunicationControl и ControlDTCSetting должны быть сброшены, что означает, что нормальная связь должна быть повторно включена, когда она была отключена в момент переключения сессии на сессию по умолчанию. Сервер должен сбросить все активированные/инициированные/измененные настройки/управление во время активной сессии. Это не включает долгосрочные изменения, запрограммированные в энергонезависимую память.

В таблице 23 определены службы, разрешенные во время defaultSession и non-defaultSession (службы с таймером). Любая non-defaultSession привязана к диагностическому таймеру сессии, который должен оставаться активным для клиента.

Параметр diagnosticSessionType используется службой DiagnosticSessionControl для выбора конкретного поведения сервера. Подробное описание и использование возможных диагностических сессий приведено в таблице 25.

Эта диагностическая сессия включает стандартную диагностическую сессию на сервере(ах) и не поддерживает никаких механизмов обработки таймаутов диагностического приложения (например, для поддержания активности сессии не требуется служба TesterPresent). Если на сервере была активна какая-либо другая сессия, кроме defaultSession, и defaultSession запускается снова, то должны соблюдаться следующие правила реализации (см. также диаграмму состояний диагностической сессии сервера, приведенную выше): Сервер должен остановить текущую диагностическую сессию, когда он отправит сообщение положительного ответа DiagnosticSessionControl, и затем запустить вновь запрошенную диагностическую сессию.

Если сервер отправил сообщение положительного ответа DiagnosticSessionControl, он должен повторно заблокировать сервер, если клиент разблокировал его во время диагностической сессии. Если сервер отправляет сообщение отрицательного ответа с идентификатором службы запроса DiagnosticSessionControl, активная сессия должна быть продолжена.

ПРИМЕЧАНИЕ. В случае, если используемая линия передачи данных требует этапа инициализации, то инициализированный(е) сервер(ы) должны по умолчанию запустить сеанс диагностики по умолчанию. После этапа инициализации не потребуется параметр DiagnosticSessionControl с параметром diagnosticSession, установленным в значение defaultSession.

ProgrammingSession - Эта диагностическая сессия включает все диагностические службы, необходимые для поддержки программирования памяти сервера. В случае, если сервер запускает сессию программирования в загрузочном программном обеспечении, сессия программирования должна быть завершена только через службу ECUReset (0x11), инициированную клиентом, службу DiagnosticSessionControl (0x10) с типом сессии, равным defaultSession, или при истечении времени ожидания на уровне сессии в сервере. В случае, если сервер запускается в загрузочном программном обеспечении, когда он получает службу DiagnosticSessionControl (0x10) с типом сессии, равным defaultSession, или происходит истечение времени ожидания на уровне сессии, и в обоих случаях присутствует действующее прикладное программное обеспечение, сервер должен перезапустить прикладное программное обеспечение. В данном документе не указаны различные методы реализации перезапуска действующего прикладного программного обеспечения (например, действующее прикладное программное обеспечение может быть определено непосредственно в загрузочном программном обеспечении, во время фазы запуска ЭБУ при выполнении сброса ЭБУ и т. д.).

extendedDiagnosticSession - Данная диагностическая сессия может использоваться для включения всех диагностических служб, необходимых для поддержки настройки таких функций, как «Скорость холостого хода, значение CO и т. д.», в памяти сервера. Она также может использоваться для включения диагностических служб, которые не связаны напрямую с настройкой функций (например, см. службы с заданным временем в таблице 23).

safetySystemDiagnosticSession - Данная диагностическая сессия включает в себя все диагностические службы, необходимые для поддержки функций, связанных с системой безопасности (например, срабатывание подушек безопасности).

sessionParameterRecord - Эта запись параметров содержит значения параметров, специфичные для сессии, сообщаемые сервером. Содержимое записи параметров сессии (sessionParameterRecord) определено в таблицах 28 и 29.

ECUReset (0x11)
UDS позволяет перезагрузить микроконтроллер. Для этого достаточно буквально отправить два байта.

ReadDataByIdentifier (SID=0x22) service

Этот сервис позволяет клиенту запрашивать значения данных по одному или более идентификатору данных DID.

Запрос клиент содержит одно или более двухбайтовых DID значений, которые соответствуют данным. Формат и определение записей данных должны быть определены производителем ECU. Там могут быть показания аналоговых входов, цифровых входов или выходов, внутренние данные, статус системы и прочее.

Сервер может ограничить количество DIDов которые запрашивают одновременно за раз.

Получив пакет SID=0x22 ECU должен извлечь запрашиваемые данные с заданным DID и передать их значение в одном положительном ответе, который содержит соответствующее значение данных. Запрос может содержать тот же самый DID несколько раз. ECU должен рассматривать каждый DID как отдельный параметр и отвечать данными для каждого DID, как запрошено.

UDS предусматривает положительный и отрицательный ответ. В случае положительного ответа в ответном пакете к оригинальному SID прибавляется константа 0x40. Вот пример запроса скорости транспортного средства (DID=0xF40D) по UDS. В пакете DID передается в big-endian формате, то есть старшим байтом вперёд.

Это же в составе с ISO-TP

Однако есть и отрицательные ответы. Это может произойти если Вы запросили значение DID про который ECU ничего не знает. В случае негативного ответа это может быть, когда сервис не поддерживается.

Вот все коды ошибок для ответа на пакет ReadDataByIdentifier

NRC	Description	Mnemonic
0x13	incorrectMessageLengthOrInvalidFormat	IMLOIF
0x14	responseTooLong	RTL
0x22	conditionsNotCorrect	CNC
0x31	requestOutOfRange	ROOR
0x33	securityAccessDenied	SAD

Вот так выглядит попытка прочитать не валидный DID=0xAAAA, который не поддерживает ECU.

Прибор просто посылает значение 0x31 (requestOutOfRange), что запрошенное 16-битное значение DID не поддерживается этим конкретным CAN-устройством.

Кодов отрицательный ответов (NRC_) десятки. Вот некоторые из них

Пакеты группы ReadDTCInformation (0x19)

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

В каждом блоке управления двигателем (ЭБУ) есть встроенные программы проверки неисправностей, которые выдают результаты тестирования. В зависимости от результатов тестирования это может быть «ПРОЙДЕНО» или «НЕ ПРОЙДЕНО». Для каждой неисправности реализуется множество тестовых программ. Но это не значит, что все тестовые программы запускаются сразу после включения питания ЭБУ или запуска основной программы.

Таким образом, существует множество конкретных критериев, по которым должна запускаться данная тестовая программа для проверки наличия диагностической ошибки. Это поможет снизить перегрузку выполнения программ микроконтроллера. Это также позволяет обнаруживать конкретную ошибку только тогда, когда это действительно необходимо в соответствии с требованиями системы.

Можно сказать, что используются специфические критерии, установленные производителем сервера, транспортного средства или поставщиком системы, для определения момента выполнения сервером конкретной внутренней диагностики. Если неисправность активна, то мы можем прочитать код неисправности (DTC) с помощью службы «Чтение информации о коде неисправности 0x19».

Критерии сдачи теста:

Теперь мы пришли к выводу, что когда тестовые программы будут запускаться для конкретной неисправности, мы уверены, что они запустятся. Но нам нужно знать, когда эта неисправность должна быть успешной или неудачной. Это означает, при каких условиях мы можем сказать, что неисправность возникает и нам нужно устранить эту проблему, только тогда должен быть зарегистрирован соответствующий код неисправности (DTC), в противном случае он не должен быть зарегистрирован. Это означает, что неисправность возникает, но она не подтверждена. Если вы хотите прочитать неподтвержденный код неисправности (DTC), вы можете сделать это, используя пакет «Чтение информации о коде неисправности 0x19» с байтом состояния 0x04.

Если внутри автомобиля произойдёт короткое замыкание, и система не сможет восстановиться, тогда и нужно будет регистрировать коды неисправностей (DTC).

Таким образом, для каждого кода неисправности (DTC) будут существовать программы диагностического тестирования. Для каждого теста будут свои специфические условия прохождения теста. Эти критерии определяются производителем сервера, транспортного средства или поставщиком системы. Таким образом, они определяют, функционирует ли диагностируемая система должным образом в пределах нормальных, допустимых рабочих диапазонов или нет.

Критерии сбоя тестирования:

Условия тестирования для конкретного диагностического теста имеют значение. Как и в случае с условиями прохождения теста, существует множество условий, при которых программа тестирования должна принять решение о том, что тест не пройден. Условия отказа, специфичные для производителя сервера, транспортного средства или поставщика системы, определяют, прошла ли диагностируемая система тест или нет.

Критерии подтверждения неисправности:

Теперь снова вопрос: что такое подтвержденная неисправность? Неисправность может возникнуть, и она может быть не подтвержденной. Но она может возникать не одновременно. Поскольку она происходит между различными услов��ями, мы должны проверить и устранить ее до того, как она будет зарегистрирована, что может обойтись дороже. Поэтому для обработки всех этих случаев у нас есть байт состояния DTC, который хранится для каждого условия проверки.

Для каждого теста существуют свои условия подтверждения неисправности. Это также называется «зрелым кодом неисправности» (DTC). Существуют различные циклы работы, после которых определенная неисправность становится «зрелой». В результате этот код неисправности сохраняет все зависимые данные, такие как байт состояния, запись снимка, расширенная запись данных и т. д., в постоянной памяти микроконтроллера. Его можно использовать в будущем, когда это потребуется, или в сервисном центре.

Счетчик возникновения неисправностей:

В каждом блоке управления двигателем (ЭБУ) есть тестовые программы, которые периодически запускаются в соответствии с системными требованиями. Но для подтверждения неисправности требуется несколько циклов работы. Каждый цикл работы имеет счетчик ошибок. Этот счетчик ошибок возвращает единицу при возникновении ошибки в определенном количестве случаев. Таким образом, каждый тест DTC регистрирует уникальное событие сбоя теста. Для чтения значения этого счетчика можно использовать службу «Чтение информации о коде неисправности 0x19».

Получение количества кодов неисправностей (DTC), соответствующих заданной клиентом маске состояния (подфункция = 0x01 reportNumberOfDTCByStatusMask)

Клиент может получить количество кодов неисправностей (DTC), соответствующих заданной клиентом маске состояния, отправив запрос на эту услугу с подфункцией reportNumberOfDTCByStatusMask. Ответ на этот запрос содержит DTCStatusAvailabilityMask, который указывает на биты состояния DTC, поддерживаемые сервером для целей маскирования. После DTCStatusAvailabilityMask ответ содержит DTCFormatIdentifier, который сообщает информацию о форматировании и кодировке DTC. За DTCFormatIdentifier следует параметр DTCCount, представляющий собой 2-байтовое беззнаковое число, содержащее количество кодов неисправностей, доступных в памяти сервера на основе маски состояния, предоставленной клиентом. Вспомогательная функция reportNumberOfMirrorMemoryDTCByStatusMask имеет ту же функциональность, что и вспомогательная функция reportNumberOfDTCByStatusMask, с той разницей, что она возвращает количество кодов неисправностей (DTC) в зеркальной памяти.

Получение списка кодов неисправностей (DTC), соответствующих заданной клиентом маске состояния (подфункция = 0x02 reportDTCByStatusMask)

Клиент может получить список кодов неисправностей (DTC), удовлетворяющих заданной клиентом маске состояния, отправив запрос с установленным байтом подфункции reportDTCByStatusMask. Эта подфункция позволяет клиенту запросить у сервера отчет обо всех кодах неисправностей, которые имеют статус «testFailed», «confirmed» или «etc.». Вычисление должно производиться следующим образом: сервер должен выполнить побитовую логическую операцию И между маской, указанной в запросе клиента, и фактическим состоянием, связанным с каждым кодом неисправностей, поддерживаемым сервером. В дополнение к DTCStatusAvailabilityMask сервер должен вернуть все коды неисправностей, для которых результат операции И отличен от нуля (т.е. (statusOfDTC & DTCStatusMask) != 0). Если клиент указывает маску состояния, содержащую биты, которые сервер не поддерживает, то сервер должен обрабатывать информацию DTC, используя только те биты, которые он поддерживает. Если в сервере нет кодов неисправностей (DTC), соответствующих критериям маскирования, указанным в запросе клиента, то после байта DTCStatusAvailabilityMask в положительном ответном сообщении не будет предоставлена информация о кодах неисправностей или состоянии. Информация о состоянии кодов неисправностей будет удалена после успешного запроса ClearDiagnosticInformation от клиента (см. определения битов состояния кодов неисправностей в D.2 для получения дополнительной информации об обработке битов состояния кодов неисправностей в случае получения запроса на обслуживание ClearDiagnosticInformation на сервере).

Получение количества кодов неисправностей (DTC), соответствующих заданной клиентом маске серьезности (подфункция = 0x07 reportNumberOfDTCBySeverityMaskRecord)

Клиент может получить количество кодов неисправностей (DTC), соответствующих заданной клиентом маске статуса серьезности, отправив запрос на эту услугу с подфункцией, установленной в значение reportNumberOfDTCBySeverityMaskRecord. Сервер должен просканировать все поддерживаемые коды неисправностей, выполнив побитовую логическую операцию И между записью маски, указанной клиентом, и фактической информацией о каждом сохраненном коде неисправности.

(((statusOfDTC & DTCStatusMask) != 0) && ((severity & DTCSeverityMask) != 0)) == TRUE

Для каждой операции И, дающей результат TRUE, сервер должен увеличить счетчик на 1. Если клиент указывает маску состояния в записи маски, содержащую биты, которые сервер не поддерживает, то сервер должен обрабатывать информацию о кодах неисправностей, используя только те биты, которые он поддерживает. После того, как все поддерживаемые коды неисправностей будут проверены один раз, сервер должен вернуть DTCStatusAvailabilityMask и результирующее 2-байтовое значение счетчика клиенту.

ПРИМЕЧАНИЕ: Если ни один код неисправности на сервере не соответствует критериям маскирования, указанным в запросе клиента, счетчик, возвращаемый сервером клиенту, будет равен 0. Сообщаемое количество кодов неисправностей, соответствующих маске состояния кодов неисправностей, действительно для момента времени, когда был сделан запрос. Нет никакой связи между сообщаемым количеством кодов неисправностей и фактическим списком кодов неисправностей, считанных с помощью подфункции reportDTCByStatusMask, поскольку запрос на чтение кодов неисправностей выполняется в другой момент времени.

Получение информации о степени серьезности и функциональном блоке, соответствующей заданной клиентом маске серьезности. record (sub-function = 0x08 reportDTCBySeverityMaskRecord)

Клиент может получить список кодов неисправности (DTC) и информацию о функциональном блоке, удовлетворяющих заданной клиентом маске серьезности, отправив запрос с установленным байтом подфункции reportDTCBySeverityMaskRecord. Эта подфункция позволяет клиенту запросить у сервера отчет обо всех кодах неисправности с определенной серьезностью и статусом, которые имеют значение «testFailed», «confirmed» или «etc.». Оценка должна выполняться следующим образом: Сервер должен выполнить побитовую логическую операцию И между DTCSeverityMask и DTCSStatusMask, указанными в запросе клиента, и фактическими значениями DTCSeverity и statusOfDTC, связанными с каждым кодом неисправности, поддерживаемым сервером. В дополнение к DTCStatusAvailabilityMask, сервер должен вернуть все коды неисправностей (DTC), для которых результат операции И равен TRUE,

(((statusOfDTC & DTCStatusMask) !=0) && ((severity & DTCSeverityMask) != 0)) == TRUE

Если клиент указывает маску состояния в записи маски, содержащую биты, которые сервер не поддерживает,

то сервер должен обрабатывать информацию о кодах неисправностей, используя только те биты, которые он поддерживает. Если ни один код неисправности на сервере не соответствует критериям маскирования, указанным в запросе клиента, информация о кодах неисправностей или состоянии не будет предоставлена

после байта DTCStatusAvailabilityMask в сообщении положительного ответа.

Получение информации о степени серьезности и функциональном блоке для определенного клиентом кода неисправности (подфункция = 0x09 reportSeverityInformationOfDTC)

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

Получение первого/последнего неисправного кода неисправности (подфункция = 0x0B reportFirstTestFailedDTC,

подфункция = 0x0D reportMostRecentTestFailedDTC)

Клиент может получить первый/последний неисправный код ошибки (DTC) от сервера, отправив запрос с байтом подфункции, установленным в значение «reportFirstTestFailedDTC» или «reportMostRecentTestFailedDTC» соответственно. Вместе с

байтом DTCStatusAvailabilityMask сервер должен вернуть клиенту номер первого или последнего неисправного кода ошибки и

связанный с ним статус. Информация о коде ошибки/статусе не будет предоставлена после байта DTCStatusAvailabilityMask в положительном ответном сообщении, если с момента последнего запроса клиента к серверу на очистку диагностической информации не было зарегистрировано ни одного неисправного кода ошибки. Кроме того, если с момента последнего запроса клиента к серверу на очистку диагностической информации возник только один неисправный код ошибки, то этот единственный неисправный код ошибки будет возвращен как в запросе reportFirstTestFailedDTC, так и в запросе reportMostRecentTestFailedDTC от клиента.

Запись о первом/последнем неисправном коде неисправности (DTC) должна быть независима от процесса устаревания подтвержденных кодов неисправности. Как указано выше, информация о первом/последнем неисправном коде неисправности должна быть удалена после успешного запроса ClearDiagnosticInformation от клиента (см. определения битов состояния DTC в D.2 для получения дополнительной информации об обработке битов состояния DTC в случае получения запроса на обслуживание ClearDiagnosticInformation на сервере).

Получение статуса всех поддерживаемых сервером кодов неисправностей (подфункция = 0x0A

reportSupportedDTC)

Клиент может получить статус всех поддерживаемых сервером кодов неисправностей (DTC), отправив запрос к этой службе с подфункцией reportSupportedDTCs. Ответ на этот запрос содержит DTCStatusAvailabilityMask, который указывает на биты статуса DTC, поддерживаемые сервером, для целей маскирования. После DTCStatusAvailabilityMask ответ также содержит список DTCAndStatusRecord, который содержит номер DTC и связанный с ним статус для каждого диагностического кода неисправности, поддерживаемого сервером.

Получение первого/наиболее недавно обнаруженного подтвержденного кода неисправности (подфункция = 0x0C

reportFirstConfirmedDTC, подфункция = 0x0E reportMostRecentConfirmedDTC)

Клиент может получить первый/последний подтвержденный код неисправности (DTC) от сервера, отправив запрос с установленным байтом подфункции «reportFirstConfirmedDTC» или «reportMostRecentConfirmedDTC» соответственно. Вместе с байтом DTCStatusAvailabilityMask сервер должен вернуть клиенту первый или последний подтвержденный номер DTC и связанный с ним статус.

Информация о DTC/статусе не будет предоставлена после байта DTCStatusAvailabilityMask в положительном ответном сообщении, если с момента последнего запроса клиента к серверу на очистку диагностической информации не было зарегистрировано ни одного подтвержденного DTC. Кроме того, если с момента последнего запроса клиента к серверу на очистку диагностической информации был подтвержден только 1 DTC, то в оба запроса клиента (reportFirstConfirmedDTC и reportMostRecentConfirmedDTC) будет возвращен только один подтвержденный DTC.

Запись о первом подтвержденном коде неисправности (DTC) должна быть сохранена в случае, если этот код неисправности в какой-то момент в прошлом не был подтвержден, но затем соответствовал критериям старения до момента запроса от клиента (независимо от любых других кодов неисправности, которые были подтверждены после подтверждения указанного кода неисправности). Аналогично, запись о самом последнем подтвержденном коде неисправности должна быть сохранена в случае, если этот код неисправности был подтвержден в какой-то момент в прошлом, но затем соответствовал критериям старения до момента запроса от клиента (при условии, что после сбоя указанного кода неисправности не были подтверждены другие коды неисправности).

Как указано выше, информация о первом/самом последнем подтвержденном коде неисправности должна быть удалена после успешного запроса клиента на очистку диагностической информации (ClearDiagnosticInformation).

Получение списка кодов неисправностей (DTC) из памяти зеркала DTC сервера, соответствующих определенной клиентом маске состояния (подфункция = 0x0F reportMirrorMemoryDTCByStatusMask)

Обработка подфункции reportMirrorMemoryDTCByStatusMask идентична обработке, определенной для reportDTCByStatusMask, за исключением того, что все проверки маски состояния выполняются с кодами неисправностей (DTC), хранящимися в памяти зеркала DTC сервера. Память зеркала DTC — это дополнительная необязательная память ошибок на сервере, которую нельзя удалить службой ClearDiagnosticInformation (0x14). Память зеркала DTC зеркалирует обычную память DTC и может использоваться, например, если обычная память ошибок удалена.

Получение количества кодов неисправности зеркальной памяти, соответствующих заданной клиентом маске состояния (подфункция = 0x11 reportNumberOfMirrorMemoryDTCByStatusMask)

Клиент может получить количество кодов неисправност��й зеркальной памяти, соответствующих заданной клиентом маске состояния, отправив запрос на эту услугу с подфункцией, установленной на reportNumberOfMirrorMemoryDTCByStatusMask. Ответ на этот запрос содержит DTCStatusAvailabilityMask, который указывает на биты состояния кодов неисправностей, поддерживаемые сервером, для целей маскирования. После DTCStatusAvailabilityMask ответ содержит DTCFormatIdentifier, который сообщает информацию о форматировании и кодировании кодов неисправностей. За DTCFormatIdentifier следует параметр DTCCount, представляющий собой 2-байтовое беззнаковое число, содержащее количество кодов неисправностей, доступных в памяти сервера, на основе маски состояния, предоставленной клиентом.

ReadScalingDataByIdentifier (SID=0x24)

Сервис ReadScalingDataByIdentifier показывает как интерпретировать данные из ECU. Это необходимо для понимания визуализации данных полученных от ECU. Благодаря пакету ReadScalingDataByIdentifier LapTop запрашивает у ECU информацию про его внутренние переменные. Для каждой доступной переменной можно узнать её

scaling information	Возможные варианты	ед. изм.
битовые отображения	?	?
формулы и коэффициенты преобразования	1/x; ax+b	?
тип данных	uint8 int32 float string и т п	тип данных
физическую величину	скорость, массу, ток	физ. величина
размер в памяти	1, 2, 5	байт
единицы измерения	градусы или радианы, паскали, бары, атмосферы или сила на кв метр	единицы измерения
размерный множитель	милли, пико, нано и т. п.	размерный множитель

Всё это называется словом scaling information. У каждого DID должна быть известная информация про тип, размер, величину, единицы измерения, множитель. Запрос от LapTop содержит одно ID переменной. Формат поля dataRecord должны быть определены по желанию производителя транспортного средства и могут включать сигналы аналоговых входов или выходов, цифровые входы, внутренние данные, информацию про статус системы. В случае получения пакета запроса ReadScalingDataByIdentifier микроконтроллер должен получить доступ к информации про переменную и передать значения в положительном ответе.

Переменная scalingByteExtension содержит единицы измерения, формат и множитель. Это нужно для представления переменной в дружественном для человека виде. Для каждой размерности в UDS предусмотрен числовой код в виде натурального числа. Поле scalingByteExtension определяет множитель для более компактного представления числа в памяти. Поле scalingByteExtension применимо только для формул, чисел и битовых масок. Для переменных типа unit первым байтом определяется единицы измерения переменной. Коды множителей перечислены в таблице Table C.8 — Unit/format scalingByteExtension encoding.

ReadDataByPeriodicIdentifier (0x2A)

Пакет ReadDataByPeriodicIdentifier позволяет клиенту запрашивать периодическую передачу значений параметров данных с ECU, идентифицированного одним или несколькими идентификаторами periodicDataIdentifier.

Сообщение запроса клиента содержит одно или несколько однобайтовых значений periodicDataIdentifier, которые идентифицируют записи данных, поддерживаемые сервером. periodicDataIdentifier представляет собой младший байт dataIdentifier из диапазона dataIdentifier, зарезервированного для этой службы (0xF2XX, см. C.1 для допустимых значений periodicDataIdentifier), например, periodicDataIdentifier 0xE3, используемый в этой службе, — это dataIdentifier 0xF2E3.

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

При получении запроса ReadDataByPeriodicIdentifier, отличного от stopSending, сервер должен проверить, соответствуют ли условия для выполнения службы.

Параметр periodicDataIdentifier может поддерживаться только с одним значением transmissionMode в данный момент времени. Изменение расписания periodicDataIdentifier должно выполняться при получении сообщения-запроса, в котором параметр transmissionMode установлен на новое расписание для того же periodicDataIdentifier. Поддержка нескольких расписаний для разных periodicDataIdentifier может осуществляться по запросу производителя транспортного средства.

ВАЖНО — Если условия соблюдены, ECU должен отправить положительный ответ, содержащий только идентификатор службы. Сервер никогда не должен отправлять отрицательный ответ после того, как он принял первоначальный запрос, отправив положительный ответ.

После получения первоначального положительного ответа сервер должен получить доступ к элементам данных записей, указанных параметром(ами) periodicDataIdentifier, и передать их значение в отдельных периодических ответных сообщениях для каждого periodicDataIdentifier, содержащих соответствующие параметры dataRecord.

Отдельные периодические сообщения ответа на данные, определенные для передачи данных periodicDataIdentifier клиенту, следующие за первоначальным положительным ответным сообщением, должны включать periodicDataIdentifier и данные periodicDataIdentifier, но не идентификатор службы положительного ответа.

Задокументированная периодическая частота для конкретного режима передачи определяется как время между любыми двумя последовательными ответными сообщениями с одним и тем же periodicDataIdentifier, когда запланирован только один periodicDataIdentifier. Если одновременно запланировано несколько periodicDataIdentifier, эффективный период между одним и тем же periodicDataIdentifier будет варьироваться в зависимости от следующих параметров проектирования:

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

Значения этих параметров повлияют на то, насколько увеличится эффективный период между одинаковыми периодическими идентификаторами данных (periodicDataIdentifier), если одновременно передается несколько periodicDataIdentifier. Поэтому все вышеупомянутые параметры проектирования должны быть указаны производителем транспортного средства. Каждый раз, когда вызывается периодический планировщик, он должен определять, готовы ли к передаче какие-либо periodicDataIdentifier.

Периодическая частота является целым кратным периодической частоте вызовов планировщика.

Например, две различные реализации ЭБУ могут поддерживать быстрый режим передачи с периодичностью 10 мс и одним уникальным идентификатором адресной информации периодического ответного сообщения данных. Если первая реализация вызывает периодический планировщик каждые 10 мс, время между вызовами одного и того же periodicDataIdentifier увеличится до 20 мс при планировании двух periodicDataIdentifier и до 40 мс при планировании четырех periodicDataIdentifier. Если вторая реализация вызывает периодический планировщик каждые 5 мс, время между вызовами одного и того же periodicDataIdentifier останется равным 10 мс при планировании двух periodicDataIdentifier и увеличится до 20 мс при планировании четырех periodicDataIdentifier.

При получении запроса ReadDataByPeriodicIdentifier, включающего параметр transmissionMode stopSending, сервер должен либо остановить периодическую передачу periodicDataIdentifier(s), содержащихся в запросе, либо остановить передачу всех periodicDataIdentifier, если в запросе не указан конкретный идентификатор. Ответное сообщение на этот параметр transmissionMode содержит только идентификатор службы.

Сервер может ограничить количество периодических идентификаторов данных (periodicDataIdentifier), которые могут поддерживаться одновременно, в соответствии с договоренностью, достигнутой производителем транспортного средства и поставщиком системы. Превышение максимального количества периодических идентификаторов данных, которые могут поддерживаться одновременно, приведет к одному отрицательному ответу, и ни один из периодических идентификаторов данных в этом запросе не будет запланирован. Повторение одного и того же периодического идентификатора данных в одном сообщении запроса не допускается, и сервер должен игнорировать их все, кроме одного периодического идентификатора данных, если клиент нарушает это правило.

transmissionMode - Этот параметр определяет частоту передачи запрошенных периодических идентификаторов данных (periodicDataIdentifiers), которые будут использоваться сервером.

periodicDataIdentifier - Этот параметр идентифицирует запрашиваемую клиентом запись данных сервера (см. C.1 и описание службы выше для подробного определения параметра). Должна быть возможность запросить несколько periodicDataIdentifiers в рамках одного запроса.

Данные объекта periodicDataIdentifier передаются периодически (с обновленными данными) с частотой, определяемой параметром transmissionMode запроса.

После получения первоначального положительного ответа, для каждого поддерживаемого periodicDataIdentifier в запросе сервер должен начать отправлять одно периодическое ответное сообщение с данными.

Данная служба не поддерживает параметры данных ответного сообщения в положительном ответном сообщении.

Запись NVRAM по ID. WriteDataByIdentifier (SID=0x2E)

Сервис WriteDataByIdentifier позволяет LapTop-у прописывать информацию во внутренности ECU по идентификатору данных. Можно прописывать так называемые dataRecord. Данные идентифицируются по идентификатору данных. Идентификатор данных имеет разрядность 16 бит. Благодаря этому сервису можно прописывать конфигурационные данные в ECU. Например VIN номер. Прописывать NVRAM память. При этом надо ограничивать доступ на изменение определенных ID.

Чтение сырой памяти по физическим адресам микроконтроллера

UDS протокол позволяет читать физическую память. Для этого заложены пакеты типа ReadMemoryByAddress (SID: 0x23). UDS клиент должен запоминать, что и сколько он хотел прочитать, так как в ответном пакете от ECU отсутствует повторение значения адреса и размера пакета. В ответе только данные.

Запись сырой физической памяти WriteMemoryByAddress (SID=0x3D)

Протокол UDS позволяет прописывать произвольную физическую память. В случае 32бит МК получается вот такой пакет.

TesterPresent (0x3E) [Hello пакет для индикации присутствие клиента]

Этот пакет используется для того, чтобы сообщить ECU , что LapTop все ещё подключен к транспортному средству и что определенные диагностические службы и средства связи, которые были активированы ранее, должны оставаться активными.

Этот Blink пакет используется для удержания ECU (или нескольких ECU) в диагностической сессии, отличной от defaultSession. Это может быть сделано путем периодической передачи сообщения запроса TesterPresent. Опять таки, с каким именно периодом надо отправлять пакет TesterPresent спека не говорит.

Чтение информации по Diagnostic Trouble Codes Service(0x19)

Этот сервис позволяет клиенту читать состояние диагностических кодов ошибок на ECU от любого сервера или группы серверов. Если иное не требуется конкретной подфункцией то сервер должен возвращать всю информацию о DTC (например связанную или несвязанную с выбросами). Этот сервис позволяет сделать следующее:

Получите количество кодов DTC, соответствующих маске состояния DTC, определенной клиентом.
Получить список всех кодов неисправности, соответствующих маске состояния кодов неисправности, определенной клиентом.
Получить список кодов DTC в конкретной функциональной группе, соответствующих маске состояния DTC, определенной клиентом.
Получите все коды DTC со статусом «постоянный код неисправности».

RequestTransferExit (0x37)

Данный пакет используется клиентом для завершения переноса данных между клиентом и сервером. Под переносом подразумевается загрузка или скачивание непрерывной последовательности байтов. Попросту LapTop берёт и запрашивает окончание переноса байтов. Поэтому закономерно что этот пакет работает в тандеме с такими пакетами как RequestDownload, RequestUpload и TransferData. Сам по себе пакет RequestTransferExit не работает.

transferRequestParameterRecord - Данная запись параметров содержит параметры, необходимые ECU для поддержки передачи данных. Формат и длина этих параметров зависят от производителя автомобиля. Можно и вовсе ничего не писать.

transferResponseParameterRecord - Этот параметр должен содержать параметры, необходимые клиенту для поддержки передачи данных. Формат и длина этого параметра (параметров) зависят от производителя транспортного средства. Можно и вовсе ничего не писать.

InputOutputControlByIdentifier (0x2F) (Управление входами и выходами по их идентификатору)

Сервис InputOutputControlByIdentifier используется клиентом для подстановки значения входного сигнала, внутренней функции сервера и/или управления силой в значение выходного сигнала (исполнительного механизма) электронной системы. В целом, этот сервис используется для относительно простой (например, статической) подстановки входного сигнала/управления выходным сигналом, тогда как сервис routineControl используется, если необходима более сложная подстановка входного сигнала/управление выходным сигналом.

Сообщение запроса клиента содержит идентификатор данных (dataIdentifier), который ссылается на входной сигнал, внутреннюю функцию сервера и/или выходной сигнал(ы) (исполнительный механизм(ы)) (в случае доступа к управлению устройством он может ссылаться на группу сигналов) сервера. Параметр controlOptionRecord должен содержать всю информацию, необходимую для входного сигнала(ов), внутренней функции(й) и/или выходного сигнала(ов) сервера. Производитель транспортного средства может потребовать, чтобы сообщение запроса содержало controlEnableMask, если идентификатор данных, которым необходимо управлять, ссылается на более чем один параметр (т.е. идентификатор данных упакован или представлен в виде битовой карты). Если производитель транспортного средства решит поддерживать концепцию EnableMask, параметр controlEnableMask является обязательным для всех типов запросов InputOutputControlByIdentifier для этой услуги. Если запрашивается inputOutputControlByIdentifier для dataIdentifier, который ссылается на измеренное выходное значение или значение обратной связи, сервер должен отвечать за подстановку правильного целевого значения в стратегию управления сервера, чтобы обычная стратегия управления сервера попыталась достичь желаемого состояния из сообщения запроса клиента.

Сервер должен отправить положительное ответное сообщение, если управление запросом было успешно запущено или достигло желаемого состояния. Сервер должен отправить положительное ответное сообщение на запрос с параметром inputOutputControlParameter, равным returnControlToECU, даже если dataIdentifier в данный момент не находится под управлением тестера. Кроме того, при получении запроса returnControlToECU сервер всегда должен предоставлять клиенту возможность установить все биты controlMask (если поддерживается) в значение «1», чтобы полностью вернуть управление пакетированным или битовым dataIdentifier обратно в ЭБУ. Формат и длина байтов controlState, следующих за параметром inputOutputControlParameter в параметре controlOptionRecord запроса, должны точно соответствовать длине и формату dataRecord запрашиваемого dataIdentifier. Таким образом, гарантируется, что фактическое состояние выхода или входа может быть получено с помощью службы ReadDatabyIdentifier с тем же DID.

При использовании службы inputOutputControlByIdentifier для подстановки входных данных или управления выходными данными, к блоку управления, принимающему запрос, предъявляются два основных требования.

№	Требование
1	отключение соответствующего(их) объекта(ов) данных, на который(е) ссылается(ются) параметр(ы) в dataIdentifier, от всех вышестоящих стратегий управления, которые в противном случае обновляли бы значение объекта данных.
2	подстановка значения в соответствующий(ие) объект(ы) данных, который(е) будет(ут) использоваться для всех последующих действий стратегии управления.

Например, запрос тестера на прямое включение фар должен предотвратить влияние положения переключателя фар на выходной сигнал фар и подставить желаемое состояние «Вкл.» в объект(ы) данных, используемый(ые) функциями, которые в конечном итоге определяют желаемое состояние выходного сигнала фар.

Данная служба позволяет управлять одним идентификатором данных (dataIdentifier) и соответствующим ему параметром (параметрами) в одном запросе. В этом случае сервер ответит одним сообщением, содержащим идентификатор данных запроса, а также информацию о статусе управления (controlStatus).

Пакеты класса RoutineControl (Управление Подпрограммами) (SID=0x31)

Пакет RoutineControl используется клиентом для выполнения определенной последовательности шагов и получения любых релевантных результатов. Этот сервис обладает большой гибкостью, но типичное использование может включать такие функции, как стирание памяти, сброс или обучение адаптивных данных, запуск самотестирования, переопределение обычной стратегии управления сервером, управление изменением значения сервера во времени, включая предопределенные последовательности (например, закрытие складной крыши) и другие. В целом, при использовании для управления выходными данными этот сервис применяется для более сложных типов управления, тогда как inputOutputControlByIdentifier используется для относительно простого (например, статического) управления выходными данными.

Сервис RoutineControl используется клиентом для следующего

Описание	sub-function	Mnemonic	Количество аргументов
Начать подпрограмму	0x01	STR	1-2
остановить подпрограммы	0x02	STPR	1
запросить результат подпрограммы	0x03	RRR	1

Каждой подпрограмме поставлен в соответствие 2-байтовый идентификатор подпрограммы routineIdentifier.

Начать процедуру по ID

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

Подпрограммы могут быть либо тестами, которые выполняются вместо обычного рабочего кода, либо подпрограммами, которые активируются и выполняется при нормальном рабочем коде. В частности, в случае теста это может быть необходимо переключить сервер в конкретный диагностический сеанс с помощью службы DiagnosticSessionControl или разблокировать сервер с помощью службы SecurityAccess перед использованием службы StartRoutine.

Остановить подпрограмму по ID

Серверная подпрограмма должна быть остановлена в памяти сервера через некоторое время после завершения отправки сообщения запроса StopRoutine и завершения отправки первого ответного сообщения, если ответное сообщение положительное или отрицательное, указывающее на то, что запрос на остановку подпрограммы уже выполнен или находится в процессе выполнения. ПРИМЕЧАНИЕ. Серверная подпрограмма может быть остановлена в любое время в соответствии с запрограммированными параметрами или предварительной инициализацией в памяти сервера.

Запросить результат подпрограммы по ID

Эта подфункция используется клиентом для запроса результатов (например, информации о статусе завершения), на которые ссылается параметр подфункции routineIdentifier и которые генерируются подпрограммой, выполненной в памяти сервера.

На основе результатов подпрограммы, которые могли быть получены в положительном ответном сообщении параметра подфункции stopRoutine (например, нормальное/ненормальное завершение с результатами), должна использоваться подфункция requestRoutineResults.

Примером routineResults могут быть данные, собранные сервером, которые не могут быть переданы во время выполнения подпрограммы из-за ограничений производительности сервера (ECU).

Для работы защищенных процедур требуется служба SecurityAccess, а следовательно, и нестандартная диагностическая сессия. Процедура, которую клиент должен активно остановить, также требует нестандартной сессии.

Вот так выглядит бинарная структура пакета запроса для RoutineControl в общем виде

RequestFileTransfer (0x38) (Запрос на перемещение файла)
Сервис requestFileTransfer используется LapTop-ом для инициирования передачи файловых данных либо от клиента к серверу, либо от сервера к клиенту (загрузка или выгрузка). Кроме того, этот сервис обладает возможностями для получения информации о файловой системе.
Данный пакет предназначена в качестве альтернативного решения для служб RequestDownload и RequestUpload, поддерживая функциональность загрузки и выгрузки данных, если сервер использует файловую систему для хранения данных.
При настройке процесса загрузки или выгрузки данных в файловую систему или из нее следует использовать службу RequestFileTransfer, заменяющую RequestDownload или RequestUpload. Фактическая передача данных и завершение передачи данных реализуются с помощью TransferData и RequestTransferExit, как это используется с пакетами RequestDownload или RequestUpload. Эта служба также включает функциональность для удаления файлов или каталогов в файловой системе сервера. В этом случае службы TransferData и RequestTransferExit не применяются.

После получения сервером запроса RequestFileTransfer, ECU должен предпринять все необходимые действия для получения или передачи данных, прежде чем отправить положительный ответ.

modeOfOperation - Этот параметр данных определяет тип операции, применяемой к файлу или каталогу, указанному в параметре filePathAndName. Значения параметра данных определены в Приложении G.

filePathAndNameLength - Определяет длину в байтах для параметра filePath.

filePathAndName - Определяет расположение файловой системы сервера, куда следует добавить, удалить, заменить или прочитать файл, в зависимости от параметра modeOfOperation. Кроме того, этот параметр включает имя файла, который следует добавить, удалить, заменить или прочитать, как часть пути к файлу. Если параметр modeOfOperation равен 0x05 (ReadDir), этот параметр указывает каталог для чтения. Каждый байт этого параметра должен быть закодирован в формате ASCII.

dataFormatIdentifier - Этот параметр данных представляет собой однобайтовое значение, при этом каждый полубайт кодируется отдельно. Старший полубайт определяет метод сжатия (compressionMethod), а младший полубайт — метод шифрования (encryptingMethod). Значение 0x00 указывает, что ни метод сжатия, ни метод шифрования не используются. Значения, отличные от 0x00, зависят от производителя транспортного средства. Если параметр modeOfOperation равен 0x02 (DeleteFile) и 0x05 (ReadDir), этот параметр не должен включаться в сообщение запроса.

fileSizeParameterLength - Определяет длину в байтах для обоих параметров fileSizeUncompressed и fileSizeCompressed. Если параметр modeOfOperation равен 0x02 (DeleteFile), 0x04 (ReadFile) или 0x05 (ReadDir), этот параметр не должен быть включен в сообщение запроса.

fileSizeUncompressed-Определяет размер несжатого файла в байтах. Если параметр modeOfOperation равен 0x02 (DeleteFile), 0x04 (ReadFile) или 0x05 (ReadDir), этот параметр не должен включаться в сообщение запроса.

lengthFormatIdentifier - Определяет длину (количество байтов) параметра maxNumberOfBlockLength. Если параметр modeOfOperation равен 0x02 (DeleteFile), этот параметр не будет включен в ответное сообщение.

maxNumberOfBlockLength -Этот параметр используется в сообщении положительного ответа requestFileTransfer для информирования клиента о том, сколько байтов данных (maxNumberOfBlockLength) следует включить в каждое сообщение запроса TransferData от клиента или сколько байтов данных сервер включит в сообщение положительного ответа TransferData при загрузке данных. Эта длина отражает полную длину сообщения, включая идентификатор службы и параметры данных, присутствующие в сообщении запроса TransferData или сообщении положительного ответа. Этот параметр позволяет клиенту адаптироваться к размеру буфера приема сервера, прежде чем начать передачу данных на сервер, или указать, сколько байтов данных будет включено в каждое сообщение положительного ответа TransferData в случае загрузки данных. Сервер обязан принимать запросы transferData, длина которых равна указанному значению maxNumberOfBlockLength. Принимаются ли запросы transferData меньшей длины, чем maxNumberOfBlockLength, в зависимости от сервера.

ПРИМЕЧАНИЕ. Последний запрос transferData в пределах данного блока может быть меньше, чем maxNumberOfBlockLength. Серверу не разрешается записывать дополнительные байты данных (т.е., байты заполнения), не содержащиеся в сообщении transferData (ни в сжатом, ни в несжатом формате), поскольку это повлияет на адрес памяти, куда будут записаны данные последующего запроса transferData. Если параметр modeOfOperation равен 0x02 (DeleteFile), этот параметр не должен включаться в ответное сообщение.

fileSizeOrDirInfoParameterLength - Определяет длину в байтах для обоих параметров fileSizeUncompressedOrDirInfoLength и fileSizeCompressed. Если параметр modeOfOperation равен 0x01 (AddFile), 0x02 (DeleteFile) или 0x03 (ReplaceFile), этот параметр не должен включаться в ответное сообщение.

fileSizeUncompressedOrDirInfoLength Определяет размер несжатого файла для загрузки или длину информации о каталоге для чтения в байтах. Если параметр modeOfOperation равен 0x01 (AddFile), 0x02 (DeleteFile) или 0x03 (ReplaceFile), этот параметр не должен включаться в ответное сообщение.

fileSizeCompressed - Определяет размер сжатого файла в байтах. Если параметр modeOfOperation равен 0x01 (AddFile), 0x02 (DeleteFile, 0x03 (ReplaceFile)) или 0x05 (ReadDir), этот параметр не должен включаться в ответное сообщение.

CommunicationControl (0x28) [Управление Общением]

Это сервис понять назначение которого трудно даже после многократного перечитывания спецификации. Поэтому просто привожу дословный перевод.

Целью сервиса CommunicationControl является включение/отключение передачи и/или приема определенных сообщений ECU (например, сообщений связи приложений).

communicationType (byte)- этот параметр используется для указания типа связи, которой надо управлять. Значения задают конкретные биты. Биты внутри позволяют управлять несколькими типами связи одновременно (normalCommunication и (или) networkManagementCommunication). Детализация бинарной структуры представлена в приложении B.1. Например первые два бита со значением 3 отключают сообщения normalCommunicationMessages и networkManagementCommunicationMessages. Старший нимбл определяет какая подсеть должна быть подключена (или отключена) к принимаемому ECU, когда соответствующий сервис управления общением принимается.

Вы чего-нибудь поняли? Я - нет. Но это дословный перевод спецификации.

Но опять таки, что такое normalCommunicationMessages ? Что такое networkManagementCommunicationMessages?

nodeIdentificationNumber (word)— это 2-байтовое значение, представляющее собой уникальный идентификационный номер узла, где-либо подключенного к сети в транспортном средстве. Или в подсети. Это ECUшный ID. Если ID в принятом пакете совпадает с его ID, то выполняется функция из запроса сервиса CommunicationControl

Например LIN совместимый ECU c уникальным адресом ECU в одной модели подключен к сети F, а в другой модели этот же модуль подключен к сети G.

К которому невозможно обратиться по адресу в более низких уровнях модели ISO-7. Параметр nodeIdentificationNumber существует в кадре запроса только когда controlType установлен в значения o 0x04 или 0x05.

При этом один и тот же узел может быть подключен к различным сетям в разных моделях автомобилей (например, узел LIN с уникальным адресом узла подключен к сети A в одной модели, а тот же узел подключен к сети B в другой модели). Получается что nodeIdentificationNumber - это аналог MAC адреса в автомобиле. Таким образом, nodeIdentificationNumber обеспечивает механизм, в рамках которого связанный главный узел, к которому подключен удаленный узел, переводит соответствующую сеть в определенный диагностический режим (например, отключает обычную связь в сети LIN). Только связанный главный узел, который обнаружил подключение соответствующего узла, идентифицированного nodeIdentificationNumber, должен выполнять запрошенную услугу communicationControl.

ControlDTCSetting (85 hex) (Управление настройками диагностических кодов неисправностей )

Сервис ControlDTCSetting используется клиентом для остановки или возобновления установки диагностических кодов неисправностей (DTC) на сервере (серверах).

Пакет ControlDTCSetting можно использовать для прекращения установки диагностических кодов неисправностей на отдельном ECU или в группе ECU. Если ECU, к которому обращаются, не может прекратить установку диагностических кодов неисправностей, он должен ответить отрицательным сообщением ControlDTCSetting, указывающим причину отклонения.

Обновление информации о битах состояния DTC должно продолжаться после выполнения запроса ControlDTCSetting, при этом подфункция должна быть установлена в значение «вкл.», или при истечении времени ожидания на уровне сессии (сервер переходит в состояние defaultSession). Сервер должен по-прежнему отправлять положительный ответ, если услуга поддерживается в активной сессии с запрошенной подфункцией, установленной в значение «вкл.» или «выкл.», даже если запрошенное состояние настройки DTC уже активно.

Если клиент отправляет сообщение clearDiagnosticInformation (14 hex), параметр ControlDTCSetting не должен запрещать сброс памяти кодов неисправностей сервера.

Если операция ECUReset будет успешно выполнена, это позволит повторно устанавливать коды неисправностей (DTC).

Запрашиваемый пакет передает две переменные.

ControlDTCSetting - Параметр используется в сообщении запроса ControlDTCSetting для указания ECU о том, следует ли прекратить или возобновить настройку диагностических кодов неисправностей.

DTCSettingControlOptionRecord- Этот параметр является необязательным для пользователя и передает данные на сервер при управлении настройкой DTC. Он может содержать список кодов неисправностей (DTC), которые необходимо включить или выключить.

Отрицательные ответы

В случае сбоев UDS отвечает отрицательными ответами. Структура пакета с отрицательным ответом показана в таблице 3. Payload начинается с константы 0x7F (SIDNR), номер SID (SIDRQ) и далее следует код ошибки (NRC_).

Адресация в UDS

В системах UDS адресация определяет участников обмена сообщениями, указывая отправителя и одного или нескольких получателей. Определены следующие типы адресации:
–Физическая адресация
–Функциональная адресация
Особенность UDS протокола в том, то на его поведение влияет CAN-ID. CAN ID влияет на то, как UDS будет отвечать на ошибки. Среди всего прочего CAN-ID может быть физическим и функциональным. Тип адресации определяется фрагментом CAN-ID принятого пакета. А именно полем TAT (Target Address type). В случае когда UDS доставляется протоколом ISO-TP за тип адреса отвечают биты 23-16 в Ext-CAN-ID пакета.

Физическая адресация или функциональна адресация или - это про то как серверу отвечать на пакеты. Таблицы, в которых фигурируют такие слова как физическая адресация или функциональная адресация показывают варианты причин положительных или отрицательных ответов.

Физическая адресация

Физическая адресация используется для связи между одним клиентом и одним сервером. Сообщения передаются напрямую (точка-точка) между клиентом и сервером. Сервер должен отвечать на запрос с физической адресацией, если в запросе явно не указано, что ответ не требуется. Для обмена данными с физической адресацией прямое физическое соединение не требуется. Сообщения могут передаваться через шлюзы для достижения целевого ECU.

Функциональная адресация

Функциональная адресация используется для одновременной отправки сообщений нескольким ECU. В этом режиме происходит связь «один ко многим» между клиентом и несколькими ECU. Серверы отвечают только на конкретные запросы с функциональной адресацией.

Чтение физической памяти

Направление передачи данных определяется сервисом RequestUpload. В ответ на пакет RequestUpload микроконтроллер высылает maxNumberOfBlockLength. Это максимальная длина в байтах сообщения TransferData, которую способен обработать этот микроконтроллер. Этот параметр позволяет клиенту адаптироваться к размеру буфера отправки сервера до того, как сервер начнет передачу данных клиенту.

Сервис TransferData (0x36) используется клиентом для передачи данных либо от клиента к серверу (загрузка), либо от сервера к клиенту (выгрузка). Если клиент инициировал RequestUpload, данные включаются в параметр(ы) transferResponseParameter в сообщении(ях) ответа TransferData.

1.858,I,[UdsClient],UdsClient1,RequestUpload,Addr:0x004821a0,Size:64 Byte
1.861,D,[UdsClient],ComposeTxFrame,RequestUpload,request,Addr:0x004821a0,Size:64 Byte
1.864,D,[UdsClient],SendDataTo:[UdsServer1],Data:[35 00 24 004821A0 0040]
1.869,D,[UdsServerLL],LapTop->ECU,size:9,data:350024004821A00040
1.884,N,[UdsServerTranf],Address:0x004821a0,size:64 Byte
1.889,D,[UdsServerLL],ECU->LapTop:size:4,data:75200082
1.931,D,[UdsClient],UDS_CLIENT_1,ExpSid:0x75,RxData:75200082
1.971,N,[UdsClient],RequestUploadPosResp:0x,SID:0x75,ParamLen:{,ParamSize:2 Byte,Res:0},Param:0082,MaxNumOfBlkLen:130 Byte
1.978,N,[UdsClient],max_number_of_block_length:130 byte
1.984,N,[UdsClient],UDS_CLIENT1,TransferData,AskData,blockSequenceCounter:1
1.991,D,[UdsClient],ComposeTxFrame,TransferData,request,blockSequenceCounter:1
2.012,D,[UdsServerLL],LapTop->ECU,size:2,data:3601
2.089,D,[UdsServerLL],ECU->LapTop:size:66,data:7601000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F
2.136,D,[UdsClient],RxDataChank,size:64,data:000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F
2.151,I,[UdsClient],DataRx,Done,size:64,data:000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F
2.194,D,[UdsServerLL],LapTop->ECU,size:1,data:37
2.212,D,[UdsServerLL],ECU->LapTop:size:1,data:77
2.237,D,[UdsClient],DataMoveDone!

Запрос к сервису TransferData включает blockSequenceCounter для улучшения обработки ошибок в случае сбоя сервиса TransferData во время последовательности нескольких запросов TransferData. blockSequenceCounter сервера должен быть инициализирован единицей при получении сообщения запроса RequestDownload (0x34) или RequestUpload (0x35). Это означает, что первое сообщение запроса TransferData (0x36), следующее за сообщением запроса RequestDownload (0x34) или RequestUpload (0x35), начинается с параметра blockSequenceCounter, равного единице.

Запись физической памяти

Аналогично можно и читать физическую память.

В логе клиента это выглядит так.

1.711,+1,193,I,[UdsClient],UDS_CLIENT1,DownLoad,Address:0x004821A0,size:16,data:[ABCDEF98765432108855556677889933]
1.715,+4,194,D,[UdsClient],ComposeTxFrame,RequestDownload,request,Addr:0x004821a0,Size:16 Byte
1.718,+3,195,D,[UdsClient],SendDataTo:[UdsServer1],Data:[34 00 24 004821A0 0010]
1.721,+3,196,D,[UdsServer],1RxArray,340024004821A00010
1.723,+2,197,D,[UdsServerLL],LapTop->ECU,size:9,data:340024004821A00010
1.730,+3,200,D,[UdsClient],Download,Ok
1.736,+6,201,D,[UdsServerTranf],udsSidRDU,thisSID:0x34
1.738,+2,202,N,[UdsServerTranf],Address:0x004821a0,size:16 Byte
1.741,+3,203,D,[UdsServer],udsSendResponse(
1.743,+2,204,D,[UdsServerLL],ECU->LapTop:size:4,data:74200082
1.789,+3,206,D,[UdsClient],UDS_CLIENT_1,ExpSid:0x74,RxData:74200082
1.793,+4,207,D,[UdsClient],UDS_CLIENT_1,RxPositiveResponse:[RequestDownload]
1.801,+8,208,N,[UdsClient],RequestPosRespDown:[,SID:0x74,ParamLen:{,ParamSize:2 Byte,Res:0},Param:0082,MaxNumOfBlkLen:130 Byte]
1.810,+9,209,N,[UdsClient],tx_max_number_of_block_length:130 byte
1.836,+21,211,N,[UdsClient],Client1,TransferData,TxData,blockSequenceCounter:1
1.843,+7,212,D,[UdsClient],ComposeTxFrame,TransferData,request,blockSequenceCounter:1,size:16,data:ABCDEF98765432108855556677889933
1.852,+9,213,D,[UdsClient],SendDataTo:[UdsServer1],Data:[3601ABCDEF98765432108855556677889933]
1.859,+7,214,D,[UdsServer],1RxArray,3601ABCDEF98765432108855556677889933
1.865,+6,215,D,[UdsServerLL],LapTop->ECU,size:18,data:3601ABCDEF98765432108855556677889933
1.877,+5,217,D,[UdsClient],TransferData,TxData,Ok
1.880,+3,218,D,[UdsServerTranf],udsSidTD:[,loadStatus:LD_IDLE,Dir:DOWNLOAD,memStartAddress:0x004821a0,memSize:16,DatCRC32:0xb2aa7578,memIndex:0,requestTime:0,memIndexPrev:0,blockSeqCntr:1,blockSeqCntrPrev:1,len:0,isMemOpOk:0,data:,crc32:0xB2AA7578,,Size:512,]
1.903,+4,220,N,[UdsServerTranf],DOWNLOAD,Len:16
1.916,+13,221,D,[UdsServerTranf]udsSidTD:[,loadStatus:LD_DONE,Dir:DOWNLOAD,memStartAddress:0x004821a0,memSize:16,DatCRC32:0x315ef3a4,memIndex:0,requestTime:1899,memIndexPrev:0,blockSeqCntr:1,blockSeqCntrPrev:1,len:16,isMemOpOk:1,data:,crc32:0x315EF3A4,,Size:512,]
1.949,+4,223,D,[UdsServerLL],ECU->LapTop:size:2,data:7601
1.959,+5,225,D,[UdsClient],UDS_CLIENT_1,ExpSid:0x76,RxData:7601
1.965,+6,226,D,[UdsClient],UDS_CLIENT_1,RxPositiveResponse:[TransferData]
1.980,+4,229,I,[UdsClient],DataTx,Done,size:16,data:ABCDEF98765432108855556677889933
1.987,+7,230,D,[UdsClient],ProcPositive,Ok
2.004,+17,231,N,[UdsClient],UDS_CLIENT1,RequestTransferExit
2.008,+4,232,D,[UdsClient],ComposeTxFrame,RequestTransferExit
2.013,+5,233,D,[UdsClient],SendDataTo:[UdsServer1],Data:[37]
2.022,+4,235,D,[UdsServerLL],LapTop->ECU,size:1,data:37
2.041,+5,239,D,[UdsServerLL],ECU->LapTop:size:1,data:77

Итоги

Появилось некоторое представление о UDS протоколе. Научились читать параметры по сервису SID=0x22 и запускать подпрограммы по UDS ( SID=0x31 ). Удалось научиться настраивать сессию, проходить проверку безопасности. Удалось читать и писать память по UDS протоколу.

DTC коды - это по сути номера модульных тестов встроенных в прошивку микроконтроллера. При падении теста его номер записывается в NVRAM.

UDS больше похож не на протокол, а на набор протоколов. Для каждого сервиса предусмотрена своя уникальная бинарная структура пакета, как для запроса, так и для ответа.

UDS настолько велик, что как правило мало, кто делает полную поддержку всех UDS сервисов. Обычно ограничиваются реализацией запуска подпрограмм, чтением / записью DIDов, чтением / запись физической памяти и пакета для Reset.

Словарь

акроним	расшифровка
UDS	Unified Diagnostic Services
ECU	Electronic Control Units
OSI	open systems interconnection
ISO	International Organization for Standardization
OEM	Original Equipment Manufacturers
OBD	On-Board Diagnostics
OBD2	On-Board Diagnostics 2
DTC	Diagnostic Trouble Codes
SA	Source Address
RA	Remote Address
SAE	Society of Automotive Engineers (Ассоциация Автомобильных Инженеров )
NRC	Negative Response Code
NVRAM	Non-Volatile Random-Access Memory
TA	Target Address
LEV	Level
PCI	Protocol Control Information
SID	Service ID
SF	Single Frame
FC	Flow Control
DID	Data IDentifier
CAN	Controller area network
VIN	Vehicle Identification Number

URLs

Ссылка	URL
UDS Knowledge Base	https://uds.readthedocs.io/en/latest/pages/knowledge_base.html
Ортодоксально Каноническая Прошивка (ОКФП)	https://habr.com/ru/articles/974152/
Diagnostic Trouble Code (DTC)	https://uds.readthedocs.io/en/latest/pages/knowledge_base/dtc.html
UDS Explained - A Simple Intro (Unified Diagnostic Services)	https://www.csselectronics.com/pages/uds-protocol-tutorial-unified-diagnostic-services
Протокол UDS	https://canhacker.ru/protocol-uds/
Обзор Протокола ISO-TP [ISO 15765-2]	https://habr.com/ru/articles/798489/
Аналитика по протоколу UDS	https://docs.google.com/spreadsheets/d/1Ekn3QwzHQcWOr1hZNXl0AYL49xHQO4UmvD1kE-T71_s/edit#gid=430258010
Обзор USB-CAN переходника USB2CANFD_V1	https://habr.com/ru/articles/944112/
Как собрать Си программу в OS Windows	https://habr.com/ru/articles/754972/
CAN-шина (Теория)	https://habr.com/ru/articles/939978/

Вопросы

--Чем протокол UDS отличается от протокола OBD-II? UDS это следующая ступень эволюции автомобильных протоколов по отношению к OBD-II.
--Какой может быть максимальный размер UDS DID? Можно ли одним UDS DIDом прочитать или прописать всю прошивку? Размер DID ограничен сверху размером одной ISO-TP транзакции. А это 4kByte. Также могут быть ограничения по оставшейся RAM памяти в микроконтроллере на котором собран данный ECU.
--Какие UDS DID значения общие для всех автопроизводителей? Наверняка же такие есть.
--Какие UDS RID значения общие для всех автопроизводителей?
--Существует ли какая-нибудь готовая клиентская Windows утилита (c GUI или консольный вариант), которая опрашивает ECU по CAN через UDS протокол? Чтобы прочитать стандартные в UDS DID параметры. Такие как VIN номер, серийный номер ECU, дату производства ECU, дату программирования ECU, название производителя ECU и прочее. Vector CANape, TOSUN TSMaster
--Можно ли по UDS читать/писать произвольные адреса физической памяти? Если да то какой cерсис позволяет это делать? Какой пакет UDS предназначен для чтения физической памяти микроконтроллера?
--Зачем в 2006 понадобился автомобильный протокол UDS, если тремя годами ранее уже в 2003 был автомобильный протокол XCP? И UDS и XCP могут читать и писать произвольную память, оба могут обновлять прошивку. Они ориентированы на разные задачи: UDS-диагностику и XCP-калибровку. XCP нужен разработчикам. UDS - техникам.
--Какими UDS пакетами (сервисами) следует обновлять прошивку? RequestTransferData, RequestDownload, RequestUpload.
--В UDS протоколе есть аналог MAC адреса?
--Какие еще прикладные протоколы могут быть в автомобиле кроме UDS? KWP2000 (Keyword Protocol 2000), ISO 15765-4 (ISO-TP), CANopen, LIN, J1939, On-Board Diagnostics (OBD2), World-Wide Harmonized OBD (WWH-OBD), CCP (Calibration Communication Protocol), XCP (Universal Measurement and Calibration Protocol).
--Зачем в UDS протоколе нужен сервис CommunicationControl?
--С каким именно периодом надо отправлять пакет TesterPresent? Раз в минуту? Раз в секунду? Раз в 30 секунд? TesterPresent отправляется с периодичностью от 1 до 10 секунд.
--В каком сервисе UDS фигурирует физический адрес модуля? Communication Control (0x28)
--Сколько бит в функциональном адресе UDS? 29 бит. Функциональный адрес это просто разновидность CAN-ID от протокола ISO-TP, где примерно в середине ExtID прописаны в константы определенные биты.
--Что такое функциональная адресация (functionally addressed) в контексте протокола UDS?
--Сколько бит в DTC (Diagnostic Trouble Code) коде UDS протокола? 24 бит.
--Что по протоколу UDS надо делать UDS клиенту, если UDS Server (ECU) не отвечает на пакеты?
--Что такое физическая адресация (physically addressed) в контексте протокола UDS?
--Сколько бит в уникальном физическом адресе UDS модуля ?
--Как можно протестировать реализацию UDS протокола?

Only registered users can participate in poll. Log in, please.

50%да5

50%нет5

10 users voted. Nobody abstained.

Only registered users can participate in poll. Log in, please.

0%да0

100%нет1

1 user voted. Nobody abstained.