Cyphal

Last updated

Developer(s) Zubax Robotics / OpenCyphal Development Team [1]
Initial release2014
Repository https://github.com/OpenCyphal
Written inC++, C, Python, Rust, JavaScript
Operating system Cross-platform
License MIT license
Website opencyphal.org

Cyphal is a lightweight protocol designed for reliable intra-vehicle communications using various communications transports, originally destined for CAN bus, [2] but targeting various network types in subsequent revisions. [3] OpenCyphal is an open-source project that aims to provide MIT-licensed implementations of the Cyphal protocol. The project was known as UAVCAN (Uncomplicated Application-level Vehicular Computing and Networking) prior to rebranding in March 2022.

Contents

History

The first RFC broadly outlining the general ideas that would later form the core design principles of Cyphal (branded UAVCAN at the time) was published in early 2014. [4] It was a response to the perceived lack of adequate technology that could facilitate robust real-time intra-vehicular data exchange between distributed components of modern intelligent vehicles (primarily unmanned aircraft).

Since the original RFC, the protocol has been through three major design iterations, which culminated in the release of the first long-term stable revision in 2020 (6 years later) labelled UAVCAN v1.0. In the meantime, the protocol has been deployed in numerous diverse systems including unmanned aerial vehicles, [5] [6] spacecraft, [7] underwater robots, [8] racing cars, [9] general robotic systems, [10] and micromobility vehicles. [11] In 2022, the protocol was rebranded as Cyphal. [12]

Cyphal is positioned by its developers as a highly deterministic, safety-oriented alternative to high-level publish-subscribe frameworks such as DDS or the computation graph of ROS, which is sufficiently compact and simple to be usable in deeply embedded high-integrity applications. [13] Cyphal has been shown to be usable with bare metal microcontrollers equipped with as little as 32K ROM and 8K RAM. [14]

The protocol is open and can be reused freely without approval or licensing fees. The development of the core standard and its reference implementations is conducted in an open manner, coordinated via the public discussion forum. [15] As of 2020, the project is supported by several major organizations including NXP Semiconductors [16] and the Dronecode Project. [17]

History of Cyphal in the context of other serial protocols

History of Serial Protocols.png

a. MODBUS often runs over RS-232.

b. DDS Borrows an Interface Definition Language from CORBA.

c. MODBUS over TCP port 502.

d. Airbus approaches ARINC to request a new CAN standard be developed. Michael Stock provides his experience developing CAN Aerospace. ARINC-825-1 is the result.

e. First AVB standard is published by the AVB Task Group of the IEEE 802.1 working group. IEEE1722-2011 is released.

f. The AVB Task Group is renamed the TSN Task Group.

g. ROS2 Builds on top of DDS. Typical media for distributed ROS2 systems is Ethernet.

h. 802.1Qbv and 802.1Qbu are released, enabling fully deterministic Ethernet networks to be defined.

i. Pavel Kirienko leads an open-source effort to define UAVCAN v0. Initially, it only supports CAN 2.0B.

j. Airbus gives a presentation to the IEEE, “Avionics Full Duplex Ethernet and the Time-Sensitive Networking Standard” which proposes incorporating AFDX into the TSN standards.

k. ARINC 825-4 adds support for CAN-FD and defines tunneling over ARINC-664.

l. Amazon Prime Air defines a minimal set of changes to v0 adding CAN-FD support. The unofficial variant is dubbed v0.5. At the same time, at the Stockholm Summit, [18] UAVCAN v1 was conceived.

m. 10 BASE T1S is added to IEEE 802.3 defining half-duplex, two-wire, multi-drop Ethernet media with PLCA (PHY-Level Collision Avoidance). The specification is targeted at automotive and industrial use cases (e.g. MODBUS replacement).

n. Airbus A380 ends production.

o. UAVCAN v1 becomes beta.

p. DroneCAN takes over maintenance of the UAVCAN v0/v0.5 specification and advancement on top of it.

q. UAVCAN v1 is renamed Cyphal. [12]

Design

Cyphal provides zero-cost abstractions that are approachable and familiar to software engineers [19] without compromising on functional safety and determinism. [3] As a new technology, it is unencumbered by legacy [3] and borrows heavily from recent developments in the field of general information technology. [20] The protocol offers a stateless publish-subscribe communication model where a node can begin operation immediately upon connection to the network to accommodate high-integrity applications. [13]

The protocol has two clearly separated major components: [21] the transport layer that works on top of reliable vehicular networks such as Ethernet or CAN FD, and the transport-agnostic presentation (serialization) layer based on the so-called Data Structure Description Language (DSDL). The protocol has been shown to be implementable in less than 1000 logical lines of code. [22]

DSDL is ideologically similar to the interface description language used in ROS, except that it introduces additional static constraints in order to render the solution suitable for real-time high-integrity embedded systems. The similarity prompted some developers to interface ROS with Cyphal using automated translation layers. [10] [23]

Core principles

The protocol is built around the following core design principles that are intended to ensure that the solution is well-suited for modern complex safety-critical vehicular systems.

Transport layer

Cyphal/CAN

The CAN transport is built on top of CAN and CAN FD using 29-bit identifiers. The CAN payload includes a fixed-size overhead of one byte per frame for the needs of the transport layer. [21]

Cyphal/UDP

The Cyphal/UDP transport has been proposed for real-time Ethernet-based vehicular networks. The design is said to be influenced by AFDX, DDS/RTPS, and SOME/IP. [20]

Standard data types

Like other similar technologies, Cyphal provides a library of common data types, managed and curated by the protocol maintainers, that are intended to address certain common issues in popular applications. [24] These data types supplement vendor-specific or application-specific data types defined by adopters, much like a programming language would normally define a standard library to be relied upon by software developed by the user. The protocol specification provides a set of rules intended to avoid conflicts and enhance interoperability of data types defined by independent vendors. [25]

Related Research Articles

<span class="mw-page-title-main">OSI model</span> Model of communication of seven abstraction layers

The Open Systems Interconnection (OSI) model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.

<span class="mw-page-title-main">Profibus</span> Communications protocol

Profibus is a standard for fieldbus communication in automation technology and was first promoted in 1989 by BMBF and then used by Siemens. It should not be confused with the Profinet standard for Industrial Ethernet. Profibus is openly published as type 3 of IEC 61158/61784-1.

Modbus or MODBUS is a client/server data communications protocol in the application layer. It was originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network.

A vehicle bus is a specialized internal communications network that interconnects components inside a vehicle. In electronics, a bus is simply a device that connects multiple electrical or electronic devices together. Special requirements for vehicle control such as assurance of message delivery, of non-conflicting messages, of minimum time of delivery, of low cost, and of EMF noise resilience, as well as redundant routing and other characteristics mandate the use of less common networking protocols. Protocols include Controller Area Network (CAN), Local Interconnect Network (LIN) and others. Conventional computer networking technologies are rarely used, except in aircraft, where implementations of the ARINC 664 such as the Avionics Full-Duplex Switched Ethernet are used. Aircraft that use AFDX include the B787, the A400M and the A380. Trains commonly use Ethernet Consist Network (ECN). All cars sold in the United States since 1996 are required to have an On-Board Diagnostics connector, for access to the car's electronic controllers.

Aeronautical Radio, Incorporated (ARINC), established in 1929, was a major provider of transport communications and systems engineering solutions for eight industries: aviation, airports, defense, government, healthcare, networks, security, and transportation. ARINC had installed computer data networks in police cars and railroad cars and also maintains the standards for line-replaceable units.

<span class="mw-page-title-main">RapidIO</span> High-speed interconnect technology

The RapidIO architecture is a high-performance packet-switched electrical connection technology. It supports messaging, read/write and cache coherency semantics. Based on industry-standard electrical specifications such as those for Ethernet, RapidIO can be used as a chip-to-chip, board-to-board, and chassis-to-chassis interconnect.

A fieldbus is a member of a family of industrial digital communication networks used for real-time distributed control. Fieldbus profiles are standardized by the International Electrotechnical Commission (IEC) as IEC 61784/61158.

The Data Distribution Service (DDS) for real-time systems is an Object Management Group (OMG) machine-to-machine standard that aims to enable dependable, high-performance, interoperable, real-time, scalable data exchanges using a publish–subscribe pattern.

Avionics Full-Duplex Switched Ethernet (AFDX), also ARINC 664, is a data network, patented by international aircraft manufacturer Airbus, for safety-critical applications that utilizes dedicated bandwidth while providing deterministic quality of service (QoS). AFDX is a worldwide registered trademark by Airbus. The AFDX data network is based on Ethernet technology using commercial off-the-shelf (COTS) components. The AFDX data network is a specific implementation of ARINC Specification 664 Part 7, a profiled version of an IEEE 802.3 network per parts 1 & 2, which defines how commercial off-the-shelf networking components will be used for future generation Aircraft Data Networks (ADN). The six primary aspects of an AFDX data network include full duplex, redundancy, determinism, high speed performance, switched and profiled network.

ARINC 429, the "Mark 33 Digital Information Transfer System (DITS)," is the ARINC technical standard for the predominant avionics data bus used on most higher-end commercial and transport aircraft. It defines the physical and electrical interfaces of a two-wire data bus and a data protocol to support an aircraft's avionics local area network.

EtherCAT is an Ethernet-based fieldbus system developed by Beckhoff Automation. The protocol is standardized in IEC 61158 and is suitable for both hard and soft real-time computing requirements in automation technology.

Sercos III is the third generation of the Sercos interface, a standardized open digital interface for the communication between industrial controls, motion devices, input/output devices (I/O), and Ethernet nodes, such as PCs. Sercos III applies the hard real-time features of the Sercos interface to Ethernet. It is based upon and conforms to the Ethernet standard. Work began on Sercos III in 2003, with vendors releasing first products supporting it in 2005.

<span class="mw-page-title-main">UniPro</span> High-speed interface technology

UniPro is a high-speed interface technology for interconnecting integrated circuits in mobile and mobile-influenced electronics. The various versions of the UniPro protocol are created within the MIPI Alliance, an organization that defines specifications targeting mobile and mobile-influenced applications.

ARINC 818: Avionics Digital Video Bus (ADVB) is a video interface and protocol standard developed for high bandwidth, low-latency, uncompressed digital video transmission in avionics systems. The standard, which was released in January 2007, has been advanced by ARINC and the aerospace community to meet the stringent needs of high performance digital video. The specification was updated and ARINC 818-2 was released in December 2013, adding a number of new features, including link rates up to 32X fibre channel rates, channel-bonding, switching, field sequential color, bi-directional control and data-only links.

<span class="mw-page-title-main">CANaerospace</span>

CANaerospace is a higher layer protocol based on Controller Area Network (CAN) which has been developed by Stock Flight Systems in 1998 for aeronautical applications.

<span class="mw-page-title-main">OpenSafety</span> Industrial safety communications protocol

openSAFETY is a communications protocol used to transmit information that is crucial for the safe operation of machinery in manufacturing lines, process plants, or similar industrial environments. Such information may be e.g. an alert signal triggered when someone or something has breached a light curtain on a factory floor. While traditional safety solutions rely on dedicated communication lines connecting machinery and control systems via special relays, openSAFETY does not need any extra cables reserved for safety-related information. It is a bus-based protocol that allows for passing on safety data over existing Industrial Ethernet connections between end devices and higher-level automation systems – connections principally established and used for regular monitoring and control purposes. Unlike other bus-based safety protocols that are suitable for use only with a single or a few specific Industrial Ethernet implementations and are incompatible with other systems, openSAFETY works with a wide range of different Industrial Ethernet variants.

RTP-MIDI is a protocol to transport MIDI messages within Real-time Transport Protocol (RTP) packets over Ethernet and WiFi networks. It is completely open and free, and is compatible both with LAN and WAN application fields. Compared to MIDI 1.0, RTP-MIDI includes new features like session management, device synchronization and detection of lost packets, with automatic regeneration of lost data. RTP-MIDI is compatible with real-time applications, and supports sample-accurate synchronization for each MIDI message.

Avnu Alliance is a consortium of member companies working together to create an interoperable ecosystem of low-latency, time-synchronized, highly reliable networking devices using the IEEE open standard, Time-Sensitive Networking (TSN) and its Pro AV networking protocol, Milan. Avnu Alliance creates comprehensive certification programs to ensure interoperability of network devices. In the Professional Audio Video (AV) industry, Alliance member companies worked together to develop Milan: a standards-based, user-driven deterministic network protocol for professional media, that through certification, assures devices will work together at new levels of convenience, reliability, and functionality. Milan™ is a standards-based deterministic network protocol for real time media. Avnu Members may use the Avnu-certified or Milan-certified logo on devices that pass the conformance tests from Avnu. Not every device based on AVB or TSN is submitted for certification to the Avnu Alliance. The lack of the Avnu logo does not necessarily imply a device is incompatible with other Avnu-certified devices. The Alliance, in conjunction with other complimentary standards bodies and alliances, provides a united network foundation for use in professional AV, automotive, industrial control and consumer segments.

References

  1. "Open technology for real-time communications in cyber-physical systems".
  2. "About OpenCyphal" . Retrieved 28 February 2020.
  3. 1 2 3 "UAVCAN - Kvaser - Advanced CAN Solutions" . Retrieved 16 October 2019.
  4. "Drones discuss | UAVCAN - CAN bus for UAV". groups.google.com/forum/#!topic/drones-discuss. Retrieved 27 February 2020.
  5. Meier, Lorenz (2017). Dynamic Robot Architecture for Robust Realtime Computer Vision (Thesis). ETH Zurich. doi:10.3929/ethz-a-010874068. hdl:20.500.11850/129849.
  6. "ArduPilot Developer | CAN bus and UAVCAN protocol". ardupilot.org. Retrieved 27 February 2020.
  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; Stenius, Ivan; Bore, Nils; Severholt, Josefine; Ljung, Carl; Torroba Balmori, Ignacio (2019). "Towards a Cyber-Physical System for Hydrobatic AUVs". OCEANS 2019 - Marseille. pp. 1–7. doi:10.1109/OCEANSE.2019.8867392. ISBN   978-1-7281-1450-7. S2CID   204700489.
  9. "Archived copy" (PDF). Archived from the original (PDF) on 28 February 2020. Retrieved 28 February 2020.{{cite web}}: CS1 maint: archived copy as title (link)
  10. 1 2 "GitHub - MonashUAS/Canros: UAVCAN to ROS interface". GitHub . 5 April 2022.
  11. "All new 2019 VESC-Tool release". 8 February 2019.
  12. 1 2 "UAVCAN v1 is now Cyphal". OpenCyphal Forum. 25 March 2022. Retrieved 13 October 2022.
  13. 1 2 "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. "OpenCyphal Forum". OpenCyphal Forum. Retrieved 25 April 2024.
  16. "NXP Semiconductors is pleased to support UAVCAN V1.0". 9 December 2019.
  17. "Dronecode | Leading open-source components for UAVs". www.dronecode.org. Retrieved 27 February 2020.
  18. "Stockholm Summit recap". OpenCyphal Forum. 5 October 2018. Retrieved 13 October 2022.
  19. "OlliW's Bastelseiten » UC4H: UAVCAN for Hobbyists".
  20. 1 2 "Alternative transport protocols in UAVCAN". 11 January 2019.
  21. 1 2 Specification opencyphal.org
  22. "Compact Cyphal/CAN v1 in C". GitHub . 22 November 2021.
  23. "Our first ROS2 UAVCAN (PyCyphal) publisher and service nodes". OpenCyphal Forum. 12 April 2022. Retrieved 13 October 2022.
  24. "Regulated DSDL definitions". GitHub . 16 November 2021.
  25. "Data type regulation policy and membership fees". 8 December 2019.