SEARCH · Engineering Papers

Results for “documentation requirements tracing”

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 37 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

A Model-Based Systems Engineering Journey to Developing a Concept of Operations

Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.

Jeffrey Robert Cohen↗

NASA NTRS1999

Product Structure, the Heart of Product Definition

This paper describes the LMMSS Product Definition System (PDS) philosophy and approach were the use of each item parts document or software can be traced to a specific end item (EI) serial/tail number of the product. It explains why a part-oriented approach to data organization and configuration management is required. The definition of part-oriented is that all appropriate product definition data products will be collected. Referenced and managed by their linkage/relationship to parts/items, The paper will touch upon how LMMSS store/controls product definition information under each project's top product designator in a two tiered approach. One tier for each product end item and another tier which contain/controls listings of drawings, documents. Specifications and standards that are required for hardware item definition.

DeHoog, C., Jr.↗

DOE OSTI2024

Batch Extraction Studies to Evaluate Trace Element Behavior in PUREX Conditions

The multilab Intentional Forensics Venture is working to identify which stable elements (i.e., taggants) at trace concentrations relative to U would persist throughout the nuclear fuel cycle in a voluntary fuel tagging scheme. A taggant would provide the nuclear forensics community with a “barcode” to help identify nuclear materials found outside of regulatory control. A portion of this project was focused on reprocessing effects and determining which, if any, elements would coextract with U(VI) in standard Pu–U reduction extraction (PUREX) conditions. Elements with a propensity to coextract could, in theory, be used as taggants from a PUREX perspective. Although retention is not a performance requirement, the taggant signature would need to partition predictably from the U stream after the PUREX process to maintain forensic utility. This report documents results from several batch extraction studies with numerous trace elements from HNO 3 (1.5–5 M), with and without U(VI), into 30% tri-n-butyl phosphate (TBP) in kerosene. Extraction and back-extraction tests were used to evaluate nearly 60 elements in surrogate conditions for PUREX, and distribution coefficients (i.e., D-values) for most species were <0.1, indicating few species are likely to co-extract with U through PUREX. Additional studies are needed to optimize sample volumes and dilutions to dial in these low D-values. The D-values (D) were determined for several of the more promising elements, including Re and Se. Ultimately, we conclude that only a limited number of the ~ 60 elements investigated are extractable in the U stream of PUREX, based on measured D values, meaning most candidate elemental taggants would likely be lost at this stage of the nuclear fuel cycle, even when considering a range of acid concentrations.

38 RADIATION CHEMISTRY, RADIOCHEMISTRY, AND NUCLEA↗

NASA NTRS1985

Managing computer-controlled operations

A detailed discussion of Launch Processing System Ground Software Production is presented to establish the interrelationships of firing room resource utilization, configuration control, system build operations, and Shuttle data bank management. The production of a test configuration identifier is traced from requirement generation to program development. The challenge of the operational era is to implement fully automated utilities to interface with a resident system build requirements document to eliminate all manual intervention in the system build operations. Automatic update/processing of Shuttle data tapes will enhance operations during multi-flow processing.

Plowden, J. B.↗

NASA NTRS2009

A Verification-Driven Approach to Traceability and Documentation for Auto-Generated Mathematical Software

Model-based development and automated code generation are increasingly used for production code in safety-critical applications, but since code generators are typically not qualified, the generated code must still be fully tested, reviewed, and certified. This is particularly arduous for mathematical and control engineering software which requires reviewers to trace subtle details of textbook formulas and algorithms to the code, and to match requirements (e.g., physical units or coordinate frames) not represented explicitly in models or code. Both tasks are complicated by the often opaque nature of auto-generated code. We address these problems by developing a verification-driven approach to traceability and documentation. We apply the AUTOCERT verification system to identify and then verify mathematical concepts in the code, based on a mathematical domain theory, and then use these verified traceability links between concepts, code, and verification conditions to construct a natural language report that provides a high-level structured argument explaining why and how the code uses the assumptions and complies with the requirements. We have applied our approach to generate review documents for several sub-systems of NASA s Project Constellation.

Denney, Ewen W.↗

NASA NTRS2016

Command and Data Handling Branch Internship

Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments (TI)' MSP430 16-bit ultra-low-power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display (LCD) touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320 by 240 RGB resistive color screen including an optional carrier board. The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA (Field Programmable Gate Array) development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At the moment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process. Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments’ MSP430 16 bit ultra-low power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320x240 RGB resistive color screen including an optional carrier board.The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At themoment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process.Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate school for a master's or doctorate degree in electrical or computer engineering.

Billings, Rachel Mae↗

NASA NTRSDate not supplied

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

DOE OSTI2026

Metadata Standards for the NSE: Extended Field Standards

This standard presents a set of optional metadata fields for managed digital objects within the Nuclear Security Enterprise (NSE) and provides a deeper look at data representation in metadata by looking at the representation of 1) Records Management required metadata, and 2) common representations of technical/scientific data. Metadata standardization is a critical enabler for effectively sharing data, documents, and other digital objects between NSE sites, and for tracing the digital thread at the object level. Standardization is necessary for both schemas and vocabularies, meaning that both field standards and value standards must be specified. This document serves as a complementary field standard, recommending an optional set of fields that should be uniformly built for all managed digital objects within the NSE. This document specifically focuses on extending the shared discovery layer defined in the first white paper by introducing additional descriptive and data representation fields that improve cross-site search and interpretation.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

NASA NTRS1977

Trace Gas Analyzer (TGA) program

The design, fabrication, and test of a breadboard trace gas analyzer (TGA) is documented. The TGA is a gas chromatograph/mass spectrometer system. The gas chromatograph subsystem employs a recirculating hydrogen carrier gas. The recirculation feature minimizes the requirement for transport and storage of large volumes of carrier gas during a mission. The silver-palladium hydrogen separator which permits the removal of the carrier gas and its reuse also decreases vacuum requirements for the mass spectrometer since the mass spectrometer vacuum system need handle only the very low sample pressure, not sample plus carrier. System performance was evaluated with a representative group of compounds.

Source record↗

DOE OSTI2026

Elevating SolTrace's Capabilities for the Next Generation of Concentrating Solar Analysis

SolTrace is an open-source Monte Carlo ray tracing software developed at NREL. SolTrace can characterize concentrating solar thermal (CST) collector optical performance and is CST technology agnostic. Shown in Fig. 1, SolTrace is a foundational tool in NREL's CST system and component modeling suite. SolTrace's generic surface elements can flexibly model novel collector and receiver designs to predict spatial and temporal flux distributions - critical to understand for CST component design, performance prediction, and system integration. Since its initial development, SolTrace has over 1,650 references on Google Scholar, over 9,800 downloads since 2017, and has served the CST research and development community as a benchmark of 3rd party verification. SolTrace provides users with many options for defining surface shape and boundaries. However, SolTrace provides limited documentation which can result in a steep learning curve for new users. Additionally, SolTrace lacks the computational performance required to evaluate optical performance of a CST system over the course of a year and/or iteratively over design parameters in a timely manner. To address this, we are working towards a new release of SolTrace that enables increased computational throughput by implementing ray tracing acceleration structures and enabling GPU parallelization. Additionally, we are working to improve SolTrace's usability, accessibility, and maintainability by (1) automating solar position time-dependent simulation processes, (2) creating general CST collector templates of grouped elements, (3) updating the user interface to better visualize model inputs and outputs, and (4) creating a user support network through forums, "how to" videos, and documentation.

14 SOLAR ENERGY↗

NASA NTRS1986

Space station WP-04 power system preliminary analysis and design document, volume 3

Rocketdyne plans to generate a system level specification for the Space Station Electric Power System (EPS) in order to facilitate the usage, accountability, and tracking of overall system level requirements. The origins and status of the verification planning effort are traced and an overview of the Space Station program interactions are provided. The work package level interfaces between the EPS and the other Space Station work packages are outlined. A trade study was performed to determine the peaking split between PV and SD, and specifically to compare the inherent total peaking capability with proportionally shared peaking. In order to determine EPS cost drivers for the previous submittal of DRO2, the life cycle cost (LCC) model was run to identify the more significant costs and the factors contributing to them.

Source record↗

NASA NTRS1980

Radio frequency performance of DSS 14 64-meter antenna at X-band using an improved subreflector

The performance of the Deep Space Station (DSS) 14 64-meter antenna X-band gain determined using the X- and K-band Radar feedcone is discussed. Tests prior to, and following the installation of an improved subreflector, proved the unit largely (if not totally) restored initial performance levels at that station. The X-band peak gain with the subreflector is +17.8dBi(area efficiency of 47.3 percent); an increase of +0.47 dB due to the unit installation. The test further showed a significant shift in the axial focus required (function of elevation angle) which, if not implemented operationally, will cause a serious degradation. An historical summary of all documented X-band gain measurements at DSS 14 is included and reviewed. The initial performance is traced through various major configuration changes such as the installation of the X-band dual hybrid mode horn within the operational XRO feedcone. Finally, based on the summary and recent data, a peak X-band antenna gain of +72.1 dBi (area efficiency of 50.8 percent) is projected for the operational feedcone.

Freiley, A. J.↗

NASA NTRS2014

Crystal Stratigraphy of Two Basalts from Apollo 16: Unique Crystallization of Picritic Basalt 606063,10-16 and Very-Low-Titanium Basalt 65703,9-13

A geochemical survey of Apollo 16 regolith fragments found five basaltic samples from among hundreds of 2-4 mm regolith fragments of the Apollo 16 site. These included a high-Ti vitrophyric basalt (60603,10-16) and one very-low-titanium (VLT) crystalline basalt (65703,9-13). Apollo 16 was the only highlands sample return mission distant from the maria (approx. 200 km). Identification of basaltic samples at the site not from the ancient regolith breccia indicates input of material via lateral transport by post-basin impacts. The presence of basaltic rocklets and glass at the site is not unprecedented and is required to satisfy mass-balance constraints of regolith compositions. However, preliminary characterization of olivine and plagioclase crystal size distributions indicated the sample textures were distinct from other known mare basalts, and instead had affinities to impact melt textures. Impact melt textures can appear qualitatively similar to pristine basalts, and quantitative analysis is required to distinguish between the two in thin section. The crystal stratigraphy method is a powerful tool in studying of igneous systems, utilizing geochemical analyses across minerals and textural analyses of phases. In particular, trace element signatures can aid in determining the ultimate origin of these samples and variations document subtle changes occurring during their petrogenesis.

Donohue, P. H.↗

NASA NTRS2001

Geomagnetic Cutoff Rigidity Computer Program: Theory, Software Description and Example

The access of charged particles to the earth from space through the geomagnetic field has been of interest since the discovery of the cosmic radiation. The early cosmic ray measurements found that cosmic ray intensity was ordered by the magnetic latitude and the concept of cutoff rigidity was developed. The pioneering work of Stoermer resulted in the theory of particle motion in the geomagnetic field, but the fundamental mathematical equations developed have 'no solution in closed form'. This difficulty has forced researchers to use the 'brute force' technique of numerical integration of individual trajectories to ascertain the behavior of trajectory families or groups. This requires that many of the trajectories must be traced in order to determine what energy (or rigidity) a charged particle must have to penetrate the magnetic field and arrive at a specified position. It turned out the cutoff rigidity was not a simple quantity but had many unanticipated complexities that required many hundreds if not thousands of individual trajectory calculations to solve. The accurate calculation of particle trajectories in the earth's magnetic field is a fundamental problem that limited the efficient utilization of cosmic ray measurements during the early years of cosmic ray research. As the power of computers has improved over the decades, the numerical integration procedure has grown more tractable, and magnetic field models of increasing accuracy and complexity have been utilized. This report is documentation of a general FORTRAN computer program to trace the trajectory of a charged particle of a specified rigidity from a specified position and direction through a model of the geomagnetic field.

Smart, D. F.↗

NASA NTRS2000

Science Requirements Document for OMI-EOS

A Dutch-Finnish scientific and industrial consortium is supplying the Ozone Monitoring Instrument (OMI) for Earth Observing System-Aura (EOS-Aura). EOS-Aura is the next NASA mission to study the Earth's atmosphere extensively, and successor to the highly successful UARS (Upper Atmospheric Research Satellite) mission. The 'Science Requirements Document for OMI-EOS' presents an overview of the Aura and OMI mission objectives. It describes how OMI fits into the Aura mission and it reviews the synergy with the other instruments onboard Aura to fulfill the mission. This evolves in the Scientific Requirements for OMI (Chapter 3), stating which trace gases have to be measured with what necessary accuracy, in order for OMI to meet Aura's objectives. The most important data product of OMI, the ozone vertical column, densities shall have a better accuracy and an improved global coverage than the predecessor instruments TOMS (Total Ozone Monitoring Spectrometer) and GOME (Global Ozone Monitoring Experiment), which is a.o. achieved by a better signal to noise ratio, improved calibration and a wide field-of-view. Moreover, in order to meet its role on Aura, OMI shall measure trace gases, such as NO2, OClO, BrO, HCHO and SO2, aerosols, cloud top height and cloud coverage. Improved accuracy, better coverage, and finer ground grid than has been done in the past are goals for OMI. After the scientific requirements are defined, three sets of subordinate requirements are derived. These are: the algorithm requirements, i.e. what do the algorithms need in order to meet the scientific requirements; the instrument and calibration requirements, i.e. what has to be measured and how accurately in order to provide the quality of data necessary for deriving the data products; and the validation requirements, i.e. a strategy of how the OMI program will assure that its data products are valid in the atmosphere, at least to the required accuracy.

Levelt, P. F.↗

NASA NTRS2001

Satellite-Based Stratospheric and Tropospheric Measurements: Determination of Global Ozone and other Trace Species

This report summarizes research done under NASA Grant NAG5-3461 from November 1, 1996 through December 31, 2000. The research performed during this reporting period includes development and maintenance of scientific software for the GOME retrieval algorithms, consultation on operational software development for GOME, sensitivity and instrument studies to help finalize the definition of the SCIAMACHY instrument, leading the development of the SCIAMACHY Scientific Requirements Document for Data and Algorithm Development, consultation and development for SCIAMACHY near-real-time (NRT) and off-line (OL) data products, radiative transfer model development for utilization in GOME, SCIAMACHY and other programs, development of infrared line-by-line atmospheric modeling and retrieval capability for SCIAMACHY, and participation in GOME and SCIAMACHY validation studies. The Global Ozone Monitoring Experiment was successfully launched on the ERS-2 satellite on April 20, 1995, and remains working in normal fashion. SCIAMACHY is currently planned for launch in late 2001 on the ESA Envisat satellite. Three GOME-2 instruments are now scheduled to fly on the Metop series of operational meteorological satellites (Eumetsat). K. Chance is a member of the reconstituted GOME Scientific Advisory Group, which will guide the GOME-2 program as well as the continuing ERS-2 GOME program.

Chance, K. V.↗

NASA NTRS2008

EVA Hand Tool Design Considerations, Development, and General Requirements Interpretation: A Junior Engineer’s Guide

This paper serves as a guide to developing hand tools for use by crewmembers during extravehicular activity (EVA) in outer space. It outlines the fundamentals of EVAs and related provisions, providing a starting point and perspective for engineers unfamiliar with designing equipment to be used during manned spaceflight. Common EVA hardware constraints, which are often unclear, are interpreted and traced back to a source or justification because, as in any design field, fully understanding the basis and intent of a design requirement is needed to properly satisfy it. Lastly, miscellaneous design considerations and lessons learned in tool development are discussed. The information found within is drawn from commonly cited NASA and EVA related documents as well as from professional experiences.

EVA↗

NASA NTRS2022

A Survey of NASA Standard Nondestructive Evaluation (NDE)

This document provides a comprehensive review to trace the evolution of NASA’s Standard nondestructive evaluation (NDE) flaw sizes provided in NASA-STD-5009B for fracture-critical metallic spaceflight hardware. A NASA Standard NDE flaw size is considered to be conservative such that most inspectors, trained and certified in the specific method, are expected to provide the required 90/95 probability of detection (POD) for that flaw size. As such, individual certified inspectors are not required to perform POD demonstration testing to be allowed to inspect fracture-critical hardware for that specific method.

Probability of Detection↗