Results for “Lessons Learned” — Page 80

NASA NTRS2022

Tri-Agency Reliability Engineering Guidance: Post Mission Disposal and Extension Assessment

The Trilateral partners — the European Space Agency (ESA), Japan Aerospace Exploration Agency (JAXA), and National Aeronautics and Space Administration (NASA) and the United States Government (USG) in their execution of safe and successful missions, have a long-standing history of sustaining the shared space environment of operational Earth-Moon orbits with their global space-stewardship, or spacekeeping, of these areas. This has driven missions to limit the generation of new and long-lived debris, control debris releases, minimize accidental explosions and collisions, and ensure Post-Mission Disposal of space systems, so that the environment remains safe for future operations and explorations. Given the continued need for space systems to support global mandatory infrastructure and commercial enterprise, spacefarers are extending beyond the Trilateral partners, more and smaller satellites are being deployed, and current assets are being utilized much longer than expected. This is making space more congested than ever; therefore, the Trilateral partners are evaluating potential future debris mitigation strategies, evolving technology, developing on-orbit servicing capabilities, and advancing their abilities to assess disposal and mission extension plans. They are also sharing their lessons learned and identifying opportunities for future state-of-the-art advancements for current and future space enterprises. Sustaining the space environment cannot be ensured by any one agency or country. Thus, the Trilateral authors have shared their lessons learned, insights, and guidance, herein, on disposal and mission extension assessment strategies with the gratitude of each agency. As such, this document is not prescriptive, but was formulated to enhance value-and-risk-balanced operational decision-making, support policy refinement, and guide spacefaring partners beyond these agencies to assess their activities in space with safety and a global space-stewardship, or spacekeeping, in mind. This includes not only the disposal and mission extension assessment addressed herein, but also preserving space history, ensuring collaboration/interoperability of technology, supporting fellow operators without interfering, and the utilization of in-situ resources for the common benefit of humankind. It is the intention of the Trilateral partners that this document evolves based on community lessons learned and the introduction of new assessment methodologies. So, all readers are encouraged to share their insights with the authors from their own application of this guidance or other strategies to ensure each mission has a successful, safe, and judicious life and conclusion.

ESA↗

NASA NTRS2006

NASA Crew Launch Vehicle Approach Builds on Lessons from Past and Present Missions

The United States Vision for Space Exploration, announced in January 2004, outlines the National Aeronautics and Space Administration's (NASA) strategic goals and objectives, including retiring the Space Shuttle and replacing it with a new human-rated system suitable for missions to the Moon and Mars. The Crew Exploration Vehicle (CEV) that the new Crew Launch Vehicle (CLV) lofts into space early next decade will initially ferry astronauts to the International Space Station and be capable of carrying crews back to lunar orbit and of supporting missions to Mars orbit. NASA is using its extensive experience gained from past and ongoing launch vehicle programs to maximize the CLV system design approach, with the objective of reducing total lifecycle costs through operational efficiencies. To provide in-depth data for selecting this follow-on launch vehicle, the Exploration Systems Architecture Study was conducted during the summer of 2005, following the confirmation of the new NASA Administrator. A team of aerospace subject matter experts used technical, budget, and schedule objectives to analyze a number of potential launch systems, with a focus on human rating for exploration missions. The results showed that a variant of the Space Shuttle, utilizing the reusable Solid Rocket Booster as the first stage, along with a new upper stage that uses a derivative of the RS-25 Space Shuttle Main Engine to deliver 25 metric tons to low-Earth orbit, was the best choice to reduce the risks associated with fielding a new system in a timely manner. The CLV Project, managed by the Exploration Launch Office located at NASA's Marshall Space Flight Center, is leading the design, development, testing, and operation of this new human-rated system. The CLV Project works closely with the Space Shuttle Program to transition hardware, infrastructure, and workforce assets to the new launch system . leveraging a wealth of lessons learned from Shuttle operations. The CL V is being designed to reduce costs through a number of methods, ranging from validating requirements to conducting trades studies against the concept design. Innovations such as automated processing will build on lessons learned from the Shuttle, other launch systems, Department of Defense operations experience, and subscale flight tests such as the Delta Clipper-Experimental Advanced (DCXA) vehicle operations that utilized minimal touch labor, automated cryogen ic propellant loading , and an 8-hour turnaround for a cryogenic propulsion system. For the CLV, the results of hazard analyses are contributing to an integrated vehicle health monitoring system that will troubleshoot anomalies and determine which ones can be solved without human intervention. Such advances will help streamline the mission operations process for pilots and ground controllers alike. In fiscal year 2005, NASA invested approximately $4.5 billion of its $16 bill ion budget on the Space Shuttle. The ultimate goal of the CLV Project is to deliver a safe, reliable system designed to minimize lifecycle costs so that NASA's budget can be invested in missions of scientific discovery. Lessons learned from developing the CLV will be applied to the growth path for future systems, including a heavy lift launch vehicle.

Dumbacher, Daniel L.↗

NASA NTRS2010

A Modular Instrumentation System for NASA's Habitat Demonstration Unit

NASA's human spaceflight program is focused on developing technologies to expand the reaches of human exploration and science activities beyond low earth orbit. A critical aspect of living in space or on planetary surfaces is habitation, which provides a safe and comfortable space in which humans can live and work. NASA is seeking out the best option for habitation by exploring several different concepts through the Habitat Demonstration Unit (HDU) project. The purpose of this HDU is to develop a fully autonomous habitation system that enables human exploration of space. One critical feature of the HDU project that helps to accomplish its mission of autonomy is the instrumentation system that monitors key subsystems operating within a Habitat configuration. The following paper will discuss previous instrumentation systems used in analog habitat concepts and how the current instrumentation system being implemented on the HDU1-PEM, or pressurized excursion module, is building upon the lessons learned of those previous systems. Additionally, this paper will discuss the benefits and the limitations of implementing a wireless sensor network (WSN) as the basis for data transport in the instrumentation system. Finally, this paper will address the experiences and lessons learned with integration, testing prior to deployment, and field testing at the JSC rock yard. NASA is developing the HDU1-PEM as a step towards a fully autonomous habitation system that enables human exploration of space. To accomplish this purpose, the HDU project is focusing on development, integration, testing, and evaluation of habitation systems. The HDU will be used as a technology pull, testbed, and integration environment in which to advance NASA's understanding of alternative mission architectures, requirements, and operations concepts definition and validation. This project is a multi-year effort. In 2010, the HDU1-PEM will be in a pressurized excursion module configuration, and in 2011 the module will be reconfigured for a pressurized core module configuration. Each year the HDU configurations will undergo testing at NASA's Desert Research and Technology Studies (D-RaTS) in Arizona [1]. As part of this project, a modular instrumentation system is developed to meet the monitoring needs of the HDU subsystems and to integrate with the current command and data handling infrastructure that has been developed for the project. The main objective of this study is to provide for the monitoring needs of the HDU. The requirements necessary to meet this objective are developed by working with the subsystem managers of the HDU to understand their monitoring needs. Additionally, the instrumentation system design leverages knowledge and lessons learned from previous studies, such as the inflatable habitat health monitoring system that was deployed in Antarctica [2], the integrated health monitoring system developed for NASA's Microhab [3], and the JSC Lunar Habitat Wireless Testbed to demonstrate a "standardsbased" approach to a wireless instrumentation system [4]. The HDU also requires flexibility in reconfiguration options, and it is necessary to demonstrate and evaluate a modular approach to an instrumentation system. Thus, the instrumentation system is designed in two parts: the primary system employs a standard WSN configuration, and the secondary system employs a wired USB hub. The WSN design provides for reconfiguration or replacement of sensors due to malfunctions or upgrades by using a wireless node that accepts ten instrument inputs and wirelessly transmits the data to the command and data handling system. The USB hub is necessary for those instruments that operate using a wired USB connection, although the design attempts to limit the amount of sensors that need to be wired connections.

Rojdev, Kristina↗

NASA NTRS2024

X-Plane Knowledge Capture Workshop Summary Report

The history of experimental aircraft research and development at the National Aeronautics and Space Administration (NASA) provides a large body of work for current and future team members to learn from and apply. NASA values the knowledge it gains from all the research it performs and desires to have that knowledge grow with each new project, incrementally adding to the collective knowledge base. To support this knowledge growth and sharing, in May 2019, NASA convened over 60 engineers; researchers; and other personnel (internal and external to NASA) for the X-plane1 Knowledge Capture Workshop to discuss their over 50-years’ worth of experiences in developing, operating, and managing experimental aircraft. Over the course of a two-day workshop, the group not only focused, primarily, on current X-plane development but also discussed a wide range of topics about experimental aircraft and flight research. In addition to the discussions, senior NASA aeronautics leaders shared their personal lessons learned with the workshop audience. Broadly, these discussions centered around the topics of organizational and cultural practices, the project lifecycle, flight, and risk and safety. Many of the observations offered by participants are applicable to other NASA team-based projects, demonstrating the value in sharing lessons learned and best practices across projects regardless of their research focus. To share the most valuable lessons learned as broadly as possible, a summary of these discussions has been compiled into the following report. These discussions are mostly included in their entirety, with some light editing for clarity and privacy. NASA is sharing this knowledge internally and making it available to the public in hopes that others can learn from the experimental aircraft challenges and successes at NASA. Note: this document represents the perspectives, experiences, and opinions of others but does not necessarily represent the official view of NASA.

Steven R Hirshorn↗

NASA NTRS2011

Habitat Demonstration Unit (HDU) Pressurized Excursion Module (PEM) Systems Integration Strategy

The Habitat Demonstration Unit (HDU) project team constructed an analog prototype lunar surface laboratory called the Pressurized Excursion Module (PEM). The prototype unit subsystems were integrated in a short amount of time, utilizing a rapid prototyping approach that brought together over 20 habitation-related technologies from a variety of NASA centers. This paper describes the system integration strategies and lessons learned, that allowed the PEM to be brought from paper design to working field prototype using a multi-center team. The system integration process was based on a rapid prototyping approach. Tailored design review and test and integration processes facilitated that approach. The use of collaboration tools including electronic tools as well as documentation enabled a geographically distributed team take a paper concept to an operational prototype in approximately one year. One of the major tools used in the integration strategy was a coordinated effort to accurately model all the subsystems using computer aided design (CAD), so conflicts were identified before physical components came together. A deliberate effort was made following the deployment of the HDU PEM for field operations to collect lessons learned to facilitate process improvement and inform the design of future flight or analog versions of habitat systems. Significant items within those lessons learned were limitations with the CAD integration approach and the impact of shell design on flexibility of placing systems within the HDU shell.

Gill, Tracy↗

NASA NTRS2010

Orion Abort Flight Test

The purpose of NASA's Constellation project is to create the new generation of spacecraft for human flight to the International Space Station in low-earth orbit, the lunar surface, as well as for use in future deep-space exploration. One portion of the Constellation program was the development of the Orion crew exploration vehicle (CEV) to be used in spaceflight. The Orion spacecraft consists of a crew module, service module, space adapter and launch abort system. The crew module was designed to hold as many as six crew members. The Orion crew exploration vehicle is similar in design to the Apollo space capsules, although larger and more massive. The Flight Test Office is the responsible flight test organization for the launch abort system on the Orion crew exploration vehicle. The Flight Test Office originally proposed six tests that would demonstrate the use of the launch abort system. These flight tests were to be performed at the White Sands Missile Range in New Mexico and were similar in nature to the Apollo Little Joe II tests performed in the 1960s. The first flight test of the launch abort system was a pad abort (PA-1), that took place on 6 May 2010 at the White Sands Missile Range in New Mexico. Primary flight test objectives were to demonstrate the capability of the launch abort system to propel the crew module a safe distance away from a launch vehicle during a pad abort, to demonstrate the stability and control characteristics of the vehicle, and to determine the performance of the motors contained within the launch abort system. The focus of the PA-1 flight test was engineering development and data acquisition, not certification. In this presentation, a high level overview of the PA-1 vehicle is given, along with an overview of the Mobile Operations Facility and information on the White Sands tracking sites for radar & optics. Several lessons learned are presented, including detailed information on the lessons learned in the development of wind placards for flight. PA-1 flight data is shown, as well as a comparison of PA-1 flight data to nonlinear simulation Monte Carlo data.

Hayes, Peggy Sue↗

NASA NTRS2015

The OSIRIS-REx Asteroid Sample Return Mission Operations Design

OSIRIS-REx is an acronym that captures the scientific objectives: Origins, Spectral Interpretation, Resource Identification, and Security-Regolith Explorer. OSIRIS-REx will thoroughly characterize near-Earth asteroid Bennu (Previously known as 1019551999 RQ36). The OSIRIS-REx Asteroid Sample Return Mission delivers its science using five instruments and radio science along with the Touch-And-Go Sample Acquisition Mechanism (TAGSAM). All of the instruments and data analysis techniques have direct heritage from flown planetary missions. The OSIRIS-REx mission employs a methodical, phased approach to ensure success in meeting the mission's science requirements. OSIRIS-REx launches in September 2016, with a backup launch period occurring one year later. Sampling occurs in 2019. The departure burn from Bennu occurs in March 2021. On September 24, 2023, the Sample Return Capsule (SRC) lands at the Utah Test and Training Range (UTTR). Stardust heritage procedures are followed to transport the SRC to Johnson Space Center, where the samples are removed and delivered to the OSIRIS-REx curation facility. After a six-month preliminary examination period the mission will produce a catalog of the returned sample, allowing the worldwide community to request samples for detailed analysis. Traveling and returning a sample from an Asteroid that has not been explored before requires unique operations consideration. The Design Reference Mission (DRM) ties together spacecraft, instrument and operations scenarios. Asteroid Touch and Go (TAG) has various options varying from ground only to fully automated (natural feature tracking). Spacecraft constraints such as thermo and high gain antenna pointing impact the timeline. The mission is sensitive to navigation errors, so a late command update has been implemented. The project implemented lessons learned from other "small body" missions. The key lesson learned was 'expect the unexpected' and implement planning tools early in the lifecycle. This paper summarizes the ground and spacecraft design as presented at OSIRIS-REx Critical Design Review(CDR) held April 2014.

mission operations↗

NASA NTRS2005

ESMD Risk Management Workshop: Systems Engineering and Integration Risks

This report has been developed by the National Aeronautics and Space Administration (NASA) Exploration Systems Mission Directorate (ESMD) Risk Management team in close coordination with the Systems Engineering Team. This document provides a point-in-time, cumulative, summary of key lessons learned derived from the SE RFP Development process. Lessons learned invariably address challenges and risks and the way in which these areas have been addressed. Accordingly the risk management thread is woven throughout the document.

Systems Engineering↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRS2011

Space Shuttle Guidance, Navigation, and Rendezvous Knowledge Capture Reports

This document is a catalog and readers guide to lessons learned, experience, and technical history reports, as well as compilation volumes prepared by United Space Alliance personnel for the NASA/Johnson Space Center (JSC) Flight Dynamics Division.1 It is intended to make it easier for future generations of engineers to locate knowledge capture documentation from the Shuttle Program. The first chapter covers observations on documentation quality and research challenges encountered during the Space Shuttle and Orion programs. The second chapter covers the knowledge capture approach used to create many of the reports covered in this document. These chapters are intended to provide future flight programs with insight that could be used to formulate knowledge capture and management strategies. The following chapters contain descriptions of each knowledge capture report. The majority of the reports concern the Space Shuttle. Three are included that were written in support of the Orion Program. Most of the reports were written from the years 2001 to 2011. Lessons learned reports concern primarily the shuttle Global Positioning System (GPS) upgrade and the knowledge capture process. Experience reports on navigation and rendezvous provide examples of how challenges were overcome and how best practices were identified and applied. Some reports are of a more technical history nature covering navigation and rendezvous. They provide an overview of mission activities and the evolution of operations concepts and trajectory design. The lessons learned, experience, and history reports would be considered secondary sources by historians and archivists.

John L Goodman↗

NASA NTRS2004

Planning Mars Memory: Learning from the MER Mission

This viewgraph presentation discusses ways in which the lessons learned from a mission can be systematically remembered, retained, and applied by individuals and by an organization as a whole. The presentation cites lessons learned from the Mars Exploration Rover (MER) Mission as examples.

Charlotte, Linde↗

NASA NTRS2017

A Comparison of the SOCIT and DebriSat Experiments

This paper explores the differences between, and shares the lessons learned from, two hypervelocity impact experiments critical to the update of orbital debris environment models. The procedures and processes of the fourth Satellite Orbital Debris Characterization Impact Test (SOCIT) were analyzed and related to the ongoing DebriSat experiment. SOCIT was the first hypervelocity impact test designed specifically for satellites in Low Earth Orbit (LEO). It targeted a 1960's U.S. Navy satellite, from which data was obtained to update pre-existing NASA and DOD breakup models. DebriSat is a comprehensive update to these satellite breakup models- necessary since the material composition and design of satellites have evolved from the time of SOCIT. Specifically, DebriSat utilized carbon fiber, a composite not commonly used in satellites during the construction of the US Navy Transit satellite used in SOCIT. Although DebriSat is an ongoing activity, multiple points of difference are drawn between the two projects. Significantly, the hypervelocity tests were conducted with two distinct satellite models and test configurations, including projectile and chamber layout. While both hypervelocity tests utilized soft catch systems to minimize fragment damage to its post-impact shape, SOCIT only covered 65% of the projected area surrounding the satellite, whereas, DebriSat was completely surrounded cross-range and downrange by the foam panels to more completely collect fragments. Furthermore, utilizing lessons learned from SOCIT, DebriSat's post-impact processing varies in methodology (i.e., fragment collection, measurement, and characterization). For example, fragment sizes were manually determined during the SOCIT experiment, while DebriSat utilizes automated imaging systems for measuring fragments, maximizing repeatability while minimizing the potential for human error. In addition to exploring these variations in methodologies and processes, this paper also presents the challenges DebriSat has encountered thus far and how they were addressed. Accomplishing DebriSat's goal of collecting 90% of the debris, which constitutes well over 100,000 fragments, required addressing many challenges stemming from the very large number of fragments. One of these challenges arose in identifying the foam-embedded fragments. DebriSat addressed this by X-raying all of the panels once the loose debris were removed, and applying a detection algorithm developed in-house to automate the embedded fragment identification process. It is easy to see how the amount of data being compiled would be outstanding. Creating an efficient way to catalog each fragment, as well as archiving the data for reproducibility also posed a great challenge for DebriSat. Barcodes to label each fragment were introduced with the foresight that once the characterization process began, the datasheet for each fragment would have to be accessed again quickly and efficiently. The DebriSat experiment has benefited significantly by leveraging lessons learned from the SOCIT experiment along with the technological advancements that have occurred during the time between the experiments. The two experiments represent two ages of satellite technology and, together, demonstrate the continuous efforts to improve the experimental techniques for fragmentation debris characterization.

Ausay, Erick↗

NASA NTRS2006

Archiving Mars Mission Data Sets with the Planetary Data System

This viewgraph presentation reviews the use of the Planetary Data System (PDS) to archive the datasets that are received from the Mars Missions. It reviews the lessons learned in the actual archiving process, and presents an overview of the actual archiving process. It also reviews the lessons learned from the perspectives of the projects, the data producers and the data users.

Planetary Data System (PDS)↗

NASA NTRS2009

Rocketdyne - Lunar Ascent Engine

The ascent engine was the last one from the moon, and I want to focus on the idea of redundancy and teams in regard to the engine. By teams, I mean teamwork - not just within Rocketdyne. It was teamwork within Rocketdyne; it was teamwork within Grumman; it was teamwork within NASA. These were all important elements leading to the successful development of the lunar excursion module (LEM) engine. Communication, rapid response, and cooperation were all important. Another aspect that went into the development of the ascent engine was the integration of technology and of lessons learned. We pushed all the above, plus technology and lessons learned, into a program, and that led to a successful result. One of the things that I like to think about - again in retrospect - is how it is very "in" now to have integrated product and process teams. These are buzzwords for teamwork in all program phases. That s where you combine a lot of groups into a single organization to get a job done. The ascent engine program epitomized that kind of integration and focus, and because this was the mid- to late-1960s; this was new ground for Rocketdyne, Grumman, and NASA. Redundancy was really a major hallmark of the Apollo Program. Everything was redundant. Once you got the rocket going, you could even lose one of the big F-1 engines, and it would still make it to orbit. And once the first stage separated from the rest of the vehicle, the second stage could do without an engine and still make a mission. This redundancy was demonstrated when an early Apollo launch shut down a J-2 second-stage engine. Actually, they shut down two J-2 engines on that flight. Even the third stage, with its single J-2 engine, was backed up because the first two stages could toss it into a recoverable orbit. If the third stage didn't work, you were circling the earth, and you had time to recover the command module and crew. Remember how on the Apollo 13 flight, there was sufficient system redundancy even when we lost the service module. That was a magnificent effort. TRW Inc. really ought to be proud of their engine for that. (See Slide 2, Appendix I) We had planned for redundancy; we had landed on the moon. However, weight restrictions in the architecture said, "You can t have redundancy for ascent from the moon. You've got one engine. It s got to work. There is no second chance. If that ascent engine doesn't work, you re stuck there." It would not have looked good for NASA. It wouldn't have looked good for the country. There was a letter written that President Richard Nixon would read if the astronauts got stuck on the moon, expressing how sorry we were and so forth. It was a scary letter, really. The ascent engine was an engine that had to work. (See Slide 3, Appendix I).

Harmon, Tim↗

NASA NTRS2011

SPASE: Current Uses, Tools, and Plans

The Space Physics Archive Search and Extract (SPASE) project is an international collaboration among Heliophysics (solar and space physics) groups concerned with data acquisition and archiving. Within this community there are a variety of old and new data centers, resident archives, "virtual observatories", etc. acquiring, holding, and distributing data. The main product of the SPASE group is an XML-based SPASE Data Model now in operational use to enable searches for and ultimate acquisition of data of interest to a researcher. The SPASE Data Model defines the content of resource descriptions (metadata). The intent is to describe all SCientifically usable Heliophysics data sets using the Data Model. Another product of the SPASE group, in collaboration with NASA's Virtual Observatories, is a set of tools and services which work with SPASE meta data. This includes Registry Services which can retrieve and render metadata using resource identifiers and facilitate the downloading of the data referenced by the meta data. The SPASE Data Model has also been used as a vocabulary in specialized data models. One example is the Heliophysics Event List Manager (HELM) model. The SPASE Data Model is also being expanded to provide the means for more detailed description of data sets with the aim of enabling more automated ingestion and use of the data through detailed format descriptions. The evolution is based on a number of lessons learned and feedback from our community. Some of the lessons learned are unique to Heliophysics, and some are common to the various data diSCiplines. We will discuss the present state of SPASE usage, the role the SPASE Data Model can play in speCialized data models and how we foresee the development direction in the future.

Thieman, J. R.↗

NASA NTRSDate not supplied

Development of the Suited Injury Modes and Effects Analysis for Identification of Top Injury Risks in Lunar Missions and Training

A new Exploration Extravehicular Activity Suit (xEVAS) is being designed to replace the current Extravehicular Mobility Unit (EMU) for the National Aeronautics and Space Administration’s (NASA’s) Artemis program to return astronauts to the lunar surface. This new suit will allow for increased range of motion compared the current EMU and Apollo era suits and will have additional features that will enhance the health and safety of exploration. With the design of lunar missions and the xEVAS progressing, it is important to consider possible injuries and injury mechanisms that could occur in the suit. To address these concerns, the suited Injury Modes and Effects Analysis (IMEA) was developed to outline suited injury scenarios and rank them based on risk score. The IMEA documents possible scenarios and underlying mechanisms of injury while wearing an extravehicular activity (EVA) suit. Tasks during lunar surface EVA as well as training events to prepare for lunar missions were considered as history has shown that more suit injuries occur during training than in flight. Each scenario is ranked with a consequence and likelihood scoring based on our current understanding of the suit and Artemis design reference missions to identify high-risk cases that will drive further work in suited injury. Injuries, mechanisms of injury, and mitigation strategies are evaluated within each scenario. The Suited Injury Summit was held on January 5, 2022, to vet the IMEA with external experts. This was an all-day virtual meeting with the suited injury team, ergonomists, suit engineers, safety engineers, the flight operations directorate, flight doctors, astronauts, astronaut strength, conditioning, and rehabilitation specialists (ASCRS), and external subject matter experts (SMEs). External SMEs consisted of surgeons with varying specialties. The intent of this meeting was to walk through the top injury risks identified in the analysis, identify any gaps that were not captured, and discuss mitigations. With participation from all groups, countless lessons-learned came from the Summit meeting. Using the lessons-learned and discussion from the Summit, the top 10 risks have been identified: neutral buoyancy laboratory training, hand/glove injuries, poor suit fit, field training, specific EVA tasks/design of task, boots/ankle injuries, falls from heights, background radiation, repetitive contact, and ambulation/long-distance ambulation. Mitigation steps have also been determined for each of the top risks. The IMEA and documentation of top risks is a living document. Yearly meetings are planned to update the analysis and reevaluate top risks and mitigations. The IMEA is being used to drive work in suited injury, and this work will continue to evolve with IMEA and lunar mission updates.

Teresa Reiber↗