Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Avionics”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 631 records · Page 35

Comparison Modeling of System Reliability for Future NASA Projects

A National Aeronautics and Space Administration (NASA) supported Reliability, Maintainability, and Availability (RMA) analysis team developed a unique RMA analysis methodology using cut set and importance measure analysis in order to comparison model proposed avionics computing architectures. In this paper we will present this efficient application of the RMA analysis methodology for importance measures that includes Reliability Block Diagram (RED) Analysis, Comparison modeling, Cut Set Analysis, and Importance Measure Analysis. We will also demonstrate that integrating RMA early in the system design process as a key to success by providing a fundamental decision metric supporting design selection. The RMA analysis methodology presented in this paper and applied to the avionics architectures enhances the usual way of predicting the need for redundancy based on failure rates or subject matter expert opinion. Using the REDs and the minimal cut sets, along with the Fussell-Vesely (FV) factors, importance measures are calculated for each functional element in the architectures. This paper presents an application of the FV importance measures and presents an improved methodology for using importance measures in success space (instead of failure space) to compare architectures. These importance measures are used to determine which functional element would be most likely to cause a system failure, thus, quickly identifying the path to increase the overall system reliability by either procuring more reliable functional elements or adding redundancy. This application of the RMA analysis methodology, using RBD analysis, cut set analysis, and the importance measure analysis, allows the avionics design team to better understand and compare the vulnerabilities in each of the architectures, enabling them to address the deficiencies in the design architectures more efficiently, while balancing the need to design for optimum weight and space allocations.

Gillespie, Amanda M.↗

Network Extender for MIL-STD-1553 Bus

An extender system for MIL-STD-1553 buses transparently couples bus components at multiple developer sites. The bus network extender is a relatively inexpensive system that minimizes the time and cost of integration of avionic systems by providing a convenient mechanism for early testing without the need to transport the usual test equipment and personnel to an integration facility. This bus network extender can thus alleviate overloading of the test facility while enabling the detection of interface problems that can occur during the integration of avionic systems. With this bus extender in place, developers can correct and adjust their own hardware and software before products leave a development site. Currently resident at Johnson Space Center, the bus network extender is used to test the functionality of equipment that, although remotely located, is connected through a MILSTD- 1553 bus. Inasmuch as the standard bus protocol for avionic equipment is that of MIL-STD-1553, companies that supply MIL-STD-1553-compliant equipment to government or industry and that need long-distance communication support might benefit from this network bus extender

Marcus, Julius↗

High-Performance 3D Articulated Robot Display

In the domain of telerobotic operations, the primary challenge facing the operator is to understand the state of the robotic platform. One key aspect of understanding the state is to visualize the physical location and configuration of the platform. As there is a wide variety of mobile robots, the requirements for visualizing their configurations vary diversely across different platforms. There can also be diversity in the mechanical mobility, such as wheeled, tracked, or legged mobility over surfaces. Adaptable 3D articulated robot visualization software can accommodate a wide variety of robotic platforms and environments. The visualization has been used for surface, aerial, space, and water robotic vehicle visualization during field testing. It has been used to enable operations of wheeled and legged surface vehicles, and can be readily adapted to facilitate other mechanical mobility solutions. The 3D visualization can render an articulated 3D model of a robotic platform for any environment. Given the model, the software receives real-time telemetry from the avionics system onboard the vehicle and animates the robot visualization to reflect the telemetered physical state. This is used to track the position and attitude in real time to monitor the progress of the vehicle as it traverses its environment. It is also used to monitor the state of any or all articulated elements of the vehicle, such as arms, legs, or control surfaces. The visualization can also render other sorts of telemetered states visually, such as stress or strains that are measured by the avionics. Such data can be used to color or annotate the virtual vehicle to indicate nominal or off-nominal states during operation. The visualization is also able to render the simulated environment where the vehicle is operating. For surface and aerial vehicles, it can render the terrain under the vehicle as the avionics sends it location information (GPS, odometry, or star tracking), and locate the vehicle over or on the terrain correctly. For long traverses over terrain, the visualization can stream in terrain piecewise in order to maintain the current area of interest for the operator without incurring unreasonable resource constraints on the computing platform. The visualization software is designed to run on laptops that can operate in field-testing environments without Internet access, which is a frequently encountered situation when testing in remote locations that simulate planetary environments such as Mars and other planetary bodies.

Powell, Mark W.↗

How to Extend the Capabilities of Space Systems for Long Duration Space Exploration Systems

For sustainable Exploration Missions the need exists to assemble systems-of-systems in space, on the Moon or on other planetary surfaces. To fulfill this need new and innovative system architecture is needed that can be satisfied with the present lift capability of existing rocket technology without the added cost of developing a new heavy lift vehicle. To enable ultra-long life missions with minimum redundancy and lighter mass the need exists to develop system soft,i,are and hardware reconfigurability, which enables increasing functionality and multiple use of launched assets while at the same time overcoming any components failures. Also the need exists to develop the ability to dynamically demate and reassemble individual system elements during a mission in order to work around failed hardware or changed mission requirements. Therefore to meet the goals of Space Exploration Missions in hiteroperability and Reconfigurability, many challenges must be addressed to transform the traditional static avionics architecture into architecture with dynamic capabilities. The objective of this paper is to introduce concepts associated with reconfigurable computer systems; review the various needs and challenges associated with reconfigurable avionics space systems; provide an operational example that illustrates the needs applicable to either the Crew Exploration Vehicle or a collection of "Habot like" mobile surface elements; summarize the approaches that address key challenges to acceptance of a Flexible, Intelligent, Modular and Affordable reconfigurable avionics space system.

Marzwell, Neville I.↗

Multiplexer/Demultiplexer Loading Tool (MDMLT)

The purpose of the MDMLT is to improve the reliability and speed of loading multiplexers/demultiplexers (MDMs) in the Software Development and Integration Laboratory (SDIL) by automating the configuration management (CM) of the loads in the MDMs, automating the loading procedure, and providing the capability to load multiple or all MDMs concurrently. This loading may be accomplished in parallel, or single MDMs (remote). The MDMLT is a Web-based tool that is capable of loading the entire International Space Station (ISS) MDM configuration in parallel. It is able to load Flight Equivalent Units (FEUs), enhanced, standard, and prototype MDMs as well as both EEPROM (Electrically Erasable Programmable Read-Only Memory) and SSMMU (Solid State Mass Memory Unit) (MASS Memory). This software has extensive configuration management to track loading history, and the performance improvement means of loading the entire ISS MDM configuration of 49 MDMs in approximately 30 minutes, as opposed to 36 hours, which is what it took previously utilizing the flight method of S-Band uplink. The laptop version recently added to the MDMLT suite allows remote lab loading with the CM of information entered into a common database when it is reconnected to the network. This allows the program to reconfigure the test rigs quickly between shifts, allowing the lab to support a variety of onboard configurations during a single day, based on upcoming or current missions. The MDMLT Computer Software Configuration Item (CSCI) supports a Web-based command and control interface to the user. An interface to the SDIL File Transfer Protocol (FTP) server is supported to import Integrated Flight Loads (IFLs) and Internal Product Release Notes (IPRNs) into the database. An interface to the Monitor and Control System (MCS) is supported to control the power state, and to enable or disable the debug port of the MDMs to be loaded. Two direct interfaces to the MDM are supported: a serial interface (debug port) to receive MDM memory dump data and the calculated checksum, and the Small Computer System Interface (SCSI) to transfer load files to MDMs with hard disks. File transfer from the MDM Loading Tool to EEPROM within the MDM is performed via the MILSTD- 1553 bus, making use of the Real- Time Input/Output Processors (RTIOP) when using the rig-based MDMLT, and via a bus box when using the laptop MDMLT. The bus box is a cost-effective alternative to PC-1553 cards for the laptop. It is noted that this system can be modified and adapted to any avionic laboratory for spacecraft computer loading, ship avionics, or aircraft avionics where multiple configurations and strong configuration management of software/firmware loads are required.

Brewer, Lenox Allen↗

Traffic Aware Planner (TAP) Flight Evaluation

NASA's Traffic Aware Planner (TAP) is a cockpit decision support tool that has the potential to achieve significant fuel and time savings when it is embedded in the data-rich Next Generation Air Transportation System (NextGen) airspace. To address a key step towards the operational deployment of TAP and the NASA concept of Traffic Aware Strategic Aircrew Requests (TASAR), a system evaluation was conducted in a representative flight environment in November, 2013. Numerous challenges were overcome to achieve this goal, including the porting of the foundational Autonomous Operations Planner (AOP) software from its original simulation-based, avionics-embedded environment to an Electronic Flight Bag (EFB) platform. A flight-test aircraft was modified to host the EFB, the TAP application, an Automatic Dependent Surveillance Broadcast (ADS-B) processor, and a satellite broadband datalink. Nine Evaluation Pilots conducted 26 hours of TAP assessments using four route profiles in the complex eastern and north-eastern United States airspace. Extensive avionics and video data were collected, supplemented by comprehensive inflight and post-flight questionnaires. TAP was verified to function properly in the live avionics and ADS-B environment, characterized by recorded data dropouts, latency, and ADS-B message fluctuations. Twelve TAP-generated optimization requests were submitted to ATC, of which nine were approved, and all of which resulted in fuel and/or time savings. Analysis of subjective workload data indicated that pilot interaction with TAP during flight operations did not induce additional cognitive loading. Additionally, analyses of post-flight questionnaire data showed that the pilots perceived TAP to be useful, understandable, intuitive, and easy to use. All program objectives were met, and the next phase of TAP development and evaluations with partner airlines is in planning for 2015.

Maris, John M.↗

SCaN Testbed Software Development and Lessons Learned

National Aeronautics and Space Administration (NASA) has developed an on-orbit, adaptable, Software Defined Radio (SDR)Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The SCAN Testbed Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, SDR platforms and the STRS Architecture.The SDRs are a new technology for NASA, and the support infrastructure they require is different from legacy, fixed function radios. SDRs offer the ability to reconfigure on-orbit communications by changing software for new waveforms and operating systems to enable new capabilities or fix any anomalies, which was not a previous option. They are not stand alone devices, but required a new approach to effectively control them and flow data. This requires extensive software to be developed to utilize the full potential of these reconfigurable platforms. The paper focuses on development, integration and testing as related to the avionics processor system, and the software required to command, control, monitor, and interact with the SDRs, as well as the other communication payload elements. An extensive effort was required to develop the flight software and meet the NASA requirements for software quality and safety. The flight avionics must be radiation tolerant, and these processors have limited capability in comparison to terrestrial counterparts. A big challenge was that there are three SDRs onboard, and interfacing with multiple SDRs simultaneously complicatesd the effort. The effort also includes ground software, which is a key element for both the command of the payload, and displaying data created by the payload. The verification of the software was an extensive effort. The challenges of specifying a suitable test matrix with reconfigurable systems that offer numerous configurations is highlighted. Since the flight system testing requires methodical, controlled testing that limits risk, a nearly identical ground system to the on-orbit flight system was required to develop the software and write verification procedures before it was installed and tested on the flight system. The development of the SCAN testbed was an accelerated effort to meet launch constraints, and this paper discusses tradeoffs made to balance needed software functionality and still maintain the schedule. Future upgrades are discussed that optimize the avionics and allow experimenters to utilize the SCAN testbed potential.

radio communication↗

On TTEthernet for Integrated Fault-Tolerant Spacecraft Networks

There has recently been a push for adopting integrated modular avionics (IMA) principles in designing spacecraft architectures. This consolidation of multiple vehicle functions to shared computing platforms can significantly reduce spacecraft cost, weight, and de- sign complexity. Ethernet technology is attractive for inclusion in more integrated avionic systems due to its high speed, flexibility, and the availability of inexpensive commercial off-the-shelf (COTS) components. Furthermore, Ethernet can be augmented with a variety of quality of service (QoS) enhancements that enable its use for transmitting critical data. TTEthernet introduces a decentralized clock synchronization paradigm enabling the use of time-triggered Ethernet messaging appropriate for hard real-time applications. TTEthernet can also provide two forms of event-driven communication, therefore accommodating the full spectrum of traffic criticality levels required in IMA architectures. This paper explores the application of TTEthernet technology to future IMA spacecraft architectures as part of the Avionics and Software (A&S) project chartered by NASA's Advanced Exploration Systems (AES) program.

Loveless, Andrew↗

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.↗

Design and Development of a Rapid Research, Design, and Development Platform for In-Situ Testing of Tools and Concepts for Trajectory-Based Operations

To provide justification for equipping a fleet of aircraft with avionics capable of supporting trajectory-based operations, significant flight testing must be accomplished. However, equipping aircraft with these avionics and enabling technologies to communicate the clearances required for trajectory-based operations is cost-challenging using conventional avionics approaches. This paper describes an approach to minimize the costs and risks of flight testing these technologies in-situ, discusses the test-bed platform developed, and highlights results from a proof-of-concept flight test campaign that demonstrates the feasibility and efficiency of this approach.

Underwood, Matthew C.↗

UAS Autonomous Hazard Mitigation through Assured Compliance with Conformance Criteria

The behavior of a drone depends on the integrity of the data it uses and the reliability of the avionics systems that process that data to affect the operation of the aircraft. Commercial unmanned aircraft systems frequently rely on commercial-off-the-shelf and open source avionics components and data sources whose reliability and integrity are not easily assured. To mitigate failure events for aircraft that do not comply with conventional aviation safety standards, operational limitations are typically prescribed by regulators. Part 107 of the Federal Aviation Regulations serves as a good example of operational limitations that mitigate risk for small unmanned aircraft systems. These limitations, however, restrict growth possibilities for the industry. Any reasonable path toward achieving routine operation of all types of drones will have to address the need for assurance of avionics systems, especially their software. This paper discusses the possibility of strategically using assured systems as a stepping stone to routine operation of drones. A specimen system for assured geofencing, called Safeguard, is described as an example of such a stepping stone.

Dill, Evan, T.↗

MUSTANG Applications

Reducing nonrecurring cost and shortening the build schedule for space qualified avionics has been a recurring theme in Space Industry. The NASA Goddard Space Flight Center has leverage its heritage flight qualified design and developed a portfolio of modular avionics comprised of 22 different board designs in a form factor named MUSTANG (Modular Unified Space Technology Avionics for Next Generation) that can be utilized in a variety flight applications. Since the design has no backplane, the modules can be mixed and match to meet the needed requirements. The MUSTANG form factor is sized to fill the void between 3U and 6U form factor and with flexibility to adapting the design without relaying out the boards.

Space↗

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↗

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↗

Prototype Demonstration of Solar-Carbothermal System to Extract Oxygen From Regolith

The Carbothermal Reduction Demonstration (CaRD) project was an effort to develop a prototype system to demonstrate the extraction of oxygen from simulated lunar regolith using concentrated solar energy and a carbothermal reaction. The prototype consisted of a deployable solar concentrator capable of tracking the sun, carbothermal reactor, fluid system, gas analysis, and a solar concentrator control system consisting of avionics and software. These subsystems were developed by multiple NASA centers and a private industry partner, Sierra Space. The various teams worked together to define requirements and interfaces to successfully assemble the complex system and demonstrate an integrated solar carbothermal process. The solar concentrator developed at Glenn Research Center (GRC) was designed to be stowed for a launch environment then deployed on the lunar surface. It utilized a crossed dragone configuration of composite mirrors to direct horizontal sunlight onto a target 90° from the incoming sunlight. The key performance parameters for the solar concentrator were efficiency and power density. The carbothermal reactor was developed by Sierra Space through a separate project called the Carbothermal Oxygen Production Reactor (COPR) where it successfully demonstrated a fully automated process in a thermal vacuum environment [1]. The fluid system needed for the carbothermal reaction was also developed by Sierra Space and successfully demonstrated in the same thermal vacuum test. The gas analysis system was developed at Kennedy Space Center (KSC) and was required to determine the amount of oxygen extracted during each test. The gas analysis system was based on the Mass Spectrometer Observing Lunar Operations (MSOLO) instrument. Avionics and software for the CaRD prototype were also developed at KSC and based on experience with MSOLO avionics and software. The control system was designed to stow, deploy, track the sun, and perform beam alignment of the concentrated light. The prototype subsystems were integrated and tested at Johnson Space Center’s (JSC) Energy Systems Test Area. A heliostat was used to direct sunlight toward the prototype in a way that is representative of the sunlight conditions at the south pole of the Moon. When concentrated sunlight was focused on simulated lunar regolith within the reactor, the gas analysis team confirmed the presence of carbon monoxide gas, which confirmed that a solar carbothermal reaction took place. The key performance parameter for the integrated prototype was grams of oxygen extracted per kilowatt hour of energy arriving at the concentrator primary mirror. The prototype design successfully demonstrated end-to-end capability and further steps to achieve a flight capable system have been defined. With lunar data, engineers would be able to design a scaled-up system capable of extracting oxygen from regolith at useful quantities for crew life support and rocket propellant. On the long term, this method of In-Situ Resource Utilization could be used to drastically reduce the cost and risk of a sustained human presence on the Moon by reducing the amount of oxygen that would have to be delivered.

Koorosh R Araghi↗

Prototype Demonstration of Solar Carbothermal System to Extract Oxygen from Regolith

The Carbothermal Reduction Demonstration (CaRD) project was an effort to develop a prototype system to demonstrate the extraction of oxygen from simulated lunar regolith using concentrated solar energy and a carbothermal reaction. The prototype consisted of a deployable solar concentrator capable of tracking the sun, carbothermal reactor, fluid system, gas analysis, and a solar concentrator control system consisting of avionics and software. These subsystems were developed by multiple NASA centers and a private industry partner, Sierra Space. The various teams worked together to define requirements and interfaces to successfully assemble the complex system and demonstrate an integrated solar carbothermal process. The solar concentrator developed at Glenn Research Center (GRC) was designed to be stowed for a launch environment then deployed on the lunar surface. It utilized a crossed dragone configuration of composite mirrors to direct horizontal sunlight onto a target 90° from the incoming sunlight. The key performance parameters for the solar concentrator were efficiency and power density. The carbothermal reactor was developed by Sierra Space through a separate project called the Carbothermal Oxygen Production Reactor (COPR) where it successfully demonstrated a fully automated process in a thermal vacuum environment. The fluid system needed for the carbothermal reaction was also developed by Sierra Space and successfully demonstrated in the same thermal vacuum test. The gas analysis system was developed at Kennedy Space Center (KSC) and was required to determine the amount of oxygen extracted during each test. The gas analysis system was based on the Mass Spectrometer Observing Lunar Operations (MSOLO) instrument. Avionics and software for the CaRD prototype were also developed at KSC and based on experience with MSOLO avionics and software. The control system was designed to stow, deploy, track the sun, and perform beam alignment of the concentrated light. The prototype subsystems were integrated and tested at Johnson Space Center’s (JSC) Energy Systems Test Area. A heliostat was used to direct sunlight toward the prototype in a way that is representative of the sunlight conditions at the south pole of the Moon. When concentrated sunlight was focused on simulated lunar regolith within the reactor, the gas analysis team confirmed the presence of carbon monoxide gas, which confirmed that a solar carbothermal reaction took place. The key performance parameter for the integrated prototype was grams of oxygen extracted per kilowatt hour of energy arriving at the concentrator primary mirror. The prototype design successfully demonstrated end-to-end capability and further steps to achieve a flight capable system have been defined. With lunar data, engineers would be able to design a scaled-up system capable of extracting oxygen from regolith at useful quantities for crew life support and rocket propellant. On the long term, this method of In-Situ Resource Utilization could be used to drastically reduce the cost and risk of a sustained human presence on the Moon by reducing the amount of oxygen that would have to be delivered.

Aaron Paz↗

Prototype Demonstration of an Integrated Solar Concentrator System and Carbothermal Reactor Using Solar Energy to Extract Oxygen from Regolith

The Carbothermal Reduction Demonstration (CaRD) project was an effort to develop a prototype system to demonstrate the extraction of oxygen from simulated lunar regolith using concentrated solar energy and a carbothermal reaction. The prototype consisted of a deployable solar concentrator capable of tracking the sun, carbothermal reactor, fluid system, gas analysis, and a solar concentrator control system consisting of avionics and software. These subsystems were developed by multiple NASA centers and a private industry partner, Sierra Space. The various teams worked together to define requirements and interfaces to successfully assemble the complex system and demonstrate an integrated solar carbothermal process. The solar concentrator developed at Glenn Research Center (GRC) was designed to be stowed for a launch environment then deployed on the lunar surface. It utilized a crossed dragone configuration of composite mirrors to direct horizontal sunlight onto a target 90° from the incoming sunlight. The key performance parameters for the solar concentrator were efficiency and power density. The carbothermal reactor was developed by Sierra Space through a separate project called the Carbothermal Oxygen Production Reactor (COPR) where it successfully demonstrated a fully automated process in a thermal vacuum environment. The fluid system needed for the carbothermal reaction was also developed by Sierra Space and successfully demonstrated in the same thermal vacuum test. The gas analysis system was developed at Kennedy Space Center (KSC) and was required to determine the amount of oxygen extracted during each test. The gas analysis system was based on the Mass Spectrometer Observing Lunar Operations (MSOLO) instrument. Avionics and software for the CaRD prototype were also developed at KSC and based on experience with MSOLO avionics and software. The control system was designed to stow, deploy, track the sun, and perform beam alignment of the concentrated light. The prototype subsystems were integrated and tested at Johnson Space Center’s (JSC) Energy Systems Test Area. A heliostat was used to direct sunlight toward the prototype in a way that is representative of the sunlight conditions at the south pole of the Moon. When concentrated sunlight was focused on simulated lunar regolith within the reactor, the gas analysis team confirmed the presence of carbon monoxide gas, which confirmed that a solar carbothermal reaction took place. The key performance parameter for the integrated prototype was grams of oxygen extracted per kilowatt hour of energy arriving at the concentrator primary mirror. The prototype design successfully demonstrated end-to-end capability and further steps to achieve a flight capable system have been defined. With lunar data, engineers would be able to design a scaled-up system capable of extracting oxygen from regolith at useful quantities for crew life support and rocket propellant. On the long term, this method of In-Situ Resource Utilization could be used to drastically reduce the cost and risk of a sustained human presence on the Moon by reducing the amount of oxygen that would have to be delivered.

Oxygen from Regolith↗

NAECON 87; Proceedings of the IEEE National Aerospace and Electronics Conference, Dayton, OH, May 18-22, 1987. Volumes 1, 2, 3, & 4

The present conference discusses topics in VLSI components and their packaging, signal processing, uses of cartographic data, data transmission, advanced avionics architectures, fiber-optics, information control and display, image processing, airborne radar and fire control, navigation, air data, Kalman filtering, power generation and control, spacecraft power structures, aircraft flying qualities, flight management, fault-tolerant computer architectures, actuation technologies, self-repairing flight control system technology, multivariable control, stability and control methods, and AFTI/F-16 flight test reports. Also discussed are the ADA/JOVIAL language and its applications, software acquisition and testing, advanced software concepts, software management, computer graphics and visual systems softwear, ADA in embedded avionics, 16- and 32-bit architectures, voice interaction applications, human/machine systems analysis, human factors and AI, mental workloads and displays, pilot acceleration protection research, communications system technology, space communications, reliability and maintainability, managerial techniques, engineering management, EM compatibility and nuclear hardening, expert systems, AI language/knowledge representation, expert system implementation, machine vision/optical processing, and advanced AI concepts and architectures.

Avionics↗