Integration of ASN.1 SCC in F'

[ThibFrgsGmz]

Hi folks! I'm transcribing here my post posted on F` Community Group

Context

ESA has been developing for several years its TASTE [1][2] framework for Flight Software, such as F Prime. This framework is based on two key languages: AADL and ASN.1. It is the second language that interests me here, ASN.1.

As a reminder, ASN.1 is an OSI Presentation layer protocol widely used in telecommunications to make systems communicate in heterogeneous environments. It allows messages to be described in an abstract (human-understandable) and physical (bitstream) way.
ESA has developed a complete and mature implementation of ASN.1 called ASN.1 SCC (Space Certifiable Compiler)[3][4] to cover all data modeling needs of space applications.
This compiler targets safe systems and generates Spark/Ada, C, SCALE or SDL code.
The source code generated to encode and decode the upstream and downstream streams makes no memory allocation at runtime, no system calls, no dependency on an external library, has a tiny footprint and generates test cases for code coverage.

Question 🤔

Do you think it would be an interesting development for F Prime to integrate by default (or optionally) the ASN.1 protocol (with ASN.1 SCC)?

Rationale

This would probably reduce the complexity of interfacing F Prime based software communicating with other SSEG (Space Segment) software such as instruments (e.g. star tracker), but also with custom Ground Systems, since they agree on the definition of Cmd and Tlm (with possible use of EDS).

This would also make the interfacing of F Prime based software with TASTE based software more or less transparent.

It also opens the door to the use of the ESA funded asn1-pusc-lib [5] open source library which is an ASN.1 implementation of the ECSS PUS-C standard[6][7].

I personally had to develop a project from scratch for the European Commission where I was required to use ASN.1 SCC because my client's AOCS was developed with TASTE. I have to admit that ASN.1 allowed me to save time on Cmd/Tlm implementation: I used the same ASN.1 SCC autogenerated encoding/decoding library on my FSW and on my EGSE.

Implementation suggestion

At the level of ASN.1 SCC protocol implementation in F Prime I have the impression that we need to add a generic data presentation plug-in concept for the command/event/telemetry channel that allow FSW and GDS to communicate?
The idea comes to me from @timcanham in his message.
Then at the code level it would probably be necessary to influence the Serializable class where a new Serializable class would be created that uses the source codes generated by the ASN.1 SCC for the encoding and decoding of messages.

References

[1] TASTE Overview https://hal.archives-ouvertes.fr/hal-02191871/document
[2] TASTE repo: https://gitrepos.estec.esa.int/taste/taste-setup
[3] ASN.1 SCC GitHub repo: https://github.com/ttsiodras/asn1scc
[4] ASN.1 SCC Overview https://www.thanassis.space/asn1.html
[5] ASN1 SCC - PUS-C library GitHub repo: https://github.com/n7space/asn1-pusc-lib
[6] ECSS PUS-C https://ecss.nl/standard/ecss-e-st-70-41c-space-engineering-telemetry-and-telecommand-packet-utilization-15-april-2016/
[7] Tailoring of PUS-C for Future ESA Missions https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2399

[ThibFrgsGmz]

I also transcribe @timcanham 's answer here:

This sounds like an interesting suggestion. Perhaps we could look at it in the future as a research proposal. Feel free to look through the F Prime layers and make some suggestions as to how we could incorporate what you are describing. We probably don't have the staffing at this point with our regular day jobs to take a deep dive at this time.

[ThibFrgsGmz]

Since then, I've had time to re-read the presentations from the 14th Annual (2021) Flight Software Workshop, especially the second day presentation by Peter Fieldman of Blue Origin "An Outsider's perspective on cFS" and some of the passages resonated with me.

(For contributors who don't know, cFS is like F Prime a NASA Flight Software framework developed by Goddard).

The presenter highlights concerns with cFS: there is a lot of "manual" message processing code and no pre-made data interchange format is used (slides 15 to 19).
The presenter suggested the use of the ASN.1 protocol, which automatically generates message encoders/decoders instead of writing them by hand.