Note: We're working on getting new videos together. In the meantime, go ahead and turn up your volume.
Vehicles have all sorts of data zipping around. Your sensors are collecting information, your functions want information, you want to send information... managing the chaos is easy when you only have a few things going on. But the problems get increasingly wild with every new feature you add.
What might work for you: One way to wrangle the madness is to have each function keep a list of functions it should send data to. This creates a cascade of functions where your logic flows from one function to another, like a Matlab or Python script. A variation on this is to have functions store data and send it when called by another function that knows to ask them.
That can work great for simple systems when one person can remember where all the connections go. And it can work well for complex systems if teams have great documentation.
Why this tends to stop working: What happens if you want to add a new feature like a sensor or algorithm? You've got to update all the functions that need to talk to that function. And you might have to rearrange the order of functions calling each other.
Or what if you need to remove a function during flight? For example, maybe one of your sensors stops working. Your cascade of functions needs to be updated to remove all calls to it. Again, no big deal if you have a simple system. But if you have a complex system developed by multiple people then things can get out of hand fast.
One more consideration: What if you need a way to stop everything if something bad happens in another part of your system? If you're cascading through functions, you might not know to stop until the end of the sequence of functions. You could write a "check for bad things" function every time there's a new call to a function but that can get messy fast.
There are solutions to these things but maybe there's a more robust solution you could start with from the beginning?
What might work better for you: cFS uses a Publish/Subscribe approach. This means some of your systems Publish information to a central location. Any part of your system interested in that data can Subscribe to it. The central location will let them know when new information comes in to process it. If there's no new information then nothing happens. It's easy to add and remove features because everything only needs to talk to the central location, not each other.
And the central location can look at messages coming in and see which ones are critical. It will make sure those things are handled first.
An example:
You have a robot that sorts colored blocks. There are red, blue, and yellow blocks and they come one at a time. Different blocks get picked up by different robot arms. So red blocks have a red robot arm that picks them up and yellow blocks have a yellow robot arm that picks them up.
In the cascade approach, your camera would detect the color and your code would look something like, "if block is red, then call this function". You would hard code each color into the detection algorithm.
In the Publish/Subscribe approach, your camera would tell the central location that the block was red. The sensor would have no idea what happened after it told the central location. Meanwhile, the central location would see who wants to know about red blocks and alert the functions that cared. Functions can subscribe/unsubscribe and no new code has to be written.
Either way works just fine when there are three blocks. But what if there are hundreds of colors and patterns? And what if some robots can pick up four or five combinations but other robot arms can only pick up one type? In the cascade approach, you might be writing hundreds of lines of code, carefully mapping each function. In the Publish/Subscribe approach, you'd only have to have your robot arm subscribe to the colors and patterns it can handle.
As of version 7.0, NASA provides their Publish/Subscribe approach as the Software Bus and Message Module. These both live in the "Core Flight Executive" layer because they're so handy for everything your system wants to do.
The Software Bus: This is the "brain" of the operation. Your sensors publish data to this brain, it looks up in a table to see who subscribed to the data, and then it alerts them. If you've not heard of a "bus" before, it's called that because it "carries" information.
The Message Module: This helps you define the format of your messages. For instance, what is your message label and what kind of data does it carry? This makes it easy for you to package data from a sensor into a common format that any function can learn to unpack.
- NASA follows the CCSDS standards for messages. (CCSDS stands for the "Consultative Committee for Space Data Systems".) This means that, if you care, you can follow their rules and your customers are much more likely to sign off on your code. You don't have to follow the rules if you don't have that requirement but you probably should since you never know when you'll want to reuse code or somebody who doesn't know what they're doing makes up a bad format.
- In the code, you'll see the abbreviation "SB" for Software Bus and "MSG" for Message Module.