Electronic datasheets are exactly the type of thing I am talking about! Apologies for the dump below, I have been using this comment as a scratchpad for some thoughts and they are a bit jumbled.
I think I am coming from a slightly different angle from a lot of that discussion, I am primarily concerned with system descriptions (and highly reliable systems!) - the interest in DSDL is because it is succinct, lightweight… and ripe to have more features abused into it!
I don’t have a proposal at this point but I’m looking at a few of things:
- A node descriptor which captures the services and messages the node may call and respond to
- A method to attach documentation to DSDL descriptors (think doxygen style comments in dsdl, or files that match up with dsdl descriptors)
- A method to handle multiple versions of the same message.
The comment you mention, and specifically
The electronic datasheets are likely to be preferred in high-reliability settings hits the nail on the head. I have a system, I know at deployment exactly what goes into it. I don’t want my nodes to negotiate, establish a connection and subscribe to things, I want them to come up ready to handle a message and do their job within milliseconds of power on.
Node descriptors make lots of awesome things very easy to do. A full node descriptor allows generation of more embedded code (in libcanard the handle and filter functions can be generated). It also allows us to create a python object and bind functions on to it to represent a specific node. We can now easily make a python implementation of a canard node - we just need to write the behavior in behind the interface. This is awesome for testing! Another benefit as well is having a good way to describe system nodes lets us lay out interfaces more effectively at design time - the test nodes can be created long before hardware arrives.
Introspection was mentioned, yes please, and with rich documentation attached to the dsdl. The user should be able to do
help(node) and see something which allows them to use it. This can also be used in generation of documents such as Interface Control Documents.
Regarding being able to work with multiple versions of the same message, would it ever be possible to use something like:
[default data type ID.][version.]<data type name>.uavcan
Suppose I want to be able to work with multiple versions of a system where I also want to keep the ddtIDs fixed. From my understanding collisions should be avoided because of the CRC. It’s not pretty, but the big hub node can brute force trying each versions signature to match the CRC.
Anyway, this is a very interesting project - I’m interested to get involved!