SEARCH · Search NASA
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.
This paper describes the Remote Agent flight experiment for spacecraft commanding and control. In the Remote Agen approach, the operational rules and constraints are encoded in the flight software, and the software may be considered to be an autonomous
Virtual Machine Language (VML) is a mission-independent, reusable software system for programming for spacecraft operations. Features of VML include a rich set of data types, named functions, parameters, IF and WHILE control structures, polymorphism, and on-the-fly creation of spacecraft commands from calculated values. Spacecraft functions can be abstracted into named blocks that reside in files aboard the spacecraft. These named blocks accept parameters and execute in a repeatable fashion. The sizes of uplink products are minimized by the ability to call blocks that implement most of the command steps. This block approach also enables some autonomous operations aboard the spacecraft, such as aerobraking, telemetry conditional monitoring, and anomaly response, without developing autonomous flight software. Operators on the ground write blocks and command sequences in a concise, high-level, human-readable programming language (also called VML ). A compiler translates the human-readable blocks and command sequences into binary files (the operations products). The flight portion of VML interprets the uplinked binary files. The ground subsystem of VML also includes an interactive sequence- execution tool hosted on workstations, which runs sequences at several thousand times real-time speed, affords debugging, and generates reports. This tool enables iterative development of blocks and sequences within times of the order of seconds.
Major hardware and software for NASA's Space Launch System (SLS) began rolling off assembly lines in 2016, setting the stage for critical testing in 2017 and the launch of a major new capability for deep space human exploration. SLS continues to pursue a 2018 first launch of Exploration Mission 1 (EM-1). At NASA's Michoud Assembly Facility near New Orleans, LA, Boeing completed welding of structural test and flight liquid hydrogen tanks, and engine sections. Test stands for core stage structural tests at NASA's Marshall Space Flight Center, Huntsville, AL. neared completion. The B2 test stand at NASA's Stennis Space Center, MS, completed major structural renovation to support core stage green run testing in 2018. Orbital ATK successfully test fired its second qualification solid rocket motor in the Utah desert and began casting the motor segments for EM-1. Aerojet Rocketdyne completed its series of test firings to adapt the heritage RS-25 engine to SLS performance requirements. Production is under way on the first five new engine controllers. NASA also signed a contract with Aerojet Rocketdyne for propulsion of the RL10 engines for the Exploration Upper Stage. United Launch Alliance delivered the structural test article for the Interim Cryogenic Propulsion Stage to MSFC for tests and construction was under way on the flight stage. Flight software testing at MSFC, including power quality and command and data handling, was completed. Substantial progress is planned for 2017. Liquid oxygen tank production will be completed at Michoud. Structural testing at Marshall will get under way. RS-25 hotfire testing will verify the new engine controllers. Core stage horizontal integration will begin. The core stage pathfinder mockup will arrive at the B2 test stand for fit checks and tests. EUS will complete preliminary design review. This paper will discuss the technical and programmatic successes and challenges of 2016 and look ahead to plans for 2017.
NASA Goddard Space Flight Center is developing Autonomous Navigation Guidance and Control (autoNGC) as a flight software system for future onboard use for missions in a variety of orbital regimes, including cislunar space and beyond. This paper describes processor-in-the-loop (PIL) testing using a lunar landing scenario with terrain relative navigation (TRN) and weak-signal GPS. We give an overview of the autoNGC project and describe preliminary navigation simulation results. We also describe the TRN PIL tests on a flight-like development board, using simulated images rendered from Lunar Reconnaissance Orbit high-resolution digital terrain models. The navigation simulations show that weak-signal GPS combined with TRN during a descent from a low lunar parking orbit results in sufficiently low navigation uncertainties to support such a mission profile independent of ground-based navigation. The PIL tests show that onboard image processing and landmark correlation is achievable at a sufficiently high measurement rate.
NASA IV&V was established in 1993 to improve safety and cost-effectiveness of mission critical software. Since its inception the tools and strategies employed by IV&V have evolved. This paper examines how lessons learned from the Phoenix project were developed and applied to the GRAIL project. Shortly after selection, the GRAIL project initiated a review of the issues documented by IV&V for Phoenix. The motivation was twofold: the learn as much as possible about the types of issues that arose from the flight software product line slated for use on GRAIL, and to identify opportunities for improving the effectiveness of IV&V on GRAIL. The IV&V Facility provided a database dump containing 893 issues. These were categorized into 16 bins, and then analyzed according to whether the project responded by changing the affected artifacts or using as-is. The results of this analysis were compared to a similar assessment of post-launch anomalies documented by the project. Results of the analysis were discussed with the IV&V team assigned to GRAIL. These discussions led to changes in the way both the project and IV&V approached the IV&V task, and improved the efficiency of the activity.
Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.
The Electron Drift Instrument (EDI) is a new technique for measuring electric fields in space by detecting the effect on weak beams of test electrons. This U.S. portions of the technique, flight hardware, and flight software were developed for the Cluster mission under this contract. Dr. Goetz Paschmann of the Max Planck Institute in Garching, Germany, was the Principle Investigator for Cluster EDI. Hardware for Cluster was developed in the U.S. at the University of New Hampshire, Lockheed Palo Alto Research Laboratory, and University of California, San Diego. The Cluster satellites carrying the original EDI instruments were lost in the catastrophic launch failure of first flight of the Arianne-V rocket in 1996. Following that loss, NASA and ESA approved a rebuild of the Cluster mission, for which all four satellites were successfully launched in the Summer of 2000. Limited operations of EDI were also obtained on the Equator-S satellite, which was launched in December, 1997. A satellite failure caused a loss of the Equator-S mission after only 5 months, but these operations were extremely valuable in learning about the characteristics and operations of the complex EDI instrument. The Cluster mission, satellites, and instruments underwent an extensive on-orbit commissioning phase in the Fall of 2000, carrying over through January 2001. During this period all elements of the instruments were checked and careful measurements of inter-experiments interferences were made. EDI is currently working exceptionally well in orbit. Initial results verify that all aspects of the instrument are working as planned, and returning highly valuable scientific information. The first two papers describing EDI on-orbit results have been submitted for publication in April, 2001. The principles of the EDI technique, and its implementation on Cluster are described in two papers by Paschmann et al., attached as Appendices A and B. The EDI presentation at the formal Cluster Commissioning Review, held at ESA Headquarters in Paris, is attached as Appendix C.
There are numerous studies which show that CASE Tools greatly facilitate software development. As a result of these advantages, an increasing amount of software development is done with CASE Tools. As more software engineers become proficient with these tools, their experience and feedback lead to further development with the tools themselves. What has not been widely studied, however, is the reliability and efficiency of the actual code produced by the CASE Tools. This investigation considered these matters. Three segments of code generated by MATRIXx, one of many commercially available CASE Tools, were chosen for analysis: ETOFLIGHT, a portion of the Earth to Orbit Flight software, and ECLSS and PFMC, modules for Environmental Control and Life Support System and Pump Fan Motor Control, respectively.
Agora software is a simulation of spacecraft attitude and orbit dynamics. It supports spacecraft models composed of multiple rigid bodies or flexible structural models. Agora simulates multiple spacecraft simultaneously, supporting rendezvous, proximity operations, and precision formation flying studies. The Agora environment includes ephemerides for all planets and major moons in the solar system, supporting design studies for deep space as well as geocentric missions. The environment also contains standard models for gravity, atmospheric density, and magnetic fields. Disturbance force and torque models include aerodynamic, gravity-gradient, solar radiation pressure, and third-body gravitation. In addition to the dynamic and environmental models, Agora supports geometrical visualization through an OpenGL interface. Prototype models are provided for common sensors, actuators, and control laws. A clean interface accommodates linking in actual flight code in place of the prototype control laws. The same simulation may be used for rapid feasibility studies, and then used for flight software validation as the design matures. Agora is open-source and portable across computing platforms, making it customizable and extensible. It is written to support the entire GNC (guidance, navigation, and control) design cycle, from rapid prototyping and design analysis, to high-fidelity flight code verification. As a top-down design, Agora is intended to accommodate a large range of missions, anywhere in the solar system. Both two-body and three-body flight regimes are supported, as well as seamless transition between them. Multiple spacecraft may be simultaneously simulated, enabling simulation of rendezvous scenarios, as well as formation flying. Built-in reference frames and orbit perturbation dynamics provide accurate modeling of precision formation control.
This software models a propulsive reaction control system (RCS) for guidance, navigation, and control simulation purposes. The model includes the drive electronics, the electromechanical valve dynamics, the combustion dynamics, and thrust. This innovation follows the Mars Science Laboratory entry reaction control system design, and has been created to meet the Mars Science Laboratory (MSL) entry, descent, and landing simulation needs. It has been built to be plug-and-play on multiple MSL testbeds [analysis, Monte Carlo, flight software development, hardware-in-the-loop, and ATLO (assembly, test and launch operations) testbeds]. This RCS model is a C language program. It contains two main functions: the RCS electronics model function that models the RCS FPGA (field-programmable-gate-array) processing and commanding of the RCS valve, and the RCS dynamic model function that models the valve and combustion dynamics. In addition, this software provides support functions to initialize the model states, set parameters, access model telemetry, and access calculated thruster forces.
The goal of the JPL reuse activity is to develop a quantitative understanding of the factors which encourage or inhibit software reuse, and of productivity improvements achievable through reuse. The primary activity is the measurement of parameters relevant to reuse in the environment of actual projects. The program has three objectives: (1) to develop a model to allow assessment of competing reuse techniques, (2) to extend reuse from the unit to the sub-system level, and (3) to expand from specific applications to a broader application domain. Application domains, which apply to all interplanetary projects, include Mission Operations, Science Information Systems, Flight Software, and Simulations. The program is targeting all phases and activities of the life cycle and a full range of software products. The approach will be both experimental (observe, hypothesize and evaluate) and constructive (introduce new tools and techniques). The primary target projects are Deep Space Network activities - the Ground Facilities facility upgrade, the Network Operations Control Center upgrade, and the Signal Processing Center. This is the first group of closely related projects being done in Ada at JPL. A reuse base will be developed initially by classifying potentially reusable components from one project; it will be used and expanded with additional projects.
The Orion flight software’s parity algorithm runs onboard to verify all three OIMUs (Orion Inertial Measurement Units) are sensing relatively uniform rate and acceleration and to quickly identify any unit which is in significant disagreement with the other two units. During the Artemis-I Wet Dress Rehearsal tests and Launch Countdowns, one of the three OIMUs regularly reported an anomalous parity signature for a brief period of time during sensor warm up. This paper will review this anomalous performance on the pad and review flight data with the intent to supplement the findings of the initial root cause investigation. Outside of this start up behavior, initial investigation into Artemis I flight data did not reveal any behavior of the OIMUs outside of preflight expectations. Flight data from any significant parity events and relevant IMU calibrations will be presented. A brief discussion of impacts to future Artemis mission operations strategy will be provided.
The scientific goal of UVCS is to obtain detailed empirical descriptions of the extended solar corona as it evolves over the solar cycle and to use these descriptions to identify and understand the physical processes responsible for coronal heating, solar wind acceleration, coronal mass ejections (CMEs), and the phenomena that establish the plasma properties of the solar wind as measured by "in situ" solar wind instruments. This report covers the period from 15 November 1998 to 14 March 2001. During that time, UVCS observations have consisted of three types: 1) standard synoptic observations comprising, primarily, the H I Lycc line profile and the O VI 103.2 and 103.7 nm intensity over a range of heights from 1.5 to about 3.0 solar radii and covering 360 degrees about the sun, 2) sit and stare watches for CMEs, and 3) special observations designed by the UVCS Lead Observer of the Week for a specific scientific purpose. The special observations are often coordinated with those of other space-based and ground based instruments and they often are part of SOHO joint observation programs and campaigns. Lead observers have included UVCS Co-Investigators, Guest Investigators, scientists from the solar physics community and several graduate and undergraduate level students. UVCS has continued to successfully meet its goal of using powerful spectroscopic diagnostic techniques to obtain a much more detailed description of coronal structures than existed before the SOHO mission. The new descriptions of coronal structures from UVCS have inspired a large number of theoretical studies aimed at identifying the physical processes responsible for solar wind acceleration in coronal holes and streamers. UVCS has proven to be a very stable instrument. Stellar observations have demonstrated its stability and the analysis of coordinated observations with Spartan 201 have verified the accuracy of the absolute calibration and spectral resolution at H I Ly (alpha) line profile. UVCS has required no flight software modifications and all mechanisms are operational. The UVCS O VI Channel with its redundant optical path for wavelengths near H I Ly (alpha) is capable of observing the entire UVCS wavelength range. Since December 1998, the O VI Channel has been used for all UVCS observations. Although the H I Ly (alpha) Channel and detector are still operational, increases in the dark count up to about 5x 10(exp-4) counts/sec/pixel and an increase in high voltage current to within a factor of two of the maximum used in the laboratory before flight led to the decision to not use that detector at the present time. There is no significant science impact since the O VI Channel can observe nearly the same wavelength range.
This study defined the preliminary designs of flight software for the Space Shuttle Orbiter for three two-phase fluid research experiments: (1) liquid reorientation - to study the motion of liquid in tanks subjected to small accelerations; (2) pool boiling - to study low-gravity boiling from horizontal cylinders; and (3) flow boiling - to study low-gravity forced flow boiling heat transfer and flow phenomena in a heated horizontal tube. The study consisted of eight major tasks: reassessment of the existing experiment designs, assessment of the Spacelab facility approach, assessment of the individual carry-on approach, selection of the preferred approach, preliminary design of flight hardware, safety analysis, preparation of a development plan, estimates of detailed design, fabrication and ground testing costs. The most cost effective design approach for the experiments is individual carry-ons in the Orbiter middeck. The experiments were designed to fit into one or two middeck lockers. Development schedules for the detailed design, fabrication and ground testing ranged from 15 1/2 to 18 months. Minimum costs (in 1981 dollars) ranged from $463K for the liquid reorientation experiment to $998K for the pool boiling experiment.
An experimental spacecraft control system will be incorporated into the Space Shuttle flight software and exercised during a forthcoming mission to evaluate its performance and handling qualities. The control system incorporates a 'phase space' control law to generate rate change requests and a linear programming jet select to compute jet firings. Posed as a linear programming problem, jet selection must represent the rate change request as a linear combination of jet acceleration vectors where the coefficients are the jet firing times, while minimizing the fuel expended in satisfying that request. This problem is solved in real time using a revised Simplex algorithm. In order to implement the jet selection algorithm in the Shuttle flight control computer, it was modified to accommodate certain practical features of the Shuttle such as limited computer throughput, lengthy firing times, and a large number of control jets. To the authors' knowledge, this is the first such application of linear programming. It was made possible by careful consideration of the jet selection problem in terms of the properties of linear programming and the Simplex algorithm. These modifications to the jet select algorithm may by useful for the design of reaction controlled spacecraft.
The Orion Crew Exploration Vehicle (CEV) will be the first human spacecraft built by NASA in almost 3 decades and will be the first vehicle to perform both Low Earth Orbit (LEO) missions and lunar missions since Apollo. The awesome challenge of designing a Guidance, Navigation, and Control (GN&C) system for this vehicle that satisfies all of its various mission requirements is countered by the opportunity to take advantage of the improvements in algorithms, software, sensors, and other related GN&C technology over this period. This paper describes the CEV GN&C reference architecture developed to support the overall NASA reference configuration and validate the driving requirements of the Constellation (Cx) Architecture Requirements Document (CARD, Reference 1) and the CEV System Requirements Document (SRD, Reference 2). The Orion GN&C team designed the reference architecture based on the functional allocation of GN&C roles and responsibilities of CEV with respect to the other Cx vehicles, such as the Crew Launch Vehicle (CLV), Earth Departure Stage (EDS), and Lunar Surface Area Module (LSAM), across all flight phases. The specific challenges and responsibilities of the CEV GN&C system from launch pad to touchdown will be introduced along with an overview of the navigation sensor suite, its redundancy management, and flight software (FSW) architecture. Sensors will be discussed in terms of range of operation, data utility within the navigation system, and rationale for selection. The software architecture is illustrated via block diagrams, commensurate with the design aspects.
The Space Environments Testbed (SET) is a flight controller data system for the Common Carrier Assembly. The SET-1 flight software provides the command, telemetry, and experiment control to ground operators for the SET-1 mission. Modes of operation (see dia gram) include: a) Boot Mode that is initiated at application of power to the processor card, and runs memory diagnostics. It may be entered via ground command or autonomously based upon fault detection. b) Maintenance Mode that allows for limited carrier health monitoring, including power telemetry monitoring on a non-interference basis. c) Safe Mode is a predefined, minimum power safehold configuration with power to experiments removed and carrier functionality minimized. It is used to troubleshoot problems that occur during flight. d) Operations Mode is used for normal experiment carrier operations. It may be entered only via ground command from Safe Mode.
Dielectrophoresis-Based Particle Sensor Using Nanoelectrode Arrays; Multi-Dimensional Damage Detection for Surfaces and Structures; ULTRA: Underwater Localization for Transit and Reconnaissance Autonomy; Autonomous Cryogenic Leak Detector for Improving Launch Site Operations; Submillimeter Planetary Atmospheric Chemistry Exploration Sounder; Method for Reduction of Silver Biocide Plating on Metal Surfaces; Silicon Micromachined Microlens Array for THz Antennas; Forward-Looking IED Detector Ground Penetrating Radar; Fully Printed, Flexible, Phased Array Antenna for Lunar Surface Communication, Battery Charge Equalizer with Transformer Array; An Efficient, Highly Flexible Multi-Channel Digital Downconverter Architecture; Dimmable Electronic Ballast for a Gas Discharge Lamp; Conductive Carbon Nanotube Inks for Use with Desktop Inkjet Printing Technology; Enhanced Schapery Theory Software Development for Modeling Failure of Fiber-Reinforced Laminates; High-Performance, Low-Temperature-Operating, Long-Lifetime Aerospace Lubricants; Carbon Nanotube Microarrays Grown on Nanoflake Substrates; Differential Muon Tomography to Continuously Monitor Changes in the Composition of Subsurface Fluids; Microgravity Drill and Anchor System; 20 Granular Media-Based Tunable Passive Vibration Suppressor; 21 Miga Aero Actuator and 2D Machined Mechanical Binary Latch; Micro-XRF for In Situ Geological Exploration of Other Planets; Hydrogen-Enhanced Lunar Oxygen Extraction and Storage Using Only Solar Power; Uplift of Ionospheric Oxygen Ions During Extreme Magnetic Storms; Miniaturized, High-Speed, Modulated X-Ray Source; Hollow-Fiber Spacesuit Water Membrane Evaporator 25 High-Power Single-Mode 2.65-micrometers InGaAsSb/AlInGaAsSb Diode Lasers; Optical Device for Converting a Laser Beam Into Two Co-aligned but Oppositely Directed Beams; A Hybrid Fiber/Solid-State Regenerative Amplifier with Tunable Pulse Widths for Satellite Laser Ranging; X-Ray Diffractive Optics; SynGenics Optimization System (SynOptSys); 29 CFD Script for Rapid TPS Damage Assessment; radEq Add-On Module for CFD Solver Loci-CHEM; Science Opportunity Analyzer (SOA) Version 8; 30 Autonomous Byte Stream Randomizer; Distributed Engine Control Empirical/Analytical Verification Tools; Dynamic Server-Based KML Code Generator Method for Level-of-Detail Traversal of Geospatial Data; Automated Planning of Science Products Based on Nadir Overflights and Alerts for Onboard and Ground Processing; Linked Autonomous Interplanetary Satellite Orbit Navigation; Risk-Constrained Dynamic Programming for Optimal Mars Entry, Descent, and Landing; Scheduling Operations for Massive Heterogeneous Clusters; Deepak Condenser Model (DeCoM); Flight Software Math Library; Recirculating 1-K-Pot for Pulse-Tube Cryostats; 35 Method for Processing Lunar Regolith Using Microwaves; Wells for In Situ Extraction of Volatiles from Regolith (WIEVR); and Estimating the Backup Reaction Wheel Orientation Using Reaction Wheel Spin Rates Flight Telemetry from a Spacecraft.