Протокол UDS. Проверка протокола по состоянию на момент введения

Время на прочтение

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

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

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

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

Программный сниффер VCDS: CAN-Sniffer

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

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

Протокол UDS

Unified Diagnostic Services (UDS) – это диагностический протокол, используемый в электронных блоках управления (ЭБУ) автомобильной электроники. Протокол описан в стандарте ISO 14229-1 и является производным от стандарта ISO 14230-3 (KWP2000) и ныне устаревшего стандарта ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN)). Более подробно в википедии.

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

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

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

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

7E0 0x03 0x22 0x11 0xBD 0x55 0x55 0x55 0x55
7E8 0x05 0x62 0x11 0xBD 0x0B 0x74 0x55 0x55

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

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

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

VAG Virtual Cockpit – экран с данными от приборной панели по протоколу UDS

VW Transport Protocol 2

Volkswagen Transport Protocol 2.0 используется в качестве транспортного уровня, а данные передаются в формате KWP2000. Keyword Protocol 2000 – это протокол для бортовой диагностики автомобиля стандартизированный как ISO 14230. Прикладной уровень описан в стандарте ISO 14230-3. Более подробно в википедии.

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

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

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

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

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

VAG Virtual Cockpit – экран с данными от двигателя по протоколу VW TP 2.0

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

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

Копия диагностического сканера ELM327

Не все ELM327 одинаково полезны

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

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

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

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

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

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

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

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

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

Пару слов про точность данных. Штатная панель приборов не точно показывает скорость – завышает показания на 5-10 км/ч, стрелка охлаждающей жидкости всегда на 90 °C, хотя реальная температура может быть 80 – 110 °C, стрелка уровня топлива до середины идет медленно, хотя топлива уже меньше половины и при нуле на самом деле топливо еще есть в баке. Производитель это делает для удобства и безопасности водителя.

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

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

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

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

Unified Diagnostic Services (UDS) – это диагностический протокол связи, используемый в электронных блоках управления (ЭБУ) в автомобильной электронике, который указан в ISO 14229-1. Он основан на ISO 14230-3 ( KWP2000 ) и ныне устаревшем ISO 15765 -3 (Диагностическая связь через сеть контроллеров (DoCAN)). «Унифицированный» в этом контексте означает, что это международный стандарт, а не стандарт для конкретной компании. К настоящему времени этот протокол связи используется во всех новых ЭБУ, производимых поставщиками Tier 1 производителей оригинального оборудования (OEM), и включен в другие стандарты, такие как AUTOSAR . Электронные блоки управления в современных транспортных средствах управляют почти всеми функциями, включая электронный впрыск топлива (EFI), управление двигателем , трансмиссией, антиблокировочной тормозной системой, дверными замками, торможением, работой окон и т. Д.

Диагностические инструменты могут связываться со всеми ЭБУ, установленными в транспортном средстве, в котором включены службы UDS. В отличие от протокола шины CAN , который использует только первый и второй уровни модели OSI , UDS использует пятый и седьмой уровни модели OSI. Идентификатор службы (SID) и параметры, связанные с услугами, содержатся в полезной нагрузке кадра сообщения.

Современные автомобили имеют диагностический интерфейс для внешней диагностики, который позволяет подключить компьютер (клиент) или диагностический прибор, называемый тестером, к системе связи автомобиля. Таким образом, запросы UDS могут быть отправлены контроллерам, которые должны предоставить ответ (он может быть положительным или отрицательным). Это позволяет опрашивать ЗУ неисправностей отдельных блоков управления, обновлять их новой прошивкой, иметь низкоуровневое взаимодействие с их оборудованием (например, включать или выключать определенный выход) или использовать специальные функции ( называемые процедурами), чтобы попытаться понять окружающую среду и условия работы ЭБУ, чтобы иметь возможность диагностировать неисправное или иное нежелательное поведение.

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

Развитие систем бортовой самодиагностики и поэтапный отказ от водителя с одновременной трансформацией машины как искусства дизайнерской мысли и средства самовыражения ее владельца в простую капсулу для перемещения в пространстве приведут к полному переводу всех средств диагностики внутрь самой этой капсулы. Электронный мозг сможет сам эффективно выявлять проблему, и человек ему нужен будет только для физической замены неисправной платы. Хотя есть подозрение, что еще четвертью века позже эта процедура будет также проводиться роботом. Не верите? Сохраните этот журнал и прочтите его через 25 лет – убедитесь сами, насколько я был прав.

Автомобиль сегодня обрастает огромным количеством компьютеров, которые общаются друг с другом на разных скоростях и типах коммуникации, поскольку призваны выполнять разные задачи. Очень быстро стало понятно, что возможностей стандартных разновидностей CAN-шины недостаточно для обеспечения ширины канала передачи огромного массива данных и поддержки новых нужных функций, например, одновременной загрузки программ или их модификации в нескольких блоках управления, параллельной диагностики нескольких модулей и скоростной выдачи полученных данных во внешнюю сеть. И все это нужно сделать через стандартный 16-штырьковый разъем, поскольку отказаться от него в пользу LAN розетки промышленность пока не готова.

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

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

Представляете, какой громадный объем должна иметь программа каждого модуля в таких условиях? А чем больше и сложнее программа, тем чаще ее необходимо менять и дополнять, одновременно меняя версии программ других модулей, чтобы они находились на одном уровне версий. Тут нужна гораздо более высокая скорость с совмещением минимальных изменений принципов конструкции современного автомобиля. Так появился новый протокол бортовой диагностики FDCAN (Flexible Data CAN), разработанный BOSCH в 2011 году.

Однако FDCAN не стал революцией. Это была попытка выжать максимальную скорость коммуникации и универсальность из существующей системы с витой парой проводов. Скорость удалось повысить до 4 Мб в секунду, но возможности технологии по универсальности все равно не позволили продвинуться вперед. Да, теперь можно загружать в бортовой блок управления огромные массивы информации и тратить на это не часы, а минуты. Не будем утомлять читателя сравнением технических характеристик. Это все можно найти в свободном доступе в Интернете. Но главные задачи – подключение автомобиля к Сети и управление им через Сеть – остались не решенными.

Кроме того, возникло несколько версий протокола, документированный ISO и не документированный. Самое главное, с чем столкнулись разработчики протокола после начала его внедрения на автомобили с 2012 года, – это несовместимость диагностических приборов для CAN и FDCAN. Подключение «неподготовленного» сканера к шине FDCAN полностью выключает и «завешивает» всю систему. Те, кто столкнулся с первыми сериями нового модельного ряда Land Rover Sport в 2012 году, понимают, что я имею в виду. Однако есть ожидание того, что в ближайшее десятилетие все автопроизводители последовательно перейдут на этот протокол по мере выхода новых моделей.

Чтобы обеспечить скорость, достаточную для управления машиной в любой точке, и подключение автомобиля к Сети, было предложено новое решение, которым стал протокол коммуникации DoIP (Diagnostics Over Internet Protocol), который позволил использовать похожую архитектуру витой пары CAN-шины (которая теперь включает 4-жильный кабель для коммуникации и пятый провод для пробуждения Сети), как это было раньше с возможностью широкополосного доступа для перекачки громадного объема информации до 1500 байт(!) на скорости до 1 Гб/с!

Скорость гораздо большая, чем используется сейчас в системах инфортеймента и подушках безопасности. Точно таким образом, по такому же принципу и с помощью того же самого стандарта IEEE802.3, как сеть Ethernet в вашем офисе. И это не картинка из далекого будущего. Это уже несколько лет как наше настоящее. Например, концерн Volvo сразу внедрил эту технологию на новом модельном ряде XC90 в 2015 году.

Слово «передать» тут ключевое, поскольку автомобиль не только принимает информацию о трафике и т.п. из Интернета, но и выкладывает телематические и диагностические данные на внешние сервера или на соседний автомобиль в реальном времени в любой точке мира в любых погодных условиях. Ведь уже сегодня многие автомобили имеют точку доступа в салоне и телематику. Это может интегрированный телефон, как у Volvo, просто нужен слот для сим-карты, как у BMW и Audi, или же подключенный трекер. Еще вариант – синхронизация системы мультимедиа со смартфоном водителя через Bluetooth, что также возможно теперь через применение технологий типа Apple Auto или CarPlay и т.п. Таким образом, наличие телематики в автомобиле позволяет подключаться к нему в любое время, будь то на стоянке или в движении.

Однако как совместить высокую технологическую составляющую идеи и право человека на конфиденциальность личных данных и информации о перемещении? Как защитить канал телематики от внешнего внедрения и использования его, например, для негласной слежки или угона? Вопросов пока еще больше, чем ответов. Поэтому протокол диагностики DOIP пока еще находится в стадии документирования. Например, коммуникационные провода не имеют пока постоянного места в 16-пиновой стандартной диагностической колодке и автопроизводители размещают их пока по своему усмотрению.

Для таких требований необходимо менять три главных составляющих коммуникации:

Еще одним альтернативным шагом в области изменения бортовой диагностики стала разработка другого протокола, BroadR. Отличие от DOIP только в использовании двухпроводной версии коммуникационных кабелей. Есть и другие технические изменения, однако на дату выхода данной статьи нам не известно реальное применение этого протокола на серийном автомобиле. Однако уже завтра все может измениться.

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

Первым шагом в этом направлении стало повсеместное внедрение Объединенного диагностического протокола UDS (Unified Diagnostics Services), который поначалу был создан для того, чтобы упростить разработку программного обеспечения и приложений для бортовых блоков управления для CAN-шины. Таким образом, можно применять одни и те же программы для блоков разных моделей и даже марок и использовать единый протокол для диагностики. Вскоре он стал отдельным международным стандартом (ISO14229-1), который сегодня используют почти все автопроизводители. Яркий пример – автомобили концерна VAG, которые одни из первых перешли на UDS более пяти лет назад, и четыре марки этого концерна диагностируются по этому протоколу.

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

В области коммерческого транспорта мы также фиксируем аналогичные изменения. В настоящий момент ни один производитель коммерческого транспорта не использует ОБД-протокол для диагностики. Существует Общий (Дженерик) протокол диагностики комтранса, который включает базовую диагностику не только двигателя, но и других систем, например, кузовной электроники или шасси. Однако его использование никак не регламентировано, производители применяют для него свои разные разъемы.

Это может быть и стандартный пиновый разъем, а чаще это 6- или 9-пиновая розетка типа Deutsch. Хотя могут применяться и собственные разъемы. Поэтому для обеспечения контроля и проведения регулярных инспекций коммерческого транспорта был разработан протокол HD-OBD. Основная его идея – внедрение аналогичных OBD-совместимых функций, как для легковых автомобилей, на коммерческий транспорт, применив в стандарте 9-пиновый разъем Deutsch. Однако соглашения по срокам повсеместного внедрения этой технологи пока не достигнуто.

Мы живем в очень интересный исторический поворотный момент. То, какие сейчас будут приняты правила игры, покажет нам, как изменится мир автосервиса, и в частности диагностики, в ближайшие 10 лет. Несомненно то, что и автопроизводители, и государства движутся в сторону удаления человеческого разума из управления автомобилем. Уже доказано многочисленными тестами, что автономный автомобиль решает две главные задачи: он безопаснее машины с человеком внутри и дешевле в обслуживании. Особенно это важно для коммерческого транспорта, потому как электронному водителю не нужно отдыхать и платить зарплату.

Мы обязательно будем свидетелями того, как из объекта роскоши и материального имущества автомобиль трансформируется в простое общественное средство передвижения из точки А в точку В. И как следствие, машине не нужен будет человек для выявления и анализа неисправностей. Заложенная в электронный мозг программа сделает это и быстрее, и своевременно, а для замены компонента вместо опытного интеллектуала-диагноста потребуется квалификация не выше мастера по ремонту кассовых аппаратов. Поэтому подумайте о поиске новой специальности, пока еще не поздно. Хотя 20 лет у нас в запасе еще будет.

Труды НАМИ
Trudy NAMI

Войти

Только для подписчиков

Полный текст

Введение (постановка задачи и актуальность). Данная работа посвящена особенностям построения общей диагностической структуры, разрабатываемой для системы диагностики отечественных транспортных средств, требованиям к ней и описанию диагностических сервисов, необходимых в процессе реализации диагностической системы. Разработка имеет значимый характер и необходима для достижения новых возможностей при диагностировании отечественного автотранспорта.Цель работы состоит в разработке отечественного программного обеспечения для среды диагностики колёсных транспортных средств, соответствующего международным стандартам протокола Unified Diagnostic Services по ISO 14229 и используемого для реализации различных диагностических сервисов.Методология и методы. Описаны основные требования и спецификации шины CAN (ISO 15765) и протокола UDS (ISO 14229). Разработанная система реализована в среде программирования Python, рассмотрены алгоритм и логика работы приложения и непосредственно данные, полученные и отправленные в шину данных CAN, в процессе проведения процедуры чтения по адресу.Результаты и научная новизна. Представлены принципы выполнения работ по апробации и валидации программного обеспечения в составе электронных блоков управления, входящих в структуру электронной аппаратуры колёсного транспортного средства, необходимых для завершения разработки и внедрения программного обеспечения диагностической системы в реальные условия эксплуатации для выполнения функции диагностики неисправностей автомобилей. Описаны принципы проведения и результаты тестов программного обеспечения, данные документирования и анализ полученных результатов, сформулированы выводы по работе.Практическая значимость. В работе представлены результаты разработки и внедрения в производство диагностического программного обеспечения, отвечающего требованиям стандартов ISO 14229 и ISO 15765 и предназначенного для повышения эффективности производственного процесса в сфере обнаружения и локализации неисправностей транспортного средства при проведении работ по их техническому обслуживанию в условиях сервисного центра.

Ключевые слова

В. А. Завойкин

ГНЦ РФ ФГУП «НАМИ»
Россия

Завойкин Владислав Анатольевич,  аспирант, инженер 2-й категории сектора технологии диагностических проверок

г. Москва 125438, Российская Федерация

Список литературы

Григорьев М.В., Демидов В.В. Применение эффективной стратегии технического обслуживания и ремонта автомобилей как способ повышения их эксплуатационной надёжности // Инженерные решения. – 2020. – № 6 (16). – С. 9–14.

Козловский В.Н., Петровский С.В., Новикова А.П. Интеллектуальная информационная система диагностики состояния автономных транспортных объектов // Фундаментальные исследования. – 2016. – № 6-1. – С. 73–77.

Сергеев Д.В., Левкин И.В. Разработка распределённой информационно-советующей системы диагностики и управления автомобилем // Вестник алтайской науки. – 2010. – № 2. – С. 20–26.

ISO 15765-3:2004. Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part 3: Implementation of unified diagnostic services (UDSonCAN).

ISO/IEC 7498-1:1994. Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model.

ISO 14229-1:2020. Road vehicles – Unified diagnostic services (UDS) – Part 1: Application layer.

ISO 14229-3:2022. Road vehicles – Unified diagnostic services (UDS) – Part 3: Unified diagnostic services on CAN implementation (UDSonCAN).

Завойкин В.А. Технологические и законодательные аспекты автомобильных систем бортовой диагностики // Международный научно-исследовательский журнал. – 2022. – № 4-1 (118). – С. 56–59. – DOI: 10.23670/IRJ.2022.118.4.010. – EDN DQBBEL.

Muneeswaran A. Automotive Diagnostics Communication Protocols Analysis KWP2000, CAN, and UDS // IOSR Journal of Electronics and Communication Engineering. – 2015. – V. 10. – Ver. 1. – P. 20–31.

Wang J., Zhou Y., Li Q. Research on Fault Diagnostic System in CVT Based on UDS // Advances in Mechanical Engineering. – 2015. – V. 7. – No. 1.

Li D., Xie P., Zhou B., Wan J., Hu H., Cui L. UDS in CAN flash programming / IOP Conference Series: Materials Science and Engineering, 2019.

Рецензия

Завойкин В.А. Реализация отечественной системы расширенной диагностики колёсных транспортных средств по UDS протоколу в шине данных CAN. Труды НАМИ. 2022;(3):6-16. https://doi.org/10.51187/0135-3152-2022-3-6-16

For citation

Zavoykin V.A. Implementation of the extended diagnostics domestic system for wheeled vehicles using the UDS protocol in the CAN data bus. Trudy NAMI. 2022;(3):6-16.
(In Russ.)

https://doi.org/10.51187/0135-3152-2022-3-6-16

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

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

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

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

Фрейм транспортного протокола строится по следующей схеме:

TA – Target Address или адрес получателя фрейма SA – Source address или адрес отправителя фрейма PCI – Поле в котором кодируется количество передаваемых байт и тип фрейма.

В реализации протокола UDS работающего поверх CAN шины адрес источника не указывается в заголовке фрейма, а адресом получателя является CAN ID всего фрейма. Например в CAN сообщении 0x7E0 02 09 02 00 00 00 00 00 00 адресатом будет блок управления двигателем, адрес которого равен =0x7E0.

Типы фреймов

Single Frame SF – Однократный фрейм. Фрейм вся информация которого умещается в один CAN пакет.

First Frame FF – Первый фрейм из серии фреймов

Поле PCI занимает два байта: Нулевой и первый. 7 бит первого байта и 3 первых бита нулевого байта определяют длину сообщения – максимум 2048 байта. Четвертый бит нулевого байта равный 1 указывает на то что это First Frame.

Пример: 0x7E8 10 14 49 02 01 57 41 55 PCI = 10 14. First frame. Длина поля данных 0x14 или 20 байт. DATA: 49 02 01 57 41 55 – шесть байт Таким образом после этого фрейма должно быть отправлено еще 2 фрейма с нагрузкой по 7 байт данных на каждый, чтобы получилось суммарно 20 байт.

Consecutive Frame CF – последующий фрейм. Каждый фрейм следующий за First Frame от одного отправителя.

Поле PCI занимает нулевой байт. Старшая половина байта =0x2 и указывает на то что перед нами CF фрейм. Младшая половина указывает порядковый номер CF фрейма от 0x0 до 0xF. Пример: 0x7E8 21 5A 5A 5A 38 45 37 37 PCI=0x21. Тип фрейма – CF, номер фрейма =1

Flow control Frame – FC – фрейм управления потоком. Отправляется получателем в ответ на First Frame

Пример 1: 0x7E0 30 02 00 00 00 00 00 00 FC фрейм. Готов принять 2 CF фрейма. С минимальным временем между CF фреймами = 0 миллисекунд.

Пример 2: 0x778 30 08 05 AA AA AA AA AA FC фрейм Готово принять 8 CF фреймов С минимальной задержкой 5 миллисекунд

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

Фрейм UDS

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

Пример Запрос CAN DLC=8 DATA: 03 22 22 06 00 00 00 00 SID = 0x22 PID = 22 06 Положительный ответ CAN ID=0x77E DLC=8 DATA: 04 62 22 06 9A 00 00 00 SID+0x40 = 0x62 PID = 22 06 Response parameter =0x9A

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

1 Диагностический прибор: DLC=8 DATA: 02 09 02 00 00 00 00 00 2 Ответ автомобиля: DLC=8 DATA: 10 14 49 02 01 57 41 55 “WAU” 3 Диагностический прибор: DLC=8 DATA: 30 02 00 00 00 00 00 00 4 Ответ автомобиля: DLC=8 DATA: 21 5A 5A 5A 38 45 37 37 “ZZZ8E77” 5 Ответ автомобиля: DLC=8 DATA: 22 41 30 37 37 37 37 32 “A077772”

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

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

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

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

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

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

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

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

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

1 Диагностический прибор: DLC=8 DATA: 03 22 22 06 00 00 00 00 2 Ответ автомобиля: ID=0x77E DLC=8 DATA: 04 62 22 06 9A 00 00 00

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

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

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

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

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

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

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

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

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

200 01 C0 00 10 00 03 01

201 00 D0 00 03 40 07 01

740 A0 0F 8A FF 32 FF

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

300 A1 0F 8A FF 4A FF

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

740 10 00 02 10 89

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

300 10 00 02 50 89

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

740 11 00 02 21 01

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

300 22 00 1A 61 01 01 C8 13

300 23 05 0A 99 14 32 86 10

300 24 FF BE 25 00 00 25 00

300 15 00 25 00 00 25 00 00

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

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

740 A1 0F 8A FF 4A FF

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

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

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

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

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

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

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

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

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

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

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

How to Unlock an ECU in a vehicle?

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

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

Security Access Service seed Request Frame format

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

Security access Seed Request over CAN data frame

Security Access Service seed Response Frame format

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

Security access Seed Response over CAN data frame

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

Security Access Service send key Request Frame format

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

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

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

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

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

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

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

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

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

TA – Target Address или адрес получателя фрейма
SA – Source address или адрес отправителя фрейма
PCI – Поле в котором кодируется количество передаваемых байт и тип фрейма.

В реализации протокола UDS работающего поверх CAN шины  адрес источника не указывается в заголовке фрейма, а адресом получателя является CAN ID всего фрейма.
Например в CAN сообщении 0x7E0 02 09 02 00 00 00 00 00 00  адресатом будет блок управления двигателем, адрес которого равен =0x7E0.

Пример:  0x7E0   02 09 02 00 00 00 00 00 .
Поле PCI в этом случае = 0x02. Оно указывает на то, что фрейм будет один и его длина 2 байта: 09 02

Поле PCI занимает два байта: Нулевой и первый. 7 бит первого байта и 3 первых бита нулевого байта определяют длину сообщения – максимум 2048 байта.
Четвертый бит нулевого байта равный 1 указывает на то что это First Frame.

Пример:   0x7E8   10 14 49 02 01 57 41 55
PCI = 10 14.  First frame. Длина поля данных 0x14 или 20 байт.
DATA: 49 02 01 57 41 55  – шесть байт
Таким образом после этого фрейма должно быть отправлено еще 2 фрейма с нагрузкой по 7 байт данных на каждый, чтобы получилось суммарно 20 байт.

Consecutive Frame  CF – последующий фрейм. Каждый фрейм следующий за First Frame от одного отправителя.

Поле PCI занимает нулевой байт. Старшая половина байта =0x2 и указывает на то что перед нами CF фрейм. Младшая половина указывает порядковый номер CF фрейма от 0x0 до 0xF.
Пример:  0x7E8   21 5A 5A 5A 38 45  37 37
PCI=0x21. Тип фрейма – CF, номер фрейма =1

Пример 1: 0x7E0   30 02 00 00 00 00 00 00
FC фрейм.
Готов принять 2 CF фрейма.
С минимальным временем между CF фреймами = 0 миллисекунд.

Пример 2: 0x778   30 08 05 AA AA AA AA AA
FC фрейм
Готово принять 8 CF фреймов
С минимальной задержкой 5 миллисекунд

Обмен с использованием  Single Frame со стороны отправителя и получателя будет выглядеть как простой обмен пакетами.  Обмен с использованием FF, CF, FC фреймов будет выглядеть сложнее, этот процесс удобнее изобразить на схеме ниже. Обратите внимание на то, что после серии Consecutive Frame -ов может следовать Flow control фрейм если передаваемые данные не умещаются в 16 блоков. А может и не следовать, это уже зависит от конкретной программной реализации протокола. Очень часто разработчики программного обеспечения автомобильных блоков управления отходят от формального описания протокола.

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

Пример
Запрос
CAN ID=0x714  DLC=8  DATA: 03 22 22 06 00 00 00 00
SID = 0x22
PID = 22 06
Положительный ответ
CAN ID=0x77E  DLC=8  DATA:  04 62 22 06 9A 00 00 00
SID+0x40 = 0x62
PID = 22 06
Response parameter =0x9A

1 Диагностический прибор: ID=0x7E0  DLC=8  DATA: 02 09 02 00 00 00 00 00
2 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  10 14 49 02 01 57 41 55            “WAU”
3 Диагностический прибор: ID=0x7E0  DLC=8  DATA: 30 02 00 00 00 00 00 00
4 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  21 5A 5A 5A 38 45  37 37         “ZZZ8E77”
5 Ответ автомобиля:              ID=0x7E8  DLC=8  DATA:  22 41 30 37 37 37 37  32          “A077772”

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

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

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

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

1 Диагностический прибор: ID=0x714  DLC=8  DATA: 03 22 22 06 00 00 00 00
2 Ответ автомобиля:               ID=0x77E  DLC=8  DATA:  04 62 22 06 9A 00 00 00

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

Если бы мы отправили команду на закрытие замка без команды открытия сессии, то ответ был бы такой: ID=0x765  DLC=8  DATA:  03 7F 30 01 00 00 00 00 , где 7F – говорит о том, что команда не может быть выполнена.

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

UDS Диагностика вход

Если вы слушаете это, вы можете сделать это с осторожностью. Адвокат науку и искать правду от фактов.

275 человек согласны с статьей

Написано впереди: UDS является практичным и сложным. Многие услуги должны испытать его один раз, чтобы понять.

Ноль, меморандум по диагностике UDS

Введение

UDS (Unified Diagnostic Services, Unified Diagnostic Service) Диагностическое согласие – это протокол диагностической связи в автомобильной среде электронного ECU.ISO 14229Нормативные документы. Он получен из протокола ISO 14230-3 (KWP2000) и ISO 15765-3. Слово «единство» означает, что оно является «международным», а не «специфическим» компании. До сих пор этот протокол связи использовался на новом ECU, сделанном почти всеми поставщиками OEM -уровня. Эти ECU контролируют различные функции транспортных средств, включая электронные системы впрыска топлива (EFI), системы управления двигателями, коробки передач, анти -мелки

Диагностические инструменты подключены ко всем единицам управления в автомобиле, и эти контрольные блоки включены службами UDS. В отличие от протоколов первого и второго уровня, которые используют только модель OSI, служба UDS использует пятый и седьмой уровень модели OSI (уровень сеанса и уровень приложения).Идентификатор обслуживания (SID)Параметры, связанные с службой, включены в 8 байтов данных в кадре данных CAN. Эти рамки данных выпускаются из диагностического инструмента.

В настоящее время новые автомобили на рынке имеют диагностические интерфейсы для внешней диагностики, что позволяет нам подключаться к системе автобусы автомобиля с помощью компьютера или диагностического инструмента (известного как тестер). Следовательно, сообщение, определенное в UDS, может быть отправлено контроллеру, который поддерживает услуги UDS (называется ECU в отрасли). Так что мы можемПосетите память разлома каждого блока управленияИли использоватьНовая прошивка обновления ECU программыСущность Кроме того, UDS также используется для написания некоторой информации (такой как код VIN) в различные части автомобиля во время обнаружения в автономном режиме. Эти функции также являются основными характеристиками UDS.

Используйте компьютер для диагностики транспортного средства, и диагностическая линия вставлена ​​в интерфейс OBD

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

В дополнение к шине CAN, UDS также может быть реализован на различной автомобильной шине (например, LIN, Flexray, Internet и K-Line).

Как показано на рисунке ниже, ISO 14229 заключается в том, что протокол UDS определяет только уровень приложения и слой сеанса. Здесь есть вопрос,UDS ссылается на ISO 14229-1?Пересечение Это утверждение неверно. UDS содержит 7 подпротоколов под ISO 14229, из которых ISO 14229-2 все еще остается сеансом, поэтомуUDS только включает в себя заявление о высказывании слоя также неправильно。

Согласно объяснению, мы используем только для описания UDS в этой статье. Для CAN физический уровень и уровень канала передачи данных следуют за протоколом ISO 11898; с точки зрения сетевого уровня, классическая банка имеет только 8 байтов поля данных и уровня приложения для обработки многократных данных. Чтобы решить эту проблему, мы используем 8 -байный набор данных, чтобы освободить один или два байта, чтобы отразить управляющую информацию о сетевом уровне.

Если вы хотите изучить знание уровня сети UDS в глубине, пожалуйста, перемещайте:

Flower of Mind: интерпретация уровня сети UDS/TP-слой (ISO 15765-2) Интерпретация Zhuanlan.Zhihu.com

Диагностическое содержание, связанное с выбросами, то есть ISO 15031-5 в основном направлено на протокол OBD, для обязательного согласия для регулирующих топливных транспортных средств, электромобили не должны быть удовлетворены. Топливные транспортные средства обычно соответствуют протоколам UDS и протоколу OBD. Эти два протокола не конфликтуют. Считают ли маленькие друзья, что самый маленький идентификатор обслуживания (SID) протокола UDS составляет 0x10, поскольку в протоколе OBD предусмотрено обслуживание менее 0х10.

Прежде чем изучать UDS, я надеюсь, что у вас есть предварительное понимание базовых знаний о банке, узнайте основной композицию кадры банки и познакомитесь, по крайней мере, с одним банком. С точки зрения соглашений, содержание ISO 15765-2 и ISO 14229-1 должно быть сосредоточено на PPT, документах и ​​оригинальных английских протоколах.После этого вы можете пересадить стек протоколов с открытым исходным кодом UDS на GIT на вашу знакомую встроенную платформу для отправки и получения данных;Существует грубое понимание UDS. Помните, что интеграция знаний и действий важна.

От ISO 14229-1-2013

Выдержка из Hengrun Technology Public Information