# Specification

**URL:** https://forum.opencyphal.org/c/dev/spec/15.md

[Latest](https://forum.opencyphal.org/latest.md) · [Categories](https://forum.opencyphal.org/categories.md)

---

## [About the Specification category](https://forum.opencyphal.org/t/about-the-specification-category/739)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 0

</div>

Topics specific to discussions of the core UAVCAN specification. On-topic is: Clarifying questions about the core specification. Questions or concerns about implementing the core specification. Proposed modifications, …

---

## [Proposal for a v1.1 extension to DSDL](https://forum.opencyphal.org/t/proposal-for-a-v1-1-extension-to-dsdl/2891)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 3\
**Last updated:** [October 23, 2026, 12:32pm UTC](https://forum.opencyphal.org/t/proposal-for-a-v1-1-extension-to-dsdl/2891 "2026-10-23T12:32:31Z")

</div>

I’m looking into zero-cost types for DSDL (Automatically detect zero-cost types · Issue #48 · OpenCyphal/pydsdl · GitHub) One of the problems with this is you cannot have any variable length arrays. This will, invariabl…

---

## [Pattern-matchable topic name hashing -- an idea that might be useful in the future](https://forum.opencyphal.org/t/pattern-matchable-topic-name-hashing-an-idea-that-might-be-useful-in-the-future/2460)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 0\
**Last updated:** [April 12, 2026, 7:10pm UTC](https://forum.opencyphal.org/t/pattern-matchable-topic-name-hashing-an-idea-that-might-be-useful-in-the-future/2460 "2026-04-12T19:10:29Z")

</div>

While working on v1.1 spec draft proposal, I encountered in my notes an idea that didn’t make it into my proposed v1.1 design but it seems interesting enough to write it down in case we need to revisit it later. The cur…

---

## [Proposed DSDL spec simplifications for Cyphal v1.1](https://forum.opencyphal.org/t/proposed-dsdl-spec-simplifications-for-cyphal-v1-1/2449)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 6\
**Last updated:** [April 10, 2026, 4:58pm UTC](https://forum.opencyphal.org/t/proposed-dsdl-spec-simplifications-for-cyphal-v1-1/2449 "2026-04-10T16:58:50Z")

</div>

One of the core design goals of Cyphal is simplicity. Whenever we add a new feature, we must likewise consider if any of the old features remain necessary and whether the complexity that they introduce is justifiable, ot…

---

## [Improve the transfer-ID timeout](https://forum.opencyphal.org/t/improve-the-transfer-id-timeout/2375)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 3\
**Last updated:** [November 18, 2025, 9:04pm UTC](https://forum.opencyphal.org/t/improve-the-transfer-id-timeout/2375 "2025-11-18T21:04:43Z")

</div>

A while ago, while we were working toward the current beta specification, @scottdixon pointed out that the transfer-ID timeout is an odd item because it brings a rather arbitrarily-chosen default parameter into the speci…

---

## [V1.1 roadmap defined](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 7\
**Last updated:** [May 16, 2025, 2:13pm UTC](https://forum.opencyphal.org/t/v1-1-roadmap-defined/2382 "2025-05-16T14:13:50Z")

</div>

On the Friday May 9th, 2025 dev call we discussed several new features that would require additions to the specification and some, non-breaking, changes. There was a general consensus that this work would be better execu…

---

## [DBC signal multiplexing across multiple CAN frames for Cyphal?](https://forum.opencyphal.org/t/dbc-signal-multiplexing-across-multiple-can-frames-for-cyphal/2185)

<div class="topic-metadata">

**Author:** [@Sergey\_Andreev](https://forum.opencyphal.org/u/Sergey_Andreev)\
**Replies:** 5\
**Last updated:** [August 20, 2024, 5:14pm UTC](https://forum.opencyphal.org/t/dbc-signal-multiplexing-across-multiple-can-frames-for-cyphal/2185 "2024-08-20T17:14:43Z")

</div>

I have a use case of quite a long Cyphal message which is split across multiple CAN frames. Is it possible to parse such message by using DBC format, i.e. multiplexing of signals like for J1939 or CANOpen?

---

## [\[Cyphal/UDP\] Architectural issues caused by the dependency between the node's IP address and its identity](https://forum.opencyphal.org/t/cyphal-udp-architectural-issues-caused-by-the-dependency-between-the-nodes-ip-address-and-its-identity/1765)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 79\
**Last updated:** [May 14, 2024, 12:34am UTC](https://forum.opencyphal.org/t/cyphal-udp-architectural-issues-caused-by-the-dependency-between-the-nodes-ip-address-and-its-identity/1765 "2024-05-14T00:34:37Z")

</div>

At the last dev call, I mentioned that I wanted to discuss an architectural deficiency in the current working draft of the Cyphal/UDP transport specification that requires attention. The deficiency is not a major one and…

---

## [Proposal for a type manifest specification](https://forum.opencyphal.org/t/proposal-for-a-type-manifest-specification/2107)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 8\
**Last updated:** [May 6, 2024, 6:26pm UTC](https://forum.opencyphal.org/t/proposal-for-a-type-manifest-specification/2107 "2024-05-06T18:26:42Z")

</div>

When consuming large pools of Cyphal messages new problems arise that were not foreseen. Specifically, pydsdl and Nunavut currently collect and generate all types found under a given root namespace. This quickly becomes …

---

## [RFC: add array of ports](https://forum.opencyphal.org/t/rfc-add-array-of-ports/1878)

<div class="topic-metadata">

**Author:** [@Dima](https://forum.opencyphal.org/u/Dima)\
**Replies:** 2\
**Last updated:** [July 3, 2023, 12:31pm UTC](https://forum.opencyphal.org/t/rfc-add-array-of-ports/1878 "2023-07-03T12:31:50Z")

</div>

ARRAY OF PORTS I suggest adding a new term to section 6.8. uavcan.register of the specification. Let’s call it an array of ports or a group of ports. Problem description There are few cases where we need to handle a lar…

---

## [Cyphal-Config food for thought](https://forum.opencyphal.org/t/cyphal-config-food-for-thought/1848)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 0\
**Last updated:** [March 13, 2023, 5:17pm UTC](https://forum.opencyphal.org/t/cyphal-config-food-for-thought/1848 "2023-03-13T17:17:45Z")

</div>

This next in my “v1.x food-for-thought” series: I wonder if standardizing on YANG models as a way to configure Cyphal networks would make sense. This is especially pertinent given my desire to develop Cyphal/TSN as part …

---

## [Cyphal-Auth food for thought](https://forum.opencyphal.org/t/cyphal-auth-food-for-thought/1847)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 0\
**Last updated:** [March 13, 2023, 5:06pm UTC](https://forum.opencyphal.org/t/cyphal-auth-food-for-thought/1847 "2023-03-13T17:06:10Z")

</div>

Cyphal 1.0 will be GA soon (we’re just cleaning up some loose ends on the Beta and then it’s v1 forever) so I’ve been thinking a bit about V1.x in general and secure communications specifically. I’m not ready to post a l…

---

## [Reserved identifiers for diagnostic and debugging tools](https://forum.opencyphal.org/t/reserved-identifiers-for-diagnostic-and-debugging-tools/1833)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 1\
**Last updated:** [February 28, 2023, 12:45am UTC](https://forum.opencyphal.org/t/reserved-identifiers-for-diagnostic-and-debugging-tools/1833 "2023-02-28T00:45:07Z")

</div>

Section 5.2.1 of the Cyphal specification reads: … The two uppermost node-ID values are reserved for diagnostic and debugging tools; these node-ID values should not be used in fielded systems. This seems to create …

---

## [Cyphal/UDP redundancy](https://forum.opencyphal.org/t/cyphal-udp-redundancy/1822)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 3\
**Last updated:** [February 1, 2023, 12:03pm UTC](https://forum.opencyphal.org/t/cyphal-udp-redundancy/1822 "2023-02-01T12:03:35Z")

</div>

The current specification defines redundant transports abstractly and redundant CAN transports concretely. What is the story for UDP? It’s interesting because Cyphal/TSN can use 802.1CB to meet this requirement but I’m n…

---

## [DSDL v1.1: Introduce the concept of default field initialization and allow customizing this behavior per field](https://forum.opencyphal.org/t/dsdl-v1-1-introduce-the-concept-of-default-field-initialization-and-allow-customizing-this-behavior-per-field/1802)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 17\
**Last updated:** [December 16, 2022, 12:13am UTC](https://forum.opencyphal.org/t/dsdl-v1-1-introduce-the-concept-of-default-field-initialization-and-allow-customizing-this-behavior-per-field/1802 "2022-12-16T00:13:58Z")

</div>

Currently, the DSDL specification does not dedicate much attention to the default value initialization of DSDL fields. I suggest amending it by Cyphal v1.1 as follows: Define and require zero-initialization of primiti…

---

## [Community RFC process](https://forum.opencyphal.org/t/community-rfc-process/1750)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 0\
**Last updated:** [September 9, 2022, 7:12pm UTC](https://forum.opencyphal.org/t/community-rfc-process/1750 "2022-09-09T19:12:04Z")

</div>

I’ve opened a PR to the specification README that defines a community-driven RFC process. If you care about the rules for contributing to the Cyphal specification, as maintained by the OpenCyphal project, please review a…

---

## [Questions about the Time Synchronization in Specification](https://forum.opencyphal.org/t/questions-about-the-time-synchronization-in-specification/1562)

<div class="topic-metadata">

**Author:** [@xbron](https://forum.opencyphal.org/u/xbron)\
**Replies:** 4\
**Last updated:** [January 7, 2022, 3:55pm UTC](https://forum.opencyphal.org/t/questions-about-the-time-synchronization-in-specification/1562 "2022-01-07T15:55:30Z")

</div>

Hello Pavel, I try to understand how to implement the time synchronization in my application and I think that detailed explanation in uavcan.time.Synchronization data type description in Specification is useful, but I li…

---

## [Default extent considered harmful](https://forum.opencyphal.org/t/default-extent-considered-harmful/972)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 5\
**Last updated:** [November 9, 2020, 5:53pm UTC](https://forum.opencyphal.org/t/default-extent-considered-harmful/972 "2020-11-09T17:53:11Z")

</div>

I am proposing a change for the GA release of UAVCAN v1 where we remove the default extent specified in section 3.4.5.5 and change this section to read: By default, a definition is not sealed unless explicitly indicate…

---

## [Data type extensibility and composition](https://forum.opencyphal.org/t/data-type-extensibility-and-composition/827)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 20\
**Last updated:** [October 28, 2020, 4:06pm UTC](https://forum.opencyphal.org/t/data-type-extensibility-and-composition/827 "2020-10-28T16:06:20Z")

</div>

The ability to mutate data type definitions as the systems they describe evolve is essential because here on Earth there is no such thing as a stable design unless it is obsolete. Being designed for high-integrity deeply…

---

## [Removal of the physical layer specification](https://forum.opencyphal.org/t/removal-of-the-physical-layer-specification/895)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 1\
**Last updated:** [July 30, 2020, 9:36am UTC](https://forum.opencyphal.org/t/removal-of-the-physical-layer-specification/895 "2020-07-30T09:36:39Z")

</div>

@scottdixon proposed that we remove the physical layer specification chapter from the UAVCAN Specification document: As discussed on the dev call, the physical layer specification for CAN transports is significantly l…

---

## [Serialization example on page 32, section 3.7.5](https://forum.opencyphal.org/t/serialization-example-on-page-32-section-3-7-5/882)

<div class="topic-metadata">

**Author:** [@al.guryanow](https://forum.opencyphal.org/u/al.guryanow)\
**Replies:** 3\
**Last updated:** [July 22, 2020, 1:49am UTC](https://forum.opencyphal.org/t/serialization-example-on-page-32-section-3-7-5/882 "2020-07-22T01:49:21Z")

</div>

It seems to me that the serialization example on page 32 in section 3.7.5 contains an error. The value of ‘first’ is +48858, it’s binary representation is 1011\_1110\_1101\_1010. But because it’s declared as ‘truncated uint…

---

## [UAVCAN/CAN: CAN FD profile](https://forum.opencyphal.org/t/uavcan-can-can-fd-profile/867)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 1\
**Last updated:** [July 9, 2020, 5:54am UTC](https://forum.opencyphal.org/t/uavcan-can-can-fd-profile/867 "2020-07-09T05:54:51Z")

</div>

The alpha specification notably lacks coverage of the CAN FD parameters. In connection with the ongoing work on the UAVCAN Drone Profile there were proposals to use a fixed ratio of data/nominal bit rate of two. I think …

---

## [Proposed change to variable-length arrays](https://forum.opencyphal.org/t/proposed-change-to-variable-length-arrays/740)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 7\
**Last updated:** [March 6, 2020, 4:42pm UTC](https://forum.opencyphal.org/t/proposed-change-to-variable-length-arrays/740 "2020-03-06T16:42:29Z")

</div>

In the spirit of simplification over optimization I think we should change the default serialization behaviour of variable-length arrays and then introduce an advanced option to reenable the existing bandwidth-optimized …

---

## [YAGNI, KISS, and @union](https://forum.opencyphal.org/t/yagni-kiss-and-union/742)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 4\
**Last updated:** [February 13, 2020, 5:41pm UTC](https://forum.opencyphal.org/t/yagni-kiss-and-union/742 "2020-02-13T17:41:24Z")

</div>

I’d like to propose removing unions from the specification to reduce some complexity and to make the wire-level protocol easier to comprehend. The tagged union introduces a second, variable-length data construct which re…

---

## [Future Proposal: Featherweight Profile](https://forum.opencyphal.org/t/future-proposal-featherweight-profile/743)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 3\
**Last updated:** [February 4, 2020, 2:37pm UTC](https://forum.opencyphal.org/t/future-proposal-featherweight-profile/743 "2020-02-04T14:37:03Z")

</div>

What if we defined a sub-set of UAVCAN designed to be even simpler and more deterministic, requiring no dynamic memory allocation of any kind allowing for more primitive memory management, and eliminating some of the mor…

---

## [UAVCAN Specification v1.0-alpha is available](https://forum.opencyphal.org/t/uavcan-specification-v1-0-alpha-is-available/732)

<div class="topic-metadata">

**Author:** [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Replies:** 1\
**Last updated:** [January 29, 2020, 7:38pm UTC](https://forum.opencyphal.org/t/uavcan-specification-v1-0-alpha-is-available/732 "2020-01-29T19:38:33Z")

</div>

A recently merged pull request marked the release of UAVCAN Specification v1.0-alpha. Please read it here:

---

## [Why does the alpha specification call the variable-length array length "implicit"?](https://forum.opencyphal.org/t/why-does-the-alpha-specification-call-the-variable-length-array-length-implicit/736)

<div class="topic-metadata">

**Author:** [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\
**Replies:** 1\
**Last updated:** [January 29, 2020, 7:32am UTC](https://forum.opencyphal.org/t/why-does-the-alpha-specification-call-the-variable-length-array-length-implicit/736 "2020-01-29T07:32:04Z")

</div>

In Section 3.7.4.2 “Variable-length array types” the length field is described as “implicit”. Why is it implicit? It seems fairly explicit to me. Am I missing some subtlety?
