Back to Top
<em>Spotlight on Lessons Learned:</em> Program Management of ISERV Design, Development, and Qualification Class D Hardware Integration

Specific events and obstacles encountered during the design and development of the ISERV payload provide the basis of an applicable program management lesson learned.

The International Space Station SERVIR Environmental Research and Visualization (ISERV) system payload was a Commercial-Off-The-Shelf (COTS) technology demonstration to assist the SERVIR team with an ISS on-board asset for disaster monitoring and data collection. The payload was developed to provide data and images through a downlink from the ISS. Mounted in the ISS Window Observational Research Facility rack, the ISERV payload consisted of COTS optical equipment and a Power Distribution Assembly developed by Marshall Space Flight Center. The Class D ISERV payload was integrated into Class A ISS hardware, which implies that the payload must meet some Class A requirements not typically captured in Class D systems.

The introduction of COTS components and systems into projects challenged the traditional Marshall approach to designing, developing, and testing flight hardware. Events and obstacles encountered with ISERV led to valuable lessons learned in managing a small, time-constrained project with limited resources and an inexperienced team.

Lesson Number: 7217
Lesson Date: March 31, 2012
Submitting Organization: Marshall Space Flight Center

 

HIGHLIGHTS

LESSON LEARNED

  • Foundational documents, critical for the initial planning and subsequent control of project activities, should be developed and widely distributed, published, and advertised to the team early in the process.
  • Wise use of analyses and evaluation of interfaces at all stages of the life cycle can save time and resource expenditures during build, test, and milestone reviews.

RECOMMENDATIONS

  • Provide the basic foundational documentation at the onset of the project, such as a simple Concept of Operations description, a readily accessible schedule, and a listing of all identifiable risks.
  • Establish a checklist or other guidance to define best practices for developing COTS-inclusive systems at the center, where to find integrated system requirements, and how to identify risks introduced by using COTS equipment.

Consult the lesson learned for complete lists.

 

Paul Tatum Credit: NASA

Paul Tatum
Credit: NASA

NASA Marshall Space Flight Center Systems Development, Integration and Test Division Chief Paul Tatum on the importance of this lesson learned:

We got a lot of great science from a very simple payload, and I think the takeaway is that it’s OK to accept a lot of risk with a Class D payload that’s going to integrate onto Class A hardware as long as you know upfront what those risks are and that you’re willing to accept them. We at NASA have a tendency to be ultra conservative. We’ve got our rules and standards that we try to follow to keep us from failing. But there are times when it’s beneficial to accept low risk to get some high gains from a project—and that’s what ISERV was. There was a lot of simplicity in the design and a lot of complexity in the actual execution and integration. But it ended up being a very easy way to get a lot of great science for the Principal Investigator (PI).

From a ConOps and schedule standpoint, the PI had a grasp of what he wanted the instrument to do and how much data he wanted to collect over the course of the project. I think we collected data for two years, and he was open to trashing today’s data collection schedule and going with something else if someone had a need. For instance, if there was a flood, then we would re-task the instrument to monitor and track the floods. In support of the search for Malaysia Airlines Flight 370, we re-tasked the ISERV instrument to start scanning every time the space station would pass over the ocean and we sent that data to the disaster team. So, I think the lesson there is that it’s OK to have a great idea and not just have a jam-packed schedule and follow rigid marching orders. It really helped us and the community to have that flexibility in scheduling targets for the camera.

 

Related Resources

Learn more about ISERV

 

Read the full lesson learned.

 

Spotlight on Lessons Learned is a monthly series of articles featuring a valuable lesson along with perspective from a NASA technical expert on why the lesson is important. The full lessons are publicly available in NASA’s Lessons Learned Information System (LLIS).

If you have a favorite NASA lesson learned that belongs in the spotlight, please contact us and be sure to include the LLIS Lesson Number.

About the Author

Share With Your Colleagues