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 307 records · Page 17

Validation of the Version 1 NOAA/NASA Pathfinder Sea Surface Temperature Data Set

A high-resolution, global satellite-derived sea surface temperature (SST) data set called Pathfinder, from the Advanced Very High Resolution Radiometer (AVHRR) aboard the NOAA Polar Orbiters, is available from the Jet Propulsion Laboratory Physical Oceanography Distributed Active Archive Center (JPL PO.DAAC). Suitable for research as well as education, the Pathfinder SST data set is a result of a collaboration between the National Oceanographic and Atmospheric Administration (NOAA), the National Aeronautics and Space Administration (NASA) and investigators at several universities. NOAA and NASA are the sponsors of the Pathfinder Program, which takes advantage of currently archived Earth science data from satellites. Where necessary, satellite sensors have been intercalibrated, algorithms improved and processing procedures revised, in order to produce long time-series, global measurements of ocean, land and atmospheric properties necessary for climate research. Many Pathfinder data sets are available to researchers now, nearly a decade before the first launch of NASA's Earth Observing System (EOS). The lessons learned from the Pathfinder programs will facilitate the processing and management of terabytes of data from EOS. The Oceans component of Pathfinder has undertaken to reprocess all Global Area Coverage (GAC) data acquired by the 5-channel AVHRRs since 1981. The resultant data products are consistent and stably calibrated [Rao, 1993a, Rao, 1993b, Brown et al., 1993], Earth-gridded SST fields at a variety of spatial and temporal resolutions.

Smith, Elizabeth A.↗

Profile of NASA software engineering: Lessons learned from building the baseline

It is critically important in any improvement activity to first understand the organization's current status, strengths, and weaknesses and, only after that understanding is achieved, examine and implement promising improvements. This fundamental rule is certainly true for an organization seeking to further its software viability and effectiveness. This paper addresses the role of the organizational process baseline in a software improvement effort and the lessons we learned assembling such an understanding for NASA overall and for the NASA Goddard Space Flight Center in particular. We discuss important, core data that must be captured and contrast that with our experience in actually finding such information. Our baselining efforts have evolved into a set of data gathering, analysis, and crosschecking techniques and information presentation formats that may prove useful to others seeking to establish similar baselines for their organization.

Hall, Dana↗

Conducting Feasibility Studies in a Virtual World: Lessons Learned and Emerging Best Practices from the NASA DEVELOP Program

In response to new workplace realities, the NASA DEVELOP National Program pivoted from co-locating students, emerging professionals, and science advisors to bringing together virtual teams from across the United States. In its spring 2020 term, rapidly evolving circumstances required an ad-hoc roll-out of a virtual approach to complete the spring projects. Based on the experience from the spring term and a few weeks of planning, DEVELOP then conducted a fully virtual summer term with features such as 1) online collaboration tools, 2) virtual machines for analysis, and 3) streamed training offerings, including DEVELOP’s first ever program-wide Software Carpentry workshop. This full term of bringing together remote actors to select, build, and manage teams brought many challenges. Summer feedback has influenced planning for the fall 2020 term and process improvement is ongoing. This presentation will highlight lessons learned throughout this period of rapid change. Feedback from spring and summer terms and the Software Carpentry workshop will be summarized. Beyond participant impacts, there will also be discussion of effects on project results and partner experience. Final takeaways will focus on best practices that have been distilled for virtually-conducted feasibility studies.

NASA DEVELOP↗

Photonics for Space Flight Instruments

For the past 25 years, the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center’s Photonics Group in the Engineering Directorate has been substantially contributing to the flight design, development, production, testing and integration of many science and navigational instruments. The group has an extensive background in screening, qualifying, development and integration of commercial components for spaceflight applications. They have been willing to communicate lessons learned in packaging, part construction, materials selection, testing, and other facets of the design and production process critical to implementation for high-reliability systems. Summarized here is the last ten years of instrumentation development lessons learned and data collected from the subsystems down to the optoelectronic component level.

Spaceflight↗

Developing scheduling benchmark tests for the Space Network

A set of benchmark tests were developed to analyze and measure Space Network scheduling characteristics and to assess the potential benefits of a proposed flexible scheduling concept. This paper discusses the role of the benchmark tests in evaluating alternative flexible scheduling approaches and defines a set of performance measurements. The paper describes the rationale for the benchmark tests as well as the benchmark components, which include models of the Tracking and Data Relay Satellite (TDRS), mission spacecraft, their orbital data, and flexible requests for communication services. Parameters which vary in the tests address the degree of request flexibility, the request resource load, and the number of events to schedule. Test results are evaluated based on time to process and schedule quality. Preliminary results and lessons learned are addressed.

Moe, Karen L.↗

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↗

The Generalized Support Software (GSS) Domain Engineering Process: An Object-Oriented Implementation and Reuse Success at Goddard Space Flight Center

The Flight Dynamics Division (FDD) of NASA's Goddard Space Flight Center (GSFC) recently embarked on a far-reaching revision of its process for developing and maintaining satellite support software. The new process relies on an object-oriented software development method supported by a domain specific library of generalized components. This Generalized Support Software (GSS) Domain Engineering Process is currently in use at the NASA GSFC Software Engineering Laboratory (SEL). The key facets of the GSS process are (1) an architecture for rapid deployment of FDD applications, (2) a reuse asset library for FDD classes, and (3) a paradigm shift from developing software to configuring software for mission support. This paper describes the GSS architecture and process, results of fielding the first applications, lessons learned, and future directions

Condon, Steven↗

Do-It-Yourself: A Special Library's Approach to Creating Dynamic Web Pages Using Commercial Off-The-Shelf Applications

Many librarians may feel that dynamic Web pages are out of their reach, financially and technically. Yet we are reminded in library and Web design literature that static home pages are a thing of the past. This paper describes how librarians at the Institute for Defense Analyses (IDA) library developed a database-driven, dynamic intranet site using commercial off-the-shelf applications. Administrative issues include surveying a library users group for interest and needs evaluation; outlining metadata elements; and, committing resources from managing time to populate the database and training in Microsoft FrontPage and Web-to-database design. Technical issues covered include Microsoft Access database fundamentals, lessons learned in the Web-to-database process (including setting up Database Source Names (DSNs), redesigning queries to accommodate the Web interface, and understanding Access 97 query language vs. Standard Query Language (SQL)). This paper also offers tips on editing Active Server Pages (ASP) scripting to create desired results. A how-to annotated resource list closes out the paper.

Relational databases↗

Wireless Sensor Needs in the Space Shuttle and CEV Structures Communities

This presentation will clarify some of the structural measurement needs of NASA's Space Shuttle and Crew Exploration Vehicles. Emerging technologies in wireless sensor systems can be of some advantage in both Programs. The presentation will address how wireless instrumentation has helped in the past and what has gone unmeasured on Shuttle due to various limitations. Finally, it will address the needs of the CEV program that can be met with reliable wireless systems, if modular avionics interfaces are provided to accommodate the usual evolving needs of an ambitious space vehicle development program. Examples of the advantages of flight data to support flight certification engineering analyses and of areas where add-on wireless instrumentation can be used will be shown. Without flight instrumentation, it is necessary to retain the conservative assumptions used in the design process. It will be shown how the lessons learned on Space Shuttle for wired and wireless structural measurements apply to the Orion Crew Exploration Vehicle (CEV), which is currently being designed.

James, George H., III↗

NASA's Agency-Wide Strategy for Environmental Regulatory Risk Analysis and Communication

NASA's mission is to pioneer the future in space exploration, scientific discovery, and aeronautics research. To help enable existing and future programs to pursue this mission, NASA has established the Principal Center for Regulatory Risk Analysis and Communication (RRAC PC) to proactively identify, analyze, and communicate environmental regulatory risks to the NASA community. The RRAC PC is chartered to evaluate the risks posed to NASA Programs and facilities by environmentally related drivers. The RRAC PC focuses on emerging environmental regulations, as well as risks related to operational changes that can trigger existing environmental requirements. Changing regulations have the potential to directly affect program activities. For example, regulatory changes can restrict certain activities or operations by mandating changes in how operations may be done or limiting where or how certain operations can take place. Regulatory changes also can directly affect the ability to use certain materials by mandating a production phase-out or restricting usage applications of certain materials. Such changes can result in NASA undertaking material replacement efforts. Even if a regulation does not directly affect NASA operations, U.S. and international regulations can pose program risks indirectly through requirements levied on manufacturers and vendors of components and materials. For example, manufacturers can change their formulations to comply with new regulatory requirements. Such changes can require time-consuming and costly requalification certification for use in human spaceflight programs. The RRAC PC has implemented several strategies for proactively managing regulatory change to minimize potential adverse impacts to NASA Programs and facilities. This presentation highlights the lessons learned through establishing the RRAC PC, the process by which the RRAC PC monitors and distributes information about emerging regulatory requirements, and the cross-Agency cooperation that is vital to supporting NASA's mission.

Duda, Kristen↗

NASA's Agency-wide Strategy for Environmental Regulatory Risk Analysis and Communication

NASA's mission is to pioneer the future in space exploration, scientific discovery, and aeronautics research. To help enable existing and future programs to pursue this mission, NASA has established the Principal Center for Regulatory Risk Analysis and Communication (RRAC PC) to proactively identify, analyze, and communicate environmental regulatory risks to the NASA community. The RRAC PC is chartered to evaluate the risks posed to NASA Programs and facilities by environmentally related drivers. The RRAC PC focuses on emerging environmental regulations, as well as risks related to operational changes that can trigger existing environmental requirements. Changing regulations have the potential to directly affect program activities. For example, regulatory changes can restrict certain activities or operations by mandating changes in how operations may be done or limiting where or how certain operations can take place. Regulatory changes also can directly affect the ability to use certain materials by mandating a production phase-out or restricting usage aPi'iications of certain materials. Such changes can result in NASA undertaking material replacement efforts. Even if a regulation does not directly affect NASA operations, U.S. and international regulations can pose program risks indirectly through requirements levied on manufacturers and vendors of components and materials. For example, manufacturers can change their formulations to comply with new regulatory requirements. Such changes can require time-consuming and costly requalification certification for use in human spaceflight programs. The RRAC PC has implemented several strategies for proactively managing regulatory change to minimize potential adverse impacts to NASA Programs and facilities. This presentation highlights the lessons learned through establishing the RRAC PC, the process by which the RRAC PC monitors and distributes information about emerging regulatory requirements, and the cross-Agency cooperation that is vital to supporting NASA's mission.

Duda, Kristen↗

Extending the Reach of IGSN Beyond Earth: Implementing IGSN Registration to Link Nasa's Apollo Lunar Samples and Their Data

The rock and soil samples returned from the Apollo missions from 1969-72 have supported 46 years of research leading to advances in our understanding of the formation and evolution of the inner Solar System. NASA has been engaged in several initiatives that aim to restore, digitize, and make available to the public existing published and unpublished research data for the Apollo samples. One of these initiatives is a collaboration with IEDA (Interdisciplinary Earth Data Alliance) to develop MoonDB, a lunar geochemical database modeled after PetDB (Petrological Database of the Ocean Floor). In support of this initiative, NASA has adopted the use of IGSN (International Geo Sample Number) to generate persistent, unique identifiers for lunar samples that scientists can use when publishing research data. To facilitate the IGSN registration of the original 2,200 samples and over 120,000 subdivided samples, NASA has developed an application that retrieves sample metadata from the Lunar Curation Database and uses the SESAR API to automate the generation of IGSNs and registration of samples into SESAR (System for Earth Sample Registration). This presentation will describe the work done by NASA to map existing sample metadata to the IGSN metadata and integrate the IGSN registration process into the sample curation workflow, the lessons learned from this effort, and how this work can be extended in the future to help deal with the registration of large numbers of samples.

Todd, Nancy S.↗

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗

Data Production on Past and Future NASA Missions

Data return is a metric that is commonly publicized for all space science missions. In the early days of the Space Program, this figure was small, and could be described in bits or maybe even megabits. But now, missions are capable of returning data volumes two or three orders of magnitude larger. For example, Voyager 1 and 2 combined produced a little over 5 Terabits of data in 39 years of operation. In contrast, the Cassini mission, launched two decades after Voyager, produced about one and a half times those data volumes in half the time. NISAR, an Earth Science Mission currently in implementation, plans to produce over 28 Petabits of raw data in just 3 years. This means that NISAR will produce about as many data in 30 days as the combined data production of nearly all planetary missions to date. These increases in capability are a result of technology enhancements in two main areas: telecommunications architecture (both space and ground segments) and data storage technology. This paper describes the progression of these two technologies over the course of more than three decades of space missions and provides additional insight into the design of the end-to-end NISAR Data System Architecture. Trends in the data are briefly explored and compared to Moore’s Law which provides only a qualitative model for memory growth but not for data production. In summary, early missions are found to be driven by unrefined processes while later missions, having utilized earlier lessons learned, focus more on improvements to flight and ground capabilities. Data return seems to fall into three categories. First, deep space missions are driven by the large distances that limit data return to the Earth. Next, the orbiter infrastructure around Mars helps these missions generate more data than other deep space spacecraft. Finally, near-Earth missions have the greatest capabilities for the studied metrics due to their close proximity to Earth and the ground network availability.

Xaypraseuth, Peter↗

Integrated Systems Engineering, Safety, Reliability and Risk Management – Minimizing Black Swan Events

This paper examines key barriers that can possibly inhibit safe and reliable mission execution and, in the worst case, result in loss of human life due to many unknown contributory factors that can lead to Black Swan events. Some of the representative contributory factors include decision errors, overconfidence and a host of common causes including cultural and human factors. Decisions are always easy to criticize in hindsight when more information is available after a major accident. Depending on the type and complexity of the project and/or mission, the catastrophic risks of drifting into failure can be alleviated by implementing uniquely and strategically tailored Integrated-System-of-Systems, dynamic, risk-informed decision management processes. This paper presents some of the lessons learned from James Webb Space Telescope (JWST), NASA’s Human Space Flight program, and industry that provide motivation to organizations working on mega-complex missions to prudently accomplish targeted mission success. These lessons are important for future human Lunar, Mars and Beyond missions planned to be pursued by NASA through a public-private partnership using nimble but effective safety-conscious, proven sound engineering practices including implementation of integrated risk mitigation practices.

SLS↗

Robotics Verification and Validation Strategies for Perseverance Rover Sampling and Caching

The Mars 2020 Sampling and Caching Subsystem(SCS) is the most complex robotic system ever fielded on a MarsRover. It includes a 5 degree-of-freedom Robotic Arm, coringdrill, gas Dust Removal Tool, interfaces for two turret-mountedinstruments, and an Adaptive Caching Assembly (ACA). TheACA is itself a complex robotic system, containing hardware tosupport docking and bit exchange, a 3 degree-of-freedomSample Handling Assembly for manipulating sample tubes,storage for several drill bits and sample tubes, and mechanismsto support observing and sealing samples collected by the drill.To successfully verify and validate the SCS hardware andsoftware and its integration with the Mars 2020 flight systemseveral key strategies were employed.The SCS Verification and Validation (V&V) program utilizedmultiple test venues with tiered levels of fidelity. These includedsimulation and visualization software environments, low fidelitydevelopment testbeds, testbeds with high fidelity SCS hardwareand commercial off-the shelf avionics, integrated systemtestbeds with flight-like avionics, and environmental testbedscapable of simulating Martian surface temperature andpressure. Multiple units of each SCS hardware componentmoved fluidly between test venues to accomplish myriadstandalone and coordinated test objectives. Test preparationand executions were performed by a diverse team of engineerswith training and technical ownership tailored for individualexperience and role. Despite significant differences between testvenues, the SCS V&V team established efficient and consistentprocesses and tools for procedure development, test execution,and data review that enabled personnel, as well as technicalproducts such as sequences and parameter configurations, toflow between venues effectively. A series of benchmark testsprovided evidence of performance consistency as elements weretransferred between venues and as system capability evolved.This paper provides an overview of the SCS V&V program andexplores several overarching strategies that enabled successfuloperation in the face of unprecedented complexity. Keyoutcomes of the SCS validation effort are summarized, alongwith lessons learned and beneficial integrations of validationtool and process innovations into Mars surface operations.

Brooks, Sawyer↗

Approach to Quality Assurance for Complex Environmental Modeling - 20407

A strong Quality Assurance (QA) program for complex environmental modeling is essential for regulatory and public acceptance and trust, but it does not have to be onerous. Neptune and Company, Inc. (Neptune) has developed a strong QA program that improves transparency, traceability, reproducibility, and therefore, defensibility and trust. Neptune's QA program has evolved over the past 27 years, transitioning from an ad hoc QA program, to a program that is currently Nuclear Quality Assurance-1 (NQA-1) compliant, and will soon be NQA-1/DOE approved for DOE EM modeling work. In addition, Neptune is a qualified laboratory assessor and qualified auditor for reference materials, a proficiency testing provider, and fully complies with the Environmental Protection Agency (EPA) QA program. Neptune's President and CEO, Kelly Black, was recently named the Chairperson of the International Organization for Standardization (ISO) Technical Committee 69, Application of Statistical Methods. A strong QA program has been developed for Neptune's radiological performance assessment (PA) program. Although pieces of their QA program are currently in development, their current program includes document control using Subversion, issue tracking and work flow tracking using JIRA, and transparency and traceability via a system of 'calc sheets' for documentation of all data analysis and modeling combined with 'check print' documentation of QA checking, and rigorous model testing and configuration control. All work is reviewed by an independent subject matter expert who is not associated with the collection and assembly of information, for an internal peer review. The program is enforced with a handful of Standard Operation Procedures (SOPs), Work Instructions, QA Project Plans (QAPPs), and Quality Management Plans (QMPs) that are updated frequently, with required annual training and acknowledgment. In addition, effective communication of modeling approaches and results to clients and stakeholders are integral to their QA program. Many of their models are built using the GoldSim modeling platform, for which their models are well-known for their level of transparency, documentation, and QA traceability. This level of QA is also applied to their process-level models. Neptune has taken some lessons learned from the extremely rigorous QA program required for the Yucca Mountain Project (YMP), and imposed the YMP requirements of complete traceability, transparency, and reproducibility, but avoided the inflexibility of a QA program that likely contributed to the suspect e-mails in 2005 that resulted in loss of trust in the YMP, and in nuclear waste disposal (and nuclear power) in general. There are far too many examples of loss of public trust due to poor QA that could have been easily avoided with a simple and straight-forward QA program combined with stakeholder engagement. The purpose of this paper is to share features of Neptune's Radiological Performance Assessment program QA program, and some of their QA related lessons learned over the past 27 years of QA for complex environmental modeling. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Metal Additive Manufacturing for Rocket Engines: Successes and Failures

NASA has been developing additive manufacturing (AM) for various technical and programmatic advantages for complex rocket engine and aerospace components. This maturation has focused on various AM processes, new alloys, characterizing material properties, developing standards, producing demonstrator parts, and integrating AM hardware in liquid rocket engines through test-fail-fix cycles, as well as application and dissemination of lessons learned of the AM lifecycle. The importance of proper AM processing was made evident in the failure of a Laser Powder Bed Fusion (L-PBF) copper-alloy combustion chamber during a hot-fire test due to a degraded material quality. The hot-fire test aimed to demonstrate high duty cycle under a risk-tolerant development project, where consequences of component failure would be minimal. However, the unintentional component failure emphasized the necessity of robust material characterization and rigorous process control procedures for the safe use of AM components in critical applications. This presentation provides an overview of the development failure, a discussion on the evaluation of the failed chamber and supplemental chambers produced at the same time, a representative material samples that included intentional build witness lines, and a summary of the key results and recommendations from the evaluations. NASA continues to approach AM processes and designs with a level of risk and acceptance of failures that is appropriate for the project objectives, with the overall goal of safe implementation of AM technology and transferring AM technology into commercial space applications. This presentation with provide critical awareness to the community lessons learned on proper implementation of AM.

L-PBF↗