Cyphal

Материал из in.wiki
Перейти к навигации Перейти к поиску

Cyphal — это легковесный протокол, разработанный для надежной связи внутри транспортной платформы[1] с использованием различных транспортных протоколов, первоначально предназначенный для шины CAN, но в последующих версиях ориентированный на различные типы сетей[2].

OpenCyphal — это проект с открытым исходным кодом, целью которого является предоставление реализаций протокола Cyphal под лицензией MIT. До ребрендинга в марте 2022 года проект был известен как UAVCAN (Uncomplicated Application-level Vehicular Computing and Networking).

История[править | править код]

Первый RFC, в котором в общих чертах изложены общие идеи, которые позже составят основные принципы проектирования Cyphal (в то время называвшегося UAVCAN), был опубликован в начале 2014 года.

Это был ответ на отсутствие[3] адекватных технологий, которые могли бы облегчить надежный обмен данными внутри транспортного средства в режиме реального времени между распределенными компонентами современных интеллектуальных транспортных средств (в первую очередь беспилотных летательных аппаратов)[4].

Со времени первоначального RFC протокол претерпел три основные итерации разработки, кульминацией которых стал выпуск первой долгосрочной стабильной версии в 2020 году (6 лет спустя) под названием UAVCAN v1.0. Тем временем протокол был использован в многочисленных разнообразных системах, включая беспилотные летательные аппараты[5][6], космические аппараты[7], подводные роботы[8], гоночные автомобили[9], робототехнические системы общего назначения[10] и транспортные средства, обеспечивающие микромобильность[11]. В 2022 году протокол был переименован в Cyphal[12].

Cyphal позиционируется разработчиками как в высшей степени детерминированная, ориентированная на безопасность альтернатива высокоуровневым платформам публикации-подписки, таким как DDS или граф вычислений ROS, которая достаточно компактна и проста, чтобы ее можно было использовать в глубоко встроенных приложениях с высокой степенью целостности[13]. Было показано, что Cyphal можно использовать с микроконтроллерами без операционной системы, оснащенными всего лишь 32 КБ ПЗУ и 8 КБ ОЗУ[14].

Протокол открыт и может свободно использоваться без одобрения или лицензионных сборов. Разработка основного стандарта и его эталонных реализаций ведется открытым способом и координируется посредством общественного дискуссионного форума[15]. По состоянию на 2020 год проект поддерживается несколькими крупными организациями, включая NXP Semiconductors[16] и Dronecode Project[17].

История Cyphal в контексте других протоколов, связанных с последовательной шиной:

History of Serial Protocols.png

Пояснения к диаграмме:

a. MODBUS часто работает поверх RS-232.

b. DDS использует CORBA Interface Definition Language.

c. MODBUS работает по TCP используея порт 502.

d. Аэробус обращается к ARINC c просьбой адаптировать CAN к авиационной индустрии. Michael Stock использует свой опыт по разработке CANAerospace и, в результате, в качестве результата запрошенной разработки публикуется ARINC-825-1.

e. Первый стандарт AVB опубликован AVB Task Group, ведущей свою деятельность в рамках рабочей группы IEEE 802.1. Выпущен стандарт IEEE 1722-2011.

f. AVB Task Group переименована в TSN Task Group.

g. Выпущен паке ROS2, использующий, в качестве базовой технологии, DDS. Типичный транспорт для распределённых систем на базе ROS2 - Ethernet.

h. С выпуском стандартов 802.1Qbv и 802.1Qbu определена полностью детерменированная версия Ethernet.

i. Павел Кириенко выпускает открытый стандарт UAVCAN v0. Первоначально стандарт поддерживает CAN 2.0B.

j. Аэробус в своей презентации “Avionics Full Duplex Ethernet and the Time-Sensitive Networking Standard”, представленной IEEE предлагает включить AFDX в состав стандартов TSN.

k. Стандарт ARINC 825-4 включает поддержку CAN-FD и определяет схему туннелирования поверх ARINC-664.

l. Сервис Amazon Prime Air предлагает минимальный набор изменений к UAVCAN v0, обеспечивающих поддержку CAN-FD. Эти изменения получают неофициальное название UAVCAN v0.5. Практически одновременно с этим на Стокгольмском саммите разработчиков UAVCAN предлагается радикально переработанная спецификация UAVCAN v1[18].

m. Спецификация 10BASE-T1S добавляет к IEEE 802.3 полудуплексный многоточечный вариант Ethernet, работающий по одной паре и включающий в себя механизм устранения коллизий на физическом уровне - PLCA (PHY-Level Collision Avoidance). Спецификация ориентирована на нужды промышленных сетей и бортовых сетей автомобилей, в том числе на замену MODBUS.

n. Заканчивается выпуск Airbus A380.

o. Выходит бета-версия UAVCAN v1.

p. Группа разработчиков, не согласная с проектом UAVCAN v1[19], принимает на себя ответственность за развитие спецификации UAVCAN v0/v0.5. Во избежание дальнейшей путаницы, новые версии этой спецификации и сама группа разработчиков получают название DroneCAN.

q. UAVCAN v1 переименовывается в Cyphal[20].

Дизайн[править | править код]

Cyphal предоставляет абстракции с нулевой стоимостью, которые доступны и знакомы инженерам-программистам без ущерба для функциональной безопасности и детерминизма.

Будучи новой технологией, Cyphal не обременен унаследованными особенностями и в значительной степени опирается на недавние разработки в сфере программирования общего назначения.

Протокол предлагает в качестве базовой модель взаимодействия между программными компонентами сети «publish/subscribe» без сохранения состояния.

Этот подход позволяет любому узлу начать работу сразу после подключения к сети без дополнительных процедур инициализации и обеспечивает взаимодействие приложений с высокой общей степенью целостности системы.

Протокол состоит из двух четко разделенных основных компонентов: транспортный уровень, который работает поверх надежных автомобильных сетей, таких как Ethernet или CAN FD, и уровень независимого от транспорта представления (сериализации), основанный на так называемом языке описания структуры данных - (Data Structure Description Language, DSDL).

Было показано, что протокол можно реализовать менее чем в 1000 логических строк кода.

DSDL идеологически похож на язык описания интерфейса, используемый в ROS, за исключением того, что он вводит дополнительные статические ограничения, чтобы сделать решение пригодным для встроенных систем реального времени с высокой степенью целостности. Сходство побудило некоторых разработчиков связать ROS с Cyphal, используя слой автоматической трансляции.

Основные принципы[править | править код]

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

Демократичная сеть. В сети отсутствует главный узел. Все узлы в сети имеют одинаковые права связи; не должно быть единой точки отказа.

Обеспечение функциональной безопасности. Проектировщики систем Cyphal имеют в своем распоряжении необходимые гарантии и инструменты для анализа системы и обеспечения ее правильного поведения. Абстракции связи высокого уровня. Протокол поддерживает семантику связи публикации/подписки и удаленного вызова процедур со статически определенными и статически проверенными типами данных (схемой). Типы данных, используемые для связи, определены ясным и независимым от платформы способом, который может быть легко понятен как машинам, так и людям.

Упрощение взаимодействия между поставщиками. Cyphal обеспечивает общую основу, на которой разные поставщики могут опираться, чтобы гарантировать совместимость своего оборудования. Cyphal предоставляет общий набор стандартных типов коммуникационных данных, не зависящих от приложения.

Четко определенные общие функции высокого уровня. Cyphal определяет стандартные службы и сообщения для общих функций высокого уровня, таких как: обнаружение сети, конфигурация узла, обновление программного обеспечения узла, мониторинг состояния узла, общесетевая синхронизация времени, Plug-and-Play. поддержка узлов и т. д.

Атомарные абстракции данных. Узлы могут обмениваться большими структурами данных, которые превышают емкость одного транспортного кадра. Cyphal выполняет автоматическую декомпозицию и сборку данных на уровне протокола, скрывая связанные с этим сложности от приложения.

Высокая пропускная способность, низкая задержка, детерминизм — Cyphal добавляет очень низкие накладные расходы к базовому транспортному протоколу, что обеспечивает высокую пропускную способность и низкую задержку. Это делает Cyphal хорошо подходящим для приложений, работающих в режиме реального времени.

Поддержка резервных интерфейсов и резервных узлов — Cyphal подходит для приложений, требующих модульного резервирования.

Простая логика, низкие вычислительные требования — Cyphal предназначен для широкого спектра встраиваемых систем, от высокопроизводительных бортовых компьютеров до микроконтроллеров с крайне ограниченными ресурсами. Его поддержка не требует больших затрат с точки зрения вычислительной мощности и времени на разработку, а расширенные функции можно внедрять постепенно по мере необходимости. Богатые типы данных и абстракции интерфейса. Язык описания интерфейса является основной частью технологии, позволяющей глубоко встроенным подсистемам напрямую взаимодействовать с системами более высокого уровня (и в удобной для сопровождения форме), одновременно обеспечивая симуляцию и функциональное тестирование.

Поддержка различных транспортных протоколов. Cyphal можно использовать с несколькими различными транспортными протоколами и в будущем можно расширить для поддержки других транспортных протоколов.

Стандарт, не зависящий от API. В отличие от некоторых других сетевых стандартов, Cyphal не пытается описать интерфейс прикладной программы (API). Любые детали, не влияющие на поведение реализации, наблюдаемое другими участниками сети, выходят за рамки спецификации.

Открытая спецификация и эталонные реализации. Спецификация Cyphal есть и всегда будет открытой и бесплатной для использования всеми. Эталонные реализации распространяются на условиях разрешительной лицензии MIT или передаются в общественное достояние.

Транспортный уровень[править | править код]

Cyphal/CAN[править | править код]

Cyphal может использовать CAN и CAN FD в качестве транспортного уровня, с использованием 29-битных идентификаторов. В этом случае в каждый кадр включается дополнительный байт служебных данных транспортного уровня[21].

Cyphal/UDP[править | править код]

Транспорт Cyphal/UDP был предложен для базирующихся на Ethernet бортовых сетей транспортных средств. На дизайн протокола повлияли AFDX, DDS/RTPS, и SOME/IP[22].

Стандартные типы данных[править | править код]

Как и другие подобные технологии, Cyphal предоставляет предопределённый набор типов данных, управляемый и курируемый разработчиками протокола, и предназначенный для решения определенных распространенных задач в популярных приложениях[23]. Эти типы данных дополняют типы данных, специфичные для конкретны поставщика или приложений, используемые разработчиками этих приложений, подобно тому, как язык программирования обычно определяет стандартную библиотеку, на которую будет опираться программное обеспечение, разработанное пользователем.

Спецификация протокола предоставляет набор правил, призванных избежать конфликтов и улучшить совместимость типов данных, определенных независимыми поставщиками[24].

Внешние ссылки[править | править код]

Примечания[править | править код]

  1. ↑ Прежде всего - БПЛА, хотя принципиальных ограничений по использованию на других видах транспортных средств нет.
  2. ↑ "UAVCAN - Kvaser - Advanced CAN Solutions". Дата обращения: 16 October 2019.
  3. ↑ По мнению разработчика UAVCAN.
  4. ↑ "Drones discuss | UAVCAN - CAN bus for UAV". groups.google.com/forum/#!topic/drones-discuss. Дата обращения: 2020-02-27.
  5. ↑ Meier, Lorenz (2017). Dynamic Robot Architecture for Robust Realtime Computer Vision (Thesis). ETH Zurich. doi:10.3929/ethz-a-010874068.
  6. ↑ "ArduPilot Developer | CAN bus and UAVCAN protocol". ardupilot.org. Дата обращения: 2020-02-27.
  7. ↑ Losekamm, Martin; Milde, Michael; Poschl, Thomas; Greenwald, David; Paul, Stephan (2016). "Real-Time Omnidirectional Radiation Monitoring on Spacecraft". AIAA Space 2016 (paper). doi:10.2514/6.2016-5532. ISBN 978-1-62410-427-5.
  8. ↑ Bhat, Sriharsha. Towards a Cyber-Physical System for Hydrobatic AUVs // OCEANS 2019 - Marseille / Sriharsha Bhat, Ivan Stenius, Nils Bore … [и др.]. — 2019. — P. 1–7. — ISBN 978-1-7281-1450-7. — doi:10.1109/OCEANSE.2019.8867392.
  9. ↑ "Archived copy" (PDF). Архивировано из оригинала (PDF) 2020-02-28. Дата обращения: 2020-02-28.{{cite web}}: Википедия:Обслуживание CS1 (архивная копия в качестве заголовка) (ссылка)К:Википедия:Обслуживание CS1 (архивная копия в качестве заголовка)
  10. ↑ "GitHub - MonashUAS/Canros: UAVCAN to ROS interface". GitHub. 5 April 2022.
  11. ↑ "All new 2019 VESC-Tool release". 8 February 2019.
  12. ↑ "UAVCAN v1 is now Cyphal". OpenCyphal Forum. 2022-03-25. Дата обращения: 2022-10-13.
  13. ↑ "UAVCAN: A highly dependable publish-subscribe protocol for real-time intravehicular networking". 2 July 2019.
  14. ↑ "New OpenGrab EPM V3 for UAV cargo holding". 4 December 2015.
  15. ↑ https://forum.opencyphal.org/
  16. ↑ "NXP Semiconductors is pleased to support UAVCAN V1.0". 9 December 2019.
  17. ↑ "Dronecode | Leading open-source components for UAVs". www.dronecode.org. Дата обращения: 2020-02-27.
  18. ↑ "Stockholm Summit recap". OpenCyphal Forum ref-английский. 2018-10-05. Дата обращения: 2022-10-13.К:CS1 английский-language sources (en)
  19. ↑ Ядром этой группы стали разработчики ArduPilot.
  20. ↑ "UAVCAN v1 is now Cyphal". OpenCyphal Forum ref-английский. 2022-03-25. Дата обращения: 2022-10-13.К:CS1 английский-language sources (en)
  21. ↑ https://opencyphal.org/specification Шаблон:Bare URL PDF
  22. ↑ "Alternative transport protocols in UAVCAN". 11 January 2019.
  23. ↑ "Regulated DSDL definitions". GitHub. 16 November 2021.
  24. ↑ "Data type regulation policy and membership fees". 8 December 2019.
Источник — https://in.wiki/w/index.php?title=Cyphal&oldid=180902