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

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

Это уже интересно. Встречный вопрос: на 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, как я понимаю, используется для связи шин с разными скоростями или просто разных физически кан-шин.

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