What is UAVCAN?

UAVCAN 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 name stands for Uncomplicated Application-level Vehicular Computing And Networking.

UAVCAN is a standard 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.

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 UAVCAN?

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, you can check out the FAQ or bring them to the forum.

Pick one of the free open source implementations (MIT licensed) for use in your application:

Library Transports Language Applications Status
Libcanard UAVCAN/CAN C11 Embedded Released
PyUAVCAN Any Python HMI, scripting Released
Libuavcan Any C++11 Embedded Work-in-progress, ETA 2021Q4

None of these implementations suits your needs? Write your own! UAVCAN is a very simple protocol; an experienced developer can easily create a customized implementation from scratch to address the unique needs of their application.

These open source tools will help you design, develop, and maintain your UAVCAN-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.uavcan.org.
  • Yakut — a simple CLI tool for diagnostic and management of UAVCAN networks.
  • Yukon (work-in-progress) — a rich IDE for observing, debugging, and interacting with a UAVCAN bus. This product is currently under active development; ETA 2021Q4.

Also, third-party solutions may be found on GitHub.

Please reference UAVCAN in scientific or technical publications.

Why do I need UAVCAN?

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

UAVCAN 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 UAVCAN 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: UAVCAN 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.). UAVCAN provides a specialized domain-specific language for this purpose titled DSDL.

Fault-tolerance: UAVCAN 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: UAVCAN 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, UAVCAN 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.

UAVCAN 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 UAVCAN 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 UAVCAN 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, UAVCAN 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 + 1 + 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.

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

Scope of UAVCAN

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

Who is behind UAVCAN?

The UAVCAN Consortium is a non-profit organization established to support, promote and standardize the technology, and expand the UAVCAN ecosystem. Any entity that leverages UAVCAN is welcome to join the organization to take part in shaping the future of the technology and stay ahead of the curve. The following benefits are available only to the members of the Consortium:

  • Use the official UAVCAN Conformity Mark with hardware and software products that pass the conformance test.
  • Include vendor-specific or domain-specific data types and network service definitions to the official public regulated data types repository.
  • Directly influence the future of the technology.

Learn more and apply to become a member.


Development activity

teamplayer3 opened a pull request “own crc impl” at UAVCAN/uavcan.rs
Oct 18
teamplayer3 created a new branch “alex/own_crc” at UAVCAN/uavcan.rs
Oct 18
Cherish-Gww forked UAVCAN/yakut
Oct 18
csrg3243 forked UAVCAN/pyuavcan
Oct 15
teamplayer3 opened an issue “API rework” at UAVCAN/uavcan.rs
Oct 14
davidlenfesty opened a pull request “Migrate v1 branch to master” at UAVCAN/uavcan.rs
Oct 14
davidlenfesty created a new branch “v0” at UAVCAN/uavcan.rs
Oct 14
davidlenfesty closed a pull request “Set up basic CI” at UAVCAN/uavcan.rs
Oct 14
pavel-kirienko created a new tag “0.7.0” at UAVCAN/yakut
Oct 13
davidlenfesty opened a pull request “Set up basic CI” at UAVCAN/uavcan.rs
Oct 13
davidlenfesty created a new branch “david/ci” at UAVCAN/uavcan.rs
Oct 13

Consortium members and adopters