Issuing commands from one component to the others

[rawinza555]

Not sure if this already exists but I have been thinking that there should be a way that components can issue commands to other components. This command must be something that can be issued via ground command.

For example, I have component A that handle GNSS receiver and component B that handle a camera and I want component A to tell component B to take a photo at certain latitude and longitude. Right now, I can add a port that connect A and B together that trigger B to take a photo.

However, once a system has lots of components and requires lots of automation, I could see this becoming more complex. I'm wondering that if we have some sort of capability to connect component A to CmdDispatcher instead and issue command through this link. Since CmdDispatcher already have a capability of rerouting commands to its destination, this could make automation much easier.

[ThibFrgsGmz]

Would you like to make CmdDispatcher an ESB (Enterprise Service Bus), analogous to the Software Bus from cFS, which interconnects the different components/services and acts as a mediator to manage complex interactive events?

[LeStarch]

There are two ways of doing this:

1. Using the CmdDispatcher: this is accomplished by building a command object, sending the object to the command dispatcher, and letting the command dispatcher run it. This is done by the CommandSequencer, however; commands for command sequencer are built on the ground. Building command objects within the running embedded system is non-trivial as you need to assemble command ids, argument types, etc.

2. Using parallel Cmd/Ports on components. Most projects I've seen define ports and commands that share a common helper implementation. Commands come from the ground, ports are invoked by other components. This requires these redundant definitions for all items that would be invoked by command/ground.

The major trade-off is the complexity of building generic commands in the embedded system vs the extra definition of ports alongside commands. Most projects chose item 2, and limit the number of commands that are defined as ports to the subset that are strictly needed on board.

[JackNWhite]

I agree that this would be a good idea. It's not critical for what I'm doing, but my current platform is essentially at least a three-part space segment: two on-device computers, only one of which runs F', and an external superior computer. It would be nice to be able to send commands between the two on-device computers, in a standard format, and only having to deal with the byte-streaming device driver for the medium between them. If you're going to do that sort of thing, then the routing would likely be based on some field of the packet headers (and in fact this is a big part of my desire for Space Packet compatibility) such as an APID or service/system ID. At that point, there is no reason why an F' component could not simply set the field in the packet header for a local component and send the command to packet routing.

[SterlingPeet]

Having done custom command framing before the framer component was available, I would think that the easiest solution would be to have a component that routed the messages to different command dispatchers, e.g. on different devices, by looking in a field like the APID. This would be closer to tying the APID to an F Prime deployment or at least to a sub-topology with its own command dispatcher. This feels more like the intended use of the APID field to me. Sterling Sent from my mobile. On Feb 1, 2022, at 10:08 AM, Jack White ***@***.***> wrote:  I agree that this would be a good idea. It's not critical for what I'm doing, but my current platform is essentially at least a three-part space segment: two on-device computers, only one of which runs F', and an external superior computer. It would be nice to be able to send commands between the two on-device computers, in a standard format, and only having to deal with the byte-streaming device driver for the medium between them. If you're going to do that sort of thing, then the routing would likely be based on some field of the packet headers (and in fact this is a big part of my desire for Space Packet compatibility) such as an APID or service/system ID. At that point, there is no reason why an F' component could not simply set the field in the packet header for a local component and send the command to packet routing. — Reply to this email directly, view it on GitHub<#1233 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAO7KVTNNYZPWSTTNMI4YPTUY7ZN3ANCNFSM5MOXCTIA>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>