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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 253 records · Page 14

All sources NASA NTRS DOE OSTI

NASA NTRS1987

Space experiment development process

Described is a process for developing space experiments utilizing the Space Shuttle. The role of the Principal Investigator is described as well as the Principal Investigator's relation with the project development team. Described also is the sequence of events from an early definition phase through the steps of hardware development. The major interactions between the hardware development program and the Shuttle integration and safety activities are also shown. The presentation is directed to people with limited Shuttle experiment experience. The objective is to summarize the development process, discuss the roles of major participants, and list some lessons learned. Two points should be made at the outset. First, no two projects are the same so the process varies from case to case. Second, the emphasis here is on Code EN/Microgravity Science and Applications Division (MSAD).

Depauw, James F.↗

NASA NTRS2008

Preparing Cassini Uplink Operations for Extended Mission

The Cassini-Huygens Mission to Saturn and Titan, a joint venture between the National Aeronautics and Space Administration, the European Space Agency, and the Italian Space Agency, is conducting a four-year, prime mission exploring the Saturnian system, including its atmosphere, rings, magnetosphere, moons and icy satellites. Launched in 1997, Cassini began its prime mission in 2004. Cassini is now preparing for a new era, a two-year extended mission to revisit many of the highlights and new discoveries made during the prime mission. Because of the light time delay from Earth to Saturn, and the time needed to coordinate the complicated science and engineering activities that take place on the spacecraft, commanding on Cassini is done in approximately 40-day intervals known as sequences. The Cassini Uplink Operations team is responsible for the final development and validation of the pointing profile and instrument and spacecraft commands that are contained in a sequence. During this final analysis prior to uplink to the spacecraft, thorough and exact evaluation is necessary to ensure there are no mistakes during commanding. In order to perform this evaluation, complete and refined processes and procedures are fundamental. The Uplink Operations team is also responsible for anomaly response during sequence execution, a process in which critical decisions often are made in real-time. Recent anomalies on other spacecraft missions have highlighted two major risks in the operations process: (1) personnel turnover and the retirement of critical knowledge and (2) aging, outdated operations procedures. If other missions are a good barometer, the Cassini extended mission will be presented with a high personnel turnover of the Cassini flight team, which could lead to a loss of expertise that has been essential to the success of the prime mission. In order to prepare the Cassini Uplink Operations Team for this possibility and to continue to develop and operate safe science and engineering sequences, a review and major update of the current documentation and operations procedures was needed. This paper will address the changes made to extended mission sequence generation processes primarily due to new restrictions in spacecraft operating capability and lessons learned from prime mission. In addition, it will address the state of the prime mission operations procedures, the philosophy changes and updates that were made to those procedures in response to process improvement, and the validation of those new procedures through the training of current and new personnel. And lastly, it will address the lessons learned throughout prime mission and how the Uplink Operations team chose to incorporate those lessons into the working documentation and team knowledge. This incorporation was necessary to facilitate the success of the extended mission with potentially all new personnel at some point prior to the end of the mission.

Maxwell, Jennifer L.↗

NASA NTRS2010

Implementation and Qualifications Lessons Learned for Space Flight Photonic Components

This slide presentation reviews the process for implementation and qualification of space flight photonic components. It discusses the causes for most common anomalies for the space flight components, design compatibility, a specific failure analysis of optical fiber that occurred in a cable in 1999-2000, and another ExPCA connector anomaly involving pins that broke off. It reviews issues around material selection, quality processes and documentation, and current projects that the Photonics group is involved in. The importance of good documentation is stressed.

Ott, Melanie N.↗

NASA NTRS2016

Enabling Science and Deep Space Exploration through Space Launch System (LSL) Secondary Payload Opportunities

For the first time in almost 40 years, a NASA human-rated launch vehicle has completed its Critical Design Review (CDR). By reaching this milestone, NASA's Space Launch System (SLS) and Orion spacecraft are on the path to launch a new era of deep space exploration. NASA is making investments to expand science and exploration capability of the SLS by developing the capability to deploy small satellites during the trans-lunar phase of the mission trajectory. Exploration Mission 1 (EM-1), currently planned for launch no earlier than July 2018, will be the first mission to carry such payloads on the SLS. The EM-1 launch will include thirteen 6U Cubesat small satellites that will be deployed beyond low earth orbit. By providing an earth-escape trajectory, opportunities are created for advancement of small satellite subsystems, including deep space communications and in-space propulsion. This SLS capability also creates low-cost options for addressing existing Agency strategic knowledge gaps and affordable science missions. A new approach to payload integration and mission assurance is needed to ensure safety of the vehicle, while also maintaining reasonable costs for the small payload developer teams. SLS EM-1 will provide the framework and serve as a test flight, not only for vehicle systems, but also payload accommodations, ground processing, and on-orbit operations. Through developing the requirements and integration processes for EM-1, NASA is outlining the framework for the evolved configuration of secondary payloads on SLS Block upgrades. The lessons learned from the EM-1 mission will be applied to processes and products developed for future block upgrades. In the heavy-lift configuration of SLS, payload accommodations will increase for secondary opportunities including small satellites larger than the traditional Cubesat class payload. The payload mission concept of operations, proposed payload capacity of SLS, and the payload requirements for launch and deployment will be described to provide potential payload users an understanding of this unique exploration capability.

Singer, Jody↗

NASA NTRS2016

Secondary Payload Opportunities on NASA's Space Launch System (SLS) Enable Science and Deep Space Exploration

For the first time in almost 40 years, a NASA human-rated launch vehicle has completed its Critical Design Review (CDR). With this milestone, NASA's Space Launch System (SLS) and Orion spacecraft are on the path to launch a new era of deep space exploration. This first launch of SLS and the Orion Spacecraft is planned no later than November 2018 and will fly along a trans-lunar trajectory, testing the performance of the SLS and Orion systems for future missions. NASA is making investments to expand the science and exploration capability of the SLS by developing the capability to deploy small satellites during the trans-lunar phase of the mission trajectory. Exploration Mission 1 (EM-1) will include thirteen 6U Cubesat small satellites to be deployed beyond low earth orbit. By providing an earth-escape trajectory, opportunities are created for the advancement of small satellite subsystems, including deep space communications and in-space propulsion. This SLS capability also creates low-cost options for addressing existing Agency strategic knowledge gaps and affordable science missions. A new approach to payload integration and mission assurance is needed to ensure safety of the vehicle, while also maintaining reasonable costs for the small payload developer teams. SLS EM-1 will provide the framework and serve as a test flight, not only for vehicle systems, but also payload accommodations, ground processing, and on-orbit operations. Through developing the requirements and integration processes for EM-1, NASA is outlining the framework for the evolved configuration of secondary payloads on SLS Block upgrades. The lessons learned from the EM-1 mission will be applied to processes and products developed for future block upgrades. In the heavy-lift configuration of SLS, payload accommodations will increase for secondary opportunities including small satellites larger than the traditional Cubesat class payload. The payload mission concept of operations, proposed payload capacity of SLS, and the payload requirements for launch and deployment will be described to provide potential payload users an understanding of this unique exploration capability.

Singer, Jody↗

NASA NTRS1998

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.↗

NASA NTRS1993

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↗

NASA NTRSDate not supplied

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↗

NASA NTRSDate not supplied

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↗

NASA NTRS1993

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.↗

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 NTRS1997

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↗

NASA NTRS2000

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↗

NASA NTRS2007

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 NTRS2008

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 NTRS2008

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↗

NASA NTRS2016

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.↗

NASA NTRS2016

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↗