Moving this discussion here as it turned out to be a serious sticking point: https://github.com/UAVCAN/specification/pull/32#discussion_r234205382
Before we begin, let me make sure we are all on the same page.
What is currently written in the proposed spec is that DSDL type definitions can have fixed port IDs defined for them. If a fixed port ID is defined, it is guaranteed that the function for which the data type is created will always be available at this port. This is supremely useful for some standard things; like, for example, by looking at
uavcan.node.Heartbeat one will know immediately that to receive Heartbeat from all nodes, one should subscribe to the subject 62805; or, say, to get a node info, one should call the service 430. Any variance is excluded, things are nice and uniform for all. Having a fixed port ID does not preclude the possibility of using the type at other port IDs concurrently if so is desired.
Now, there are regulated and unregulated port identifiers. Regulated are those that are reviewed and vetted by the community. Being maintained in a centralized manner, they are always the same for everyone, so the possibility of conflicts or collisions is excluded. Currently, there are two locations where regulated identifiers are used:
- The standard data type set: https://github.com/UAVCAN/dsdl
- Vendor-specific public data types: https://github.com/UAVCAN/vendor-specific-dsdl (one namespace per vendor)
Besides fixed identifiers, there are also non-fixed ones (we used to call them “dynamic”, but Scott objected; the reasons were considered valid (at least that was my own understanding) so we are not using that word anymore). They can be assigned per-subject or per-service at the system definition time; for example, by a vehicle designer, or by an integrator, or similar.
Fixed identifiers are dangerous, because if one is used, it can’t be changed anymore until the node is upgraded. There is no possibility for anybody except the node designer to change it, because otherwise it would break the function availability guarantees described above. If anybody would like to challenge this point, please ignore the following text – until this is settled, further discussion would not make sense.
Since fixed identifiers cannot be changed, they can lead to unresolvable conflicts in the real world. As in, a vehicle designer would procure two nodes from two different vendors and then find out that they use the same fixed ID for different purposes. Too bad, they can’t work together; complaints afoot.
To prevent such conflicts, we make the following power move: we demand that if one wanted to use a fixed port ID with their data type, they make the data type definition public. They get in touch with the maintainers and ask for a fixed ID (by sending a pull request). Maintainers grant the ID (which we call regulated ID) and the definition gets accepted into the vendor-specific type repo linked here earlier.
- If you want a fixed ID, you make the data type definition publicly available. Maintainers give you your brand new ID, which is also called a “regulated ID”.
- If you want your types private, you don’t get any fixed ID. Because if you could have one, you would eventually run into conflicts with other vendors.
- If you tried to trick the system by using a fixed ID with your private data types, DSDL parsers would catch that and
report you to authoritiesraise an error.
Now, it may seem restrictive, indeed. Consider an entirely hypothetical scenario where a huge online retailer wanted to build a robotic submarine for their own maritime delivery needs. Their submarines would never be available off-the-shelf to any third parties, the ecosystem is entirely closed, so who cares if they re-use port IDs already taken by some Chinese noname? Indeed, nobody; right until the point where their ecosystem ceases to be so closed: either because they decided to provide their submarines or any parts of them to third parties, or if they decided to procure some third-party parts for themselves. We are interested in promoting a non-fragmented shared ecosystem where COTS equipment can easily collaborate; allowing conflicts here would very much go against that goal.
How about we demand that vendors switch from fixed IDs to non-fixed IDs once they make their ecosystems not-so-closed? Well, seeing as it can’t be enforced automatically, good luck with that. We meatbags are notoriously bad at following complex rules, especially if they require planning ahead. Nobody wants to mess with the code of a perfectly working submarine to un-fix some ID just to appease some standards.
To the point raised by Kjetil:
If they were starting to sell the unit (instead of just the integrated application) they would have to move the definition to the vendor specific domain and request a new static ID (or use dynamically configured IDs). They would have to move their definition to the vendor specific namespace either way (to make it available and check out on Port compatibility checks) which would be impossible with an ID from the application specific DTS.
No, it will not work as decribed. Many would opt to not go back and change a working product; they would release it with a footnote in the doc saying that unfortunately, due to historic reasons, this thing is stuck using this fixed ID; if you have problems with that, give our tech support a call. There are few things that can be more detrimental to the ecosystem than that. People don’t care about standards enough.