Anonymous message and dynamic node ID allocation

[Martin Jäger]

Hey there,

I am currently developing a CAN based protocol for energy management systems (Libre Solar project) and I am glad I found the UAVCAN protocol spec. Thanks a lot for the great work and for making it open source.

The usage of the CAN ID looks somewhat similar to the SAE J1939 standard. However, UAVCAN uses a very different approach for dynamic node ID allocation. Why is the approach with anonymous messages used instead of the J1939 address claiming feature?

And is the anonymous message only used for this feature or also for something else?

Would be nice to understand the background for this concept.

Martin

[Pavel Kirienko]

Hey Martin,

Yes, anonymous messages are used only for node allocation requests, although we may find other uses for them in the future. They are difficult to work with because a number of special handling rules apply (such as randomized bits in CAN ID and the requirement to abort transmission after a collision).

The approach implemented in J1939 is quite different. Its major downsides are the following:

- It relies on the assumption that every node has a preferred node ID. This forces the protocol to make unnecessary assumptions about the typical distribution of functions and responsibilities across different nodes in the network, which, in turn, increases the undesirable cohesion between the transport layer and the application layer.

- The approach is less deterministic, as there is no single authority on the bus that can make a centralized well-informed decision about the distribution of node ID between nodes. Note that in UAVCAN, nodes still can communicate their preferred node ID to the allocator, which is taken into account when choosing a dynamic node ID. Additionally, despite offering centralized allocation services, UAVCAN's allocator is not a single point of failure, as it can be redundant by virtue of a Raft cluster.

- The address claiming procedure in J1939 assumes that all nodes are permanently available on the bus once their addresses have been confirmed. This imposes a number of restrictions on the behavior of nodes. UAVCAN makes no assumptions about the availability of any node on the bus, or its ability to respond to any request.

Hope this helps!

Concerning your project: have you considered to just use UAVCAN, perhaps with a custom set of data type definitions?

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/39d71aa5-760c-47d8-a0ff-e2f826aacc49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.