Search NASA⌕ Search

SEARCH · Search NASA

Results for “GNC Hardware”

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.

36 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

System level verification applying the Space Shuttle experience to the Space Station

The applicability of the verification process for the Shuttle guidance, navigation and control (GNC) and data management system (DMS) for the development of the Space Station are described. Shuttle avionics hardware/software integration was delayed to finalize the hardware design before detailed definition and testing of the software. A block diagram is provided of the flight simulation laboratory used to test the GNC programs before flight data were available. The Station will have distributed computers, unlike the Orbiter, and will only be assembled fully in space. Standardized integration simulation test equipment are being defined to guide the development of hardware and software. The simulation capability may become part of nominal in-flight operations to initiate new capabilities as they are added to the Station. The Station GNC and DMS systems development will be somewhat simplified relative to those of the Shuttle because ascent and reentry will not be considered for the Station.

Gilbert, David W.↗
NASA NTRS2024

Aerocapture: An Enabling Technology for Flagship-Class Uranus Orbiter and Probe Mission

Introduction: The current decadal survey published by the National Academies of Sciences has informed National Aeronautics and Space Administration (NASA) to prioritize the study of the Ice Giants, especially Uranus. To gather the required data that addresses the science questions raised in this survey, a mission to Uranus with an orbiter and atmospheric probe must be designed. The Uranus Orbiter and Probe (UOP) study, which the survey identified as the flagship mission of this decade, proposes a 2031 launch to take advantage of a Jupiter fly-by and utilizes a fully propulsive orbit insertion design with an Earth-to-Uranus transit times ranging from 13 to 15 years. This fully propulsive orbit insertion at Uranus will be very fuel expensive (wet mass percentages of around 60-70\%) thereby leaving less mass for the scientific payload and additional planetary probes. In addition, scientists are more interested in visiting Uranus before 2049, when the Spring Equinox will occur, as it allows studying Uranus seasons not seen during Voyager 2's flyby in 1987. A NASA Flagship-Class mission would require at least 10 years of lead time prior to launch thereby making the 2031 launch to take advantage of the Jupiter fly-by extremely challenging. The consequence of missing the Jupiter fly-by and launching in the late 2030s is the challenge of a fully-propulsive mission like UOP to have a feasible alternative interplanetary trajectory that reaches Uranus before 2050. As an alternative, to address the shortcomings of the fully propulsive mission, one can design a mission to Uranus using aerocapture. What is aerocapture: Aerocapture is an atmospheric maneuver that uses aerodynamic forces generated by flight within a planetary atmosphere to decelerate and achieve orbit insertion. Using aerocapture allows one to provide the change in velocity (Delta V) needed to slow down from the approach hyperbolic trajectory to achieve the desired captured orbit around the target planet using aerodynamic forces of the vehicle (lift and drag). Using aerodynamic forces instead of fully-propulsive maneuvers results in significant savings in the fuel. Furthermore, aerocapture can also allow one to consider interplanetary trajectories with higher approach hyperbolic velocities, thus reducing the mission transit times. Aerocapture as an enabling technology: To use aerocapture as an enabling technology for the Uranus exploration mission, one would require an integrated system-level design, including a Thermal Protection System (TPS), hardware needed for aerodynamic modulation, and autonomous Guidance, Navigation, and Control (GNC) systems. Aerocapture has yet to be demonstrated, despite considering it for several past missions. Recent advancements in TPS and GNC capabilities show the potential for using rigid, heritage entry vehicle configurations already flown at other planetary bodies for Uranus aerocapture. Aerocapture can be a robust technology that can deliver spacecraft to Uranus science orbits while substantially increasing on-orbit payload mass (more than 40\%) that can enable robust atmospheric entry probes. Additionally, the aerocapture maneuver would reduce the interplanetary transit time by 2–5 years (15-30\%) relative to fully-propulsive orbit insertion. Recent work has shown that one can conduct a flagship-class mission in a shorter period than fully-propulsive missions if using aerocapture. What does aerocapture bring in for a Uranus Mission: Using aerocapture for a Uranus orbiter and atmospheric probe mission can provide one with considerable propellant savings. Spacecraft in interplanetary trajectories to Uranus typically need an Delta V in orders of kilometers per second to insert into science orbit. One would require thousands of kilograms of fuel to achieve such a Delta V using a traditional fully propulsive maneuver, leaving less mass for payload during the mission launch. Aerocapture can reduce the propulsion needs by dissipating energy in the sizable atmosphere of Uranus without a significant mass increase due to the need for an aeroshell. One can use the mass savings achieved using the aerocapture to reduce the launch vehicle requirements. In addition, one can also have additional science instruments on the orbiter or create a robust instrumentation suite on an atmospheric probe that can significantly increase the science outcome of the Uranus exploration mission. Furthermore, since aerocapture performance is relatively insensitive to increases in hyperbolic excess velocity, one can design the interplanetary trajectory to arrive at Uranus faster, reducing the interplanetary transit time and operations cost. All these savings, achieved using aerocapture, could help fit a larger class mission, such as the Uranus mission within a smaller capital, e.g., a Flagship-class orbiter mission in a New Frontiers class capital. Summary: This talk will provide an overview of how aerocapture can enable the Uranus exploration mission. Specifically, this talk will discuss the latest advancements made in the Uranus aerocapture study, such as investigating interplanetary trajectories with higher hyperbolic approach velocities and their implications on the aero heating and the TPS design, incorporating FNPAG (an advanced numerical-predictor guidance) and comparison of multiple navigation approaches. In addition, this talk will focus on mechanical design that can house more than one atmospheric probe and the six degrees of freedom simulation of aerocapture at Uranus. Findings from a recent NASA Space Technology Mission Directorate (STMD)-funded activity studying the aerocapture as an enabling technology for a Uranus orbiter will be presented. Using the science payload recommended by the Decadal Survey for Uranus exploration, this work shows many improvements over the baseline fully-propulsive mission. These improvements include a shorter cruise phase, flexibility in launch opportunities late into the 2030s while reaching Uranus before the 2050 equinox for the desired science opportunities, and lower propellant mass needs. This talk will highlight how aerocapture can be utilized for Uranus science orbit insertion using a lower-risk, heritage entry vehicle configuration used extensively as a Mars entry, descent, and landing vehicle. Furthermore, this talk will explore how the demonstration of aerocapture at Earth can benefit the aerocapture-enabled Uranus mission.

Aerocapture↗
NASA NTRS2017

NASA Affordable Vehicle Avionics (AVA)

Small satellites are becoming ever more capable of performing valuable missions for both government and commercial customers. However, currently these satellites can be launched affordably only as secondary payloads. This makes it difficult for the small satellite mission to launch when needed, to the desired orbit, and with acceptable risk. What is needed is a class of low-cost launchers, so that launch costs to low-Earth orbit (LEO) are commensurate with payload costs. Several private and government-sponsored launch vehicle developers are working toward just that-the ability to affordably insert small payloads into LEO. But until now, cost of the complex avionics remained disproportionately high. AVA (Affordable Vehicle Avionics) solves this problem. Significant contributors to the cost of launching nanosatellites to orbit are the avionics and software systems that steer and control the launch vehicles, sequence stage separation, deploy payloads, and telemeter data. The high costs of these guidance, navigation and control (GNC) avionics systems are due in part to the current practice of developing unique, single-use hardware and software for each launch. High-performance, high-reliability inertial sensors components with heritage from legacy launchers also contribute to costs-but can low-cost commercial inertial sensors work just as well? NASA Ames Research Center has developed and tested a prototype low-cost avionics package for space launch vehicles that provides complete GNC functionality in a package smaller than a tissue box (100 millimeters by 120 millimeters by 69 millimeters; 4 inches by 4.7 inches by 2.7 inches), with a mass of less than 0.84 kilogram (2 pounds. AVA takes advantage of commercially available, low-cost, mass-produced, miniaturized sensors, filtering their more noisy inertial data with real-time GPS (Global Positioning Satellite) data. The goal of the AVA project is to produce and light-verify a common suite of avionics and software that deliver affordable, capable GNC and telemetry avionics with application to multiple nanolaunch vehicles at 1 percent of the cost of current state-of-the-art avionics.

space technology↗
NASA NTRS2017

Space Technology Game Changing Development: NASA Affordable Vehicle Avionics (AVA)

Common Modular Avionics System for Nanolaunchers Offering Affordable Access to Space Small satellites are becoming ever more capable of performing valuable missions for both government and commercial customers. However, currently these satellites can be launched affordably only as secondary payloads. This makes it difficult for the small satellite mission to launch when needed, to the desired orbit, and with acceptable risk. What is needed is a class of low-cost launchers, so that launch costs to low-Earth orbit (LEO) are commensurate with payload costs. Several private and government-sponsored launch vehicle developers are working toward just that—the ability to affordably insert small payloads into LEO. But until now, cost of the complex avionics remained disproportionately high. AVA solves this problem. Significant contributors to the cost of launching nanosatellites to orbit are the avionics and software systems that steer and control the launch vehicles, sequence stage separation, deploy payloads, and telemeter data. The high costs of these guidance, navigation and control (GNC) avionics systems are due in part to the current practice of developing unique, single use hardware and software for each launch. High-performance, high-reliability inertial sensors components with heritage from legacy launchers also contribute to costs—but can low-cost commercial inertial sensors work just as well?

Aquilina, Rudy↗
NASA NTRSDate not supplied

OASSIS: Onboard Adaptive Safe-site Identification System Y3

The OASSIS Year 3 project continues to innovate with three goals: 1) transition to a generic configuration compatible with GNC flight software, 2) implement a new, computationally-efficient TRN algorithm for lunar landing, and 3) integrate with the a HWIL testbed to validate lunar landing GNC systems. This project enables lunar lander GNC flight software to be tested dynamically without the need of a costly flight campaign and without the risk of catastrophic hardware loss. Additionally, the TRN algorithm development and testing enhances the state-of-the-art in pinpoint landing navigation, ultimately improving the overall landing accuracy, safety, and reliability of a crewed lunar landing mission.

James S Mccabe↗
NASA NTRS2015

NASA Propulsion Concept Studies and Risk Reduction Activities for Resource Prospector Lander

The trade study has led to the selection of propulsion concept with the lowest cost and net lowest risk -Government-owned, flight qualified components -Meet mission requirements although the configuration is not optimized. Risk reduction activities have provided an opportunity -Implement design improvements while development with the early-test approach. -Gain knowledge on the operation and identify operation limit -Data to anchor analytical models for future flight designs; The propulsion system cold flow tests series have provided valuable data for future design. -The pressure surge from the system priming and waterhammer within component operation limits. -Enable to optimize the ullage volume to reduce the propellant tank mass; RS-34 hot fire tests have successfully demonstrated of using the engines for the RP mission -No degradation of performance due to extended storage life of the hardware. -Enable to operate the engine for RP flight mission scenarios, outside of the qualification regime. -Provide extended data for the thermal and GNC designs. Significant progress has been made on NASA propulsion concept design and risk reductions for Resource Prospector lander.

Trinh, Huu P.↗
NASA NTRS2022

Night Sky Testing of the Lunar Flashlight Star Tracker

Lunar Flashlight (LF) is a 6U, 14 kg spacecraft being built by the NASA Jet Propulsion Laboratory (JPL). The mission will use IR laser technology to search for volatiles and surface water ice deposits in the permanently shadowed regions (PSR) of the moon in preparation for future human lunar exploration. The fine pointing provided by the Guidance, Navigation and Control (GNC) system is crucial for the spacecraft to successfully reach the moon, enter a lunar orbit, and acquire scientific data. At the center of the GNC system’s ability to determine the spacecraft’s attitude is a star tracker. The LF star tracker is a commercial-off-the-shelf (COTS) unit built into the integrated GNC system provided by Blue Canyon Technologies. Blue Canyon tested the star tracker in a lab environment for basic functionality and attitude estimation capabilities; upon delivery of the hardware to JPL, further testing with a real night sky was desired to determine expected in-flight operational characteristics. JPL maintains the Table Mountain Facility with its suite of ground telescopes, including a 0.6m telescope with an equatorial mount. This stable platform provided a highly accurate method of providing slews and attitude holds akin to what the spacecraft will perform in flight. Therefore, by analyzing the data from these representative night-sky ground tests performed in March, 2021, it is possible to acquire expected flight performance of the star tracker, particularly in regard to the ability of the star tracker to maintain lock on the starfield during planned maneuver types. This paper presents the various tests that have been performed to ensure that the LF star tracker will function as part of the overall GNC system and integrated spacecraft once launched. Test data is included for several key tests, and a path forward towards future integration and testing at the spacecraft level is described.

Baker, John↗
NASA NTRS2013

Orion GNC Mitigation Efforts for Van Allen Radiation

The Orion Crew Module (CM) is NASA's next generation manned space vehicle, scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and GN&C architectures have progressed through a number of project phases and are nearing completion of a major milestone. The first unmanned test mission, dubbed "Exploration Flight Test One" (EFT-1) is scheduled to launch from NASA Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and software. The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, which will be launched on an expendable launch vehicle (ELV). The ELV will place CM and the ELV upper stage into a low Earth orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a relatively high velocity, high heating environment. While not producing entry velocities as high as those experienced in returning from a lunar orbit, the trajectory was chosen to provide higher stresses on the thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required entry geometry with constraints on inclination and landing site result in a trajectory that lingers for many hours in the Van Allen radiation belts. This exposes the vehicle and avionics to much higher levels of high energy proton radiation than a typical LEO or lunar trajectory would encounter. As a result, Van Allen radiation poses a significant risk to the Orion avionics system, and particularly the Flight Control Module (FCM) computers that house the GN&C flight software. The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated with the Van Allen radiation on EFT-1 are covered in the paper. Background on the Orion avionics subsystem is provided, as well as an overview of the GN&C software architecture. The measures taken to handle radiation induced failure of the one or both of the FCM's are presented, and finally simulation and actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. The paper presents an overview of the Orion avionics architecture describing the GNC sensors, onboard data network as well as the flight control computers and their planned restart capabilities. GN&C sensors include two Orion Inertial Measurement Units (OIMU's), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters and a single GPS receiver. All of the sensors communicate to one of two Power and Data Units (PDU's). The PDU's multiplex analog and serial data from the sensors and write the data to the Orion Data Network (ODN). The OIMU s write measurement messages directly as onto the ODN, but they are routed through PDU network switches.

King, Ellis T.↗
NASA NTRS2014

Evolution of MPCV Service Module Propulsion and GNC Interface Requirements

The Orion Multi-Purpose Crew Vehicle Service Module Propulsion Subsystem provides propulsion for the integrated Crew and Service Module. Updates in the exploration architecture between Constellation and MPCV as well as NASA's partnership with the European Space Agency have resulted in design changes to the SM Propulsion Subsystem and updates to the Propulsion interface requirements with Guidance Navigation and Control. This paper focuses on the Propulsion and GNC interface requirement updates between the Constellation Service Module and the European Service Module and how the requirement updates were driven or supported by architecture updates and the desired use of hardware with heritage to United States and European spacecraft for the Exploration Missions, EM-1 and EM-2.

spacecraft propulsion↗
NASA NTRS2018

Sensor Data Quality and Angular Rate Down-Selection Algorithms on SLS EM-1

The NASA Space Launch System Block 1 launch vehicle is equipped with an Inertial Navigation System (INS) and multiple Rate Gyro Assemblies (RGA) that are used in the Guidance, Navigation, and Control (GN&C) algorithms. The INS provides the inertial position, velocity, and attitude of the vehicle along with both angular rate and specific force measurements. Additionally, multiple sets of co-located rate gyros supply angular rate data. The collection of angular rate data, taken along the launch vehicle, is used to separate out vehicle motion from flexible body dynamics. Since the system architecture uses redundant sensors, the capability was developed to evaluate the health (or validity) of the independent measurements. A suite of Sensor Data Quality (SDQ) algorithms is responsible for assessing the angular rate data from the redundant sensors. When failures are detected, SDQ will take the appropriate action and disqualify or remove faulted sensors from forward processing. Additionally, the SDQ algorithms contain logic for down-selecting the angular rate data used by the GNC software from the set of healthy measurements. This paper explores the trades and analyses that were performed in selecting a set of robust fault-detection algorithms included in the GN&C flight software. These trades included both an assessment of hardware-provided health and status data as well as an evaluation of different algorithms based on time-to-detection, type of failures detected, and probability of detecting false positives. We then provide an overview of the algorithms used for both fault-detection and measurement down selection. We next discuss the role of trajectory design, flexible-body models, and vehicle response to off-nominal conditions in setting the detection thresholds. Lastly, we present lessons learned from software integration and hardware-in-the-loop testing.

Park, Thomas↗
NASA NTRS2013

Practical Application of PRA as an Integrated Design Tool for Space Systems

This paper presents the application of the first comprehensive Probabilistic Risk Assessment (PRA) during the design phase of a joint NASA/NOAA weather satellite program, Geostationary Operational Environmental Satellite Series R (GOES-R). GOES-R is the next generation weather satellite primarily to help understand the weather and help save human lives. PRA has been used at NASA for Human Space Flight for many years. PRA was initially adopted and implemented in the operational phase of manned space flight programs and more recently for the next generation human space systems. Since its first use at NASA, PRA has become recognized throughout the Agency as a method of assessing complex mission risks as part of an overall approach to assuring safety and mission success throughout project lifecycles. PRA is now included as a requirement during the design phase of both NASA next generation manned space vehicles as well as for high priority robotic missions. The influence of PRA on GOES-R design and operation concepts are discussed in detail. The GOES-R PRA is unique at NASA for its early implementation. It also represents a pioneering effort to integrate risks from both Spacecraft (SC) and Ground Segment (GS) to fully assess the probability of achieving mission objectives. PRA analysts were actively involved in system engineering and design engineering to ensure that a comprehensive set of technical risks were correctly identified and properly understood from a design and operations perspective. The analysis included an assessment of SC hardware and software, SC fault management system, GS hardware and software, common cause failures, human error, natural hazards, solar weather and infrastructure (such as network and telecommunications failures, fire). PRA findings directly resulted in design changes to reduce SC risk from micro-meteoroids. PRA results also led to design changes in several SC subsystems, e.g. propulsion, guidance, navigation and control (GNC), communications, mechanisms, and command and data handling (C&DH). The fault tree approach assisted in the development of the fault management system design. Human error analysis, which examined human response to failure, indicated areas where automation could reduce the overall probability of gaps in operation by half. In addition, the PRA brought to light many potential root causes of system disruptions, including earthquakes, inclement weather, solar storms, blackouts and other extreme conditions not considered in the typical reliability and availability analyses. Ultimately the PRA served to identify potential failures that, when mitigated, resulted in a more robust design, as well as to influence the program's concept of operations. The early and active integration of PRA with system and design engineering provided a well-managed approach for risk assessment that increased reliability and availability, optimized lifecyc1e costs, and unified the SC and GS developments.

Kalia, Prince↗
NASA NTRS2014

Time and Frequency-Domain Cross-Verification of SLS 6DOF Trajectory Simulations

The SLS GNC team and its partners have developed several time- and frequency-based simulations for development and analysis of the proposed SLS launch vehicle. The simulations differ in fidelity and some have unique functionality that allows them to perform specific analyses. Some examples of the purposes of the various models are: trajectory simulation, multi-body separation, Monte Carlo, hardware in the loop, loads, and frequency domain stability analyses. While no two simulations are identical, many of the models are essentially six degree-of-freedom (6DOF) representations of the SLS plant dynamics, hardware implementation, and flight software. Thus at a high level all of those models should be in agreement. Comparison of outputs from several SLS trajectory and stability analysis tools are ongoing as part of the program's current verification effort. The purpose of these comparisons is to highlight modeling and analysis differences, verify simulation data sources, identify inconsistencies and minor errors, and ultimately to verify output data as being a good representation of the vehicle and subsystem dynamics. This paper will show selected verification work in both the time and frequency domain from the current design analysis cycle of the SLS for several of the design and analysis simulations. In the time domain, the tools that will be compared are MAVERIC, CLVTOPS, SAVANT, STARS, ARTEMIS, and POST 2. For the frequency domain analysis, the tools to be compared are FRACTAL, SAVANT, and STARS. The paper will include discussion of these tools including their capabilities, configurations, and the uses to which they are put in the SLS program. Determination of the criteria by which the simulations are compared (matching criteria) requires thoughtful consideration, and there are several pitfalls that may occur that can severely punish a simulation if not considered carefully. The paper will discuss these considerations and will present a framework for responding to these issues when they arise. For example, small event timing differences can lead to large differences in mass properties if the criteria are to measure those properties at the same time, or large differences in altitude if the criteria are to measure those properties when the simulation experiences a staging event. Similarly, a tiny difference in phase can lead to large gain margin differences for frequency-domain comparisons of gain margins.

VanZwieten, Tannen↗
NASA NTRS2017

Time and Frequency-Domain Cross-Verification of SLS 6DOF Trajectory Simulations

The Space Launch System (SLS) Guidance, Navigation, and Control (GNC) team and its partners have developed several time- and frequency-based simulations for development and analysis of the proposed SLS launch vehicle. The simulations differ in fidelity and some have unique functionality that allows them to perform specific analyses. Some examples of the purposes of the various models are: trajectory simulation, multi-body separation, Monte Carlo, hardware in the loop, loads, and frequency domain stability analyses. While no two simulations are identical, many of the models are essentially six degree-of-freedom (6DOF) representations of the SLS plant dynamics, hardware implementation, and flight software. Thus at a high level all of those models should be in agreement. Comparison of outputs from several SLS trajectory and stability analysis tools are ongoing as part of the program's current verification effort. The purpose of these comparisons is to highlight modeling and analysis differences, verify simulation data sources, identify inconsistencies and minor errors, and ultimately to verify output data as being a good representation of the vehicle and subsystem dynamics. This paper will show selected verification work in both the time and frequency domain from the current design analysis cycle of the SLS for several of the design and analysis simulations. In the time domain, the tools that will be compared are MAVERIC, CLVTOPS, SAVANT, STARS, ARTEMIS, and POST 2. For the frequency domain analysis, the tools to be compared are FRACTAL, SAVANT, and STARS. The paper will include discussion of these tools including their capabilities, configurations, and the uses to which they are put in the SLS program. Determination of the criteria by which the simulations are compared (matching criteria) requires thoughtful consideration, and there are several pitfalls that may occur that can severely punish a simulation if not considered carefully. The paper will discuss these considerations and will present a framework for responding to these issues when they arise. For example, small event timing differences can lead to large differences in mass properties if the criteria are to measure those properties at the same time, or large differences in altitude if the criteria are to measure those properties when the simulation experiences a staging event. Similarly, a tiny difference in phase can lead to large gain margin differences for frequency-domain comparisons of gain margins.

Johnson, Matthew↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

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.

Gualdoni, Matthew J.↗
NASA NTRS2016

A GNC Perspective of the Launch and Commissioning of NASA's SMAP (Soil Moisture Active Passive) Spacecraft

The NASA Soil Moisture Active Passive (SMAP) spacecraft was designed to use radar and radiometer measurements to produce global soil moisture measurements every 2-3 days. The SMAP spacecraft is a complicated dual-spinning design with a large 6 meter deployable mesh reflector mounted on a platform that spins at 14.6 rpm while the Guidance Navigation and Control algorithms maintain precise nadir pointing for the de-spun portion of the spacecraft. After launching in early 2015, the Guidance Navigation and Control software and hardware aboard the SMAP spacecraft underwent an intensive spacecraft checkout and commissioning period. This paper describes the activities performed by the Guidance Navigation and Control team to confirm the health and phasing of subsystem hardware and the functionality of the guidance and control modes and algorithms. The operations tasks performed, as well as anomalies that were encountered during the commissioning, are explained and results are summarized.

Brown, Todd S.↗
NASA NTRS2016

Simulation of Mission Phases

This position with the Simulation and Graphics Branch (ER7) at Johnson Space Center (JSC) provided an introduction to vehicle hardware, mission planning, and simulation design. ER7 supports engineering analysis and flight crew training by providing high-fidelity, real-time graphical simulations in the Systems Engineering Simulator (SES) lab. The primary project assigned by NASA mentor and SES lab manager, Meghan Daley, was to develop a graphical simulation of the rendezvous, proximity operations, and docking (RPOD) phases of flight. The simulation is to include a generic crew/cargo transportation vehicle and a target object in low-Earth orbit (LEO). Various capsule, winged, and lifting body vehicles as well as historical RPOD methods were evaluated during the project analysis phase. JSC core mission to support the International Space Station (ISS), Commercial Crew Program (CCP), and Human Space Flight (HSF) influenced the project specifications. The simulation is characterized as a 30 meter +V Bar and/or -R Bar approach to the target object's docking station. The ISS was selected as the target object and the international Low Impact Docking System (iLIDS) was selected as the docking mechanism. The location of the target object's docking station corresponds with the RPOD methods identified. The simulation design focuses on Guidance, Navigation, and Control (GNC) system architecture models with station keeping and telemetry data processing capabilities. The optical and inertial sensors, reaction control system thrusters, and the docking mechanism selected were based on CCP vehicle manufacturer's current and proposed technologies. A significant amount of independent study and tutorial completion was required for this project. Multiple primary source materials were accessed using the NASA Technical Report Server (NTRS) and reference textbooks were borrowed from the JSC Main Library and International Space Station Library. The Trick Simulation Environment and User Training Materials version 2013.0 release was used to complete the Trick tutorial. Multiple network privilege and repository permission requests were required in order to access previous simulation models. The project was also an introduction to computer programming and the Linux operating system. Basic C++ and Python syntax was used during the completion of the Trick tutorial. Trick's engineering analysis and Monte Carlo simulation capabilities were observed and basic space mission planning procedures were applied in the conceptual design phase. Multiple professional development opportunities were completed in addition to project duties during this internship through the System for Administration, Training, and Education Resources for NASA (SATERN). Topics include: JSC Risk Management Workshop, CCP Risk Management, Basic Radiation Safety Training, X-Ray Radiation Safety, Basic Laser Safety, JSC Export Control, ISS RISE Ambassador, Basic SharePoint 2013, Space Nutrition and Biochemistry, and JSC Personal Protective Equipment. Additionally, this internship afforded the opportunity for formal project presentation and public speaking practice. This was my first experience at a NASA center. After completing this internship I have a much clearer understanding of certain aspects of the agency's processes and procedures, as well as a deeper appreciation from spaceflight simulation design and testing. I will continue to improve my technical skills so that I may have another opportunity to return to NASA and Johnson Space Center.

Carlstrom, Nicholas Mercury↗
NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗
NASA NTRS2023

Backup Optical Navigation Attitude for Artemis-1 Backup Attitude Ground Tool

The Backup Optical Navigation Attitude (BONA) software was developed as a response to the Artemis1 Power Distribution Unit (PDU) hardware problems found early in 2021. The hardware problem, a capacitor installed incorrectly, removes the intended redundant path for which the PDU can relay its power and data to attached devices. Specific to the BONA context, the concern is that a failure of the single remaining path in this PDU would lead to an inability to communicate with one of the two-star trackers (STs) on Orion. By flight rule, being reduced to a single star tracker means an immediate turn around end-of-mission. The BONA software is not intended to extend the mission, but instead act as a single star tracker attitude confirmation tool. Insurance, if you will, for the Orion project that a ground tool is available to compare the single remaining ST results with optical navigation images retrieved during the mission. Engineers operating BONA in the Mission Control Center (MCC) Mission Evaluation Room (MER) will analyze the downlinked star field images and based on the stars identified and known time of image, derive vehicle attitude estimates, which can be compared with the ST results. Potentially, in extreme situations, and with expert recommendation, the derivations could lead to navigation state updates being commanded to Orion.

GNC↗