FPP additions for Fault Protection features.

[timcanham]

This is a proposal for possible future updates to FPP to make fault protection a first-class feature of F Prime. At this stage, this can act as a brainstorming discussion.

1. Monitors

The components can declare monitors in the FPP like this (borrowed from FPP user's guide):

For example:

@ An active component for performing an action
active component Action {
   @ Other component items like commands/ports/etc...

   fault announce port faultAnnounceOut
   fault response port faultResponseIn

   monitor tempLimit (
      high: 34.0
      low: 15.2
      warning: 5
      fault: 10
   )

The fields are specified this way:

Field	Meaning
high	Optional; high limit for check
low	Optional; low limit for check
warning	persistence count for condition to issue a warning
fault	persistence count for a fault to be declared (must be >= warning count

The FPP should require at least a low or high limit to be valid. The values would be defaults to the run-time initialization of the code.

The FPP code generator would generate code in the component base class for each monitor:

1. A protected instance of the fault monitor helper (see Basic Fault Protection Ports and Components #2536).
2. Commands to modify the values of the fields in the monitor
3. Commands to disable/enable the monitors
4. Parameters to store the field values and enable/disable state
5. Events to announce changes in the monitor (e.g. warning/fault)
6. Telemetry for the current state of the monitor

[EbenezerA99]

How would the underlying code check the value of the monitor against the high and low limits? If a user writes a value to telemetry for the monitor, would the underlying code intercept the value and check it against the limits?

For ex.

User calls tlmWrite_monitor1(value), autocoded code checks value against high and low limits for monitor1

Or would it be a new function call that would explicitly check the value against the monitor

ex.

checkValue_monitor1(value)

[zimri-leisher]

At the moment, as far as I can tell, telemetry values are only stored in serialized form. When you call tlmWrite, the value immediately gets serialized into a buffer. This is an issue that I encountered while working on our own fault detection system. The solution we're going with is to write a separate database that stores the values in-memory, in non-serialized form. Generally, I just didn't want to mess with telemetry because it's supposed to be for downlink/informational purposes, not for making automated decisions about fault responses.