Чтение и Запись Параметров по UDS

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

Как многие уже знают UDS протокол позволяет читать и писать реальные физические параметры автомобильного агрегата. Такие как, например, время с момента пуска прошивки, обороты всяческих валов, VIN номер, одометр и прочее.

UDS протокол реализует динамическую типизацию. То есть вся информация про типы данных поступает во время исполнения программы пакетом ReadScalingDataByIdentifier.
Сам микроконтроллер рассказывает LapTop-у какие переменные он поддерживает внутри себя.

Стоит отметить, что параметры, как ни крути, а должны сохранять свои значения между пересбросами питания. Поэтому они должны где-то надёжно храниться . Для полноценного портирования функционала работы с UDS параметрами Ваша прошивка должна поддерживать NVRAM. 

Определение

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

Массив – непрерывная последовательность байт. Массив обладает размером.Структура – набор переменных разного типа данныхПакет – бинарная структура в массивеUDS cервис – это просто входной пакет, на который спецификацией определён ответный пакет.

Идентификатор – имя переменной выражаемое в виде натурального числа

Данные – массив hex байтов с указанной длинной

File это именованный бинарный массив байтов в памяти. В качества памяти может выступать RAM, ROM (Flash), FRAM, EEPROM, SD карты. Что значит именованный? Это значит, что к этим данным можно обращаться по значению. Пусть это будет натуральное 16-битное число. Так проще. Так как это массив, то рядом с данными также надо хранить и длину этого массива. 

Нимбл (Nibble) – четырехбитное число (пол байта), которое может принимать значения от нуля до 15.

NVRAM – энергонезависимая память (NV) с произвольным доступом (RAM). По сути Key Val-Map(ка). В ней могут храниться любые бинарные данные, ассоциированные со своим ID числом. В NVRAM хранятся файлы.

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

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

Клиент – LapTop (тестер). Тестировочное оборудование с программой UDS-клиента внутри. Мастер UDS сети.

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

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

Big-Endian (Motorola byte order/сетевой порядок байт)- порядок байт от старшего к младшему.

Переменные в протоколе UDS (такие как DID) передаются в формате Big-Endian.

Весь механизм работы с параметрами описывается вот этими UDS пакетами.

b- Для использования защищенных идентификаторов данных требуется открыть доступ пакетом SecurityAccess, а следовательно, и нестандартную диагностическую сессию. То есть нельзя просто взять и начать читать некоторые параметры. Надо сперва перевести ECU в режим Prog (сессия Prog) и ввести своеобразный пароль (key).

Список стандартных значений DID

Какие вообще существуют значения для DID номеров? Стандартные номера DID можно посмотреть в таблице Table C.1 — DID data-parameter definitions

Фаза 0: Переключиться на non-default Session

Для работы с параметрами надо перейти с сессию в которой больше прав. Например в non-default сессию. Это необходимо чтобы ввести пароль.

Отправлять пакеты DiagnosticSessionControl можно из любой сессии.

Фаза 1 : Набрать пароль.

Затем протокол UDS ограничивает доступ к сервисам не только сессиями, но и своеобразными паролями. Иначе прилетит негативный код securityAccessDenied. Для ввода пароля существует отдельные пакеты группы SecurityAccess (0x27).

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

1.619,133,D,[UdsServerLL],LapTop->ECU,2701
1.624,134,D,[UdsServerLL],ECU->LapTop:6701FFFE4A27
1.674,135,N,[UdsClient],Seed:0xFFFE4A27
1.724,136,N,[UdsClient],UDS_CLIENT1,SecurityAccess,SendKey:0xFEEDFACE
1.726,137,D,[UdsServerLL],LapTop->ECU,2702FEEDFACE
1.728,138,D,[UdsServerLL],ECU->LapTop:6702
1.774,139,I,[UdsClient],UnLocked!

Сервис SecurityAccess позволяет клиенту разблокировать функции/сервисы с ограниченным доступом. Цель данного пакета — предоставить средства доступа к данным и/или диагностическим услугам, доступ к которым ограничен по соображениям безопасности или защиты. Диагностические услуги, включающие загрузку/выгрузку программ или данных на сервер и чтение определенных ячеек памяти с сервера, относятся к ситуациям, когда может потребоваться доступ с целью обеспечения безопасности. Концепция безопасности использует связь между начальным значением и ключом.

Последовательность разблокировки:

1–Клиент запрашивает у ECU начальное значение (seed). По сути это номер пароля.
2–ECU отвечает положительным ответом, содержащим случайно сгенерированное значение начального значения (seed).
3–И клиент, и ECU вычисляют значение ключа на основе этого начального значения (используя секретный алгоритм).
4–Клиент отправляет вычисленный ключ на ECU .
5–ECU проверяет подлинность клиента, сравнивая полученный ключ со своим собственным вычисленным ключом. Если они совпадают, клиенту предоставляется доступ к защищенной функциональности соответствующего уровня безопасности.

Значение параметра подфункции ‘requestSeed’ всегда должно быть нечетным числом, а соответствующее значение параметра подфункции ‘sendKey’ для того же уровня безопасности должно равняться значению параметра подфункции ‘requestSeed’ плюс один.

В любой момент времени может быть активен только один уровень безопасности. Например, если активен уровень безопасности, связанный с requestSeed 0x03, и запрос тестировщика успешно разблокирует уровень безопасности, связанный с requestSeed 0x01, то в этот момент будет разблокирована только защищенная функциональность, поддерживаемая уровнем безопасности, связанным с requestSeed 0x01. Любая дополнительная защищенная функциональность, которая ранее была разблокирована уровнем безопасности, связанным с requestSeed 0x03, больше не будет активна. Нумерация уровней безопасности является произвольной и не подразумевает какой-либо связи между уровнями.

Клиент должен запросить у ECU «разблокировку», отправив сообщение SecurityAccess «requestSeed». ECU должен ответить, отправив «начальное значение» с помощью сообщения SecurityAccess «requestSeed» (положительный ответ). Затем клиент должен ответить, отправив ECU номер «ключа» с помощью соответствующего сообщения SecurityAccess «sendKey». ECU должен сравнить этот «ключ» с одним из тех, что хранятся/вычисляются внутри системы. Если два числа совпадают, ECU должен разрешить («разблокировать») доступ клиента к определенным службам/данным и указать это с помощью сообщения SecurityAccess «sendKey» (положительный ответ).

Если присланный ключ и вычисленный локально ключ не совпадают, это считается ложной попыткой доступа. Недействительный ключ требует от клиента начать все сначала с помощью сообщения SecurityAccess «requestSeed» (см. Приложение I для получения дополнительной информации о деталях обработки доступа к безопасности).

Если ECU поддерживает безопасность, но запрошенный уровень безопасности уже разблокирован при получении сообщения SecurityAccess «requestSeed», этот ECU должен ответить положительным сообщением SecurityAccess «requestSeed» со значением начального числа, равным нулю (0). ECU никогда не должен отправлять начальное число, равное нулю, для заданного уровня безопасности, который в данный момент заблокирован. Клиент должен использовать этот метод для определения того, заблокирован ли ECU для определенного уровня безопасности, проверяя наличие ненулевого начального числа.

Для корректного ответа на сообщение «requestSeed» службы SecurityAccess от клиента после включения/перезагрузки ECU и после определенного количества ложных попыток доступа (см. подробное описание ниже) может потребоваться задержка, специфичная для производителя транспортного средства.

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

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

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

ReadScalingDataByIdentifier (SID=0x24)

Прочитать сырые данные по номеру DID это еще не значит понять смысл прочитанных данных. У каждого параметра есть целая куча метаданных. Это

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

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

В случае получения пакета запроса ReadScalingDataByIdentifier микроконтроллер должен получить доступ к информации про переменную и передать значения в положительном ответе.

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

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

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

ReadDataByPeriodicIdentifier (0x2A) 

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

Сразу стоит отметить, что не всякий DID можно заставить испускаться самопроизвольно, а только те, что начинаются с 0xF2xx. Это как раз подмножество PDIDов. Как видите их всего 256.

Сообщение запроса клиента содержит одно или несколько однобайтовых значений periodicDataIdentifier (младший байт от DID), которые идентифицируют записи данных, поддерживаемые сервером. 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 содержит только идентификатор службы (т.е. 0x6A).

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

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

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

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

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

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

Итоги

Удалось научиться читать писать и интерпретировать параметры по UDS.

NVRAM в протоколе UDS нужна не только для регистрирования упавших модульных тестов в пакетах про DTC, но также банально для пакетов чтения и записи параметров по DID (WriteDataByIdentifier ). 

Например прописать в VIN номер, дату сборки прошивки, дату калибровки, дату монтирования ECU, серийный номер , значение тахографа, название производителя ECU и прочих VehicleManufacturerSpecific параметров (CRC32 прошивки, размер прошивки и прочее) 

Словарь

URLs

Вопросы

–Какие UDS DID значения общие для всех автопроизводителей? Наверняка же такие есть. Какие метаданные у этих стандартных DID значений?

–Какой может быть максимальный размер для UDS DID? Можно ли, например, одним UDS DIDом взять и прочитать (или прописать) всю прошивку?

–Есть ли в UDS протоколе сервис, который возвращает массив известных DID и их количество? А то ведь проверять DID отправляя каждый раз запрос ReadDataByIdentifier SID=0x22 и проверять все 2**16=65536 возможных ответов даже с таймаутом 100ms – это как-то уж очень долго (110 мин).