I think this is a very general use case that is applicable beyond just BMS. We envision a generic application-agnostic datalogging framework as outlined briefly here (even though it is documented in an implementation repo, it is not specific just to this implementation):
opened 03:45PM - 27 Aug 19 UTC
**EDIT 2021: see https://forum.uavcan.org/t/uavcan-v1-wireshark-plugin/1058/2?u=… pavel.kirienko**
We need the ability to log network frames into dump files and read them back for later analysis. This feature is vital for various R&D and flight recording purposes.
The feature has been discussed first in this thread: https://forum.uavcan.org/t/gui-tool-next-generation/229/2?u=pavel.kirienko. At the application level, its purpose is close to that of ROS bags: http://wiki.ros.org/Bags.
First, it was proposed to define a dedicated format, where log files are flat binaries (no global structure) consisting of an ordered set of frames: https://docs.google.com/spreadsheets/d/1yP9zXChKTaIm92Bd60jgrOSwGIeXp-CO5tGyYcaBopg/edit. As explained on the forum in the linked above thread, lack of global structure (e.g., no file header) is desirable because it allows trivial manipulations over log files (which can be huge) to be performed by naive concatenation/truncation/splitting.
Later it was observed that the log file frame format and a then-hypothetical [serial link frame format](https://github.com/UAVCAN/pyuavcan/pull/70) would be largely identical because flat log files and serial links are structurally similar: https://forum.uavcan.org/t/yukon-design-megathread/390/115?u=pavel.kirienko. So we can use the existing (albeit still extremely experimental) serial transport for log file storage. At the architectural level, the only missing piece is the set of DSDL definitions describing transport frame data formats for various transports. Once such definitions are available, the task of log recording can be defined as listening to the network traffic in promiscuous mode, encoding each received frame into a DSDL object, and then serializing that as a message transfer over serial transport. The resulting byte sequence is then appended to the log file. Likewise, it is possible to log arbitrary metadata by using appropriate DSDL message types.
Shall this approach prove successful, we could expand this to become a de-facto standard for data logging not only by software tools but also by hardware data recorders.
Under this model, the recommended way of handling faults is to emit a UAVCAN message (such as uavcan.diagnostic.RecordYukon .