Some thoughts on UAVCAN v1.0 PnP / node-ID allocation:
I’ve been involved in designing similar functionality to a CANaerospace implementation. In that particular implementation the unique ID is an EUI-48 identifier assigned by IEEE, which fits nicely inside a single CAN 2.0 frame. The Node-ID acquisition is similar to DHCP (discovery/offer/request/acknowledgement). So, my question is: should UAVCAN unique-ID acquisitions be formalized (i.e. applying IDs from e.g. IEEE or other number/ID allocation body) or is it ok that anyone can generate an unique-ID if needed?
Maybe worth some further iterations:
Should the UAVCAN network itself behave as a state machine? I.e. it would have states like ‘down/non operational’, ‘operational’ and ‘maintenance mode’ and should service clusters have additional status info like ‘redundant’, ‘degraded’ and ‘non-redundant’. In a ‘certified’ network configuration it would make sense that PnP / node-ID assignments could only be done when the network is in maintenance mode (i.e. aircraft is on ground).
As a side note (referring to ETSI modal verbs terminology, chapter 3 in the document linked below), usually ‘must’ and ‘must not’ are avoided in technical specifications and standards. ‘shall’ and ‘shall not’ are the preferred forms for expression of provisions.
…Separate message on (electrical) ground connectivity coming up.