Эмуляторы датчиков для VAG-группы оказались вообще универсальными. Главная сложность с эмуляторами - правильно представлять САМО физическое поведение эмулируемой системы, и затем его имитировать. Для примера - имитируем ДМРВ (ФОРД). Для этого:
1. Необходимо посылать в шину 2 сообщения со своими идентификаторами. Одно шлется только в ответ на соответствующий запрос ЭБУ (когда он придет), второе - периодически один раз в 32 мс.
2. Данные условно можно разделить так: служебные данные и непосредственно измеряемые данные. ЭБУ с некоторой периодичностью отправляет сообщение - запрос, в котором содержится, в частности, информация о режиме работы датчика ДМРВ (оказывается, у ФОРД их несколько и по команде от ЭБУ ДМРВ должен в них как бы "переключаться", а вот, отчего режимы зависят - до конца не ясно, - нужно углубленно изучить трейсы с реальной машины при реальной езде). Ну, и собственно, данные о расходе (это в периодическом сообщении от ДМРВ), в формате 4 байта (двойной точности) - в м.куб/сек.
Некоторые байты чисто булевы - ("есть связь - нет связи", результаты самодиагностики датчика "исправен-неисправен" и т.д.), некоторые (их 2 - по одному для каждого 8-мибайтного сообщения) - всегда имеют значение 0 - по-видимому, зарезервированы, а сейчас не используются.. и т.д.
Основная сложность в эмуляции - понять как переключаются режимы и от чего это зависит...
То есть в общем эмулятор готов, однако, к нему нужна программная надстройка имитирующая его поведение. В настоящий момент, при совместной работе готовых эмуляторов датчиков скорости, ХХ, газа, ДМРВ, машина "глохнет" через 20-25 сек работы, при этом диагностика передает, что причина - ДМРВ (неверный режим)..
Как-то так.
Остальные байты в этих двух

99,9% это J1939, погугли.

Alexo, Тема конечно интересная, но :
К примеру по форду от марки к марке (а точнее идентификатора мотороного блока) есть отличие в запросе PID к примеру МАФ по заводскому протоколу и по ОБД. То есть по итогу получаем разные значения одного и того же параметра (так написали софт софтописатели форд :biggrin1:)

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

Тем не менее за поднятие темы спасибо!

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

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

Приложу пожалуй несколько файликов по теме.
Правда вся инфа на английском, но для тех кто в теме это не проблема :super:

Может де компилировать прошивку Модуля 2CAN для какой нибудь CAN сигнализации. К примеру Starline E90. И вообще сама платка с ARM процессором на борту интересный объект для исследования. Она переводит can запросы в обычные Rx Tx.

Чем elm-327 в терминале не устраивает!И какая декомпилляция (это не ассемблер)! Суть протокола iso 15765 почитайте!

Ну для начала так

Один из участников любезно предоставил протокол обмена так называемого замедлителя, который применяется в грузовых и автобусах для регулирования крутящего момента на колесах в зависимости от многих факторов. Если он разрешит, то я выложу и сам протокол в дальнейшем. А пока- для конкретного примера этого замедлителя (ZF, насколько я понимаю):
Допустим, нам необходимо насколько возможно протестить замедлитель, протокол обмена по КАН с которым у нас имеется. В протоколе вначале идет описание распиновки разъема замедлителя. Относительно CAN интересны пины 21-24 и 48-51. При этом, для анализатора (допустим, Marathon – стоимость которого на сайте производителя вместе с ПО около 6500 руб. всего-то) нужны пины 22 и 49 (или 23 и 50 – как они обозначены в описании, - «redundant» или «дополнительные», так как скорее всего к ним ничего не подключается и они нужны как раз для подключения подобного анализатору оборудования). Возможно, надо будет подключить и массовый провод (24 или 51) и установить терминатор (резистор на 120 Ом) между (21 или 48 и земля). Можно и «вычислить» шину CAN идущую от разъема этого замедлителя где-то в другом, доступном месте и там к ней подключиться зачистив каждый из двух проводов для подключения. А есть и КАН-крокодилы, которые позволяют подключаться к проводам без гальванического контакта.
Ну, допустим, подключились, и, запустив ПО CANwise на ноуте, выбираем скорость. Тут надо пояснить – имеющийся протокол не описывает скорость обмена, так как он представляет из себя только лишь часть большого описания, касающаяся только замедлителя (это видно из того, что написано, например, «page 19 from 54», то есть, это было описание не только одного конкретного замедлителя, но, возможно всей системы, в рамках которой он работает). Видимо, где-то в общих описаниях и было конкретное значение скоростей обмена. Ну, да не беда – стандартизированных скоростей всего-то с десяток, а с такими системами как двигатель, ходовая и проч. вообще скорее всего скорость 500 кбит/сек. Так что скорость, хоть она и не описана – не проблема. Хорошо, вычислили скорость – т.е., просто установили очередную стандартную из предлагаемого списка и запустили прогу «стартом». Как только со скоростью «угадаем» и связь установится, - сразу в поле Receive появится куча данных. Далее удобнее использовать режим проги Tracer, в котором сообщения не «бегут» а «стоят» на месте, а в них данные меняются.
Теперь непосредственно описание сообщений и данных – в принципе все понятно из описания – кто (какой прибор) и с какой периодичностью посылает данные (например, скорость замедлитель получает во 2-м и 3-м байте сообщения от системы круиз контроля, сам замедлитель шлет в 1-ых четырех битах 1-го байта одного из своих сообщений информацию о том включен он или отключен, если включен, то по какой причине (что инициировало его включение в работу – ABS, ASR, transmission control, acceleration pedal и т.д.).) Всего по этому протоколу обмена с десяток различных сообщений, в которых приводится и управляющая и диагностическая иформация.
Теперь, что можно сделать дополнительно, кроме непосредственно диагностики.
А можно очень просто «откинуть» «подозрительный» прибор, с которым происходит общение по КАН у замедлителя, и вместо него посылать свои данные с помощью той же проги CANwise. Тут, конечно, надо знать что посылать, но процентов 90 описано в самом протоколе, а можно снять логи с заведомо испраного и т.д. – поле деятельности необъятное.
Просто хотел сказать на этом примере для авто, оборудованных CAN – прибор за 100 баксов + протоколы обмена > любого самого крутого дилерского сканера