Workshop on Biosecurity Curriculum Development in Yemen - Day 2: Analyze Design and Develop for Biosecurity Curriculum in Yemen.
Abstract not provided.
SEARCH · Engineering Papers
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.
Abstract not provided.
A key challenge for research roadmapping in the crisis response and management domain is articulation of a shared vision that describes what the future can and should include. Visioning allows for far-reaching stakeholder engagement that can properly align research with stakeholders needs. Engagement includes feedback from researchers, policy makers, general public, and end-users on technical and non-technical factors. This work articulates a process and framework for the construction and maintenance of a stakeholder-centric research vision and roadmap in the emergency management domain. This novel roadmapping process integrates three pieces: analysis of the research and technology landscape, visioning, and stakeholder engagement. Our structured engagement process elicits research foci for the roadmap based on relevance to stakeholder mission, identifies collaborators, and builds consensus around the roadmap priorities. We find that the vision process and vision storyboard helps SMEs conceptualize and discuss a technology's strengths, weaknesses, and alignment with needs
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Abstract not provided
Explore the source record for details and available documents.
Abstract not provided.
Explore the source record for details and available documents.
This report provides the status of tensile, creep, fatigue, and creep-fatigue testing to date conducted at Argonne National Laboratory, Idaho National Laboratory, and Oak Ridge National Laboratory to generate the data package required to qualify Alloy 709 in American Society of Mechanical Engineers, Boiler and Pressure Vessel Code, Section III, Division 5. The Division 5 Class A Alloy 709 Code Case requires data generated from a minimum of three commercial heats. Extensive mechanical properties data have been generated on two commercial heats, and some initial test data have been generated from the third commercial heat. The room temperature tensile test results for the three commercial heats met the specification minimum of the American Society of Mechanical Engineers, Boiler and Pressure Vessel Code, Section II, Part A, SA-213/SA-213M for Grade TP310MoCbN (UNS S31025) seamless tubing. These three commercial heats of Alloy 709 are suitable for generating the code case data.
Explore the source record for details and available documents.
This presentation is for the paper INL/CON-22-65800
Explore the source record for details and available documents.
This Final Report refers to the project “Development of Thermoacoustic Sensors for Sodium-cooled Fast Reactor Systems”, which was led by Westinghouse Electric Company (Westinghouse) and carried out in collaboration with Argonne National Laboratory (ANL) and University of Pittsburgh. Thermo-acoustic Power Sensors (TAPS) are self-powered, wireless sensors envisioned for measuring key parameters, such as local temperature and neutron flux, in a nuclear reactor core. This project was intended to specifically investigate their applicability to Sodium-cooled Fast Reactors (SFR). TAPS are non-invasive (wireless) and passive (self-powered) devices. The passivity derives from their ability to use conditions that “naturally” exist in a nuclear reactor, such as gamma and neutron flux, as power sources. They generate oscillating pressure waves (i.e., sound waves) which, with a frequency and amplitude dependent upon these conditions, can travel through the core and associated structures, and reach the outside of the reactor vessel where a properly designed network of receivers can detect and interpret them. These receivers require a very small amount of power which, during loss of power events, can be provided for example by harvesting gamma radiation energy, thus resulting in a monitoring system that can function both during normal operation and during loss of power events. The project aimed at TAPS development through a series of tasks which are listed and briefly discussed as follows. TASK 1 – Sensor hardware design Subtask 1a: Assessment of sensor applications to SFRs Subtask 1b: Development of sensor functional requirements Subtask 1c: Definition of sensor hardware design specifications Task description: TAPS design was informed by considerations on their application (Subtask 1a), both the ultimate one in an SFR and the actual one in the ANL testing facilities that was intended to be used in support of the project. Considerations were made to identify optimum sensor design features that optimize the sensor size, materials, and output signal, for installation inside an SFR core. These considerations led to the development of Functional Requirements (Subtask 1b) and Design Requirements (Subtask 1c). TASK 2 – Sensor Hardware Manufacture Subtask 2a: Sensor hardware construction drawing development Subtask 2b: Sensor manufacture and assembly Task description: TAPS technical drawings were developed (Subtask 2a) using the Design Requirements established under Task 1. Subsequently, in spite of some problems which ultimately caused the program to be delayed, TAPS manufacturing was completed based on drawings (Subtask 2b). TASK 3 – Development of TAPS Signal Measurement System and TAPS Testing in Water Subtask 3a: Design, assembly and testing of signal measurement system, and TAPS testing in water Subtask 3b: Signal prediction-correction methodology development Task description: An assessment was performed on the techniques that can potentially be used to detect the signals emitted by the TAPS, e.g. a fiber-optic based acoustic signal measurement system, a laser vibrometer system, or an accelerometer-based system. The most suited technology, i.e. the accelerometer-based system, was developed further, and tested in water (Subtask 3a). Moreover, efforts were made to develop the methodology required to determine the actual system temperature and neutron flux distribution using differences between the measured and predicted TAPS responses (Subtask 3b). TASK 4 – Sensor System Testing in Sodium Subtask 4a: Test plan development Subtask 4b: Design, assembly and testing in small-scale sodium facility Subtask 4c: Design, assembly and testing in large-scale sodium and structures facility Task description: Upon proper test plan development (Subtask 4a), the fabricated TAPS was planned to be tested in sodium, by using two sodium facilities at ANL having different size and different purpose. The Under Sodium Viewing (USV) small-scale facility was intended to be used to investigate the effect of sodium on the sensor and its performance (Subtask 4b). The Mechanism Engineering Test Loop (METL) large-scale facility was instead intended to be used to assess the additional effect of prototypical SFR structures, such as fuel assembly mockup or parts of the core restrain structure, on sensor performance (Subtask 4c). As discussed in Section 3.2.2.7, unexpected issues during the TAPS manufacturing process resulted in some activities being delayed, with the TAPS and USV facility developed to the point to be ready for testing in sodium, however without the possibility to actually perform such testing (including the testing in METL) due to the end of the program’s performance period. Overall, through the development and testing (in water only) of two TAPS devices (a First-Generation TAPS followed by an optimized Second-Generation TAPS), the project confirmed the capability of this technology to generate acoustic signals proportional to temperature, which can be detected through a network of accelerometers identified as the best-suited type of receivers for acoustic signal detection. Moreover, the project also developed a computational model to predict the characteristics of the acoustic signals being generated, which combines thermal analysis of the TAPS with Finite Element Modeling (FEM)-aided acoustic characterization of the system. This model was benchmarked against experimental data collected during the project and, although general agreement was obtained, some limitations of the modeling methods were identified, which require additional development. Additional testing is needed in order to assess the effect, on TAPS operation and performance, of environmental changes resulting from the transition from water to liquid sodium. Such testing, which is suggested to be performed in the future, should look specifically at 1) both the effect resulting from the different thermoacoustic behavior of sodium (relative to water) and the effects of higher temperature on TAPS performance, and 2) the performance of the sensor-receiver system when multiple TAPS are used simultaneously and prototypical reactor structures are positioned in the testing environment. The latter testing is needed to assess the effects that potential signal attenuation/ distortion phenomena, as well as potential interference between signals emitted simultaneously, have on the performance of the technology for ultimate application in a nuclear reactor.
The primary goal of this project was to speed the development of one of the first commercially available, OEM-produced plug-in hybrid electric vehicles (PHEV). The performance of the PHEV was expected to double the fuel economy of the conventional hybrid version. This vehicle program incorporated a number of advanced technologies, including advanced lithium-ion battery packs and an E85-capable flex-fuel engine. The project developed, fully integrated, and validated plug-in specific systems and controls by using GM’s Global Vehicle Development Process (GVDP) for production vehicles. Engineering Development related activities included the build of mule vehicles and integration vehicles for Phases I & II of the project. Performance data for these vehicles was shared with the U.S. Department of Energy (DOE). The deployment of many of these vehicles was restricted to internal use at GM sites or restricted to assigned GM drivers. Phase III of the project captured the first half or Alpha phase of the Engineering tasks for the development of a new thermal management design for a second generation battery module. The project spanned five years. It included six on-site technical reviews with representatives from the DOE. One unique aspect of the GM/DOE collaborative project was the involvement of the DOE throughout the OEM vehicle development process. The DOE gained an understanding of how an OEM develops vehicle efficiency and FE performance, while balancing many other vehicle performance attributes to provide customers well balanced and fuel efficient vehicles that are exciting to drive. Many vehicle content and performance trade-offs were encountered throughout the vehicle development process to achieve product cost and performance targets for both the OEM and end customer. The project team completed two sets of PHEV development vehicles with fully integrated PHEV systems. Over 50 development vehicles were built and operated for over 180,000 development miles. The team also completed four GM engineering development Buy-Off rides/milestones. The project included numerous engineering vehicle and systems development trips including extreme hot, cold and altitude exposure. The final fuel economy performance demonstrated met the objectives of the PHEV collaborative GM/DOE project. Charge depletion fuel economy of twice that of the non-PHEV model was demonstrated. The project team also designed, developed and tested a high voltage battery module concept that appears to be feasible from a manufacturability, cost and performance standpoint. The project provided important product development and knowledge as well as technological learnings and advancements that include multiple U.S. patent applications.
The simple goal of the Human Research Facility (HRF) is to conduct human research experiments on the International Space Station (ISS) astronauts during long-duration missions. This is accomplished by providing integration and operation of the necessary hardware and software capabilities. A typical hardware development flow consists of five stages: functional inputs and requirements definition, market research, design life cycle through hardware delivery, crew training, and mission support. The purpose of this presentation is to guide the audience through the early hardware development process: requirement definition through selecting a development path. Specific HRF equipment is used to illustrate the hardware development paths. The source of hardware requirements is the science community and HRF program. The HRF Science Working Group, consisting of SCientists from various medical disciplines, defined a basic set of equipment with functional requirements. This established the performance requirements of the hardware. HRF program requirements focus on making the hardware safe and operational in a space environment. This includes structural, thermal, human factors, and material requirements. Science and HRF program requirements are defined in a hardware requirements document which includes verification methods. Once the hardware is fabricated, requirements are verified by inspection, test, analysis, or demonstration. All data is compiled and reviewed to certify the hardware for flight. Obviously, the basis for all hardware development activities is requirement definition. Full and complete requirement definition is ideal prior to initiating the hardware development. However, this is generally not the case, but the hardware team typically has functional inputs as a guide. The first step is for engineers to conduct market research based on the functional inputs provided by scientists. CommerCially available products are evaluated against the science requirements as well as modifications needed to meet program requirements. Options are consolidated and the hardware development team reaches a hardware development decision point. Within budget and schedule constraints, the team must decide whether or not to complete the hardware as an in-house, subcontract with vendor, or commercial-off-the-shelf (COTS) development. An in-house development indicates NASA personnel or a contractor builds the hardware at a NASA site. A subcontract development is completed off-site by a commercial company. A COTS item is a vendor product available by ordering a specific part number. The team evaluates the pros and cons of each development path. For example, in-bouse developments utilize existing corporate knowledge regarding bow to build equipment for use in space. However, technical expertise would be required to fully understand the medical equipment capabilities, such as for an ultrasound system. It may require additional time and funding to gain the expertise that commercially exists. The major benefit of subcontracting a hardware development is the product is delivered as an end-item and commercial expertise is utilized. On the other hand, NASA has limited control over schedule delays. The final option of COTS or modified COTS equipment is a compromise between in-house and subcontracts. A vendor product may exist that meets all functional requirements but req uires in-house modifications for successful operation in a space environment. The HRF utilizes equipment developed using all of the paths described: inhouse, subcontract, and modified COTS.
The Psyche mission to the asteroid (16) Psyche was selected as the fourteenth mission in the Discovery program in January 2017. The Psyche mission will determine if (16) Psyche is the core of a larger differentiated body. As part of the development of this mission a Verification and Validation (V&V) engineer was assigned early in the project’s design Phase B. This paper will discuss some of the strategies that the Psyche team is using to take full advantage of the early planning for V&V on flight projects and specifically how the Psyche mission is approaching these tasks. This paper will discuss the effects of having a V&V mindset on: 1) The Psyche requirements development process, and how focusing not only on how the team will verify these requirements but also on developing the tools necessary to track and monitor that verification feeds back into the requirement development process. 2) The Psyche testbed development, and how using a verification mindset is useful for identifying holes in the testbed development process, including the required testbed speed and how to think about testbed certification early in the process while encouraging trades and developing relationships with the testbed team. 3) Developing new V&V Tools for Psyche, and how developing tools early in the project development process means that they can influence the development of other requirement and scheduling tools. 4) Verification Activity Planning, which is typically done to a preliminary level during Phase B of the project, and is important for understanding the major testing that is needed to ensure that the system as built represents the design. On Psyche we are not only focused on bringing this planning to a preliminary level, we are also developing a V&V focused schedule to help us de-conflict V&V activities that may require similar resources early on in the program’s development. 5) Validation Planning, for which we are working with the testbed and model development teams to ensure that their models can be effectively validated and that the plans to do so are in place. In this paper we will describe how the Psyche mission is approaching each of these V&V areas and identify lessons that can be taken by other space missions trying to decide how much effort should be put into V&V early in the project lifecycle.
Previous studies have demonstrated the necessity of involving users in the development of automation aids, especially for complex domains such as air traffic control (ATC). Traditional development only demanded a single field test to validate a completed system, but a more iterative combination of development and assessment ensures that the technology meets the requirements of its application domain. Exposure across an adequate spectrum of field users is also required during development, and the use of multiple development sites provides an opportunity to consider individual facility cultures as they relate to implementation strategies. The development of the Center/TRACON Automation System (CTAS) Traffic Management Advisor (TMA) at the Denver and Dallas ATC facilities demonstrates successful iterative development and assessment at multiple field sites. The use of field development changes the nature of assessment. As development progresses, periodic assessments are required to validate that system development is progressing along an appropriate track. In the development of the TMA, assessments were performed based on software in the field, and input from traffic managers was analyzed and incorporated into subsequent releases of the TMA, to be reassessed in the field. This has led to a tool with operational suitability and broad user acceptance. Assessment at multiple sites provides a more generalizable perspective that allows the production of a system that is both generic enough to be used at different sites and tailored enough to be of use at any site. In addition to providing a better understanding of specific facility requirements, the use of multiple assessment sites in the development of TMA has provided an opportunity to consider individual facility operations, procedures and cultures as they relate to development and implementation strategies.