Fprime design pattern discussion for passive components

[DentOpt]

Hi,

The target for most space systems is to operate with mostly passive components to mitigate scheduling risks.Therefore you typically use a sequential execution pattern with normal function calls e.g. send necessary execution information and get the results back e.g. via reference. As example with a passive master component (MC) and passive slave components.

MC                                           SC1                 SC2
  │ ----exec(infotosend, &returnresults)--->  │                   │
  │ ---------------exec(infotosend, &returnresults)-------------> │

In Fprime that's an issue, as we want to be modular with all component, communication types. So a serialization is typically used to be compatible with a TMTC design pattern.

Here my questions

1. Is there any Fprime reference component that shows how a port with nontrivial return values is defined in xml and connected?
2. Did anyone look into possible alternative solutions with a return value serialization/buffer?
3. What are your design patterns for such a simple request response interaction with passive components while keeping modularity? E.g.

MC                                        SC1                  SC2
  │ -------------------exec- ------------> │                    │
  │ <--- setResultsInMemory--------------- │                    │
   -                                                            │
  │ ------------------exec------------------------------------> │
  │ <--- setResultsInMemory------------------------------------ │

Thank you in advance for your inspiration!

[Joshua-Anderson]

Here's an example of returning a complex type from a port call

You can return a serialized F' type like what you can see there, or just return a normal C++ object/struct

[LeStarch]

How your project handles moving data around is left up to the project. For passive components using guarded_input and sync_input port types, one can define return types on the port that allows passing data back as you describe above. These return types can be primitives, complex types, and pointers to memory.

For active components one typically uses a "callback" model where a port is sent, and the receiving component calls another port when finished. Return values are passed as arguments to this return port. This method comes with slightly added complexity as the source component needs both a send call and a handler to respond when finished.

In general, one first determines if the components need to be active/queued or passive. From there, an implementer determines the type of return data, and if a reference/pointer or pass-by-value scheme is needed. With these two decisions, a determination can be made. Passives use ports w/ returns and large types typically pass-by-reference. Actives use the callback pattern ans small types typically pass-by-value.