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

Максимально его возможности, что мне удалось вычислить - на 500 Кбитной шине 20 сообщений с периодичностью 3 мс каждое. А в реале на том же Кобальте - около 40 сообщений, из них 20 - с периодичностью 250 мкс!..
Тут бы, конечно, во-первых, - делать программный коннект не на уровне библиотек (как у меня сейчас), а на уровень ниже - на уровне драйверов контроллера, а во-вторых, само ПО хорошо чтобы крутилось не под виндой, а в какой-нибудь ОС реального времени.. (мечтать не вредно)

Alexo, на сколько я понял, Вы сделали программный фильтр-репитер?


Не боитесь, что устроите флуд на шине? Но не это главное, На сколько я понял, вы хотите подменять сигналы какого либо из блоков. Так?
Возможно, проще будет данные блок на время перевести в stand-by, если такое имеется (тут я просто мечтаю :), а возможно такое реализовано уже. не обладаю информацией на данную тему.)
Или, Вы хотите брать сигналы с неисправного блока, пропускать их через шлюз и отдавать ответ исправного блока?

Если RTOS - посмотрите в сторону uC/OS II или ChibiOS. Последняя - бесплатная. Можно запустить на STM каком-нибудь с ARM архитектурой.

Шина вроде линейная и связывает все блоки. Или я не так Вас понял? Или межблочные связи - это, например, общение двигателя с ABS/ESP?

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

Ну да, но как я понял, если она не выведена на диагн. разъем, то и диагностики в ней не предусмотрено?.. А я пока изучаю именно это.

Alexo, почему шина не выведена на разъем - сказать сложно. Возможно, VAG по каким-то причинам не захотел выводить CAN. На сколько я понял в фольце только моторный CAN. Так?

У меня около 5 блоков управления в легковой. Но все пока не нашел.

Хотел спросить про имплементацию репитера.
Что используется в качестве CAN-контроллера SJA1000 или MCP2510/11?

В целом - задумка отличная.

Использую Marathon - 2-канальный CAN-USB адаптер, контроллер там SJA1000. Вообще - это наш отечественный клон америкосского IXXAAT - кстати, там тоже SJA1000 (контроллер, разработке которого 20 лет "в обед")
Но стоимость нашего на порядок дешевле (6,5 килоруб. vs 60 тыс)
А про задумку - это да, я рассказал только о небольшой толике возможностей - довести бы до ума.. Пока перейду на уровень драйверов - посмотрим насколько улучшится динамика...

----------

Видимо, просто в те года (2004) был переход на кан, по-видимому, диагностику тогда ЕЩЁ не вывели, оставалась какое-то время клайновская.
А кан там не только моторный - и комфорт и все остальные блоки тоже по-моему, кан..

У меня CAN выведен на OBD-II и на диагностический разъем под капотом. Но это 2010 год. Возможно, на VW есть еще один разъем для диагностики.
A схема VW у Вас есть? С ней как раз прояснится как связаны блоки между собой.

По поводу адаптера - неплохо. Возьму на заметку.

[OFFTOPIC]
Почему спрашивал про контроллеры - параллельно вожусь с концепцией умного дома. Выбираю контроллер. Возможно найду платы с датчиками и контроллером, либо просто с контроллером.
[/OFFTOPIC]

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

----------

Ну, тут, вроде, попроще должно быть - скорости-то не должны быть большими? Сильно динамичных процессов ведь нет как в транспорте.
Я в плане используемых контроллеров - в принципе, достаточно недорогих?..

В читаемых доках не все описывается.

Базовое это на адрес скажем 7E0 ответ +8 , ну это относится для последних адресов а вот для первых 700, 701... от тут уже не стыковка , одни производители используют +8 а некоторые +40hex и +60hex.

Существуют команды которые не в какой стандарт не входят.

Опыт использования КАН есть в разных проектах в том числе полный эмулятор разных автомобилей и разных брендов.

..
 

Вот это интересно!.. Тогда куча вопросов.
Эмуляторы чего конкретно, - всех блоков?
Я не для "плагиата" спрашиваю, а чтобы понять для себя - насколько это все можно сэмулировать и какая возможная польза от этого?..

Для изучения и понятия о происходящих процесов.

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

Не отрицаю. Производители могут навернуть массу всего. Я же пока отталкиваюсь от стандартов.

Это уже интересно. Встречный вопрос: на broadcast адрес 0x7FF отвечают все?

Вы не участвовали в [Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Спасибо за ссылку! Не знал об этом ресурсе..

Смотрим ISO 15765-4 First edition 2005-01-15

6.3.2.2 11 bit CAN identifiers
Table 3 specifies the 11 bit CAN identifiers for legislated OBD, based on the defined mapping of the
diagnostic addresses.

Table 3 — 11 bit legislated-OBD CAN identifiers
CAN identifier Description
(hex)
7DF CAN identifier for functionally addressed request messages sent by external test equipment
7E0 Physical request CAN identifier from external test equipment to ECU #1
7E8 Physical response CAN identifier from ECU #1 to external test equipment
7E1 Physical request CAN identifier from external test equipment to ECU #2
7E9 Physical response CAN identifier from ECU #2 to external test equipment
7E2 Physical request CAN identifier from external test equipment to ECU #3
7EA Physical response CAN identifier from ECU #3 to external test equipment
7E3 Physical request CAN identifier from external test equipment to ECU #4
7EB Physical response CAN identifier ECU #4 to the external test equipment
7E4 Physical request CAN identifier from external test equipment to ECU #5
7EC Physical response CAN identifier from ECU #5 to external test equipment
7E5 Physical request CAN identifier from external test equipment to ECU #6
7ED Physical response CAN identifier from ECU #6 to external test equipment
7E6 Physical request CAN identifier from external test equipment to ECU #7
7EE Physical response CAN identifier from ECU #7 to external test equipment
7E7 Physical request CAN identifier from external test equipment to ECU #8
7EF Physical response CAN identifier from ECU #8 to external test equipment
-----------------------------------------------------
While not required for current implementations, it is strongly recommended (and may be required by applicable
legislation) that for future implementations the following 11-bit CAN identifier assignments be used:
7E0/7E8 for ECM (engine control module);
7E1/7E9 for TCM (transmission control module).
Заметьте что читал не где-то. Поэтому думаю вопрос
вы должны задать в первую очередь себе :wink:

а чего задавать-то - я и так прекрасно "знаю, что ничего не знаю"(с), в отличие, видимо, от вас? хотя делаю все лично сам и убеждаюсь, где надо, а где не надо прибавлять 8-ки...
Вот когда сделаете что-нибудь лично сами - думаю, вся "натянутость" исчезнет..:smile:

Какое самомнение, только пока вашей работы я здесь не видел одни слова и зачастую не правильные.

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

Иногда производители используют сразу несколько разных протоколов диагностики и в основном все происходит через гетевей и иногда некоторые гетевеи умеют делать перидку одного стандарта в другой.

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

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

Думаю, как может повлиять поврежденный радарный контроль на отказ шины, на которой он сидит. Допустим, шина сильно загружена, так как радарный контроль использует высокую частоту посылки сообщений в силу высокой динамики процессов.
Допустим от блока этого радарного контроля перестали поступать сообщения (повредился этот самый блок). Шина наоборот дожна освободиться. Повредить блок да ещё таким образом чтобы он ещё больше стал отсылать сообщений и просадил шину - невозможно.
Все остальные физические неисправности шины (к примеру, замыкание CAN-L или (и) CAN-H на массу или между собой) как бы прямого отношения к какому-нибудь конкретному блоку, вроде, отношения не должны иметь, и могут возникнуть "сами по себе"?
Потом ещё не ясно вот это: "отключает часть шины"
Имеется ввиду - рвет связь с какими-то блоками?

Да физически разрывает провода, шина "привода" не предусматривает работу в "аварийном" режиме по одному проводу или замыкание между собой. Задумка у них такая в момент когда разбивается машина по КАНу передаются команды (еще подушки не взорвались) , должны отключится некие блоки и через телематик отослана информация на сервисный центр что разбивается конкретная машины, просто стыкался с ремонтом таких машин после аварии.

Имеем ECU в диагностическом режиме (0x7E0 -> 0x10 0x81 => 0x7E8 -> 0x50 0x81).
На сколько я понял для каждого ECU для функции 0x21 (ReadDataByLocalIdentifier) нет четкого описания подфункций. Стандарт (ISO 14230-3) описывает несколько подфункций 00, 01. Далее идут диапазоны 02-EF;F0-F9;FA-FE и FF. В стандарте есть пример с подфункцией 0x0A. Где-то видел описание ВАЗовских подфункций.

Вопросы знатокам:

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

Не все ECU поддерживают KWP-2000 тем более по CAN, для некоторых (Toyota, Hуundai) PID 21 отдан на откуп производителю, и большинство данных для этих авто идет именно с ним, а вот тут описания соответственно нет ни какого.

GASCHE, согласен, что не все. Комтранспорт вроде SAE J1939 использует. Да и по нему ABS/EBS/ECAS c EDC Общаются.
Буду искать инфу и ковырять далее. Для легковых примерно понятно в каком направлении двигаться.
На поиграться у меня еще есть ECU двигателя от Hyundai SantaFe и немного WABCO.

Нашел немного инфы по VW Transport Protocol 2.0 (TP 2.0) for CAN bus. Возможно, будет интересно. [Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Даже используя протоколы ISO-9141, ISO-14230, ISO-15765 у производителей на PID 21 может быть совершенно разные значения. Я не совсем понимаю вашу цель, но если вы хотите узнать что значат те или иные значения под этим PID то единственный способ это узнать это найти программу под эту марку и с помощью эмулятора ECU разбираться с этими значениями. Для ряда марок можете посмотреть программу TECU там есть расшифровки PID в отдельных файлах.

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

Моя цель - съем данных с шины и расшифровка их. Что-то типа бортового самописца.
Диагностика - это если заинтересует. Мне интересно взаимодействие датчиков с ECU/EDC.

----------

TECU скачал, посмотрел. Там есть многое из того, что мне нужно.

Прикольно, у Marathon, оказывается, появился бесплатный плагин J1939 к их стандартной программе CAN-мониторинга (CANwise). Уже скачал и установил, (жаль, "под рукой" нет подходящего грузовичка:smile:)
Приложу ещё файл-руководство к этому плагину - там все доходчиво расписано.. (там и интерпретация есть параметров согласно протоколу, вобщем, все расписано..)
Также не менее прикольно, что у них в качестве бесплатных же плагинов возможна серьезная работа с CANopen (для авто- это применимо, например, для спецтехники, где для всякого дополнительного (навесного, к примеру) оборудования используется протокол верхнего уровня - CANopen, главное преимущество которого в наличии так называемых "словарей объектов", чтобы оборудование, в общем случае разных производителей практически "автоматически" интегрировалось в общую систему)
Пока мне не до конца понятно взаимодействие плагинов J1939 и CANopen-вских, о чем они прозрачно намекают в своей документации..
Будем дальше разбираться..

Alexo, Видел данный адаптер и плагины к нему. Скажу честно, мне дешевле заказать китайца.
Доставку в Беларусь на сайте не нашел, попробую им отписать. Их представительств или дилеров у нас нашел (в первом приближении).
У меня читалка на SJA 1000 потом парсинг логов в удобоваримый формат питонами и т.д. Позже перепишу на нормальную прогу и под другую систему. Пока хватает винды для эксперементов.

Многим очень поможет сей девайс с плагинами. База для J1939 зашифрована, хотя бы расшифровывать было бы легче при наличии устройства. Без оного прогу просто не запустить. Придется IDA'ой ковырять. Там dll в которой все и есть. Попробую поиграться на досуге.

Ну да, - в описании в (пдф-е) файлы БД названы как manufacturers.txt (производители) и pgns.txt (собственно, база PGN-ов), а в реале они с расширением .dat. Видимо, в самом начале они были в обычной кодировке в текстовых файлах (т.е., прописаны в явном виде), однако, потом их "закрыли". И раскодировка производится в самой dll-ке.
Хотя о характере записей можно судить также по прилагающемуся файлу revision.2013.txt (ревизии по изменениям и дополнениям) за 2013 г. Там все в явном виде в текстовом формате (кстати, если это изменения действительно только за один год - то офигеть, - сколько их там много для одного года-то..)
Что касается "дорого - дешево" - смотря для чего. Думаю, что за два полноценных канала в исследовательских целях, да ещё и с довольно удобными прикладными интерфейсами и анализаторами и возможностью собственных программных разработок, хорошо задокументированных, $100, считаю недорого...
Кроме того, в таких профессиональных девайсах есть возможность установки LOM (listen only mode) - режим только прослушивания. Дело в том, что любой контроллер в сети обозначает свое присутствие, отсылая периодически обязательную служебную информацию (не путать со стандартными CAN-сообщениями), как бы обозначая свое присутствие. В режиме LOM контроллер никак не выдает своего присутствия, однако все слышит, что происходит в сети.
Далеко не во всех дешевых решениях вообще можно выйти в этот режим.
Точно не знаю как в авто-, но во многих случаях, сеть штатных девайсов просто отказывается общаться, при появлении "лишнего" участника, либо автоматически переходит в режим кодирования и т.д. и т.п.
К тому же - анализ самой шины на ошибки и проч..
Буквально на прошлой неделе знакомый диагност сканматиком не увидел гранту - я же, подкинув два проводка на два известных пина, получил лог, правда он ещё и показал большое количество ошибок самой шины, однако, это уже не сравнить с "Ааа! Все пропало - сканмат вообще ничего не видит! Что делать!:smile:"
Из минусов - как я уже писал, Marathon это клон IXXAAT. На работе у нас есть с десяток тех и других. При большой загруженности (например, подключено 4 двухканальных девайса, то есть, всего 8 каналов, - максимально возможное количество на 1 комп.), Marathon-ы часто начинают глючить, чего не скажешь об IXXAAT. Есть и ещё косячки не в пользу марафонов..
Но я уже говорил - цена IXXAAT - на порядки больше.
Кстати, вот скрин моих небольших опытов с J1939 - соединил два канала одного марафона между собой (2 и 7 пины) и получился простейший эмулятор - с одного канала посылаю, на втором смотрю расшифровку.. Прикольно!

Есть китайский CANalyst-II (Спасибо за наводку Juan7), за 70$ с доставкой. 2 канала, контроллер - SJA1000.
Протоколы: CAN2.0A/2.0B; iCAN; DeviceNet; CANopen; SAE J1939.
SDK присутствует.

Второй мой адаптер - CAN Hacker. Копия того, что делали немцы. Тоже SJA1000. В обоих адаптерах присутствует LOM.

На работе используем CAN BUS Analyzer Tool APGDT002 от Microchip.

Это еще один подводный камешек. 8) В тех авто, что смотрел - такого не видел. Видел только отказ в общении, но не на авто. Пните плз на пример с шифрованием. Интересно для общего развития. Кстати, а что может передаваться по сети в кодированном виде?

В таких случаях либо мультиметр, а лучше осциллограф и смотреть сигналы. Знаю пару примеров, когда EDC заваливал CAN-Lo при нормальном сигнале CAN-Hi. Еще были примеры несогласованной линии - ошибками плевало очень сильно.
Ниже - формы сигналов на линии.
http://tigach.narod.ru/is.files/image002.jpg

CAN-Hacker тоже не подарок, подвисает, глючит. Возможно из-за тормозной ATMega. В CANalyst-II что-то пошустрее.

Посмотрите лог отсюда, если так заинтересовал J1939.
[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]
Там живые данные. Есть на чем поэскперементировать.

----------

Alexo, Еще хотел добавить про PCI/PCI-E<>CAN интерфейсы. Вы такие используете?
М.б. проблема не в адаптерах марафоновских а в South Bridge компа.

По поводу кодировки - знаю, что это применяется в, скажем так, спец. технике - помимо резервирования каналов, допустим, есть такое - период SINC -ов ( в CANopen - сети) в случае какой-либо нештатной ситуации на шине, например, сопротивление вышло за допустимые пределы (тут, кстати, и LOM не поможет) начинает изменяться по квази-случайному закону с большим периодом "квазийности", что сильно осложняет работу "посторонних" блоков, даже если им удалось внедриться в сеть под видом одного из штатных.
Там вариантов - куча, - есть даже алгоритмы, позволяющие вначале вычислить внедренные блоки, а затем перевести их в разные режимы вплоть до отключения.. Все зависит от характера и логики работы шины.
Конечно, не думаю, что все это используется в обычном автомобилестроении, однако, думаю, что некоторые наиболее критичные узлы или службы могут быть защищены чем-то подобным...

----------

За ссылку спасибо, но я пока сам ещё до конца не понял, - что конкретно изучать, - пока ещё даже общая картина не сложилась - просто, пока интересно все подряд связанное с кан-технологиями.
Так что сказать, что J1939 как-то "по-особому" заинтересовал - не могу..

----------

Может быть.. Нет, платы мы не используем.

----------

Посмотрел ссылку - насколько я понял, там формирование базы из реальных логов, причем автоматизировано по-возможности. Вобщем-то, в плагине J1939 уже это есть. Как подключаться к его dll из своего софта и что туда передавать в качестве параметров, - тоже понятно...

У нас пару таких есть, для моделирования сети. Еще часто для отладки их используют.
А так в основном - CAN BUS Analyzer Tool для мониторинга и отправки комманд. И JTAG для внутрисхемной отладки/программирования.

Не совсем так. Там база формируется из XLS файла (файл на 17 странице в моем посте) от SAE. А база отчетов уже из реальных данных.

Файл пока не декодировал, так что трудно сказать. Что касается Вашего скрина с логами - очень похоже, что база у Вас полная и, возможно, старше моей. Т.е. с дополнениями. Сам файл можно скачать для ознакомления. Там описаны алгоритмы расчета параметров, для некоторых параметров - значащие биты.

У меня есть тот екселевский файл с параметрами (тогда ещё скачал). Но, пока, - говорю же, - не знаю в каком направлении "приложиться" более серьезно, в голове пока можно сказать "каша" от обилия информации. Приложиться, - в смысле и чтобы полезно было для знаний, и чтобы интересно по максимуму. Но и про реальный доход забывать нельзя (хотя прекрасно знаю, - начнешь думать преимущественно о марже - все! - лучше и не начинать, - ничего не получится..:cool:)
Сейчас вот почитываю форум rusefi (по Вашей ссылке), - например, интересно, что оттуда можно почерпнуть очень много по логике работы ECU. Для начала хотел бы для себя оценить сложность алгоритмов и объем информации..
То есть, у меня пока цели неуточненные..
Да, ещё и друг зовет вплотную заняться диагностикой (хотя бы на выходных). Тоже пока до конца не пойму - в каком, собственно, качестве? Бывают, конечно, моменты, где и я могу что-то подсказать (как в примере с Грантой), но опять же - пока для меня здесь больше.. не то чтобы неизвестного.., а не "уложившегося по своим полочкам" в голове, - так будет точнее:wink:...

СТО Выходного дня? :smile:
У меня примерно такая же фигня. Только еще один момент. Есть собственный МАЗ, что не свойственно для IT-шника, и сдаю его в аренду.

По поводу инфы - тут лучше определиться что именно нужно. Для меня интересен бортовой самописец/треккер. Для этого я ищу протоколы взаимодействия датчиков с ECU/EDC.
Работа самого блока пока не интересна, но думаю пригодится в дальнейшем.

Ну, он-то занимается постоянно - не просто диагностика, а ещё и ремонт, сигналки, парктроники и проч. Но у него много случаев, типа таких - звонит недавно: "Мазда 3-ка не заводится! По тем ошибкам, что выдавал сканер - отработал - заменил (откинул, что-то там ещё "колдовал") - ничего не помогает. Ты же "спец" по кану! Приезжай - поможешь!":smile:
Трудно объяснить, что все что в лучшем случае я могу дать - это некую доп. информацию, которую все равно "додумывать" придется и чуда не получится..
Да вот тоже - думаю эмуляторы - интересная тема. Однако, там протокол обмена даже не бОльшая часть. Главное - имитация алгоритмов работы. А это уже глубокими знаниями надо обладать..
Такие дела.:smile:

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

Полезная инфа - спасибо!..
Это взгляд, так сказать, "изнутри" - как я понимаю, специалиста, который непосредственно занимается ремонтом.
Хотелось бы услышать мнения о создании эмуляторов также (кто-то говорил тут, что занимался этим)
Интересно также мнение о создании универсального сканера-анализатора с возможностью постоянного САМОСТОЯТЕЛЬНОГО наращивания функционала с помощью интегрированных возможностей (не будучи при этом программистом)..

Ну текса так и делалась, цепляем логер и пишем дамп от дилерского тестера, потом разбираемя, что как и как активируется. Эмуляторы давно придуманы. А вот готовая фича, например ошибки стирать постоянно ;) [Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]