Autopsy/Tracing concept

[timcanham]

This concept is for tracing execution (AKA Autopsy for JPL folks). Tracing allows an on-board log to be built of software execution where various points in the software a sample point can be saved with a time tag. The data would be stored on a per-thread basis. The data is stored in buffers, and then save to storage as a Data Product for later downlinking.

The work would consist of:

1) New FPP specification (for example):

trace StartRateGroup (
                     cycle: U64 @< The cycle count
                   ) \
  type execution \
  id 0x01

This would turn into code-generated functions that the user could call when a trace event happens. The FPP can specify arguments like cycle that are custom, and they would be serialized into a trace record that includes the id, a time tag, and the user arguments.

Trace points would be automatically generated for the following autocoded actions:

Action	Stored
Port call	Port id, arguments
Command port call	Command opcode, arguments
Message Wait
Message dequeue	Message ID
Output port call	Port ID, arguments

The trace entries could be put in the dictionary so a ground system could automatically decode the trace data.

2) Implement a new trace port type. It could look a lot like an event port:

port Trace(
            $id: FwTraceIdType @< Trace ID
            ref timeTag: Fw.Time @< Time Tag
            $type: TraceType @< The trace type argument
            ref args: TraceBuffer @< Buffer containing serialized trace entry
          )

3) Implement a basic in-memory logger with data products to dump the buffers. Projects could write more sophisticated versions or embedded versions if they like.

Since this feature could consume significant code and processing, it should be a feature that can be turned on and off.

[Shivaly-Reddy]

Trace_Requirements.docx

@timcanham : I've attached a revision of Trace requirements. Can you please take a look and provide your feedback? @LeStarch: I'll also put the final revised requirements here and of course it will be part of Fw::Trace -> sdd.md as well. Thanks!

[LeStarch]

@Shivaly-Reddy that file seems corrupt. Can you just copy-paste the data here?

[timcanham]

I was able to view it, FYI...

[timcanham]

Let's separate them in to categories for the framework vs. a particular implementation:

Framework

Requirement	Rationale
F Prime shall provide a Trace feature
The Trace feature shall log a trace ID, a time tag, and context data
The Trace feature shall support logging for framework execution for port calls message dispatches, and message dequeues including any arguments
The framework logging shall be selectable on a per-component basis	Certain components may wish to be excluded
The Trace feature shall support user-defined trace IDs and arguments
Trace entries will be defined in the ground dictionary to support ground-side decoding
The trace feature shall have three levels of configuration at compile-time: off, minimal (ID only), full (ID + arguments)	Projects may wish to not use the feature or have a minimal version

Embedded Implementation (e.g. VxWorks)

Requirement	Rationale
Record in memory with DPs
Store per thread
Recoverable memory
Write DP on reboot
Command to dump on request
Command to disable/enable

Demo Implementation - File Logging

Requirement	Rationale
The file logger shall log all entries to a file name specified at initialization time (replace with DP when ready)	Demonstrator for Reference app