This post is co-authored by Scott Dixon @scottdixon and Pavel Kirienko, long-time maintainer and BDFL respectively.
As most of you know by now, there has been a fork of UAVCAN v0 codebases by a new open source project, DroneCAN. This new project has agreed to take on the maintenance and continued development of the UAVCAN v0 specification and the UAVCAN v0 tools and reference implementations. The current state where uavcan.org and uavcan · GitHub are not the definitive places to find UAVCAN v0 is not sustainable and so we, the UAVCAN maintainers, have decided to embrace DroneCAN stewardship of the UAVCAN v0 protocol and to rebrand the UAVCAN project as an umbrella for development and promotion of technologies based on UAVCAN v1. Furthermore, to reduce confusion, we will rename the UAVCAN v1 protocol to Cyphal* and will call the tools and reference implementations developed in support of Cyphal, OpenCyphal†.
We regret the confusion this transition period has caused as we regret that the v1 effort was not welcomed by the existing user base. V0, and now v0.5 (which is the CAN-FD variant of v0), was always targeted to the simplest use cases and optimized for consumer UAVs and robotics. V1 was an effort to elevate the protocol even as the UAV industry is rising from a dedicated base of enthusiasts and academics into an industry. It was an important step forward in terms of interoperability and formalism and we hope DroneCAN will use the v1 specification as a roadmap for improving the wire-level protocol and increasing interoperability through the same data type evolution features v1 introduced.
Cyphal starts at this end. It brings the lessons learned from building a protocol for deeply embedded software, up to sophisticated robotics systems. It sets a roadmap for a future where Ethernet technologies are ubiquitous even in the hardest of real-time systems and the most critical of safety functions. It proposes an audacious concept of “lab-bench to production” where the communication protocol used to experiment, prototype, and test UAVs, advanced automotive systems, and other robotics evolves with the project to become part of the deployed system. The OpenCyphal project will incorporate lessons from the wild success of Ethernet and IP networking technologies, the economy of CAN bus technologies, and the rigor of aerospace methodologies. We present figure 1, “A Brief History of Serial Protocols” to provide the context for Cyphal as we see it and to show our expectation of a slow deprecation of CAN technologies in favor of new IP networking technologies over the coming decade.
figure 1 – a brief history of serial protocols
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, v1 was conceived.
m. 10 BASE T1S is added to IEEE 802.3 defining half-duplex, two-wire, multi-drop ethernet media with PLCA (Physical Layer 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. (today) UAVCAN v1 is renamed Cyphal. It promises to provide TSN/CAN interoperability and to be the first messaging protocol defined for 10 BASE T1S.
House cleaning
What are the next steps then? Starting immediately the UAVCAN community and maintainers will do some housecleaning to improve the overall health of the organization:
- Start a new GitHub org named UAVCAN-garage which will contain dead projects, dead-end experiments, and new ideas not ready for the upstream project.
- Cleanup of the UAVCAN GitHub org will then commence:
- Move abandoned projects to the garage.
- Move incomplete projects without active maintainers to the garage.
- Scrub, triage, and bug-bash the remaining issues in the retained projects.
- Remove all v0 branches where they are duplicated by DroneCAN repositories.
- Write contributor standards to define things like:
- How to become a maintainer
- How a sub-project gets started
- How a sub-project gets promoted from the garage
- Etc
- Create a new Cyphal logo and do general rebranding across all UAVCAN sites and assets.
Cyphal 1.x development
With this reset complete we will begin the definition of Cyphal 1.x (where 1.0 is the existing UAVCAN v1 specification, renamed):
- Complete design work on Cyphal/UDP.
- Start design work on a UDP-CAN routing amendment.
- Develop a roadmap for additional Cyphal amendments including:
- System health standards and interfaces
- Software load and security standards and interfaces
- CAN-FD physical layer standard for avionics
- Cyphal TSN amendment
- Develop Cyphal as a ROS 2 middleware
- Define an independent Cyphal-Avionics standard for systems like:
- Actuation systems
- Electrical systems
- Propulsion systems
- Air speed data systems
- Etc
- Also on the roadmap will be developing a Cyphal amendment for use on 10-base T1S, half-duplex, shared media. This will be, from a topological view, a drop-in replacement for CAN bus, MODBUS, and other shared media networking technologies.
On its face, this is just a renaming and cleanup exercise so the project is not, in any way, throwing away what it has built in UAVCAN v1. Fundamentally, however, Cyphal will shift from a protocol that was a better I2C, to a protocol that ties together the sub-systems of modern robotics systems, automotive autonomy functions, air mobility vehicles, package delivery drones, and any other cyber-physical system utilizing intelligent sensing and actuation components.
* What’s in a name? We struggled with a new name for this protocol wanting to avoid obscure acronyms (UAVCAN anyone?) and completely random nouns (Nunavut anyone?). Cyphal is an invented word; a portmanteau of Cyber and Hyphal. The former references cyber-physical systems which is a generalization of the type of system this new protocol is optimized for. The latter describes Hypha, branching structures found in the fungal symbionts of mycorrhizal networks. And by that circuitous route we create a name meaning a cyber-physical, low-level, and tightly integrated network.
† Why call Cyphal a standard and OpenCyphal a project? Cyphal will always be an abstract standard that can be implemented from scratch given only the specification. OpenCyphal is an open-source implementation of parts of this specification to facilitate the “lab-bench” side of Cyphal’s “lab-bench to production” design tenet. We welcome commercial development on top of the specification and other open-source projects to replicate our work. In a future where there are many “Cyphal stacks” available, OpenCyphal will serve as a brand name for the software written while developing the abstract specification.
