Search NASA⌕ Search

SEARCH · Search NASA

Results for “integrated testing”

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 883 records · Page 49
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

An Implementation Analysis of Communications, Navigation, and Surveillance (CNS) Technologies for Unmanned Air Systems (UAS)

The aviation industry and government agencies face a rapidly-emerging need for integrating large-scale populations of Unmanned Air Systems (UAS) into the worldwide controlled and uncontrolled airspace. Critical components for integration include the Communications, Navigation, and Surveillance (CNS) technologies necessary for ensuring safe UAS operations. Under NASA program NNA16BD84C, our work on CNS architectural concepts for the safe operation of UAS in controlled and uncontrolled airspace has introduced CNS architectures which must be analyzed in terms of implementation readiness.Controlled airspace operations for UAS are consistent with the needs for manned aviation in the worldwide Air Traffic Management (ATM) service. Uncontrolled airspace operations are consistent with the NASA Unmanned (air) Traffic Management (UTM) concept of operations. Implementation readiness is based on the NASA concept of Technology Readiness Levels (TRLs) ranging from TRL1 (basic principles observed and reported) to TRL9 (actual system flight proven through successful mission operations). In the architecture concepts, we have introduced a number of new CNS architectural elements which need to be correlated with TRL levels. In this paper, we present our implementation analysis for communications networks, communications data links, navigation, and surveillance. Each area has been under active research and development during the course of the current NASA program which has produced studies on UAS CNS Requirements, UAS CNS Architecture for Controlled Airspace and UAS CNS Architecture for Uncontrolled Airspace. We have published our architecture concepts in major UAS-related conferences (including iCNS2017, IEEE Aerospace 2018, and iCNS2018) and will continue to seek additional publication opportunities. We look forward to continuing our work to realize a full integration testing scenario for both controlled and uncontrolled airspace operation.

Unmanned (Air) Traffic Management (UTM) service↗
NASA NTRS2019

Characterization of Flat-Plate Heat Pipe Functionality for Fuel Cell Application

For many exothermic systems such as proton exchange membrane (PEM) fuel cells, cooling is necessary to maintain consistent and uniform operating temperatures which are generally in the range of 60 to 80°C. A potential solution is a heat pipe employing the principle of conduction in combination with a phase change. The purpose of this study was to fully characterize the operation of a heat pipe with unique geometry designed for fuel cell heat removal at operating temperatures up to 100°C and to assess the suitability of the resulting performance for cooling system integration. Test variables consist of cold sink thermal contact conductance coefficient improving material usage, heat rejection temperature, contact pressure and area, heat pipe orientation, operational hours, and variability between units. The test results showed that heat pipe performance improves through increased condenser and heat sink contact pressure, thermal contact coating usage, greater condenser area utilization, and colder heat sink temperature. Higher initial heat pipe temperature and greater age or operation time reduce the heat pipe capabilities. Placing the condenser lower than the evaporator is the only heat pipe orientation that affects evaporator plate temperature. Condensing fluid in the lower section reduces heat transfer capacity as that orientation requires liquid water to transport by wicking against gravity.

Smith, Phillip J.↗
NASA NTRS2018

NOS3: NASA Operational Simulator for Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.

Suder, Mark↗
NASA NTRS2018

PACE Technical Report Series, Volume 5: Mission Formulation Studies

This chapter summarizes the mission architecture for the Plankton, Aerosol, Cloud, ocean Ecosystem (PACE) mission, ranging from its scientific rationale to the history of its realized conception to itspresent-day organization and management. This volume in the PACE Technical Report series focuses ontrade studies that informed the formulation of the mission in its pre-Phase A (2014-2016; pre-formulation:define a viable and affordable concept) and Phase A (2016-2017; concept and technology development).With that in mind, this chapter serves to introduce the mission by providing: a brief summary of thescience drivers for the mission; a history of the direction of the mission to NASA's Goddard Space Flight Center (GSFC); a synopsis of the mission's and instruments' management and development structures; and a brief description of the primary components and elements that form the foundation ofthe mission, encompassing the major mission segments (space, ground, and science data processing) and their roles in integration, testing, and operations.

Cetinic, Ivona↗
NASA NTRS2018

An Implementation Analysis of Communications, Navigation, and Surveillance (CNS) Technologies for Unmanned Air Systems (UAS)

The aviation industry and government agencies face a rapidly-emerging need for integrating large-scale populations of Unmanned Air Systems (UAS) into the worldwide controlled and uncontrolled airspace. Critical components for integration include the Communications, Navigation, and Surveillance (CNS) technologies necessary for ensuring safe UAS operations. Under NASA program NNA16BD84C, our work on CNS architectural concepts for the safe operation of UAS in controlled and uncontrolled airspace has introduced CNS architectures which must be analyzed in terms of implementation readiness.Controlled airspace operations for UAS are consistent with the needs for manned aviation in the worldwide Air Traffic Management (ATM) service. Uncontrolled airspace operations are consistent with the NASA Unmanned (air) Traffic Management (UTM) concept of operations. Implementation readiness is based on the NASA concept of Technology Readiness Levels (TRLs) ranging from TRL1 (basic principles observed and reported) to TRL9 (actual system flight proven through successful mission operations). In the architecture concepts, we have introduced a number of new CNS architectural elements which need to be correlated with TRL levels.In this paper, we present our implementation analysis for communications networks, communications data links, navigation, and surveillance. Each area has been under active research and development during the course of the current NASA program which has produced studies on UAS CNS Requirements, UAS CNS Architecture for Controlled Airspace and UAS CNS Architecture for Uncontrolled Airspace. We have published our architecture concepts in major UAS-related conferences (including iCNS2017, IEEE Aerospace 2018, and iCNS2018) and will continue to seek additional publication opportunities. We look forward to continuing our work to realize a full integration testing scenario for both controlled and uncontrolled airspace operation.

Ponchak, Denise↗
NASA NTRSDate not supplied

Lightning Protection System

A new Lightning Protection System (LPS) was designed and built at Launch Complex 39B (LC-39B), at the Kennedy Space Center (KSC), Florida, in 2009, for NASA’s Space Launch System (SLS) program. A comprehensive lightning monitoring system was additionally designed and the LC-39B lightning instrumentation started incremental deployment early 2011. By March 2011, the LC-39B lightning monitoring system was activated with short outages during construction and renovations of the LC-39B. Since 2011, the LC-39B LPS has been directly struck at least once per year. The earliest and latest in a year that the LPS has been directly struck by lightning has been January 7th and October 1st (both 2017), respectively. During the summer of 2018, the Mobile Launcher 1 (ML-1) lightning monitoring system was deployed and partially active during ML-1 construction/testing. Since 2018, the ML-1 has been parked at the LC-39B for different durations of time for integrated testing. Early August 2019 (6th and 9th ) multiple lightning strikes terminated directly on the LPS at three different locations in addition to a nearby strike within the Pad perimeter and multiple nearby strikes outside the Pad Perimeter, triggering both, the LC-39B and the ML-1 lightning monitoring systems. This has been the first time direct lightning strikes have terminated on the LPS or within the LC-39B perimeter while the ML-1 has been at the LC-39B. This paper summarizes direct and close nearby lightning strikes to LC-39B from 2011 until the summer of 2019.

Angel G Mata↗
NASA NTRSDate not supplied

Going beyond reliability to robustness and resilience in space systems

The words reliability, robustness, and resilience, are often used interchangeably to describe tough and dependable systems but the distinctions between them suggest how to design more serviceable space systems. Reliability is simply the quality of consistently performing well. A system that dependably meets its design requirements in the specified environments is reliable. The designers may not consider themselves responsible for failures under unanticipated conditions. Robustness is the capability of performing without failure under a wide range of conditions, which can go beyond the expected range to include possible off-nominal conditions. Resilience is the ability to recover from or adapt to damaging events, such as failures, accidents, external disruptions, and repurposing. Such changes are usually unanticipated. They often invalidate the usual operating assumptions and cause system failure. Reliability, robustness, and resilience describe dependable performance under increasingly difficult conditions, first the specified environment, then a wider possible environment, and finally unanticipated damaging events. These three are increasingly desirable and increasingly difficult to achieve. Engineering for resilience would design systems that can ignore or repair failures, survive accidents, and recover from disruptions. Increasing the resilience of space systems, the ability to perform after unanticipated events, would greatly increase space crew safety. Improving reliability and robustness can be done by dealing with known sources of problems, but improving resilience requires implementing a general approach to reducing the impact of unknown future events. Two contrasting approaches are reducing system complexity and adding supervisory control. The need for resilience has been claimed for decades but little has been accomplished. Systems designers assume that they understand requirements, technologies, designs, architectures, integration, testing, operations, and environments. The potential problems of changes, failures, accidents, unknown environments, and unknown unknowns are ignored. Systems designers are typically overconfident and ignore the need for robustness and resilience.

Harry W Jones↗
NASA NTRSDate not supplied

Designing a Distributed Web-based Simulation Environment for Enabling Autonomous Systems Research

In the continued pursuit of creating a future with robust Urban Air Mobility (UAM) operations defined as safe and efficient air traffic operations in metropolitan environments for both piloted and autonomous systems, development of the concepts, technologies, and procedures to establish this UAM ecosystem remains an active area of research. In particular, as autonomous systems continue to grow in both complexity and use throughout UAM concepts the need for simulation environments to both test individual components and systems and to study the complex interactions between them is paramount. In this paper we address design considerations, technologies, and challenges of adapting native simulation environment application concepts to an interactive and distributed web-based framework. The proposed web-based design allows for easier and wider access for developing, testing, integrating, and studying emergent behaviors of complex autonomous systems interaction. We demonstrate the utility of the proposed approach by showing multi-agent interaction and emergent behavior in two scenarios: (1) autonomous urban air mobility vehicles flying in a convoy and (2) interaction of a convoy with a search and rescue operation.

Benjamin N Kelley↗
NASA NTRSDate not supplied

The High Density Vertiplex Advanced Onboard Automation Overview

While many studies have been performed examining Urban Air Mobility (UAM) operations from UAM Maturity Level (UML) UML-1 to UML-4, [1, 2] some uncertainty exists regarding the integration and role of onboard autonomous systems, airspace management systems, ground control and fleet management systems, and how they integrate with vertiport automation systems to ensure safe high-density future operations. One thrust of the Advanced Air Mobility (AAM) High Density Vertiplex (HDV) sub-project is to perform rapid prototyping and assessment of an Urban Air Mobility (UAM) Ecosystem within the terminal operational area to help inform future research investments and technology development. Another thrust within HDV is to perform integration, testing, and safety risk assessments required to acquire operational credit for several NASA small Unmanned Aerial Systems (sUAS) beyond visual line of sight (BVLOS) enabling technologies to expand test capabilities and to expedite technology transfer and ultimate effective usage. Both thrusts leverage sUAS to serve as surrogates for the highly-technologically-similar envisioned UAM aircraft as well as to provide significant contributions to sUAS Part-135 operators. This report provides an overview of the activities accomplished within the Advanced Onboard Automation (AOA) schedule work package of HDV.

Human Factors, Simulation↗
NASA NTRSDate not supplied

Challenges of Building, Launching, and Operating The Curiosity SAM Instrument on Mars

The Sample Analysis at Mars (SAM) Suite Investigation onboard the Mars Science Laboratory (MSL) Curiosity rover is currently roving up Mt Sharp in Gale Crater on Mars. It is investigating the present and past habitability of Mars by exploring molecular and elemental chemistry relevant to life. SAM is a suite of three instruments, a Quadrupole Mass Spectrometer (QMS), a Gas Chromatograph (GC), and a Tunable Laser Spectrometer (TLS). As Curiosity climbs Mt. Sharp, SAM’s instrument suite search for and measure the abundances of carbon, oxygen, hydrogen, and nitrogen - elements that are associated with life as we know it. SAM quantitatively addresses the habitability of Mars, an essential step in the search for past or present life on Mars. This talk provides a behind-the-scenes look at the vignettes of the engineering challenges of building, integrating, testing, launching, and the SAM’s team’s initial experiences of operating SAM on Mars.

Florence Tan↗
NASA NTRSDate not supplied

Transforming any Facility for Meeting Strict Cleanliness Requirements

Over the life of the James Webb Space Telescope (JWST), Integration & Test (I&T) has taken place in areas that needed considerable work to make the facility itself and/or the protocols used while working in the rooms suitable to meet JWST percent area coverage (PAC) and molecular accumulation requirements. In addition to normal particulate matter, JWST had a uniquely significant challenge: fibers! Fibers not only cause much higher PAC levels, but they also risk damaging the angstrom sized Near Infrared Spectrometer (NIRSpec) microshutter array (MSA), which is critical to NIRSpec instrument performance. The primary emphasis of this paper is to address particulate and fiber contamination. The success of the JWST mission required effective cleanrooms, protocols, and mitigations in non-cleanroom areas that were pressed into service to house contamination-sensitive optics and scientific instruments. Some presented profound challenges. These included: NASA’s 60-year-old Johnson Space Center (JSC) Chamber A, which had never been used for anything contamination-sensitive, and the European tropical launch facilities, which were designed to meet International Standard Organization (ISO) Class 8 processing for communication satellites. The final challenge for JWST, as if to stare us in the face and say, “I dare you to try and make me clean enough,” was preparing the 4 areas in the Centre Spatial Guyanais (CSG) Final Assembly Building (BAF) located in French Guiana, a building in which one entire side opens for Ariane 5 rocket ingress and egress. This paper will describe our initial evaluation processes and the actual work undertaken to transform even the most challenging areas into first class cleanrooms that met JWST particulate and fiber requirements.

James Webb Space Telescope↗
NASA NTRSDate not supplied

Preliminary Application of Formal Verification to An Autonomy Architecture for Unmanned Aircraft

There is a desire to design autonomous systems in such a way that capabilities can be easily added or re- combined to produce new behaviors while preserving their safety properties. ICAROUS, a prototype software architecture for building safety-centric autonomous unmanned aircraft applications, is designed to support this type of extensibility and re-configurability. In ICAROUS, core capabilities are implemented as individual soft- ware services, so that enabling access to new capabilities simply requires adding new services. To make use of these capabilities, ICAROUS includes a specialized service that provides a general framework for config- uring the relative priorities, conditions, and rules that govern how different modules should be engaged and disengaged during flight. The inherent complexity of coordinating multiple modules under changing conditions makes it difficult to determine whether a particular configuration could have erroneous behaviors in certain circumstances. A robust set of integration tests can help discover errors, but testing can only realistically cover a relatively small proportion of total system behaviors. Developing good tests and interpreting the results to pinpoint the cause of errors when they arise can also be very time-consuming. To supplement testing, formal methods can be used to model and analyze complex systems, achieving better coverage and simplifying the process of finding, understanding, and fixing errors. To demonstrate these benefits, this paper explores the ap- plication of formal methods to ICAROUS. In particular, the Spin model checker is used to specify requirements for and model portions of the system, then verify whether the model satisfies the requirements and find and fix errors when it does not.

Formal Methods↗
NASA NTRS2024

High Level Architecture (HLA) as a Research Tool for Advanced Air Mobility (AAM)

In this document, a NASA investigation into the High-Level Architecture (HLA) standard for distributed simulation as a means of furthering Advanced Air Mobility (AAM) research is illustrated along with a description of the evolution of distributed simulation leading to the HLA standard. HLA enables efficient definition and insertion of components and participants in simulation sessions. Novel concepts can be added or removed as the work evolves. A general history of the HLA standard is described to show past needs for improved methods of distributed simulation, particularly among participating laboratories in separate locations, as well as previous applications of HLA simulation to airspace research. These examples from the past illustrate how new and emerging concepts can be simulated by layering notional ideas over simulated current-day systems and capabilities in a controlled environment for examination. In the 1990s, the Federal Aviation Administration (FAA) and the MITRE Corporation performed joint research into then-emergent capabilities in the National Airspace System (NAS). In the early 2000s, the MITRE Corporation developed an open, extendable set of objects and protocols designed for global and collaborative aviation research called AviationSimNet, which has HLA as its foundation. This led to NASA and the FAA using AviationSimNet to connect laboratories for AAM research, resulting in the NASA/FAA Laboratory Integrated Test Environment (NFLITE). The underlying capabilities of HLA enabled testing a notional interaction between AAM and legacy ATC systems that resulted in AAM vehicles receiving beacon codes for identification on ATC screens in Class C airspace. The potential next steps in this work include defining and examining notional interactions between AAM and legacy ATC systems within Class B airspace.

UAM↗
NASA NTRSDate not supplied

Preliminary Application of Formal Verification to An Autonomy Architecture for Unmanned Aircraft

There is a desire to design autonomous systems in such a way that capabilities can be easily added or re-combined to produce new behaviors while preserving their safety properties. ICAROUS, a prototype software architecture for building safety-centric autonomous unmanned aircraft applications, is designed to support this type of extensibility and re-configurability. In ICAROUS, core capabilities are implemented as individual soft- ware services, so that enabling access to new capabilities simply requires adding new services. To make use of these capabilities, ICAROUS includes a specialized service that provides a general framework for config- uring the relative priorities, conditions, and rules that govern how different modules should be engaged and disengaged during flight. The inherent complexity of coordinating multiple modules under changing conditions makes it difficult to determine whether a particular configuration could have erroneous behaviors in certain circumstances. A robust set of integration tests can help discover errors, but testing can only realistically cover a relatively small proportion of total system behaviors. Developing good tests and interpreting the results to pinpoint the cause of errors when they arise can also be very time-consuming. To supplement testing, formal methods can be used to model and analyze complex systems, achieving better coverage and simplifying the process of finding, understanding, and fixing errors. To demonstrate these benefits, this paper explores the ap- plication of formal methods to ICAROUS. In particular, the Spin model checker is used to specify requirements for and model portions of the system, then verify whether the model satisfies the requirements and find and fix errors when it does not.

Formal Methods↗
NASA NTRSDate not supplied

Preliminary Development of Multi-Vehicle (m:N) Operations with NASA Langley’s Remote Vehicle Operations Center

To achieve the vision of Advanced Air Mobility (AAM), a transition from localized operations of aircraft to remote operations is being pursued across many use cases. This transition will allow fewer human operators to manage more increasingly autonomous aircraft (i.e., m operators managing N vehicles, or m:N). To study this operational concept, the National Aeronautics and Space Administration (NASA) Langley Research Center (LaRC) has developed a prototype remote vehicle operations center and ground control station (GCS) software to conduct research with simulated and real flight operations. To date, flight operations at LaRC have been limited to one vehicle per operator. However, the current paper describes initial development and considerations for enabling m:N flight operations at LaRC. Further, the research described in this paper provides the foundation for a concept of operations (ConOps) that will be developed to support remote operators managing multiple increasingly autonomous vehicles, with the goal of exploring human-autonomy teaming (HAT) concepts that enable more advanced m:N operations. Two key enablers have been identified to facilitate successful m:N operations: GCS software updates for multi-vehicle management and procedural updates for vehicle handoffs during off-nominal events. Additionally, specific modifications were identified across five key areas: technology and software, team structure, inter-team communication, contingency plans, and operator decision flows. Next steps in forming the LaRC m:N ConOps will include working with subject-matter experts to identify off-nominal scenarios, implementing the recommended GCS functionality for m:N operations, and performing integration testing of facility capabilities and new operational procedures. Although the future m:N ConOps will be tailored to the NASA LaRC remote operations facility and flight range, it is intended to be a transparent, accessible, and reality-based exemplar for external organizations seeking to create or evaluate their own m:N operational concepts.

m:N↗
DOE OSTI2018

The International Experimental Thermal Hydraulic Systems database – TIETHYS: A new NEA validation tool

Nuclear reactor codes require validation with appropriate data representing the plant for specific scenarios. The thermal-hydraulic data is scattered in different locations and in different formats. Some of the data is in danger of being lost. A relational database is being developed to organize the international thermal hydraulic test data for various reactor concepts and different scenarios. At the reactor system level, that data is organized to include separate effect tests and integral effect tests for specific scenarios and corresponding phenomena. The database relies on the phenomena identification sections of expert developed PIRTs. The database will provide a summary of appropriate data, review of facility information, test description, instrumentation, references for the experimental data and some examples of application of the data for validation. The current database platform includes scenarios for PWR, BWR, VVER, and specific benchmarks for CFD modelling data and is to be expanded to include references for molten salt reactors. There are place holders for high temperature gas cooled reactors, CANDU and liquid metal reactors. This relational database is called The International Experimental Thermal Hydraulic Systems (TIETHYS) database and currently resides at Nuclear Energy Agency (NEA) of the OECD and is freely open to public access. Going forward the database will be extended to include additional links and data as they become available. https://www.oecd-nea.org/tiethysweb/

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2020

Availability of Shielding Benchmark Experiment Data in the ICSBEP Handbook

The International Criticality Safety Benchmark Evaluation Projects (ICSBEP) has over two decades of experience under the auspices of the Organisation for Economic Co-operation and Development (OECD) Nuclear Energy Agency (NEA) to identify, evaluate, and compile a comprehensive data set of criticality safety benchmark data [1]. The activities of the ICSBEP have led to the continued success of the International Handbook of Evaluated Criticality Safety Benchmark Experiments (ICSBEP Handbook) [2]. The contents of the ICSBEP Handbook include benchmark specifications derived from nuclear facilities around the world, which have been utilized to support criticality safety efforts and also integral testing of nuclear data [3]. The 2020 edition of the ICSBEP Handbook will include data from 582 evaluations containing benchmark specifications for 5,053 critical, subcritical, or near-critical configurations. There are seven criticality-alarm-placement/shielding evaluations containing a total of 45 benchmark configurations, and ten fundamental physics evaluations containing a total of 237 measurements relevant to criticality safety applications. The purpose of this paper is to summarize those benchmarks relative to validation needs in shielding applications currently found within the ICSBEP Handbook. The current and future plans of shielding benchmarks with regards to the ICSBEP will also be discussed.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2019

UMo Benchmark Experiment Data Needed to Support Computational and Nuclear Data Validation

Currently there are almost no benchmark experiment data available directly supporting neutronics modeling and simulation of ~20 wt.% 235U, UMo fuel contained within the Organisation for Co-operation and Development Nuclear Energy Agency (OECD NEA) international benchmark handbooks from the International Criticality Safety Benchmark Evaluation Project (ICSBEP) and International Reactor Physics Experiment Evaluation Project (IRPhEP). The benchmarks within these two handbooks represent the international standards used to support computational and nuclear data validation. Recent activities in nuclear data development supporting new neutronics thermal scattering cross sections for UMo fuel indicate the necessity to provide quality benchmark experiment data that can be utilized to support their validation and development. Preparation of high-integrity neutronics benchmarks from UMo experimental data will ensure proper integral testing of these cross sections, as well as serve to support computational validation of contemporary modeling and simulation software.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗