NTB: You mentioned software. How important of a role does software play in flight control systems?
Frost: I'm somewhat biased. I would say that software really is the role in flight control systems. Hardware is a distant second. I'm a software guy, so I'm a bit biased about this, but I think it's fair to say that software is playing an increasingly large role in control systems, both for aircraft and for spacecraft, and for several reasons. Where we're looking somewhat into hardware advances, some of those advances are smarter bits of hardware. And that typically means embedded software into that hardware. We're also looking at distributed systems of hardware, and now that we have those embedded systems and the distributed systems, plus the original control software you'd normally need, you now have to have the software required to interconnect all of these systems of systems, plus the additional software required to meet the expectations not delivered by hardware. Of course, that includes software to deal with fault detection and fault management from this now very complex system. You can sort of see this mushrooming effect, and software is really central to it all, and evermore so. Being a software guy, I'm somewhat biased, but I really think that software is the central role in flight control systems and for the future.
NTB: How much of a role do you play in writing the software itself?
Frost: I've been a manager for some years now so my hands-on-the-code is not what it once was. I have a whole collection of little software utilities I've written over the years, mostly to do simple analyses and stitch together other pieces of software, or manipulate files the way I want. I think that's true for most of us. We make these little tools all the time, and occasionally they turn into something bigger.
As a bigger organization, we're really trying to build very open tools whenever possible, to make them as broadly useful as we can, and sometimes that becomes a real challenge in itself. Should you make something that's very useful but does just one specific thing, or should you invest more time to build a more general solution? I think that's really reflected by my team's leadership in NASA's open source initiative. We have a considerable number of software tools and libraries available under the NASA open source agreement as well as more typical, collaboratively developed projects that are out there, where people can contribute as well as use the software. So no, I don't have a day-to-day, hands-on-the-code kind of experience that I did when I was younger and just working as an engineer on projects, but I like to think that I have maybe more instruments in steering our directions than I once did.
NTB: What is your day-to-day work with flight control systems?
Frost: I'm really just a lowly manager these days. I don't have a lot of "hands-on" on any single project, and I've been in that kind of a role between the last 5-7 years, I'd say. So my daily involvement isn't really what it once was, and I miss that. I do try to participate in our project meetings, both at the beginning and the middle and the end of the process. I think the initial brainstorming about how to solve a problem, or what approaches we might use to achieve our research objective, is really quite fun and satisfying.
During the life of a project, there are also many opportunities for me to learn from our researchers and engineers, and as a project comes to fruition, I'm typically looking around at how we can get whatever we have developed out into the public, where the taxpayers' investment in NASA can see some return. These days I get my satisfaction from being involved in all these phases, even though I'm not necessarily developing control algorithms or systems myself.
NTB: You've done a lot of research simulating the handling qualities of spacecraft, including lunar landers. What conclusions have you been able to draw from this kind of work?
Frost: That's one of the ways that I've tried to keep my foot in the technical world a little bit. NASA started this project because no work had really been done, since the Apollo era, on how spacecraft should fly, and even then it was quite specific to the Apollo spacecraft configuration. We wanted to establish boundaries more generically for what constituted good spacecraft handling qualities. There are several papers now written on this, and there were a lot of co-investigators on this project: D. Bilimoria, Eric Mueller, Randy Bailey, Bruce Jackson, and myself.
For crewed spacecraft, even in the case of a nominally, fully automated spacecraft, it's vitally important to consider how it will fly under the control of a human pilot. In that particular case, the human might well be trying to fly it under the worst possible conditions because the automation would've failed for some reason. Thus it's important that the spacecraft fly well even in its most degraded state. We found that there's definitely a sweet spot in the control characteristics for lunar landers. Piloting spacecraft is definitely aided by intuitive displays in the cockpit. Astronauts truly have the "right stuff" when it comes to flying spacecraft. None of that is a particularly new revelation. It mostly backs up what's been observed or obtained through early experiments in the Apollo days and somewhat worked with the shuttle. The details that we published in these papers that I mentioned are what will be useful over the long-term, as NASA and our commercial providers in the future work to define how spacecraft really should be.