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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

GSFC Technical Outreach: The Capitol College Model

In February 2005, as part of the National Aeronautic and Space Administration (NASA) Technical Outreach Program, Goddard Space Flight Center (GSFC) awarded Capitol College of Laurel, Maryland an Educational Grant to establish a Space Operation academic curriculum to meet the future needs of mission operations engineers. This was in part due to the aerospace industry and GSFC concerns that a large number of professional engineers are projected to retire in the near term with evidence showing that current enrollment in engineering schools will not produce sufficient number of space operation trained engineers that will meet industry and government demands. Capitol College, under the agreement of the Educational Grant, established the Space Operations Institute (SOI) with a new curriculum in Space Operations that was approved and certified by the State of Maryland. The SO1 programs focuses on attracting, recruiting, and training a pipeline of highly qualified engineers with experience in mission operations, system engineering and development. The selected students are integrated as members of the engineering support team in any of the missions supported by the institute. The students are mentored by professional engineers from several aerospace companies that support GSFC. Initially, the institute was involved in providing console engineers and mission planning trainees for the Upper Atmosphere Research Satellite (UARS), the Earth Radiation Budget Satellite (ERBS) and the Total Ozone Mapping Spectrometer mission (TOMS). Subsequently, the students were also involved in the technology refresh of the TOMS ground system and other mission operations development. Further mission assignment by GSFC management included participation in the Tropical Rainfall Measuring Mission (TRMM) mission operations and ground system technology refresh. The SOI program has been very successful. Since October 2005, sixty-four students have been enrolled in the SOI program and twenty-five have already graduated from the program, nineteen of whom are employed by company's supporting GSFC. Due to the success of the program, the initial grant period was extended for another period of two years. This paper presents the process that established the SOI as a viable pipeline of mission operations engineers, the lessons learned in the process of dealing with grants, and experience gained in mentoring engineering students that are responsible for particular areas of expertise and functionality. This paper can also be considered a case study and model for integrating a student team with government and industry professionals in the real world of mission operations.

Marius, Julio L.↗
NASA NTRS2002

Lessons Learned In Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The "pieces" are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗
NASA NTRS2002

Lessons Learned in Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The pieces are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗
DOE OSTI2023

Safety-Related Instrumentation and Control Upgrade Pilot Project: NUREG- 0711 Process Development, Planning and Analysis Activities, and Lessons Learned

Constellation Energy and the United States Department of Energy (DOE) have established a public/private partnership to implement a pilot digital upgrade to replace legacy analog, safety-related reactor protection and emergency safety feature actuation systems (RPS/ESFAS) with modern digital systems. This effort is occurring at Constellation’s Limerick Generating Station. This project is being performed in accordance with industry processes that have been adapted to better support digital upgrades. These processes include IP-ENG-001, Standard Design Process, NISP-EN-04, Standard Digital Engineering Process and Electric Power Research Institute Report 3002011816, Digital Engineering Guide. The Light Water Reactor Sustainability (LWRS) Program at the Idaho National Laboratory (INL) has been supporting this effort. Latest INL HFE efforts in support of this project have focused on definition and implementation of the Human Factors Engineering (HFE) Program in support of Constellation design and related licensing efforts. This paper presents the development execution of the HFE Program through completion of the Planning and Analysis Phase as defined by NUREG-0711 as well as HFE lessons learned.

99 GENERAL AND MISCELLANEOUS↗
NASA NTRS2011

Experiences with Text Mining Large Collections of Unstructured Systems Development Artifacts at JPL

Often repositories of systems engineering artifacts at NASA's Jet Propulsion Laboratory (JPL) are so large and poorly structured that they have outgrown our capability to effectively manually process their contents to extract useful information. Sophisticated text mining methods and tools seem a quick, low-effort approach to automating our limited manual efforts. Our experiences of exploring such methods mainly in three areas including historical risk analysis, defect identification based on requirements analysis, and over-time analysis of system anomalies at JPL, have shown that obtaining useful results requires substantial unanticipated efforts - from preprocessing the data to transforming the output for practical applications. We have not observed any quick 'wins' or realized benefit from short-term effort avoidance through automation in this area. Surprisingly we have realized a number of unexpected long-term benefits from the process of applying text mining to our repositories. This paper elaborates some of these benefits and our important lessons learned from the process of preparing and applying text mining to large unstructured system artifacts at JPL aiming to benefit future TM applications in similar problem domains and also in hope for being extended to broader areas of applications.

text mining↗
NASA NTRS2016

Design and Development of NEA Scout Solar Sail Deployer Mechanism

The 6U (approximately10cm x 20cm x 30cm) cubesat Near Earth Asteroid (NEA) Scout, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System (SLS), will utilize a solar sail as its main method of propulsion throughout its approximately 3 year mission to a near earth asteroid. Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems and advance solutions. Though finite element analysis was performed during this process in an attempt to quantify forces present within the mechanism during deployment, both the boom and the sail materials do not lend themselves to achieving high-confidence results. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented here will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.

Sobey, Alexander R.↗
NASA NTRS2004

A Boresight Adjusment Mechanism For Use in Laser Altimeters

This paper describes the development of the Boresight Adjustment Mechanism (BAM) for the Geoscience Laser Altimeter System (GLAS) Instrument. The BAM was developed late in the integration and test phase of the GLAS instrument flight program. Thermal vacuum tests of the GLAS instrument indicated that the instrument-boresight alignment stability over temperature may be marginal. To reduce the risk that GLAS may not be able to meet the boresight alignment requirements an intensive effort was started to develop a BAM. Observatory-level testing and further evaluation of the boresight alignment data indicated that sufficient margin could be obtained utilizing existing instrument resources and therefore the BAM was never integrated onto the GLAS Instrument. However, the BAM was designed fabricated and fully qualified over a 4 month timeframe to be capable of precisely steering (less than 2 arcsec over plus or minus 300 arcsec) the output of three independent lasers to ensure the alignment between the transmit and receive paths of the GLAS instrument. The short timeline for the development of the mechanism resulted in several interesting design solutions. This paper discusses the requirement definition design, and testing processes of the BAM development effort how the design was affected by the extremely tight development schedule and the lessons learned throughout the process.

Hakun, Claef↗
NASA NTRS2004

A Boresight Adjustment Mechanism for use on Laser Altimeters

This paper describes the development of the Boresight Adjustment Mechanism (BAM) for the Geoscience Laser Altimeter System (GLAS) Instrument. The BAM was developed late in the integration and test phase of the GLAS instrument flight program. Thermal vacuum tests of the GLAS instrument indicated that the instrument boresight alignment stability over temperature may be marginal. To reduce the risk that GLAS may not be able to meet the boresight alignment requirements, an intensive effort was started to develop a BAM. Observatory-level testing and further evaluation of the boresight alignment data indicated that sufficient margin could be obtained utilizing existing instrument resources and therefore the BAM was never integrated onto the GLAS Instrument. However, the BAM was designed fabricated and fully qualified over a 4 month timeframe to be capable of precisely steering (< 1 arcsec over 300 arcsec) the output of three independent lasers to ensure the alignment between the transmit and receive paths of the GLAS instrument. The short timeline for the development of the mechanism resulted in several interesting design solutions. This paper discusses the requirement definition, design, and testing processes of the BAM development effort, how the design was affected by the extremely tight development schedule, and the lessons learned throughout the process.

Hakun, Claef↗
NASA NTRS2003

Mechanical Design of a Performance Test Rig for the Turbine Air-Flow Task (TAFT)

To support development of the Boeing-Rocketdyne RS84 rocket engine, a fill-flow, reaction turbine geometry was integrated into the NASA-MSFC turbine air-flow test facility. A mechanical design was generated which minimized the amount of new hardware while incorporating all test and instrUmentation requirements. This paper provides details of the mechanical design for this Turbine Air-Flow Task (TAFT) test rig. The mechanical design process utilized for this task included the following basic stages: Conceptual Design. Preliminary Design. Detailed Design. Baseline of Design (including Configuration Control and Drawing Revision). Fabrication. Assembly. During the design process, many lessons were learned that should benefit future test rig design projects. Of primary importance are well-defined requirements early in the design process, a thorough detailed design package, and effective communication with both the customer and the fabrication contractors. The test rig provided steady and unsteady pressure data necessary to validate the computational fluid dynamics (CFD) code. The rig also helped characterize the turbine blade loading conditions. Test and CFD analysis results are to be presented in another JANNAF paper.

Xenofos, George↗
NASA NTRS2004

Mechanical Design of a Performance Test Rig for the Turbine Air-Flow Task (TAFT)

To support development of the Boeing-Rocketdyne RS84 rocket engine, a full-flow, reaction turbine geometry was integrated into the NASA-MSFC turbine air-flow test facility. A mechanical design was generated which minimized the amount of new hardware while incorporating all test and instrumentation requirements. This paper provides details of the mechanical design for this Turbine Air-Flow Task (TAFT) test rig. The mechanical design process utilized for this task included the following basic stages: Conceptual Design. Preliminary Design. Detailed Design. Baseline of Design (including Configuration Control and Drawing Revision). Fabrication. Assembly. During the design process, many lessons were learned that should benefit future test rig design projects. Of primary importance are well-defined requirements early in the design process, a thorough detailed design package, and effective communication with both the customer and the fabrication contractors.

Forbes, John C.↗
NASA NTRS2016

Design and Development of NEA Scout Solar Sail Deployer Mechanism

The 6U (approximately 10cm x 20cm x 30cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System (SLS), will utilize a solar sail as its main method of propulsion throughout its approximately 3 year mission to a Near Earth Asteroid (NEA). Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.

Sobey, Alexander R.↗
NASA NTRS2016

Design and Development of NEA Scout Solar Sail Deployer Mechanism

The 6U (approx.10 cm x 20 cm x 30 cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System, will utilize a solar sail as its main method of propulsion throughout its approx.3-year mission to a Near Earth Asteroid. Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.

Sobey, Alexander R.↗
NASA NTRSDate not supplied

Preliminary Examination Process of Apollo Core 73002 - Insights and Lessons Learned From ANGSA for Future Sample Return Missions

Apollo Sample 73002 is part of a 2-foot long “drive tube” (73001/73002) of regolith that was collected from a landslide deposit near Lara Crater at the Apollo 17 site, Station 3. The double drive tube is believed to have penetrated a lunar landslide deposit that was transported from the slope of the South Massif into the TLV [1]. As part of the ANGSA (Apollo Next Generation Sample Analyses) initiative, preparing preliminary examination (PE) catalog of 73002 is a crucial first step for the early identification of material types such as rock fragments, and potential stratigraphy within the core. PE of Apollo core 73002 is distinct from science activities with the main goal to produces a sample catalog with a level of detail about sample characterization that is sufficient for the ANGSA PIs (and later on the lunar sample community) to select and request the samples to conduct their individual, scientific studies. Ultimately, the PE catalog of 73002 will help to establish a better understanding of the stratigraphy of the land slide deposit; the processes of the landslide including the trigger(s) and possibly number of landslide events, as well as the role of volatiles [1] and will aid in the careful preservation of the material for future studies [2].

Apollo↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
DOE OSTI2024

Demonstration and Automation of Reflected Target Optical Measurement for Heliostats

Accurate optical surfaces are a primary driver of concentrated solar power plant performance. Errors in pointing and tracking mirrors, the canting of individual mirror facets, and the surface slope of the mirror itself can be caused by errors during assembly, transportation, wind loading, gravity, and many other sources. The tools that exist to measure these error sources today largely rely on fringe deflectometry (SOFAST, QDec, others), or photogrammetry with targets attached to the mirror surface. Since 2022, NREL has been developing a measurement method called the Reflected Target Non-intrusive Assessment (ReTNA) system. This system differs from most established methods in that we perform deflectometry with a pattern of coded targets, identified in space with photogrammetry. Reflected target systems have several advantages over traditional fringe deflectometry systems. Firstly, they can be operated in bright or ambient lighting, a challenge for fringe systems that use a projector and screen. Reflected target systems also can use a much lighter and less expensive target than projector-based systems. Lastly, 2D slope measurement can be solved from a single image, which leads to several advantages for accommodating faster measurements and smaller sized targets. These advantages make ReTNA particularly well-suited for applications where there are space or lighting constraints, like performing heliostat quality assurance on an assembly line. It's also useful when a lightweight, flexible system is needed, like for heliostat developers to quickly measure a new heliostat design at different orientations, to observe gravitational effects on the mirror surface shape. In the last year, significant improvements were made to this tool to make it more useful for these applications. These improvements were focused around validation of the ReTNA measurement system, and automation of the setup and measurement process. First, we present an improved ReTNA layout, for use on the heliostat assembly line. Next, we detail the various changes to the ReTNA software and computer vision methods to automate data collection in this new setup, and lessons learned from this process. The goal with this new setup is to perform a full heliostat surface characterization without removing the mirror from the assembly line. Lastly, we share results from several ReTNA validation studies undertaken over the last year. These include repeated ReTNA measurement on demonstration mirror facets, comparisons with other optical measurement tools, and some studies aimed at quantifying the uncertainty of ReTNA measurement under various constraints (mirror-target spacing, camera resolution, etc.). These results are compared with 2024 HelioCon performance targets, and our planned next steps for the ReTNA measurement system are presented.

CSP↗
NASA NTRS2005

REIMR: A Process for Utilizing Propulsion-Oriented 'Lessons-Learned' to Mitigate Development Risk

This paper is a summary overview of a study conducted a t the NASA Marshall Space Flight Center (MSFC) during the initial phases of the Space Launch Initiative (SLI) program to evaluate a large number of technical problems associated with the design, development, test, evaluation and operation of several major liquid propellant rocket engine systems (i.e., SSME, Fastrac, J-2, F-1). The results of this study was the identification of the "Fundamental Root Causes" that enabled the technical problems to manifest, and practices that can be implemented to prevent them from recurring in future engine development efforts. This paper will discus the Fundamental Root Causes, cite some examples of how the technical problems arose from them, and provide a discussion of how they can be mitigated or avoided.

Ballard, Richard O.↗
NASA NTRS2010

Anatomy of a Security Operations Center

Many agencies and corporations are either contemplating or in the process of building a cyber Security Operations Center (SOC). Those Agencies that have established SOCs are most likely working on major revisions or enhancements to existing capabilities. As principle developers of the NASA SOC; this Presenters' goals are to provide the GFIRST community with examples of some of the key building blocks of an Agency scale cyber Security Operations Center. This presentation viII include the inputs and outputs, the facilities or shell, as well as the internal components and the processes necessary to maintain the SOC's subsistence - in other words, the anatomy of a SOC. Details to be presented include the SOC architecture and its key components: Tier 1 Call Center, data entry, and incident triage; Tier 2 monitoring, incident handling and tracking; Tier 3 computer forensics, malware analysis, and reverse engineering; Incident Management System; Threat Management System; SOC Portal; Log Aggregation and Security Incident Management (SIM) systems; flow monitoring; IDS; etc. Specific processes and methodologies discussed include Incident States and associated Work Elements; the Incident Management Workflow Process; Cyber Threat Risk Assessment methodology; and Incident Taxonomy. The Evolution of the Cyber Security Operations Center viII be discussed; starting from reactive, to proactive, and finally to proactive. Finally, the resources necessary to establish an Agency scale SOC as well as the lessons learned in the process of standing up a SOC viII be presented.

Wang, John↗