Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Ground System”

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 1,027 records · Page 57

NASA's Space Launch System Begins Integration, Stacking in Preparation for Artemis I Launch

The Artemis era of human lunar exploration is nearing take-off as NASA’s new super heavy-lift launch vehicle, the Space Launch System (SLS), begins stack-ing and integration operations in mid-2020 at Kennedy Space Center (KSC) in Florida. With a planned upgrade path to progressively more powerful vehicles and availability in crew and cargo configurations, SLS provides a unique and flexible launch solution to send crew, large-scale infrastructure and robotic probes to deep space. The SLS Block 1 vehicle, the initial variant to fly, is optimized for lunar missions with a proven propulsion system consisting of four liquid hydrogen (LH2)/liquid oxygen (LOX)-fed RS-25 engines and twin five-segment solid rocket boosters (SRBs). The Block 1 vehicle can also be outfitted with an industry-standard 5 m-class payload fairing (the “cargo” configuration) and will launch at least 27 metric tons (t) of mass to trans-lunar injection (TLI). SLS is the backbone of NASA’s Artemis program, which will return the agency’s human spaceflight program to the Moon for the first time since 1972. For the Artemis I mission, SLS will send an uncrewed Orion spacecraft to TLI, where it will enter a distant retrograde lunar orbit and fly 38,000 nmi past the Moon – farther than any spacecraft built for humans has ever traveled. The SLS Block 1 vehicle for Artemis I completed manufacturing in 2019. Several elements, including the upper stage, have been delivered to the Exploration Ground Systems (EGS) program at KSC and are being prepped for integration and stack-ing. The five-segment solid rocket boosters – the largest and most powerful ever built for flight – are also complete. The booster motor segments for the Artemis I flight are scheduled to ship from prime contractor Northrop Grumman’s Utah facilities and begin stacking and integration at KSC in June 2020. The SLS core stage is the largest rocket stage NASA has ever built in terms of volume and height, and includes the avionics and the tanks that feed cryogenic propellant to the four RS-25s (formerly Space Shuttle Main Engines [SSMEs]). They have been modified with an updated controller and nozzle insulation to protect them from the hotter launch environment. The SLS core stage is currently being test-ed at NASA’s Stennis Space Center (SSC) in a series of “green run” tests to verify it meets design and performance requirements. Following the green run test series, which is scheduled to culminate with a full-duration hot-fire of the four RS-25 engines, the core stage will ship to KSC and be stacked between the sol-id rocket boosters in the Vehicle Assembly Building (VAB). Integration of the vehicle will continue with the upper stage, known as the Interim Cryogenic Propulsion Stage (ICPS) and the Launch Vehicle Stage Adapter (LVSA) on the core stage. Another adapter, the Orion Stage Adapter (OSA), connects SLS to Orion and provides housing for 13 6U CubeSat payloads manifested on Artemis I. The CubeSats will be released in deep space after Orion separates from the vehicle, and the flight marks the first ride share opportunity for independent small-sats to deep space. The second major SLS variant to come online, Block 1B, replaces the single-engine ICPS with a four-engine LH2/LOX Exploration Upper Stage (EUS). This more powerful upper stage, along with other vehicle up-grades, will enable the Block 1B vehicle to launch 38-42 t to TLI, depending on crew or cargo configuration. The final evolution of the vehicle, Block 2, will onramp evolved solid rocket boosters to increase mass to TLI to 43-46 t, de-pending on crew or cargo configuration. The Block 1B/Block 2 vehicles can be outfitted with an 8.4 m-diameter payload fairing in 19.1 m or 27.4 m lengths, to provide unprecedented volume for payloads. With the initial Block 1 vehicle completely manufactured and the core stage in final testing before shipping to KSC, the SLS Program and its industry partners have made significant progress manufacturing subsequent vehicles. For the second Block 1 vehicle, the solid rocket motor segments are complete, as are the RS-25 engines with controllers. All five major components of the Artemis II core stage – the forward skirt, LOX and LH2 tanks, intertank and engine section – are manufactured and technicians are installing subsystems at NASA’s rocket factory, Michoud Assembly Facility. The RL-10 engine for the Artemis II ICPS is complete and panels have been machined for its LH2 tank. In addition, panels are machined for the vehicle’s two adapters, with welding scheduled to begin in summer 2020. Flight hard-ware is also in production for the third SLS vehicle, with several booster motor segments cast. The pace of development on the EUS has increased, with the goal to complete Critical Design Review (CDR) in December 2020. Several EUS test rings have been machined at Michoud. The EUS is designed to exe-cute a variety of missions – human spaceflight, deployment of deep-space infra-structure, or high-C3 missions to the outer solar system – with crew and cargo configurations available beginning in the mid-2020s. The near-term goal for the nation’s powerful new space exploration asset, however, is to launch the Arte-mis program, and send the first woman and the next man to the lunar surface. At the Astrodynamics Specialist Conference, the SLS program will update the community on the progress of the initial Block 1 vehicle in final green run test-ing, integration and stacking. In addition, this paper will provide an update to the community on the manufacturing status of subsequent Block 1 and Block 1B vehicles.

Steve Creech↗

Lessons Learned for Planning and Estimating Operations Support Requirements

Operations (phase E) costs are typically small compared to the spacecraft development and test costs. This, combined with the long lead time for realizing operations costs, can lead projects to focus on hardware development schedules and costs, de-emphasizing estimation of operations support requirements during proposal, early design, and replan cost exercises. The Discovery and New Frontiers (D&NF) programs comprise small, cost-capped missions supporting scientific exploration of the solar system. Even moderate yearly underestimates of the operations costs can present significant LCC impacts for deep space missions with long operational durations, and any LCC growth can directly impact the programs ability to fund new missions. The D&NF Program Office at Marshall Space Flight Center recently studied cost overruns for 7 D&NF missions related to phase C/D development of operational capabilities and phase E mission operations. The goal was to identify the underlying causes for the overruns and develop practical mitigations to assist the D&NF projects in identifying potential operations risks and controlling the associated impacts to operations development and execution costs. The study found that the drivers behind these overruns include overly optimistic assumptions regarding the savings resulting from the use of heritage technology, late development of operations requirements, inadequate planning for sustaining engineering and the special requirements of long duration missions (e.g., knowledge retention and hardware/software refresh), and delayed completion of ground system development work. This presentation summarizes the study and the results, providing a set of lessons NASA can use to improve early estimation and validation of operations costs.

Newhouse, Marilyn↗

NASA’s Space Launch System: Exploration Mission-1 Hardware Nears Completion

The Space Launch System (SLS) Program completed several significant production milestones in 2018 for the launch vehicle’s first mission (Fig. 1) and is poised for greater accomplishments in 2019. With manufacturing and hardware installation finished, Boeing completed the core stage forward join and shipped the liquid hydrogen tank structural test article to Marshall Space Flight Center for testing. The core stage aft join and LOX tank STA are expected to be completed in 2019 on the way to final stage integration. The four EM-1 engines are poised for stage integration in 2019. The Launch Vehicle Stage Adapter completed outfitting at Marshall and will be shipped to Kennedy Space Center in 2019. All solid rocket motor segments for the EM-1 boosters are cast, inspected and ready for shipment to KSC. The upper stage, the Interim Cryogenic Propulsion Stage (ICPS), and the Orion Stage Adapter (OSA), where 13 6U CubeSats will ride to deep space on EM-1, were completed and delivered to Exploration Ground Systems at KSC in 2017 and 2018, respectively. The Program continues to work toward first launch of the nation’s new super heavy lift deep space capability in fiscal 2020. SLS is designed, engineered and tested to launch the most challenging exploration missions, minimizing risk and providing the greatest opportunity for mission success. This paper will discuss the technical and programmatic successes and challenges of the past year and look ahead to plans for 2019.

Honeycutt, John↗

NASA's Space Launch System Moves into Testing and Integration

NASA's Space Launch System (SLS) has moved from design and manufacturing into testing and integration for its first flight as early as December 2019. In 2017, the NASA/industry team completed manufacturing of all major structural elements for the launch vehicle for Exploration Mission-I (EM-1 ). That work included shipping the first major flight hardware element to the launch site. The team processed all four RS-25 engines for stage integration, cast all 10 booster flight motor segments, and manufactured all five major sections of the core stage. The program also completed major structural work on the B-2 test stand at Stennis Space Center, which will be used for the core stage "green run" test; delivered the core stage and engine simulators used for training; and much of the transportation equipment for the core stage. Engineers completed structural testing on the upper stage/payload section of the vehicle as well as the engine section test article. In 2018, the program will deliver the Orion Stage Adapter (OSA) to Exploration Ground Systems (EGS) at KSC and send the test articles for the core stage liquid hydrogen tank, liquid oxygen tank, and intertank to NASA's Marshall Space Flight center for structural testing. Additionally, workers will begin the challenging process of integrating the major sections of the 212-foot EM-1 core stage. This work is focused on the initial Block 1 variant of SLS, capable of launching more than 70 metric tons (t) to low Earth orbit (LEO). However, work concurrently is underway on the Block lB variant, which will enable 105 t to LEO and more than 37t to trans-lunar injection (TLI). Block lB will be the workhorse vehicle of NASA's lunar exploration plans. As the needs of the nation's deep space exploration program grow, SLS performance is designed to evolve to a payload mass of 130 t to LEO and up to 45t to TLI. The advantages of this mass - as well as volume- are critical to the entire exploration architecture for deep space exploration. They translate to greater capability, greater infrastructure and operational simplicity, less overall mission risk, and opportunities to accomplish unprecedented exploration and discovery. This paper will discuss SLS progress to date and planned future work.

Honeycutt, John↗

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

Interfacing Space Communications and Navigation Network Simulation with Distributed System Integration Laboratories (DSIL)

NASA's planned Lunar missions will involve multiple NASA centers where each participating center has a specific role and specialization. In this vision, the Constellation program (CxP)'s Distributed System Integration Laboratories (DSIL) architecture consist of multiple System Integration Labs (SILs), with simulators, emulators, testlabs and control centers interacting with each other over a broadband network to perform test and verification for mission scenarios. To support the end-to-end simulation and emulation effort of NASA' exploration initiatives, different NASA centers are interconnected to participate in distributed simulations. Currently, DSIL has interconnections among the following NASA centers: Johnson Space Center (JSC), Kennedy Space Center (KSC), Marshall Space Flight Center (MSFC) and Jet Propulsion Laboratory (JPL). Through interconnections and interactions among different NASA centers, critical resources and data can be shared, while independent simulations can be performed simultaneously at different NASA locations, to effectively utilize the simulation and emulation capabilities at each center. Furthermore, the development of DSIL can maximally leverage the existing project simulation and testing plans. In this work, we describe the specific role and development activities at JPL for Space Communications and Navigation Network (SCaN) simulator using the Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) tool to simulate communications effects among mission assets. Using MACHETE, different space network configurations among spacecrafts and ground systems of various parameter sets can be simulated. Data that is necessary for tracking, navigation, and guidance of spacecrafts such as Crew Exploration Vehicle (CEV), Crew Launch Vehicle (CLV), and Lunar Relay Satellite (LRS) and orbit calculation data are disseminated to different NASA centers and updated periodically using the High Level Architecture (HLA). In addition, the performance of DSIL under different traffic loads with different mix of data and priorities are evaluated.

Traffic Measuring and Monitoring↗

Planning and Estimation of Operations Support Requirements

Life Cycle Cost (LCC) estimates during the proposal and early design phases, as well as project replans during the development phase, are heavily focused on hardware development schedules and costs. Operations (phase E) costs are typically small compared to the spacecraft development and test costs. This, combined with the long lead time for realizing operations costs, can lead to de-emphasizing estimation of operations support requirements during proposal, early design, and replan cost exercises. The Discovery and New Frontiers (D&NF) programs comprise small, cost-capped missions supporting scientific exploration of the solar system. Any LCC growth can directly impact the programs' ability to fund new missions, and even moderate yearly underestimates of the operations costs can present significant LCC impacts for deep space missions with long operational durations. The National Aeronautics and Space Administration (NASA) D&NF Program Office at Marshall Space Flight Center (MSFC) recently studied cost overruns and schedule delays for 5 missions. The goal was to identify the underlying causes for the overruns and delays, and to develop practical mitigations to assist the D&NF projects in identifying potential risks and controlling the associated impacts to proposed mission costs and schedules. The study found that 4 out of the 5 missions studied had significant overruns at or after launch due to underestimation of the complexity and supporting requirements for operations activities; the fifth mission had not launched at the time of the mission. The drivers behind these overruns include overly optimistic assumptions regarding the savings resulting from the use of heritage technology, late development of operations requirements, inadequate planning for sustaining engineering and the special requirements of long duration missions (e.g., knowledge retention and hardware/software refresh), and delayed completion of ground system development work. This paper updates the D&NF LCC study, looking at the operations (phase E) cost drivers in more detail and extending the study to include 2 additional missions and identifies areas for increased emphasis by project management in order to improve the fidelity of operations estimates.

Newhouse, Marilyn E.↗

Design and Development of Functionally Effective Human-Machine Interfaces for Firing Room Displays

This project involves creating software for support equipment used on the Space l aunch System (SLS). The goal is to create applications and displays that will be used to remotely operate equipment from the firing room and will continue to support the SLS launch vehicle to the extent of its program. These displays include design practices that help to convey information effectively, such as minimizing distractions at normal operating state and displaying intentional distractions during a warning or alarm state. The general practice for creating an operator display is to reduce the detail of unimportant aspects of the display and promote focus on data and dynamic information. These practices include using minimalist design, using muted tones for background colors, using a standard font at a readable text size, displaying alarms visible for Immediate attention, grouping data logically, and displaying data appropriately varying on the type of data. Users of these displays are more likely to stay focused on operating for longer periods by using design practices that reduce eye strain and fatigue. Effective operator displays will improve safety by reducing human errors during operation, which will help prevent catastrophic accidents. This report entails the details of my work on developing remote displays for the Hypergolics ground system. Before developing a prototype display, the design and requirements of the system are outlined and compiled into a document. Then each subsystem has schematic representations drawn tha.t meet the specifications detailed in the document. The schematics are then used as the outline to create display representations of each subsystem. Each display is first tested individually. Then the displays are integrated with a prototype of the master system, and they are tested in a simulated environment then retested in the real environment. Extensive testing is important to ensure the displays function reliably as intended.

Cho, Henry↗

Maximally Expressive Task Modeling

Planning and scheduling systems organize "tasks" into a timeline or schedule. The tasks are defined within the scheduling system in logical containers called models. The dictionary might define a model of this type as "a system of things and relations satisfying a set of rules that, when applied to the things and relations, produce certainty about the tasks that are being modeled." One challenging domain for a planning and scheduling system is the operation of on-board experiment activities for the Space Station. The equipment used in these experiments is some of the most complex hardware ever developed by mankind, the information sought by these experiments is at the cutting edge of scientific endeavor, and the procedures for executing the experiments are intricate and exacting. Scheduling is made more difficult by a scarcity of space station resources. The models to be fed into the scheduler must describe both the complexity of the experiments and procedures (to ensure a valid schedule) and the flexibilities of the procedures and the equipment (to effectively utilize available resources). Clearly, scheduling space station experiment operations calls for a "maximally expressive" modeling schema. Modeling even the simplest of activities cannot be automated; no sensor can be attached to a piece of equipment that can discern how to use that piece of equipment; no camera can quantify how to operate a piece of equipment. Modeling is a human enterprise-both an art and a science. The modeling schema should allow the models to flow from the keyboard of the user as easily as works of literature flowed from the pen of Shakespeare. The Ground Systems Department at the Marshall Space Flight Center has embarked on an effort to develop a new scheduling engine that is highlighted by a maximally expressive modeling schema. This schema, presented in this paper, is a synergy of technological advances and domain-specific innovations.

Japp, John↗

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

Processing of KaRIn/SWOT Data

The Surface Water and Ocean Topography (SWOT) mission [1] is part of NASA’s Decadal Survey Program, and prepared jointly by NASA’s Jet Propulsion Laboratory (JPL), the French space agency (CNES), and the Canadian space agency (CSA). Launch is currently foreseen in 2020. The principal instrument KaRIn (Ka-band Radar Interferometer) would be a bistatic SAR system operating at Kaband, with 200 MHz bandwidth, covering 50 km wide near-nadir swaths (1-4° incidence) on both sides of the satellite track. The nominal payload also would include a conventional Ku/C-band nadir altimeter, a water vapor radiometer, and a precise orbit determination suite. Moreover, additional near-nadir channels from KaRIn to reduce the gap between the nominal swaths may be considered. The main mission goals would be to improve the spatio-temporal coverage of the oceans with respect to today’s nadir-looking altimeters (such as the Jason series), by providing measurements on a 1 km2 grid with virtually complete coverage up to ±78° latitude, while keeping a height precision of 1-2 cm, and to extend the altimetry measurements to continental water surfaces, including lakes, reservoirs and wetlands bigger than 250x250 m2 and rivers down to a width of 100 m (50 m as a goal), with a height precision of the order of 10 cm, represented with a horizontal point spacing of about 50 m. The fine scale of the measurements, with continuous acquisition over both oceans and continents, will result in huge data volumes, starting at the spacecraft and flowing through all links of the ground system. Furthermore, the centimetric height accuracy required means that all aspects of the processing must be considered carefully. In this article we give an overview of the foreseen data products and data processing chains for KaRIn on SWOT. Some particularly challenging processing steps are (will be) described in more detail.

Desroches, Damien↗

Operational Modal Analysis of the Artemis I Dynamic Rollout Test and Wet Dress Rehearsal

NASA has developed an expendable heavy lift launch vehicle capability, the Space Launch System (SLS), to support lunar and deep space exploration. The uncrewed Artemis I was the first flight of this new launch vehicle and tested critical systems for the upcoming crewed Artemis II flight to the moon. Accelerations were recorded at a multitude of locations on Artemis, the Mobile Launcher (ML), and the Crawler Transporter (CT)during the rollout of Artemis I from the Vehicle Assembly Building (VAB) to Launch Pad 39B March 2022 and is referred to as the Artemis I Dynamic Rollout Test (DRT). While Artemis I was at Launch Pad 39B, the Wet Dress Rehearsal (WDR) was performed to demonstrate launch readiness and acceleration measurements were also recorded. Finally, Artemis I rolled back from Launch Pad 39B to the VAB in April 2022, where acceleration measurements were also recorded and is referred to as the rollback portion of DRT. Because the forces during rollout and at the launch pad acting on Artemis I, the ML, and the CT are not directly measurable, Operational Modal Analysis (OMA) techniques, instead of traditional Experimental Modal Analysis (EMA) techniques, were used to identify modal characteristics. The OMA analysis of DRT and WDR directly builds upon the lessons learned from the OMA analysis of an earlier rollout of the ML from the VAB. DRT and WDR dynamic characteristics will be used to support SLS Integrated Modal Test finite element model correlation efforts and Exploration Ground System ML and CT finite element model verification and validation, which are part of the Building Block approach the Space Launch System program has implemented. The dynamic characteristics extracted from DRT as well as the rollout acceleration time histories themselves will be used in the development of generic rollout forcing functions that will provide refined estimates of the Artemis IV rollout forces, which will have the heavier and larger SLS Block 1B launch vehicle and Mobile Launcher 2 (ML-2). This paper briefly describes Artemis I, the ML, and the CT physical characteristics, DRT rollout/rollback and WDR data collection, the challenges in implementing OMA techniques due in part to the CT harmonics, and how these challenges were overcome to obtain the Artemis I DRT configuration and WDR configuration modal characteristics.

Apollo↗

Operational Modal Analysis of the Artemis I Dynamic Rollout Test and Wet Dress Rehearsal

NASA has developed an expendable heavy lift launch vehicle capability, the Space Launch System (SLS), to support lunar and deep space exploration. The uncrewed Artemis I was the first flight of this new launch vehicle and tested critical systems for the upcoming crewed Artemis II flight to the moon. Accelerations were recorded at a multitude of locations on Artemis, the Mobile Launcher (ML), and the Crawler Transporter (CT)during the rollout of Artemis I from the Vehicle Assembly Building (VAB) to Launch Pad 39B March 2022 and is referred to as the Artemis I Dynamic Rollout Test (DRT). While Artemis I was at Launch Pad 39B, the Wet Dress Rehearsal (WDR) was performed to demonstrate launch readiness and acceleration measurements were also recorded. Finally, Artemis I rolled back from Launch Pad 39B to the VAB in April 2022, where acceleration measurements were also recorded and is referred to as the rollback portion of DRT. Because the forces during rollout and at the launch pad acting on Artemis I, the ML, and the CT are not directly measurable, Operational Modal Analysis (OMA) techniques, instead of traditional Experimental Modal Analysis (EMA) techniques, were used to identify modal characteristics. The OMA analysis of DRT and WDR directly builds upon the lessons learned from the OMA analysis of an earlier rollout of the ML from the VAB. DRT and WDR dynamic characteristics will be used to support SLS Integrated Modal Test finite element model correlation efforts and Exploration Ground System ML and CT finite element model verification and validation, which are part of the Building Block approach the Space Launch System program has implemented. The dynamic characteristics extracted from DRT as well as the rollout acceleration time histories themselves will be used in the development of generic rollout forcing functions that will provide refined estimates of the Artemis IV rollout forces, which will have the heavier and larger SLS Block 1B launch vehicle and Mobile Launcher 2 (ML-2). This paper briefly describes Artemis I, the ML, and the CT physical characteristics, DRT rollout/rollback and WDR data collection, the challenges in implementing OMA techniques due in part to the CT harmonics, and how these challenges were overcome to obtain the Artemis I DRT configuration and WDR configuration modal characteristics.

Apollo↗

Application of Fault Management Theory to the Quantitative Selection of a Launch Vehicle Abort Trigger Suite

The theory of System Health Management (SHM) and of its operational subset Fault Management (FM) states that FM is implemented as a "meta" control loop, known as an FM Control Loop (FMCL). The FMCL detects that all or part of a system is now failed, or in the future will fail (that is, cannot be controlled within acceptable limits to achieve its objectives), and takes a control action (a response) to return the system to a controllable state. In terms of control theory, the effectiveness of each FMCL is estimated based on its ability to correctly estimate the system state, and on the speed of its response to the current or impending failure effects. This paper describes how this theory has been successfully applied on the National Aeronautics and Space Administration's (NASA) Space Launch System (SLS) Program to quantitatively estimate the effectiveness of proposed abort triggers so as to select the most effective suite to protect the astronauts from catastrophic failure of the SLS. The premise behind this process is to be able to quantitatively provide the value versus risk trade‐off for any given abort trigger, allowing decision makers to make more informed decisions. All current and planned crewed launch vehicles have some form of vehicle health management system integrated with an emergency launch abort system to ensure crew safety. While the design can vary, the underlying principle is the same: detect imminent catastrophic vehicle failure, initiate launch abort, and extract the crew to safety. Abort triggers are the detection mechanisms that identify that a catastrophic launch vehicle failure is occurring or is imminent and cause the initiation of a notification to the crew vehicle that the escape system must be activated. While ensuring that the abort triggers provide this function, designers must also ensure that the abort triggers do not signal that a catastrophic failure is imminent when in fact the launch vehicle can successfully achieve orbit. That is, the abort triggers must have low false negative rates to be sure that real crew‐threatening failures are detected, and also low false positive rates to ensure that the crew does not abort from non‐crew‐threatening launch vehicle behaviors. The analysis process described in this paper is a compilation of over six years of lessons learned and refinements from experiences developing abort triggers for NASA's Constellation Program (Ares I Project) and the SLS Program, as well as the simultaneous development of SHM/FM theory. The paper will describe the abort analysis concepts and process, developed in conjunction with SLS Safety and Mission Assurance (S&MA) to define a common set of mission phase, failure scenario, and Loss of Mission Environment (LOME) combinations upon which the SLS Loss of Mission (LOM) Probabilistic Risk Assessment (PRA) models are built. This abort analysis also requires strong coordination with the Multi‐Purpose Crew Vehicle (MPCV) and SLS Structures and Environments (STE) to formulate a series of abortability tables that encapsulate explosion dynamics over the ascent mission phase. The design and assessment of abort conditions and triggers to estimate their Loss of Crew (LOC) Benefits also requires in‐depth integration with other groups, including Avionics, Guidance, Navigation and Control(GN&C), the Crew Office, Mission Operations, and Ground Systems. The outputs of this analysis are a critical input to SLS S&MA's LOC PRA models. The process described here may well be the first full quantitative application of SHM/FM theory to the selection of a sensor suite for any aerospace system.

Lo, Yunnhon↗

NASA Space Launch System Operations Strategy

The National Aeronautics and Space Administration's (NASA) Space Launch System (SLS) Program, managed at the Marshall Space Flight Center, is charged with delivering a new capability for human and scientific exploration beyond Earth orbit. The SLS also will provide backup crew and cargo services to the International Space Station, where astronauts have been training for long-duration voyages to destinations such as asteroids and Mars. For context, the SLS will be larger than the Saturn V, providing 10 percent more thrust at liftoff in its initial 70 metric ton (t) configuration and 20 percent more in its evolved 130 t configuration. The SLS Program knows that affordability is the key to sustainability. This paper will provide an overview of its operations strategy, which includes initiatives to reduce both development and fixed costs by using existing hardware and infrastructure assets to meet a first launch by 2017 within the projected budget. It also has a long-range plan to keep the budget flat using competitively selected advanced technologies that offer appropriate return on investment. To arrive at the launch vehicle concept, the SLS Program conducted internal engineering and business studies that have been externally validated by industry and reviewed by independent assessment panels. A series of design reference missions has informed the SLS operations concept, including launching the Orion Multi-Purpose Crew Vehicle on an autonomous demonstration mission in a lunar flyby scenario in 2017, and the first flight of a crew on Orion for a lunar flyby in 2021. Additional concepts address the processing of very large payloads, using a series of modular fairings and adapters to flexibly configure the rocket for the mission. This paper will describe how the SLS, Orion, and 21st Century Ground Systems programs are working together to create streamlined, affordable operations for sustainable exploration.

Singer, Joan A.↗

NASA Space Launch System Operations Strategy

The National Aeronautics and Space Administration s (NASA) Space Launch System (SLS) Program, managed at the Marshall Space Flight Center (MSFC), is charged with delivering a new capability for human and scientific exploration beyond Earth orbit (BEO). The SLS may also provide backup crew and cargo services to the International Space Station, where astronauts have been training for long-duration voyages to destinations such as asteroids and Mars. For context, the SLS will be larger than the Saturn V, providing 10 percent more thrust at liftoff in its initial 70 metric ton (t) configuration and 20 percent more in its evolved 130-t configuration. The SLS Program knows that affordability is the key to sustainability. This paper will provide an overview of its operations strategy, which includes initiatives to reduce both development and fixed costs by using existing hardware and infrastructure assets to meet a first launch by 2017 within the projected budget. It also has a long-range plan to keep the budget flat using competitively selected advanced technologies that offer appropriate return on investment. To arrive at the launch vehicle concept, the SLS Program conducted internal engineering and business studies that have been externally validated by industry and reviewed by independent assessment panels. A series of design reference missions has informed the SLS operations concept, including launching the Orion Multi-Purpose Crew Vehicle (MPCV) on an autonomous demonstration mission in a lunar flyby scenario in 2017, and the first flight of a crew on Orion for a lunar flyby in 2021. Additional concepts address the processing of very large payloads, using a series of modular fairings and adapters to flexibly configure the rocket for the mission. This paper will describe how the SLS, Orion, and Ground Systems Development and Operations (GSDO) programs are working together to create streamlined, affordable operations for sustainable exploration for decades to come.

Singer, Joan A.↗

Message Mode Operations for Spacecraft: A Proposal for Operating Spacecraft During Cruise and Mitigating the Network Loading Crunch

The NASA Deep Space Network (DSN) is a world-class spacecraft tracking facility with stations located in Spain, Australia and USA, servicing Deep Space Missions of many space agencies. The current system of scheduling spacecraft during cruise for multiple 8 hour tracking sessions per week currently leads to an overcommitted DSN. Studies indicate that future projected mission demands upon the Network will only make the loading problem worse. Therefore, a more efficient scheduling of DSN resources is necessary in order to support the additional network loading envisioned in the next few years: The number of missions is projected to increase from 25 in 1998 to 34 by 2001. In fact given the challenge of the NASA administrator, Dan Goldin, of launching 12 spacecraft per year, the DSN would be tracking approximately 90 spacecraft by 2010. Currently a large amount of antenna time and network resources are subscribed by a project in order to have their mission supported during the cruise phase. The recently completed Mars Pathfinder mission was tracked 3 times a week (8 hours/day) during the majority of its cruise to Mars. This paper proposes an innovative approach called Message Mode Operations (MMO) for mitigating the Network loading problem while continuing to meet the tracking, reporting, time management, and scheduling requirements of these missions during Cruise while occupying very short tracking times. MMO satisfies these requirements by providing the following services: Spacecraft Health and Welfare Monitoring Service Command Delivery Service Adaptive Spacecraft Scheduling Service Orbit Determination Service Time Calibration Service Utilizing more efficient engineering telemetry summarization and filtering techniques on-board the spacecraft and collapsing the navigation requirements for Doppler and Range into shorter tracks, we believe spacecraft can be adequately serviced using short 10 to 30 minute tracking sessions. This claim assumes that certain changes would have to he made in the way the Network traditionally services missions in Cruise. Furthermore, limiting spacecraft to short sessions will free up larger blocks of time in the tracking schedule to help accommodate future tracking demands soon to be placed upon the Network. This paper describes the key characteristics and benefits of MMO, the operational scenarios for its use, the required changes to the ground system in order to make this approach feasible and the results of two simulations: 1) to determine the effects of MMO on projected mission loading on the DSN and, 2) to determine the effect MMO has on spacecraft orbit determination.

Greenberg, Ed↗