Description

The command service is probably one of the most critical components of our flight software architecture, as it determines the satellite’s mode of operation. It analyzes the current state of the spacecraft using the Parameter Table, and determines which operating mode the satellite should be in. The goal of this task is to create the command service thread with the capability of executing the modes of operation and executing commands received directly from ground station.

The role of the command service is better described using this zoomed-in version of our architecture diagram.

            You can find the full diagram on the Firmware x CDH x Pay-Firm IDR slides 

The command service is essentially a finite state machine (FSM) that would use the values read from the parameter table to determine when to change to a certain mode of operation. There is also a special connection from the RF transceiver to the Command Service, to forward commands from the ground station directly to the Command Service. These commands allow us on the ground to force the satellite into a certain mode of operation. The RF Handler will update a message queue with a command struct that details the command type, any arguments and the trigger type. The trigger type will indicate whether the command needs to be executed immediately or scheduled for a given time.

Once the command service knows which operating mode the satellite needs to enter, it will awaken the Command Handler thread, which will then be in charge of awakening the corresponding operating mode thread and ensuring that the thread runs successfully to completion.

Your main points of contacts are:

• Firmware Design Lead
• CDH Design Lead

Tasks

• [ ] Verify that requirements below cover all required functionality of the command service
• [ ] Develop a plan for the functions that you will implement and create a test plan for unit testing
• [ ] Create the interface between the Parameter Table and the Command Service (The command service will only be reading the values stored in the parameter table!)
  • [ ] Please keep in mind that multiple threads will be interacting with the parameter table, so synchronization primitives are required
• [ ] Plan out the structure of the finite state machine (i.e. Determine how different inputs will cause transitions in the state machine)
  • [ ] Implement this finite state machine using the interface you developed in the previous step
• [ ] Develop the interface between the RF Handler and the Command Service, so that the Command Service can read the command message queue for anything uplinked from mission control
• [ ] Create the Command Handler thread and develop the interface between the Command Service and Command Handler. The Command Service should be able to communicate to the Command Handler about which thread to awaken in an effective manner
  • [ ] Optional: Implement the Command Handler functionality of awakening each of the operating mode threads when commanded to by the Command Service. You shouldn’t implement the functionality of each operating mode, that would be an entirely separate task. Just get the Command Handler to start waking up a couple threads that represent the modes of operation.
• [ ] Test the code against the test plan written earlier
• [ ] Ensure the code adheres to the Firmware Design Guidelines, and make a pull request on your branch

The command handler should be designed as a CSP thread, which has the capability send messages over a CSP connection or shared message queues