This is an incremental FAQ aimed at beginners to the Cyphal ecosystem. It attempts to introduce the framework to newcomers and clarify common misconceptions without going into technical detail. For a more in-depth tutorial, refer to The Guide.
What is Cyphal?
Cyphal is an open-source framework for intravehicular real-time communication and distributed computing. Simply put, it allows different electronics onboard vehicles to communicate effectively. It is designed for use in unmanned and manned aircraft, cars, spacecraft, and other robotic applications.
What does the name mean?
When it was first created, Cyphal was designed for communication between electronics onboard Unmanned Aerial Vehicles (UAVs) using the Controller Area Network (CAN) bus. Since then, Cyphal has grown to include many other robotic use cases and other networking transports (including Ethernet and serial communication).
What is DSDL?
DSDL stands for data structure description language. It’s a human-readable language for describing the contents of Cyphal messages. Here’s an example of the Heartbeat message (simplified for brevity):
uint16 MAX_PUBLICATION_PERIOD = 1 # [second]
uint16 OFFLINE_TIMEOUT = 3 # [second]
uint32 uptime # [second]
Health.1.0 health
Mode.1.0 mode
uint8 vendor_specific_status_code
Why are there multiple standards?
The Cyphal Specification itself describes the transport layer - how messages sent by an application are serialized into a byte stream, packed into packets depending on the underlying networking technology (such as CAN or Ethernet), and sent over the network before being deserialized. It also covers how different message topics (called subjects and services) are designed and configured. The application layer - the contents of messages and what data types should be used for different vehicular applications - are left to other standards. Some of these standards (such as UDRAL) are publicly developed and maintained by interested parties, while others are privately developed by users. The exception is a small set of services common to all networks - such as node status, node configuration, file transfer, time synchronization, and a few others, which are defined in the main Specification.
UDRAL, the Cyphal drone application layer specification, defines a set of messages and services intended for use on unmanned aerial vehicles, including multicopters, airplanes, and VTOL vehicles. It specifies messages for common requirements on UAVs, as well as what services must be provided by different components, and how those services should be configured and linked. This is where you’ll find messages for controlling ESCs and reading GNSS data.
UCANPHY, the Cyphal Controller Area Network PHYsical layer specification, defines how electronics should be wired for robust and fault-tolerant communication on a Controller Area Network (CAN bus). This includes recommended connectors, maximum wire length, and bitrates for classic CAN and CAN-FD networks.