Home > On-Demand Archives > Keynote Presentations >

Flight Software Design for Lunar Exploration: A Case Study

Jacob Beningo - Watch Now - EOC 2023 - Duration: 01:25:36

Flight Software Design for Lunar Exploration: A Case Study
Jacob Beningo

A typical satellite flight computer will often directly control its propulsion system. Direct control, while convenient, adds hardware and software complexity to a flight computer system that is often already overburdened with duties. In the CAPSTONE mission to the moon, the Stellar Exploration Inc. propulsion module was used to uniquely decouple propulsive maneuvers from the flight computer to a propulsion controller.

This session will explore the techniques and tools employed to create robust flight software for Capstone's propulsion controller. Attendees will gain insight into modern development processes, tools, and techniques through real-world examples and learn how software architecture was broken down and implemented as a quasi-microservices architecture. Additionally, we will showcase how RTOS task code was modularized and how configuration tools were utilized to manage RTOS tasks automatically.

Topics covered in this talk will include:

  • Software architecture best practices
  • How to write mission configurable flight software
  • Modern development software processes such as unit testing, DevOps, etc
  • Flight software quality analysis
  • Examples from CAPSTONE, an Artemis mission to Lunar orbit
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 0 | 11 months ago | 1 reply

Thank you for sharing your knowledge! Maybe it's quite a late question, but still.

People often talk about space radiation and its impact on electronics. Especially "deadly" is considered the one the spacecraft meets beyond the LEO. Like a mystic dragon, it mercilessly burns out the silicon devices to ash if those are not prepared enough (RAD-hardened). :-)

So, is it really true? What is the average time to a complete failure for a regular off-the-shelf component, like a microcontroller or memory? What is the period between, for instance, consecutive single upset events (once a day or once an hour)? And are there any chances to watch over them using software techniques only? For instance, by the periodic check of the ROM and RAM content?

Score: 0 | 11 months ago | 1 reply

Thanks for the question.
How long memory / or a microcontroller will last will depend on a lot of factors. The radiation environment, the technology used, etc. Usually for a mission calculations are performed over the desired orbit that provide a statistical probability of how often SEU's, etc will occur.

Usually systems will employ memory scrubbing and checking to detect bit flips and other events that are caused by radiation. They are then corrected or may trigger a power cycle of the system.

Score: 0 | 11 months ago | 1 reply

Thanks for your answer.

I've asked that question because your lecture reminded me of a story once told by an ex-colleague. One day, he or one of his friends were involved in the development of the satellite, which was controlled by the numerous 8-bit microcontrollers (AVR or PIC architecture). I don't remember exactly how many of them there were. And unfortunately, I cannot ask him again, as he moved to the USA long ago. But definitely below 10. Probably that was an educational satellite built in one of the ex-USSR countries.

But I definitely remember that he has emphasized that numerous controllers were put there just for redundancy, so the satellite could survive for a while: if one dies, then there is still a few in reserve.

I was young and didn't believe him at the time. :-) But it seems like a common practice for certain applications.

Score: 0 | 11 months ago | no reply

Redundancy is definitely a technique that is often used in space systems. Education and smaller satellites might not make use of it. Watchdogs are critical and then redundancy for when there is a hardware failure. However, that adds complexity and cost so there are trade-offs that are made depending on what the end goal and life-time of the mission are.

Score: 1 | 1 year ago | 1 reply

Jacob, your presentation was fascinating. I can identify with your excitement of being a part of the project. In the 1980's, as a cooperative education student working at the General Dynamics facility in San Diego (Convair Division), I worked on the T- software to replace stript chart recorders for pre-launch monitoring. GD was working on adapting the Centaur to fly in the space shuttle bay. That never happened due to the dangers involved with the risk of an explosion of a fully fueled rocket in the bay. I was given a tour of the factory where the Atlas and Centaur were being built. The technician showing me around had me climb up a platform where I found myself next to the Atlas rocket farings. The technician grabbed and pulled me away before the rocket engines underwent gimble testing. It was a setup to impress me with the power and speed at which the engines can gimble. The technician told me, "If you had been standing where you were when the engines gimbaled, you would have been knocked off the platform" (about 15 feet above ground level.) It was an experience I never forgot. I was invited to go to an launch that summer, but decided to return to summer school.

Score: 0 | 1 year ago | no reply

Awesome! Thanks for sharing! Super cool!

Score: 0 | 1 year ago | 1 reply

One of the top 3 presentations so far at EOC 2023, straight from one of the co-organisers and renown embedded systems luminary. The topic - development of flight software for small satellites is top notch, even for seasoned embedded software development professionals. Concise, detailed presentation even without protected proprietary and confidential details. Without adding more 'noise' by my side - bow down mr. Benigo!

Score: 0 | 1 year ago | no reply

Thanks for the positive feedback. I'm glad to hear that you enjoyed the presentation! Enjoy the rest of the conference!

Score: 0 | 1 year ago | 1 reply

Following up on a question I put during the Q&A after the keynote:
since the purpose of the software architecture includes presenting the "principles guiding its design and evolution", how does the presented architecture guide the evolution of the Capstone Propulsion Controller ? Could you elaborate imagining new features added to the existing controller and how the architecture would guide us in including these new features ?

Score: 0 | 1 year ago | no reply

ah yes. So, the presented materials probably did not demonstrate this as well as the formalized architecture. There were a key pieces in the architecture that will help it evolve and will guide how to features will be added. (Since launch, the system has actually been scaled dramatically and is expected to be flown in nearly another half-a-dozen missions).
1) You'll remember I mentioned some principles that we used like "there is no hardware", "data dictates design", etc. These principles were used to guide the architecture to use abstractions that allow us minimize application dependencies on the hardware. This allowed us to scale and also simulate the application.
2) You probably can't tell from the diagrams presented, but we leveraged configuration tables and generated code. These allowed for the hardware, valves, pumps, sensors to be easily scaled and exchanged.
3) The architecture leveraged a micro-service like behavior using RTOS threads. New features can be added to the data flow to see what data it needs to consume, what the outputs are, and that will help to guide how that new feature will be implemented. There were communication structures that could be leveraged to broadcast data, which allows new tasks that contain features to be added. This allowed the application to scale without breaking existing infrastructure.

I hope that helps.

Score: 1 | 1 year ago | 1 reply

That was a great talk and covered lots of material from your book. I was wondering how much of your time it took to optimise your process and tools, vs day-day tasks of coding and testing in order to generate value? Did you have lots of regulatory requirements to fullfil as well, such as DO-178C?

Score: 1 | 1 year ago | no reply

Thanks for the question.
Yes, so a lot of the process and ideas that I use on a day-to-day basis to develop products are represented in the book. To some degree, writing books, articles, etc help me to think through some of these ideas.
In general, I don't consider my processes and tools to ever be efficient or complete. They are constantly evolving, scaling and adapting. I probably spend at least half a day every week thinking about how they working, where they can be improved, what should be changed, etc.
For this project, there were no regulatory requirements for the software. I believe there were some regulations related to storage of the fuel, etc. We did try to follow as robust of a process and code as we believed was necessary to successfully fulfill the mission.

15:02:26 From  RF  to  Everyone:
	Excellent Presentation let alone excellent product delivery, thank you.
15:03:07 From  bblatz  to  Everyone:
	Excellent Presentation
15:03:09 From  Aaron Olowin  to  Everyone:
	Thanks Jacob
15:03:49 From  Jacob Beningo  to  Everyone:
15:04:26 From  Linari  to  Everyone:
	How did you set up your target code to run on your computer system?
15:05:03 From  Rishav Vatsa  to  Everyone:
	what IPC protocols are generally used to communicate between sensors,actuators and MCU
15:05:04 From  Douglas Renaux  to  Everyone:
	Hi Jacob
	thanks to the excellent talk
	Could you go back to slide with the software architecture and explain how it would guide the evolution of the solution ?
15:05:28 From  apr  to  Everyone:
	Impressive project, thanks for sharing!What was your role resp. parts in this design and development?
15:06:04 From  Rishav Vatsa  to  Everyone:
	Replying to "what IPC protocols a…"
	for space communication in specific
15:06:33 From  Mohammed Eshaq  to  Everyone:
	How is your experience with Embedded File System (such as FatFs) in space applications? Is it recommended? Some might argue that File Systems are fragile and cause FSWs to crash.
15:06:39 From  Ribero.Alex  to  Everyone:
	Hi. Could you give us an example of some technical difficulty (in firmware) that you ran into during the development, and how you resolve the issue? Thanks!
15:07:11 From  George Addison  to  Everyone:
	Thank you for the really insightful talk! I was wondering how the details of the communications interface between the thruster controller and flight computer were hammered out? Did you produce an ICD that the flight computer team designed to? Or vice versa? Or somewhere in between?
15:09:15 From  David  to  Everyone:
	Say you are working at a company (startup of course….) that is bad at everything in the "embedded software triad". Where would you start focus on improving?
15:09:20 From  Thomas Schaertel  to  Everyone:
	Were you also involved with hardware development? What about redundancy in soft- and hardware? Did you also use radiation safe silicon? Can you also tell something about the costs of just the propulsion system?
15:13:26 From  RF  to  Everyone:
	You did comment briefly concerning target hardware emulation during the presentation, presumably because the actual final hardware target was not yet available at the time. What are your views ultimately on HIL / virtual modelling tools.
15:16:13 From  apr  to  Everyone:
	Can you share insights on why your changed from FreeRTOS to whatever-RTOS?
15:22:21 From  Aaron Olowin  to  Everyone:
	Were you able to end up with a RTOS-agnostic data-sharing scheme between tasks and modules?
15:27:21 From  Ulises V  to  Everyone:
15:27:34 From  René Andrés Ayoroa  to  Everyone:
	thank you Jacob
15:27:36 From  Vishwa Perera  to  Everyone:
	Thank you