Skip to Main Page Content

Flight Software (FSW) Overview

The Flight Software (FSW) is what enables the spacecraft to perform all operations necessary to facilitate the science objective and perform maintenance tasks for the spacecraft. The FSW is operated from an On Board Computer (OBC), which acts as the “brain” of the satellite.The OBC is the link to all peripheral hardware and acts as the central entity for sending commands and collecting all housekeeping information. Of all of the subsystems, the FSW is therefore one of the most critical to ensure is robust. 

The flight software team was responsible for developing hardware-specific applications which could execute operations automatically or via a ground command. Engineering and Flight Models were purchased for each component that was to be part of the spacecraft, allowing the student team to develop and test software on the same hardware that would eventually be put in space. In addition, to get the CubeSat to an operational state, it was essential that the FSW team work directly with other subsystem teams to develop software requirements and ensure that all functionality was thoroughly tested in various conditions before it was declared complete.

The team used an iterative development methodology to achieve the key functionality that the spacecraft needed - starting from basic requirements and then refining functionality to be more efficient once the original method had been developed, tested for various cases, and validated. 

 

Partnerships

The flight software incorporates NASA’s Core Flight System (cFS), a software framework developed by the NASA Goddard Space Flight Center to provide mission-independent and re-usable services.  As the team developed the software applications, cFS was incorporated into the application framework to help bring everything together. Additional support is leveraged from NASA’s STF-1 mission. This partnership provides the team with access to free ROTS software for use in developing satellite command sequences.

FSW Applications

The following is a list of all satellite applications that were developed to facilitate the mission and a description of their basic functionality: 

  • Adcs driver
    • Responsible for converting commands from command ingest to a form that can be used by the adcs application.
  • Adcs tlm (Adcs Telemetry)
    • The ADCS writes telemetry at a 4Hz rate, which is too much for the OBC to process. The ADCS telemetry app is therefore responsible for parsing adcs telemetry on command so that mission operators can still assess the health of the hardware
    • ci (Command Injest) 
      • Interprets commands given through a schedule file and sends out those commands in accordance with the times set within the schedule. In addition, CI has a feature that allows commands to be executed immediatley in case of an emergency.
      • Camera Manager & Driver Applications 
        • The camera manager acts as the go between operations commands and the driver.
        • The Camera Driver is responsible for processing commands that are specific to the payload. This includes: taking images, transferring images to the flash memory, and collecting other telemetry from the camera during imaging passes that is necessary to understand the state of the payload at the time of imaging, such as getting the temperature of the Focal Plane Array. 
      • eps mgr (EPS Manager) 
        • The eps manager is responsible for both the operations handling and lower level processing of commands. It performs no smart functionality or power management. It simply does as it’s told and records telemetry. It does however check on whether or not a power rail has turned off or on by checking that the rail’s voltage is within a ‘reasonable’ range from expected.
        • gpio lib
          • Handles switching between gathering data from the payload or the ADCS, as both devices share the same UART line
        • GPS Driver and Manager Applications
          • The GPS manager acts as the go between operations commands and the driver. Commands are passed to this, and processed in the driver
          • The GPS driver application handles the execution of all commands and collects telemetry from the GPS module. This includes collecting the time and position from the GPS satellites and all GPS housekeeping information. Finally, the driver handles parsing the output from the GPS to only collect the information that is needed. 
          • Telemetry Applicatoin
            • Regularly retrieves telemetry information from the other hardware control apps and writes that data to a file which can later be downlinked and processed by the mission operations team. 
            • The telemetry application also handles writing status logs, which are meant to divulge events that occur during operations. For example, when a command fails to process, this event is written to the most recent status log so that operators can assess whether anything went wrong during an imaging flyby. All status logs are titled based on the date and time of day at which information was written so that it is easy to collect status logs based on when imaging passes or other operations were scheduled. 
          • UHF Manager Application
            • Processes all communications events and hands off data to command ingest when necessary. Also responsible for the heartbeat transmissions.