Search NASA⌕ Search

SEARCH · Search NASA

Results for “learning with rationales”

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.

At least 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Lessons Learned JSC Micro-Wireless Instrumentation Systems on Space Shuttle and International Space Station CANEUS 2006

A viewgraph presentation on lessons learned from NASA Johnson Space Center's micro-wireless instrumentation is shown. The topics include: 1) Background, Rationale and Vision; 2) NASA JSC/Structural Engineering Approach & History; 3) Orbiter Wing Leading Edge Impact Detection System; 4) WLEIDS Confidence and Micro-WIS Lessons Learned; and 5) Current Projects and Recommendations.

Studor, George↗
NASA NTRSDate not supplied

A Survey Protocol to Assess Meaningfulness and Usefulness of Automated Topic Finding in the NASA Aviation Safety Reporting System

Context: The NASA Aviation Safety Reporting System (ASRS) is a voluntary confidential aviation safety reporting system. The ASRS receives reports from pilots, air traffic controllers, flight attendants and other involved in aviation operations. The reports are de-identified and coded by ASRS expert safety analysts and a short descriptive synopsis is written to describe the safety issue. The de-identified reports are then disseminated to the aviation community in a number of ways including entry into an online database, Safety Alert Bulletins and For Your Information Notices, and the CALLBACK newsletter. Key to these publications are the timely processing (de-identification, coding and summarization) of new reports, which is currently done by ASRS expert safety analysts. Thus, we believe topic modelling could decrease effort in ASRS, if topics are comprehensible. Aim: We propose a methodology to evaluate whether automated topic finding using topic modelling provides meaningful and useful topics. Method: We extend the total error survey methodology to evaluate user topic comprehension of machine learning outputs. To accomplish this we performed a literature review to identify existing methods and define a construct for topic comprehension, utilizing existing ASRS synopsis writing practices to more precisely define meaningfulness and usefulness. Results: A survey protocol was created that addresses the limitations of other survey protocols found in the literature review, which we found lacking in rationale and clear protocol definition. Conclusion: The surveying of user understanding in machine learning outputs presents challenges due to the explosion of parameters to control for and the lack of systematic approach presented in the literature. More reproducible work and survey protocols are needed in the literature and our work is one step towards that direction.

topic finding↗
NASA NTRS2009

Apollo Mission Techniques Lunar Orbit Activities - Part 1a

This slide presentation reviews the planned sequence of events and the rationale for all lunar missions, and the flight experiences and lessons learned for the lunar orbit activities from a trajectory perspective. Shown are trajectories which include the moon's position at the various stages in the complete trip from launch, to the return and reentry. Included in the presentation are objectives and the sequence of events,for the Apollo 8, and Apollo 10. This is followed by a discussion of Apollo 11, including: the primary mission objective, the sequence of events, and the flight experience. The next mission discussed was Apollo 12. It reviews the objectives, the ground tracking, procedure changes, and the sequence of events. The aborted Apollo 13 mission is reviewed, including the objectives, and the sequence of events. Brief summaries of the flight experiences for Apollo 14-16 are reviewed. The flight sequence of events of Apollo 17 are discussed. In summary each mission consistently performing precision landings required that Apollo lunar orbit activities devote considerable attention to: (1) Improving fidelity of lunar gravity models, (2) Maximizing availability of ground tracking, (3) Minimizing perturbations on the trajectory, (4) Maximizing LM propellant reserves for hover time. Also the use of radial separation maneuvers (1) allows passive re-rendezvous after each rev, but ... (2) sensitive to small dispersions in initial sep direction

Interbartolo, Michael A.↗
NASA NTRS2014

Distributed System Design Checklist

This report describes a design checklist targeted to fault-tolerant distributed electronic systems. Many of the questions and discussions in this checklist may be generally applicable to the development of any safety-critical system. However, the primary focus of this report covers the issues relating to distributed electronic system design. The questions that comprise this design checklist were created with the intent to stimulate system designers' thought processes in a way that hopefully helps them to establish a broader perspective from which they can assess the system's dependability and fault-tolerance mechanisms. While best effort was expended to make this checklist as comprehensive as possible, it is not (and cannot be) complete. Instead, we expect that this list of questions and the associated rationale for the questions will continue to evolve as lessons are learned and further knowledge is established. In this regard, it is our intent to post the questions of this checklist on a suitable public web-forum, such as the NASA DASHLink AFCS repository. From there, we hope that it can be updated, extended, and maintained after our initial research has been completed.

Hall, Brendan↗
NASA NTRS2004

Lessons Learned Study Final Report for the Exploration Systems Mission Directorate

This report is the final product of a 90-day study performed for the Exploration Systems Mission Directorate. The study was to assemble lessons NASA has learned from previous programs that could help the Exploration Systems Mission Directorate pursue the Exploration vision. It focuses on those lessons that should have the greatest significance to the Directorate during the formulation of program and mission plans. The study team reviewed a large number of lessons learned reports and data bases, including the Columbia Accident Investigation Board and Rogers Commission reports on the Shuttle accidents, accident reports from robotic space flight systems, and a number of management reviews by the Defense Sciences Board, Government Accountability Office, and others. The consistency of the lessons, findings, and recommendations validate the adequacy of the data set. In addition to reviewing existing databases, a series of workshops was held at each of the NASA centers and headquarters that included senior managers from the current workforce as well as retirees. The full text of the workshop reports is included in Appendix A. A lessons learned website was opened up to permit current and retired NASA personnel and on-site contractors to input additional lessons as they arise. These new lessons, when of appropriate quality and relevance, will be brought to the attention of managers. The report consists of four parts: Part 1 provides a small set of lessons, called the Executive Lessons Learned, that represent critical lessons that the Exploration Systems Mission Directorate should act on immediately. This set of Executive Lessons and their supporting rationale have been reviewed at length and fully endorsed by a team of distinguished NASA alumni; Part 2 contains a larger set of lessons, called the Selected Lessons Learned, which have been chosen from the lessons database and center workshop reports on the basis of their specific significance and relevance to the near-term work of the Exploration Directorate. These lessons frequently support the Executive lessons but are more general in nature; Part 3 consists of the reports of the center workshops that were conducted as part of this activity. These reports are included in their entirety (approximately 200 pages) in Appendix G and have significance for specific managers; Part 4 consists of the remainder of the lessons that have been selected by this effort and assembled into a database for the use of the Explorations Directorate. The database is archived and hosted in the Lessons Learned Knowledge Network, which provides a flexible search capability using a wide variety of search terms. Finally, a spreadsheet lists databases searched and a bibliography identifies reports that have been reviewed as sources of lessons for this task. NASA has been presented with many learning opportunities. We have conducted numerous programs, some extremely successful and others total failures. Most have been documented with a formal lessons learned activity, but we have not always incorporated these learning opportunities into our normal modes of business. For example, the Robbins Report of 2001 clearly indicates that many project failures of the past two decades were the result of violating well documented best practices, often in direct violation of management instructions and directives. An overarching lesson emerges: that disciplined execution in accordance with proven best practices is the greatest single contributor to a successful program. The Lessons Learned task team offers a sincere hope that the lessons presented herein will be helpful to the Exploration Systems Directorate in charting and executing their course. The success of the Directorate and of NASA in general depends on our collective ability to move forward without having to relearn the lessons of those who have gone before.

Van Laak, Jim↗
DOE OSTI2021

Using diverse potentials and scoring functions for the development of improved machine-learned models for protein–ligand affinity and docking pose prediction

The advent of computational drug discovery holds the promise of significantly reducing the effort of experimentalists, along with monetary cost. More generally, predicting the binding of small organic molecules to biological macromolecules has far-reaching implications for a range of problems, including metabolomics. However, problems such as predicting the bound structure of a protein–ligand complex along with its affinity have proven to be an enormous challenge. In recent years, machine learning-based methods have proven to be more accurate than older methods, many based on simple linear regression. Nonetheless, there remains room for improvement, as these methods are often trained on a small set of features, with a single functional form for any given physical effect, and often with little mention of the rationale behind choosing one functional form over another. Moreover, it is not entirely clear why one machine learning method is favored over another. Here, we endeavor to undertake a comprehensive effort towards developing high-accuracy, machine-learned scoring functions, systematically investigating the effects of machine learning method and choice of features, and, when possible, providing insights into the relevant physics using methods that assess feature importance. Here, we show synergism among disparate features, yielding adjusted R 2 with experimental binding affinities of up to 0.871 on an independent test set and enrichment for native bound structures of up to 0.913. When purely physical terms that model enthalpic and entropic effects are used in the training, we use feature importance assessments to probe the relevant physics and hopefully guide future investigators working on this and other computational chemistry problems.

59 BASIC BIOLOGICAL SCIENCES↗
NASA NTRS1982

A system safety model for developmental aircraft programs

Basic tenets of safety as applied to developmental aircraft programs are presented. The integration of safety into the project management aspects of planning, organizing, directing and controlling is illustrated by examples. The basis for project management use of safety and the relationship of these management functions to 'real-world' situations is presented. The rationale which led to the safety-related project decision and the lessons learned as they may apply to future projects are presented.

Amberboy, E. J.↗
NASA NTRS2021

Pointing Error Budget Development and Methodology on the Psyche Project

The Psyche mission was selected by NASA as the 14th mission in the Discovery Program in 2017. The Psyche spacecraft utilizes solar electric propulsion, and will journey to the asteroid (16) Psyche during a 3.5 year trajectory after its planned 2022 launch. The spacecraft instrument suite includes a magnetometer, a multispectral imager, a gamma ray neutron spectrometer, and an X-band radio telecommunications system. It also includes the Deep Space Optical Communication technical demonstration. These instruments along with other spacecraft components require pointing accuracy to meet their scientific and engineering performance requirements. Early on in the project development, the team established a methodology by which pointing accuracy (knowledge and control) is analyzed against the system requirements by means of pointing error budgets and requirement allocations. A margin policy was implemented to ensure the instrument and engineering component pointing accuracy requirements will be met during verification and in flight. Psyche’s pointing management framework defines detailed rationales for the system and subsystem error allocations of the top level pointing accuracy requirements, with sufficient project level pointing margin, and supports end-to-end pointing requirement verification. This paper will present an overview of the Psyche project’s pointing error budget development process, and discuss the rationale behind the methodology. Psyche’s pointing budget methodology integrates best practices and lessons learned from heritage missions, while focusing on the specific needs of the Psyche spacecraft and its science instruments. Key challenges in the pointing error budget development will be reviewed, and a deep dive into two key Psyche pointing budgets are presented. The systems engineering of Psyche’s pointing budget methodology outlined in this paper will serve as a resource for future deep space missions.

Lai, Peter↗
NASA NTRS2019

Deep Learning Method for Detecting Precursors to Adverse Events

With the recent advancements in Deep Learning methods, the ability to model large complex heterogeneous data sets are fundamentally changing industry and research. Coupled with hardware improvements, and ease of implementation, a wide variety of deep neural network architectures can quickly be developed to solve a sweeping range of problems such as: object detection in images, automatic healthcare diagnosis using heterogenous data sources, real time language translating and sentence prediction, upscaling low resolution images, and forecasting of multivariate timeseries. Generally, many of these architectures outperform classical machine learning approaches in their respective tasks, however, this typically comes at a cost of interpretability. These black box algorithms generally suffer from lack of transparency in both model complexity as well as the rationale behind the prediction. This lack of comprehension, is driving an emerging area of interest in “Explainable AI”. An algorithm called: “Deep Temporal Multiple Instance Learning”1 was a recently developed to identify precursors to adverse events and has been applied in the aviation domain. The deep learning architecture is designed to capture the evolution of the probability of the outcome over the time preceding the adverse event using a multiple instance learning approach as illustrated in Figure 1. Precursors are defined when the probability of the event has exceeded a threshold at some point in the timeseries, at which point, a sensitivity analysis is performed to determine contributing factors. The contributing factors are used to explain and define the precursor during the periods where the probability score is high. The identified contributing factors are then presented to subject matter experts to provide objective insights into the leading factors associated with the particular adverse event. The algorithm has been tested on flight data from a commercial airline and has the ability to discover precursors to known adverse events that take the form of safety critical operations, such as unstable approach events on final approach. Apart from detecting precursors to adverse events, the converse can also be leveraged to discover corrective actions. These positive actions manifest themselves as periods in the timeseries when the precursor score has been lowered from an elevated state; meaning that if the system had been left uncorrected, it would have eventually reached the adverse event state. Characterizing these state changes can help identify successful interventions that may not have been known before. Policy makers and procedure designers can use this additional knowledge to craft more safety and efficient resilient procedures for future operations and therefore improve the overall performance of the National Airspace.

Matthews, Bryan L.↗
NASA NTRS1997

Lessons Learned from the Clementine Mission

According to BMDO, the Clementine mission achieved many of its technology objectives during its flight to the Moon in early 1994 but, because of a software error, was unable to test the autonomous tracking of a cold target. The preliminary analyses of the returned lunar data suggest that valuable scientific measurements were made on several important topics but that COMPLEX's highest-priority objectives for lunar science were not achieved. This is not surprising given that the rationale for Clementine was technological rather than scientific. COMPLEX lists below a few of the lessons that may be learned from Clementine. Although the Clementine mission was not conceived as a NASA science mission exactly like those planned for the Discovery program, many operational aspects of the two are similar. It is therefore worthwhile to understand the strengths and faults of the Clementine approach. Some elements of the Clementine operation that led to the mission's success include the following: (1) The mission's achievements were the responsibility of a single organization and its manager, which made that organization and that individual accountable for the final outcome; (2) The sponsor adopted a hands-off approach and set a minimum number of reviews (three); (3) The sponsor accepted a reasonable amount of risk and allowed the project team to make the trade-offs necessary to minimize the mission's risks while still accomplishing all its primary objectives; and (4) The development schedule was brief and the agreed-on funding (and funding profile) was adhered to. Among the operational shortcomings of Clementine were the following: (1) An overly ambitious schedule and a slightly lean budget (meaning insufficient time for software development and testing, and leading ultimately to human exhaustion); and (2) No support for data calibration, reduction, and analysis. The principal lesson to be learned in this category is that any benefits from the constructive application of higher risk for lower cost and faster schedule will be lost if the schedule does not allow adequate time for the development of all essential systems or makes no allowance for human frailties. Another lesson to be drawn is that despite its limitations, if judged strictly as a science mission, Clementine attested that significant scientific information can be gathered during a technology-demonstration mission. In the current era of limited funds, when science missions will be infrequent, the opportunity to fly scientific instruments aboard missions whose objectives might be other than science must be seized and, indeed, encouraged. During such opportunities it would be inexcusable to do second-class science. Thus the scientific community must be actively involved in such projects from their initiation.

Source record↗
NASA NTRS2012

Enhancing Cassini Operations & Science Planning Tools

The Cassini team uses a variety of software utilities as they manage and coordinate their mission to Saturn. Most of these tools have been unchanged for many years, and although stability is a virtue for long-lived space missions, there are some less-fragile tools that could greatly benefit from modern improvements. This report shall describe three such upgrades, including their architectural differences and their overall impact. Emphasis is placed on the motivation and rationale behind architectural choices rather than the final product, so as to illuminate the lessons learned and discoveries made.These three enhancements included developing a strategy for migrating Science Planning utilities to a new execution model, rewriting the team's internal portal for ease of use and maintenance, and developing a web-based agenda application for tracking the sequence of files being transmitted to the Cassini spacecraft. Of this set, the first two have been fully completed, while the agenda application is currently in the early prototype stage.

science planning↗
NASA NTRS2011

Lessons Learned from the Space Shuttle Engine Hydrogen Flow Control Valve Poppet Breakage

The Main Propulsion System (MPS) uses three Flow Control Valves (FCV) to modulate the flow of pressurant hydrogen gas from the Space Shuttle Main Engines (SSME) to the hydrogen External Tank (ET). This maintains pressure in the ullage volume as the liquid level drops, preserving ET structural integrity and assuring the engines receive a sufficient amount of head pressure. On Space Transportation System (STS)-126 (2009), with only a handful of International Space Station (ISS) assembly flights from the end of the Shuttle program, a portion of a single FCV?s poppet head broke off at about a minute and a half after liftoff. The risk of the poppet head failure is that the increased flow area through the FCV could result in excessive gaseous hydrogen flow back to the external tank, which could result in overboard venting of hydrogen ullage pressure. If the hydrogen venting were to occur in first stage (i.e., lower atmosphere), a flammability hazard exists that could lead to catastrophic loss of crew and vehicle. Other failure risks included particle impact damage to MPS downstream hardware. Although the FCV design had been plagued by contamination-related sluggish valve response problems prior to a redesign at STS-80 (1996), contamination was ruled out as the cause of the STS-126 failure. Employing a combination of enhanced hardware inspection and a better understanding of the consequences of a poppet failure, safe flight rationale for subsequent flights (STS-119 and later) was achieved. This paper deals with the technical lessons learned during the investigation and mitigation of this problem at a time when assembly flights were each in the critical path to Space Station success.

Martinez, Hugo E.↗
DOE OSTI2024

Artificial Intelligence Transforming Post-Translational Modification Research

Post-Translational Modifications (PTMs) are covalent changes to amino acids that occur after protein synthesis, including covalent modifications on side chains and peptide backbones. Many PTMs profoundly impact cellular and molecular functions and structures, and their significance extends to evolutionary studies as well. In light of these implications, we have explored how artificial intelligence (AI) can be utilized in researching PTMs. Initially, rationales for adopting AI and its advantages in understanding the functions of PTMs are discussed. Then, various deep learning architectures and programs, including recent applications of language models, for predicting PTM sites on proteins and the regulatory functions of these PTMs are compared. Finally, our high-throughput PTM-data-generation pipeline, which formats data suitably for AI training and predictions is described. We hope this review illuminates areas where future AI models on PTMs can be improved, thereby contributing to the field of PTM bioengineering.

59 BASIC BIOLOGICAL SCIENCES↗
NASA NTRS2003

Shuttle Payload Ground Command and Control: An Experiment Implementation Combustion Module-2 Software Development, STS-107

This presentation covers the design of a command and control architecture developed by the author for the Combustion Module-2 microgravity experiment, which flew aboard the STS-107 Shuttle mission, The design was implemented to satisfy a hybrid network that utilized TCP/IP for both the onboard segment and ground segment, with an intermediary unreliable transport for the space to ground segment. With the infusion of Internet networking technologies into Space Shuttle, Space Station, and spacecraft avionics systems, comes the need for robust methodologies for ground command and control. Considerations of high bit error links, and unreliable transport over intermittent links must be considered in such systems. Internet protocols applied to these systems, coupled with the appropriate application layer protections, can provide adequate communication architectures for command and control. However, there are inherent limitations and additional complexities added by the use of Internet protocols that must be considered during the design. This presentation will discuss the rationale for the: framework and protocol algorithms developed by the author. A summary of design considerations, implantation issues, and learned lessons will be will be presented. A summary of mission results using this communications architecture will be presented. Additionally, areas of further needed investigation will be identified.

Carek, David Andrew↗
NASA NTRS1994

Lessons learned in deploying software estimation technology and tools

Developing a software product involves estimating various project parameters. This is typically done in the planning stages of the project when there is much uncertainty and very little information. Coming up with accurate estimates of effort, cost, schedule, and reliability is a critical problem faced by all software project managers. The use of estimation models and commercially available tools in conjunction with the best bottom-up estimates of software-development experts enhances the ability of a product development group to derive reasonable estimates of important project parameters. This paper describes the experience of the IBM Software Solutions (SWS) Toronto Laboratory in selecting software estimation models and tools and deploying their use to the laboratory's product development groups. It introduces the SLIM and COSTAR products, the software estimation tools selected for deployment to the product areas, and discusses the rationale for their selection. The paper also describes the mechanisms used for technology injection and tool deployment, and concludes with a discussion of important lessons learned in the technology and tool insertion process.

Panlilio-Yap, Nikki↗
NASA NTRS2016

Assessment of the Orion-SLS Interface Management Process in Achieving the EIA 731.1 Systems Engineering Capability Model Generic Practices Level 3 Criteria

NASA is currently developing the next generation crewed spacecraft and launch vehicle for exploration beyond earth orbit including returning to the Moon and making the transit to Mars. Managing the design integration of major hardware elements of a space transportation system is critical for overcoming both the technical and programmatic challenges in taking a complex system from concept to space operations. An established method of accomplishing this is formal interface management. In this paper we set forth an argument that the interface management process implemented by NASA between the Orion Multi-Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) achieves the Level 3 tier of the EIA 731.1 System Engineering Capability Model (SECM) for Generic Practices. We describe the relevant NASA systems and associated organizations, and define the EIA SECM Level 3 Generic Practices. We then provide evidence for our compliance with those practices. This evidence includes discussions of: NASA Systems Engineering Interface (SE) Management standard process and best practices; the tailoring of that process for implementation on the Orion to SLS interface; changes made over time to improve the tailored process, and; the opportunities to take the resulting lessons learned and propose improvements to our institutional processes and best practices. We compare this evidence against the practices to form the rationale for the declared SECM maturity level.

Jellicorse, John J.↗
DOE OSTI2023

CyTRICS Impact-Based Prioritization Process

Cyber Testing for Resilient Industrial Control Systems™ (CyTRICS™) is the Department of Energy’s (DOE’s) program for cybersecurity vulnerability testing, digital subcomponent enumeration, and forensic assessment. CyTRICS leverages best-in-class test facilities and analytic capabilities at six DOE National Laboratories and strategic partnerships with key stakeholders including technology developers, manufacturers, asset owners and operators, and interagency partners. During the program’s development, CyTRICS established a unique methodology for prioritizing digital components within operational technology (OT) and industrial control systems (ICS) in the Energy Sector Industrial Base (ESIB) for cyber vulnerability testing. The CyTRICS prioritization process leverages multiple characteristics of systems, components, and their contextual deployment to calculate a quantification of individual digital components for CyTRICS testing. The initial version of the CyTRICS prioritization process was premised largely upon the impact which could result to an energy sector industrial control system if the digital component under testing was compromised, either through malicious means, faulty engineering, or other modes. CyTRICS has termed this process the “CyTRICS Impact-based Prioritization Process.” This paper describes the factors identified for use in the Impact-based Prioritization process and identifies the rationale for inclusion. During development, three National Laboratories piloted this prioritization process and generated prioritization scores for seven systems. Following the piloting of the process, laboratory subject matter experts (SME) validated that the numerical scores generated by the prioritization process were consistent with their knowledge of the impact that may occur should any of these systems be disrupted. The following document explains how to perform the prioritization process to generate prioritization scores for energy sector systems. After outlining assumptions required to conduct the process, it describes how to identify and elicit data which can be leveraged to evaluate a system and assign numerical values for each factor. The prioritization process uses different weights on different factors; rationale for each weight is included within the paper. Additionally, the paper includes some recommendations for future enhancements to prioritization, including lessons learned from developing and piloting the process. Finally, a comprehensive appendix includes example documents to be leveraged by those looking to execute the prioritization process.

99 GENERAL AND MISCELLANEOUS↗