Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Guideline documentation”

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
All sourcesNASA NTRSDOE OSTI
NASA NTRS1976

Atmospheric, Magnetospheric and plasmas in Space (AMPS) spacelab payload definition study; Volume 4: Part 3, Labcraft instrument systems general specification

Guidelines and general requirements applicable to the development of instrument flight hardware intended for use on the GSFC Shuttle Scientific Payloads Program are given. Criteria, guidelines, and an organized approach to specifying the appropriate level of requirements for each instrument in order to permit its development at minimum cost while still assuring crew safety, are included. It is recognized that the instruments for these payloads will encompass wide ranges of complexity, cost, development risk, and safety hazards. The flexibility required to adapt the controls, documentation, and verification requirements in accord with the specific instrument is provided.

Keeley, J. T.↗
NASA NTRSDate not supplied

Safe Space Conduct: NASA Best Practices Overview

While prevention of launch and on-orbit collisions has been an institutional concern of NASA for several decades (beginning with the Shuttle program), historically the paucity of spaceactors and deployed payloads made the conduct of such protection activities relatively straightforward. With the substantial increases in launched payloads over the last several years, collision avoidance operations have become substantially more complicated. At the same time, many operators are uncertain regarding what collision avoidance activities are appropriate to their missions. The lack of a space traffic management authority to articulate standards and guidelines for such conduct has only increased the confusion.In response to this situation, NASA has published a Spacecraft Conjunction Assessment and Collision Avoidance Handbook, which articulates and explains the launch and on-orbit collision avoidance best practices that the Agency has developed and is requiring of present and future NASA missions. Because the CA2 Handbook is a living document regularly updated to reflect best practices changes as the industry develops, feedback from both NASA missions and other users is continuously collected in order to issue CA2 Handbook updates.This talk will summarize and explain the collision avoidance best practices from the CA2Handbook, along with the key issues that drove the selection of those practices.

Conjunction Assessment↗
NASA NTRSDate not supplied

NASA Best Practices Overview

While prevention of launch and on-orbit collisions has been an institutional concern of NASA for several decades (beginning with the Shuttle program), historically the paucity of space actors and deployed payloads made the conduct of such protection activities relatively straightforward. With the substantial increases in launched payloads over the last several years, collision avoidance operations have become substantially more complicated. At the same time, many operators are uncertain regarding what collision avoidance activities are appropriate to their missions. The lack of a space traffic management authority to articulate standards and guidelines for such conduct has only increased the confusion. In response to this situation, NASA has published a Spacecraft Conjunction Assessment and Collision Avoidance Handbook, which articulates and explains the launch and on-orbit collision avoidance best practices that the Agency has developed and is requiring of present and future NASA missions. Because the CA2 Handbook is a living document regularly updated to reflect best practices changes as the industry develops, feedback from both NASA missions and other users is continuously collected in order to issue CA2 Handbook updates. This talk will summarize and explain the collision avoidance best practices from the CA2 Handbook, along with the key issues that drove the selection of those practices.

Conjunction Assessment↗
NASA NTRS1997

Integrated Requirements Analysis and Technology Roadmaps

In fiscal year 1997, Strategic Insight performed analytical studies for NASA's Highly Reusable Space Transportation (HRST) program, creating program documents which illuminated technical requirements and critical research opportunities. Studies were performed to structure and confirm HRST's evolving technical requirements, building on Marshall's Phase 1 work, which defined HRST system concepts, analytical tools and high-level issues for assessment in Phase 2. Specifically, Strategic Insight: (1) Performed a requirements analysis to update HRST: An Advanced Concepts Study, Study Guidelines, Version 2.0 of January 22, 1996; only minor changes were recommended for the given parameters of interest to concept designers; (2) Conducted mini-workshops during HRST Working Group meetings on April 14-15, 1997 and July 22-24, 1997; and (3) Created structures for technology road maps of candidate HRST concepts, both subsystem and end-to-end concepts, emerging from the 13 cooperative agreement projects.

Source record↗
NASA NTRS2014

Single Event Effects (SEE) Testing: Practical Approach to Test Plans

While standards and guidelines for performing SEE testing have existed for several decades, guidance for developing SEE test plans has not been as easy to find. In this presentation, the variety of areas that need to be considered ranging from resource issues (funds, personnel, schedule) to extremely technical challenges (particle interaction and circuit application), shall be discussed. Note: we consider the approach outlined here as a "living" document: Mission-specific constraints and new technology related issues always need to be taken into account.

Single Event Effects (SEE)↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2016

NASA Standing Review Board Handbook: Revision B

This SRB Handbook provides review guidance for the program and project communities and for the SRBs regarding the expectations, processes, products, timelines, and working interfaces with review organizations, Centers, Mission Directorates, Mission Support Organizations, and Management Councils. It provides guidelines for membership selection, review implementation, review products, and reporting of results. The SRB Handbook guidance may be tailored, with the Convening Authorities' approval, to meet the needs of the Agency, Mission Directorates, Centers, and the programs and projects being reviewed. The final review agreement of the SRB, program and project, and Convening Authorities for program and project Life-Cycle Reviews (LCRs) is documented in the terms of reference, as described in Section 4.1 and Appendix H.

Tahani R Amer↗
NASA NTRS2005

Access 5 - Step 1: Human Systems Integration Program Plan (HSIPP)

This report describes the Human System Interface (HSI) analysis, design and test activities that will be performed to support the development of requirements and design guidelines to facilitate the incorporation of High Altitude Long Endurance (HALE) Remotely Operated Aircraft (ROA) at or above FL400 in the National Airspace System (NAS). These activities are required to support the design and development of safe, effective and reliable ROA operator and ATC interfaces. This plan focuses on the activities to be completed for Step 1 of the ACCESS 5 program. Updates to this document will be made for each of the four ACCESS 5 program steps.

Source record↗
NASA NTRS1973

Extravehicular activities guidelines and design criteria

A listing of astronaut EVA support systems and equipment, and the physical, operational, and performance characteristics of each major system are presented. An overview of the major ground based support operations necessary in the development and verification of orbital EVA systems is included. The performance and biomedical characteristics of man in the orbital EV environment are discussed. Major factors affecting astronaut EV work performance are identified and delineated as they relate to EV support systems design. Data concerning the medical and physiological aspects of spaceflight on man are included. The document concludes with an extensive bibliography, and a series of appendices which expand on some of the information presented in the main body.

Brown, N. E.↗
NASA NTRS2003

Integration and Test of Shuttle Small Payloads

Recommended approaches for space shuttle small payload integration and test (I&T) are presented. The paper is intended for consideration by developers of shuttle small payloads, including I&T managers, project managers, and system engineers. Examples and lessons learned are presented based on the extensive history of NASA's Hitchhiker project. All aspects of I&T are presented, including: (1) I&T team responsibilities, coordination, and communication; (2) Flight hardware handling practices; (3) Documentation and configuration management; (4) I&T considerations for payload development; (5) I&T at the development facility; (6) Prelaunch operations, transfer, orbiter integration and interface testing; (7) Postflight operations. This paper is of special interest to those payload projects that have small budgets and few resources: that is, the truly faster, cheaper, better projects. All shuttle small payload developers are strongly encouraged to apply these guidelines during I&T planning and ground operations to take full advantage of today's limited resources and to help ensure mission success.

Wright, Michael R.↗
NASA NTRS2001

Integration and Test for Small Shuttle Payloads

Recommended approaches for shuttle small payload integration and test (I&T) are presented. The paper is intended for consideration by developers of small shuttle payloads, including I&T managers, project managers, and system engineers. Examples and lessons learned are presented based on the extensive history of the NASA's Hitchhiker project. All aspects of I&T are presented, including: (1) I&T team responsibilities, coordination, and communication; (2) Flight hardware handling practices; (3) Documentation and configuration management; (4) I&T considerations for payload development; (5) I&T at the development facility; (6) Prelaunch operations, transfer, orbiter integration, and interface testing; and (7) Postflight operations. This paper is of special interest to those payload projects which have small budgets and few resources: That is, the truly 'faster, cheaper, better' projects. All shuttle small payload developers are strongly encouraged to apply these guidelines during I&T planning and ground operations to take full advantage of today's limited resources and to help ensure mission success.

Wright, Michael R.↗
NASA NTRS2016

The Value of Successful MBSE Adoption

The value of successful adoption of Model Based System Engineering (MBSE) practices is hard to quantify. Most engineers and project managers look at the success in terms of cost. But there are other ways to quantify the value of MBSE and the steps necessary to achieve adoption. The Glenn Research Center (GRC) has been doing Model-Based Engineering (design, structural, etc.) for years, but the system engineering side has not. Since 2010, GRC has been moving from documents centric to MBSE/SysML. Project adoption of MBSE has been slow, but is steadily increasing in both MBSE usage and complexity of generated products. Sharing of knowledge of lessons learned in the implementation of MBSE/SysML is key for others who want to be successful. Along with GRC's implementation, NASA is working hard to increase the successful implementation of MBSE across all the other centers by developing guidelines, templates and libraries for projects to utilize. This presentation will provide insight into recent GRC and NASA adoption efforts, lessons learned and best practices.

MBSE↗
NASA NTRS1998

An approach to the design and implementation of spacecraft attitude control systems

Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.

ODonnell, James R., Jr.↗
NASA NTRS1998

An Approach to the Design and Implementation of Spacecraft Attitude Control Systems

Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and .what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.

ODonnell, James R., Jr.↗
NASA NTRS2004

Handbook for Using IP Protocols for Space Missions

This presentation will provide a summary of a handbook developed at GSFC last year that contains concepts and guidelines for using Internet protocols for space missions. It will include topics on: Lessons learned from current Space IP mission. General architectural issues related to use of IP in space. Operational scenarios for common space data transfer applications. Security issues. A general review of protocols applicable for use with IP in space. The presentation will also pose questions on what sort of information would be useful in future versions of the document.

Hogie, Keith↗
NASA NTRS2006

Human Factors Considerations for Area Navigation Departure and Arrival Procedures

Area navigation (RNAV) procedures are being implemented in the United States and around the world as part of a transition to a performance-based navigation system. These procedures are providing significant benefits and have also caused some human factors issues to emerge. Under sponsorship from the Federal Aviation Administration (FAA), the National Aeronautics and Space Administration (NASA) has undertaken a project to document RNAV-related human factors issues and propose areas for further consideration. The component focusing on RNAV Departure and Arrival Procedures involved discussions with expert users, a literature review, and a focused review of the NASA Aviation Safety Reporting System (ASRS) database. Issues were found to include aspects of air traffic control and airline procedures, aircraft systems, and procedure design. Major findings suggest the need for specific instrument procedure design guidelines that consider the effects of human performance. Ongoing industry and government activities to address air-ground communication terminology, design improvements, and chart-database commonality are strongly encouraged. A review of factors contributing to RNAV in-service errors would likely lead to improved system design and operational performance.

Barhydt, Richard↗
NASA NTRS2026

Towards an improved understanding of the Antarctic coastal zone and its contribution to future global sea level

Understanding the coastal zone of the Antarctic Ice Sheet, where it interacts with the Southern Ocean and warmer air masses, is crucial for predicting Antarctica's influence on the global climate. This region has multiple tipping mechanisms that could trigger large, rapid, and potentially irreversible changes in the coming centuries. The Antarctic Ice Sheet remains the largest source of uncertainty in future sea-level projections. Insufficient knowledge of bed topography beneath the ice shelves and the coastal ice sheet is not yet well documented, but is a major source of this uncertainty. This review assesses current knowledge of the coastal zone and highlights methods to investigate it, including aerogeophysical surveys, ground- and ship-based measurements, satellite observations, and computer modeling. An ensemble analysis of published bed topography datasets identifies significant data gaps and their regional distribution, framed in the context of current ice-sheet behavior and potential instability. We propose scientific priorities and guidelines for future aerogeophysical surveys, advocating for a comprehensive, coordinated international effort to build a next-generation dataset of Antarctic bed properties. Such an initiative would significantly advance understanding of the role of coastal processes in ice-sheet dynamics, reducing uncertainties in sea-level rise projections and enhancing predictions of future ocean and climate changes.

Kenichi Matsuoka↗
NASA NTRS2018

Development of Guidelines for In-Situ Repair of SLS-Class Composite Flight Hardware

The purpose of composite repair development at KSC (John F. Kennedy Space Center) is to provide support to the CTE (Composite Technology for Exploration) project. This is a multi-space center effort with the goal of developing bonded joint technology for SLS (Space Launch System) -scale composite hardware. At KSC, effective and efficient repair processes need to be developed to allow for any potential damage to composite components during transport or launch preparation. The focus of the composite repair development internship during the spring of 2018 was on the documentation of repair processes and requirements for process controls based on techniques developed through hands-on work with composite test panels. Three composite test panels were fabricated for the purpose of repair and surface preparation testing. The first panel included a bonded doubler and was fabricated to be damaged and repaired. The second and third panels were both fabricated to be cut into lap-shear samples to test the strength of bond of different surface preparation techniques. Additionally, jointed composite test panels were impacted at MSFC (Marshall Space Flight Center) and analyzed for damage patterns. The observations after the impact tests guided the repair procedure at KSC to focus on three repair methods. With a finalized repair plan in place, future work will include the strength testing of different surface preparation techniques, demonstration of repair methods, and repair of jointed composite test panels being impacted at MSFC.

Weber, Thomas P., Jr.↗