А я - заценил. Прелесть CANopen'а в том, что настроив устройства,
внутри сети, ты можешь подавать сигнал с одного источника на
несколько приёмников. Автоматически, на уровне устройств, без
всяких шлюзов, серверов и брокеров. А с ведущим, настроив
синхронизацию, фазы и приоритеты, обеспечиваешь гарантированные
временные задержки. И всё это - без правки прошивок устройств,
стандартными средствами! К примеру, пару модулей ввода-вывода CANopen, можно настроить так, чтобы они работали в качестве прозрачного цифрового моста для пучка дискретных и/или аналоговых сигналов, между собой автономно, без всякого сервера. Причём одно устройство, в случае пропадания связи с другим, будет обнаружит отказ и переведёт свои сигналы в безопасное состояние. А можно сеть с ведущим. Тогда ведущий может задавать синхронизацию на сети (предусмотрен механизм горячей автозамены ведущего на случай отказа устройства), а остальные будут привязывать свои кадры с данными к заданной фазе и приоритету передачи в пределах цикла синхронизации. В таком случае Если постараться, то можно не вылезть за пределы пропускной способности и гарантия реальности времени сохранится.
Тут Скрипач неоднократно упоминал случай, когда в сегменте CAN создаётся больше сообщений, чем может передать канальный уровень. С похожим я сталкивался, например, когда в модулях ввода-вывода не была должным образом настроена фильтрация входных сигналов. Тогда, при шуме на входе, модуль генерирует массу сообщений с малым интервалом между ними. И если таких модулей несколько, они могут "положить" сегмент. Но это характерно лишь для асинхронного однорангового режима, когда устройства вольны передавать кадры когда им вздумается. В случае работы с опросом ведущим и запретом произвольной генерации сообщений, а так же в синхронном режиме, шквала сообщений и перегрузки сегмента можно избежать.