BMS: Method to Retrieve Fault Logs

raulrff · July 21, 2020, 4:53pm

We are planning to have some kind of fault log, which records fault conditions.
The exact implementation is still somewhat TBD, but I imagine the fault log would contain the timestamp, fault code, and maybe some captured data.

It could be easy enough as retrieving ASCII data. Example use case:

BMS has 10 different faults
FC requests fault count, BMS reports “10”
FC requests fault “1”
BMS sends details (in string format) for fault 1
FC loops to fault 10

Is there already an easy way in UAVCAN to allow for this kind of communications?

pavel.kirienko · July 21, 2020, 5:47pm

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):

github.com/OpenCyphal/yakut

Log files

opened 03:45PM - 27 Aug 19 UTC

pavel-kirienko

**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. ![image](https://user-images.githubusercontent.com/3298404/63782791-9b06cb80-c8f4-11e9-989e-b47382292dfd.png) 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.Record or vendor-specific) and let the blackbox record it for postmortem analysis later. The analysis feature is to be implemented in Yukon.