Integration of ASN.1 SCC in cFS

[ThibFrgsGmz]

Hi folks! I would like to discuss the possible integration of ASN.1 into cFS, in particular the ESA/ESTEC ASN.1 SCC.

Context

I just reread 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 passages stood out to me.

The presenter highlights some of the problems that cFS would have: there is a lot of "manual" message processing code and there is no pre-established data exchange format used (slides 15-19).
The presenter suggested using the ASN.1 protocol, which automatically generates message encoders/decoders instead of writing them by hand.

Not having been able to attend the workshop at the moment I don't know what the situation is, if there were any actions/reactions following this presentation.

Question 🤔

Is it planned to have ASN.1 to define Cmd/Tlm between two cFS based software?

If not, do you think it would be interesting for cFS to integrate the ASN.1 protocol by default, or optionally according to the specific needs of the projects?
If so, I would suggest integrating the ESA/ESTEC ASN.1 SCC version.

Rationale

Personally I am largely in favor of ASN.1 and more specifically ASN.1 SCC developed by ESA/ESTEC, and here is why.

ESA has been developing for several years its TASTE framework [1] [2] for flight software, such as cFS or F Prime. This framework is based on two key languages: AADL and ASN.1. It is the second language that I draw attention to 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 dependencies on an external library, has a tiny footprint, and generates test cases for code coverage.

I think this would probably reduce the complexity of interfacing cFS-based software communicating with other space segment software (SSEG) such as instruments (e.g., star sights), but also with custom ground systems, since they agree on the definition of Cmd and Tlm.

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

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

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

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

[jwilmot]

Although we have done a poor job communication this, Peter Fieldman’s comment of "no pre-established data exchange format used" was and is being actively addressed. There is a CCSDS standard data exchange format for cFS, “XML Specification for SOIS Electronic Data Sheet (SEDS)” https://public.ccsds.org/Pubs/876x0b1.pdf Peter was just not aware of the standard or tooling. The SEDS standards are also called out as requirements in the International Deep Space Interoperability Standards https://www.internationaldeepspacestandards.com/.
These standards are being used on NASA’s Artemis program with support from ESA, JAXA, CSA, and other international partners. ESA has a recent presentations on SEDS: Marek Prochazka (ESA/ESTEC) co-wrote a SEDS presentation “SAVOIR Electronic Data Sheet Definition: Overview and Status” https://indico.esa.int/event/338/contributions/5707/attachments/4006/5911/1400%20-%20Electronic%20Data%20Sheets.pdf
Richard Melvin ([email protected]) has a presentation on SEDS including TASTE (https://indico.esa.int/event/146/contributions/844/attachments/912/1094/05_-_Deploying_Plug_and_Play_Avionics.pdf Richard’s tooling also generates ASN.1 SCC from a SEDS. Please contact Richard for more information. Joseph Hickey (NASA) has also developed cFS code generation tools from the cFS SEDS interface definitions. There is a lot going on in this area and we would welcome any help in developing open source tools.

[ThibFrgsGmz]

Good evening Jonathan,

thanks for the reference on International Deep Space Interoperability Standards, I didn't know about it, very interesting.
Regarding the EDS, I am not yet comfortable with them.

I had read the CCSDS specification last year in my spare time as I regularly hang out on the CCSDS site.

In my company, we have no knowledge of EDS, some of our customers/prime contractors are starting to ask us to translate our GNC instruments ICDs to EDS format.
But it seems that our prime contractors are each using a different EDS format that needs to be filled in Microsoft Excel, which is a bit confusing to me as I thought the EDS format was internationally standardized.
I can hardly imagine adapting our ICDs to the EDS format of each of our clients...

Maybe CCSDS 876.0-B-1 for April 2019 came in late or our customers anticipated the EDS too much?

I will be taking a closer look at EDS as part of my study on cFS.

Do you have any recommendations on how best to capture/understand the EDS (file editor to customize the EDS, generate encoder/decoder source code in C language etc.).

Regarding cFS EDS, I was able to find several NASA projects on the subject of EDS:

• https://github.com/jphickey/cfe-eds-framework
• https://github.com/nasa/EdsLib
• https://github.com/nasa/cFS-EDS-GroundStation

Did I miss a resource I won't know about?

I chose to start with the cfe-eds-framework tonight.
So far I have some Lua related makefile errors when I run the commands defined in the README.md.

PS: thanks for the contact Richard Melvin, I'll contact him once I'm more in control of EDS!

[ThibFrgsGmz]

FYI, Richard's tool is the SAVOIR EDS Common Tooling (SECT), it is a Java library and command line application owned by ESA, developed by CGI and archived in the ESSR https://essr.esa.int/project/ccsds-eds-reference-tooling.

It appears to have been used as a reference implementation for interoperability testing under the CCSDS EDS standard.

The tool supports both code generation (intended for use in resource-constrained environments such as FSW) and an EDS interpreter that executes the EDS specification directly, without requiring a compilation step. This tool can generate ASN.1 message definitions and the corresponding ACN encoding specification.

[pmehradnia]

Hi @ThibFrgsGmz. Did you have much progress on the questions you raised in your post? What direction did you take?

[ThibFrgsGmz]

I didn't go into detail because it was a simple question to start a potential debate.

Personally, I don't know if ASN.1 is the most relevant serializer today. For example, I came across a benchmark of several serializers and ASN.1 would be the least efficient in terms of speed. Although there is always a trade-off between compression speed and transmitted message size.