Flight Path: A Microservices Message-Passing Flight Software Architecture for CesiumAstro Element One Satellite
Abstract
The CesiumAstro Element One Satellite, designed for multi-band phased array communications in Low Earth Orbit, required a new approach to satellite flight software. The variety of new devices on the satellite bus, fast-paced development schedule, and combination of in-house and purchased subsystems required flight software to incorporate a mixture of programming languages, a mixture of open source and proprietary software, and a pairing of high Technology Readiness Level (TRL) frameworks with new, first-flight software. To achieve integration, assembly, and test on compressed schedule, the flight software paradigm focused on microservices-brokered access to hardware and a message-passing based coordination between software modules. Success outcomes included mission end-to-end functional results in eighteen months from a team of seven flight software engineers, and integration of software modules from a variety of sources including the NASA Core Flight System (cFS) open-source framework in C, custom, internal guidance-navigation-control (GNC) algorithms in C++, graphical user interfaces in Rust, and vendor supplied APIs in a variety of protocols. Valuable lessons learned included leveraging POSIX Message Queues as a baseline for inter-process communication (IPC) among microservices in different programming languages. Message Queues coupled to IP Sockets enabled hardware-in-the-loop (HWIL) testing with external mission simulators such as Ansys System Toolkit (STK) and the open-source Basilisk Astrodynamics Simulation Framework. Opportunities for security advancement presented with the microservices approach, and opportunities for scaling the strategy to a variety of satellite architectures became apparent. Discussed results may be useful to new satellite programs looking to evaluate make-versus-buy decisions in flight software, and to organizations looking to integrate high-TRL frameworks from established providers with in-house, proprietary software for new payloads and experiments.
Flight Path: A Microservices Message-Passing Flight Software Architecture for CesiumAstro Element One Satellite
Salt Palace Convention Center, Salt Lake City, UT
The CesiumAstro Element One Satellite, designed for multi-band phased array communications in Low Earth Orbit, required a new approach to satellite flight software. The variety of new devices on the satellite bus, fast-paced development schedule, and combination of in-house and purchased subsystems required flight software to incorporate a mixture of programming languages, a mixture of open source and proprietary software, and a pairing of high Technology Readiness Level (TRL) frameworks with new, first-flight software. To achieve integration, assembly, and test on compressed schedule, the flight software paradigm focused on microservices-brokered access to hardware and a message-passing based coordination between software modules. Success outcomes included mission end-to-end functional results in eighteen months from a team of seven flight software engineers, and integration of software modules from a variety of sources including the NASA Core Flight System (cFS) open-source framework in C, custom, internal guidance-navigation-control (GNC) algorithms in C++, graphical user interfaces in Rust, and vendor supplied APIs in a variety of protocols. Valuable lessons learned included leveraging POSIX Message Queues as a baseline for inter-process communication (IPC) among microservices in different programming languages. Message Queues coupled to IP Sockets enabled hardware-in-the-loop (HWIL) testing with external mission simulators such as Ansys System Toolkit (STK) and the open-source Basilisk Astrodynamics Simulation Framework. Opportunities for security advancement presented with the microservices approach, and opportunities for scaling the strategy to a variety of satellite architectures became apparent. Discussed results may be useful to new satellite programs looking to evaluate make-versus-buy decisions in flight software, and to organizations looking to integrate high-TRL frameworks from established providers with in-house, proprietary software for new payloads and experiments.
