Question about application API's

[tstern-masten]

Hello!

Still getting up to speed with cFS so apologies if this is a "remedial" question.

My question is, is there a centralized point for application API's and specifically message ID's or are they all contained within the application tree? I want to be able to have external processes easily interface with applications and it would be nice to have some common library or source to link against.

For reference I am currently using the OSK release so I am not fully up to date with the latest cFS releases, but I believe I read somewhere in OSK that there were future plans to centralize the message ID's and add tools for generating those sources.

Any and all help is greatly appreciated!

[jbohren-hbr]

@tstern-masten you've touched on a very popular use case.

In the main cFS distribution, Message ID / Topic ID and type definitions are currently only specified in C header files. There is a big push from the community to embrace the (CCSDS SOIS EDS standard](https://public.ccsds.org/publications/SOIS.aspx) for specifying all of these interfaces in XML which can be processed by the NASA EDS Tooling. The approach leveraging EDS would allow you to generate interface source definitions for whatever external system you need from a single source of truth.

There's a fork of the cFS distribution which shows how the EDS files can be used and processed here: https://github.com/jphickey/cfe-eds-framework/

See the following discussions for more info:

• Ground System and Remote Dev Environments #307
• Using EDS with cFS #284

cc @jphickey

[pmehradnia]

@tstern-masten I am curious what tools you have come across to convert SEDS to XTCE, and also, what general direction did you take with regard to integration of the EDS? Thanks :)

[tstern-masten]

We actually pivoted slightly in our approach. We found a open source tool called auto-yamcs that allows us to generate XTCE from our cFS binaries formatted for our ground software. With a little effort I was able to get it to work with cFS 6.7.

[pmehradnia]

@tstern-masten Interesting. Did you have to structure the cFS binary in a particular way? Does it take in the various Application .so files as input and generate the XML at the output? I am assuming you didn't pursue CCDD?

[tstern-masten]

The auto-yamcs tool is made up of several smaller tools that parse the cFS binaries and generate XTCE.

The first one, Juicer, you run recursively on any exe's or .so's that you want to build XTCE from. This tool generates a single SQLITE database of all the symbols in the passed in binaries. The only tricky thing here is the symbols have to be used in the code somewhere so you may have to create an _symbols.c source to actually define a symbol for juicer to parse (More detail on that here: WindhoverLabs/xtce_generator#41).

From there you run it against the next tool which is tlm_cmd_merger that takes in that database and a YML config file defining the telemetry, commands, message ID's, etc. and generates another SQLITE database.

Finally that database is converted to an XTCE.xml with the xtce_generator tool which is comes pre-formatted for import into YAMCS.

Given that we plan to use YAMCS, this solution was perfect for our needs and I have been really pleased with the documentation and support from the Windhover Labs team.

[pmehradnia]

Thanks Tim. We will look into this - your guidance is much appreciated!
-Payam

[skliper]

I bit of additional background on the mechanics - although apps typically do include a header that defines their message ID's, these are really just intended as the default such that it's trivial to plug-and-play with the open source framework. For a real distribution the defaults are typically all overridden with headers that are maintained within the *_defs directory (which is "owned" by the distribution). This approach avoids the need to "clone-and-own" or modify anything within the related open source repo. Your *_defs directory then becomes the "one-stop-shop" for all these definitions, which in turn are frequently generated via a data management system like https://github.com/nasa/CCDD or similar utilizing EDS or other common data description techniques. Using this technique you can create a single header that includes all the various distribution mission ID headers, or whatever grouping you need to make things easy to manage.