FSW Info Component and Os API Changes

[LeStarch]

We'd like to add to fprime a component that telemeters the following information while connected to a rate group:

1. FSW_VERSION
2. RAM usage
3. CPU usage

This will be a component in the Svc package that will call into a new section of the API in Os, which would supply the raw data.

Users will be able to supply their own script to generate the version, where the default version will come from the git repo.

Note: the intention is to define 16 CPU channels for utilization, but only telemeter those channels when the given CPU is present. For systems with more than 16 CPUs, a custom component would be needed.

[LeStarch]

@sfregoso any additional information? @kevin-f-ortega any thoughts?

[kevin-f-ortega]

This looks good. Something to consider: adding Boot Count which indicates how many times FSW rebooted from last hard reset. This can help catch an unnoticed FSW reset.

I would also add a command to dump the telemetry since there is the chance the ground can miss these values (in particular FSW_VERSION) on boot up.

[ThibFrgsGmz]

The idea is very relevant; I was working on a technology demonstrator where we needed to know the RAM and CPU usage to determine whether the hardware platform sizing was appropriate for the mission.

What is the reason for the 16-channel limit? Is it an arbitrary value?

[LeStarch]

A truly generic solution limiting the defined channels per-hardware is complicated. Thus we recommended a solution where we picked some limit for the number of CPUs and telemeter up to the minimum of CPU count and this limit. This does mean we have some extra channels that won't be used on all hardware...but it isn't a major cost to offset much large complexity.

So how did we choose this limit? At some cpu count, the per-cpu utilization is unusable as discreet channels and also results in may unused channels on less capable hardware. Since CPU cores tend to follow powers of two, we were selecting from (4, 8, 16, 32) cores as a limit. We see a lot of embedded 4, 8 cores today and 16 gives us some room for growth. 32 seems like way to much to manage as discrete channels.

I could also be convinced to use 8 channels as well, if users feel that 16 is too many.

[Joshua-Anderson]

Is this not something that's possible just to configure with a constant? We can default it to 16 and make it easy for others to resize if necessary for their deployment.

[LeStarch]

Not easily. I don't think array length nor channel names can be parameterized via a constant with the existing autocoder. Hence this solution.

[ThibFrgsGmz]

I wonder about the usefulness of CPU and RAM usage information for a product in flight.

The interest in feasibility studies, technology demonstrators on the ground or in debugging configuration seems undeniable to me.

However, in flight configuration, I am curious to know what can be done with this information and what decisions would have to be made if it is not nominal.

I imagine that in special operational modes of the software system, it would be useful to monitor CPU and RAM usage. If they exceed a certain limit, the system could go into safe mode or something similar.

Is there anything else I'm not aware of?

[timcanham]

We use it quite frequently on our projects during testing and flight to get an idea of how much CPU is being used. Since we start activities by sequence and they can run in parallel, we can gauge how close to the limit we are. We encounter the real world in flight, and sometimes the system reacts differently than in testing.

[sfregoso]

This is how the telemetry looks in the GUI. Maybe units in the label would help. The "Util" is percentage. The "Total" value is a unit of such as KB. "CPU" is the average of all CPUs.

[timcanham]

Telemetry channels have an attribute that lets you define a C format string for displaying data.

For example:

        <channel id="23" name="Core0Util" data_type="F32"  format_string="%3.2fPCT">
            <comment>The Core 0 utilization percentage</comment>
        </channel>

[sfregoso]

Ah great i'll make that change. Thank you!

[LeStarch]

Check:

commands guarded, or queued component.

[SterlingPeet]

Side note, I already have implementations like this in my projects so I think it is nice to see upstream recognition of the same concerns. For my ultra-small deployments, it gets rolled into some other component as a rather extreme space-saving measure.

However, you can see that the following deployment template code I wrote alludes to the same need (and only slightly predates this call for comments):

Deployment Template Main.cpp file lines 42-50

/**
 * In a production deployment, the following version definitions should
 * be kept in a component that can telemeter the values on-demand, and
 * those definitions can be used directly in the logMsg call rather than
 * being re-defined below.
 */
#define {{cookiecutter.deployment_slug|upper}}_VERSION_MAJOR 0
#define {{cookiecutter.deployment_slug|upper}}_VERSION_MINOR 0
#define {{cookiecutter.deployment_slug|upper}}_VERSION_PATCH 1

I never ever want to guess what version of software/firmware is running on the remote device. It should be obvious, somehow.

[LeStarch]

This item has been approved for implementation!

[sfregoso]

Wow this is great!

[LeStarch]

PR has been made: #1116

[ThibFrgsGmz]

From what I see quickly, the component is passive?

I assumed that for CPU usage, we'd have an active component that would be an idle task that would increment a counter, a task whose priority would be as low as possible, lower than, say, a memory scrubbing task.