Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “lessons learned process”

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 811 records · Page 45
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Lessons Learned Using COTS Electronics for the International Space Station Radiation Environment

The mantra of 'Faster, Better, Cheaper' has to a large degree been interpreted as using Commercial Off-the-Shelf (COTS) components and/or circuit boards. One of the first space applications to actually use COTS in space along with radiation performance requirements was the Expedite the Processing of Experiments to Space Station (EXPRESS) Rack program, for the International Space Station (ISS). In order to meet the performance, cost and schedule targets, military grade Versa Module Eurocard (VME) was selected as the baseline design for the main computer, the Rack Interface Controller (RIC). VME was chosen as the computer backplane because of the large variety of military grade boards available, which were designed to meet the military environmental specifications (thermal, shock, vibration, etc.). These boards also have a paper pedigree in regards to components. Since these boards exceeded most ISS environmental requirements, it was reasoned using COTS mid-grade VME boards, as opposed to designing custom boards could save significant time and money. It was recognized up front the radiation environment of ISS, while benign compared to many space flight applications, would be the main challenge to using COTS. Thus in addition to selecting vendors on how well their boards met the usual performance and environmental specifications, the board's parts lists were reviewed on how well they would perform in the ISS radiation environment. However, issues with verifying that the available radiation test data was applicable to the actual part used, vendor part design changes and the fact most parts did not have valid test data soon complicated board and part selection in regards to radiation.

Blumer, John H.↗
NASA NTRS2016

Brief History of Agricultural Systems Modeling

Agricultural systems science generates knowledge that allows researchers to consider complex problems or take informed agricultural decisions. The rich history of this science exemplifies the diversity of systems and scales over which they operate and have been studied. Modeling, an essential tool in agricultural systems science, has been accomplished by scientists from a wide range of disciplines, who have contributed concepts and tools over more than six decades. As agricultural scientists now consider the next generation models, data, and knowledge products needed to meet the increasingly complex systems problems faced by society, it is important to take stock of this history and its lessons to ensure that we avoid re-invention and strive to consider all dimensions of associated challenges. To this end, we summarize here the history of agricultural systems modeling and identify lessons learned that can help guide the design and development of next generation of agricultural system tools and methods. A number of past events combined with overall technological progress in other fields have strongly contributed to the evolution of agricultural system modeling, including development of process-based bio-physical models of crops and livestock, statistical models based on historical observations, and economic optimization and simulation models at household and regional to global scales. Characteristics of agricultural systems models have varied widely depending on the systems involved, their scales, and the wide range of purposes that motivated their development and use by researchers in different disciplines. Recent trends in broader collaboration across institutions, across disciplines, and between the public and private sectors suggest that the stage is set for the major advances in agricultural systems science that are needed for the next generation of models, databases, knowledge products and decision support systems. The lessons from history should be considered to help avoid roadblocks and pitfalls as the community develops this next generation of agricultural systems models.

agricultural systems↗
NASA NTRS1999

Testing of the International Space Station and X-38 Crew Return Vehicle GPS Receiver

This paper discusses the process and results of the performance testing of the GPS receiver planned for use on the International Space Station (ISS) and the X- 38CrewReturnVehicle(CRV). The receiver is a Force-19 unit manufactured by Trimble Navigation and modified in software by NASA:s Goddard Space Flight Center (GSFC) to perform navigation and attitude determination in space. The receiver is the primary source of navigation and attitude information for ISS and CRV. Engineers at GSFC have developed and tested the new receiver with a Global Simulation Systems Ltd (GSS) GPS Signal Generator (GPSSG). This paper documents the unique aspects of ground testing a GPS receiver that is designed for use in space. A discussion of the design of tests using the GPSSG, documentation, data capture, data analysis, and lessons learned will precede an overview of the performance of the new receiver. A description of the challenges that were overcome during this testing exercise will be presented. Results from testing show that the receiver will be within or near the specifications for ISS attitude and navigation performance. The process for verifying other requirements such as Time to First Fix, Time to First Attitude, selection/deselection of a specific GPS satellite vehicles (SV), minimum signal strength while still obtaining attitude and navigation, navigation and attitude output coverage, GPS week rollover, and Y2K requirements are also given in this paper.

Simpson, James↗
DOE OSTI2020

Methods and Experiences for Developing Abstractions for Data-intensive, Scientific Applications

Developing software for scientific applications that require the integration of diverse types of computing, instruments, and data present challenges that are distinct from commercial software. These applications require scale, and the need to integrate various programming and computational models with evolving and heterogeneous infrastructure. Pervasive and effective abstractions for distributed infrastructures are thus critical; however, the process of developing abstractions for scientific applications and infrastructures is not well understood. While theory-based approaches for system development are suited for well-defined, closed environments, they have severe limitations for designing abstractions for scientific systems and applications. The design science research (DSR) method provides the basis for designing practical systems that can handle real-world complexities at all levels. In contrast to theory-centric approaches, DSR emphasizes both practical relevance and knowledge creation by building and rigorously evaluating all artifacts. In this work, we show how DSR provides a well-defined framework for developing abstractions and middleware systems for distributed systems. Specifically, we address the critical problem of distributed resource management on heterogeneous infrastructure over a dynamic range of scales, a challenge that currently limits many scientific applications. We use the pilot-abstraction, a widely used resource management abstraction for high-performance, high throughput, big data, and streaming applications, as a case study for evaluating the DSR activities. For this purpose, we analyze the research process and artifacts produced during the design and evaluation of the pilot-abstraction. We find DSR provides a concise framework for iteratively designing and evaluating systems. Finally, we capture our experiences and formulate different lessons learned.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1992

The Software Engineering Laboratory: An operational software experience factory

For 15 years, the Software Engineering Laboratory (SEL) has been carrying out studies and experiments for the purpose of understanding, assessing, and improving software and software processes within a production software development environment at NASA/GSFC. The SEL comprises three major organizations: (1) NASA/GSFC, Flight Dynamics Division; (2) University of Maryland, Department of Computer Science; and (3) Computer Sciences Corporation, Flight Dynamics Technology Group. These organizations have jointly carried out several hundred software studies, producing hundreds of reports, papers, and documents, all of which describe some aspect of the software engineering technology that was analyzed in the flight dynamics environment at NASA. The studies range from small, controlled experiments (such as analyzing the effectiveness of code reading versus that of functional testing) to large, multiple project studies (such as assessing the impacts of Ada on a production environment). The organization's driving goal is to improve the software process continually, so that sustained improvement may be observed in the resulting products. This paper discusses the SEL as a functioning example of an operational software experience factory and summarizes the characteristics of and major lessons learned from 15 years of SEL operations.

Basili, Victor R.↗
NASA NTRS2004

Thermal Control Technologies for Complex Spacecraft

Thermal control is a generic need for all spacecraft. In response to ever more demanding science and exploration requirements, spacecraft are becoming ever more complex, and hence their thermal control systems must evolve. This paper briefly discusses the process of technology development, the state-of-the-art in thermal control, recent experiences with on-orbit two-phase systems, and the emerging thermal control technologies to meet these evolving needs. Some "lessons learned" based on experience with on-orbit systems are also presented.

Swanson, Theodore D.↗
NASA NTRS2011

Design and Evaluation of a Cross-Cultural Training System

Cross-cultural competency, and the underlying communication and affective skills required to develop such expertise, is becoming increasingly important for a wide variety of domains. To address this need, we developed a blended learning platform which combines virtual role-play with tutorials, assessment and feedback. A Middle-Eastern Curriculum (MEC) exemplar for cross-cultural training U.S. military personnel was developed to guide the refinement of an existing game-based training platform. To complement this curriculum, we developed scenario authoring tools to enable end-users to define training objectives, link performance measures and feedback/remediation to these objectives, and deploy experiential scenarios within a game-based virtual environment (VE). Lessons learned from the design and development of this exemplar cross-cultural competency curriculum, as well as formative evaluation results, are discussed. Initial findings suggest that the underlying training technology promotes deep levels of semantic processing of the key information of relevant cultural and communication skills.

Santarelli, Thomas↗
NASA NTRS2011

Doppler Radar Profiler for Launch Winds at the Kennedy Space Center (Phase 1a)

The NASA Engineering and Safety Center (NESC) received a request from the, NASA Technical Fellow for Flight Mechanics at Langley Research Center (LaRC), to develop a database from multiple Doppler radar wind profiler (DRWP) sources and develop data processing algorithms to construct high temporal resolution DRWP wind profiles for day-of-launch (DOL) vehicle assessment. This document contains the outcome of Phase 1a of the assessment including Findings, Observations, NESC Recommendations, and Lessons Learned.

Murri, Daniel G.↗
NASA NTRS2015

Lessons Learned from Optical Payload for Lasercomm Science (OPALS) Mission Operations

This paper provides an overview of Optical Payload for Lasercomm Science (OPALS) activities and lessons learned during mission operations. Activities described cover the periods of commissioning, prime, and extended mission operations, during which primary and secondary mission objectives were achieved for demonstrating space-to-ground optical communications. Lessons learned cover Mission Operations System topics in areas of: architecture verification and validation, staffing, mission support area, workstations, workstation tools, interfaces with support services, supporting ground stations, team training, procedures, flight software upgrades, post-processing tools, and public outreach.

Sindiy, Oleg V.↗
NASA NTRSDate not supplied

Open-Source Data Engineering at NASA: CCMC's Approach to Managing Petabyte-Scale Heliophysics Data

The Community Coordinated Modeling Center (CCMC) at NASA Goddard Space Flight Center (GSFC) leads heliophysics research by providing open access to numerous models and their outputs. Our resources are available on-demand and continuously updated with real-time data, covering sun-earth interactions across multiple domains. These domains include coronal, heliosphere, inner and global magnetosphere, ionosphere, thermosphere, and lower atmosphere interactions. Operating in a hybrid environment, CCMC utilizes both self-owned hardware and Amazon Web Services (AWS) cloud infrastructure. Managing petabytes of data across multiple locations necessitates robust data engineering solutions. To address this challenge, CCMC has adopted industry-standard and open-source tools. We use Apache Airflow as our primary data engineering platform, Python for scripting and data processing, and GitLab for version control and CI/CD. Additionally, we employ Kubernetes for containerized services, Grafana and Prometheus for metrics and monitoring, and Terraform and Puppet for reproducible infrastructure as code. This presentation will discuss lessons learned from our data engineering experiences, platforms evaluated but found unsuitable for our scientific data requirements, and specific techniques developed to enhance data transfer speed and reliability. By using these technologies effectively, CCMC continues to advance heliophysics research through efficient data management and open-access modeling.

space weather↗
NASA NTRS1999

Testing of the International Space Station and X-38 Crew Return Vehicle GPS Receiver

This paper discusses the process and results of the performance testing of the GPS receiver planned for use on the International Space Station (ISS) and the X-38 Crew Return Vehicle (CRV). The receiver is a Force-19 unit manufactured by Trimble Navigation and modified in software by the NASA Goddard Space Flight Center (GSFC) to perform navigation and attitude determination in space. The receiver is the primary source of navigation and attitude information for ISS and CRV. Engineers at GSFC have developed and tested the new receiver with a Global Simulation Systems Ltd (GSS) GPS Signal Generator (GPSSG). This paper documents the unique aspects of ground testing a GPS receiver that is designed for use in space. A discussion of the design of tests using the GPSSG, documentation, data capture, data analysis, and lessons learned will precede an overview of the performance of the new receiver. A description of the challenges that were overcome during this testing exercise will be presented. Results from testing show that the receiver will be within or near the specifications for ISS attitude and navigation performance. The process for verifying other requirements such as Time to First Fix, Time to First Attitude, selection/deselection of a specific GPS satellite vehicles (SV), minimum signal strength while still obtaining attitude and navigation, navigation and attitude output coverage, GPS week rollover, and Y2K requirements are also given in this paper.

Simpson, James↗
NASA NTRS2006

Lessons Learned from Daily Uplink Operations during the Deep Impact Mission

The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.

uplink↗
NASA NTRS2018

Creating Innovative Frameworks to Spur Cultural Change at NASA Armstrong Flight Research Center

Changing the culture of an organization is a monumental task that often takes years and has no set formula. Steps can be taken, however, to spur cultural change by creating spaces and infrastructure to serve as the initial driving force. An innovation space and a bicycle sharing (bike share) program were implemented at the National Aeronautics and Space Administration (NASA) Armstrong Flight Research Center (AFRC) (Edwards, California) with a vision toward connecting Center personnel, fostering collaboration and innovation, retaining newer employees, promoting flexibility, and improving the culture and workplace atmosphere. This paper discusses the steps taken, challenges faced, novel culture-change-focused design elements, lessons learned, acquired metrics, and how these initiated cultural change at AFRC. For both the innovation space and the bike share program, funding was negotiated and provided through the NASA Convergent Aeronautics Solutions (CAS) project, which was seeking to improve the innovation and collaboration capabilities at each of the four NASA aeronautics Centers. Key stakeholders across AFRC from upper management, facilities, safety, engineering, and procurement were identified early in the process and were consulted and included throughout execution to ensure that any encountered roadblocks could be easily navigated. Research was then conducted by attending conferences and visiting culture-changing organizations both inside and outside United States Government agencies. Distilling the research, identifying available space, and deciding on specific design elements for the space was conducted by a subset of individuals of diverse backgrounds to enable quick, effective decision-making. Decisions were made with the intent to increase usage and diversity of users of the space; care was taken to ensure a well-crafted atmosphere that would foster the desired culture change. The allocated physical space required major structural modifications, new furniture, and new capabilities that would bring people in. Decisions and desires underwent a rapid reiterative process in order to stay within budget and short deadlines, while holding firm to what was seen as fundamental elements of an innovation space. The framework for cultural change being established, the more difficult task began: incubating the desired culture. Intentional workday use of the innovation space was encouraged, and organized events coordinated in order to truly foster culture change. Such incubation supports the organic spread of culture change to all areas of AFRC. This framework was complemented and expanded by the implementation of the bike share program. Steps for implementation included bike selection based on lessons learned, creating bike stations and signage, implementing bike share rules, and building a volunteer maintenance infrastructure. A novel user-reporting feedback system at each bike station is a low-impact method of capturing usage metrics. Due to the nature of the work conducted at AFRC, the bike share program and feedback system were negotiated and vetted through various organizations including legal, safety, and operations. The innovation space and the bike share program together are an effective initial framework for innovation and collaboration. Culture change takes time, but the innovation space and the bike share program are already showing signs of making a positive impact on the AFRC workforce.

rooms↗
NASA NTRS1999

Testing of the International Space Station and X-38 Crew Return Vehicle GPS Receiver

This paper discusses the process and results of the performance testing of the GPS receiver planned for use on the International Space Station (ISS) and the X-38 Crew Return Vehicle (CRV). The receiver is a Force-19 unit manufactured by Trimble Navigation and Modified in software by the NASA Goddard Space Flight Center (GSFC) to perform navigation and attitude determination in space. The receiver is the primary source of navigation and attitude information for ISS and CRV. Engineers at GSFC have developed and tested the new receiver with a Global Simulation Systems Ltd (GSS) GPS Signal Generator (GPSSG). This paper documents the unique aspects of ground testing a GPS receiver that is designed for use in space. A discussion of the design and tests using the GPSSG, documentation, data capture, data analysis, and lessons learned will precede an overview of the performance of the new receiver. A description of the challenges of that were overcome during this testing exercise will be presented. Results from testing show that the receiver will be within or near the specifications for ISS attitude and navigation performance. The process for verifying other requirements such as Time to First Fix, Time to First Attitude, selection/deselection of a specific GPS satellite vehicles (SV), minimum signal strength while still obtaining attitude and navigation, navigation and attitude output coverage, GPS week rollover, and Y2K requirements are also given in this paper.

Simpson, James↗
DOE OSTI2025

Security-by-Design: Light Water Small Modular Reactor

The growing demand for nuclear power is increasing pressure to find solutions to cost prohibitive requirements of both construction and security. Offsite response has been proposed as an option to reduce costs associated with training and maintaining an onsite response force. A previous report explored this option and revealed that security could be provided at the required level, but cost savings was not a result of this methodology. An offsite response strategy required costly active and passive delay barriers to provide sufficient time for responders to muster and deploy to a site in time to interrupt a determined and well-equipped adversary. Also, contrary to the hypothesis, the number of responders required for this strategy exceeded that needed for an onsite response force, as the adversaries could avail themselves of advantageous positions within the facility to repel arriving responders. This report builds upon the previous evaluation by using the same hypothetical light water small modular reactor (LWSMR) facility model, but this time an onsite response strategy was assessed. The goal of this analysis was to show that an onsite response strategy could be implemented effectively at a cost point that removes barriers within the industry at this critical time of growth and development. The assessment of the facility design and response strategy was completed through modeling using Scribe3D© and subsequent scenario analysis over the course of a two-day tabletop exercise. Subject matter experts in nuclear security, nuclear facility design, and response strategy and tactics contributed to the effort to ensure accurate representation of hypothetical scenarios. Several adaptations were made to the layout of the LWSMR based on lessons learned during the first day of scenario analysis. The subsequent design evaluated on the second day proved to provide a robust response posture against a large and well-trained adversary force. This report details the process of the analysis and compares the cost of the final facility design with that of the LWSMR model used for evaluation of offsite response. Ultimately, the results of this effort indicate that, when implemented correctly, an onsite response strategy is the best option from a security and cost perspective.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS2006

Communal Cooperation in Sensor Networks for Situation Management

Situation management is a rapidly evolving science where managed sources are processed as realtime streams of events and fused in a way that maximizes comprehension, thus enabling better decisions for action. Sensor networks provide a new technology that promises ubiquitous input and action throughout an environment, which can substantially improve information available to the process. Here we describe a NASA program that requires improvements in sensor networks and situation management. We present an approach for massively deployed sensor networks that does not rely on centralized control but is founded in lessons learned from the way biological ecosystems are organized. In this approach, fully distributed data aggregation and integration can be performed in a scalable fashion where individual motes operate based on local information, making local decisions that achieve globally-meaningful results. This exemplifies the robust, fault-tolerant infrastructure required for successful situation management systems.

Jones, Kennie H.↗
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 NTRS2018

TPSAS-NF1676L-30296-DND

A teacher will share how she guided students through the process of making observations to contributing to a GLOBE field campaign, working with a NASA mentor, and ultimately completing group projects which were submitted to the IVSS. Benefits for students will be discussed as well as lessons learned.

STEM↗