I think we should attempt to utilize what we have: the early-stage experimental PoC of the UAVCAN/serial transport. I am not sure if it’s entirely compatible with the requirement of being self-describing though.
I proposed earlier that we should log transport-layer data directly (like raw CAN frames) rather than processed higher-level entities (like DSDL objects) because it provides more context for later analysis and enables robust dumb loggers that do not understand UAVCAN and need not be configured. The idea is to construct DSDL objects of the appropriate type from
uavcan.metatransport.*, then serialize them into UAVCAN/serial transfers, and store the result into a headerless binary file. This way we naturally get extensibility because we can also serialize arbitrary metadata, like
uavcan.diagnostic.Record. The thing that I consider to be the most important here is that such logging solution is built upon things that are already available in UAVCAN; it’s self-sustaining.
I think we should postpone including things like this into the spec. We somewhat talked about this before:
Scott: should we define a UAVCAN storage format as part of the specification?
Pavel: I am not certain yet. UAVCAN is about real-time communication, not about data storage; the latter belongs to a different domain and does not affect many of the things that UAVCAN is concerned about, such as wire compatibility and functional correctness. At any rate, I am pretty sure it’s safe to just avoid answering this question for a while until we have gathered substantial empirical data on this feature.
We should revisit this question again if we decided to standardize the serial transport. In this case, the specification of UAVCAN/serial would seem to be the right place to document the log storage format.