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.
During the development of the PnP algorithm for UAVCAN, we studied the DHCP model along with J1939 address claiming procedure and the CANOpen LSS auto address allocation (https://www.can-cia.org/fileadmin/resources/documents/proceedings/2008_pfeiffer.pdf). Taking the existing industry practices into account along with our high-level application models we were able to come up with a solution which could be considered simpler than the existing alternatives, although it has to make some assumptions about the overall network architecture. Our algorithm suits our envisioned use cases well, but it breaks for more involved scenarios such as those that require true dynamic reconfiguration where nodes from an unbounded set may be added and removed repeatedly over an indefinite period of time. That case would fall outside of the scope of our algorithm entirely (on the technical level it fails because our allocation table is a write-only data structure due to concerns over distributed consensus (https://raft.github.io/raft.pdf) and determinism).
Our solution is built on a purposefully large unique ID (128-bit), again, for reasons of simplicity: a sufficiently large set of valid UID values allows adopters to avoid reliance on centralized means of UID assignment.
At any rate, PnP is a very optional addition to the protocol which we expect may never find widespread use in certified deployments. UAVCAN itself is mostly intended for static or mostly-static architectures where PnP may often be superfluous.
On the subject of network-as-state-machine - we avoid centralization of activities/processes/states for reason of simplified failure mode analysis and reducing the number of assumptions made about the application. Simplicity is either the top priority or among the few top priorities for the design of the protocol. Each node is modeled as a separate agent capable of independent action – power up and go, no need to engage in configuration or synchronization processes of any kind unless the application itself requires that. This is unlikely to change ever.
Regarding the wording issue – thank you for bringing that up! I have documented it here: https://github.com/UAVCAN/specification/issues/54. The Specification document is currently awaiting updates to its transport layer chapter (need genericity and transport agnosticism) and the final proofreading.