Service/message ID alocation registry - initial thoughts

Consortium UDRAL: Cyphal Drone Application Layer
1

Quick dump of my thoughts and previous discussion regarding the message ID allocation files.

  1. There are several options to define split between instance # and message ID parts, for usages like message routing in the receiver and parsing in analyzers.

    • fixed # of bits (like 4+12 aka 16+4K or 6+10 aka 64-1K)
    • configurable # of bits per file specified in the header
    • class-based structure like in IPv4 with predefined blocks of different sizes
    • class-less structure where each block specifies size (would require tooling support to help validate allocations for collisions)

  2. It is highly desirable to allow compiling this file to get all the information required to configure a system and parse logs. Therefore inclusion of URL where full message DSDL can be retrieved.

  3. Picking option 4 for the instance_ID range, the main content of the file would be a collection of triplets { service_name, message_type, port_range }

  4. @pavel.kirienko prefers to use YAML as a format, therefore the following example :

version: 1
uri:
    reg: https://github.com/UAVCAN/public_regulated_data_types/tree/udral/reg
reg.udral.srv.battery:
    status:
        type: reg.udral.service.battery.Status.0.2
        id: [100, 110]
    energy:
    ...
1 Like