EPISODE 109: NASA ENGINEERING AND SAFETY CENTER

Transcript

Tim Wilson: Nobody wants to see a mission fail. Nobody wants to see a risk accepted because the underlying technical problem couldn’t be resolved.

We exist to make programs and projects successful, and to enable safe flight for NASA’s critical programs.

Our teams are independently funded, they’re independently constructed, and they’re pieced together from technical resources available to us from just about everywhere.

Deana Nunley (Host): Welcome to Small Steps, Giant Leaps, a NASA APPEL Knowledge Services podcast where we tap into project experiences to share best practices, lessons learned and novel ideas. I’m Deana Nunley.

The NASA Engineering and Safety Center engages proactively with NASA missions, programs, and projects to help the agency avoid future problems. The NESC maintains a broad, diverse knowledge base, keeping informed and engaged with each NASA center, and performing independent technical assessments for some of NASA’s most challenging and demanding technical issues.

Tim Wilson is the director of the NESC and joins us now. Tim, thank you for being our guest.

Wilson: Absolutely, Deana. Glad to be here. Thank you.

Host: Sure. What led to creation of the NASA Engineering and Safety Center?

Wilson: We were created shortly after the Columbia accident. And, at the time, Admiral Gehman made a comment during the investigation that some NASA organizations and, in particular, he was picking on Safety, attend the Flight Readiness Reviews. They make inputs along with everyone else. But in his view and the view of that panel, there was no strong technical resource behind them to substantiate what they were saying. In his words, ‘There was no there there.’ So, we were created, in part, to fill that gap, and to give agency leaders and to give programs a place to go for independent technical support. So that’s really where we came about.

Host: What’s the primary focus, or mission, of the NESC?

Wilson: Flight safety. We exist to make programs and projects successful. And to enable safe flight for NASA’s critical programs. That’s really what we’re all about. That’s our intent, focus.

Host: How do you provide independent testing and analysis of NASA’s high-risk projects?

Wilson: Yeah, that’s a good question. So, we’re structured such that we report to the NASA Chief Engineer, which makes our reporting chain independent of programs. Our funding comes through the Chief Engineer’s Office, which again makes us independent of programs and projects. And we put teams together with resources drawn from across the agency, academia, industry, other government agencies to go work on problems. So, our teams are independently funded, they’re independently constructed, and they’re pieced together from technical resources available to us from just about everywhere. And we use that resource then, to go tackle problems.

Host: So, what’s involved in identifying and addressing potential concerns before they become major problems?

Wilson: It’s not complicated, really. We’re plugged into most, if not all, of the agency’s critical activities. We have folks who participate on boards and panels who, they’re kind of our boots on the ground, literally watching for issues, or being cognizant of what’s going on, and prepared to hold their hands up if there’s something that they feel hasn’t been adequately addressed.

We participate, as I said, in those things. We also have a function internal to the NESC that looks for trends and it looks for issues that recur across programs and projects. And we try and bring those forward.

I think probably the best answer to your question is ‘where do our requests come from?’ And they come from just about everywhere. Programs, projects, engineering, directorates reach out to us, and ask for our involvement in the issues that they’re having. So those sources are really where the work comes from. And they’re where we identify issues that need to be targeted. Does that make sense?

Host: That does make sense. So, they really want your help.

Wilson: They do. So I will tell you, when we started this 20 years ago, we kind of felt like we had to elbow our way in, right? Folks weren’t sure of who we were. They weren’t sure of what we did. Didn’t really understand what the function was. Didn’t feel like they needed us for what, I’m sure, are obvious reasons.

But as things have evolved over time, I think our success, our ability to add value to what programs are doing has spoken for itself. And in today’s world, folks reach out to us. It’s very rare for us to see an issue that we think hasn’t been adequately addressed. The vast majority of our projects come directly from requests from programs, or from engineering organizations seeking our help to get a problem resolved.

Host: So then, how do you set priorities for the work?

Wilson: We have our own priority list, I guess if you will, with flight projects, or projects that are in flight, having an in-flight issue being our top priority. Second being projects that are in development, that are coming together, that are preparing to fly. And then three, four, and five relate to things that other folks may not be working that cross program boundaries, issues that pop up with program A, and maybe pop up at program B too, and program C, and no one has the resources available to go tackle those in and of themselves. So those are our third and fourth priorities. Then, we also do some discipline-advancing work where we try and build tools and build resources for the technical disciplines to improve their capabilities. So that’s really the way our priorities lie: projects in flight, projects that are coming along in work, and then things that cross program boundaries, or enable technical disciplines.

Host: So, this top priority — projects in flight – would refer to missions that have already launched.

Wilson: Yes, absolutely. So, in today’s world, it’s the International Space Station. It’s a Commercial Crew Program mission that happens to be flying. Or it’s Artemis in-flight, or it could be any other robotic missions that are active and flying.

Host: Is it harder to solve problems in-flight?

Wilson: It’s much harder. And the reason is usually those things, they’re spur-of-the-moment things. They’re events that need to be addressed quickly. It’s a little more difficult to move resources, and to get the right folks plugged in to get things done. So, it’s more difficult because of the real-time nature of the work typically than it is for, say, a program in development where the pace is — maybe not to those folks but to us — it’s a little bit more leisurely. It’s a little easier to pull a team together, and go get the work done. It doesn’t have the sense of urgency, or the sense of immediacy that a flight program would have if they have an issue in-flight.

Host: Would you say the majority of what you’re working on is in the development phase?

Wilson: It is. The bulk of our work right now is programs that are in development. A lot of it’s the Commercial Crew Program. Artemis consumes a significant amount of our resource as well. Gateway has begun to ramp up, and they’ve asked for assistance in a number of areas. So, they’re beginning to consume some of our effort. And the HLS program as well has begun to consume some.

Then, there’s the whole spread of robotics missions that we provide some technical assistance to as well. So that accounts for the bulk of what we do. So not nearly as much in-flight, and not nearly as much discipline-advancing or cross-program type activities as there are for programs that are putting hardware together.

Host: Do you see these requests to provide support to programs such as Artemis, Gateway, and the Human Landing System as kind of the fruits of the labor of the past 20 years as different programs and projects seek help from the NESC?

Wilson: I think so, absolutely. It’s difficult to find a place at the table when folks aren’t interested in what you’re providing, and they don’t see the value. When they appreciate the value that you bring, then they’re eager to have the help. Everyone wants to do the right thing, right? Nobody wants to see a mission fail. Nobody wants to see a risk accepted because the underlying technical problem couldn’t be resolved. And I think they’ve come to see us as a resource to help get to the bottom of those things, and add value to what they’re doing. So, it’s evolved from elbow your way in, which is really how we started, to an environment in which folks ask for our help and seek us out.

The other piece of our evolution has been from trying to act independent of a program totally. We were seen sometimes as doing our work, and building results, and throwing them over the wall. And that’s difficult for a program to accept those kinds of things. So, we’ve tried to work in a more collaborative fashion over the last few years. And I’d say all of our work now is done in collaboration with programs. So, some of their folks sit on our project teams while we’re trying to resolve an issue. And we work interactively with them to get things done. It’s much more collegial than it was in the early days. And I think it’s been much more successful, and we’ve added more value doing work that way.

We still maintain our independence through our reporting chain, and through our funding model. But we can work with the teams that we’re engaged with, and get things done in a much more effective fashion doing work this way.

Host: How does the NESC assemble Technical Discipline Teams?

Wilson: Yeah, Technical Discipline Teams are really the muscle that gets the work done. We have 20 Tech Fellows. And each of those Tech Fellows maintains a team of folks from their discipline, their technical discipline, whatever that might be. And we really lean on them to reach out and find the right folks. I mean, if you’re the agency’s Guidance Navigation, and Control Tech Fellow, you’re the agency’s expert in that field, you probably know who the other agency experts are, and you know who to reach out to, and you know where those resources are. So, we count on them to pull those teams together, and build an effective tool, if you will, for us to reach back to when we need help to solve an issue.

So, 20 Tech Fellows each maintain a Technical Discipline Team. Those folks are drawn from across the agency, from academia, from industry, from other government agencies in some cases. And they meet on a more or less active, regular basis, monthly to talk about agency issues, and things that are taking place. They meet face-to-face once a year, same sort of a model to understand what’s going on, and to stay connected so they know what’s going on within their discipline and what the needs are, where the weaknesses might be.

Then, when we pull a team together to go resolve a problem, they become the primary source of expertise to get those things done. So, a task lead, a principal engineer, for instance, will reach out to the Tech Fellows for assistance depending on what the nature of the problem is, and the Tech Fellow helps route those folks to us.

Host: And then, what’s the approach for creating solution-driven reports with preventive and corrective recommendations?

Wilson: Yeah so, reports are the documentation that communicates what we have done to programs and projects, or to others who are interested in our work. So, they’re like the final product that we create after we complete an assessment. So, the assessment team does the work, whatever that might be, a test, or an analysis, or some other activity. And they document everything they did along with their findings, observations, and recommendations in detailed technical reports. And those reports are peer-reviewed. They come to the NESC Review Board, and then we approve them for release to the project or to whatever stakeholder might have asked for the work.

They can form the basis for other products that we release. We try and communicate our work between programs so that we maximize the impact of what we’ve done. So, the reports are a way to do that, but that’s really how they come about. They’re the final product that comes about as a result of the technical assessment.

Host: Tim, what are the biggest technical risks NASA faces in the near future?

Wilson: Oh, there’s a host of them, as you might well expect, right?

Host: Mm-hmm.

Wilson: I’ll tell you, in my mind, probably the biggest thing that the agency struggles with, believe it or not, is parachutes. And making parachute systems safe and reliable for human spaceflight. You would think over 50 years, or much more than that actually, of flying parachutes on aircraft we would have that down to an art. But it’s really not. They’re non-deterministic systems. They’re incredibly difficult to model. Their behavior is difficult to predict. Unlike system-like wings and landing gear where we’re confident we understand how they’re going to work, parachutes are a much different beast, and they’re much more difficult. So I would say parachute systems are one of the agency’s biggest risks.

We struggle with other systems. Valves for some reason, have been difficult to deal with, and multiple programs have struggled with valve failures. They’ve impacted launches, they’ve impacted missions in-flight, and they cross many program boundaries. So, numerous programs deal with those issues and with those mechanisms and the complexities that underlie them. Building solid, reliable hardware is difficult in that case. But it does pose a challenge.

I’d say, going forward into the future for the Human Landing System to work, we’re going to need to master on-orbit propellant transfer. And that technology really is in its infancy. So that’s a technical challenge, and it poses a risk to the agency going forward, and it’s another broad cross-cutting one that’s going to need to be tackled.

So, in my mind, those are the top three. There are others, certainly, but we try and target those with some of the work that we do.

Host: How would you summarize the NESC’s impact to date on agency mission success?

Wilson: I think it’s been profound. Not only the things that we provided, the discrete products that we’ve developed, the questions that we’ve answered, the value that we have added to programs and projects,right? Those are the things that you can look at and see. But we’ve had an impact, I think, in other ways that isn’t so obvious. It’s kind of like the movie, ‘It’s a Wonderful Life,’ right? You don’t know how the world would’ve been if you weren’t in it until you’re able to see it without you in it. And we’ve had that kind of an impact on the agency.

I think, we have added value in that way by stressing engineering excellence to programs and projects, and helping them adopt a data-driven, prove-this-is-correct mindset as they go forward. We’ve had an influence on younger engineers as they’ve come up, as they’ve had a chance to work with our Tech Fellows, and work with our technical experts. And I think that has influenced the agency in positive ways that you can’t really quantify. In fact, I’d say that influence has probably been of more value to the agency overall than any of the specific discrete products that we’ve delivered. But yeah, I think our impact has been profound and we’re going to continue to make that impact as we go forward.

Host: So interesting. Tim, thank you so much for taking time to talk with us today.

Wilson: Absolutely. Glad to do it.

Host: Do you have any closing thoughts?

Wilson: I thank you for the time, and for the opportunity to let folks know what the NESC is, and what we do. Folks should know that we’re available to anyone in the agency who needs technical assistance, and they’re certainly free to reach out to us.

Host: Tim’s bio is available on our website at appel.nasa.gov/podcast along with links to topics discussed during our conversation and a show transcript.

If you have suggestions for future guests or topics on the podcast, please share your ideas with us on Twitter at NASA APPEL – that’s app-el– and use the hashtag Small Steps, Giant Leaps.

As always, thanks for listening.