What if we defined a sub-set of UAVCAN designed to be even simpler and more deterministic,
requiring no dynamic memory allocation of any kind allowing for more primitive memory management, and eliminating some of the more vexing parts of the protocol for implementers. Specifically the featherweight profile (It’s a working title) would remove variable-length arrays and RPC/service calls (and unions if my proposal to remove unions wholesale is rejected). All full UAVCAN nodes would be able to receive all messages from featherweight nodes and would be able to send featherweight-compatible messages to those nodes (i.e. featherweight is a proper sub-set of the full protocol). We would also add a directive to DSDL to assert that a given message is compatible with the subset.
This is particularly useful for a safety-critical device that is self-programming over CAN. The primary application can be a featherweight but the secondary “flash over CAN” application would implement the full protocol. This allows for a certified hypervisor to protect the two making it easier to certify the primary to a higher design assurance level then the secondary and for the secondary to implement a large number of higher-level functions to facilitate diagnostics and debugging interactions without introducing failure modes to the primary application.