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

In the seven-layer OSI model of computer networking, the physical layer or layer 1 is the first and lowest layer: the layer most closely associated with the physical connection between devices. The physical layer provides an electrical, mechanical, and procedural interface to the transmission medium. The shapes and properties of the electrical connectors, the frequencies to transmit on, the line code to use and similar low-level parameters, are specified by the physical layer.

A Berkeley (BSD) socket is an application programming interface (API) for Internet domain sockets and Unix domain sockets, used for inter-process communication (IPC). It is commonly implemented as a library of linkable modules. It originated with the 4.2BSD Unix operating system, which was released in 1983.

<span class="mw-page-title-main">CAN bus</span> Standard for serial communication between devices without host computer

A controller area network (CAN) is a vehicle bus standard designed to enable efficient communication primarily between electronic control units (ECUs). Originally developed to reduce the complexity and cost of electrical wiring in automobiles through multiplexing, the CAN bus protocol has since been adopted in various other contexts. This broadcast-based, message-oriented protocol ensures data integrity and prioritization through a process called arbitration, allowing the highest priority device to continue transmitting if multiple devices attempt to send data simultaneously, while others back off. Its reliability is enhanced by differential signaling, which mitigates electrical noise. Common versions of the CAN protocol include CAN 2.0, CAN FD, and CAN XL which vary in their data rate capabilities and maximum data payload sizes.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. Message-oriented middleware is in contrast to streaming-oriented middleware where data is communicated as a sequence of bytes with no explicit message boundaries. Note that streaming protocols are almost always built above protocols using discrete messages such as frames (Ethernet), datagrams (UDP), packets (IP), cells (ATM), et al.

<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.

<span class="mw-page-title-main">Modbus</span> Serial communications protocol

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

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 Avionics Full-Duplex Switched Ethernet (AFDX) include the Boeing 787, the Airbus A400M and the Airbus 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.

The Mobile Application Part (MAP) is an SS7 protocol that provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to users. The Mobile Application Part is the application-layer protocol used to access the Home Location Register, Visitor Location Register, Mobile Switching Center, Equipment Identity Register, Authentication Centre, Short message service center and Serving GPRS Support Node (SGSN).

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.

<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.

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.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.