Telemetry database access from inside FSW

[zimri-leisher]

Affected Component	TlmPacketizer, TlmChan, Autocoder

---

Rationale

In order to allow the advanced sequencing language to perform complex conditions based on the state of the flight software, the values of telemetry channels will need to be accessible during runtime in a generic way.

Example syntax in the advanced sequencing language:

if module.component.tlmChanName > 10:
     ...

if module.component.tlmStructName.structMember == 5:
    ...
...

The current implementation stores telemetry channels only in their serialized form. This allows it to be generic but means that accessing the channel values requires deserializing them, which is not ideal.

Feature Description

• An API will need to be made which supports getting telemetry channel values based on a telemetry channel id.
• It is permissible for this API to output Fw::PolyType on a query. However, if it does, the void* option for PolyType should be a pointer to a deserialized type, not a serialized byte array.
• It would be ideal if it supported getting members of structs and arrays in telemetry too. For example, allowing us to query channel.memberName.subMemberName instead of just querying channel and having to figure out how to get the members and sub members.

[zimri-leisher]

From @vietjnguyen

Regarding the state/variable map, it seems the current concept is to use telemetry channels as the state/variables that the script/sequence can perform logic on. I think it's worth considering introducing a state/variables concept as a first-class concept in F Prime and using that concept as a building block for telemetry and parameters. Having this advanced sequencing capability (via custom design or third-party scripting engine) will require centralization of at least references to the states/variables anyhow. Making it a first-class concept creates a natural integration point and can streamline telemetry/parameters. You can also provide notification hooks for change detection. Such hooks could be used to implement a telemetry system on top of the state store. Similarly parameters could be reconceptualized as states that are populated on start up and loaded to components. Having this state centralized like this would also make integrating a scripting language or advanced sequencer easier. If you also introduce an abstraction for the state store you can add additional implementations beyond the "contiguous region of memory" one like one that stores it in three memory regions and does voting, one backed by external ECC memory, one enhanced with transaction history, etc.

Worth considering this idea for any implementation of this.