Uds vag что это
Диагностика на пороге больших изменений. Часть 3. Новые протоколы бортовой коммуникации
В предыдущих номерах журнала мы проанализировали то, как будут меняться работа и навыки диагноста в самом ближайшем будущем, что обычные сегодня приборы для диагностики канут в Лету, как это когда-то произошло с пейджерами, кассетными магнитофонами, печатными машинками и перьевыми ручками. Повышение скорости коммуникации, новые задачи, связанные с удаленным доступом во все системы автомобиля, уже сейчас создают новые реалии работы, более скоростные, мобильные, простые и низкозатратные, чем сейчас. Более того, сама профессия диагноста станет архаичной, пополнив список вымерших специальностей вместе с бурлаками, фонарщиками и трубочистами. Мы предполагаем, что это произойдет еще не в будущем десятилетии, но лет через 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 году.
Внедрение интернет-принципа позволило не только легко синхронизировать через внутренние шлюзы разные типы локальных сетей, например Flexray, MOST и LIN, но сделать автомобиль точкой доступа, которая имеет свой собственный IP-адрес. Таким образом, нам теперь не будет нужен компьютер-сканер для того, чтобы извлечь и обработать информацию из бортового блока управления, а потом передать ее через Интернет на сервер, как это делается сейчас многими автопроизводителями. Цель в другом. Теперь автомобиль сам сможет подключиться к Сети и передать данные по тому адресу, по которому это будет нужно.
Слово «передать» тут ключевое, поскольку автомобиль не только принимает информацию о трафике и т.п. из Интернета, но и выкладывает телематические и диагностические данные на внешние сервера или на соседний автомобиль в реальном времени в любой точке мира в любых погодных условиях. Ведь уже сегодня многие автомобили имеют точку доступа в салоне и телематику. Это может интегрированный телефон, как у 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 лет у нас в запасе еще будет.
Протокол UDS
Протокол UDS – это “язык” на котором общается диагностическое оборудование. Протокол UDS может работать на различных физических шинах: K-Line, CAN, Ethernet, FlexRay. В этой статье мы рассмотрим механизм работы протокола UDS на шине CAN, как самый распространенный вариант в настоящее время. Рассматривать вопрос будем с практической точки зрения для быстроты восприятия материала. Подробно протокол описан в стандарте ISO-15765.
По протоколу UDS возможно не только считать\стереть коды ошибок – DTC, но и запросить текущие параметры датчиков и блоков управления (ECU), а так же давать команды исполнительным механизмам (например открыть\закрыть центральный замок).
Кроме того с помощью этого протокола осуществляется прошивка блоков управления.
В своей базе протокол UDS строится на транспортном протоколе TP. Транспортном не в смысле его применения на транспорте, а в том смысле что протокол предназначен для транспортировки данных по некоторому каналу передачи.
Описание транспортного протокола TP
Фрейм транспортного протокола строится по следующей схеме: 
TA – Target Address или адрес получателя фрейма
SA – Source address или адрес отправителя фрейма
PCI – Поле в котором кодируется количество передаваемых байт и тип фрейма.
В реализации протокола UDS работающего поверх CAN шины адрес источника не указывается в заголовке фрейма, а адресом получателя является CAN ID всего фрейма.
Например в CAN сообщении 0x7E0 02 09 02 00 00 00 00 00 00 адресатом будет блок управления двигателем, адрес которого равен =0x7E0.
Типы фреймов
Single Frame SF – Однократный фрейм. Фрейм вся информация которого умещается в один CAN пакет. 
First Frame FF – Первый фрейм из серии фреймов 
Поле PCI занимает два байта: Нулевой и первый. 7 бит первого байта и 3 первых бита нулевого байта определяют длину сообщения – максимум 2048 байта.
Четвертый бит нулевого байта равный 1 указывает на то что это First Frame.
Пример: 0x7E8 10 14 49 02 01 57 41 55
PCI = 10 14. First frame. Длина поля данных 0x14 или 20 байт.
DATA: 49 02 01 57 41 55 – шесть байт
Таким образом после этого фрейма должно быть отправлено еще 2 фрейма с нагрузкой по 7 байт данных на каждый, чтобы получилось суммарно 20 байт.
Consecutive Frame CF – последующий фрейм. Каждый фрейм следующий за First Frame от одного отправителя. 
Поле PCI занимает нулевой байт. Старшая половина байта =0x2 и указывает на то что перед нами CF фрейм. Младшая половина указывает порядковый номер CF фрейма от 0x0 до 0xF.
Пример: 0x7E8 21 5A 5A 5A 38 45 37 37
PCI=0x21. Тип фрейма – CF, номер фрейма =1
Flow control Frame – FC – фрейм управления потоком. Отправляется получателем в ответ на First Frame 
FC фрейм служит для управления потоком в случае если используется поток фреймов First Frame-Consicutive Frames.
PCI занимает три байта: Нулевой, первый, второй.
Заголовок 0x3 в заголовке поля PCI указывает что это FC фрейм.
Flow Status говорит отправителю First Frame о статусе получателя 00- Готов к приему CF фреймов, 01- Жди, 02 – Переполнение.
Block Size определяет количество СF фреймов которые готов принять получателю. В некоторых может быть равно нулю и протокол все равно будет работать.
Minimum Separation Time в миллисекундах, задает минимальное время между передаваемыми CF фреймов.
Пример 1: 0x7E0 30 02 00 00 00 00 00 00
FC фрейм.
Готов принять 2 CF фрейма.
С минимальным временем между CF фреймами = 0 миллисекунд.
Пример 2: 0x778 30 08 05 AA AA AA AA AA
FC фрейм
Готово принять 8 CF фреймов
С минимальной задержкой 5 миллисекунд
Такой же пример на конкретных данных.
ID Отправителя = 0x7CE
ID Получателя = 0x7C6
Отправитель передает массив данных размером 0xB5 или 181 байт получателю. На изображении представлен НЕ весь массив! 
Фрейм UDS
Фреймы диагностического протокола UDS строятся поверх транспортных фреймов и выглядят так: 
Где – SID – идентификатор сервиса. (запрос DTC, запрос текущих параметров, команды…)
PID\LEV – Номер запрашиваемого параметра или номер вызываемой функции.
Пример
Запрос
CAN DLC=8 DATA: 03 22 22 06 00 00 00 00
SID = 0x22
PID = 22 06
Положительный ответ
CAN ID=0x77E DLC=8 DATA: 04 62 22 06 9A 00 00 00
SID+0x40 = 0x62
PID = 22 06
Response parameter =0x9A
Подробный разбор конкретных примеров использования протокола UDS
Пример 1. Запрос VIN номера
1 Диагностический прибор: DLC=8 DATA: 02 09 02 00 00 00 00 00
2 Ответ автомобиля: DLC=8 DATA: 10 14 49 02 01 57 41 55 “WAU”
3 Диагностический прибор: DLC=8 DATA: 30 02 00 00 00 00 00 00
4 Ответ автомобиля: DLC=8 DATA: 21 5A 5A 5A 38 45 37 37 “ZZZ8E77”
5 Ответ автомобиля: DLC=8 DATA: 22 41 30 37 37 37 37 32 “A077772”
Запрос от диагностического прибора ID=0x7E0 DLC=8 DATA: 02 09 02 00 00 00 00 00
Ответ ECU: DLC=8 DATA: 10 14 49 02 01 57 41 55
Запрос от диагностического прибора ID=0x7E0 DLC=8 DATA: 30 02 00 00 00 00 00 00
Байт 0: 0x30 – Flow control. Команда блоку управления выдать все байты данных запрашиваемого параметра блоком из двух CF фреймов с минимальной задержкой 0 миллисекунд.
Ответ ECU: DLC=8 DATA: 21 5A 5A 5A 38 45 37 37
Ответ ECU: DLC=8 DATA: 22 30 37 37 37 37 37 32
Затем блок управления отдает все байты данных запрашиваемого параметрах, которые упакованы в необходимое число CF фреймов. В описываемом примере таких фрейма два.
Байт 0: 0x21, 0x22 – номера CF фреймов в серии.
Байты 1…7: Байты данных запрашиваемого параметра.
Пример 2. Запрос уровня топлива
Рассмотрим более простой пример – запрос уровня топлива по протоколу UDS у панели приборов автомобиля VW Touareg NF.
1 Диагностический прибор: DLC=8 DATA: 03 22 22 06 00 00 00 00
2 Ответ автомобиля: ID=0x77E DLC=8 DATA: 04 62 22 06 9A 00 00 00
Запрос от диагностического прибора ID=0x714 DLC=8 DATA: 03 22 22 02 00 00 00 00
Ответ ECU: DLC=8 DATA: 04 62 22 06 9A 00 00 00
Пример 3. Команда активации исполнительного механизма
В качестве примера команды активации исполнительного механизма рассмотрим управление приводом центрального замка автомобилей Renault.
В этом случае мы видим использование уже двух команд: Открытие сессии и команда на закрытие замка. Очень часто команды на управление исполнительными механизмами требуют открытия сессии расширенного диагностического режима.
Таблица сервисов доступных в протоколе UDS
В таблице представлены сервисы которые заложены в протокол. Не все блоки управления поддерживают полный набор сервисов.
Хакаем CAN шину авто. Мобильное приложение вместо панели приборов
Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.
По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.
Программный сниффер VCDS
Чтобы узнать по какому протоколу общаются электронные блоки я использовал специальную версию VCDS с программным сниффером в комплекте. В этот раз никаких железных снифферов на Arduino или RPi не пришлось изобретать. С помощью CAN-Sniffer можно подсмотреть общение между VCDS и автомобилем, чтобы затем телефон мог прикинуться диагностической утилитой и отправлять те же самые запросы.
Я собрал некоторую статистику по использованию диагностических протоколов на разных моделях автомобилей:
Протокол UDS
Диагностические данные от двигателя по протоколу UDS (Skoda Octavia A7)
В моей машине (Skoda Octavia A5) приборка использует UDS протокол, это дало мне легкий старт разработки, т.к. данные были в простом формате Single Frame SF (фрейм, вся информация которого умещается в один CAN пакет) и большинство значений легко поддавались расшифровке. Volkswagen не дает документацию на формат значений, поэтому формулу расшифровки для каждого датчика приходилось подбирать методом логического мышления. Про UDS протокол очень хорошо и с подробным разбором фреймов написано на canhacker.ru.
Разбор UDS пакета в формате Single Frame
Пример запроса и ответа температуры моторного масла:
Запрос температуры моторного масла:
Ответ температуры моторного масла:
Первая версия мобильного приложения VAG Virtual Cockpit умела подключаться только к приборной панели по UDS.
VW Transport Protocol 2.0
Т.к. KWP2000 использует сообщения переменной длины, а CAN шина позволяет передавать сообщения не больше 8 байт, то VW TP 2.0 разбивает длинное сообщение KWP2000 на части при отправке по CAN шине и собирает заново при получении.
Диагностические данные от двигателя по протоколу KWP2000 (Skoda Octavia A5)
ЭБУ двигателя моей машины использует протокол VW TP 2.0, поэтому мне пришлось изучить его. Видимо Volkswagen разрабатывала транспортный протокол не только для работы по надежной CAN шине, но и для менее надежных линий связи, иначе нет объяснения для чего требуется такая избыточная проверка целостности данных. Главным источником информации по VW TP 2.0 является сайт https://jazdw.net/tp20.
Разбор протокола VW TP 2.0 на примере подключения к первой группе двигателя:
200 01 C0 00 10 00 03 01
201 00 D0 00 03 40 07 01
740 A0 0F 8A FF 32 FF
Настраиваем ЭБУ на отправку сразу 16 пакетов и выставляем временные параметры
300 A1 0F 8A FF 4A FF
Получили положительный ответ
740 10 00 02 10 89
Получили первый ACK
300 10 00 02 50 89
Мы отправили первый ACK, что получили ответ
740 11 00 02 21 01
Получили второй ACK
300 22 00 1A 61 01 01 C8 13
300 23 05 0A 99 14 32 86 10
300 24 FF BE 25 00 00 25 00
300 15 00 25 00 00 25 00 00
Отправляем ACK. Прибывляем к нашему предыдущему ACK количество полученных пакетов 0xB1 + 0x4 = 0xB5
Запрос KeepAlive, что мы еще на связи
740 A1 0F 8A FF 4A FF
Мы разрываем связь
ЭБУ в ответ тоже разрывает связь
Во второй версии мобильного приложения VAG Virtual Cockpit появилась возможность диагностировать двигатель и трансмиссию по протоколу VW TP 2.0.
Диагностический адаптер ELM327
Для меня некоторое время было вопросом, как получить данные из CAN шины и передать на телефон. Можно было бы разработать собственный шлюз с Wi-Fi или Bluetooth, как это делают производители сигнализаций, например Starline. Но изучив документацию на популярный автомобильный сканер ELM327 понял, что его можно настроить с помощью AT команд на доступ к CAN шине.
Копия диагностического сканера ELM327 Не все ELM327 одинаково полезны
Оригинальный ELM327 от компании elmelectronics стоит порядка 50$, в России я таких не встречал в продаже. У нас продаются только китайские копии/подделки, разного качества и цены 10-30$. Бывают полноценные копии, которые поддерживают все протоколы, а бывают и те которые умеют отвечать только на несколько команд, остальные игнорируют, такие адаптеры не имеют доступ к CAN шине. Я например пользуюсь копией Viecar BLE 4.0, который поддерживает 100% всех функций оригинала.
Для работы с протоколом UDS через ELM327 нужно указать адреса назначения, источника и разрешить длинные 8 байтные сообщения, по умолчанию пропускается максимум 7 байт.
Последовательность ELM327 AT команд для работы с UDS по CAN шине:
Для работы с протоколом KWP2000 через ELM327 нужно только указать адреса назначения и источника.
Последовательность ELM327 AT команд для работы с VW TP 2.0 по CAN шине:
Мобильное приложение VAG Virtual Cockpit
Для разработки мобильного приложения подключаемого к автомобилю требовалось:
Сниффером собрать трафик от диагностической утилиты VCDS
Изучить работу протоколов UDS, VW TP 2.0, KWP2000
Настроить диагностический сканер ELM327 на работу с UDS и VW TP 2.0
Изучить новый для меня язык программирования Swift
Мобильное приложение VAG Virtual Cockpit для iOS
В итоге получилось приложение, которое сочетает в себе функции отображения точных данных панели приборов и диагностика основных параметров двигателя и трансмиссии.
На данный момент приложение показывает следующие параметры:
Приборная панель
Двигатель
Трансмиссия (температура)
1) Какая дверь открыта
2) Скорость
3) Обороты
4) Температура масла
5) Температура ОЖ
6) Топливо в баке в л.
7) Запас хода в км.
8) Средний расход
9) Время в машине
10) Пробег
11) Температура за бортом
1) Обороты
2) Массовый расход воздуха
3) Температура забора воздуха
4) Температура выхлопа (рассчитанная)
5) Критический уровень масла
6) Уровень масла
7) Наддув турбины (реальный)
8) Наддув турбины (ожидаемый)
9) Пропуски зажигания в цилиндрах
10) Углы откатов зажигания в цилиндрах
1) ATF AISIN (G93)
2) DSG6 (G93)
3) Блок управления DSG6 (G510)
4) Масло диска сцепления DSG6 (G509)
5) Мехатроник DSG7 (G510)
6) Процессор DSG7
7) Диск сцепления DSG7
Я стремлюсь чтобы приложение поддерживало как можно больше моделей автомобилей. Пока что поддерживаются производители: Volkswagen, Skoda, Seat, Audi. На разных комплектациях могут отображаться не все параметры, но это поправимо.
Сейчас я провожу тестирование версии 3.0. Приложение доступно только на iOS, после релиза 3.0 перейду к разработке версии для Android.
Если интересно потестировать и есть желание принять участие в проекте, то установить приложение можно по ссылке. Также я веду бортжурнал на drive2.ru, где делюсь полезной информацией и новостями о VAG Virtual Cockpit.