Development of a Downhole Piston Motor Power Section for Improved Directional Drilling: Part II - Axial Piston Motor Development & Testing.
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.
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 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.
The small patient populations inherent to rare genetic diseases present many challenges to the traditional drug development paradigm. One major challenge is generating sufficient data in early phase studies to inform dose selection for later phase studies and dose optimization for clinical use of the drug. However, optimizing the benefit-risk profile of drugs through appropriate dose selection during drug development is critical for all drugs, including those being developed to treat rare diseases. Recognizing the challenges of conducting dose finding studies in rare disease populations and the importance of dose selection and optimization for successful drug development, we assessed the dose-finding studies and analyses conducted for drugs recently approved for rare genetic diseases. Of the 40 marketing applications for new molecular entity (NME) drugs and biologics approved by the United States Food and Drug Administration for rare genetic diseases from 2015 to 2020, 21 (53%) of the development programs conducted at least one dedicated dose-finding study. In addition, the majority of drug development programs conducted clinical studies in healthy subjects and included population pharmacokinetic and exposure–response analyses; some programs also conducted clinical studies in patient populations other than the disease for which the drug was initially approved. The majority of primary endpoints utilized in dedicated dose-finding studies were biomarkers, and the primary endpoint of the safety and efficacy study matched the primary endpoint used in the dose finding study in 9 of 13 (69%) drug development programs where primary study endpoints were assessed. Our study showed that NME drug development programs for rare genetic diseases utilize multiple data sources for dosing information, including studies in healthy subjects, population pharmacokinetic analyses, and exposure–response analyses. In addition, our results indicate that biomarkers play a key role in dose-finding studies for rare genetic disease drug development programs. Our findings highlight the need to develop study designs and methods to allow adequate dose-finding efforts within rare disease drug development programs that help overcome the challenges presented by low patient prevalence and other factors. Furthermore, the frequent reliance on biomarkers as endpoints for dose-finding studies underscores the importance of biomarker development in rare diseases.
One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and procedure for developing software. This paper will discuss the some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies.
One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases, they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At the Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and processes for developing software. This paper will discuss some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies and processes.
This study examines how different types of social network structures are associated with early cognitive development in children. Objectives To assess how social relationships and structures are associated with early cognitive development and to elucidate whether variations in the mother’s social networks alter a child’s early cognitive development patterns. Design, Setting, and Participants This cohort study used data from 1082 mother-child pairs in the University of Tennessee Health Science Center–Conditions Affecting Neurocognitive Development and Learning and Early Childhood project to examine the association between networks of different levels of complexity (triad, family, and neighborhood) and child cognitive performance after adjustment for the mother’s IQ, birth weight, and age, and the father’s educational level. The final model was adjusted for the household poverty level. Data were collected from December 2006 through January 2014 and analyzed from October through November 2018. Exposures The child-mother relationship, child-mother-father triad, family setting, child’s dwelling network, mother’s social support network, and neighborhood networks. Main Outcomes and Measures Measure of cognitive development of the child using Bayley Scales of Infant Development (BSID) at 2 years of age. Results Of 1082 participants, 544 (50.3%) were males and 703 (65.1%) were African American; the mean (SD) age was 2.08 (0.12) years. Large family size had a negative association with early cognitive development, with a mean 2.21-point decrease in BSID coefficient score (95% CI, 0.40 to 4.02; P = .01). Mother’s social support network size was positively associated early cognitive development, with a mean 0.40-point increase in BSID coefficient score (95% CI, 0.001 to 0.80; P = .05). Knowing many neighbors was not statistically significantly associated with early cognitive development, with a mean 1.39-point increase in BSID coefficient score (95% CI, -0.04 to 2.83; P = .06). Conclusions and Relevance The findings suggest that maternal social relationships are associated with cognitive development in children and that social relationships beyond the mother-child-father triad are significantly associated with children’s cognitive development. This study investigates the environmental influences on child health outcomes and, specifically, how early cognitive development is associated with social networks for the primary caregiver.
Ada will soon become a part of systems developed for the US Department of Defense. NASA must determine whether it will become part of its environment and particularly whether it will become a part fo the space station development. However, there are several issues about Ada which should be considered before this decision is made. One means of considering these issues is the examination of other developments in Ada. Unfortunately, few full scale developments have been completed or made publicly available for observation. Therefore, it will probably be necessary to study an Ada development in a NASA environment. Another means related to the first is the development of Ada metrics which can be used to characterize and evaluate Ada developments. These metrics need not be confined to full scale developments and could be used to evaluate on going projects as well. An early development in Ada, some observations from that development, metrics which were developed for use with Ada, and future directions for research into the use of Ada in software development in general and in the NASA Goddard environment in particular are described.
The NASA Marshall Space Flight Center (MSFC) has been leading the development of technologies that will enable the development, fabrication, and flight of the automated X-37 Orbital Vehicle (OV). With the Administration s recent announcement of the Vision for Space Exploration, NASA placed the X-37 OV design on hold while developing detailed requirements for a Crew Exploration Vehicle, but has continued funding the development of high-risk, critical technologies for potential future space exploration vehicle applications. Hot Structure Control Surfaces (HSCS) technology development is one of the high-priority areas being funded at this time. The goal of HSCS research is to mitigate risk by qualifying the lightest possible components that meet the stringent X-37 OV weight and performance requirements, including Shuttle-type reen- try environments with peak temperatures of 2800 OF. The small size of the X-37 OV (25.7-feet long and 14.9-foot wingspan) drives the need for advanced HSCS because the vehicle's two primary aerodynamic surfaces, the flaperons and ruddervators, have thicknesses ranging from approximately 5 in. down to 1 in. Traditional metallic or polymer-matrix composites covered with tile or blanket thermal protection system (TPS) materials cannot be used as there is insufficient volume to fabricate such multi-component structures. Therefore, carbon-carbon (C-C) and carbodsilicon-carbide (C-SiC) composite HSCS structures are being developed in parallel by two teams supporting the X-37 prime contractor (The Boeing Company). The Science Applications International Coy. (SAIC) and Carbon-Carbon Advanced Technologies, Inc. (C-CAT) team is developing the C-C HSCS, while the General Electric Energy Power Systems Composites (GE-PSC) and Materials Research and Design (MRD) team is developing the C-SiC HSCS. These two teams were selected to reduce the high level of risk associated with developing advanced control surface components. They have continued HSCS development work as part of the X-37 critical technology development contract. The SAIC/C-CAT team is using Advanced Carbon-Carbon (ACC) because its fabrication is very similar to the process used for Space Shuttle Reinforced Carbon-Carbon fabrication, including the Sic-based pack cementation conversion coating systems using with both materials. ACC was selected over RCC because it has much higher tension and compressions strengths, and because T-300 fiber is readily available, whereas RCC rayon fiber is no longer manufactured. The GE-PSC/MRD team is using a T-300 fiber-reinforced Sic matrix composite material densified by chemical vapor infiltration. The C-Sic material has an Sic-based environmental barrier coating. Major accomplishments have been made over the past year by both HSCS teams. C-C and C- SiC flaperon subcomponents, which are truncated full-scale versions of flight hardware, have been fabricated and are undergoing testing at the NASA Dryden Flight Research Center, NASA Langley Research Center, and U.S. Air Force Research Laboratory. By the end of 2004, ruddervator subcomponents also will be delivered and tested. As NASA moves forward in realizing the Vision for Space Exploration, it will continue to invest in advanced research and development aimed at making new generations of spacecraft safer, more reliable, and more affordable. The X-37 HSCS effort ultimately will benefit the Agency's vision and mission.
YAM is a software development framework with tools for facilitating the rapid development and integration of software in a concurrent software development environment. YAM provides solutions for thorny development challenges associated with software reuse, managing multiple software configurations, the development of software product-lines, multiple platform development and build management. YAM uses release-early, release-often development cycles to allow developers to incrementally integrate their changes into the system on a continual basis. YAM facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. YAM uses modules and packages to organize and share software across multiple software products. It uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One side-benefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability as well as software reuse. YAM is in use by several mid-size software development teams including ones developing mission-critical software.
The Energy Storage Project of NASA s Exploration Technology Development Program is developing advanced lithium-ion batteries to meet the requirements for specific Constellation missions. NASA GRC, in conjunction with JPL and JSC, is leading efforts to develop High Energy and Ultra High Energy cells for three primary Constellation customers: Altair, Extravehicular Activities (EVA), and Lunar Surface Systems. The objective of the High Energy cell development is to enable a battery system that can operationally deliver approximately 150 Wh/kg for 2000 cycles. The Ultra High Energy cell development will enable a battery system that can operationally deliver 220 Wh/kg for 200 cycles. To accomplish these goals, cathode, electrolyte, separator, and safety components are being developed for High Energy Cells. The Ultra High Energy cell development adds lithium alloy anodes to the component development portfolio to enable much higher cell-level specific energy. The Ultra High Energy cell development is targeted for the ascent stage of Altair, which is the Lunar Lander, and for power for the Portable Life support System of the EVA Lunar spacesuit. For these missions, mass is highly critical, but only a limited number of cycles are required. The High Energy cell development is primarily targeted for Mobility Systems (rovers) for Lunar Surface Systems, however, due to the high risk nature of the Ultra High Energy cell development, the High Energy cell will also serve as a backup technology for Altair and EVA. This paper will discuss mission requirements and the goals of the material, component, and cell development efforts in further detail.