How to deliver a software based on F´ to a customer to integrate it into his own software

[ThibFrgsGmz]

Hi there 👋

I have a question about delivering F´ based software to a customer for integration into their main software.

Let me go into a little more detail about this configuration.

Let's say a prime contractor designing a spacecraft wants a centralized architecture for cost reasons. This prime contractor then asks its instruments subcontractors to provide control software that it can integrate with its onboard software.
This means that the software used to control the equipment (star tracker, gyroscope, cameras, etc.) is not deported to different hardware platforms from the central computer, but run on the same hardware platform.

In this configuration, the spacecraft software does not communicate with the instrument software via hardware communication buses such as MIL-STD-1553, Spacewire, CAN, Time-Triggered-Ethernet, but by software means such as function calls.

I then ask myself different questions:

1- How to manage these different architecture configurations? That is to say, how to manage the project in both centralized and distributed architecture.

I would say that the project should be managed by default in a centralized architecture where it is clear in the source code which parts the client should also handle.
The client should call a constructApp function which would contain only the components that can be delivered to the client (not those that interface with the GDS for example). In this function there would be the functions <component>.init(), <component>.loadParameters(),<component>.start() and <component>.exit() so no <component>.regCommands().

2- What do we deliver to the client in terms of software, integration/usage procedure, communication interface? Keeping in mind that it should be very easy to use/integrate for the client.

In terms of software, I would say that we should deliver all components as static libraries with their header file. The disadvantage is that there would be a lot of files.

As an installation procedure we would ask the client to make some function calls contained in the constructApp() function of Topology.cpp to configure the different components.

For the usage procedure, the communication interface with the different APIs available to the client, it seems more complicated to me.

Let's imagine that we have two components, component A which is a service provider and component B which is a service consumer.
In F Prime, in order for component A to transmit data to component B, we need to call an autogenerated function of component A (example: this->mathOut_out(...)).

But in the case where component A, the service provider, is on the client side and component B, the service consumer, is on our side, I don't see how the client could pass the information to component B, except by redeveloping the whole logic of the autocoder.

3- What are the limitations imposed on the client?

At first sight, we require the customer to use a C++ compiler. If he develops in C, he would probably be tempted to ask us to make a C/C++ wrapper so that he can keep a C compiler to integrate the software developed with F´.

What do you think about this?

[sheershak-agarwal]

for the 3rd question: #842

[ThibFrgsGmz]

Thanks for your answer, unfortunately it is the opposite case described in your reference.

It is a case of instantiating classes and calling C++ functions from F´, from the client software whose implementation is made in a language different from C++.
For example, if the client software is in C language and the sources are compiled with a C compiler, the latter cannot integrate C++ code because it does not know how to interpret the keywords, the concepts of polymorphisms etc. of C++.

In general, if we want to integrate a C++ library into a C program, we have to develop a C/C++ wrapper so that the C compiler can interpret all the symbols in the library header file. And this is done in particular with the help of the external "c" tag.

[timcanham]

It's hard to give a standard answer to these, since it's dependent on how the integrator wants it. They could request just libraries, or they may wish to recompile everything. Either way, they would need a C++ compiler to process any C -> C++ glue code. To get from C to C++, a common pattern I've used is something like this:

header file for C code:

somefile.h:

void some_bridge_function(int somearg);

some C++ glue code file:

somegluecode.cpp

// this forces C function symbols
extern "C" {
   void some_bridge_function(int somearg);
};

#include "somefile.h"

myClass class1;

void some_bridge_function(int somearg) {
   class1.doit(somearg);
}

From C:

someCfile.c

#include "somefile.h"

void doSomeCThing(int arg) {
   some_bridge_function(arg);
}

[ThibFrgsGmz]

Concerning the integrator's need, we can assume that he wants a static library. The sources will have to be recompiled by the equipment supplier for the customer's hardware platform with the corresponding compiler. This is the classic and simple requirement that we are always asked for, except in TSP architectures where the format is slightly different.

I totally agree with you about the C/C++ glue code (that I call C/C++ wrapper), it must be compiled with a C++ compiler.
For me, it is not up to the integrator to develop this glue code but to the supplier of the instrument.

On this point I wanted to make sure that we were in sync and that I hadn't missed something else that makes it infeasible.

But I feel like the biggest problem is the inter-component communication mechanism where the serialization is autogenerated.
Since I haven't really looked into the details of this mechanism I'm not at all confident about it, I'm walking on eggshells.

From what I understand, we are forced to use this inter-component communication mechanism to transmit data between components.
Indeed, unless I'm mistaken, the available public methods of a component are only the constructor/destructor and the initialization. All other methods/handlers for port/commands etc are private.

In order for the integrator not to have to worry about an inter-component communication mechanism it might be necessary to make some methods of a component public. Thus the integrator would pass the data to the component by a simple function call.
And we could define this "public handler" configuration in the XML description file, but I don't know what impact this has and if it is possible.

[timcanham]

You can write a public method for the component that internally calls an output port to bridge the communication. There is no rule that you can't write your own public methods since it is your implementation. We commonly have public methods to pass in configuration data during initialization. It is less common to do it later in execution, but there is no reason you can't. The reverse is also true - if you want to send data back in to the C domain via an API or something similar, then you are in the C++ invoking C pattern again.

[ThibFrgsGmz]

If I try to summarize the approach to take, let's say I have :

• a component A, service consumer, developed with F Prime and named compA
• a component B, service provider, developed in C language by the integrator, component named compB.

In the XML of compA, I define a port corresponding to a certain service data unit, for example an array of four floats.
When implementing compA, I will then have a private method private_method_compA in charge of handling the data of this port.

I must then manually define an interface function public_method_compA whose declaration will be in a header file "header_C_compA.h" interpretable by a C compiler. As for its definition, it will be in the compAImpl.cpp file and will only call the private_method_compA method.

The integrator will then only have to link the static library of the compA component and include the header file "header_C_compA.h" in its compB component developed in C and thus communicate with the instrument software, based on F Prime, by simple function call.

Does my description sum it all up or are there some things missing?

[timcanham]

My suggestion was more along the lines of your component B being an F Prime component that interfaced with the C module (not calling the integrator code a component to not confuse the terms). The glue code would call a public function in the B component which would internally call an output port connected to component A. That way component A can be kept isolated from component B and the C module for testing. The library can have the F Prime deployment with interconnections between any components you use.

[ThibFrgsGmz]

OK, I see what you mean; this appears to be more elegant because it decouples the F Prime topology from the glue code more than my method.

This component B would be the cross-cutting glue code for all F Prime components in your method, correct?

The major disadvantage of my method was that instead of centralizing them, I created a C/C++ interface for each component that interacted with the integrator.

This would also improve the operability of the instrument software for the integrator, as they would only have to use one interface file. And it is always possible to combine all of the static libraries of the F Prime components into a single library, saving the integrator from having to link dozens of libraries.

I feel that in order to be able to deliver software in both centralized and distributed configuration in a transparent way, we need to implement component B glue code by default.
This component B would serve as a hub for all data input and output from the instrument software system.

• In a centralized configuration, the integrator, for example, uses the instrument software via simple function calls provided by component B.

• In distributed configuration, the integrator communicates with the instrument software via a hardware bus with Cmd/Tlm. And the components managing Cmd/Tlm/Event in the instrument's software system developed with F Prime must connect to the B component.