SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The potential for errors in engineering judgement arguably present the highest level of risk when applied to interplanetary spaceflight. JPL has been refining its lessons learned process to optimize the collection and transfer of critical success factors applicable to current and future spaceflight projects.
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.
Launching a rocket, running a business, driving to work and even day-to-day living all involve some degree of risk. Risk is ever present yet not always recognized, adequately assessed and appropriately mitigated. Identification, assessment and mitigation of risk are elements of the risk management component of the "continuous improvement" way of life that has become a hallmark of successful and progressive enterprises. While the application of risk management techniques to provide continuous improvement may be detailed and extensive, the philosophy, ideals and tools can be beneficially applied to all situations. Experiences with the use of risk identification, assessment and mitigation techniques for complex systems and processes are described. System safety efforts and tools used to examine potential risks of the Ares I First Stage of NASA s new Constellation Crew Launch Vehicle (CLV) presently being designed are noted as examples. Recommendations from lessons learned are provided for the application of risk management during the development of new systems as well as for the improvement of existing systems. Lessons learned and suggestions given are also examined for applicability to simple systems, uncomplicated processes and routine personal daily tasks. This paper informs the reader of varied uses of risk management efforts and techniques to identify, assess and mitigate risk for improvement of products, success of business, protection of people and enhancement of personal life.
NASA has a unique history in processing the Space Shuttle fleet for launches. Some of this experience has been captured in the NASA Lessons Learned Information System (LLIS). This tool provides a convenient way for design engineers to review lessons from the past to prevent problems from reoccurring and incorporate positive lessons in new designs. At the Kennedy Space Center, the LLIS is being used to design ground support equipment for the next generation of launch and crewed vehicles. This paper describes the LLIS process and offers some examples.
Managing and referencing design knowledge is a critical activity in the design process. However, reliably retrieving useful knowledge can be a frustrating experience for users of knowledge management systems due to inherent limitations of standard keyword-based searches. In this research, we consider the task of retrieving relevant lessons learned from the NASA Lessons Learned Information System (LLIS). To this end, we apply a state-of-the-art natural language processing (NLP) technique for information retrieval: semantic search with sentence-BERT, which is a modification of a Bidirectional Encoder Representations from Transformers (BERT) model that uses siamese and triplet network architectures to obtain semantically meaningful sentence embeddings. While the pretrained sBERT model shows excellent out-of-the-box performance, we further fine-tune the model on data from the LLIS so that it learns on design engineering-relevant vocabulary. We quantify the improvement in query results using both standard sBERT and fine-tuned sBERT over the LLIS’s built-in keyword search. Additionally, we demonstrate a use case for the query system by searching for lessons learned relevant to specific requirements from a NASA project as part of a broader knowledge management and retrieval system. Results indicate that applying state-of-the-art natural language processing techniques, especially when fine-tuned using engineering data, to design information retrieval tasks shows significant promise in modernizing design knowledge management systems.
There has been growing interest in utilizing natural language processing (NLP) algorithms in Aviation Safety. This interest has extended to leveraging the decades of records publicly available on the Aviation Safety Reporting System (ASRS). While related literature has given more emphasis in lessons learned from the narratives, our prior work has focused on using NLP to support narrative search in the ASRS. Specifically, we evaluated if the use of alternative search mechanisms to keyword search, such as the retrieval of related narratives even without matching keywords could improve narrative discovery. A difficulty in experimenting alternative search mechanisms in any information retrieval task is the lack of ground truth. To address this limitation, we propose Kaona, a lightweight interface which enables the prototyping of alternative search retrieval tasks, by tracking user experience both explicitly (user-specified feedback), or implicitly (user navigation through interface affordances). Differently from distracting requests for feedback during user navigation, Kaona collects explicit feedback from users by mapping them to affordances which support the user workflow, while obtaining ground truth information for learning tasks.
This report describes the state of practices of design reviews at NASA and research into what can be done to improve peer review practices. There are many types of reviews at NASA: required and not, formalized and informal, programmatic and technical. Standing project formal reviews such as the Preliminary Design Review and Critical Design Review are a required part of every project and mission development. However, the technical, engineering peer reviews that support teams' work on such projects are informal, some times ad hoc, and inconsistent across the organization. The goal of this work is to identify best practices and lessons learned from NASA's experience, supported by academic research and methodologies to ultimately improve the process. This research has determined that the organization, composition, scope, and approach of the reviews impact their success. Failure Modes and Effects Analysis (FMEA) can identify key areas of concern before or in the reviews. Product definition tools like the Project Priority Matrix, engineering-focused Customer Value Chain Analysis (CVCA), and project or system-based Quality Function Deployment (QFD) help prioritize resources in reviews. The use of information technology and structured design methodologies can strengthen the engineering peer review process to help NASA work towards error-proofing the design process.
The Space Telecommunications Radio System (STRS) Application Repository Design and Analysis document describes the STRS application repository for software-defined radio (SDR) applications intended to be compliant to the STRS Architecture Standard. The document provides information about the submission of artifacts to the STRS application repository, to provide information to the potential users of that information, and for the systems engineer to understand the requirements, concepts, and approach to the STRS application repository. The STRS application repository is intended to capture knowledge, documents, and other artifacts for each waveform application or other application outside of its project so that when the project ends, the knowledge is retained. The document describes the transmission of technology from mission to mission capturing lessons learned that are used for continuous improvement across projects and supporting NASA Procedural Requirements (NPRs) for performing software engineering projects and NASAs release process.
In 2001, NASA Goddard Space Flight Center's Laboratory for Terrestrial Physics started the construction of a science Investigator-led Processing System (SIPS) for processing data from the Ozone Monitoring Instrument (OMI) which will launch on the Aura platform in mid 2004. The Ozone Monitoring Instrument (OMI) is a contribution of the Netherlands Agency for Aerospace Programs (NIVR) in collaboration with the Finnish Meteorological Institute (FMI) to the Earth Observing System (EOS) Aura mission. It will continue the Total Ozone Monitoring System (TOMS) record for total ozone and other atmospheric parameters related to ozone chemistry and climate. OMI measurements will be highly synergistic with the other instruments on the EOS Aura platform. The LTP previously developed the Moderate Resolution Imaging Spectrometer (MODIS) Data Processing System (MODAPS), which has been in full operations since the launches of the Terra and Aqua spacecrafts in December, 1999 and May, 2002 respectively. During that time, it has continually evolved to better support the needs of the MODIS team. We now run multiple instances of the system managing faster than real time reprocessings of the data as well as continuing forward processing. The new OMI Data Processing System (OMIDAPS) was adapted from the MODAPS. It will ingest raw data from the satellite ground station and process it to produce calibrated, geolocated higher level data products. These data products will be transmitted to the Goddard Distributed Active Archive Center (GDAAC) instance of the Earth Observing System (EOS) Data and Information System (EOSDIS) for long term archive and distribution to the public. The OMIDAPS will also provide data distribution to the OMI Science Team for quality assessment, algorithm improvement, calibration, etc. We have taken advantage of lessons learned from the MODIS experience and software already developed for MODIS. We made some changes in the hardware system organization, database and software to adapt the system for OMI. We replaced the fundamental database system, Sybase, with an Open Source RDBMS called PostgreSQL, and based the entire OMIDAPS on a cluster of Linux based commodity computers rather than the large SGI servers that MODAPS uses. Rather than relying on a central I/O server host, the new system distributes its data archive among multiple server hosts in the cluster. OMI is also customizing the graphical user interfaces and reporting structure to more closely meet the needs of the OMI Science Team. Prior to 2003, simulated OMI data and the science algorithms were not ready for production testing. We initially constructed a prototype system and tested using a 25 year dataset of Total Ozone Mapping Spectrometer (TOMS) and Solar Backscatter Ultraviolet Instrument (SBUV) data. This prototype system provided a platform to support the adaptation of the algorithms for OMI, and provided reprocessing of the historical data aiding in its analysis. In a recent reanalysis of the TOMS data, the OMIDAPS processed 108,000 full orbits of data through 4 processing steps per orbit, producing about 800,000 files (400 GiB) of level 2 and greater data files. More recently we have installed two instances of the OMIDAPS for integration and testing of OM1 science processes as they get delivered from the Science Team. A Test instance of the OMIDAPS has also supported a series of "Interface Confidence Tests" (ICTs) and End-to-End Ground System tests to ensure the launch readiness of the system. This paper will discuss the high-level hardware, software, and database organization of the OMIDAPS and how it builds on the MODAPS heritage system. It will also provide an overview of the testing and implementation of the production OMIDAPS.
This viewgraph presentation reviews NASA s Evolutionary Xenon Thruster (NEXT) Ion Propulsion system. The NEXT project is developing a solar electric ion propulsion system. The NEXT project is advancing the capability of ion propulsion to meet NASA robotic science mission needs. The NEXT system is planned to significantly improve performance over the state of the art electric propulsion systems, such as NASA Solar Electric Propulsion Technology Application Readiness (NSTAR). The status of NEXT development is reviewed, including information on the NEXT Thruster, the power processing unit, the propellant management system (PMS), the digital control interface unit, and the gimbal. Block diagrams NEXT system are presented. Also a review of the lessons learned from the Dawn and NSTAR systems is provided. In summary the NEXT project activities through 2007 have brought next-generation ion propulsion technology to a sufficient maturity level.
Emerging complex engineered systems may have unexpected safety issues due to novel operational environments, increasing autonomy, human-machine interaction, and other factors. To prevent failures in operation or testing that necessitate costly redesign, it is desirable to predict likely failure modes early in the design process. Text-based information about past engineering failures presents one possible solution by facilitating the retrieval of information that can inform new designs. However, identifying documents containing relevant information and extracting required information can be prohibitively time-consuming when implemented at scale. In this research, an automated natural language processing-based framework is proposed to discover relevant knowledge from documents containing failure-related design information. Documents containing usable information are filtered using sentiment analysis based on a custom lexicon specialized for engineering design and by filtering out documents containing only irrelevant topics. Next, from the identified usable documents, information relating to engineering failures, contributing factors that can be controlled at design time (“risk factors”), and recommended preventative actions are extracted. Semantic similarity is then used to group similar pieces of extracted information for improved generalizability. The proposed framework is applied to NASA’s Lessons Learned Information System (LLIS). The framework can be used to identify documents containing usable failure-related design information from other databases, extract relevant information from these documents, and generalize the acquired knowledge such that it can be applied to novel systems.
Using the vantage point of space, satellite observations provide information about the Earth that can serve a critical role in building situational awareness and filling in data gaps during disaster response. NASA’s Earth Science Division ( studies the Earth as a system and develops technologies to improve the quality of life here on our home planet. Within NASA ESD, the Disasters Program and its Disasters Response Coordination System (DRCS) aims to advance Earth science data and information to support management decisions that prevent or mitigate the impacts of disasters. Using a whole-of-NASA approach to coordinate and mobilize the Agency’s assets and expertise to provide geospatial information during disasters, this work brings the utility of Earth observation information to emergency management and disaster response and reduces the impacts of disasters on lives and livelihoods .This poster will introduce the utility of satellite and geospatial information to disaster response through examples of recent DRCS incident response activations and highlight the DRCS model that employs a user-centered activation framework beginning with direct requests from responders and ending with after-action assessments that feed lessons learned and process improvements.
The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has been tasked with the development of Medical System Foundations for Level of Care IV for both short-duration lunar orbital missions and, subsequently, long-duration lunar orbital and surface operations missions. These Medical System Foundations serve as a framework to aid in early medical system design and mission planning. The content of both Foundation models is similar, consisting of a concept of operations, functional decomposition, clinical content (medical conditions, capabilities, and resources), technical requirements (interface, non-functional, and functional), and traces between these components and to the NASA standards documents and parent-level (Program- and Vehicle habitat system-level) requirements. Additionally, the development of both Foundations employed systems engineering principles and a model-based systems engineering (MBSE) approach. Throughout the development of these Foundations, ExMC has strived to improve the efficiency and robustness of its processes and to be more responsive to change (i.e., in design reference mission parameters and assumptions) and to stakeholders’ feedback. The most significant improvements made between the short- and long-duration Foundation models during this transformation process are the following: • Replacement of the traditional document-based ConOps with a model-based ConOps according to MBSE principles, which facilitated more efficient understanding of the material and the consolidation of all relevant information into a centralized location. • Utilization of an agile approach with tasks organized into sprints. This approach enabled solicitation of more frequent usability feedback from stakeholders, incorporation of more human factors reviews into the sprints, and more efficient tasking of team members. This presentation will discuss the journey of developing both Foundation models, as well as the lessons learned and resulting improvements made between the Short- and Long-Duration models.
The entire procedure of incorporating the requirements and goals of a space flight project into integrated, time ordered sequences of spacecraft commands, is called the uplink process. The Uplink Process Control Task (UPCT) was created to examine the uplink process and determine ways to improve it. The Problem Statement Language/Problem Statement Analyzer (PSL/PSA) designed to assist the designer/analyst/engineer in the preparation of specifications of an information system is used as a supporting tool to aid in the analysis. Attention is given to a definition of the uplink process, the definition of PSL/PSA, the construction of a PSA database, the value of analysis to the study of the uplink process, and the PSL/PSA lessons learned.
In connection with work related to the use of earth-resources images, it became apparent by 1974, that certain system improvements are necessary for the efficient processing of digital data. To resolve this dilemma, Billingsley and Bryant (1975) proposed the use of image processing technology. Bryant and Zobrist (1976) reported the development of the Image Based Information System (IBIS) as a subset of an overall Video Image Communication and Retrieval (VICAR) image processing system. A description of IBIS is presented, and its employment in connection with advanced applications is discussed. It is concluded that several important lessons have been learned from the development of IBIS. The development of a flexible system such as IBIS is found to rest upon the prior development of a general purpose image processing system, such as VICAR.
Open, interdisciplinary science inevitably relies heavily on standards. Standards are those often unseen agreements that we take for granted when systems and processes are working fine. Yet standards work is perpetual, laborious, and sometimes contentious, especially for standards to work across diverse disciplines. Standards development, maintenance, and implementation is a complex, ongoing socio-technical process. NASA has developed a progressively open science policy and strategy that calls for the establishment of a data standards process reaching across the five diverse divisions of the Science Mission Directorate. This is a delicate exercise. We, therefore, seek to apply a holistic yet pragmatic approach to developing and maintaining a standards process. We adopt an ecological philosophy that focuses on the interactions within the data ecosystem and how standards facilitate those interactions. We couple high-level analysis with on the ground experimentation. We began by 1) mapping information ecosystem components (e.g. data centers, missions, services, protocols, users), 2)establishing how the components interact (e.g. sharing (meta)data, funding, personnel exchange), and 3) modelling system dynamics (e.g. creation of products from multiple data centers, redundant processes, shared services). The goal is to apply understanding of the ecosystem to real world applications (e.g. planning a new mission, implementing new policy requirements, improving process efficiency, etc.). We have also conducted studies of historical standardization efforts, documenting lessons learned and cautionary tales. We then contrast this more abstract work with real examples. We reviewed and assessed multiple existing standards development processes both within and external to NASA. We now work to implement an initial test process which can be further optimized. We seek to define a consistent approach for assigning persistent identifiers for research objects, especially for the purposes of citation. The experience from this relatively ‘simple’ test case adds a pragmatic perspective on how researchers and engineers actually work. This presentation will review the details of this methodology, our initial findings, and how they might apply to other interdisciplinary standardization efforts.
Since the Space Shuttle Challenger accident in 1986, NASA has extensively used probabilistic analysis methods to assess, understand, and communicate the risk of space launch vehicles. Probabilistic Risk Assessment (PRA), used in the nuclear industry, is one of the probabilistic analysis methods NASA utilizes to assess Loss of Mission (LOM) and Loss of Crew (LOC) risk for launch vehicles. PRA is a system scenario based risk assessment that uses a combination of fault trees, event trees, event sequence diagrams, and probability distributions to analyze the risk of a system, a process, or an activity. It is a process designed to answer three basic questions: 1) what can go wrong that would lead to loss or degraded performance (i.e., scenarios involving undesired consequences of interest), 2) how likely is it (probabilities), and 3) what is the severity of the degradation (consequences). Since the Challenger accident, PRA has been used in supporting decisions regarding safety upgrades for launch vehicles. Another area that was given a lot of emphasis at NASA after the Challenger accident is reliability engineering. Reliability engineering has been a critical design function at NASA since the early Apollo days. However, after the Challenger accident, quantitative reliability analysis and reliability predictions were given more scrutiny because of their importance in understanding failure mechanism and quantifying the probability of failure, which are key elements in resolving technical issues, performing design trades, and implementing design improvements. Although PRA and reliability are both probabilistic in nature and, in some cases, use the same tools, they are two different activities. Specifically, reliability engineering is a broad design discipline that deals with loss of function and helps understand failure mechanism and improve component and system design. PRA is a system scenario based risk assessment process intended to assess the risk scenarios that could lead to a major/top undesirable system event, and to identify those scenarios that are high-risk drivers. PRA output is critical to support risk informed decisions concerning system design. This paper describes the PRA process and the reliability engineering discipline in detail. It discusses their differences and similarities and how they work together as complementary analyses to support the design and risk assessment processes. Lessons learned, applications, and case studies in both areas are also discussed in the paper to demonstrate and explain these differences and similarities.
This document examines the challenges inherent in designing and regulating to support human-automation interaction for new technologies that will deployed into complex systems. A key question for new technologies, is how work will be accomplished by the human and machine agents. This question has traditionally been framed as how functions should be allocated between humans and machines. Such framing misses the coordination and synchronization that is needed for the different human and machine roles in the system to accomplish their goals. Coordination and synchronization demands are driven by the underlying human-automation architecture of the new technology, which are typically not specified explicitly by the designers. The human machine interface (HMI) which is intended to facilitate human-machine interaction and cooperation, however, typically is defined explicitly and therefore serves as a proxy for human-automation cooperation requirements with respect to technical standards for technologies. Unfortunately, mismatches between the HMI and the coordination and synchronization demands of the underlying human-automation architecture, can lead to system breakdowns. A methodology is needed that both designers and regulators can utilize to evaluate the expected performance of a new technology given potential human-automation architectures. Three experiments were conducted to inform the minimum HMI requirements a detect and avoid system for unmanned aircraft systems (UAS). The results of the experiments provided empirical input to specific minimum operational performance standards that UAS manufacturers will have to meet in order to operate UAS in the National Airspace System (NAS). These studies represent a success story for how to objectively and systematically evaluate prototype technologies as part of the process for developing regulatory requirements. They also provide an opportunity to reflect on the lessons learned from a recent research effort in order to improve the methodology for defining technology requirements for regulators in the future. The biggest shortcoming of the presented research program was the absence of the explicit definition, generation and analysis of potential human-automation architectures. Failure to execute this step in the research process resulted in less efficient evaluation of the candidate prototypes technologies in addition to the complete absence of different approaches to human-automation cooperation. For example, all of the prototype technologies that were evaluated in the research program assumed a human-automation architecture that relied on serial processing from the automation to the human. While this type of human-automation architecture is typical across many different technologies and in many different domains, it ignores different architectures where humans and automation work in parallel. Defining potential human-automation architectures a priori also allows regulators to develop scenarios that will stress the performance boundaries of the technology during the evaluation phase. The importance of adding this step of generating and evaluating candidate human-automation architectures prior to formal empirical evaluation is discussed.