На счёт диагностики по CAN не знаю, аскан их диагностил только по к-линии. В 240м вроде J1939 добавили, по нему какую-то стандартную диагностику можно делать, типа ошибки прочитать, переменные стандартные посмотреть. А где-то в инете выкладывали протоколы на эти блоки?

..
 

Да, на абитовском сайте - там в разделе "ДОКУМЕНТАЦИЯ" к каждому блоку..

Да, в нем SJA1000. Писал выше.

Сказать сложно. С данными блоками не сталкивался. Если на них есть какое-то описание, то можно посмотреть протоколы. Либо по дампу попробовать определить протокол.

Подыму тему.

Досталась намедни рулевая колонка от i30/Kia Ceed с электроусилителем. Что самое интересное работает по CAN. Попробую подключить и поиграться.

Возможно не заработает сразу, т.к. для запуска ЭУР необходим сигнал от мозгов о том, что двигатель запущен/работает генератор. Токи там довольно большие на питание усилителя (сечение провода 8mm^2). Дальше буду копать протокол, возможно увижу инициализацию, ответ блока об активации/запуске и положении руля (возможно).

Если найду пакеты с указаением угла поворота, то можно будет потом подключить камеру заднего вида и на монике каком нибуть вместе с видео с камеры еще и траекторию показывать. Так сделано на Tucson/SantaFe.

..
 

Да, тоже вот пытаюсь понять, насколько чего интересного и полезного можно сделать? Я так понимаю, что сигнал о том, что движок запущен, на мозги идет кановский?
Тогда надо искать, в каких сообщениях в таких авто идет информация об оборотах двигла, - и эти сообщения эмулировать. Насколько я понял, читая всякие сайты по канхакингу, вычислить обороты (то есть, отыскать сообщение, где они передаются, выделить байты(обычно их 2 под обороты) довольно просто, так как довольно просто отследить изменения в байтах, с разными усилиями нажимая педаль газа, контролируя показания оборотов на приборке, и одновременно записывая лог по кан-шине).
Другое дело, что реально мозги рулевой колонки могут "опираться" на несколько сигналов - например, чтобы сделать вывод о том, что двиг заведен, - аналоговый об оборотах - отличен от 0, и какой-то сигнал с булевой переменной - "заведен" - "незаведен". По логике "и". То есть, если сымитировать только растущие обороты двигателя, - ничего не будет. Придется находить ещё тот самый "битик"...

Прикольный диалог (но, и "куча" полезной инфы, как то зачастую и бывает "на стыке" чего-нибудь, в данном случае - авто- и авиа- строения:wink:):
[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Alexo, дополню вышесказанное.

Да, на блок идет только CAN и питание.

Похоже так и есть. Опишу режим работы. При включении зажигания. На приборке загораются различные индикаторы. Некоторые погасают (иммобилайзер, abs), некоторые остаются гореть пока не будет заведен двигатель (EPS(ЭУР), ESP). ESP при недостаточном заряде батареи не включается (горит ESP OFF), возможно там нужны большие токи и, чтобы не садить аккумулятор, они не запускаются.
После запуска двигателя инитится ЭУР и погасает лампочка EPS. То же происходит и с ESP.

Из всего этого я сделал следующие заключения:

• Есть устройства, критичные к потреблению электроэнергии и, чтобы не садить аккумулятор, они не запускаются.
• ECU/ECM сообщает о запуске двигателя на шину, для инициализации других устройств.
• Устройства, после инициализации сообщают свой статус. Приборка на основании этого включает/выключает нужную индикацию.

Возможно, здесь учтены не все моменты. И все это верно только для определенной марки и модели авто.

Изучая схему своего авто, убедился, что Body Control Module (BCM) и ECU Smartra (immo) работают через K-Line.
Т.к. BCM подключен только через K-Line, то невозможно(?нужно копать протокол) управлять замками двери. Приборка видит состояние дверей, но вроде бы к ней подключен BCM через K-Line. Схемы нет под рукой. Утверждать не буду.
Причем immo подключен напрямую, без вывода на диагностический разъем. Для привязки новых ключей (прописывания) в иммо нужно будет использовать специфический протокол.

SRS, ABS, ESP, EPS подключены к CAN-шине.

Вот собственно и все, что удалось выяснить.

Так, для общего развития, глянул на стандарты интерфейсов в авиации.
Интересно, что там только сравнительно недавно появился стандарт ARINC 825 - на основе CAN (в Вики, правда, буржуйской, есть описание). Смысл тот же, что и в авто - связь блоков системы управления. До этого протоколы были на основе RS 485. И только последние аирбасы и боинги стали оборудовать каном (хотя, я точно раньше ещё где-то читал - года 2 назад, что ту-204 продекларировали, что будут тоже использовать ARINC 825, но не удивлюсь, если до сих пор это осталось только декларацией)
Причем, этот ARINC 825 сильно смахивает на j1939 - как по принципам, так и по общей "философии". Тоже используются только 29-битные идентификаторы, в которые помимо всего прочего заложена "групповость" и "адресность", расписаны основные параметрические функции, переменные и проч.
А теперь - что сильно интересно, там, как я понял с английской Вики, разработыики протоколов пошли ещё дальше - с помощью довольно простых средств программных разработок (вроде Simulinc-а из пакета MathLab - ну, там, где ещё "квадратики мышкой перетаскивать" (как мне сказал один студент, проходивший у нас практику), создавая логику программы) - создаются после компиляции этих самых "квадратиков" xml -файлы с этими самыми алгоритмами работы, которые заливаются в специально поддерживаемые эту шнягу контроллеры рабочих блоков ЛА. И это все расписано и стандартизировано в ARINC-е.. Вот это круто!
На самом деле, там есть, конечно, и некое управляющее ядро основной программы на неком условном "ЭБУ" (под управлением ОС реального времени, к примеру, - QNX-neytrino), но отдельные блоки можно "легко и непринужденно", а самое главное, - стандартизированно программить..
Да, конечно, там используются и "сверх-" скоростные шины - до 100 Гбит/сек (но это или на "низком" уровне - блоки - актуаторы, датчики и проч., или, к примеру, для быстрой передачи несжатого видео на всякого рода мониторы.. )

----------

Одна из причин консерватизма авиастроения применительно к использованию CAN мне, в общем-то, понятна. Со всеми своими "наворотами" и скоростью, вот, мало кто знает, но у CAN есть один, но могущий в определенных условиях стать очень большим - недостаток. Это то, что шина CAN на низком уровне является НЕДЕТЕРМИНИРОВАННОЙ шиной. То есть, предсказать, в общем случае, что в ней происходит в каждый конкретный момент времени при её загрузке более 50% невозможно.
Имеется ввиду вот что. В сравнении, допустим, с RS485 - тут все ясно и понятно - один блок является мастером (или ведущим, или сервером), все остальные, коих, кстати, в одном сегменте сети может быть не более 255-ти, - слэйвы (ведомые или клиенты). Все четко определено, - каждый блок имеет свой адрес (имя), мастер его периодически опрашивает по строго определенному алгоритму, затем - следующий и т.д.. То есть, последовательность изменения состояния шины известна априори. В кане - все не так - все слышат всех, и все решает шинный арбитраж. И что происходит в каждый конкретный момент - неизвестно.
Для того то, в частности, и "выдумывают" все эти CANopen, DeviceNET и проч. надстройки над кан-ом, чтобы по-возможности, уменьшить недетерминированность. Например, в DeviceNET примерно также как и в RS485 есть мастер, который опрашивае всех остальных..
Только, как говорится, зачем платить больше, если большего функционала и не надо? Стоимость кан-технологий на порядок выше RS485.
Однако, у этих интерфейсов типа RS485 есть вполне физические пределы и с развитием и усложнением СУ транспорта, они просто перестают справляться. Да и программировать сложную логику кан-шины гораздо проще (когда "все слышат всех")

Да и протоколы j1939 и ARINC 825 (также как и другие надстройки) тоже - попытка найти компромисс между практически неограниченными возможностями CAN и несомненно большим достоинством детерминированных протоколов..

Для начала.