Choosing Message and Service IDs

[pavel.kirienko]

@schwac

Are you saying that the subject IDs will need to be assigned dynamically?

No. They will be assigned statically, but they will be assigned by the integrator rather than the vendor. This means that the vendor will have to make them configurable. This is not the same as “dynamic” because they won’t be changing while the system is operational.

@schwac

If so, is there a well known fixed subject ID that can be used to assign system specific subject IDs?

Yes, it’s called the Register API. It’s on a fixed ID (just like many other standard services).

@schwac

It would be really helpful to have an example of recommended device provisioning in a system.

This example should make things clearer: Automatic configuration of port identifiers - #3 by pavel.kirienko (the discussion in that thread seems a little ragged because much of it was discussed in our private Slack, but we try to avoid that to keep all context public).

@schwac

For example, if the device has no UI, it must have a method to configure it via the comms interface it has available right? Like is there a way to send a message from the central node in the system, like the flight controller, that pairs the textual subject name with a subject ID number? The device can then store this to it’s own NVM, but that at least needs to happen once. It seems like that process is so critical to the system that it should be part of UAVCAN?

It is part of UAVCAN; specifically, it’s the part of the Register API. The UI is absolutely irrelevant here because whether it’s provided by the vendor or not has no effect on the UAVCAN interface – all DS-015-compliant devices will be required to support the Register API, always.