This section covers basic concepts that govern development and maintenance of the specification. The actual specification is contained in the following sections.
Core design goals
The list of core design goals below helps to understand the basic concepts of UAVCAN and the motivation behind them.
- Democratic network - since the network does not require a master node (bus controller), it has no single point of failure.
- Nodes shall be able to exchange long payloads - typical use cases for a vehicle bus include the need to transfer sets of related parameters (e.g., GNSS solution, 3D vectors, etc.), where each parameter cannot be used independently. Such a set of parameters often does not fit into a single CAN frame, hence the need to split it into several CAN frames with a subsequent reassembly process on the receiving nodes.
- Support for redundant interfaces and redundant nodes - it is a common requirement for safety-concerned applications.
- High throughput, low latency communication - many applications require high-frequency, hard real-time control loops, which necessitates the need for a low-latency, high-throughput communication method.
- Simple logic, low computational requirements - UAVCAN targets a wide variety of embedded systems, from high-performance embedded on-board computers for intensive data processing (e.g., a high-performance Linux-powered machine) to extremely resource-constrained microcontrollers. The latter imposes severe restrictions on the amount of logic needed to implement the protocol.
- Common high-level functions should be clearly defined - UAVCAN defines standard services and messages for common high-level functions, such as network discovery, node configuration, node firmware update, node status monitoring (which naturally grows into a vehicle-wide health monitoring), network-wide time synchronization, dynamic node ID allocation (a.k.a. plug-and-play), etc.
- Open specification and reference implementation - the UAVCAN specification is open and freely available for anyone; the reference implementations are distributed under the terms of the MIT License.
Specification update and approval process
UAVCAN development team is charged with advancing the specification based on the input from adopters gathered via the mailing list, where everyone can contribute to the discussion.
The set of standard DSDL definitions is one of the cornerstone concepts of the specification. Within the same major version, it can be extended only in the following ways:
- A new data type can be added, possibly with default data type ID, as long as the default data type ID doesn’t conflict with one of the existing data types.
- An existing data type can be modified, as long as the modification doesn’t break backward compatibility.
- An existing data type can be declared deprecated. Once declared deprecated, the data type will be maintained for at least two more years before its default data type ID can be reused for an incompatible data type. Deprecation will be announced via the mailing list, and indicated in the form of a comment within the DSDL definition.
Link to the repository containing the set of default DSDL definitions can be found on the contacts page.
The UAVCAN specification contains references to the following sources:
- CiA 801 - Application note - Automatic bit rate detection.
- IEEE 754 - Standard for binary floating-point arithmetic.
- ISO 11898-1 - Controller area network (CAN) - Part 1: Data link layer and physical signaling.
- ISO 11898-2 - Controller area network (CAN) - Part 2: High-speed medium access unit.
- ISO/IEC 10646:2014 - Universal Coded Character Set (UCS).
- ISO/IEC 14882:2014(E) - Programming Language C++.
- “Implementing a Distributed High-Resolution Real-Time Clock using the CAN-Bus”, M. Gergeleit and H. Streich.
- “In Search of an Understandable Consensus Algorithm (Extended Version)”, Diego Ongaro and John Ousterhout.