While updating the specification in accordance with the changes we discussed, I decided to take a tiny step back and see whether all other possible approaches have also been considered. After an hour of doodling in my notepad, I arrived at the conclusion that none of the sensible alternatives that come to mind are viable, so I am continuing with the original plan. For the benefit of posterity, I decided to share a brief summary of my reasoning here; this will also serve as a justification for the major design decisions related to the UAVCAN type system.
A new abstraction layer added to the protocol introduces the concept of “Subject” – an entity identifying a stream of messages pertaining to a particular physical process in the system.
Within the new hierarchical system model adopted for UAVCAN (system / physical process / physical quantity / datatype / bit sequence) – which is not strictly enforced anywhere but rather used as an optional mind-crutch for ease of reasoning about the application – a physical process is modeled as a set of varying physical quantities, at least one per process.
| Layer | Example |
|---|---|
| System | A rotating wheel |
| Physical process | Rotation |
| Physical quantity | uavcan.si.angular_velocity.Timestamped |
| Datatype | float32 |
| Bit sequence | 10000101001100001100110011010010 |
Seeing as a process might require more than one physical quantity to be described, one would be tempted to think (I know I was) that it would be sensible to permit different physical quantities to share the same Subject. A particular quantity within the system would then be identified by a pair of values: Subject ID and some other kind of identifier used to pinpoint the physical quantity within the Subject (i.e. physical process). For example, for a rotating wheel, the same Subject might contain two physical quantities: angular velocity and the angular position of the wheel.
The obvious downside would be that we just added an extra concept out of necessity, requiring two parameters where just one used to be enough. Additionally, consider what happens if there is a need to report multiple parameters of the same physical dimension. For example, imagine that the wheel is equipped with a brake; suppose that it is desired to be aware of the temperature of the braking mechanism and of the tire surface while braking, so the Subject would contain two physical quantities (brake temperature, tire temperature) under the same dimension (kelvin). Now we got ourselves in a bind as we can’t distinguish between the two (a meticulous reader might object that braking could be considered a separate physical process under a separate Subject, thus eliminating the collision; however, the validity of this replacement largely depends on one’s view of the system structure which we don’t want to force, and there exist other examples where such replacement would be less organic).
To work around the above problem, one could go further and add yet another identifier separating physical quantities sharing the same dimension from each other, thus increasing the number of parameters needed to pinpoint a particular physical quantity within the system to three.
From my perspective, the problem would appear to be solved, but at a great cost of additional complexity and an overly strict/opinionated system model. Same results can be achieved using the initially proposed logic, where each physical quantity is referenced by Subject alone, and the mapping between Subject and its quantities is always one-to-one. Provided that the space of Subject identifiers is sufficiently large, the integrator (vendor, application designer, user) can devise custom, arbitrarily sophisticated system models, e.g. requiring that certain ranges of Subject ID are reserved for specific parts of the system (e.g. 100-200 for the left wheel, 200-300 for the right wheel). The advantage is that the specification would be made much simpler and we relieve ourselves from having to make decisions that are better delegated to the user.