Cyphal interfaces avionics and on-board computing systems in manned and unmanned aircraft

Image by Katla Aero

Cyphal enables real-time distributed computing in bleeding-edge robotics

Image by Revolve NTNU Trondheim

Cyphal is an open interoperability standard for off-the-shelf equipment

Image by Hitec RCD

Cyphal runs distributed avionics in modern spacecraft

Previous Next

What is Cyphal?

Cyphal is an open technology for real-time intravehicular distributed computing and communication based on modern networking standards (Ethernet, CAN FD, etc.). It was created to address the challenge of on-board deterministic computing and data distribution in next-generation intelligent vehicles: manned and unmanned aircraft, spacecraft, robots, and cars.

The underlying Cyphal Specification is open to everyone, and it will always remain this way. No licensing or approval of any kind is necessary for its implementation, distribution, or use.

Cyphal was known as UAVCAN before 2022.

Features

• Designed for complex, high-integrity, real-time vehicular computing systems.
• Publish/subscribe and request/response (RPC) exchange semantics.
• Specialized interface description language provides rich zero-cost interface abstractions and facilitates service-oriented design.
• Lightweight — implementable from scratch in ca. 1000 logical lines of code; cheap to verify and validate.
• Peer-to-peer network — no bus master, no single point of failure.
• Modular redundancy for fault-tolerant systems with automatic fail-over.
• Different transport-layer protocols (Ethernet, CAN, etc.), including heterogeneous transport redundancy.
• High-quality open source reference implementations are freely available under the MIT license.

How do I use Cyphal?

First, read the Guide. To learn the technical details, read the Specification. Familiarize yourself with the regulated DSDL repository. If you have questions or feedback, bring them to the forum.

The OpenCyphal project provides MIT-licensed implementations of the Cyphal technology (other implementations of the Cyphal stack are available from third parties):

These open source tools will help you design, develop, and maintain your Cyphal-based application:

• Nunavut — a Python library and a CLI tool for transcompiling DSDL definitions into C/C++/Python/etc. A web-GUI is available at nunaweb.opencyphal.org.
• Yakut — a simple CLI tool for diagnostic and management of Cyphal networks.
• Yukon — a rich GUI tool for observing, debugging, and interacting with a Cyphal bus.

Please reference Cyphal in scientific or technical publications.

Why do I need Cyphal?

Modern vehicles are becoming increasingly complex as they implement advanced autonomy and safety capabilities. Most of the complexity is concentrated around the on-board software which largely defines the functional capabilities of the vehicle, yielding the concept of a software-defined vehicle. This is especially true for unmanned transport.

Holistic approaches to the design of the on-board vehicular intelligence (or any sophisticated system in general) are complicated by the limitations of the human mind, so distribution is applied widely, where the resulting complex system is composed of subsystems and components whose lesser complexity is hidden behind well-defined abstract interfaces. While distributed computing is not a new concept, its application for vehicular intelligence may be hindered by the requirements of functional safety and determinism.

The high intrinsic complexity of existing distributed computing technologies is due to a wide range of supported usage scenarios and types of interaction, only a small part of which is relevant for the application area of interest to us. We propose that this statement is true even for specialized prior art technologies (like DDS, ROS, SOME/IP). Careful rethinking of the basic principles and core requirements of the data distribution platform allowed us to achieve a more balanced trade-off between its intrinsic complexity (and, as a result, the cost of verification and validation) and its ability to express powerful abstractions (and, therefore, allowing the designer to implement more complex behaviors cheaply).

Cyphal is a response to the unmet demand for a distributed computing technology that would allow the designer to hide the complexity of the components of the on-board intelligence behind well-formalized network services while not compromising on functional safety and the costs of verification and validation. Its design rests on the following core values:

Simplicity is paramount for high-integrity and safety-critical systems as it reduces the verification and validation efforts. The complexity of Cyphal scales together with its application: unsophisticated components (nodes) of the distributed computing system may implement the protocol in less than a thousand lines of code from scratch. The only mandatory application-level function that shall be supported by all implementations is the Heartbeat message; the broader spectrum of optional protocol capabilities remains at the disposal of the implementer, if needed.

High-level abstractions: Cyphal allows the designer to construct robust service-oriented interfaces between components of the distributed computing system, taking into account fault-tolerance and real-time constraints. The definitions of such interfaces focus solely on the needs of the application and delegate impertinent lower-level details to the protocol (network state machines, distributed state management, data serialization, etc.). Cyphal provides a specialized domain-specific language for this purpose titled DSDL.

Fault-tolerance: Cyphal is a decentralized peer-to-peer network with built-in support for modular redundancy. Under certain reasonable assumptions, the protocol is compatible with unreliable networks where packet loss is possible due to short-term destructive environmental influences.

Determinism: Cyphal is designed to satisfy the requirements of real-time deterministic embedded systems. The resource ceiling (time, memory) is always trivially predictable and provable.

To meet these values, Cyphal makes reasonable assumptions about the system. The first such assumption is that the service curve of the underlying transport network is well-characterized, and the probability of packet loss in the absence of adverse influences from the outside environment (e.g., electromagnetic interference or faulty connector) is zero. The latter means that losses cannot arise as a result of processes occurring within the network, such as a queue overflow, but short-term disturbances caused by external factors such as electromagnetic interference may occur. Packet losses caused by such external disturbances are mitigated by tunable duplication of transfers. This assumption is valid for deterministic on-board networks.

Cyphal is nearly stateless — the protocol is designed to drastically minimize the shared state compared to prior art technologies. As a result, the state space of the distributed system is reduced; its analysis, implementation, and testing are simplified. Participants of the distributed system make virtually no assumptions about the state of their collaborators. Traditional pub-sub frameworks define an explicit subscription establishment procedure where the subscriber informs the publisher of its interest in specific data (SOME/IP, DDS, virtually all MQ*, etc.), whereas in Cyphal the publisher blindly sends messages to the network, allowing interested agents to accept or ignore them.

The latter circumstance would have hampered scalability if not for the extensive reliance on hardware packet filtering and pattern matching. Other commonly used protocols (with notable exclusion of AFDX, ARINC 664) often overlook the fact that modern high-speed networking hardware provides powerful means of automatic traffic policing (e.g., Ethernet NICs, switches, CAN controllers, etc). Reasonable exploitation of this fact enables radical simplification of the transport layer.

The absence of explicitly synchronized states between collaborators (between a publisher and a subscriber or between an RPC client and its server) allows a newly joined network participant to start performing its tasks immediately, without any mandatory registration procedures, service discovery, etc. This is important when analyzing failure scenarios where a critical device is briefly shut down and then reconnected to the network (e.g., due to a power surge, lightning strike, software or hardware defect, etc.).

Another assumption is that the distributed computing system is typically configured statically. First, the configuration of vehicular systems is rarely subject to radical changes in the field, which allows Cyphal to avoid the complexity and failure case analysis of dynamic reconfiguration in most cases. This, however, does not mean that dynamic field reconfiguration (e.g., plug-and-play devices) is not supported (it is useful in research and some limited subset of production systems), but it means that dynamic reconfiguration capabilities belong to the optional parts of the protocol which can be omitted to simplify the validation and verification of safety-critical applications.

Second, Cyphal always provides a well-defined guaranteed resource ceiling for any part of the system at the design stage. Data types defined using the previously mentioned DSDL language always have an upper limit on the size of any variable-length data field, which means that the worst-case data transfer latency, worst-case (de-)serialization time, and, in general, the worst-case processing time can be determined statically. A practical example is shown below:

# A generic displacement amplitude spectrum representation. Documentation is omitted for brevity.
uavcan.si.unit.frequency.Scalar.1.0 frequency_step
float32[<=1024] peak_abs_amplitude  # [meter]
# Observe that the array length is bounded. It is not possible to define an unbounded data type.
@assert _offset_.max == 8 * (4 + 2 + 1024 * 4) # Validate the layout.

At the transport layer, bounded resource utilization and timely data processing are facilitated by explicit upper bounds on all protocol resources. For instance, the maximum number of publish-subscribe channels in the system is limited (the limit, however, is expected to be sufficient for any application), as well as the number of network nodes. The specification discusses different approaches to implementing the transport layer with an assessment of their asymptotic complexity.

At the application layer, the user defines custom network services and data types (using the DSDL domain-specific language) for use in pub-sub or RPC links. For common tasks (like diagnostics, file transfer, logging, configuration management, etc.) there is no need to design custom network services because the corresponding definitions are provided by the standard library of network services.

Cyphal is also intended to serve as a foundation for narrowly specialized domain-specific application-layer standards (like standard USB classes, CANopen profiles, DDS FACE, etc.).

Adopting Cyphal might seem like a little paradigm shift for an engineer experienced with prior art solutions, but our experience and understanding of the field give us confidence that it as a necessary step to adapt to the growing sophistication of modern software-defined vehicles.