Engineering Papers⌕ Search

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.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 289 records · Page 16

Space Flight Requirements for Fiber Optic Components; Qualification Testing and Lessons Learned

"Qualification" of fiber optic components holds a very different meaning than it did ten years ago. In the past, qualification meant extensive prolonged testing and screening that led to a programmatic method of reliability assurance. For space flight programs today, the combination of using higher performance commercial technology, with shorter development schedules and tighter mission budgets makes long term testing and reliability characterization unfeasible. In many cases space flight missions will be using technology within years of its development and an example of this is fiber laser technology. Although the technology itself is not a new product the components that comprise a fiber laser system change frequently as processes and packaging changes occur. Once a process or the materials for manufacturing a component change, even the data that existed on its predecessor can no longer provide assurance on the newer version. In order to assure reliability during a space flight mission, the component engineer must understand the requirements of the space flight environment as well as the physics of failure of the components themselves. This can be incorporated into an efficient and effective testing plan that "qualifies" a component to specific criteria defined by the program given the mission requirements and the component limitations. This requires interaction at the very initial stages of design between the system design engineer, mechanical engineer, subsystem engineer and the component hardware engineer. Although this is the desired interaction what typically occurs is that the subsystem engineer asks the components or development engineers to meet difficult requirements without knowledge of the current industry situation or the lack of qualification data. This is then passed on to the vendor who can provide little help with such a harsh set of requirements due to high cost of testing for space flight environments. This presentation is designed to guide the engineers of design, development and components, and vendors of commercial components with how to make an efficient and effective qualification test plan with some basic generic information about many space flight requirements. Issues related to the ~ physics of failure, acceptance criteria and lessons learned will also be discussed to assist with understanding how to approach a space flight mission in an ever changing commercial photonics industry.

Ott, Melanie N.↗

Functional Mobility Testing: A Novel Method to Create Suit Design Requirements

This study was performed to aide in the creation of design requirements for the next generation of space suits that more accurately describe the level of mobility necessary for a suited crewmember through the use of an innovative methodology utilizing functional mobility. A novel method was utilized involving the collection of kinematic data while 20 subjects (10 male, 10 female) performed pertinent functional tasks that will be required of a suited crewmember during various phases of a lunar mission. These tasks were selected based on relevance and criticality from a larger list of tasks that may be carried out by the crew. Kinematic data was processed through Vicon BodyBuilder software to calculate joint angles for the ankle, knee, hip, torso, shoulder, elbow, and wrist. Maximum functional mobility was consistently lower than maximum isolated mobility. This study suggests that conventional methods for establishing design requirements for human-systems interfaces based on maximal isolated joint capabilities may overestimate the required mobility. Additionally, this method provides a valuable means of evaluating systems created from these requirements by comparing the mobility available in a new spacesuit, or the mobility required to use a new piece of hardware, to this newly established database of functional mobility.

England, Scott A.↗

The New NASA Orbital Debris Mitigation Procedural Requirements and Standards

NASA has issued major updates to its principal orbital debris mitigation policy directive and standards. The new NASA Procedural Requirements for Limiting Orbital Debris (NPR 8715.6), with its supporting NASA Standard 8719.14, both refine earlier orbital debris mitigation documents and in some areas expand their applicability. Organizational and individual responsibilities along with general directives are set forth in NPR 8715.6. New requirements include routine conjunction assessments for all maneuverable NASA spacecraft in LEO and GEO, prompt notifications of intended or unintended debris generation, preparation and maintenance of formal end-of-mission plans, and disposal of vehicles in operation around the Moon and Mars and at the Earth-Sun Lagrangian points. NASA Standard 8719.14 replaces the 1995 NASA Safety Standard 1740.14 with no major new requirements but with several refinements and additions, some of which had already been adopted. Compliance with human casualty risk limitations from reentering debris will be calculated explicitly and not be expressed in terms of average debris casualty area. Moreover, the minimum kinetic energy threshold for potentially injurious reentering debris is set at 15 Joules. The overarching requirement for the disposal of GEO spacecraft and launch vehicle orbital stages is to ensure that the vehicles do not come within GEO + 200 km for at least 100 km after end of mission, rather than setting specific requirements for the disposal orbit. Spacecraft operating in or routinely transiting LEO must remain in the region for no more than 25 years after end of mission or 30 years after launch, whichever occurs sooner. A comprehensive new NASA handbook on orbital debris has also been prepared to provide background on the orbital debris environment and the related NASA mitigation requirements and standards.

Johnson, Nicholas L.↗

Human Rating Requirements for NASA's Constellation Program

NASA s Constellation Program (CxP) will conduct a series of human space expeditions of increasing scope, starting with missions supporting the International Space Station and expanding to encompass the Moon and Mars. Although human-rating is an integral part of all CxP activities throughout their life cycle, NASA Procedural Requirements document NPR 8705.2B, Human-Rating Requirements (HRR) for Space Flight Systems, defines the additional processes, procedures, and requirements necessary to produce human-rated space systems that protect the safety of crew members and passengers on these NASA missions. In order to be in compliance with 8705.2B the CxP must show appropriate implementation or progression toward the HRR, or justification for an exception. Compliance includes an explanation of how the CxP intends to meet the HRR, analyses to be performed to determine implementation; and a matrix to trace the HRR to CxP requirements. The HRR requires the CxP to establish a human system integration team (HSIT), consisting of astronauts, mission operations personnel, training personnel, ground processing personnel, human factors personnel, and human engineering experts, with clearly defined authority, responsibility, and accountability to lead the human-system integration. For example, per the HRR the HSIT is involved in the evaluation of crew workload, human-in-the-loop usability evaluations, determining associated criteria, and in assessment of how these activities influenced system design. In essence, the HSIT is invaluable in CxP s ability to meet the three fundamental tenets of human rating: the process of designing, evaluating, and assuring that the total system can safely conduct the required human missions; the incorporation of design features and capabilities that accommodate human interaction with the system to enhance overall safety and mission success; and the incorporation of design features and capabilities to enable safe recovery of the crew from hazardous situations.

Berdich, Debbie↗

The First Development of Human Factors Engineering Requirements for Application to Ground Task Design for a NASA Flight Program

The National Aeronautics and Space Administration has long applied standards-derived human engineering requirements to the development of hardware and software for use by astronauts while in flight. The most important source of these requirements has been NASA-STD-3000. While there have been several ground systems human engineering requirements documents, none has been applicable to the flight system as handled at NASA's launch facility at Kennedy Space Center. At the time of the development of previous human launch systems, there were other considerations that were deemed more important than developing worksites for ground crews; e.g., hardware development schedule and vehicle performance. However, experience with these systems has shown that failure to design for ground tasks has resulted in launch schedule delays, ground operations that are more costly than they might be, and threats to flight safety. As the Agency begins the development of new systems to return humans to the moon, the new Constellation Program is addressing this issue with a new set of human engineering requirements. Among these requirements is a subset that will apply to the design of the flight components and that is intended to assure ground crew success in vehicle assembly and maintenance tasks. These requirements address worksite design for usability and for ground crew safety.

Dischinger, H. Charles, Jr.↗

Human Research Program Requirements Document (Revision C)

The purpose of this document is to define, document, and allocate the Human Research Program (HRP) requirements to the HRP Program Elements. It establishes the flow-down of requirements from Exploration Systems Mission Directorate (ESMD) and Office of the Chief Health and Medical Officer (OCHMO) to the various Program Elements of the HRP to ensure that human research and technology countermeasure investments are made to insure the delivery of countermeasures and technologies that satisfy ESMD's and OCHMO's exploration mission requirements. Requirements driving the HRP work and deliverables are derived from the exploration architecture, as well as Agency standards regarding the maintenance of human health and performance. Agency human health and performance standards will define acceptable risk for each type and duration of exploration mission. It is critical to have the best available scientific and clinical evidence in setting and validating these standards. In addition, it is imperative that the best available evidence on preventing and mitigating human health and performance risks is incorporated into exploration mission and vehicle designs. These elements form the basis of the HRP research and technology development requirements and highlight the importance of HRP investments in enabling NASA's exploration missions. This PRD defines the requirements of the HRP which is comprised of the following major Program Elements: Behavioral Health and Performance (BHP), Exploration Medical Capability (ExMC), Human Health Countermeasures (HHC), ISS Medical Project (ISSMP), Space Human Factors and Habitability (SHFH), and Space Radiation (SR).

Vargas, Paul R.↗

Trading Robustness Requirements in Mars Entry Trajectory Design

One of the most important metrics characterizing an atmospheric entry trajectory in preliminary design is the size of its predicted landing ellipse. Often, requirements for this ellipse are set early in design and significantly influence both the expected scientific return from a particular mission and the cost of development. Requirements typically specify a certain probability level (6-level) for the prescribed ellipse, and frequently this latter requirement is taken at 36. However, searches for the justification of 36 as a robustness requirement suggest it is an empirical rule of thumb borrowed from non-aerospace fields. This paper presents an investigation into the sensitivity of trajectory performance to varying robustness (6-level) requirements. The treatment of robustness as a distinct objective is discussed, and an analysis framework is presented involving the manipulation of design variables to effect trades between performance and robustness objectives. The scenario for which this method is illustrated is the ballistic entry of an MSL-class Mars entry vehicle. Here, the design variable is entry flight path angle, and objectives are parachute deploy altitude performance and error ellipse robustness. Resulting plots show the sensitivities between these objectives and trends in the entry flight path angles required to design to these objectives. Relevance to the trajectory designer is discussed, as are potential steps for further development and use of this type of analysis.

Lafleur, Jarret M.↗

Engine Gimbal Requirements for Ground Testing of J-2X

Based on the Apollo-era J-2 that powered the second and third stages of the Saturn V, the current J-2X is the liquid hydrogen and oxygen high-altitude rocket engine in development for both the Ares I Upper Stage and Ares V Earth Departure Stage. During my summer 2009 internship, J-2X was at a stage in its design maturity where verification testing needed to be considered for the benefit of adequate test facility preparation. My task was to focus on gimbal requirements and gimbal related hot-fire test plans. Facility capabilities were also of interest, specifically for hot-fire testing slated to occur at test stands A-1, A-2, and A-3 at Stennis Space Center(SSC) in Bay St. Louis, Mississippi. Gimbal requirements and stage interface conditions were investigated by applying a top-to-bottom systems engineering approach, which involved system level requirements, engine level requirements from both government and engine contractor perspectives, component level requirements, and the J-2X to Upper Stage and Earth Departure Stage interface control documents. Previous hydrogen and oxygen liquid rocket engine gimbal verification methods were researched for a glimpse at lessons learned. Discussion among the J-2X community affected by gimballing was organized to obtain input relative to proper verification of their respective component. Implementing suggestions such as gimbal pattern, angulated dwell time, altitude testing options, power level, and feed line orientation, I was able to match tests to test stands in the A Complex at SSC. Potential test capability gaps and risks were identified and pursued. The culmination of all these efforts was to coordinate with SSC to define additional facility requirements for both the A-3 altitude test stand that is currently under construction and the A-1 sea level test stand which is being renovated

Kovalcik, Julia↗

From Goal-Oriented Requirements to Event-B Specifications

In goal-oriented requirements engineering methodologies, goals are structured into refinement trees from high-level system-wide goals down to fine-grained requirements assigned to specific software/ hardware/human agents that can realise them. Functional goals assigned to software agents need to be operationalised into specification of services that the agent should provide to realise those requirements. In this paper, we propose an approach for operationalising requirements into specifications expressed in the Event-B formalism. Our approach has the benefit of aiding software designers by bridging the gap between declarative requirements and operational system specifications in a rigorous manner, enabling powerful correctness proofs and allowing further refinements down to the implementation level. Our solution is based on verifying that a consistent Event-B machine exhibits properties corresponding to requirements.

Aziz, Benjamin↗

Exploration Planetary Surface Structural Systems: Design Requirements and Compliance

The Lunar Surface Systems Project developed system concepts that would be necessary to establish and maintain a permanent human presence on the Lunar surface. A variety of specific system implementations were generated as a part of the scenarios, some level of system definition was completed, and masses estimated for each system. Because the architecture studies generally spawned a large number of system concepts and the studies were executed in a short amount of time, the resulting system definitions had very low design fidelity. This paper describes the development sequence required to field a particular structural system: 1) Define Requirements, 2) Develop the Design and 3) Demonstrate Compliance of the Design to all Requirements. This paper also outlines and describes in detail the information and data that are required to establish structural design requirements and outlines the information that would comprise a planetary surface system Structures Requirements document.

Dorsey, John T.↗

The Development and Implementation of Ground Safety Requirements for Project Orion Abort Flight Testing - A Case Study

A rigorous set of detailed ground safety requirements is required to make sure that ground support equipment (GSE) and associated planned ground operations are conducted safely. Detailed ground safety requirements supplement the GSE requirements already called out in NASA-STD-5005. This paper will describe the initial genesis of these ground safety requirements, the establishment and approval process and finally the implementation process for Project Orion. The future of the requirements will also be described. Problems and issues encountered and overcame will be discussed.

Kirkpatrick, Paul D.↗

Vehicle Health Management Communications Requirements for AeroMACS

As the development of standards for the aeronautical mobile airport communications system (AeroMACS) progresses, the process of identifying and quantifying appropriate uses for the system is progressing. In addition to defining important elements of AeroMACS standards, indentifying the systems uses impacts AeroMACS bandwidth requirements. Although an initial 59 MHz spectrum allocation for AeroMACS was established in 2007, the allocation may be inadequate; studies have indicated that 100 MHz or more of spectrum may be required to support airport surface communications. Hence additional spectrum allocations have been proposed. Vehicle health management (VHM) systems, which can produce large volumes of vehicle health data, were not considered in the original bandwidth requirements analyses, and are therefore of interest in supporting proposals for additional AeroMACS spectrum. VHM systems are an emerging development in air vehicle safety, and preliminary estimates of the amount of data that will be produced and transmitted off an aircraft, both in flight and on the ground, have been prepared based on estimates of data produced by on-board vehicle health sensors and initial concepts of data processing approaches. This allowed an initial estimate of VHM data transmission requirements for the airport surface. More recently, vehicle-level systems designed to process and analyze VHM data and draw conclusions on the current state of vehicle health have been undergoing testing and evaluation. These systems make use of vehicle system data that is mostly different from VHM data considered previously for airport surface transmission, and produce processed system outputs that will be also need to be archived, thus generating additional data load for AeroMACS. This paper provides an analysis of airport surface data transmission requirements resulting from the vehicle level reasoning systems, within the context of overall VHM data requirements.

Kerczewski, Robert J.↗

Control Requirements to Support Manual Piloting Capability

The manual piloting requirements specified under the NASA Constellation Program involved Cooper-Harper ratings, which are a qualitative and subjective evaluation from experienced pilots. This type of verification entails a significant investment of resources to assess a completed design and is not one that can easily or meaningfully be applied upfront in the design phase. The evolution of the Multi-Purpose Crew Vehicle Program to include an independently developed propulsion system from an international partner makes application of Cooper-Harper based design requirements inadequate. To mitigate this issue, a novel solution was developed to reformulate the necessary piloting capability into quantifiable requirements. A trio of requirements was designed which specify control authority, precision, and impulse residuals enabling propulsion design within specified guidance and control boundaries. These requirements have been evaluated against both the existing Orion design and the proposed ESA design and have been found to achieve the desired specificity. The requirement set is capable of being applied to the development of other spacecraft in support of manual piloting.

Merancy, Nujoud↗

Traceability of Software Safety Requirements in Legacy Safety Critical Systems

How can traceability of software safety requirements be created for legacy safety critical systems? Requirements in safety standards are imposed most times during contract negotiations. On the other hand, there are instances where safety standards are levied on legacy safety critical systems, some of which may be considered for reuse for new applications. Safety standards often specify that software development documentation include process-oriented and technical safety requirements, and also require that system and software safety analyses are performed supporting technical safety requirements implementation. So what can be done if the requisite documents for establishing and maintaining safety requirements traceability are not available?

Hill, Janice L.↗

Requirements Flowdown for Prognostics and Health Management

Prognostics and Health Management (PHM) principles have considerable promise to change the game of lifecycle cost of engineering systems at high safety levels by providing a reliable estimate of future system states. This estimate is a key for planning and decision making in an operational setting. While technology solutions have made considerable advances, the tie-in into the systems engineering process is lagging behind, which delays fielding of PHM-enabled systems. The derivation of specifications from high level requirements for algorithm performance to ensure quality predictions is not well developed. From an engineering perspective some key parameters driving the requirements for prognostics performance include: (1) maximum allowable Probability of Failure (PoF) of the prognostic system to bound the risk of losing an asset, (2) tolerable limits on proactive maintenance to minimize missed opportunity of asset usage, (3) lead time to specify the amount of advanced warning needed for actionable decisions, and (4) required confidence to specify when prognosis is sufficiently good to be used. This paper takes a systems engineering view towards the requirements specification process and presents a method for the flowdown process. A case study based on an electric Unmanned Aerial Vehicle (e-UAV) scenario demonstrates how top level requirements for performance, cost, and safety flow down to the health management level and specify quantitative requirements for prognostic algorithm performance.

video acuity↗

A Scenario-Based Process for Requirements Development: Application to Mission Operations Systems

The notion of using operational scenarios as part of requirements development during mission formulation (Phases A & B) is widely accepted as good system engineering practice. In the context of developing a Mission Operations System (MOS), there are numerous practical challenges to translating that notion into the cost-effective development of a useful set of requirements. These challenges can include such issues as a lack of Project-level focus on operations issues, insufficient or improper flowdown of requirements, flowdown of immature or poor-quality requirements from Project level, and MOS resource constraints (personnel expertise and/or dollars). System engineering theory must be translated into a practice that provides enough structure and standards to serve as guidance, but that retains sufficient flexibility to be tailored to the needs and constraints of a particular MOS or Project. We describe a detailed, scenario-based process for requirements development. Identifying a set of attributes for high quality requirements, we show how the portions of the process address many of those attributes. We also find that the basic process steps are robust, and can be effective even in challenging Project environments.

MOS↗

Z-2 Architecture Description and Requirements Verification Results

The Z-2 Prototype Planetary Extravehicular Space Suit Assembly is a continuation of NASA's Z series of spacesuits. The Z-2 is another step in NASA's technology development roadmap leading to human exploration of the Martian surface. The suit was designed for maximum mobility at 8.3 psid, reduced mass, and to have high fidelity life support interfaces. As Z-2 will be man-tested at full vacuum in NASA JSC's Chamber B, it was manufactured as Class II, making it the most flight-like planetary walking suit produced to date. The Z-2 suit architecture is an evolution of previous EVA suits, namely the ISS EMU, Mark III, Rear Entry I-Suit and Z-1 spacesuits. The suit is a hybrid hard and soft multi-bearing, rear entry spacesuit. The hard upper torso (HUT) is an all-composite structure and includes a 2-bearing rolling convolute shoulder with Vernier sizing mechanism, removable suit port interface plate (SIP), elliptical hemispherical helmet and self-don/doff shoulder harness. The hatch is a hybrid aluminum and composite construction with Apollo style gas connectors, custom water pass-thru, removable hatch cage and interfaces to primary and auxiliary life support feed water bags. The suit includes Z-1 style lower arms with cam brackets for Vernier sizing and government furnished equipment (GFE) Phase VI gloves. The lower torso includes a telescopic waist sizing system, waist bearing, rolling convolute waist joint, hard brief, 2 bearing soft hip thigh, Z-1 style legs with ISS EMU style cam brackets for sizing, and conformal walking boots with ankle bearings. The Z-2 Requirements Verification Plan includes the verification of more than 200 individual requirements. The verification methods include test, analysis, inspection, demonstration or a combination of methods. Examples of unmanned requirements include suit leakage, proof pressure testing, operational life, mass, isometric man-loads, sizing adjustment ranges, internal and external interfaces such as in-suit drink bag, partial pressure relief valve, purge valve, donning stand and ISS Body Restraint Tether (BRT). Examples of manned requirements include verification of anthropometric range, suit self-don/doff, secondary suit exit method, donning stand self-ingress/egress and manned mobility covering eight functional tasks. The eight functional tasks include kneeling with object pick-up, standing toe touch, cross-body reach, walking, reach to the SIP and helmet visor. This paper will provide an overview of the Z-2 design. Z-2 requirements verification testing was performed with NASA at the ILC Houston test facility. This paper will also discuss pre-delivery manned and unmanned test results as well as analysis performed in support of requirements verification.

Graziosi, Dave↗

Application of Strength Requirements to Complex Loading Scenarios

NASA's endeavors in human spaceflight rely on extensive volumes of human-systems integration requirements to ensure mission success. These requirements protect for space hardware accommodation for the full range of potential crewmembers, but cannot cover every possible action and contingency in detail. This study was undertaken in response to questions from various strength requirement users who were unclear how to apply idealized strength requirements that did not map well to the complex loading scenarios that crewmembers would encounter. Three of the most commonly occurring questions from stakeholders were selected to be investigated with human testing and human modeling. Preliminary findings indicate deviation from nominal postures can affect strength requirement compliance positively or negatively, depending on the nature of the deviation. Human modeling offers some avenues for quickly addressing requirement verification questions, but is limited by the fidelity of the model and environment.

England, Scott↗