Комментарии 17
Торт!
Первый блин проекта был заложен в 2014-м.Странно, самолеты летают и без этого гораздо гораздо раньше, котятки :-~
Ваш комментарий относится скорее не к технологии, а к экосистеме вокруг неё. Экосистема не вырастет за ночь или даже за год; это крайне длительный процесс, и не следует ожидать консистентной поддержки вендорами технологии, альфа-релиз которой состоялся лишь шесть месяцев назад. По части конкретно дронов (я так понял, вы из этого сектора) у нас немного сошёл с рельсов процесс в марте этого года, когда выяснилось, что поддержка v1 не успевает в merge window следующего релиза PX4, что косвенно снизило приоритет внедрения и в других проектах из той же отрасли. Происходит это из-за хронической нехватки ресурсов, что вы (ваша компания) можете самым непосредственным образом помочь исправить, если вы видите потенциал во внедрении UAVCAN в ваши продукты. Если вы готовы рассмотреть прямое участие, напишите, пожалуйста, мне в личку — вопросы планирования ресурсов проекта мы не можем обсуждать публично.
Переход от экспериментальной версии v0 к стабильному релизу v1, безусловно, сказался очень тяжело на экосистеме, но это было ожидаемо, и если бы этого можно было избежать, мы бы поступили иначе. Не один тред на форуме посвящён ответам на разные формы вопроса "зачем ломать что работает", так что я тут не буду повторяться. Скажу лишь, что v0 всегда был тестовой площадкой; несколько лет назад я имел смелость сказать, что "v1 вот-вот уже выйдет", но кроличья нора оказалась существенно глубже. Опасения о внезапном выходе v2 со всеми вытекающими для вас как вендора необоснованны, потому что само предположение о том, что v0 является стабильным релизом некорректно (иначе мы назвали бы его v1). Мы заинтересованы в успехе технологии и экосистемы, и мы не собираемся стрелять себе (и вам) в ногу, ломая совместимость с тем, что мы строили шесть лет.
Ваши слова об отсутствии чёткого описания объективно не соответствуют действительности. Возможно, вы имели в виду, что не хватает удобоваримой документации, что было бы правдой, ведь спецификация написана максимально нудным языком (как это обычно бывает со спецификациями). Мы пытаемся это исправить в официальном руководстве, и нам очень нужна конструктивная критика от интеграторов вроде вас.
Насчёт Yukon — его действительно нет, никогда не было, наличие никогда не заявлялось, и причины всё те же. Пока его заменяют инструменты командной строки. Они не фонтан, конечно, но с задачей справляются пока мы работаем над нормальным инструментом.
Насчёт регистров я вас не понял.
Перед массивами переменной длины всегда есть длина. Я не знаю, о каком примере вы говорите, но, судя по вашему описанию, он корректен. Репрезентация массивов переменной длины описана спецификацией в разделе 3.7.4.2 Variable-length array types; там объясняется, как кодируется этот префикс.
Длина была бы не нужна только если бы определение было не uint8[<=50] name, а uint8[50] name.
Не покладая клавиатуры над поддержкой v1 в PX4 трудится товарищ Daniel Agar; вы можете наблюдать за прогрессом тут: https://github.com/PX4/Firmware/pull/14865. Параллельно идёт работа над DS-015 (чем со следующей недели я начну заниматься лично) и сериализацией (вместо ревью ценного пулреквеста я засел вот писать статью, сами видите). Всё это необходимо для интеграции в PX4.
документация неконсистентна
Где именно?
И да, у нас есть практически готовый актуатор с поддержкой CAN FD, к которому мы хотели бы прикрутить поддержку UAVCAN v1, если с Вашей стороны есть интерес в этом направлении, то было бы очень здорово.
Есть. Рассказывайте. Можно в личку.
Как я вижу, пункт 3.4.3 спецификации говорит, что uint8[<=50] — это объявление массива переменного размера, а пункт 3.7.4.2 говорит как его сериализовать.
habr.com/ru/post/512652
Есть возражения?
Я пока не увидел новых идей в вашей публикации. Если я что-то упустил или не так понял, пожалуйста, поправьте меня.
Согласно моему пониманию, вы описываете дисциплину организации очереди (мультиплексирования) с регулировкой скорости (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, как пример.
Если вы планируете и дальше заниматься этим вопросом, вам следует ознакомиться с современной теорией, иначе есть риск открыть Америку.
Согласно моему пониманию, вы описываете дисциплину организации очереди (мультиплексирования) с регулировкой скорости (rate-controlled service discipline).
Некоторое созвучие с указанной вами технологией есть, если я не ошибаюсь, похожие идеи используются в программно определяемых сетях. Хочу отметить, что эти протоколы достаточно высокого уровня и требуют «общесетевой» координации, что невозможно в высокоскоростных системах реального времени. RCS алгоритм чем то напоминает телефонную связь — набери номер (зарегистрируй канал связи) и пользуйся. В гипертрофированном виде RCS становится близнецом технологии SDH (ну разве что без иерархии скоростей), поскольку SDH не применяется в качестве интерфейса компьютерной связи, то и перспективы RCS тоже весьма туманны. Программно определяемые сети появились достаточно давно, но энтузиазма в их внедрении не наблюдается — думаю это тоже мертво-рожденный проект.
Для символьной коммутации похожие идеи планирую применить на уровне управления приоритетами исполнения программ, там есть возможность заранее предсказывать потребность исполняемой программы в сервисе передачи данных и «на лету» переконфигурировать сеть передачи данных.
Мое мнение, в системах связи основанных на чистой пакетной коммутации невозможно получить требуемое для высокоскоростных систем реального времени гарантированное качество обслуживания.
Предлагаемый алгоритм, является алгоритмом канального уровня и позиционируется как альтернатива пакетным (Ethernet) и синхронным фреймовым (SDH) системам и именно с ними необходимо сравнивать. Символьная иерархия позволит создавать каналы передачи с требуемым качеством обслуживания от гарантированного канала ( с несколькими альтернативами и параллельной передачей данных по различным маршрутам за точно известное и неизменное время — такие каналы необходимы в авиационных системах и тд) и до предельно негарантированного канала (скачивание данных из сети, с возможностью временно занять всю имеющуюся пропускную способность канала и мгновенным ее освобождением при необходимости).
Rate-Controlled Service Disciplines (Zhang, Ferrari, 1994)— прочитал, не могу сказать, что очень внимательно, суть уловил: Необходимо создать отдельный сервер, который будет управлять коммутаторами и клиентами. Обрабатывать заявки на соединения и указывать параметры связи. Считаю такой подход не имеющим будущего.
На чём основано и что означает утверждение о «гарантированной надёжности»
На отсутствии возможности переполнения промежуточных буферов, гарантии скорости,
постоянства времени доставки сообщений, возможности узнать о обрыве соединения за время сравнимое со временем распространения ЭМ сигнала от между приемником и передатчиком (в одну сторону), возможность заранее создать один или несколько каналов передачи данных с требуемым маршрутом. И при этом если резервные каналы не используются, то их пропускная способность используется каналами с негарантированным качеством.
Если требования по качеству связи немного снижены и нет необходимости в дублировании или троировании, то можно узнав о обрыве основного канала связи, быстро попытаться создать канал с альтернативным маршрутом и скоростью.
На этапе создания нового канала связи и вступает в дело различный математический аппарат описывающий работу систем массового обслуживания, 100% гарантии создания нового канала нет — линии связи могут быть перегружены. В отличии от пакетной коммутации, символьная коммутация стабильно работает (для уже созданных каналов) практически до 100% утилизации физического канала.
Асинхронность в символьной коммутации проявляется на этапе создания нового канала, чем чаще передатчик запрашивает создание нового канала, тем больше асинхронность (случайная составляющая) предоставляемого канала. Если канал создать в момент запуска приложения, то он гарантированно существует до его закрытия или приложением или вышестоящим администратором или до перманентной аварии оборудования. Регулирование вероятности ошибки в передаваемых данных осуществляется обычными методами (корректирующие коды и тд).
Что касается маршрутизации: вы писали о маршрутизации от источника, но это, в принципе, вещь широко известная и практикуемая
Согласен и применено по причине максимальной скорости и отсутствию необходимости в памяти для хранения коммутационных таблиц определения интерфейса для дальнейшей передачи данных. Кроме того достаточно удобно совмещать адресацию интерфейсов с различными типами авторизации, указанием интерфейсной информации (адрес в памяти можно представить как маршрут) и тд.
По поводу выбора кванта передаваемой информации (размера): квант информации называю символом по причине его относительно небольшого размера. Размер кванта определяется отношением битовой скорости передачи физического канала и тактовой частотой работы аппаратуры коммутатора. Скорость передач в триллионы бит уже не удивительна, а цифровых микросхем с тактовой частотой в 1000ГГц еще нет, вот и приходится обрабатывать информацию порциями больше одного бита. Сверху размер символа ограничивается ростом размера буфера, зачем долго хранить много информации, если можно почаще и мало.
Вы ничего не поняли. Простите за прямоту, я хочу сэкономить нам обоим время. Прочитайте учебники, что я предложил, подтяните матчасть, потом возвращайтесь. Ничего личного.
www.electronics.ru/journal/article/759
Думаю это упростит понимание, в SpaceWire много параллелей.
Символьный коммутатор позволяет создавать большое число каналов с различной постоянной скоростью (или с постоянной+асинхронная не гарантированная составляющая). По кодированию символов и адресации практически один в один.
В SpaceWire я не увидел что делать при перегрузки каналов (может что то пропустил) — написано: сразу коммутируем данные в выходной порт и получаем задержку на время передачи одного символа. А вот как быть если в этот канал уже что передается именно в это время.
Думаю Вы несправедливо упрекаете меня в незнании «матчасти». Хотя человеку привыкшему что все сети пакетные, очень трудно принять, что сеть с коммутацией каналов будет эффективней.
PS Прошу выражайтесь проще, думаю нет необходимости «укрываться» за около научной терминологией (да и короче получится), я и так не сомневаюсь в Вашей компетентности.
Да, через директиву @union. См. примеры и определение в спецификации. Ещё можете заглянуть в руководство, там это упоминается, в т.ч. в контексте проектирования типобезопасных интерфейсов.
С момента публикации статьи у нас появился канал в телеграме: t.me/uavcan_ru
Издатель/подписчик для распределённых отказоустойчивых бортовых систем реального времени в 1500 строк кода