Search NASA⌕ Search

SEARCH · Search NASA

Results for “heritage”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Structural Dynamics Observations in Space Launch System Green Run Hot Fire Testing

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight 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 Green Run Hot Fire (GRHF) of the SLS Core Stage provided a flight-like ground test environment for verification of integrated vehicle TVC performance. A TVC model coupled to a vehicle structural dynamic model has been developed previously and incrementally validated in subsystem tests and simulations. Still, some aspects of TVC performance in GRHF were not anticipated. The ensuing investigation demonstrated the need for well-instrumented test environments, various levels of modeling fidelity, test-representative structural models, and caution in reuse of legacy components. This paper is the sixth installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. It introduces the salient structural dynamic phenomena uncovered in ambient and hot fire testing. During the Green Run test campaign, a comparison of ambient and hot fire step responses showed a significant change in apparent damping due to the presence of friction, challenging long standing assumptions that friction could be neglected. Additionally, the characteristic response of the engine and thrust structure during GRHF proved to be more complex than anticipated, as evidenced by the available actuator, thrust structure, and engine measurements. While the string-potentiometer based test instrumentation was intended to allow for reconstruction of the engine angles along the two control axes, the geometric placement, location uncertainty, and responses in overlapping frequency spectra revealed additional phenomena requiring further analysis and post-processing. The observations from both modal and frequency response testing during the Green Run ambient and hot fire configurations led to Engine and Core Stage FEM (finite element model) updates. When evidence of unexpected engine motion was found in engine section accelerometer data, the authors pursued additional structural analysis leading to FEM updates associated with the TVC gimbal and thrust structure. Through collaboration between structures, TVC, and flight control disciplines, the test-informed models and root-cause analysis led to confident flight rationale for the first flight of the SLS launch vehicle.

Richard K. Moore↗
NASA NTRSDate not supplied

Design, Instrumentation, and Data Analysis for the SLS Core Stage Green Run Test Series

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. The actuators are powered by a Shuttle-derived hydraulic Core Auxiliary Power Unit (CAPU), and integrated with an all-new Core Stage thrust structure. The actuators are interfaced to the SLS Vehicle Management (VM) software via an all-new TVC Actuator Control (TAC) avionics subsystem. Despite the significant test and flight experience of the Shuttle hardware, the SLS Green Run ambient and hot fire test activities revealed a number of new findings associated with the dynamic response of the TVC integrated system. Test responses suggested that the TVC system did not meet its performance specifications and its step and frequency responses exhibited unexpected departures from prior lab tests and modeled behavior. This paper is the fifth installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the design of the TVC analyses conducted during the Core Stage Green Run test series are discussed in detail. Throughout the course of the test activities, the SLS flight control team worked diligently with the Core Stage contractor to revise test command profiles and ensure sufficient instrumentation was available to collect data. Post-test analysis combined the Green Run modal, ambient, and hot fire test data, MSFC 2- axis Core Stage TVC Inertial Load Simulator (ILS) data, Hardware-In-the-Loop (HWIL) Systems Integration Lab (SIL) results, and actuator Acceptance Testing Procedure (ATP) responses. These data were used to characterize the response, validate critical math models of the TVC subsystem, and isolate the probable cause of the unexpected responses. Through comprehensive analysis of the available test data sources, the integrated team identified the dominant contributors to the observed response and developed test-correlated rationale for vehicle flight control system performance, ultimately leading to a confident posture for the Artemis I mission.

John H. Wall↗
NASA NTRSDate not supplied

Structural Dynamics Observations in Space Launch System Green Run Hot Fire Testing

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight 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 Green Run Hot Fire (GRHF) of the SLS Core Stage provided a flight-like ground test environment for verification of integrated vehicle TVC performance. A TVC model coupled to a vehicle structural dynamic model has been developed previously and incrementally validated in subsystem tests and simulations. Still, some aspects of TVC performance in GRHF were not anticipated. The ensuing investigation demonstrated the need for well-instrumented test environments, various levels of modeling fidelity, test-representative structural models, and caution in reuse of legacy components. This paper is the sixth installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. It introduces the salient structural dynamic phenomena uncovered in ambient and hot fire testing. During the Green Run test campaign, a comparison of ambient and hot fire step responses showed a significant change in apparent damping due to the presence of friction, challenging long standing assumptions that friction could be neglected. Additionally, the characteristic response of the engine and thrust structure during GRHF proved to be more complex than anticipated, as evidenced by the available actuator, thrust structure, and engine measurements. While the string-potentiometer based test instrumentation was intended to allow for reconstruction of the engine angles along the two control axes, the geometric placement, location uncertainty, and responses in overlapping frequency spectra revealed additional phenomena requiring further analysis and post-processing. The observations from both modal and frequency response testing during the Green Run ambient and hot fire configurations led to Engine and Core Stage FEM (finite element model) updates. When evidence of unexpected engine motion was found in engine section accelerometer data, the authors pursued additional structural analysis leading to FEM updates associated with the TVC gimbal and thrust structure. Through collaboration between structures, TVC, and flight control disciplines, the test-informed models and root-cause analysis led to confident flight rationale for the first flight of the SLS launch vehicle.

Richard Moore↗
NASA NTRSDate not supplied

Flight Performance and Stability of Space Launch System Core Stage Thrust Vector Control

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. The Core Stage TVC shares vehicle control authority with the SLS 5-segment Solid Rocket Boosters (SRBs) during boost phase flight, and is the sole means of vehicle flight control during in exoatmospheric flight following SRB separation. TVC responses during Green Run Hot Fire (GRHF) testing revealed that the TVC did not meet its performance specifications. Step and frequency responses exhibited unexpected departures from prior laboratory data and modeled behavior. Post-test analysis determined that the characteristics of the structure and gimbal friction are significantly influenced by the thrust-loaded conditions, and the command avionics exhibited a small but important gain nonlinearity. Using the available test data, the design team augmented the flight control TVC models to bound the observed results and include the additional fidelity needed for vehicle flight control analysis so as to build sufficient rationale for flight certification. Prior to the Green Run tests, “simplex” linear models typically used for flight control analysis did not include gimbal friction and other nonlinearities owing to long-standing assumptions that these effects were negligible in the Shuttle Orbiter TVC system. Following the Green Run findings, simulation analysis of the flight dynamics in the time and frequency domain revealed the propensity for a flight control limit cycle oscillation (LCO) if friction and structural compliances fell near the edges of test-predicted bounds. While the “most probable” models did not predict an in-flight LCO, the SLS Program conservatively proceeded with a system-wide evaluation and ultimate acceptance of the possibility for a small amplitude, low-frequency TVC LCO in flight. A final validation of the extensive test and modeling effort occurred when the first flight of SLS successfully demonstrated the fully integrated performance of the vehicle’s TVC system This paper is the final installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the development of flight rationale in light of the TVC responses observed in Green Run is discussed, along with a review of the flight telemetry illustrating the correlation of the preflight predictions with the observed performance.

John H. Wall↗
NASA NTRS2022

Mars 2020 Entry, Descent, and Landing System Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗
NASA NTRS2022

Mars 2020 Entry, Descent, and Landing Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. In addition to performing the critical function of landing the rover on the Martian surface, the EDL timeline behavior must co-exist in a non-partitioned software and system environment with other high-level functions that accomplish the goals for the rest of the mission. Due to the criticality of EDL, the potential for loss of mission, and a need for complete system autonomy, the standard for how the EDL Timeline interacts with other functions in the system is highly constrained. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗
NASA NTRS2022

Cross-Cutting Flight Infrastructure Improvements on M2020

Mars2020 (M2020) was formulated as a mission that leveraged as much Mars Science Laboratory (MSL) heritage as possible, while focusing major new development efforts on the original and unique elements needed to accomplish the different mission objectives. Well publicized examples of high profile new developments include precision landing, the sampling and caching system, the specific instrument suite, improved mobility via Autonomous Navigation, and later the addition of the Ingenuity helicopter. Less well known are the refinements to the core flight infrastructure, primarily in the cross-cutting functions of Telecom, Avionics, Data Management, Communications Behaviors, and Parameter Management. These enhancements are introduced predominately via flight software, and represent increases in capability that justified their inclusion in an otherwise heritage-focused project environment.Perseverance’s cross-cutting flight infrastructure improvements fall into and across the following five categories. First is a trimming of the software footprint of infrastructure modules, in order to make room for memory demands elsewhere in the system. Second is the minimization of data volume to be downlinked, through various methods such as the incorporation of new compression options. Third is the maximization of the available downlink bandwidth for data, by curtailing content-less data (fill) and introducing an improved UHF proximity link protocol. Fourth is a reduction in vulnerabilities, through increased file system redundancy, robustness, and software process monitoring. Fifth is an increase in operations efficiency by lowering file system mount times, improving parallelism between simultaneous events, minimizing the time to recover from file system errors, streamlining the purging of obsolete data, and reducing the number of commands to service parameters by a factor of 100.Individually, none of the cross-cutting infrastructure improvements are likely to garner headlines, but collectively they appreciably improve the safety and operability of Perseverance over its predecessor. This paper will describe the improvements, their promise, and where applicable, their actual impact in operations.

Bohannon, Emily↗
NASA NTRS2022

Mid-Air Helicopter Delivery at Mars Using a Jetpack

Mid-Air Helicopter Delivery (MAHD) is a new Entry, Descent and Landing (EDL) architecture to enable in situ mobility for Mars science at lower cost than previous rover missions. It uses a jetpack to slow down a Mars Science Helicopter (MSH) after separation from the backshell, and reach aerodynamic conditions suitable for helicopter take-off in mid air. MAHD's lander-free approach leaves enough room in the aeroshell to accommodate larger rotors. This drastically improves flight performance compared to heritage EDL approaches, notably +60\% science payload mass. MAHD also brings cost savings, a simpler architecture, improved surface access and can reach higher elevations on Mars. This paper introduces a design for the MAHD system architecture and operations. We present a mechanical configuration which fits both MSH and the jetpack within the 2.65-m Mars heritage aeroshell, and a jetpack control architecture which fully leverages the available helicopter avionics. We discuss preliminary numerical models of the flow dynamics resulting from the interaction between the jets, the rotors and the side winds. We define a force-torque sensing architecture capable of handling the wind and trimming the rotors to prepare for safe take-off. Finally, we analyze the dynamic environment and closed-loop control simulation results to demonstrate the preliminary feasibility of MAHD.

Balaram, J.↗
NASA NTRS2022

Flight Rule Design, Implementation, Verification, and Validation for the Psyche Mission

NASA Jet Propulsion Lab (JPL)’s upcoming mission Psyche will begin its journey to the asteroid (16) Psyche in late 2022 in an effort to better understand its origins and, in turn, better understand our own. Operating the spacecraft safely will require the dedicated efforts of a small team that understands the spacecraft’s operational constraints, as well as a set of powerful spacecraft models designed to catch command errors that can pose risks to mission success. One of the responsibilities of the operations team is to ensure adherence to a set of Flight Rules written by spacecraft and instrument experts that are designed to mitigate these risks. Psyche’s innovations in Flight Rule design principles and advancements in the tools and processes used to implement and check Flight Rules are discussed. A comparison of Psyche’s approach to Flight Rules to other JPL missions will provide lessons learned for future missions that must perform constraint checking during operations. Flight Rule development faces several major challenges. First, flight rule developers must work with Subject Matter Experts (SME) to write the rules in a way that captures the intent of the constraint in a straightforward, enforceable manner. Second, software implementers must correctly interpret flight rules into code so that it meets the original intent of the SME. Finally, a means must be provided for SMEs to validate flight rule implementations without requiring them to understand the underlying software. Innovative processes intended to efficiently close the loop between stakeholders and software developers are described, such as the use of test-driven development to provide stakeholders with easy-to-review implementations. New guidelines for flight rule writing, designed to address these challenges, are described for future missions to adopt and build upon. Psyche Mission System has a variety of new and heritage tools that improve in the Flight Rule validation and checking process. Psyche developed a powerful, new tool called RandSEQ and made significant improvements to Octopusjam, two valuable tools that aid the development of Flight Rule unit tests. Advancements in the models and processes for performing sequence validation with SEQuence GENerator (SEQGEN), the primary, high-heritage tool used for automated flight rule checks on Psyche, are described. The development of new software and the advancements to existing software put Psyche at the forefront of Flight Rule technology. All missions must perform detailed constraint checking, so a comparison of Psyche’s approach to some of these items to the approaches taken by other missions such as Dawn, M2020, and Europa Clipper is done, specifically to examine SME-developer communication, tools used, and development process. Lessons learned from this comparison will be provided.

Weise, Tim↗
NASA NTRS2022

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo↗
NASA NTRSDate not supplied

Tropical Convection Through the Lens of the INCUS Mission

The overarching goal of the recently selected NASA INvestigation of Convective UpdraftS (INCUS) mission is to enhance our understanding of why, when and where tropical convective storms form, and why only some of these storms produce extreme weather. Convective storms provide an important pathway for the transport of air and water between Earth’s surface and the upper troposphere. This vertical transport of air and water, often referred to as convective mass flux (CMF), plays a critical role in Earth’s weather and climate system through its impacts on microphysical and precipitation rates, detrainment and upper tropospheric moistening, high cloud feedbacks, and the large-scale circulation. Potential changes to the CMF as a function of the local environment or with changing climates may also have significant implications for severe weather such as flood-producing rainfall, damaging hail and lightning. In spite of the critical role of this vertical transport of water and air, representation of CMF remains a major source of error in weather and climate models, thereby limiting our ability to accurately predict convective storms and their impacts. The tropics-wide observations from INCUS will enhance our understanding of tropical convective storm processes and will provide guidance for representing these processes in numerical models across scales. INCUS is comprised of three SmallSat platforms each carrying a RainCube-heritage Ka-band 7-beam scanning radar. The satellite platforms will be 30 and 90 seconds apart, thus providing three time intervals (30, 90 and 120 seconds) over which observations will be made. INCUS will investigate CMF using a novel time-differenced radar reflectivity profile approach. In addition to the Ka-band radar, a single TEMPEST-D-heritage cross-track-scanning passive microwave radiometer will be housed on the middle SmallSat. The radiometer will provide extensive storm context for the radar observations, as well as observations of the convective anvils. The combination of the radars and radiometer on INCUS will deliver unprecedented three-dimensional views of tropical convective storms. INCUS is the first systematic investigation of the rapidly evolving CMF within tropical convective storms, the observations of which are expected to significantly enhance both our understanding and prediction of storm structure, their dynamics and microphysical processes, and the ways in which these evolve over storm lifetimes. This presentation will highlight the observational capabilities and scientific approach of the INCUS mission.

Susan C. van den Heever↗
NASA NTRS2023

Flex-Capsules for the Roman Space Telescope High Gain Antenna Gimbal

The Cable Wrap mechanism has been traditionally used for feeding power and telemetry through each gimbal actuator exiting at the gimbal output flange. Such a mechanism had often utilized round wire bundles or a multitude of single insulated conductors woven together flatwise to handle the angular rotation. Though flexible printed circuit board (PCB) is not a new technology, it was decided to implement it for the Roman Space Telescope (RST) High Gain Antenna Gimbal in an effort to improve reliability with consistency of manufacture and to save mass and minimize required volume. This paper provides a description of what we term Flex-Capsule (a similar vendor flight development is termed Twist Capsule), discusses the reasoning behind choosing a new engineering development over maintaining heritage, and includes commentary pertaining to life cycle analysis, electrical performance, and flexible PCB lubrication. Lessons learned from the design, analysis, and test campaign are also included. The conclusion is that benefits of pursuing the Flex-Capsule over heritage Cable Wrap have been realized.

twist capsule↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗
NASA NTRSDate not supplied

Mission Overview and Status IGARSS Conference

The Plankton, Aerosol, Cloud, ocean Ecosystem (PACE) mission is a strategic climate continuity mission that was defined in the 2010 document Responding to the Challenge of Climate and Environmental Change: NASA’s Plan for Climate-Centric Architecture for Earth Observations and Applications from Space (referred to as the “Climate Initiative”). Scheduled for launch in January 2024, the PACE mission represents NASA’s next investment in ocean biology, clouds, and aerosol data records [1]. PACE will extend the high quality ocean ecological, ocean biogeochemical, cloud, and aerosol particle data records begun by NASA in the 1990s, building on the exceptional heritages of the Sea-Viewing Wide Field-of-View Sensor (SeaWiFS), the Moderate Resolution Imaging Spectroradiometer (MODIS), the Multi-angle Imaging SpectroRadiometer (MISR), and the Visible Infrared Imaging Radiometer Suite (VIIRS). The PACE project office at NASA’s GSFC is responsible for the satellite development, launch and operations. The NASA Headquarters PACE Program Science office is responsible for supporting the science data processing system and assembling competed community science teams, which will include field-based vicarious calibration and data product validation efforts to support the PACE Project Science team. The mission is planned for launch into a Sun synchronous polar orbit at 676.5 km with an inclination of 98 degrees and a 1 pm local ascending node crossing time. The PACE observatory is comprised of three instruments, an Ocean Color Instrument (OCI) and two polarimeters, the Hyper-Angular Rainbow Polarimeter 2 (HARP2) and the Spectro-Polarimeter for Exploration (SPEXone). The OCI is the primary instrument on the observatory and is being developed at Goddard Space Flight Center (GSFC). The OCI is a hyperspectral scanning radiometer designed to measure spectral radiances from the ultraviolet to shortwave infrared (SWIR) to enable advanced ocean color and heritage cloud and atmospheric aerosol science [2]. The HARP2 and SPEXone are complimentary instruments on the PACE observatory, acquired outside of GSFC. The HARP2 is multi-spectral, wide swath (supporting atmospheric correction of OCI), and hyper-angular, with capabilities for cloud science that exceed what is capable from OCI alone. The SPEXone is narrow swath, multi-angular, and hyperspectral, with capabilities for atmospheric aerosol science that exceed what can be accomplished with OCI. NASA Headquarters directed the mission development to be guided by a Design-to-Cost (DTC) process. All elements of the mission, other than the cost, are in the DTC trade space. At the heart of the DTC process are the mission studies, performed across all the mission elements. The mission studies were used to define appropriate approaches within and across elements while maximizing science capabilities at a high cost confidence. Mission baseline requirements development is also embedded within the DTC process, as these requirements were not established at the onset of the mission concept development. Baseline mission requirements are a product of the mission studies and are defined by the project office as part of the DTC process. At the time of this writing, OCI, HARP2 and SPEXone are integrated onto the PACE spacecraft, creating the PACE observatory. The instruments and spacecraft subsystems are undergoing combined functional performance testing in preparation for observatory-level environmental testing prior to shipment to the launch site. Here, we will provide an update on science capabilities and observatory readiness for its early 2024 launch.

remote sensing↗
NASA NTRSDate not supplied

Orion's Powered Flight Guidance Performance During Artemis I

Artemis is NASA’s campaign to explore the Moon and beyond. Artemis I, the un-crewed exo-LEO test flight, was completed in 2022. The Artemis I mission provided the means to prove-out both vehicle and systems as a pre-cursor to more advanced missions. The Orion capsule and service module had to be capable of accurately executing all major orbital burns and numerous correction burns to successfully execute the mission profile. In support of this needed translation maneuver capability, a powered flight guidance algorithm has been designed that provides a number of guided burn options depending on the burn objective. Some of these guidance options are based on classic orbit transfer problems, such as Lambert's time-of-flight problem. Some are based on proven NASA heritage manned space programs like Apollo and Shuttle. Some are new concepts that fill unique niche requirements. All of these options are integrated into an architecture based on a proven Shuttle heritage design, with a simple closed-loop guidance strategy, that provides both modularity, simplicity and adaptability to future, as yet to be defined, mission profiles. This paper will summarize the performance of Orion’s orbital powered flight guidance during the mission.

space guidance↗
NASA NTRS2023

Flex-Capsule for the Roman Space Telescope High Gain Antenna Gimbal

The Cable Wrap mechanism has been traditionally used for feeding power and telemetry through each gimbal actuator exiting at the Gimbal output flange. Such a mechanism had often utilized round wire bundles, or a multitude of single insulated conductors woven together flatwise to handle the angular rotation. Though flexible printed circuit board (PCB) is not a new technology, it was decided to implement it for the Roman Space Telescope (RST) High Gain Antenna Gimbal in an effort to improve reliability with consistency of manufacture and to save mass and minimize required volume. This paper provides a description of what we term Flex-Capsule (a similar vendor flight development is termed Twist Capsule), discusses the reasoning behind choosing a new engineering development over maintaining heritage, and includes commentary pertaining to life cycle analysis, electrical performance, and flexible PCB lubrication. Lessons learned from the design, analysis, and test campaign are also included. The conclusion is that benefits of pursuing the Flex-Capsule over heritage Cable Wrap have been realized.

twist capsule↗
NASA NTRSDate not supplied

Overview of the MISSE-16 Mission and Preliminary Characterization of Novel Space Weathered Materials

The Materials International Space Station Experiment (MISSE) project is a series of experiments that began in 2001, involving the deployment of external experiment platforms on the International Space Station (ISS). Since then, more than 4,000 materials were tested yielding valuable data and insights into the performance of materials and coatings in the harsh space environment, as well as providing a platform for testing and validating new materials and technologies. The results of the MISSE experiments have contributed to the development of more durable and reliable spacecraft and equipment, as well as improving our understanding of the space environment and its effects on human space exploration. To gain deeper insights into the changes in material properties of both novel and heritage spacecraft materials over the course of a mission, we proposed to enhance the MISSE hardware. This was achieved by integrating a high-resolution camera that can capture both RGB and IR color data, along with an updated illumination scheme. The identical sets of selected materials were mounted on the Zenith, Ram, and Wake faces of the ISS to expose them to predominant vacuum ultraviolet (VUV), atomic oxygen, and high-energy electron conditions. In addition, we exposed flight duplicates of these materials to a simulated space environment, which included sequential exposure to the same irradiation species on the ground. This allowed us to study the effects of space exposure on the materials in a controlled manner and to compare their behavior in both real and simulated space environments. The MISSE-FF flight sample collection comprised different classes of polymers, including polyimides from the Kapton family, manufactured by E.I du Pont de Nemours and Co., Polyethylene terephthalate (PET) materials, liquid crystal polymers, PI/Polyhedral Oligomeric Silsesquioxanes (POSS), and carbon and glass fiber reinforced polymers. The experimental cadence during the MISSE-16 mission (~6 months) included daily images of each sample for the first week, weekly for the next 2 months, and monthly the remaining duration of the mission. This paper will focus on the flight duplicate as well as the postflight optical characterization of novel and heritage materials currently under observation on the MISSE-FF.

Jainisha R Shah↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗