# What should our logging format be? **URL:** \ **Category:** Development & Maintenance\ **Created:** [February 24, 2020, 8:16pm UTC](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764 "2020-02-24T20:16:55Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [February 25, 2020, 6:25am UTC](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764/5 "2020-02-25T06:25:09Z")
Sure, we can get started here. First, I think the datatype hash is something we should figure out and add to the core specification. So is this a book on just system management or on design and management of UAVCAN systems? ![image](https://forum.opencyphal.org/uploads/default/original/1X/cff045316c8dc47a0c9dcfba01c2cc19799874a4.png) Here’s a start at the TOC ## Part 1: Designing a manageable system 1. Message profiles and interoperability 2. bottom-up design; optimizing your messages for bus, transport, and bandwidth efficiency. 3. top-down design: optimizing your messages for realtime control systems. 4. Integrating DSDL with your build-system. 5. Diagnostics, prognostics, system health, and error codes. ## Part 2: Critical Design 1. RPC versus Pub-sub: when and why to use either 2. How to allocate message priorities 3. Defining and ensuring bounded message latency on CANBUS 4. De-conflicting messages on complex busses 5. Heterogenous redundancy, system-level effects. 6. Inter-bus routing 7. Interfacing with a high-level sub-system (e.g. SocketCAN on Linux) ## Part 3: System Management 1. Data Logging 2. Health System 3. Update over UAVCAN 4. System-of-Systems: How UAVCAN is used in robotics fleets. 5. Manufacturing and maintenance: Using UAVCAN as part of vehicle assembly and when troubleshooting. --- _[View the full topic](https://forum.opencyphal.org/t/what-should-our-logging-format-be/764)._