Human Spaceflight Knowledge Sharing: Integration LessonsNo Comment
Longtime NASA Engineering Manager Chris Singer compares human spaceflight integration to marriage. Interface control documents and marriage licenses may be in place, but breakdowns will still occur if good relationships are absent.
Editor’s Note: NASA’s Office of the Chief Engineer and the Human Exploration and Operations Mission Directorate sponsored the Human Spaceflight Knowledge Sharing Forum in November 2016. Select individuals responsible for shaping NASA’s future over the next 10 to 20 years focused on technical best practices and lessons learned from successful and unsuccessful human spaceflight missions. This is part of a series of articles recapping lessons learned and knowledge shared by these individuals at the pilot knowledge sharing event.
Chris Singer, NASA’s Deputy Chief Engineer for Engineering Integration prior to his retirement in 2017, says that just like a good marriage, you have to share and communicate effectively to make a human spaceflight system work.
“The document doesn’t make the relationship that’s required to be a good system for these high performance systems. You’ve got to live in each other’s space. You’ve got to appreciate what’s important to each other,” said Singer. “That means you actually have to talk about what’s important, and what you’re worried about, and why you’re worried about it, and start building that longer-term relationship.”
He considers integration the most important part. “Dealing with highly complex, high-reliability systems requires a lot of effective communications,” said Singer, who moderated the Integration Lessons panel at the Human Spaceflight Knowledge Sharing Forum. The panel, composed of the following individuals, shared integration challenges and lessons learned during NASA’s ongoing Journey to Mars.
- Jim Geffre, NASA Orion Program
- Johnny Heflin, NASA Space Launch System (SLS) Program
- Jessica Parsons, NASA Ground Systems Development and Operations (GSDO) Program
- Jennifer Read, NASA Exploration Systems Development (ESD) Division
ESD’s approach pushes the integration function to lower levels closer to the hardware owners and relies on the Orion, SLS and GSDO programs to self-integrate. Management models used by the programs could leave open the possibility of gaps in coverage, so a strong Cross-Program Integration Team (CPIT) with Integrated Task Teams (ITT) was established. The teams use resources largely owned by the programs, but report and respond to the ESD CPIT.
Orion Integration Models
The Orion Program uses a streamlined oversight model to maximize the amount of inline work, maintaining a minimum level of oversight. “Our philosophy is the best oversight comes from being part of the day-to-day work, working through the challenges with our engineers,” said Jim Geffre, Orion Vehicle System Performance and Analysis Office Lead. “Meanwhile, we maintain a strong system manager/subsystem manager function to preserve that traditional oversight role.”
Since its inception in 2005, Orion has used multiple integration models. Geffre shared lessons learned and common themes throughout the use of different integration models:
- Integration needs to occur at all levels throughout the organization.
- Emphasize communication in all directions.
- Multiple integration models can be applied successfully depending on the situation, and demand a nimble, adaptable organization.
- Don’t confuse oversight with integration; integration is most successful when participatory.
Orion and SLS are geographically distributed across NASA centers, contractors and international partners. Geffre said one of the most interesting integration challenges on Orion is the European-built service module, an essential part of the spacecraft that will power, propel and cool Orion in deep space as well as provide air and water for crew members. The European Space Agency (ESA) has engaged 13 European countries in development of the service module.
“This kind of geographic separation introduces some new integration challenges,” said Geffre. “You’re dealing with a six-to-eight-hour time difference every day, which limits how much communication can be done via telecon or phone call. We’ve had to adapt our integration model to working with ESA.”
The Orion Program created a dedicated European integration office to negotiate agreements and manage the integration function. Geffre said they rely more heavily on integration through documentation due to limited opportunities for day-to-day integration and interaction. He said one of the biggest challenges in working with the European partners is getting the documentation right so that the end product meets overall mission needs.
SLS Hardware Integration
The process of integrating proven engines into a new vehicle is front and center for SLS. “Legacy hardware. Legacy engines. 135 successful flights. Very robust, proven design. But it’s a new vehicle. New operating conditions. New environments. Different avionics protocols. So, we have to do some work to adapt those engines to that vehicle,” said Johnny Heflin, SLS Liquid Engine Office Deputy Manager. “We’re in the process of testing those engines at Stennis now to prove that the engine meets SLS environments and capability along with certifying the new engine controller that we’ve developed in order to interface with the new vehicle avionics.”
SLS will be the most powerful rocket NASA has ever built. When completed, the rocket will enable astronauts to begin their journey to explore destinations far into the solar system. Heflin provided an SLS overview and a description of the systems engineering and integration (SE&I) function from an organizational point of view. “That’s what integration is all about – people. And it’s about those touch points,” he said. “It’s about having people in the right positions with clear lines of responsibility, roles and responsibilities defined, and clear lines of communication.”
Heflin added that clearly defined roles, responsibilities and communication paths are essential not only for integration, but for programs to remain lean in an era of affordability.
GSDO Cross-Program Integration
GSDO is responsible for upgrading KSC infrastructure and developing ground systems to build, process, launch and recover SLS and Orion on time and on budget. GSDO relies on the CPIT model, which depends on multiple ITTs and proactive involvement of program SE&I leads who identify and address high risk integration items. GSDO also uses Integration Engineers as technical representatives to SLS and Orion, providing program-to-program technical integration during development, integrated testing and operations.
Jessica Parsons, GSDO SLS Integration Lead, said using the CPIT model instead of an independent Level 2 Integration Office allows GSDO, SLS and Orion to work together more closely than during the Constellation Program, where issues were elevated to Level 2 for them to work the problem. “We don’t wait for somebody else to solve that problem,” said Parsons. “We will call our sister program and try to figure out how can we resolve that problem. What is the best solution that we can come up with for the enterprise?”
Parsons said each of the programs participates in major life cycle reviews, and she thinks this has been essential to help identify technical issues and disconnects early in the process.
“I think this integration model allows for quick decision velocity,” said Parsons. Joint Integration Control Boards convene three times per week and the three program Chief Engineers make technical decisions. If they can’t come to resolution on an issue, it is elevated to the Program Managers the following week to expedite decision making.
The biggest challenge from Parsons’ perspective is that each program has an agile software development process. She said it’s really hard to integrate the software, but they have been successful in identifying what each program needs and when the information is needed.
ESD Lessons Learned
Jennifer Read, Integration Scientist and Lessons Learned Coordinator with KBRwyle supporting the ESD Division of NASA’s Human Exploration and Operations Mission Directorate, said CPIT is a new model resulting from lessons learned from the Constellation Program. CPIT leverages the programs to lead and develop the integrated products.
“One of the great things about what we do with the CPIT model is it can grow, or it can retract as we move through our development cycle,” said Read. “The ad hoc teams are short lived. They may not be product-specific, but sometimes actually an ad hoc team can turn into an integrated task team.”
She said schedule is a challenge as the three programs work independently, but also collaboratively. Read noted that the importance of communication in integration is a recurring theme, and that the CPIT leads talk with each other every morning and have weekly tag-ups and a technical forum where they status technical topics and action resolution.
Orion’s Geffre added that daily communications between the organizations was established as a regular business rhythm. “Sometimes you need to force that communication at the start, and then it just kind of grows organically,” said Geffre. “Probably the biggest lesson learned is the benefit of early communication.”