Издатель/подписчик для распределённых отказоустойчивых бортовых систем реального времени в 1500 строк кода

Ваш комментарий относится скорее не к технологии, а к экосистеме вокруг неё. Экосистема не вырастет за ночь или даже за год; это крайне длительный процесс, и не следует ожидать консистентной поддержки вендорами технологии, альфа-релиз которой состоялся лишь шесть месяцев назад. По части конкретно дронов (я так понял, вы из этого сектора) у нас немного сошёл с рельсов процесс в марте этого года, когда выяснилось, что поддержка v1 не успевает в merge window следующего релиза PX4, что косвенно снизило приоритет внедрения и в других проектах из той же отрасли. Происходит это из-за хронической нехватки ресурсов, что вы (ваша компания) можете самым непосредственным образом помочь исправить, если вы видите потенциал во внедрении UAVCAN в ваши продукты. Если вы готовы рассмотреть прямое участие, напишите, пожалуйста, мне в личку — вопросы планирования ресурсов проекта мы не можем обсуждать публично.

Переход от экспериментальной версии v0 к стабильному релизу v1, безусловно, сказался очень тяжело на экосистеме, но это было ожидаемо, и если бы этого можно было избежать, мы бы поступили иначе. Не один тред на форуме посвящён ответам на разные формы вопроса "зачем ломать что работает", так что я тут не буду повторяться. Скажу лишь, что v0 всегда был тестовой площадкой; несколько лет назад я имел смелость сказать, что "v1 вот-вот уже выйдет", но кроличья нора оказалась существенно глубже. Опасения о внезапном выходе v2 со всеми вытекающими для вас как вендора необоснованны, потому что само предположение о том, что v0 является стабильным релизом некорректно (иначе мы назвали бы его v1). Мы заинтересованы в успехе технологии и экосистемы, и мы не собираемся стрелять себе (и вам) в ногу, ломая совместимость с тем, что мы строили шесть лет.

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

Насчёт Yukon — его действительно нет, никогда не было, наличие никогда не заявлялось, и причины всё те же. Пока его заменяют инструменты командной строки. Они не фонтан, конечно, но с задачей справляются пока мы работаем над нормальным инструментом.

Насчёт регистров я вас не понял.

Я пока не увидел новых идей в вашей публикации. Если я что-то упустил или не так понял, пожалуйста, поправьте меня.

Согласно моему пониманию, вы описываете дисциплину организации очереди (мультиплексирования) с регулировкой скорости (rate-controlled service discipline). Конкретно в вашем случае, как это обычно бывает с RCS, вы описываете несохраняющую работу дисциплину (non-work-conserving service discipline, NWC). RCS в целом широко применяются в сетях реального времени с гарантированными характеристиками. Несохраняющие работу дисциплины могут быть неприемлемы в коммерческих сетях потому они, по своему определению, допускают простой (бездействие) канала, что снижает его среднюю загрузку, от чего страдает рентабельность оборудования и средний уровень обслуживания. Смысл их использования сводится к более равномерной резидентности пакетов по маршруту и упрощению анализа сети, что представляет высокую ценность лишь в реальном времени. Средний случай несохраняющей работу дисциплины обслуживания хуже, чем у сохраняющей, но с худшим случаем это отношение может быть обратным. Обратите внимание, что подобная инверсия отношения среднего и худшего случая наблюдается и в других областях; например, в аллокаторах памяти.

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

Конкретно для описанного вами случая обратите внимание на статью Rate-Controlled Service Disciplines (Zhang, Ferrari, 1994), где приводится анализ практически вашего случая, но с адекватным теоретическим аппаратом. Если у вас нет понимания сетевого анализа, рекомендую начать с вводного курса Network Calculus: A Comprehensive Guide (Bemten, Kellerer, 2016), иначе с наскоку утонете. Если интересует реальное время, ознакомьтесь с учебником Safety and Certification Approaches for Ethernet-Based Aviation Databuses (я его уже указал в источниках к этой статье). Также обратите внимание на десятки других методов планирования трафика под разные задачи, помимо класса RCS: D-EDD, VC, WFQ, EDF, и т.п., каждый из которых имеет свои преимущества и недостатки в конкретных приложениях.

На чём основано и что означает утверждение о "гарантированной надёжности" я не понял.

Что касается маршрутизации: вы писали о маршрутизации от источника, но это, в принципе, вещь широко известная и практикуемая. Я вот здесь даже писал о SpaceWire, как пример.

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

Да, через директиву @union. См. примеры и определение в спецификации. Ещё можете заглянуть в руководство, там это упоминается, в т.ч. в контексте проектирования типобезопасных интерфейсов.