Где взять описания CAN-протоколов для разных марок?..

Alexo

Так, для общего развития, глянул на стандарты интерфейсов в авиации.
Интересно, что там только сравнительно недавно появился стандарт 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 есть вполне физические пределы и с развитием и усложнением СУ транспорта, они просто перестают справляться. Да и программировать сложную логику кан-шины гораздо проще (когда "все слышат всех")