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:
- 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.
- 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]