Flight Software

About Onboarding Package

Satellite Flight Software is usually a modular subsystem wherein modules are built for individual pieces of hardware as the hardware is defined and pieced together when software modules are ready. With Model-Based Systems Engineering, those hardware modules are known from the beginning of mission planning, and software can be created from a holistic perspective rather than a piecewise, modular approach. ABEX utilizes the F’ (pronounced F Prime) software framework from the Jet Propulsion Lab to define its software architecture, organize its commands, events, and telemetry channels, and apply those to the custom C&DH hardware. F’ affords ABEX an incredible degree of flexibility and autonomy in software creation, built-in modules for unit functionality testing, and simplified hardware integration flows.

Technical Performance Measures

TPM	Rationale	Units
SLOC	The total number of lines of code compiled and stored on the spacecraft for all the subsystems. This is related to all subsystems and is usually between 150,000 and 300,000 for CubeSats, but higher numbers are possible.	N/A
Boot Memory Data Size	The number of bytes required to store the bootable Operating System image. The memory is non-volatile, read-only, and radiation tolerant at the expense of low storage capacity.	kB
Configuration Memory Data Size	The number of bytes required to store the software framework including all subsystems; this non-volatile memory can be written and overwritten in the event of component failure or Error-Correction Code application.	kB
Working Memory Science Data Generation Rate	The rate of science data provided from the Payload Interface Unit to volatile working memory. This data is written to the working memory in preparation for organization and encoding as part of the downlink telemetry message.	kB/s
Working Memory Diagnostics Data Generation Rate	The rate of diagnostics data generated by all software subsystems and written to working memory.	kB/s
Working Memory Event Log Data Generation Rate	The rate of event log data generated by all software subsystems and written to working memory.	kB/s
Working Memory Data Size	The number of bytes required to store the non-encoded science memory, diagnostics data, and event log data on the volatile working memory over a predefined period.	kB
Telemetry Memory Data Generation Rate	The rate at which telemetry messages are organized, encoded, and written to the non-volatile telemetry memory as a function of number of operations and assumed clock speed.	kB/s
Telemetry Memory Data Size	The number of bytes required to store a predefined number of downlink telemetry messages. Messages are stored over multiple downlink periods in the event that downlink messages are not received correctly and are requested.	kB

Analysis Tools

This content is coming soon!

Analysis Tool	Description	TPM
F Prime Prime	F Prime Prime is an open-source modeling language specific to F Prime model construction and analysis. F Prime Prime provides clean syntax, a tool suite for error checking and auto code conversion, and visualization of models for development. The ABEX Flight Software team uses this tool to build and visualize subsystem models that will be converted to C++ code for development.	N/A
F Prime	F Prime is an open-source flight software framework specific to small-scale flight systems. The ABEX Flight Software team uses this framework to create functional flight software running on a Linux operating system. F Prime is useful for the complexity of a CubeSat program like ABEX. It is modular and provides reusable code that has been proven to work on other spacecraft systems. It provides modeling tools, testing tools, and a ground data system for interaction between earth and the satellite. The framework provides autogenerated C++ code sourced from F Prime Prime models. The ABEX Flight Software team is responsible for developing mission specific code using the F Prime framework.	Configuration Memory Data Size Working Memory Diagnostics Data Generation Rate Working Memory Event Log Data Generation Rate
GitLab	The ABEX Flight Software team uses a private GitLab server to host code in a single version-controlled repository. This provides the functionality for CI/CD as well as an F Prime GDS deployment for testing. Hosting the flight software code on GitLab provides an easy onboarding experience for new students, while maintaining history on previous development.	SLOC
Docker	Docker is a containerization platform for packaging and deployment of images, which are essentially tools running under bare-bones operating systems. These can be customized and distributed and allow us to mitigate issues due to different environments by running tools and code under the same containerized environment. Overhead is low since the kernel is shared between the host and the container, and flight software development tools run in a headless fashion.	N/A

Architecture & Design

Satellite software architectures differ from hardware subsystem architectures. For example, C&DH hardware is not represented as a subsystem because it’s the computer running the software. Software subsystems are organized by purpose, with some smaller functions lumped into an “Engineering” subsystem. Design of satellite subsystems begins through an analysis of the requirements for that subsystem. Of importance is the hardware the subsystem will need to interface with, what data it will need to collect and share, how it will respond to outside events and commands, and how it will communicate with other subsystems. The software framework used by ABEX is the F Prime framework from the Jet Propulsion Lab, and F Prime is written using a modeling language called F Prime Prime.

Components within subsystems are designed in F Prime Prime; modeling components in F Prime Prime allows iterative development by retaining the history of each development stage in source control. After components are designed to specifications and require no major revisions, a C++ implementation is generated by F Prime, and behavior-specific code can be written.

Subsystem	Description	Components
Mode Management	Keeps time and current operation for the satellite. Handles transitions from one operational mode to another. Commands power subsystem to drive power to the subsystems pertaining to current mode.	manager powerInterface
Power Management	Controls the state of the transistors driving power to specific subsystems or a group of subsystems. Engages patch heaters when safety mode is triggered due to a thermal event. Exclusively driven by Mode Management operations.	power
Prognostic Health Management	Sends health pings and monitors overall satellite health. Determines likelihood of boundary-crossing thermal events. Controls entry into safety modes. Monitors conditions specific to start-up and shut-down operations for drift.	healthMonitor
Engineering	Handles satellite operations requiring hardware access, such as Solar Array Deployment.	SolarArrayDeployment EPSDataStream
Science	Parses data provided from the Payload Interface Unit.	manager payloadInterfaceUnit
Guidance, Navigation & Control	A wrapper for the software provided by Blue Canyon Technologies.	Proprietary
Telemetry, Tracking & Command	Handles all communication with ground, including encryption and decryption tasks. Processes scientific payloads for downlink by encoding output data to minimize atmospheric disruption. Sends decrypted commands to the dispatcher component for routing.	Manager Encoder Decoder
Thermal	Monitors temperatures within the spacecraft and communicates with Prognostic Health Management to ensure the satellite does not exceed temperature thresholds.	thermalControl thermostat
Fault Protection	Prevents faults caused by single event upsets (SEUs) from propagating and producing errors resulting in undesired system states through error detection and correction (EDAC) operations.	TBD