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 649 records · Page 36

All sources NASA NTRS DOE OSTI

NASA NTRS2007

Microbiological Monitoring for the Constellation Program: Current Requirements and Future Considerations

Microbiological requirements for spaceflight are based on assessments of infectious disease risk which could impact crew health or mission success. The determination of risk from infectious disease is composed of several factors including (1) crew susceptibility, (2) crew exposure to the infectious disease agent, (3) the concentration of the infectious agent, and (4) the characteristics of the infectious agent. As a result of the Health Stabilization Program, stringent monitoring, and cleaning protocols, in-flight environmental microbial monitoring is not necessary for short-duration spaceflights. However, risk factors change for long-duration missions, as exemplified by the presence of medically significant organisms in the environments of both the Mir and International Space Station (ISS). Based upon this historical evidence, requirements for short duration usage aboard the Orion Crew Exploration Vehicle and Lunar Lander Vehicle will not require in-flight monitoring; however, as mission duration increases with a Lunar Outpost, an ability to detect microbial hazard will be necessary. The nature of the detection requirements will depend on the maturity of technology in a rapidly evolving marketplace. Regardless, the hardware will still need to maximize information to discipline experts and the crew, while minimizing the size, mass, power consumption, and crew time usage. The refinement of these monitors will be a major goal in our efforts to travel successfully to Mars.

Ott, C. Mark↗

NASA NTRS2006

Design Tools for Cost-Effective Implementation of Planetary Protection Requirements

Since the Viking missions to Mars in the 1970s, accounting for the costs associated with planetary protection implementation has not been done systematically during early project formulation phases, leading to unanticipated costs during subsequent implementation phases of flight projects. The simultaneous development of more stringent planetary protection requirements, resulting from new knowledge about the limits of life on Earth, together with current plans to conduct life-detection experiments on a number of different solar system target bodies motivates a systematic approach to integrating planetary protection requirements and mission design. A current development effort at NASA's Jet Propulsion Laboratory is aimed at integrating planetary protection requirements more fully into the early phases of mission architecture formulation and at developing tools to more rigorously predict associated cost and schedule impacts of architecture options chosen to meet planetary protection requirements.

mission architecture↗

NASA NTRS2007

Electric Propulsion Requirements and Mission Analysis Under NASA's In-Space Propulsion Technology Project

The In-Space Propulsion Technology Project (ISPT) is currently NASA's sole investment in electric propulsion technologies. This project is managed at NASA Glenn Research Center (GRC) for the NASA Headquarters Science Mission Directorate (SMD). The objective of the electric propulsion project area is to develop near-term and midterm electric propulsion technologies to enhance or enable future NASA science missions while minimizing risk and cost to the end user. Systems analysis activities sponsored by ISPT seek to identify future mission applications in order to quantify mission requirements, as well as develop analytical capability in order to facilitate greater understanding and application of electric propulsion and other propulsion technologies in the ISPT portfolio. These analyses guide technology investments by informing decisions and defining metrics for technology development to meet identified mission requirements. This paper discusses the missions currently being studied for electric propulsion by the ISPT project, and presents the results of recent electric propulsion (EP) mission trades. Recent ISPT systems analysis activities include: an initiative to standardize life qualification methods for various electric propulsion systems in order to retire perceived risk to proposed EP missions; mission analysis to identify EP requirements from Discovery, New Frontiers, and Flagship classes of missions; and an evaluation of system requirements for radioisotope-powered electric propulsion. Progress and early results of these activities is discussed where available.

Dudzinski, Leonard a.↗

NASA NTRS2007

Life Support Requirements and Challenges for NASA's Constellation Program

NASA's Constellation Program, which includes the mission objectives of establishing a permanently-manned lunar Outpost, and the exploration of Mars, poses new and unique challenges for human life support systems that will require solutions beyond the Shuttle and International Space Station state of the art systems. In particular, the requirement to support crews for 210 days duration at the lunar outpost with limited resource resupply capability wilt require closed-loop regenerative life support systems with minimal expendables. Planetary environmental conditions such as lunar dust and extreme temperatures, as well as the capability to support frequent and extended-duration EVA's will be particularly challenging. This presentation will summarize the key program and mission life support requirements for the Constellation Program and the unique challenges they present for technology and architecture development.

Carasquillo, Robyn↗

NASA NTRS2007

Space Telecommunications Radio System (STRS) Architecture Goals/Objectives and Level 1 Requirements

The Space Telecommunications Radio System (STRS) Architecture Requirements Document provides the basis for the development of an open architecture for NASA Software Defined Radios (SDRs) for space use. The main objective of this document is to evaluate the goals and objectives and high level (Level 1) requirements that have bearing on the design of the architecture. The goals and objectives will provide broad, fundamental direction and purpose. The high level requirements (Level 1) intend to guide the broader and longer term aspects aspects of the SDR Architecture and provide guidance for the development of level 2 requirements.

Briones, Janette C.↗

NASA NTRS2008

Unmanned Aircraft System Control and ATC Communications Bandwidth Requirements

There are significant activities taking place to establish the procedures and requirements for safe and routine operation of unmanned aircraft systems (UAS) in the National Airspace System (NAS). Among the barriers to overcome in achieving this goal is the lack of sufficient frequency spectrum necessary for the UAS control and air traffic control (ATC) communications links. This shortcoming is compounded by the fact that the UAS control communications links will likely be required to operate in protected frequency spectrum, just as ATC communications links are, because they relate to "safety and regularity of flight." To support future International Telecommunications Union (ITU) World Radio Conference (WRC) agenda items concerning new frequency allocations for UAS communications links, and to augment the Future Communications Study (FCS) Technology Evaluation Group efforts, NASA Glenn Research Center has sponsored a task to estimate the UAS control and ATC communications bandwidth requirements for safe, reliable, and routine operation of UAS in the NAS. This report describes the process and results of that task. The study focused on long-term bandwidth requirements for UAS approximately through 2030.

Henriksen, Steve↗

NASA NTRS2008

Functional Mobility Testing: A Novel Method to Establish Human System Interface Design Requirements

Across all fields of human-system interface design it is vital to posses a sound methodology dictating the constraints on the system based on the capabilities of the human user. These limitations may be based on strength, mobility, dexterity, cognitive ability, etc. and combinations thereof. Data collected in an isolated environment to determine, for example, maximal strength or maximal range of motion would indeed be adequate for establishing not-to-exceed type design limitations, however these restraints on the system may be excessive over what is basally needed. Resources may potentially be saved by having a technique to determine the minimum measurements a system must accommodate. This paper specifically deals with the creation of a novel methodology for establishing mobility requirements for a new generation of space suit design concepts. Historically, the Space Shuttle and the International Space Station vehicle and space hardware design requirements documents such as the Man-Systems Integration Standards and International Space Station Flight Crew Integration Standard explicitly stated that the designers should strive to provide the maximum joint range of motion capabilities exhibited by a minimally clothed human subject. In the course of developing the Human-Systems Integration Requirements (HSIR) for the new space exploration initiative (Constellation), an effort was made to redefine the mobility requirements in the interest of safety and cost. Systems designed for manned space exploration can receive compounded gains from simplified designs that are both initially less expensive to produce and lighter, thereby, cheaper to launch.

England, Scott A.↗

NASA NTRS2005

Registration and Marking Requirements for UAS. Unmanned Aircraft System (UAS) Registration

The registration of an aircraft is a prerequisite for issuance of a U.S. certificate of airworthiness by the FAA. The procedures and requirements for aircraft registration, and the subsequent issuance of registration numbers, are contained in FAR Part 47. However, the process/method(s) for applying the requirements of Parts 45 & 47 to Unmanned Aircraft Systems (UAS) has not been defined. This task resolved the application of 14 CFR Parts 45 and 47 to UAS. Key Findings: UAS are aircraft systems and as such the recommended approach to registration is to follow the same process for registration as manned aircraft. This will require manufacturers to comply with the requirements for 14 CFR 47, Aircraft Registration and 14 CFR 45, Identification and Registration Marking. In addition, only the UA should be identified with the N number registration markings. There should also be a documentation link showing the applicability of the control station and communication link to the UA. The documentation link can be in the form of a Type Certificate Data Sheet (TCDS) entry or a UAS logbook entry. The recommended process for the registration of UAS is similar to the manned aircraft process and is outlined in a 6-step process in the paper.

Source record↗

NASA NTRS2006

Step 1: Human System Interface (HSI) Functional Requirements Document (FRD). Version 2

This Functional Requirements Document (FRD) establishes a minimum set of Human System Interface (HSI) functional requirements 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)". Basically, it provides what functions are necessary to fly UAS in the NAS. The framework used to identify the appropriate functions was the "Aviate, Navigate, Communicate, and Avoid Hazards" structure identified in the Access 5 FRD. As a result, fifteen high-level functional requirements were developed. In addition, several of them have been decomposed into low-level functional requirements to provide more detail.

Source record↗

NASA NTRS2005

Airspace Operations Demo Functional Requirements Matrix

The Flight IPT assessed the reasonableness of demonstrating each of the Access 5 Step 1 functional requirements. The functional requirements listed in this matrix are from the September 2005 release of the Access 5 Functional Requirements Document. The demonstration mission considered was a notional Western US mission (WUS). The conclusion of the assessment is that 90% of the Access 5 Step 1 functional requirements can be demonstrated using the notional Western US mission.

Source record↗

NASA NTRS2006

HALE UAS Command and Control Communications: Step 1 - Functional Requirements Document. Version 4.0

The High Altitude Long Endurance (HALE) unmanned aircraft system (UAS) communicates with an off-board pilot-in-command in all flight phases via the C2 data link, making it a critical component for the UA to fly in the NAS safely and routinely. This is a new requirement in current FAA communications planning and monitoring processes. This document provides a set of comprehensive C2 communications functional requirements and performance guidelines to help facilitate the future FAA certification process for civil UAS to operate in the NAS. The objective of the guidelines is to provide the ability to validate the functional requirements and in future be used to develop performance-level requirements.

Source record↗

NASA NTRS2009

Philosophies Applied in the Selection of Space Suit Joint Range of Motion Requirements

Space suits are the most important tool for astronauts working in harsh space and planetary environments; suits keep crewmembers alive and allow them to perform exploration, construction, and scientific tasks on a routine basis over a period of several months. The efficiency with which the tasks are performed is largely dictated by the mobility features of the space suit. For previous space suit development programs, the mobility requirements were written as pure functional mobility requirements that did not separate joint ranges of motion from the joint torques. The Constellation Space Suit Element has the goal to make more quantitative mobility requirements that focused on the individual components of mobility to enable future suit designers to build and test systems more effectively. This paper details the test planning and selection process for the Constellation space suit pressure garment range of motion requirements.

Aitchison, Lindsway↗

NASA NTRS2009

Conversion from Tree to Graph Representation of Requirements

A procedure and software to implement the procedure have been devised to enable conversion from a tree representation to a graph representation of the requirements governing the development and design of an engineering system. The need for this procedure and software and for other requirements-management tools arises as follows: In systems-engineering circles, it is well known that requirements- management capability improves the likelihood of success in the team-based development of complex systems involving multiple technological disciplines. It is especially desirable to be able to visualize (in order to identify and manage) requirements early in the system- design process, when errors can be corrected most easily and inexpensively.

Mayank, Vimal↗

NASA NTRS2009

Review of FEWS NET Biophysical Monitoring Requirements

The Famine Early Warning System Network (FEWS NET) provides monitoring and early warning support to decision makers responsible for responding to famine and food insecurity. FEWS NET transforms satellite remote sensing data into rainfall and vegetation information that can be used by these decision makers. The National Aeronautics and Space Administration has recently funded activities to enhance remote sensing inputs to FEWS NET. To elicit Earth observation requirements, a professional review questionnaire was disseminated to FEWS NET expert end-users: it focused upon operational requirements to determine additional useful remote sensing data and; subsequently, beneficial FEWS NET biophysical supplementary inputs. The review was completed by over 40 experts from around the world, enabling a robust set of professional perspectives to be gathered and analyzed rapidly. Reviewers were asked to evaluate the relative importance of environmental variables and spatio-temporal requirements for Earth science data products, in particular for rainfall and vegetation products. The results showed that spatio-temporal resolution requirements are complex and need to vary according to place, time, and hazard: that high resolution remote sensing products continue to be in demand, and that rainfall and vegetation products were valued as data that provide actionable food security information.

Ross, K. W.↗

NASA NTRS2009

Thermal Considerations for Meeting 20 C and Stringent Temperature Gradient Requirements of IXO SXT Mirror Modules

The Soft X-Ray Telescope (SXT) is an instrument on the International X-Ray Observatory (IXO). Its flight mirror assembly (FMA) has a single mirror configuration that includes a 3.3 m diameter and 0.93 m tall mirror assembly. It consists of 24 outer modules, 24 middle modules and 12 inner modules. Each module includes more than 200 mirror segments. There are a total of nearly 14,000 mirror segments. The operating temperature requirement of the SXT FMA is 20 C. The spatial temperature gradient requirement between the FMA modules is 1 C or smaller. The spatial temperature gradient requirement within a module is 0.5 C. This paper presents thermal design considerations to meet these stringent thermal requirements.

Choi, Michael K.↗

NASA NTRS2009

Survey and Method for Determination of Trajectory Predictor Requirements

A survey of air-traffic-management researchers, representing a broad range of automation applications, was conducted to document trajectory-predictor requirements for future decision-support systems. Results indicated that the researchers were unable to articulate a basic set of trajectory-prediction requirements for their automation concepts. Survey responses showed the need to establish a process to help developers determine the trajectory-predictor-performance requirements for their concepts. Two methods for determining trajectory-predictor requirements are introduced. A fast-time simulation method is discussed that captures the sensitivity of a concept to the performance of its trajectory-prediction capability. A characterization method is proposed to provide quicker, yet less precise results, based on analysis and simulation to characterize the trajectory-prediction errors associated with key modeling options for a specific concept. Concept developers can then identify the relative sizes of errors associated with key modeling options, and qualitatively determine which options lead to significant errors. The characterization method is demonstrated for a case study involving future airport surface traffic management automation. Of the top four sources of error, results indicated that the error associated with accelerations to and from turn speeds was unacceptable, the error associated with the turn path model was acceptable, and the error associated with taxi-speed estimation was of concern and needed a higher fidelity concept simulation to obtain a more precise result

Rentas, Tamika L.↗

NASA NTRS2010

Assessing Requirements Volatility and Risk Using Bayesian Networks

There are many factors that affect the level of requirements volatility a system experiences over its lifecycle and the risk that volatility imparts. Improper requirements generation, undocumented user expectations, conflicting design decisions, and anticipated / unanticipated world states are representative of these volatility factors. Combined, these volatility factors can increase programmatic risk and adversely affect successful system development. This paper proposes that a Bayesian Network can be used to support reasonable judgments concerning the most likely sources and types of requirements volatility a developing system will experience prior to starting development and by doing so it is possible to predict the level of requirements volatility the system will experience over its lifecycle. This assessment offers valuable insight to the system's developers, particularly by providing a starting point for risk mitigation planning and execution.

Russell, Michael S.↗

NASA NTRS2010

Project Interface Requirements Process Including Shuttle Lessons Learned

Most failures occur at interfaces between organizations and hardware. Processing interface requirements at the start of a project life cycle will reduce the likelihood of costly interface changes/failures later. This can be done by adding Interface Control Documents (ICDs) to the Project top level drawing tree, providing technical direction to the Projects for interface requirements, and by funding the interface requirements function directly from the Project Manager's office. The interface requirements function within the Project Systems Engineering and Integration (SE&I) Office would work in-line with the project element design engineers early in the life cycle to enhance communications and negotiate technical issues between the elements. This function would work as the technical arm of the Project Manager to help ensure that the Project cost, schedule, and risk objectives can be met during the Life Cycle. Some ICD Lessons Learned during the Space Shuttle Program (SSP) Life Cycle will include the use of hardware interface photos in the ICD, progressive life cycle design certification by analysis, test, & operations experience, assigning interface design engineers to Element Interface (EI) and Project technical panels, and linking interface design drawings with project build drawings

Bauch, Garland T.↗