Results for “Interface modification” — Page 24

NASA NTRS1998

Hydrodynamic Instability in an Extended Landau/Levich Model of Liquid-Propellant Combustion

The classical Landau/Levich models of liquid propellant combustion, which serve as seminal examples of hydrodynamic instability in reactive systems, have been combined and extended to account for a dynamic dependence, absent in the original formulations, of the local burning rate on the local pressure and/or temperature fields. The resulting model admits an extremely rich variety of both hydrodynamic and reactive/diffusive instabilities that can be analyzed in various limiting parameter regimes. In the present work, a formal asymptotic analysis, based on the realistic smallness of the gas-to-liquid density ratio, is developed to investigate the combined effects of gravity, surface tension and viscosity on the hydrodynamic instability of the propagating liquid/gas interface. In particular, a composite asymptotic expression, spanning three distinguished wavenumber regimes, is derived for both cellular and pulsating hydrodynamic neutral stability boundaries A(sub p)(k), where A(sub p) is the pressure sensitivity of the burning rate and k is the disturbance wavenumber. For the case of cellular (Landau) instability, the results demonstrate explicitly the stabilizing effect of gravity on long-wave disturbances, the stabilizing effect of viscosity and surface tension on short-wave perturbations, and the instability associated with intermediate wavenumbers for critical negative values of A(sub p). In the limiting case of weak gravity, it is shown that cellular hydrodynamic instability in this context is a long-wave instability phenomenon, whereas at normal gravity, this instability is first manifested through O(l) wavenumber disturbances. It is also demonstrated that, in the large wavenumber regime, surface tension and both liquid and gas viscosity all produce comparable stabilizing effects in the large-wavenumber regime, thereby providing significant modifications to previous analyses of Landau instability in which one or more of these effects were neglected. In contrast, the pulsating hydrodynamic stability boundary is found to be insensitive to gravitational and surface-tension effects, but is more sensitive to the effects of liquid viscosity, which is a significant stabilizing effect for O(l) and higher wavenumbers. Liquid-propellant combustion is predicted to be stable (i.e., steady and planar) only for a range of negative pressure sensitivities that lie between the two types of hydrodynamic stability boundaries.

Margolis, Stephen B.↗

NASA NTRS1999

Using Transom Jack in the Human Engineering Analysis of the Materials Science Research Rack-1 and Quench Module Insert

This paper describes the human engineering analysis performed on the Materials Science Research Rack-1 and Quench Module Insert (MSRR-1/QMI) using Transom Jack (Jack) software. The Jack software was used to model a virtual environment consisting of the MSRR-1/QMI hardware configuration and human figures representing the 95th percentile male and 5th percentile female. The purpose of the simulation was to assess the human interfaces in the design for their ability to meet the requirements of the Pressurized Payloads Interface Requirements Document - International Space Program, Revision C (SSP 57000). Jack was used in the evaluation because of its ability to correctly model anthropometric body measurements and the physical behavior of astronauts working in microgravity, which is referred to as the neutral body posture. The Jack model allows evaluation of crewmember interaction with hardware through task simulation including but not limited to collision avoidance behaviors, hand/eye coordination, reach path planning, and automatic grasping to part contours. Specifically, this virtual simulation depicts the human figures performing the QMI installation and check-out, sample cartridge insertion and removal, and gas bottle drawer removal. These tasks were evaluated in terms of adequate clearance in reach envelopes, adequate accessibility in work envelopes, appropriate line of sight in visual envelopes, and accommodation of full size range for male and female stature maneuverability. The results of the human engineering analysis virtual simulation indicate that most of the associated requirements of SSP 57000 were met. However, some hardware design considerations and crew procedures modifications are recommended to improve accessibility, provide an adequate work envelope, reduce awkward body posture, and eliminate permanent protrusions.

Dunn, Mariea C.↗

NASA NTRSDate not supplied

Conversion of Environment Files from ORDEM 3 & MEM 3 to STENVI

To perform Micrometeoroid and Orbital Debris (MMOD) analyses, NASA describes the orbital debris particle environment using the ORDEM 3 tool and the micrometeoroid environment using the MEM 3 tool. Both output files that detail the flux of particles as a function of several parameters. European MMOD analyses use different tools to perform similar functions, including the Meteoroid And Space debris Terrestrial Environment Reference (MASTER) environment model, which outputs flux data in the Standard Environment Interface (STENVI) format. The NASA Johnson Space Center Hypervelocity Impact Technology Group was asked to create a converter to translate flux data from the output file formats used by ORDEM 3.x and MEM 3 into the STENVI file format. Validation was performed to ensure that the converter was reproducing the input data correctly. The Bumper 3 MMOD risk assessment tool has a capability for reading ORDEM 3.x, MEM 3, and STENVI environment file formats and was used to compare MMOD risk results generated using the converter’s output STENVI files to the risk results generated using the input ORDEM 3.x and MEM 3 igloo files. Specific point comparisons validated that the converter translated the environment data correctly, producing the intended output. However, realistic risk assessments showed that the bin methodology employed by Bumper for determining particle flux as a function of particle size when reading files in STENVI format produces much higher MMOD risk than the point-interpolation methodology used in Bumper risk assessments using ORDEM and MEM. Modifications to how Bumper 3 reads STENVI files during analyses are considered to improve Bumper’s ability to perform useful analyses with environment files in this format.

STENVI↗

NASA NTRS2023

Conversion of ORDEM 3.X & MEM 3 Into STENVI File Format

To perform Micrometeoroid and Orbital Debris (MMOD) analyses, NASA describes the orbital debris particle environment using the ORDEM 3 tool and the micrometeoroid environment using the MEM 3 tool. Both output files that detail the flux of particles as a function of several parameters. European MMOD analyses use different tools to perform similar functions, including the Meteoroid And Space debris Terrestrial Environment Reference (MASTER) environment model, which outputs flux data in the Standard Environment Interface (STENVI) format. The NASA Johnson Space Center Hypervelocity Impact Technology Group was asked to create a converter to translate flux data from the output file formats used by ORDEM 3.x and MEM 3 into the STENVI file format. Validation was performed to ensure that the converter was reproducing the input data correctly. The Bumper 3 MMOD risk assessment tool has a capability for reading ORDEM 3.x, MEM 3, and STENVI environment file formats and was used to compare MMOD risk results generated using the converter’s output STENVI files to the risk results generated using the input ORDEM 3.x and MEM 3 igloo files. Specific point comparisons validated that the converter translated the environment data correctly, producing the intended output. However, realistic risk assessments showed that the bin methodology employed by Bumper for determining particle flux as a function of particle size when reading files in STENVI format produces much higher MMOD risk than the point-interpolation methodology used in Bumper risk assessments using ORDEM and MEM. Modifications to how Bumper 3 reads STENVI files during analyses are considered to improve Bumper’s ability to perform useful analyses with environment files in this format.

STENVI↗

NASA NTRSDate not supplied

Core Stage TVC Systems Engineering Challenges in Reusing Heritage Hardware

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Core Auxiliary Power Unit (CAPU) is derived from the Orbiter Auxiliary Power Unit (APU). The Orbiter and Solid Rocket Booster APU turbines are powered by hot gas produced by catalyzed hydrazine decomposition. On the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. While direct reuse or slight modification of existing hardware may seem to be a triple-win for a program in cost, schedule, and technical risk mitigation, those benefits can only be realized when its degree of application in a new system is carefully and thoughtfully managed. The heritage hardware reuse should be prescribed within the heritage design capability and reuse environments must lie within the envelope of heritage qualification testing. Despite the significant test and flight experience of the Shuttle heritage hardware components, successful integration with the newly designed CS TVC components and incorporation into the stage design proved to be a challenge which required re-qualification of the heritage hardware as well as thorough integrated testing to support flight certification. Examples of the challenges that were overcome include: re-qualifying heritage hardware to survive new shock and vibration environments, certifying performance of extensively modified heritage hardware, regenerating design insight due to lack of available heritage vendor data, showing compliance to modern structural design standards, translation of heritage requirements for analog avionics to modern digital avionics, and interfacing heritage mechanical hardware with newly designed avionics. This paper is the second installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. This paper will discuss several engineering challenges encountered during the development process for SLS CS TVC and how they were successfully overcome to reach flight readiness.

Thrust Vector Control↗

NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

NASA NTRSDate not supplied

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

NASA NTRSDate not supplied

Space Launch System: Core Stage Thrust Vector Control Systems Engineering Challenges in Reusing Heritage Hardware

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Core Auxiliary Power Unit (CAPU) is derived from the Orbiter Auxiliary Power Unit (APU). The Orbiter and Solid Rocket Booster APU turbines are powered by hot gas produced by catalyzed hydrazine decomposition. On the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. While direct reuse or slight modification of existing hardware may seem to be a triple-win for a program in cost, schedule, and technical risk mitigation, those benefits can only be realized when its degree of application in a new system is carefully and thoughtfully managed. The heritage hardware reuse should be prescribed within the heritage design capability and reuse environments must lie within the envelope of heritage qualification testing. Despite the significant test and flight experience of the Shuttle heritage hardware components, successful integration with the newly designed CS TVC components and incorporation into the stage design proved to be a challenge which required re-qualification of the heritage hardware as well as thorough integrated testing to support flight certification. Examples of the challenges that were overcome include: re-qualifying heritage hardware to survive new shock and vibration environments, certifying performance of extensively modified heritage hardware, regenerating design insight due to lack of available heritage vendor data, showing compliance to modern structural design standards, translation of heritage requirements for analog avionics to modern digital avionics, and interfacing heritage mechanical hardware with newly designed avionics. This paper is the second installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. This paper will discuss several engineering challenges encountered during the development process for SLS CS TVC and how they were successfully overcome to reach flight readiness.

Thrust Vector Control↗

NASA NTRS2017

Development of Reliable Life Support Systems

The life support systems on the International Space Station (ISS) are the culmination of an extensive effort encompassing development, design, and test to provide the highest possible confidence in their operation on ISS. Many years of development testing are initially performed to identify the optimum technology and the optimum operational approach. The success of this development program depends on the accuracy of the system interfaces. The critical interfaces include the specific operational environment, the composition of the waste stream to be processed and the quality of the product. Once the development program is complete, a detailed system schematic is built based on the specific design requirements, followed by component procurement, assembly, and acceptance testing. A successful acceptance test again depends on accurately simulating the anticipated environment on ISS. The ISS Water Recovery System (WRS) provides an excellent example of where this process worked, as well as lessons learned that can be applied to the success of future missions. More importantly, ISS has provided a test bed to identify these design issues. Mechanical design issues have included an unreliable harmonic drive train in the Urine Processor's fluids pump, and seals in the Water Processor's Catalytic Reactor with insufficient life at the operational temperature. Systems issues have included elevated calcium in crew urine (due to microgravity effect) that resulted in precipitation at the desired water recovery rate, and the presence of an organosilicon compound (dimethylsilanediol) in the condensate that is not well removed by the water treatment process. Modifications to the WRS to address these issues are either complete (and now being evaluated on ISS) or are currently in work to insure the WRS has the required reliability before embarking on a mission to Mars.

Carter, Layne↗

NASA NTRS2017

Development of Reliable Life Support Systems

The life support systems on the International Space Station (ISS) are the culmination of an extensive effort encompassing development, design, and test to provide the highest possible confidence in their operation on ISS. Many years of development testing are initially performed to identify the optimum technology and the optimum operational approach. The success of this development program depends on the accuracy of the system interfaces. The critical interfaces include the specific operational environment, the composition of the waste stream to be processed and the quality of the product. Once the development program is complete, a detailed system schematic is built based on the specific design requirements, followed by component procurement, assembly, and acceptance testing. A successful acceptance test again depends on accurately simulating the anticipated environment on ISS. The ISS Water Recovery System (WRS) provides an excellent example of where this process worked, as well as lessons learned that can be applied to the success of future missions. More importantly, ISS has provided a test bed to identify these design issues. Mechanical design issues have included an unreliable harmonic drive train in the Urine Processor's fluids pump, and seals in the Water Processor's Catalytic Reactor with insufficient life at the operational temperature. Systems issues have included elevated calcium in crew urine (due to microgravity effect) that resulted in precipitation at the desired water recovery rate, and the presence of an organosilicon compound (dimethylsilanediol) in the condensate that is not well removed by the water treatment process. Modifications to the WRS to address these issues are either complete (and now being evaluated on ISS) or are currently in work to insure the WRS has the required reliability before embarking on a mission to Mars.

Carter, Layne↗

NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

NASA NTRS1994

SIGMA: A Knowledge-Based Simulation Tool Applied to Ecosystem Modeling

The need for better technology to facilitate building, sharing and reusing models is generally recognized within the ecosystem modeling community. The Scientists' Intelligent Graphical Modelling Assistant (SIGMA) creates an environment for model building, sharing and reuse which provides an alternative to more conventional approaches which too often yield poorly documented, awkwardly structured model code. The SIGMA interface presents the user a list of model quantities which can be selected for computation. Equations to calculate the model quantities may be chosen from an existing library of ecosystem modeling equations, or built using a specialized equation editor. Inputs for dim equations may be supplied by data or by calculation from other equations. Each variable and equation is expressed using ecological terminology and scientific units, and is documented with explanatory descriptions and optional literature citations. Automatic scientific unit conversion is supported and only physically-consistent equations are accepted by the system. The system uses knowledge-based semantic conditions to decide which equations in its library make sense to apply in a given situation, and supplies these to the user for selection. "Me equations and variables are graphically represented as a flow diagram which provides a complete summary of the model. Forest-BGC, a stand-level model that simulates photosynthesis and evapo-transpiration for conifer canopies, was originally implemented in Fortran and subsequenty re-implemented using SIGMA. The SIGMA version reproduces daily results and also provides a knowledge base which greatly facilitates inspection, modification and extension of Forest-BGC.

Dungan, Jennifer L.↗

NASA NTRS2004

Activity-Centric Approach to Distributed Programming

The first phase of an effort to develop a NASA version of the Cybele software system has been completed. To give meaning to even a highly abbreviated summary of the modifications to be embodied in the NASA version, it is necessary to present the following background information on Cybele: Cybele is a proprietary software infrastructure for use by programmers in developing agent-based application programs [complex application programs that contain autonomous, interacting components (agents)]. Cybele provides support for event handling from multiple sources, multithreading, concurrency control, migration, and load balancing. A Cybele agent follows a programming paradigm, called activity-centric programming, that enables an abstraction over system-level thread mechanisms. Activity centric programming relieves application programmers of the complex tasks of thread management, concurrency control, and event management. In order to provide such functionality, activity-centric programming demands support of other layers of software. This concludes the background information. In the first phase of the present development, a new architecture for Cybele was defined. In this architecture, Cybele follows a modular service-based approach to coupling of the programming and service layers of software architecture. In a service-based approach, the functionalities supported by activity-centric programming are apportioned, according to their characteristics, among several groups called services. A well-defined interface among all such services serves as a path that facilitates the maintenance and enhancement of such services without adverse effect on the whole software framework. The activity-centric application-program interface (API) is part of a kernel. The kernel API calls the services by use of their published interface. This approach makes it possible for any application code written exclusively under the API to be portable for any configuration of Cybele.

Levy, Renato↗

NASA NTRS1994

Thermo-Oxidative Stability of Graphite/PMR-15 Composites: Effect of Fiber Surface Modification on Composite Shear Properties

Experiments were conducted to establish a correlation between the weight loss of a polyimide (PMR- 15) matrix and graphite fibers and the in-plane shear properties of their unidirectional composites subjected to different isothermal aging times up to 1000 hr at 316 C. The role of fiber surface treatment on the composite degradation during the thermo-oxidative aging was investigated by using A4 graphite fibers with three surface modifications: untreated (AU-4), surface treated (AS-4), and surface treated and sized with an epoxy-compatible sizing (AS-4G). The weight loss of the matrix fibers, and composites was determined during the aging. The effect of thermal aging was seen in all the fiber samples in terms of weight loss and reduction in fiber diameter. Calculated values of weight loss fluxes for different surfaces of rectangular unidirectional composite plates showed that the largest weight loss occurred at those cut surfaces where fibers were perpendicular to the surface. Consequently, the largest amount of damage was also noted on these cut surfaces. Optical observation of the neat matrix and composite plates subjected to different aging times revealed that the degradation (such as matrix microcracking and void growth) occurred in a thin surface layer near the specimen edges. The in-plane shear modulus of the composites was unaffected by the fiber surface treatment and the thermal aging. The shear strength of the composites with the untreated fibers was the lowest and it decreased with aging. A fracture surface examination of the composites with untreated fibers suggested that the weak interface allowed the oxidation reaction to proceed along the interface and thus expose the inner material to further oxidation. The results indicated that the fiber-matrix interface affected the composite degradation process during its thermal aging and that the the weak interface accelerated the composite degradation.

Madhukar, Madhu S.↗

NASA NTRS2012

James Webb Space Telescope Integrated Science Instrument Module Calibration and Verification of High-Accuracy Instrumentation to Measure Heat Flow in Cryogenic Testing

The James Webb Space Telescope (JWST) is an upcoming flagship observatory mission scheduled to be launched in 2018. Three of the four science instruments are passively cooled to their operational temperature range of 36K to 40K, and the fourth instrument is actively cooled to its operational temperature of approximately 6K. The requirement for multiple thermal zoned results in the instruments being thermally connected to five external radiators via individual high purity aluminum heat straps. Thermal-vacuum and thermal balance testing of the flight instruments at the Integrated Science Instrument Module (ISIM) element level will take place within a newly constructed shroud cooled by gaseous helium inside Goddard Space Flight Center's (GSFC) Space environment Simulator (SES). The flight external radiators are not available during ISIM-level thermal vacuum/thermal testing, so they will be replaced in test with stable and adjustable thermal boundaries with identical physical interfaces to the flight radiators. Those boundaries are provided by specially designed test hardware which also measures the heat flow within each of the five heat straps to an accuracy of less than 2 mW, which is less than 5% of the minimum predicted heat flow values. Measurement of the heat loads to this accuracy is essential to ISIM thermal model correlation, since thermal models are more accurately correlated when temperature data is supplemented by accurate knowledge of heat flows. It also provides direct verification by test of several high-level thermal requirements. Devices that measure heat flow in this manner have historically been referred to a "Q-meters". Perhaps the most important feature of the design of the JWST Q-meters is that it does not depend on the absolute accuracy of its temperature sensors, but rather on knowledge of precise heater power required to maintain a constant temperature difference between sensors on two stages, for which a table is empirically developed during a calibration campaign in a small chamber at GSFC. This paper provides a brief review of Q-meter design, and discusses the Q-meter calibration procedure including calibration chamber modifications and accommodations, handling of differing conditions between calibration and usage, the calibration process itself, and the results of the tests used to determine if the calibration is successful.

Comber, Brian↗

NASA NTRSDate not supplied

Biological Insights at the Interface of Multiple Arabidopsis Legacy Datasets

The NASA GeneLab database includes an open-access collection of datasets yielded by space biology experiments. Six Gene Lab Data Sets (GLDS’s) performed in Arabidopsis were selected for analysis (7/17/44/121/205/213), all of which included transcriptome data from spaceflight and ground control environments. Hardware, ecotype, environmental conditions, and other experimental conditions varied, allowing the observations of overarching gene expression impacts of microgravity on plant life without focusing on effects of specific experimental conditions. Using GeneLab pre-processed datasets as the basis for the study, RNA microarray data were analyzed to identify genes that showed altered expression in microgravity when compared to control samples for each individual GLDS. All differentially expressed genes were compared to locate differentially expressed genes common between spaceflight experiments. The most noteworthy result is that not one gene shared differential expression among the six GLDS’s. However, gene expression was not influenced randomly by the microgravity environment, as there were several gene ontology terms that were significantly enriched across all experiments. These included 20 significantly enriched biological processes, and although the genes which enriched each term varied, there were many cases of specific genes common to clusters of multiple GLDS’s. Gene expression such as NAC92 and ERF011 or membrane structural element FFP6 provide insight and direction toward understanding the plant response to spaceflight. Characterizing these common processes and the shared differentially expressed genes has demonstrated potential targets for further study to understand and modulate the biological response of plants in microgravity. Life on Earth has never been subjected to the absence of gravity as a selective pressure, so observing how life forms react to a microgravity environment could provide insight to our shared fundamental biological processes. It is also feasible that the genetic modification of specific genes linked to the microgravity response could improve health and yield of space crops.

Joseph Emhof↗

NASA NTRSDate not supplied

A Crew and Logistics Lander for the Common Habitat Architecture

The Common Habitat Architecture is a conceptual study that explores the use of a large habitat derived from the Space Launch System (SLS) liquid oxygen tank as a core habitation element that can be used for crew missions or training in 0g, 1/6g, 3/8g, and 1g. This is not part of current NASA Artemis mission planning, but instead represents an architecture that could potentially follow after the Artemis missions and initial human Mars landings. This architecture leverages Starship-derived vehicles for crew landing on and ascent from the Moon and Mars in support of long-duration surface missions with pressurized crew transfer baselined as a nominal capability. This is not the Human Landing System variant of Starship but represents a number of modifications to enable long-duration surface missions with an eight-person crew size. A rapid brainstorming study was conducted in February of 2021, using only public data, to identify options to deliver the 90-ton Common Habitat to the surface and emplace it at the intended habitation site. This study compared three lunar lander concepts and three Mars lander concepts before ultimately selecting the SpaceX Starship as the most viable lander. The Common Habitat Architecture assumes that this Starship variant can further be modified for crew and cargo delivery, assuming that the use of a common system will lead to cost benefits. It is assumed that the Starship will expend too much propellant in landing crew and logistics to be able to launch, given the assumed absence of surface propellant production. Consequently, a separable ascent stage is used for crew ascent. The pressurized elements of this modified Starship are discussed: Starship Ascent Module, Airlock, Transfer Tunnel, Pressurized Crew Transfer Module, and Logistics Modules. For each element, a description, dimensions, rough mass estimates, core capabilities, and design features are presented. Key mechanisms and internal structures of the starship are also discussed. This will include flame diverters for the ascend module, the orbital docking hatch, Pressurized Crew Transfer Module Garage door, Starship Ascent Module fairing, flame diverter blow-out panels, Pressurized Crew Transfer Module lift system, logistics module lift system, contingency crew ascent via the logistics module lift system, internal catwalks, and structural interfaces. Concept of Operations will be discussed for both Moon and Mars. This will include in-space crew rendezvous and transfer, crewed landing, shirtsleeve crew transfer, crew departure, contingency surface operations, and final element disposition. Key differences for Mars will be discussed, such as the Martian atmosphere, dust storms, the absence of crew handover, and Deep Space Exploration Vehicle rendezvous. Contingency microgravity maintenance access will also be discussed. This work will demonstrate viable pressurized crew transfer with a Starship-based lander architecture. Forward work includes Garage lighting and camera systems, Starship Ascent Module propulsion system and docking port trades, contingency habitation trades, and mass/power equipment estimation. Finally, forward work includes developing a heavy cargo return system derived from the Crew and Logistics Starship. The goal of this system is the return of at least 10,000 kg payloads from the surfaces of the Moon and Mars.

Lunar Lander↗

NASA NTRS2006

CAPRI: A Geometric Foundation for Computational Analysis and Design

CAPRI is a software building tool-kit that refers to two ideas; (1) A simplified, object-oriented, hierarchical view of a solid part integrating both geometry and topology definitions, and (2) programming access to this part or assembly and any attached data. A complete definition of the geometry and application programming interface can be found in the document CAPRI: Computational Analysis PRogramming Interface appended to this report. In summary the interface is subdivided into the following functional components: 1. Utility routines -- These routines include the initialization of CAPRI, loading CAD parts and querying the operational status as well as closing the system down. 2. Geometry data-base queries -- This group of functions allow all top level applications to figure out and get detailed information on any geometric component in the Volume definition. 3. Point queries -- These calls allow grid generators, or solvers doing node adaptation, to snap points directly onto geometric entities. 4. Calculated or geometrically derived queries -- These entry points calculate data from the geometry to aid in grid generation. 5. Boundary data routines -- This part of CAPRI allows general data to be attached to Boundaries so that the boundary conditions can be specified and stored within CAPRI s data-base. 6. Tag based routines -- This part of the API allows the specification of properties associated with either the Volume (material properties) or Boundary (surface properties) entities. 7. Geometry based interpolation routines -- This part of the API facilitates Multi-disciplinary coupling and allows zooming through Boundary Attachments. 8. Geometric creation and manipulation -- These calls facilitate constructing simple solid entities and perform the Boolean solid operations. Geometry constructed in this manner has the advantage that if the data is kept consistent with the CAD package, therefore a new design can be incorporated directly and is manufacturable. 9. Master Model access This addition to the API allows for the querying of the parameters and dimensions of the model. The feature tree is also exposed so it is easy to see where the parameters are applied. Calls exist to allow for the modification of the parameters and the suppression/unsuppression of nodes in the tree. Part regeneration is performed by a single API call and a new part becomes available within CAPRI (if the regeneration was successful). This is described in a separate document. Components 1-7 are considered the CAPRI base level reader.

Haimes, Robert↗