V1.1 roadmap defined

Development & Maintenance Specification
1

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 executed as part of a new minor revision, 1.1. @pavel.kirienko reminded the group that V1.0 was not yet officially released. @scottdixon proposed that we then release v1.0 to make way for v1.1 work to proceed. There were no objections to this. As such the consensus is that, once the remaining v1.0 issues have been resolved we will officially release v1.0 and begin work on v1.1.

The current set of items for 1.0 under discussion are as follows:

  1. Improvements to the transfer ID for transports using large identifiers (i.e. , not CAN)
  2. Additional DSDL directives focused on system-level and runtime analysis. For example, directives for message publication rates, valid ranges for integer values, and grouping (e.g. tagging messages by sub-system).
  3. Named Topics (mic drop)
  4. Secure node authentication
  5. Formal proofs of certain protocol features (e.g. proofs for multi-part transfer reassembly reliability)

Please join our weekly devcall if you want to add to this list or participate in v1.1 standarization.

1 Like
2

Slight amendment: Named topics are also meant to include named RPC endpoints. For the rationale and discussion please refer to the separate topic.

3

While we’ve been hoping to get to Cyphal/TSN I wonder if we should first tackle Cyphal/IPC? That is, we should have a specification for a zero-copy transport using shared memory to support ARINC-653-like sampling and queuing ports. This would complete a function portability story where the application interface for a given function previously available over a network would remain stable but a performance improvement could be realized by migrating the function to the local compute.

1 Like
4

Another thing to consider, perhaps, in 1.1; canonical storage format for Cyphal.

5

Are you talking about traffic dumps like pcap/candump or something else?

6

I contemplated proposing routing but in the end decided to shelve it until v1.2. It is fairly clear that routing will be highly affected by the design of named topics; while we probably shouldn’t attempt to formalize routing in any way in the v1.1 spec, we must keep it in mind while working on the named topic protocol.

7

Logging that is transport agnostic but which can contain metadata about the transport if needed. Something that includes timestamps, the data type itself, a textual representation of the data, etc. The use case is logging with an ability to perform time-accurate playback in simulations.

8

Something like this? Postmortem dump analyzer tool

One record from there reformatted for clarity:

{
  "_meta_": {
    "ts_system": 1723389566.189359,
    "ts_monotonic": 892858.413041906,
    "transport": {
      "kind": "can",
      "source_iface": "slcan0"
    },
    "priority": "nominal",
    "transfer_id": 4,
    "source_node_id": 0,
    "destination_node_id": null,
    "subject_id": 7509,
    "dtype": "uavcan.node.Heartbeat.1.0",
    "payload_hex": "44000000000000"
  },
  "uptime": 68,
  "health": {
    "value": 0
  },
  "mode": {
    "value": 0
  },
  "vendor_specific_status_code": 0
}