Port type safety enforcement

Consortium UDRAL: Cyphal Drone Application Layer
89

Hi all!
I’m a new poster to this thread, though I’ve interacted with some of you before. Trying to avoid what seems to me like a looming fork in the project, I’d like to bring up a compromise proposal. This proposal addresses a major disagreement point - subject-id assignment. Some additional points such as the desired granularity of messages and the means to increase type safety are left out for now and can be discussed additionally.

  • suggestion
    • Let’s introduce a standard file format to keep a mapping between subject-id and a message type (and instance-id). Lets provisionally call it “subject-id allocation format”
    • URDAL working group would create and maintain an instance of this file. Let’s call this “UDRAL subject-id allocation” Other working groups could choose to fork this file, coordinate compatible extension of it or choose a different allocation approach altogether.
    • This “UDRAL subject-id allocation” file would be used by both the diagnostic tools (log analyzers, field diagnostics) and “network managing” components of PX4, ArduPilot, and other central nodes. Such use can be either static (code generation) or dynamic.
    • During system powerup, the “network manager” would configure the subject-id for each peripheral instance according to this allocation. This should be a relatively straightforward extension of the current dynamic node id allocation.
    • As the subject-ids would be well defined within the boundaries of UDRAL compatible networks, dispatch and network monitoring tooling can depend on knowing them. Recent versions can even be pulled from a repository together with DSDLs.
    • The manual configuration remains an option. Even then, allocation file as a source of unambiguous documentation makes the process easier and the resulting system compatible with tooling.
  • tradeoffs
    • There will be at least one more register round-trip per message during initialization to check or configure the subject-id (as compared with v0)
    • Transferring peripherals between uncoordinated application domains would cause unintelligible messages on powerup and before initialization is complete. For example, removing servo from a CNC machine and putting it on UAV, assuming the UDRAL and (hypothetical) CNC working group do not coordinate their allocations.
    • Multiple network managers can not share a network unless they use coordinated allocations (for example: unifying the two groups mentioned above to make a flying CNC machine would require two networks with a bridge node)
    • The presence of such allocation guidelines could encourage some extremely near-sighted peripheral vendors to hardcode the value instead of implementing a configuration interface.
  • summary
    • “subject-id allocation format” makes the subject-id allocation issue explicit and provides tools to express the design, manage coordination within and even between working groups (if deemed worthwhile). Having this information out in machine-readable format allows adequate tooling to be made.
    • the tradeoffs are probably mild, easily mitigated, and worth the additional expressiveness gained
2 Likes