Noooooooo! Not our precious reserved bit!?! @kjetilkjeka, Andrew wants our reserved bit! Do you have any idea how hard we fought @pavel.kirienko to get that bit? 
Seriously though, I think the idea of just having a smattering of fixed port identifiers as part of a super-simple profile is the best way forward and I really donāt want to touch the UAVCAN V1 core specification to make this work (while I donāt expect to use UDRAL I also donāt want it to conflict with other profiles I will use). Again, Iāll raise the not-particularly-apt-but-somewhat-illustrative example of I2C addresses. Millions of I2C devices are manufactured with very little by way of a guarantee that the device address will be unique for a given bus. Manufacturers are willing to live with this because there are probably not many devices on any single I2C bus and they all can probably be configured between a set of two or three different address options and if not the board designer can probably just use another I2C peripheral to isolate the troublesome part, etc. So while I2C addressing should be a shit-show in theory itās generally fine in practice.
If you define a āsimple sensor networkā profile as the first output from the UDRAL effort where each manufacturer is given guidance in how they should map port identifiers to datatypes for just this profile and we require that the manufactured-in defaults can be manually tweaked if someone fails to follow the community guidance then I think the semantic mapping of ids should be, generally, fine for the constrained problem space. Even looking at the newest offerings from NXP, theyāll be enough CAN peripherals available that you could just put a poorly configured sensor on its own CAN bus.
So, my concrete proposal is:
- define a set of datatypes that compose the UDRAL āSimple Sensor Network Profile.ā
- maintain a matrix of data types to three port identifiers each (one recommended and two alternative) that is generated from the @semantic_id fields in the profileās DSDL
- publish guidance for how port identifier deconfliction should be accommodated (e.g. solder jumpers, dip switches, UART terminals, USB programmers, etc) but plan for most devices to ājust workā when you attach them to a system.
- (later/next) develop a more advanced profile (āAdvanced Avionics Networkā profile, perhaps?) that includes a distributed ledger defining the system configuration including port to data-type identifier mapping. Build on this to implement device attestation and trust boundaries.
Now, this all said, Iām curious Andrew, how does Ardupilot deal with node identifiers today?