SEARCH · Engineering Papers
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.
This presentation provides lessons learned for use of ramp traffic control (RTC) and ramp manager traffic console (RMTC) features of the ATD-2 (Airspace Technology Demonstration 2) Integrated Arrival, Departure, and Surface (IADS) system in an operational environment.
This presentation conveys lessons learned about data, data sources, and TMIs from the ATD-2 field demonstration.
Sixty years of spacesuit knowledge capture and lessons learned by spacesuit subject matter experts are documented on videos and presentations and archived with the NASA Engineering and Safety Center (NESC) Academy. The NESC Academy is a web-based platform that hosts online courses by technical experts. A process is underway to transition these decades of lessons learned from the U.S. Spacesuit Knowledge Capture Program Library into more quicky searchable databases and to proactively provide this information to those working on spacesuit projects. Hundreds of lessons learned from Project Mercury, Gemini, Apollo, Apollo- Soyuz Test Project, Skylab, Space Shuttle, International Space Station, and Artemis have been captured in a format that can be quickly searched, enabling users to find information directly applicable to their needs. Transitioning this information to a NASA wiki page will further enhance search and retrieval of data immediately useful to users. This paper provides information about how the lessons learned were determined and how to access them.
Sixty years of spacesuit knowledge capture and lessons learned by spacesuit subject matter experts are documented on videos and presentations and archived with the NASA Engineering and Safety Center (NESC) Academy. The NESC Academy is a web-based platform that hosts online courses by technical experts. A process is underway to transition these decades of lessons learned from the U.S. Spacesuit Knowledge Capture Program Library into more quicky searchable databases and to proactively provide this information to those working on spacesuit projects. Hundreds of lessons learned from Project Mercury, Gemini, Apollo, Apollo- Soyuz Test Project, Skylab, Space Shuttle, International Space Station, and Artemis have been captured in a format that can be quickly searched, enabling users to find information directly applicable to their needs. Transitioning this information to a NASA wiki page will further enhance search and retrieval of data immediately useful to users. This paper provides information about how the lessons learned were determined and how to access them.
A comprehensive database of engineering lessons learned that corresponds with relevant technical standards will be a valuable asset to those engaged in studies on future space vehicle developments, especially for structures, materials, propulsion, control, operations and associated elements. In addition, this will enable the capturing of technology developments applicable to the design, development, and operation of future space vehicles as planned in the Space Launch Initiative. Using the time-honored tradition of passing on lessons learned while utilizing the newest information technology, NASA has launched an intensive effort to link lessons learned acquired through various Internet databases with applicable technical standards. This paper will discuss the importance of lessons learned, the difficulty in finding relevant lessons learned while engaged in a space vehicle development, and the new NASA effort to relate them to technical standards that can help alleviate this difficulty.
This paper presents the lessons learned from six years of experiments with planetary rover prototypes running the Service Oriented Robotic Architecture (SORA) developed by the Intelligent Robotics Group (IRG) at the NASA Ames Research Center. SORA relies on proven software engineering methods and technologies applied to space robotics. Based on a Service Oriented Architecture and robust middleware, SORA encompasses on-board robot control and a full suite of software tools necessary for remotely operated exploration missions. SORA has been eld tested in numerous scenarios of robotic lunar and planetary exploration. The experiments conducted by IRG with SORA exercise a large set of the constraints encountered in space applications: remote robotic assets, ight relevant science instruments, distributed operations, high network latencies and unreliable or intermittent communication links. In this paper, we present the results of these eld tests in regard to the developed architecture, and discuss its bene ts and limitations.
The following subject areas are covered: expendable launch vehicle lessons learned, upper stage/transfer vehicle lessons learned, shuttle systems - reuse, and reusable system issues and lessons learned.
NASA has an established process for documenting and disseminating lessons learned from spaceflight missions and related activities. However, independent assessments of the NASA lessons learned process conducted in 2002, 2003, and 2011 have concluded that NASA programs and projects are failing to heed and apply these lessons learned. JPL recently completed implementation of a three-pronged approach to assure that NASA lessons learned get used by JPL spaceflight projects.
Lessons learned during the development of the NASA Systems Test and Operations Language (STOL) Intelligent Tutoring System (ITS), being developed at NASA Goddard Space Flight Center are presented. The purpose of the intelligent tutor is to train STOL users by adapting tutoring based on inferred student strengths and weaknesses. This system has been under development for over one year and numerous lessons learned have emerged. These observations are presented in three sections, as follows. The first section addresses the methodology employed in the development of the STOL ITS and briefly presents the ITS architecture. The second presents lessons learned, in the areas of: intelligent tutor development; documentation and reporting; cost and schedule control; and tools and shells effectiveness. The third section presents recommendations which may be considered by other ITS developers, addressing: access, use and selection of subject matter experts; steps involved in ITS development; use of ITS interface design prototypes as part of knowledge engineering; and tools and shells effectiveness.
Experience on International Space Station (ISS) provides many important lessons for future space flight. NASA human factors engineers have been systematically collecting lessons learned from crew debriefs, as well as working with ground support teams to continuously improve crew operations. This paper describes the methods for collecting data from debriefs, lessons learned through that process, and an example of a technology development task funded through the Space Human Factors Engineering (SHFE) program element in response to an identified operational need. Each ISS increment crew spends many hours after the flight answering questions from the various subsystem leads. The Flight Crew Integration subsystem lead asks questions specific to human factors and habitability issues. In addition, crew comments on many other subsystems provide insight into interface designs, operability and maintainability. The debrief comments are unique to each crew, and must be categorized to provide operational lessons learned. Personal identifiers are removed and comments aggregated to separate consistent issues from personal preferences. Examples will be given, and the procedure for incorporating the lessons into requirements and guidelines for the next human space vehicle will be described. In flight, very few astronauts are medical doctors. Written medical procedures during flight need to be easy to follow and quick to understand. The problem was analyzed as part of a SHFE task. Organization was analyzed and reorganizations were created and tested. Results will be reported. The ISS is a very important analog for planning future long-term missions. Collection of data from debriefs, studying the lessons learned and focusing on requirements for future missions are examples of the accomplishments through the SHFE program.
A synoptic of programmatic and technical lessons learned in the development of aerothermodynamic data bases for the X-33 and X-34 programs is presented in general terms and from the perspective of the NASA Langley Research Center Aerothermodynamics Branch. The format used is that of the "aerothermodynamic chain," the links of which are personnel, facilities, models/test articles, instrumentation, test techniques, and computational fluid dynamics (CFD). Because the aerodynamic data bases upon which the X-33 and X-34 vehicles will fly are almost exclusively from wind tunnel testing, as opposed to CFD, the primary focus of the lessons learned is on ground-based testing. The period corresponding to the development of X-33 and X-34 aerothermodynamic data bases was challenging, since a number of other such programs (e.g., X-38, X-43) competed for resources at a time of downsizing of personnel, facilities, etc., outsourcing, and role changes as NASA Centers served as subcontractors to industry. The impact of this changing environment is embedded in the lessons learned. From a technical perspective, the relatively long times to design and fabricate metallic force and moment models, delays in delivery of models, and a lack of quality assurance to determine the fidelity of model outer mold lines (OML) prior to wind tunnel testing had a major negative impact on the programs. On the positive side, the application of phosphor thermography to obtain global, quantitative heating distributions on rapidly fabricated ceramic models revolutionized the aerothermodynamic optimization of vehicle OMLs, control surfaces, etc. Vehicle designers were provided with aeroheating information prior to, or in conjunction with, aerodynamic information early in the program, thereby allowing trades to be made with both sets of input; in the past only aerodynamic data were available as input. Programmatically, failure to include transonic aerodynamic wind tunnel tests early in the assessment phase led to delays in the optimization phase, as OMLs required modification to provide adequate transonic aerodynamic performance without sacrificing subsonic and hypersonic performance. Funding schedules for industry, based on technical milestones, also presented challenges to aerothermodynamics seeking optimum flying characteristics across the subsonic to hypersonic speed regimes and minimum aeroheating. This paper is concluded with a brief discussion of enhancements in ground-based testing/CFD capabilities necessary to partially/fully satisfy future requirements.
This paper describes the lessons learned from introducing CASE methods/tools into organizations and applying them to actual Ada software development projects. This paper will be useful to any organization planning to introduce a software engineering environment (SEE) or evolving an existing one. It contains management level lessons learned, as well as lessons learned in using specific SEE tools/methods. The experiences presented are from Alpha Test projects established under the STARS (Software Technology for Adaptable and Reliable Systems) project. They reflect the front end efforts by those projects to understand the tools/methods, initial experiences in their introduction and use, and later experiences in the use of specific tools/methods and the introduction of new ones.
This article synthesizes and describes the lessons learned from the Network Operations Control Center (NOCC) upgrade project, from the requirements phase through development and test and transfer. At the outset, the NOCC upgrade was being performed simultaneously with two other interfacing and dependent upgrades at the Signal Processing Center (SPC) and Ground Communications Facility (GCF), thereby adding a significant measure of complexity to the management and overall coordination of the development and transfer-to-operations (DTO) effort. Like other success stories, this project carried with it the traditional elements of top management support and exceptional dedication of cognizant personnel. Additionally, there were several NOCC-specific reasons for success, such as end-to-end system engineering, adoption of open-system architecture, thorough requirements management, and use of appropriate off-the-shelf technologies. On the other hand, there were several difficulties, such as ill-defined external interfaces, transition issues caused by new communications protocols, ambivalent use of two sets of policies and standards, and mistailoring of the new JPL management standard (due to the lack of practical guidelines). This article highlights the key lessons learned, as a means of constructive suggestions for the benefit of future projects.
The Vision for Space Exploration sets out a number of goals, involving both strategic and tactical objectives. These include returning the Space Shuttle to flight, completing the International Space Station, and conducting human expeditions to the Moon by 2020. Each of these goals has profound logistics implications. In the consideration of these objectives,a need for a study on NASA logistics lessons learned was recognized. The study endeavors to identify both needs for space exploration and challenges in the development of past logistics architectures, as well as in the design of space systems. This study may also be appropriately applied as guidance in the development of an integrated logistics architecture for future human missions to the Moon and Mars. This report first summarizes current logistics practices for the Space Shuttle Program (SSP) and the International Space Station (ISS) and examines the practices of manifesting, stowage, inventory tracking, waste disposal, and return logistics. The key findings of this examination are that while the current practices do have many positive aspects, there are also several shortcomings. These shortcomings include a high-level of excess complexity, redundancy of information/lack of a common database, and a large human-in-the-loop component. Later sections of this report describe the methodology and results of our work to systematically gather logistics lessons learned from past and current human spaceflight programs as well as validating these lessons through a survey of the opinions of current space logisticians. To consider the perspectives on logistics lessons, we searched several sources within NASA, including organizations with direct and indirect connections with the system flow in mission planning. We utilized crew debriefs, the John Commonsense lessons repository for the JSC Mission Operations Directorate, and the Skylab Lessons Learned. Additionally, we searched the public version of the Lessons Learned Information System (LLIS) and verified that we received the same result using the internal version of LLIS for our logistics lesson searches. In conducting the research, information from multiple databases was consolidated into a single spreadsheet of 300 lessons learned. Keywords were applied for the purpose of sorting and evaluation. Once the lessons had been compiled, an analysis of the resulting data was performed, first sorting it by keyword, then finding duplication and root cause, and finally sorting by root cause. The data was then distilled into the top 7 lessons learned across programs, centers, and activities.
The capabilities and limitations of a particular system design are well known by the people who operate it. Operational workarounds, operational notes and lessons learned are traditional methods for dealing with and documenting design shortcomings. The beginning of each new program brings the hope that hard-learned lessons will be incorporated into the next new system. But often operations personnel find their well-intentioned efforts frustrated by an inability to have their inputs considered by design personnel who have strictly-scoped requirements that are coupled with ambitious cost and schedule targets. There is a way for operational inputs to make it into the design, but the solution involves a combination of organizational culture and technical data. Any organization that utilizes this approach can realize significant benefits over the life cycle of their project.
This paper presents lessons learned from the Space Shuttle return to flight experience and the importance of these lessons learned in the development of new the NASA Crew Launch Vehicle (CLV). Specifically, the paper discusses the relationship between process control and system risk, and the importance of process control in improving space vehicle flight safety. It uses the External Tank (ET) Thermal Protection System (TPS) experience and lessons learned from the redesign and process enhancement activities performed in preparation for Return to Flight after the Columbia accident. The paper also, discusses in some details, the Probabilistic engineering physics based risk assessment performed by the Shuttle program to evaluate the impact of TPS failure on system risk and the application of the methodology to the CLV.
This paper provides an overview of the lessons learned from the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center s (GSFC) Flight Dynamics Facility s (FDF) support of the Time History of Events and Macroscale Interactions during Substorms (THEMIS) spacecraft emergency in February 2007, and the Tracking and Data Relay Satellite-3 (TDRS-3) spacecraft emergency in March 2006. A successful and timely recovery from both of these spacecraft emergencies depended on accurate knowledge of the orbit. Unfortunately, the combination of each spacecraft emergency with very little tracking data contributed to difficulties in estimating and predicting the orbit and delayed recovery efforts in both cases. In both the THEMIS and TDRS-3 spacecraft emergencies, numerous factors contributed to problems with obtaining nominal tracking data measurements. This paper details the various causative factors and challenges. This paper further enumerates lessons learned from FDF s recovery efforts involving the THEMIS and TDRS-3 spacecraft emergencies and scant tracking data, as well as recommendations for improvements and corrective actions. In addition, this paper describes the broad range of resources and complex navigation methods employed within the FDF for supporting critical navigation activities during all mission phases, including launch, early orbit, and on-orbit operations.
Historically, regulatory barriers have precluded nuclear plant safety-related (SR) Instrumentation and Control (I&C) system modernizations. These barriers have been largely addressed by industry and United States Nuclear Regulatory Commission (NRC) efforts, including development of the License Amendment Request (LAR) Alternate Review (AR) process for digital I&C upgrades. The U.S. Department of Energy (DOE) and the Idaho National Laboratory (INL) are supporting a SR I&C pilot upgrade at the Limerick Generating Station (LGS) to demonstrate this process and capturing associated lessons learned for the benefit of industry. In 2021, a paper summarizing lessons learned as captured in INL/EXT-20-59809, Safety Related Instrumentation & Control Pilot Upgrade Initial Scoping Phase Implementation Report and Lessons Learned was presented at the 12th NPIC & HMIT conference. It is recommended that readers of this paper review reference 1 or the associated Nuclear Journal paper for context. This paper summarizes activities performed and lessons learned for the conceptual design phase and portions of the detailed design phase as captured in INL/RPT-23-XXXX, “Safety-Related Instrumentation and Control Pilot Upgrade: Conceptual - Detailed Design Phase Report and Lessons Learned.” The portions of the effort covered by reference 2 include conceptual design phase activities from December 2020, through completion in November 2021, and detailed design activities through September 2022. These efforts and associated detailed documentation in reference 3 are intended to support similar industry upgrades as a foundation stone for a Digital Transformation that will improve plant safety, reliability, and operational performance while lowering plant total cost of ownership.