Results for “HARDWARE” — Page 4

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

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↗

DOE OSTI2022

DFSynthesizer: Dataflow-based Synthesis of Spiking Neural Networks to Neuromorphic Hardware

Spiking Neural Networks (SNNs) are an emerging computation model that uses event-driven activation and bio-inspired learning algorithms. SNN-based machine learning programs are typically executed on tile-based neuromorphic hardware platforms, where each tile consists of a computation unit called a crossbar, which maps neurons and synapses of the program. However, synthesizing such programs on an off-the-shelf neuromorphic hardware is challenging. This is because of the inherent resource and latency limitations of the hardware, which impact both model performance, e.g., accuracy, and hardware performance, e.g., throughput. We propose DFSynthesizer, an end-to-end framework for synthesizing SNN-based machine learning programs to neuromorphic hardware. The proposed framework works in four steps. First, it analyzes a machine learning program and generates SNN workload using representative data. Second, it partitions the SNN workload and generates clusters that fit on crossbars of the target neuromorphic hardware. Third, it exploits the rich semantics of the Synchronous Dataflow Graph (SDFG) to represent a clustered SNN program, allowing for performance analysis in terms of key hardware constraints such as number of crossbars, dimension of each crossbar, buffer space on tiles, and tile communication bandwidth. Finally, it uses a novel scheduling algorithm to execute clusters on crossbars of the hardware, guaranteeing hardware performance. We evaluate DFSynthesizer with 10 commonly used machine learning programs. Our results demonstrate that DFSynthesizer provides a much tighter performance guarantee compared to current mapping approaches.

Computer Science↗

NASA NTRS1999

Hardware

The full complement of EDOMP investigations called for a broad spectrum of flight hardware ranging from commercial items, modified for spaceflight, to custom designed hardware made to meet the unique requirements of testing in the space environment. In addition, baseline data collection before and after spaceflight required numerous items of ground-based hardware. Two basic categories of ground-based hardware were used in EDOMP testing before and after flight: (1) hardware used for medical baseline testing and analysis, and (2) flight-like hardware used both for astronaut training and medical testing. To ensure post-landing data collection, hardware was required at both the Kennedy Space Center (KSC) and the Dryden Flight Research Center (DFRC) landing sites. Items that were very large or sensitive to the rigors of shipping were housed permanently at the landing site test facilities. Therefore, multiple sets of hardware were required to adequately support the prime and backup landing sites plus the Johnson Space Center (JSC) laboratories. Development of flight hardware was a major element of the EDOMP. The challenges included obtaining or developing equipment that met the following criteria: (1) compact (small size and light weight), (2) battery-operated or requiring minimal spacecraft power, (3) sturdy enough to survive the rigors of spaceflight, (4) quiet enough to pass acoustics limitations, (5) shielded and filtered adequately to assure electromagnetic compatibility with spacecraft systems, (6) user-friendly in a microgravity environment, and (7) accurate and efficient operation to meet medical investigative requirements.

Source record↗

NASA NTRS2015

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

DOE OSTI2021

Operating Hardware Impact on the Heat Transfer Properties of Windows

Despite significant advancements in fenestration technology in the last two decades, the thermal transmittance of fenestration products is still significantly higher than that of walls. This corresponds to 60% of the total energy loss of a modern building envelope through the windows. Hence, further development and improvements of fenestration products are necessary. Increasingly stringent codes and standards for fenestration stimulate industry to work on improved solutions. Thus, it is crucial that assessment techniques are able to account for innovations accurately. The thermal effects of non-continuous hardware in window frames are currently ignored by international rating procedures. A preliminary investigation conducted by our team showed significant performance degradation in two of the three out-opening casement profiles caused by the presence of operating hardware. Frames with the structure made of vinyl and fiberglass consist of many air cavities that are penetrated by operating hardware made of highly conductive materials. In these frames, in order to have an accurate assessment, it may be required to employ three-dimensional modeling due to the convective nature of heat transfer within the cavities. However, in this study, we demonstrate that the three-dimensional (3D) effects of non-continuous hardware can be approximated accurately with simpler two-dimensional (2D) simulations. We then develop a simplified model based on weighted average capable of replacing the time- and computation-intensive 3D simulations with 2D simulations and validate it against market available frames and their corresponding hardware. Validation results show that our approximation technique results in discrepancies lower than 0.05 W/(m2K), or 3% of the total thermal transmittance. Thus, we conclude that simplified 2D simulation models may be used for predicting hardware impact in window frames with reasonable accuracy. As windows and glazing structures are becoming ever better thermally insulated, it is becoming even more important to be able to model the impact of the operating hardware on the total thermal performance in order to design the best windows possible and not let the operating hardware ruin an otherwise well-proven design, which is hence addressed in this study.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

DOE OSTI2019

Orthopedic metallic hardware in routine abdomino-pelvic CT scans: occurrence and clinical significance

Purpose: To study the occurrence of orthopedic metallic hardware in routine abdomen/pelvic computed tomography (CT) scans and their impact on image quality (IQ) and diagnostic evaluation. Material and methods: In this retrospective single institution study, we analyzed 3500 consecutive abdomen/pelvis CT scans for occurrence of orthopedic metallic hardware. In the cohort of patients with metallic hardware detected on CT scans, subjective and objective IQ analysis was performed to estimate diagnostic acceptability (DA, 4-point scale), subjective noise (SN, 3-point scale), presence of artifacts (PA, 4-point scale) and objective noise. The clinical significance of metallic hardware was determined by evaluating the impact of artifacts on radiological diagnosis according to the clinical indication and disease type. Results: Orthopedic metallic hardware was encountered in 4.97% of abdomino-pelvic CT scans (n = 174/3500), and artifacts related to the hardware in the region of clinical interest were identified in 82% (n = 144/174) of scans. The overall mean DA was 2.66 (n = 174), and it was severely limited (score < 2) in 32% of cases particularly affecting patients with bilateral hip implants (92.6%, n = 25/27). The artifacts due to hardware significantly limited diagnostic evaluation in 58.6% of cases (PA score ≥ 3), and the image noise was unacceptable in 71% of cases (SN score > 2) in the region of clinical interest. Conclusion: Orthopedic metallic hardware is encountered in nearly 5% of abdomino-pelvic CT scans and causes significant image degradation limiting diagnostic evaluation in the region of clinical interest.

62 RADIOLOGY AND NUCLEAR MEDICINE↗

NASA NTRS1992

A novel visual hardware behavioral language

Most hardware behavioral languages just use texts to describe the behavior of the desired hardware design. This is inconvenient for VLSI designers who enjoy using the schematic approach. The proposed visual hardware behavioral language has the ability to graphically express design information using visual parallel models (blocks), visual sequential models (processes) and visual data flow graphs (which consist of primitive operational icons, control icons, and Data and Synchro links). Thus, the proposed visual hardware behavioral language can not only specify hardware concurrent and sequential functionality, but can also visually expose parallelism, sequentiality, and disjointness (mutually exclusive operations) for the hardware designers. That would make the hardware designers capture the design ideas easily and explicitly using this visual hardware behavioral language.

Li, Xueqin↗

NASA NTRS2012

Cumulative Measurement Errors for Dynamic Testing of Space Flight Hardware

Located at the NASA Johnson Space Center in Houston, TX, the Six-Degree-of-Freedom Dynamic Test System (SDTS) is a real-time, six degree-of-freedom, short range motion base simulator originally designed to simulate the relative dynamics of two bodies in space mating together (i.e., docking or berthing). The SDTS has the capability to test full scale docking and berthing systems utilizing a two body dynamic docking simulation for docking operations and a Space Station Remote Manipulator System (SSRMS) simulation for berthing operations. The SDTS can also be used for nonmating applications such as sensors and instruments evaluations requiring proximity or short range motion operations. The motion base is a hydraulic powered Stewart platform, capable of supporting a 3,500 lb payload with a positional accuracy of 0.03 inches. The SDTS is currently being used for the NASA Docking System testing and has been also used by other government agencies. The SDTS is also under consideration for use by commercial companies. Examples of tests include the verification of on-orbit robotic inspection systems, space vehicle assembly procedures and docking/berthing systems. The facility integrates a dynamic simulation of on-orbit spacecraft mating or de-mating using flight-like mechanical interface hardware. A force moment sensor is used for input during the contact phase, thus simulating the contact dynamics. While the verification of flight hardware presents unique challenges, one particular area of interest involves the use of external measurement systems to ensure accurate feedback of dynamic contact. The measurement systems for the test facility have two separate functions. The first is to take static measurements of facility and test hardware to determine both the static and moving frames used in the simulation and control system. The test hardware must be measured after each configuration change to determine both sets of reference frames. The second function is to take dynamic measurements during hardware motion and contact. While performing dynamic testing of an active docking system, researchers found that the data from the motion platform, test hardware and two external measurement systems exhibited frame offsets and rotational errors. While the errors were relatively small when considering the motion scale overall, they substantially exceeded the individual accuracies for each component. After evaluating both the static and dynamic measurements, researchers found that the static measurements introduced significantly more error into the system than the dynamic measurements even though, in theory, the static measurement errors should be smaller than the dynamic. In several cases, the magnitude of the errors varied widely for the static measurements. Upon further investigation, researchers found the larger errors to be a consequence of hardware alignment issues, frame location and measurement technique whereas the smaller errors were dependent on the number of measurement points. This paper details and quantifies the individual and cumulative errors of the docking system and describes methods for reducing the overall measurement error. The overall quality of the dynamic docking tests for flight hardware verification was improved by implementing these error reductions.

Winnitoy, Susan↗

NASA NTRS2012

Use of CCSDS Packets Over SpaceWire to Control Hardware

For the Lunar Reconnaissance Orbiter, the Command and Data Handling subsystem consisted of several electronic hardware assemblies that were connected with SpaceWire serial links. Electronic hardware would be commanded/controlled and telemetry data was obtained using the SpaceWire links. Prior art focused on parallel data buses and other types of serial buses, which were not compatible with the SpaceWire and the core flight executive (CFE) software bus. This innovation applies to anything that utilizes both SpaceWire networks and the CFE software. The CCSDS (Consultative Committee for Space Data Systems) packet contains predetermined values in its payload fields that electronic hardware attached at the terminus of the SpaceWire node would decode, interpret, and execute. The hardware s interpretation of the packet data would enable the hardware to change its state/configuration (command) or generate status (telemetry). The primary purpose is to provide an interface that is compatible with the hardware and the CFE software bus. By specifying the format of the CCSDS packet, it is possible to specify how the resulting hardware is to be built (in terms of digital logic) that results in a hardware design that can be controlled by the CFE software bus in the final application

Haddad, Omar↗

NASA NTRS2014

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a Simulink(R) library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

numerical simulation↗

NASA NTRS2014

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (40,000 pound force thrust) (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a Simulink (R) library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

numerical simulation↗

NASA NTRS2015

A Modular Framework for Modeling Hardware Elements in Distributed Engine Control Systems

Progress toward the implementation of distributed engine control in an aerospace application may be accelerated through the development of a hardware-in-the-loop (HIL) system for testing new control architectures and hardware outside of a physical test cell environment. One component required in an HIL simulation system is a high-fidelity model of the control platform: sensors, actuators, and the control law. The control system developed for the Commercial Modular Aero-Propulsion System Simulation 40k (C-MAPSS40k) provides a verifiable baseline for development of a model for simulating a distributed control architecture. This distributed controller model will contain enhanced hardware models, capturing the dynamics of the transducer and the effects of data processing, and a model of the controller network. A multilevel framework is presented that establishes three sets of interfaces in the control platform: communication with the engine (through sensors and actuators), communication between hardware and controller (over a network), and the physical connections within individual pieces of hardware. This introduces modularity at each level of the model, encouraging collaboration in the development and testing of various control schemes or hardware designs. At the hardware level, this modularity is leveraged through the creation of a SimulinkR library containing blocks for constructing smart transducer models complying with the IEEE 1451 specification. These hardware models were incorporated in a distributed version of the baseline C-MAPSS40k controller and simulations were run to compare the performance of the two models. The overall tracking ability differed only due to quantization effects in the feedback measurements in the distributed controller. Additionally, it was also found that the added complexity of the smart transducer models did not prevent real-time operation of the distributed controller model, a requirement of an HIL system.

propulsion simulation↗

NASA NTRS2016

A Framework for Assessing the Reusability of Hardware (Reusable Rocket Engines)

Within the space flight community, reusability has taken center stage as the new buzzword. In order for reusable hardware to be competitive with its expendable counterpart, two major elements must be closely scrutinized. First, recovery and refurbishment costs must be lower than the development and acquisition costs. Additionally, the reliability for reused hardware must remain the same (or nearly the same) as "first use" hardware. Therefore, it is imperative that a systematic approach be established to enhance the development of reusable systems. However, before the decision can be made on whether it is more beneficial to reuse hardware or to replace it, the parameters that are needed to deem hardware worthy of reuse must be identified. For reusable hardware to be successful, the factors that must be considered are reliability (integrity, life, number of uses), operability (maintenance, accessibility), and cost (procurement, retrieval, refurbishment). These three factors are essential to the successful implementation of reusability while enabling the ability to meet performance goals. Past and present strategies and attempts at reuse within the space industry will be examined to identify important attributes of reusability that can be used to evaluate hardware when contemplating reusable versus expendable options. This paper will examine why reuse must be stated as an initial requirement rather than included as an afterthought in the final design. Late in the process, changes in the overall objective/purpose of components typically have adverse effects that potentially negate the benefits. A methodology for assessing the viability of reusing hardware will be presented by using the Space Shuttle Main Engine (SSME) to validate the approach. Because reliability, operability, and costs are key drivers in making this critical decision, they will be used to assess requirements for reuse as applied to components of the SSME.

Childress-Thompson, Rhonda↗

NASA NTRS2016

A Framework for Assessing the Reusability of Hardware (Reusable Rocket Engines)

Within the space flight community, reusability has taken center stage as the new buzzword. In order for reusable hardware to be competitive with its expendable counterpart, two major elements must be closely scrutinized. First, recovery and refurbishment costs must be lower than the development and acquisition costs. Additionally, the reliability for reused hardware must remain the same (or nearly the same) as "first use" hardware. Therefore, it is imperative that a systematic approach be established to enhance the development of reusable systems. However, before the decision can be made on whether it is more beneficial to reuse hardware or to replace it, the parameters that are needed to deem hardware worthy of reuse must be identified. For reusable hardware to be successful, the factors that must be considered are reliability (integrity, life, number of uses), operability (maintenance, accessibility), and cost (procurement, retrieval, refurbishment). These three factors are essential to the successful implementation of reusability while enabling the ability to meet performance goals. Past and present strategies and attempts at reuse within the space industry will be examined to identify important attributes of reusability that can be used to evaluate hardware when contemplating reusable versus expendable options. This paper will examine why reuse must be stated as an initial requirement rather than included as an afterthought in the final design. Late in the process, changes in the overall objective/purpose of components typically have adverse effects that potentially negate the benefits. A methodology for assessing the viability of reusing hardware will be presented by using the Space Shuttle Main Engine (SSME) to validate the approach. Because reliability, operability, and costs are key drivers in making this critical decision, they will be used to assess requirements for reuse as applied to components of the SSME.

Childress-Thompson, Rhonda↗

NASA NTRS2016

Terrestrial Sources of X-Ray Radiation and Their Effects on NASA Flight Hardware

X-rays are an energetic and penetrating form of ionizing electromagnetic radiation, which can degrade NASA flight hardware. The main concern posed by such radiation is degradation of active electronic devices and, in some cases, diodes. Non-electronic components are only damaged at doses that far exceed the point where any electronic device would be destroyed. For the purposes of this document, flight hardware can be taken to mean an entire instrument, the flight electronics within the instrument or the individual microelectronic devices in the flight electronics. This document will discuss and describe the ways in which NASA flight hardware might be exposed to x-rays, what is and isn't a concern, and how to tell the difference. First, we must understand what components in flight hardware may be vulnerable to degradation or failure as a result of being exposed to ionizing radiation, such as x-rays. As stated above, bulk materials (structural metals, plastics, etc.) are generally only affected by ionizing radiation at very high dose levels. Likewise, passive electronic components (e.g. resistors, capacitors, most diodes) are strongly resistant to exposure to x-rays, except at very high doses. The main concerns arise when active components, that is, components like discrete transistors and microelectronic devices, are exposed to ionizing radiation. Active components are designed to respond to minute changes in currents and voltages in the circuit. As such, it is not surprising that exposure to ionizing radiation, which creates ionized and therefore electrically active particles, may degrade the way the hardware performs. For the most part, the mechanism for this degradation is trapping of the charges generated by ionizing radiation by defects in dielectric materials in the hardware. As such, the degree of damage is a function of both the quantity of ionizing radiation exposure and the physical characteristics of the hardware itself. The metric that describes the level of exposure to ionizing radiation is total ionizing dose (TID). The unit of TID is the rad, which is defined as 100 ergs absorbed per gram of material. Dose can be expressed in other units, for example grays (gy), where 1 gy = 100 rads. The actual fluence of radiation needed to deliver a rad depends on the absorbing material, so units of dose are usually stated in reference to the material of interest. That is, for microelectronic devices, the unit of dose is generally rad (Si) or rad (SiO2). However, the definition of absorbed dose in this fashion has the advantage that the type of radiation causing the ionization can be normalized so that a realistic and adequate comparison can be made. The sensitivity of microelectronic parts to TID varies over many orders of magnitude. (Note: Doses to humans are typically expressed in rems-or roentgen-equivalent-man-which measures tissue damage, and depends on the type of radiation, as well as the dose in rads.) Thus far, the "softest" parts tested at NASA showed damage at 500 rads (Si), while parts that are radiation-hardened by design can remain functional to doses on the order of 107 rads (Si). This broad range of sensitivity highlights one of the most important considerations when considering the effects of radiation on electronic parts: In order to determine whether a radiation exposure is a concern for a particular part, one must understand the technologies used in the part and their vulnerabilities to TID damage. A NASA radiation expert should be consulted to obtain such information.

X-ray↗

NASA NTRS1998

Electronic processing and control system with programmable hardware

A computer system with reprogrammable hardware allowing dynamically allocating hardware resources for different functions and adaptability for different processors and different operating platforms. All hardware resources are physically partitioned into system-user hardware and application-user hardware depending on the specific operation requirements. A reprogrammable interface preferably interconnects the system-user hardware and application-user hardware.

Alkalaj, Leon↗

NASA NTRS2011

The Application of Acoustic Measurements and Audio Recordings for Diagnosis of In-Flight Hardware Anomalies

In many cases, an initial symptom of hardware malfunction is unusual or unexpected acoustic noise. Many industries such as automotive, heating and air conditioning, and petro-chemical processing use noise and vibration data along with rotating machinery analysis techniques to identify noise sources and correct hardware defects. The NASA/Johnson Space Center Acoustics Office monitors the acoustic environment of the International Space Station (ISS) through periodic sound level measurement surveys. Trending of the sound level measurement survey results can identify in-flight hardware anomalies. The crew of the ISS also serves as a "detection tool" in identifying unusual hardware noises; in these cases the spectral analysis of audio recordings made on orbit can be used to identify hardware defects that are related to rotating components such as fans, pumps, and compressors. In this paper, three examples of the use of sound level measurements and audio recordings for the diagnosis of in-flight hardware anomalies are discussed: identification of blocked inter-module ventilation (IMV) ducts, diagnosis of abnormal ISS Crew Quarters rack exhaust fan noise, and the identification and replacement of a defective flywheel assembly in the Treadmill with Vibration Isolation (TVIS) hardware. In each of these examples, crew time was saved by identifying the off nominal component or condition that existed and in directing in-flight maintenance activities to address and correct each of these problems.

Welsh, David↗