Implementing a Housekeeping Service #26

New Issue

muellerr · 2022-12-17T17:30:26+01:00

muellerr commented

2022-12-17 17:30:26 +01:00

Some thoughts and trade-offs how to implement the HK service.

Some background information first:

The FSFW implementation of PUS HK is not really standard-conformant. If it is re-implemented like done in the FSFW, custom subservices should be used

Some notes on how the FSFW implementation and the PUS Specification differ:

PUS has a more parameter centric approach where it is also possible to dynamically create new sets consisting of those parameters
The FSFW has a dataset centric approach where the HK datasets are fixed for a given Software and can only be updated with a software update
The FSFW has an object-oriented approach, where a housekeeping structure ID consists of a source object ID and a individual set ID.
The FSFW has validity flags for individual fields of a set. The bitfield solution used to implemnent this is not ideal and should be implemented differently for Rust
The FSFW simply uses floating point seconds as the collection interval parameter. The standard specifies that the collection interval is actually a unsigned integer specifying the multiple of a minimum collection interval. Each application process can have different minimum collection intervals.
The FSFW has a distributed architecture for HK data
No support for super commutated parameters in the FSFW

The Rust implementation is not bound to object-orientation. Therefore, it would theoretically be possible to implement something which is fully PUS conformant again.

Some disadvantages of the PUS approach:

No mention or specification of HK parameter validity
Not really tailored towards the object-oriented approach
No mention of vector parameters.
No mention of how HK packets could be self-describing. Maybe this is not intended at all for PUS?

Some implementation specifics:

Getting closer to the PUS model would mean that each parameter in an OBSW is associated with a parameter ID. Macros could probably help with this
The set approach is something which I really like. From an OBSW developer perspective, it should be possible to easily group parameters into sets which can then be dumped as HK easily (pre-defined sets).
The distributed architecture does not have to be implemented like in the FSFW and will probably be implemented as a distribution over threads or/and over APIDs.
Creating sets at run-time seems to be a bit of a luxury for me. How to even do this without dynamic allocation?
Self-describing sets might be a nice thing. Why not add 1-3 description bytes for each dumped parameter which contain validity, type of parameter, whether it is scalar or a vector, and if it is a vector, how large the vector is? With this, we are not PUS conformant anymore, but I might not care anymore at this point because working with the HK data now gets a lot more easy on the telemetry side.

Ah und byte the way we can just dump everything as JSON is downlink capacity is not an issue.

Some thoughts and trade-offs how to implement the HK service. Some background information first: - The FSFW implementation of PUS HK is not really standard-conformant. If it is re-implemented like done in the FSFW, custom subservices should be used Some notes on how the FSFW implementation and the PUS Specification differ: - PUS has a more parameter centric approach where it is also possible to dynamically create new sets consisting of those parameters - The FSFW has a dataset centric approach where the HK datasets are fixed for a given Software and can only be updated with a software update - The FSFW has an object-oriented approach, where a housekeeping structure ID consists of a source object ID and a individual set ID. - The FSFW has validity flags for individual fields of a set. The bitfield solution used to implemnent this is not ideal and should be implemented differently for Rust - The FSFW simply uses floating point seconds as the collection interval parameter. The standard specifies that the collection interval is actually a unsigned integer specifying the multiple of a minimum collection interval. Each application process can have different minimum collection intervals. - The FSFW has a distributed architecture for HK data - No support for super commutated parameters in the FSFW The Rust implementation is not bound to object-orientation. Therefore, it would theoretically be possible to implement something which is fully PUS conformant again. Some disadvantages of the PUS approach: - No mention or specification of HK parameter validity - Not really tailored towards the object-oriented approach - No mention of vector parameters. - No mention of how HK packets could be self-describing. Maybe this is not intended at all for PUS? Some implementation specifics: 1. Getting closer to the PUS model would mean that each parameter in an OBSW is associated with a parameter ID. Macros could probably help with this 2. The set approach is something which I really like. From an OBSW developer perspective, it should be possible to easily group parameters into sets which can then be dumped as HK easily (pre-defined sets). 3. The distributed architecture does not have to be implemented like in the FSFW and will probably be implemented as a distribution over threads or/and over APIDs. 4. Creating sets at run-time seems to be a bit of a luxury for me. How to even do this without dynamic allocation? 5. Self-describing sets might be a nice thing. Why not add 1-3 description bytes for each dumped parameter which contain validity, type of parameter, whether it is scalar or a vector, and if it is a vector, how large the vector is? With this, we are not PUS conformant anymore, but I might not care anymore at this point because working with the HK data now gets a lot more easy on the telemetry side. Ah und byte the way we can just dump everything as JSON is downlink capacity is not an issue.

muellerr added the

concepts

label 2022-12-17 17:30:26 +01:00

muellerr added this to the satrs v0.1.0 milestone 2023-09-01 23:38:39 +02:00

muellerr commented

2024-03-21 17:25:37 +01:00

I really need to have a look at MessagePack and protobuf at some point. If low memory footprint is an important requirement, we can still drop down to stupid C structs again.. Irrespective of the exchange protocol, there is some boilerplate logic like figuring out how often to dump HK packets and exposing a generic interface which is at least partially compatible to PUS.

I really need to have a look at `MessagePack` and `protobuf` at some point. If low memory footprint is an important requirement, we can still drop down to stupid C structs again.. Irrespective of the exchange protocol, there is some boilerplate logic like figuring out how often to dump HK packets and exposing a generic interface which is at least partially compatible to PUS.

Sign in to join this conversation.