Interview with Dr. Guillaume Brat, lead for Robust Software Engineering at NASA’s Ames Research Center in California’s Silicon Valley
Innovation is key for space missions, and the longer the distance from the earth, the greater the need for innovation to support more autonomous operations. As such, NASA’s Space Technology Mission Directorate focuses on transformative space technologies to enable future missions to the moon, to Mars and beyond. And much of this innovation focuses on development.
In this interview, Dr. Guillaume Brat, lead for Robust Software Engineering at NASA’s Ames Research Center in California’s Silicon Valley, talks about the specific nature of developing applications for space missions, and how even space applications rely on open source components. Dr. Brat has more than twenty years of experience in software engineering, design, and assurance of flight software for aviation and space applications, including autonomous systems.
Q: What are some of the unique aspects of developing space apps?
A: When you’re developing code for space apps, you need to consider that the code will reside on a computer with a lot less computing and processing power, and with less memory than what we’re used to. So, we must be frugal with the size of our programs, and also be more predictable about how the code is going to execute. We might not use some constructs that are used in regular programming. For example, there is less use of pointers or virtual functions for C and C++, which are the standard languages that we use for space applications. Other languages, such as Java and python can be in applications on the ground station but not on the software that goes on board our spacecraft.
For developing these types of applications, we look to automobile standards like MISRA and AUTOSTAR, which include restrictions for what you can use, mostly for predictability purposes. For example, you can determine how much time it’s going to take to execute and how much memory a program’s going to need.
Pro Tip: MISRA and AUTOSTAR guidelines merged in 2019, creating a one stop location for developer guidelines under the MISRA Consortium for C and C++. Meanwhile, AUTOSTAR is still an active and independent set of standards with lead working groups in safety, security, and architecture.
Q: What type of security requirements should developers follow when building space applications?
A: They can look at the NASA NPR 7150.2 software engineering requirements. Some strict project standards went into that. The higher the criticality of the mission, the stricter the standards. Criticality is based on how bad it would be to lose the mission, and whether it can cause safety problems for humans. For example, a very high criticality would be new code that goes into the space station or gateway. Lower criticality would be code for a CubeSat, because it’s not so big of a deal if you lose a miniature satellite.
Q: Are there cases where code repairs must be made in space?
A: In shorter-distance space missions, we usually have the capability of uploading code from an earth-based console. But that is not always the case. For example, the space station is not remotely operated, and so, plans to operate the station are sent to the astronauts and the astronauts are the ones who are executing it onboard.
There is always the tendency to introduce more automation and autonomy, but that’s being done slowly. You’ll see more autonomy and automation in missions like the Mars missions, for example, because we cannot send a human there yet.
Q: How is open-source code used in space apps?
A: Some of the middleware frameworks used for space applications are publicly available on GitHub, such as the CFS/CFE Core Flight Software. Another component that is becoming more popular is the ROS (Robotics Open Software Framework), which is also available publicly, and a later version, ROS2 is more amenable to space applications. We’re currently working on a version of ROS especially for space applications, Space ROS, which will also be in GitHub in about a year.
Pro Tip: NASA also keeps its own open source catalog available for public use here: https://www.nasa.gov/press-release/nasa-software-benefits-earth-available-for-business-public-use
Q: What are the build cycles like in secure space app development
A: It really depends on the mission. We are mostly doing missions for small satellites or a space flight going to the moon, and for those, we use an Agile process. For the build cycle, we use continuous integration, which includes automatic testing and verification tools being run on the code—at least on the code that we develop. If we’re building the code on top of ROS and CFS open source components, we run the verification tools mostly when we get a new version of those components. A typical development cycle is about a two- to three-week sprint. It’s a lot of testing, including static analysis, which is a NASA requirement.
Some developers are annoyed with such a rigorous process, but I would tell them to be patient and put up with the process. These processes are in place for a good reason.
Pro Tip: Check out GrammaTech’s MISRA compliance documentation, which covers the most serious bugs in C, many of which arise from undefined behavior, such as buffer overruns and underruns, invalid pointer direction, double close, and more.
