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 217 records · Page 12
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Structural Requirements for the Space Propulsion Engine Systems

In January 2004, the National Aeronautics and Space Administration (NASA) was given a vision for Space Exploration by President Bush, setting our sight on a bold new path to go back to the Moon, then to Mars and beyond. As NASA gets ready to meet the vision set by President Bush, failures are not an option. Reliability of the propulsion engine systems will play an important role in establishing an overall safe and reliable operation of these new space systems. A new standard, NASA-STD-5012, Strength and Life Assessment for Space Propulsion System Engines, has been developed to provide structural requirements for assessment of the propulsion systems engine. This standard is a complement to the current NASA-wide standard NASA-STD-5001, Structural Design and Test Factors of Safety for Spaceflight Hardware, which excluded the requirement for the engine systems (rotatory structures) along with pressure vessels. As developed, this document builds on the heritage of the multiple industrial standards related to strength and life assessment of the structures. For assuring a safe and reliable operation of a product and/or mission, establishing a set of structural assessment requirements is a key ingredient. Hence, a concentrated effort was made to improve the requirements where there are known lessons learned during the design, test, and operation phases of the Space Shuttle Main Engine (SSME) and other engine development programs. Requirements delineated in this standard are also applicable for the reusable and/or human missions. It shall be noted that "reliability of a system cannot be tested and inspected but can only be achieved if it is first designed into a system." Hence, these strength and life assessment requirements for the space propulsion system engines shall be used along with other good engineering practices, requirements, and policies.

Aggarwal, Pravin K.↗
NASA NTRS2006

Automated Derivation of Complex System Constraints from User Requirements

International Space Station (ISS) payload developers submit their payload science requirements for the development of on-board execution timelines. The ISS systems required to execute the payload science operations must be represented as constraints for the execution timeline. Payload developers use a software application, User Requirements Collection (URC), to submit their requirements by selecting a simplified representation of ISS system constraints. To fully represent the complex ISS systems, the constraints require a level of detail that is beyond the insight of the payload developer. To provide the complex representation of the ISS system constraints, HOSC operations personnel, specifically the Payload Activity Requirements Coordinators (PARC), manually translate the payload developers simplified constraints into detailed ISS system constraints used for scheduling the payload activities in the Consolidated Planning System (CPS). This paper describes the implementation for a software application, User Requirements Integration (URI), developed to automate the manual ISS constraint translation process.

Muery, Kim↗
NASA NTRS2008

Determining Exercise Strength Requirements for Astronaut Critical Mission Tasks: Reaching Under G-Load

The critical mission tasks assessments effort seeks to determine the physical performance requirements that astronauts must meet in order to safely and successfully accomplish lunar exploration missions. These assessments will determine astronaut preflight strength, fitness, and flexibility requirements, and the extent to which exercise and other countermeasures must prevent the physical deconditioning associated with prolonged weightlessness. The purpose is to determine the flexibility and strength that crewmembers must possess in order to reach Crew Exploration Vehicle controls during maneuvers that result in sustained acceleration levels ranging from 3.7G to 7.8G. An industry standard multibody dynamics application was used to create human models representing a 5th percentile female, a 50th percentile male, and a 95th percentile male. The additional mass of a space suit sleeve was added to the reaching arm to account for the influence of the suit mass on the reaching effort. The human model was merged with computer models of a pilot seat and control panel for the Crew Exploration Vehicle. Three dimensional paths were created that guided the human models hand from a starting position alongside its thigh to three control targets: a joystick, a keyboard, and an overhead switch panel. The reaching motion to each target was repeated under four vehicle acceleration conditions: nominal ascent (3.7G), two ascent aborts (5.5G and 7.8G) and lunar reentry (4.6G). Elbow and shoulder joint angular excursions were analyzed to assess range of motion requirements. Mean and peak elbow and shoulder joint torques were determined and converted to equivalent resistive exercise loads to assess strength requirements. Angular excursions for the 50th and 95th percentile male models remained within joint range of motion limits. For the 5th percentile female, both the elbow and the shoulder exceeded range of motion limits during the overhead reach. Elbow joint torques ranged from 10 N-m (nominal ascent) to 60 N-m (ascent abort). Shoulder joint torques ranged from 65 N-m (nominal ascent) to 280 N-m (ascent abort). Maximal equivalent exercise loads reached 30 lb in tricep extension, 9 lb in bicep curl, 110 lb in unilateral pullover and unilateral bench press for nominal conditions (lunar reentry), and 188 lb in unilateral pullover and unilateral bench press. The location of the pilot seat was found to be inadequately located to allow a 5th percentile female to reach the switches on the overhead panel. Elbow strength requirements were found to be well within population norms. Shoulder strength was found to be a limiting factor. Reaching under nominal ascent and lunar reentry conditions was found to require near maximal shoulder strength. Reaching under ascent abort conditions requires shoulder strength well beyond population norms. Pilot seats must adjust to accomodate a 5th percentile female. Exercise countermeasures must maintain maximal pullover and bench press strength to allow pilots to reach and operate controls during lunar reentry. Reaching will not be possible during ascent abort conditions. Flight controls should be built into armrests or flight control must be accomplished by autonomous systems during acceleration exceeding 4.6G.

Schaffner, Grant↗
NASA NTRS2005

Step 1: Human System Integration Pilot-Technology Interface Requirements for Weather Management

This document involves definition of technology interface requirements for Hazardous Weather Avoidance. Technology concepts in use by the Access 5 Weather Management Work Package were considered. Beginning with the Human System Integration (HIS) high-level functional requirement for Hazardous Weather Avoidance, and Hazardous Weather Avoidance 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 hazardous weather, and (2) the control capability needed by the pilot to obtain hazardous weather information. Fundamentally, these requirements provide the candidate Hazardous Weather Avoidance technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Hazardous Weather Avoidance operations and functions should interface with the pilot to provide the necessary Weather Management functionality to the UA-pilot system. Requirements and guidelines for Hazardous Weather Avoidance are partitioned into four categories: (1) Planning En Route (2) Encountering Hazardous Weather En Route, (3) Planning to Destination, and (4) Diversion Planning Alternate Airport. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗
NASA NTRS2009

Review of the Constellation Level II Safety, Reliability, and Quality Assurance (SR&QA) Requirements Documents during Participation in the Constellation Level II SR&QA Forum

At the request of the Exploration Systems Mission Directorate (ESMD) and the Constellation Program (CxP) Safety, Reliability; and Quality Assurance (SR&QA) Requirements Director, the NASA Engineering and Safety Center (NESC) participated in the Cx SR&QA Requirements forum. The Requirements Forum was held June 24-26; 2008, at GRC's Plum Brook Facility. The forums purpose was to gather all stakeholders into a focused meeting to help complete the process of refining the CxP to refine its Level II SR&QA requirements or defining project-specific requirements tailoring. Element prime contractors had raised specific questions about the wording and intent of many requirements in areas they felt were driving costs without adding commensurate value. NESC was asked to provide an independent and thorough review of requirements that contractors believed were driving Program costs, by active participation in the forum. This document contains information from the forum.

Cameron, Kenneth D.↗
NASA NTRS2009

Altair Lander Life Support: Requirement Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA s Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally-functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair s life support system.

Anderson, Molly↗
NASA NTRS2010

Altair Lander Life Support: Requirements Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA's Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally -functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper'. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair's life support system.

Anderson, Molly↗
NASA NTRS2010

L-Band Digital Aeronautical Communications System Engineering - Concepts of Use, Systems Performance, Requirements, and Architectures

This NASA Contractor Report summarizes and documents the work performed to develop concepts of use (ConUse) and high-level system requirements and architecture for the proposed L-band (960 to 1164 MHz) terrestrial en route communications system. This work was completed as a follow-on to the technology assessment conducted by NASA Glenn Research Center and ITT for the Future Communications Study (FCS). ITT assessed air-to-ground (A/G) communications concepts of use and operations presented in relevant NAS-level, international, and NAS-system-level documents to derive the appropriate ConUse relevant to potential A/G communications applications and services for domestic continental airspace. ITT also leveraged prior concepts of use developed during the earlier phases of the FCS. A middle-out functional architecture was adopted by merging the functional system requirements identified in the bottom-up assessment of existing requirements with those derived as a result of the top-down analysis of ConUse and higher level functional requirements. Initial end-to-end system performance requirements were derived to define system capabilities based on the functional requirements and on NAS-SR-1000 and the Operational Performance Assessment conducted as part of the COCR. A high-level notional architecture of the L-DACS supporting A/G communication was derived from the functional architecture and requirements.

Zelkin, Natalie↗
NASA NTRS2011

Structural Design Requirements and Factors of Safety for Spaceflight Hardware: For Human Spaceflight

This document establishes the structural requirements for human-rated spaceflight hardware including launch vehicles, spacecraft and payloads. These requirements are applicable to Government Furnished Equipment activities as well as all related contractor, subcontractor and commercial efforts. These requirements are not imposed on systems other than human-rated spacecraft, such as ground test articles, but may be tailored for use in specific cases where it is prudent to do so such as for personnel safety or when assets are at risk. The requirements in this document are focused on design rather than verification. Implementation of the requirements is expected to be described in a Structural Verification Plan (SVP), which should describe the verification of each structural item for the applicable requirements. The SVP may also document unique verifications that meet or exceed these requirements with NASA Technical Authority approval.

Bernstein, Karen S.↗
NASA NTRS2013

Flight Hardware Packaging Design for Stringent EMC Radiated Emission Requirements

This packaging design approach can help heritage hardware meet a flight project's stringent EMC radiated emissions requirement. The approach requires only minor modifications to a hardware's chassis and mainly concentrates on its connector interfaces. The solution is to raise the surface area where the connector is mounted by a few millimeters using a pedestal, and then wrapping with conductive tape from the cable backshell down to the surface-mounted connector. This design approach has been applied to JPL flight project subsystems. The EMC radiated emissions requirements for flight projects can vary from benign to mission critical. If the project's EMC requirements are stringent, the best approach to meet EMC requirements would be to design an EMC control program for the project early on and implement EMC design techniques starting with the circuit board layout. This is the ideal scenario for hardware that is built from scratch. Implementation of EMC radiated emissions mitigation techniques can mature as the design progresses, with minimal impact to the design cycle. The real challenge exists for hardware that is planned to be flown following a built-to-print approach, in which heritage hardware from a past project with a different set of requirements is expected to perform satisfactorily for a new project. With acceptance of heritage, the design would already be established (circuit board layout and components have already been pre-determined), and hence any radiated emissions mitigation techniques would only be applicable at the packaging level. The key is to take a heritage design with its known radiated emissions spectrum and repackage, or modify its chassis design so that it would have a better chance of meeting the new project s radiated emissions requirements.

Lortz, Charlene L.↗
NASA NTRS2014

Exploration of the Trade Space Between Unmanned Aircraft Systems Descent Maneuver Performance and Sense-and-Avoid System Performance Requirements

A need exists to safely integrate Unmanned Aircraft Systems (UAS) into the United States' National Airspace System. Replacing manned aircraft's see-and-avoid capability in the absence of an onboard pilot is one of the key challenges associated with safe integration. Sense-and-avoid (SAA) systems will have to achieve yet-to-be-determined required separation distances for a wide range of encounters. They will also need to account for the maneuver performance of the UAS they are paired with. The work described in this paper is aimed at developing an understanding of the trade space between UAS maneuver performance and SAA system performance requirements, focusing on a descent avoidance maneuver. An assessment of current manned and unmanned aircraft performance was used to establish potential UAS performance test matrix bounds. Then, near-term UAS integration work was used to narrow down the scope. A simulator was developed with sufficient fidelity to assess SAA system performance requirements. The simulator generates closest-point-of-approach (CPA) data from the wide range of UAS performance models maneuvering against a single intruder with various encounter geometries. Initial attempts to model the results made it clear that developing maneuver performance groups is required. Discussion of the performance groups developed and how to know in which group an aircraft belongs for a given flight condition and encounter is included. The groups are airplane, flight condition, and encounter specific, rather than airplane-only specific. Results and methodology for developing UAS maneuver performance requirements are presented for a descent avoidance maneuver. Results for the descent maneuver indicate that a minimum specific excess power magnitude can assure a minimum CPA for a given time-to-go prediction. However, smaller amounts of specific excess power may achieve or exceed the same CPA if the UAS has sufficient speed to trade for altitude. The results of this study will support UAS maneuver performance requirements development for integrating UAS in the NAS. The methods described are being used to help RTCA Special Committee 228 develop requirements.

Jack, Devin P.↗
NASA NTRS2010

Importance of Requirements Analysis & Traceability to Improve Software Quality and Reduce Cost and Risk

The goal of this paper is to emphasize the importance of developing complete and unambiguous requirements early in the project cycle (prior to Preliminary Design Phase). Having a complete set of requirements early in the project cycle allows sufficient time to generate a traceability matrix. Requirements traceability and analysis are the key elements in improving verification and validation process, and thus overall software quality. Traceability can be most beneficial when the system changes. If changes are made to high-level requirements it implies that low-level requirements need to be modified. Traceability ensures that requirements are appropriately and efficiently verified at various levels whereas analysis ensures that a rightly interpreted set of requirements is produced.

Kapoor, Manju M.↗
NASA NTRS2015

A Path to Planetary Protection Requirements for Human Exploration: A Literature Review and Systems Engineering Approach

As systems, technologies, and plans for the human exploration of Mars and other destinations beyond low Earth orbit begin to coalesce, it is imperative that frequent and early consideration is given to how planetary protection practices and policy will be upheld. While the development of formal planetary protection requirements for future human space systems and operations may still be a few years from fruition, guidance to appropriately influence mission and system design will be needed soon to avoid costly design and operational changes. The path to constructing such requirements is a journey that espouses key systems engineering practices of understanding shared goals, objectives and concerns, identifying key stakeholders, and iterating a draft requirement set to gain community consensus. This paper traces through each of these practices, beginning with a literature review of nearly three decades of publications addressing planetary protection concerns with respect to human exploration. Key goals, objectives and concerns, particularly with respect to notional requirements, required studies and research, and technology development needs have been compiled and categorized to provide a current 'state of knowledge'. This information, combined with the identification of key stakeholders in upholding planetary protection concerns for human missions, has yielded a draft requirement set that might feed future iteration among space system designers, exploration scientists, and the mission operations community. Combining the information collected with a proposed forward path will hopefully yield a mutually agreeable set of timely, verifiable, and practical requirements for human space exploration that will uphold international commitment to planetary protection.

Johnson, James E.↗
NASA NTRS2016

Category B Plastic Pane Testing for JSC 66320 Rev A Requirements Verifiable Through Acceptance Testing

JSC 66320, Revision A, Optical Property Requirements for Glasses, Ceramics, and Plastics in Spacecraft Window Systems, lists several quantitative requirements that spacecraft windowpanes must meet. Recently, we were asked to establish a capability at the Kennedy Space Center to perform these measurements on category B plastic panes, i.e., plastic panes that could be used on a spacecraft for long-focal-length photography and piloting. Two of the criteria, normal wavefront and 30-degree wavefront attributes, can be measured with existing equipment and processes (see NASA TM NESC-RP-14-00951, April 2016) and are not discussed in this document. However, the other six criteria-haze, wedge angle, birefringence, reflectance, transmittance, and color balance-required substantial development and are the subject of this document. In this document, we do not discuss the rationale behind the requirements, but we did engage in discussions with the authors of JSC 66320 in order to better understand the requirements and the verifications being imposed on windows and their testing. Accordingly, this document presents our best understanding of the requested requirements and verifications. We also present our methodology for performing each of the six measurements, along with applicable mathematics and a description, with photos, of the hardware used. In addition, we supply the results of a test on a low-quality in-house plastic window as an example of the system operation. Only requirements that can be met by acceptance test and analysis, as opposed to optical inspection, are considered in this document.

spaceflight windows↗
NASA NTRS2019

Formalizing and Analyzing Requirements with FRET

Formal verification and simulation are powerful tools to validate requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. To this end, we have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written structured natural language.

Mavridou, Anastasia↗
NASA NTRSDate not supplied

Medical System Requirements Development for Lunar Operations

The major health hazards of spaceflight include higher levels of damaging radiation, altered gravity, extended periods of isolation and confinement, a closed and potentially hostile living environment, and the stress associated with being a long distance from Earth. As we increase the duration of lunar stays with foreseeable communication latencies and disruptions, there will be a progressive need for crew to maintain their own health and independently respond to critical medical events. The Exploration Medical Capability element of the NASA Human Research Program is developing a set of Medical System requirements for lunar transit and surface operations. These requirements specify the capabilities, processes and procedures of a habitat Medical System needed for a range of conditions known to occur during spaceflight. Requirement text is written so as not to constrain innovative design solutions necessary for a resilient system. The requirement set includes attributes and functions the Medical System imposes on eight additional habitat systems. A key property of the Medical System is the provision of medical knowledge that will be stored, updated, analyzed, and secured within a Habitat Data System. A Task Performance Support System will aid in medical data acquisition and interpretation, crew training, medical condition prevention, diagnosis and treatment, provide interactive procedures, and track medical inventory. A Wellness System will focus on the provision of countermeasures to prevent, mitigate or treat adverse physical and behavioral health effects while the Medical System recommends adjustments to these countermeasures to maintain crew health. An Environmental Monitoring System will share out-of-bounds readings of air and water quality, acoustics, and radiation exposure levels with the Medical System to help identify issues before they affect crew health and performance. A Communications System will provide secured and private consultations between crew and the ground medical team and their loved ones on Earth. The Medical System also imposes requirements on a Research & Testbed System, fostering advanced medical science such as human research. A Waste Management System provides biohazard waste containment and waste disposal options (recycle and reuse). An Extravehicular Activity System supports crew health during lunar surface activities. And finally, a Maintenance Support System ensures that medical equipment is performing as expected. These requirements are being specifically developed for lunar surface operations but could help to identify Medical System requirements for any space habitat (e.g., I-Hab, commercial endeavors, etc.).

technology↗
DOE OSTI2020

Enabling Marine Energy Integration for Ocean Observing: Functional Requirements

Marine renewable energy (i.e., wave, tidal or ocean current, thermal gradient, and salinity gradient) or MRE can revolutionize ocean observing capabilities. Five use cases representing a range of ocean observing platforms were developed based on end-user feedback. Drawing from these use cases, common needs or functional requirements were developed to help guide the integration of MRE power delivery for ocean observation structures and functions. The functional requirements were determined from descriptions of the use cases, specifications of hardware that are used or closely associated with existing ocean observation platforms, and direct feedback from ocean observation sensor/platform developers and users. Twenty types of functional requirements were identified, including those associated with power and energy use; physical system requirements; temperature and depth; electrical, acoustic, and motion interference; and reliability. Each set of functional requirements is illustrated as features of the use cases. By defining functional requirements for MRE technology integration in ocean observing platforms, and focusing on end-user requirements, barriers to developing MRE-driven ocean observation missions can be reduced.

Cavagnaro, Robert J.↗
DOE OSTI2016

Tritium Distribution and Capture Requirements for UNF Reprocessing

Four radionuclides have been identified as being sufficiently volatile in reprocessing of nuclear fuel that their gaseous release needs to be controlled to meet U.S. regulatory requirements. These radionuclides are {sup 3}H, {sup 14}C, {sup 85}Kr, and {sup 129}I. Previous studies have discussed the need for treating off-gas streams to control {sup 3}H, {sup 14}C, {sup 85}Kr, and {sup 129}I from the reprocessing of used nuclear fuel (UNF) and the regulations that set the limits for releases from such a facility. These regulations ultimately prescribe the decontamination factor (DF) that must be met in the facility. Jubin et al. examined the role of off-gas pathways since the gaseous radionuclides can partition to different reprocessing off-gas streams. Based on this report and subsequent analysis, the required DF for {sup 129}I could be 1000 to 3000. The required DF for {sup 3}H could be as high as 200, depending on the age of the fuel processed. The DF for {sup 85}Kr could be up to ∼35, also depending on fuel age. The required DF for {sup 14}C is 1 in many cases (no treatment required) but could be higher in specific cases. While iodine has been the focus of a number of studies due to the high DF requirements on multiple escape pathways, it is clear from the studies noted above that the control of tritium will also be a significant issue for future reprocessing plants, especially if processing relatively short-cooled fuels (<10 yr post reactor discharge). Tritium contained in a UNF matrix will be released into the liquid and off-gas streams during fuel reprocessing. The amount released into the process streams is a function of the type and burnup of the fuel processed, and the chemical processes employed within the reprocessing plant. Previous studies have examined the tritium capture requirements for the reprocessing facility assuming that all of the tritium is volatilized in the head-end operations, i.e., tritium pretreatment is employed and tritium is completely released from the cladding. This is clearly a worst case scenario from the standpoint of the amount of tritium that could be released, but the scenario tends to limit the release pathway to the head-end off-gas stream. In this analysis, the volume of HTO and the HTO to H{sub 2}O ratio for each of the three plant-wide tritium DFs were determined. The overall amount of HTO that had to be captured from the off-gas streams was virtually the same for the three DF cases evaluated; 98%, 99% and 99.5% of the tritium in the fuel entering the plant needed to be recovered for overall plant DFs of 50, 100 and 200, respectively. The use of the 'tritium barrier' to limit the spread of HTO from the head-end systems to the balance of the plant results in an increase in tritiated waste concentration in the head-end recycle acid systems which results in a decrease in the total amount of HTO + H{sub 2}O that must recovered from the gaseous effluent from the plant. The use of the 'tritium barrier' decreases the waste volume due to the higher HTO:H{sub 2}O ratio in the treated off-gas stream. The results also show that increasing the acid recycle percentage increases the concentration of HTO within the UNF reprocessing plant. This is then manifested in less HTO + H{sub 2}O that must be recovered from the gaseous effluents. Finally, the application of tritium recovery on the recycle acid reduces the HTO concentration in the recycle acid stream and generates a separate HTO + H{sub 2}O stream that must be managed. However, the resulting volume of tritium-containing waste generated plant-wide is a function of the selectivity of the tritium recovery system and the ability of the tritium recovery system to limit the accumulation of HTO in the recycle acid such that the HTO + H{sub 2}O recovered from gaseous effluents does not contribute significantly to the overall tritium waste volume. (authors)

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗