Subject-ID Assignment

Applications & Usage
1

For an hypothetical Cyphal network with say, 500 nodes which periodically publish a sensor reading, how should the Subject-IDs be handled?

Based on the Cyphal Guide

While it is possible to embed the means of instance identification into the service contract itself (for example, by extending the data types with a numerical instance identifier like it is sometimes done in DDS keyed topics), this practice is ill-advised because it constitutes a leaky abstraction that couples the service instance identification with its domain objects.

and the extensive discussion around the integration of Cyphal into ArduPilot and DS-015, I understand that the intention is to assign at the time of setup, an unique Subject-ID of 5000-5499 for the output of each node.

While I see the benefits of not defining a fixed Subject-ID at the data type definition, this method of separate Subject-IDs for every reading seems to result in large runtime costs, especially on RAM: for instance, libcanard requires 0.5KiB~ per subscription. There’s also the associated code bloat.

I can think of a few ways to compromise:

  1. Configure a single Subject-ID used by all the nodes, then use the Node-ID to identify where the message came from. Of course, this breaks when a node has more than one sensor.
  2. Configure a single Subject-ID used by all the nodes, then extend the data type with an identifier
uint8 sensor_id              # Which specific sensor is it?
float32 pressure_difference  # [pascal]
2

The idiomatic approach is to assign a separate Subject-ID per sensor, as you described.

The libcanard RAM utilization per session is something that may require revision. For example, in libudpard, where the maximum number of nodes is 65535 (from 0 to 65534), the static table approach adopted in libcanard is no longer viable, so we use a O(\log n) tree instead; perhaps the same approach should be applied in libcanard as well, possibly as a build option.

The compromises you listed are well-known indeed, and they are known to cause significant issues in practical deployments. I advise avoiding them.

For the bloat issue you mentioned, check out this RFC: RFC: add array of ports. Any input would be appreciated (I am yet to provide mine).