SEARCH · Engineering Papers

Results for “Requirements”

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 181 records · Page 10

All sources NASA NTRS DOE OSTI

NASA NTRS2002

Remote Sensing Requirements Development: A Simulation-Based Approach

Earth science research and application requirements for multispectral data have often been driven by currently available remote sensing technology. Few parametric studies exist that specify data required for certain applications. Consequently, data requirements are often defined based on the best data available or on what has worked successfully in the past. Since properties such as spatial resolution, swath width, spectral bands, signal-to-noise ratio (SNR), data quantization and band-to-band registration drive sensor platform and spacecraft system architecture and cost, analysis of these criteria is important to optimize system design objectively. Remote sensing data requirements are also linked to calibration and characterization methods. Parameters such as spatial resolution, radiometric accuracy and geopositional accuracy affect the complexity and cost of calibration methods. However, few studies have quantified the true accuracies required for specific problems. As calibration methods and standards are proposed, it is important that they be tied to well-known data requirements. The Application Research Toolbox (ART) developed at the John C. Stennis Space Center provides a simulation-based method for multispectral data requirements development. The ART produces simulated datasets from hyperspectral data through band synthesis. Parameters such as spectral band shape and width, SNR, data quantization, spatial resolution and band-to-band registration can be varied to create many different simulated data products. Simulated data utility can then be assessed for different applications so that requirements can be better understood.

Zanoni, Vicki↗

NASA NTRS2004

Robust Requirements Tracing via Internet Search Technology: Improving an IV and V Technique

There are three major objectives to this phase of the work. (1) Improvement of Information Retrieval (IR) methods for Independent Verification and Validation (IV&V) requirements tracing. Information Retrieval methods are typically developed for very large (order of millions - tens of millions and more documents) document collections and therefore, most successfully used methods somewhat sacrifice precision and recall in order to achieve efficiency. At the same time typical IR systems treat all user queries as independent of each other and assume that relevance of documents to queries is subjective for each user. The IV&V requirements tracing problem has a much smaller data set to operate on, even for large software development projects; the set of queries is predetermined by the high-level specification document and individual requirements considered as query input to IR methods are not necessarily independent from each other. Namely, knowledge about the links for one requirement may be helpful in determining the links of another requirement. Finally, while the final decision on the exact form of the traceability matrix still belongs to the IV&V analyst, his/her decisions are much less arbitrary than those of an Internet search engine user. All this suggests that the information available to us in the framework of the IV&V tracing problem can be successfully leveraged to enhance standard IR techniques, which in turn would lead to increased recall and precision. We developed several new methods during Phase II; (2) IV&V requirements tracing IR toolkit. Based on the methods developed in Phase I and their improvements developed in Phase II, we built a toolkit of IR methods for IV&V requirements tracing. The toolkit has been integrated, at the data level, with SAIC's SuperTracePlus (STP) tool; (3) Toolkit testing. We tested the methods included in the IV&V requirements tracing IR toolkit on a number of projects.

Hayes, Jane↗

NASA NTRS2007

Step 1:Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Collision Avoidance

This document provides definition of technology human interface requirements for Collision Avoidance (CA). This was performed through a review of CA-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Access 5 CA work package were considered... Beginning with the HSI high-level functional requirement for CA, and CA technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge CA system status, and (2) the control capability needed by the pilot to obtain CA information and affect an avoidance maneuver. Fundamentally, these requirements provide the candidate CA technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how CA operations and functions should interface with the pilot to provide the necessary CA functionality to the UA-pilot system .Requirements and guidelines for CA are partitioned into four categories: (1) General, (2) Alerting, (3) Guidance, and (4) Cockpit Display of Traffic Information. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

NASA NTRS2005

Step 1: Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Contingency Management

This document involves definition of technology interface requirements for Contingency Management. This was performed through a review of Contingency Management-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Contingency Management Work Package were considered. Beginning with HSI high-level functional requirements for Contingency Management, and Contingency Management technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge of system failures and associated contingency procedures, and (2) the control capability needed by the pilot to obtain system status and procedure information. Fundamentally, these requirements provide the candidate Contingency Management technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Contingency Management operations and functions should interface with the pilot to provide the necessary Contingency Management functionality to the UA-pilot system. Requirements and guidelines for Contingency Management are partitioned into four categories: (1) Health and Status and (2) Contingency Management. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

NASA NTRS2006

Functional Requirements Document for HALE UAS Operations in the NAS: Step 1. Version 3

The purpose of this Functional Requirements Document (FRD) is to compile the functional requirements needed to achieve the Access 5 Vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the national airspace system (NAS)" for Step 1. These functional requirements could support the development of a minimum set of policies, procedures and standards by the Federal Aviation Administration (FAA) and various standards organizations. It is envisioned that this comprehensive body of work will enable the FAA to establish and approve regulations to govern safe operation of UAS in the NAS on a routine or daily "file and fly" basis. The approach used to derive the functional requirements found within this FRD was to decompose the operational requirements and objectives identified within the Access 5 Concept of Operations (CONOPS) into the functions needed to routinely and safely operate a HALE UAS in the NAS. As a result, four major functional areas evolved to enable routine and safe UAS operations for an on-demand basis in the NAS. These four major functions are: Aviate, Navigate, Communicate, and Avoid Hazards. All of the functional requirements within this document can be directly traceable to one of these four major functions. Some functions, however, are traceable to several, or even all, of these four major functions. These cross-cutting functional requirements support the "Command / Control: function as well as the "Manage Contingencies" function. The requirements associated to these high-level functions and all of their supporting low-level functions are addressed in subsequent sections of this document.

Source record↗

NASA NTRS2008

Defining Constellation Suit Helmet Field of View Requirements Employing a Mission Segment Based Reduction Process

Field of view has always been a design feature paramount to helmet design, and in particular space suit design, where the helmet must provide an adequate field of view for a large range of activities, environments, and body positions. For Project Constellation, a slightly different approach to helmet requirement maturation was utilized; one that was less a direct function of body position and suit pressure and more a function of the mission segment in which the field of view is required. Through taxonimization of various parameters that affect suited FOV, as well as consideration for possible nominal and contingency operations during that mission segment, a reduction process was able to condense the large number of possible outcomes to only six unique field of view angle requirements that still captured all necessary variables without sacrificing fidelity. The specific field of view angles were defined by considering mission segment activities, historical performance of other suits, comparison between similar requirements (pressure visor up versus down, etc.), estimated requirements from other teams for field of view (Orion, Altair, EVA), previous field of view tests, medical data for shirtsleeve field of view performance, and mapping of visual field data to generate 45degree off-axis field of view requirements. Full resolution of several specific field of view angle requirements warranted further work, which consisted of low and medium fidelity field of view testing in the rear entry ISuit and DO27 helmet prototype. This paper serves to document this reduction progress and followup testing employed to write the Constellation requirements for helmet field of view.

McFarland, Shane M.↗

NASA NTRS2010

What is the Final Verification of Engineering Requirements?

This slide presentation reviews the process of development through the final verification of engineering requirements. The definition of the requirements is driven by basic needs, and should be reviewed by both the supplier and the customer. All involved need to agree upon a formal requirements including changes to the original requirements document. After the requirements have ben developed, the engineering team begins to design the system. The final design is reviewed by other organizations. The final operational system must satisfy the original requirements, though many verifications should be performed during the process. The verification methods that are used are test, inspection, analysis and demonstration. The plan for verification should be created once the system requirements are documented. The plan should include assurances that every requirement is formally verified, that the methods and the responsible organizations are specified, and that the plan is reviewed by all parties. The options of having the engineering team involved in all phases of the development as opposed to having some other organization continue the process once the design has been complete is discussed.

Poole, Eric↗

NASA NTRS2006

Requirements and Waivers

Good requirements are the first step for good communications, and good communications are central to insure an understanding between the customer and contractor. Failure to generate good requirements is unfortunately commonplace and repeated. Waivers to requirements are discussed from a risk based point of view. The assumption that every requirement will eventually be waived is used to establish a critical review of a draft safety requirement. Validation methods of requirements are addressed. Value added that safety requirements contribute to the Project is estimated to further our critical review of draft requirements.

Goodin, James Ronald↗

NASA NTRS2014

VARED: Verification and Analysis of Requirements and Early Designs

Requirements are a part of every project life cycle; everything going forward in a project depends on them. Good requirements are hard to write, there are few useful tools to test, verify, or check them, and it is difficult to properly marry them to the subsequent design, especially if the requirements are written in natural language. In fact, the inconsistencies and errors in the requirements along with the difficulty in finding these errors contribute greatly to the cost of the testing and verification stage of flight software projects [1]. Large projects tend to have several thousand requirements written at various levels by different groups of people. The design process is distributed and a lack of widely accepted standards for requirements often results in a product that varies widely in style and quality. A simple way to improve this would be to standardize the design process using a set of tools and widely accepted requirements design constraints. The difficulty with this approach is finding the appropriate constraints and tools. Common complaints against the tools available include ease of use, functionality, and available features. Also, although preferable, it is rare that these tools are capable of testing the quality of the requirements.

Badger, Julia↗

NASA NTRS2014

Advanced Extravehicular Activity Pressure Garment Requirements Development

The NASA Johnson Space Center advanced pressure garment technology development team is addressing requirements development for exploration missions. Lessons learned from the Z‐2 high fidelity prototype development have reiterated that clear low‐level requirements and verification methods reduce risk to the government, improve efficiency in pressure garment design efforts, and enable the government to be a smart buyer. The expectation is to provide requirements at the specification level that are validated so that their impact on pressure garment design is understood. Additionally, the team will provide defined verification protocols for the requirements. However, in reviewing exploration space suit high level requirements there are several gaps in the team's ability to define and verify related lower level requirements. This paper addresses the efforts in requirement areas such as mobility/fit/comfort and environmental protection (dust, radiation, plasma, secondary impacts) to determine the by what method the requirements can be defined and use of those methods for verification. Gaps exist at various stages. In some cases component level work is underway, but no system level effort has begun, in other cases no effort has been initiated to close the gap. Status of ongoing efforts and potential approaches to open gaps are discussed.

Ross, Amy↗

NASA NTRS2015

Advanced Extra-Vehicular Activity Pressure Garment Requirements Development

The NASA Johnson Space Center advanced pressure garment technology development team is addressing requirements development for exploration missions. Lessons learned from the Z-2 high fidelity prototype development have reiterated that clear low-level requirements and verification methods reduce risk to the government, improve efficiency in pressure garment design efforts, and enable the government to be a smart buyer. The expectation is to provide requirements at the specification level that are validated so that their impact on pressure garment design is understood. Additionally, the team will provide defined verification protocols for the requirements. However, in reviewing exploration space suit high level requirements there are several gaps in the team's ability to define and verify related lower level requirements. This paper addresses the efforts in requirement areas such as mobility/fit/comfort and environmental protection (dust, radiation, plasma, secondary impacts) to determine the method by which the requirements can be defined and use of those methods for verification. Gaps exist at various stages. In some cases component level work is underway, but no system level effort has begun; in other cases no effort has been initiated to close the gap. Status of on-going efforts and potential approaches to open gaps are discussed.

Ross, Amy↗

NASA NTRS2019

Gateway System Requirements

The Gateway Program (GW) System Requirements Document (SRD) is approved for the public domain to support NASA's Lunar Gateway Program. The main intent of these documents is to define top level functional and performance requirements for the systems that facilitate cooperative deep space exploration endeavors and execute lunar missions. The SRD defines NASA requirements for the procurement and development of the GW mission. The Gateway Program is a collaboration of US government, international partners and commercial providers. The Gateway SRD are expected to be used by all parties in development of the Gateway Program elements. For effective development and integration of the Gateway vehicle, all involved entities must use, and have awareness of, these high level program requirements to flow down to their respective developmental responsibilities so all Gateway elements will be operable as an entity. The Gateway SRD represents the requirements that are necessary for the Gateway mission. NASA has determined there is benefit to U.S. and foreign spacecraft developers to approve this information for the public domain because all the parties/participants need a common understanding of the requirements and the parameters under which they operate (size, shape, form fit and function). This will allow systems built by various nations and commercial entities to attach and function together properly and safely in the hostile environment of space.The Gateway SRD provides information regarding the current requirements for Gateway elements. Specifically, the Gateway SRD provide an overview of expected features and capabilities and requirements for safe integration of elements within the Gateway program. The SRD contains top-level functional and performance descriptions of the Gateway and definition of the interfaces limited to the scope necessary for integration purposes between Gateway elements. The documents do NOT contain detailed design information or any specifics of hardware or software implementation. The data approved for release does not include: manufacturing drawings, detailed interface control and design data, software code, detailed CAD models, structural or thermal models of the system, avionics or avionics box, board, or cable manufacturing information.

Adamek, Christopher↗

NASA NTRS2021

A Fully Automated Approach to Requirement Extraction from Design Documents

Design documents are intended to outline the goalsof a system or project, which are utilized in the creation ofspecific software requirements. At the NASA Jet PropulsionLaboratory, California Institute of Technology, Functional DesignDescription (FDD) documents describe the scope of theproject and reflect the design and implementation of the system.The specifications in the document are not explicitly writtenas requirements, though these guidelines must be reflected inthe official software requirements. In this work we present afully automatic approach to extracting software requirementsfrom design documents as well as comparing the extractedrequirements to those that exist in the official software requirementdatabase. We do this through (1) sentence extractionfrom the design document, (2) the incorporation of coreferenttext, and (3) aligning the extracted text to the official softwarerequirements. Via natural language processing and informationretrieval techniques, our system results in an automated processthat ensures that the specifications in the design document resultin official software requirements. We find that extraction ofimperatives results in a recall rate of 0.73 and the TF-IDF cosinesimilarity metric is shown to be a useful and successful way tocompare requirements.Though there has been recent work investigating the usefulnessof natural language processing techniques in requirement engineering,this has not been made use of in the aerospace industry.Aerospace requirement engineering is a field particularly ripefor this type of innovation because these techniques can bothautomate some of needlessly manual work and contribute toaerospace safety practices by identifying issues that a humanmay miss. We present the first fully automated approach thatextracts requirements from a design document and comparesthem to a database, and use these findings as encouragementfor future work that makes use of natural language processingtechniques in aerospace requirement engineering.

Briggs, Paul↗

NASA NTRS2023

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗

NASA NTRS2024

Loads and Structural Dynamics Requirements for Spaceflight Hardware

The NASA Exploration Systems Development Mission Directorate requires Crewed Space Systems (CSS) to meet the intent of a set of Engineering Technical Authority (TA) documents called out in HEOMD-003, Crewed Deep Space Systems Human Rating Certification Requirements and Standards for NASA Missions. For the Loads and Dynamics technical discipline, the document invoked by the HEOMD-003 is JSC 65829, Loads and Structural Dynamics Requirements for Spaceflight Hardware. JSC 65829 was originally developed for the NASA Commercial Crew Program as an implementation of NASA STD-5002, Load Analyses of Spacecraft and Payloads, for that Program. Since that time, tailored alternatives to JSC 65829 have been produced for the Gateway, Human Landing System, and Extravehicular Activity and Human Surface Mobility Programs. Experience with those Programs has shown that the reduced set of less-prescriptive requirements in those tailored documents offers an advantage over the set of requirements in JSC 65829 Rev A and is a better fit for the paradigm of NASA procurement of commercially developed systems for crewed spaceflight. Revision B of JSC 65829 has been constructed to align with those tailored documents. The reduction in the number and specificity of requirements is balanced by a new requirement for hardware developers to create and provide a Loads Control Plan which describes how the approaches used to generate design-to loads and dynamic environments and substantiate dynamic model validity satisfy the requirements herein. The Plan will establish an agreement between the hardware developer and the TA for the loads and dynamics discipline and offer an opportunity for reengagement if the Plan changes during development.

Kenneth Schultz↗

DOE OSTI2017

Development of utility generic functional requirements for electronic work packages and computer-based procedures

The Nuclear Electronic Work Packages - Enterprise Requirements (NEWPER) initiative is a step toward a vision of implementing an eWP framework that includes many types of eWPs. This will enable immediate paper-related cost savings in work management and provide a path to future labor efficiency gains through enhanced integration and process improvement in support of the Nuclear Promise (Nuclear Energy Institute 2016). The NEWPER initiative was organized by the Nuclear Information Technology Strategic Leadership (NITSL) group, which is an organization that brings together leaders from the nuclear utility industry and regulatory agencies to address issues involved with information technology used in nuclear-power utilities. NITSL strives to maintain awareness of industry information technology-related initiatives and events and communicates those events to its membership. NITSL and LWRS Program researchers have been coordinating activities, including joint organization of NEWPER-related meetings and report development. The main goal of the NEWPER initiative was to develop a set of utility generic functional requirements for eWP systems. This set of requirements will support each utility in their process of identifying plant-specific functional and non-functional requirements. The NEWPER initiative has 140 members where the largest group of members consists of 19 commercial U.S. nuclear utilities and eleven of the most prominent vendors of eWP solutions. Through the NEWPER initiative two sets of functional requirements were developed; functional requirements for electronic work packages and functional requirements for computer-based procedures. This paper will describe the development process as well as a summary of the requirements.

47 OTHER INSTRUMENTATION↗

DOE OSTI2021

Designing Energy-Efficient Quantum Computers Through Prediction and Reduction of Cooling Requirements for Cryogenic Electronics

Quantum computing has been identified as a “wild card” by the International Energy Agency in predicting future global data center energy usage. This is primarily because both uncertainty in the extent to which quantum computing will be adopted, and uncertainty in the power consumption of individual quantum data centers. Unlike the classical counterparts, quantum computers need to be maintained at near absolute zero, requiring energy-intensive cryogenic cooling systems. Therefore, as quantum computers scale up from existing 50 qubit technology demonstrations to the 10,000 to 100,000 qubit systems that will be able to solve complex problems, the energy consumption of both the electronics and the required cooling systems will also increase. To predict this scaling, this work analyzes the energy requirements for both computation and cooling of quantum hardware. We show that the energy requirements for cooling of quantum computers is determined by several computing system parameters, including the number and type of physical qubits, the operating temperature, the packaging efficiency of the system, and the split between circuits operating at cryogenic temperatures and those operating at room temperature. The energy requirements can then be found based on thermal system parameters such as cooling efficiency and cryostat heat transfer. Analysis of these parameters shows that the energy required for cooling is significantly larger than that required for computation, a reversal from energy usage patterns seen in conventional computing. The results and discussions provide a road-map for creating energy efficient quantum computers through the selection of computer architectures and cryogenic system configurations that minimize cooling requirements.

energy efficiency↗

DOE OSTI2017

Development of utility generic functional requirements for electronic work packages and computer-based procedures - 273

The Nuclear Electronic Work Packages - Enterprise Requirements (NEWPER) initiative is a step toward a vision of implementing an eWP framework that includes many types of eWPs. This will enable immediate paper-related cost savings in work management and provide a path to future labor efficiency gains through enhanced integration and process improvement in support of the Nuclear Promise (Nuclear Energy Institute 2016). The NEWPER initiative was organized by the Nuclear Information Technology Strategic Leadership (NITSL) group, which is an organization that brings together leaders from the nuclear utility industry and regulatory agencies to address issues involved with information technology used in nuclear-power utilities. NITSL strives to maintain awareness of industry information technology-related initiatives and events and communicates those events to its membership. NITSL and Light Water Reactor Sustainability Program researchers have been coordinating activities, including joint organization of NEWPER-related meetings and report development. The main goal of the NEWPER initiative was to develop a set of utility generic functional requirements for eWP systems. This set of requirements will support each utility in their process of identifying plant-specific functional and non-functional requirements. The NEWPER initiative has 140 members where the largest group of members consists of 19 commercial U.S. nuclear utilities and eleven of the most prominent vendors of eWP solutions. Through the NEWPER initiative two sets of functional requirements were developed; functional requirements for electronic work packages and functional requirements for computer-based procedures. This paper will describe the development process as well as a summary of the requirements. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗