Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “abort”

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 883 records · Page 49
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Managing Space System Faults: Coalescing NASA's Views

Managing faults and their resultant failures is a fundamental and critical part of developing and operating aerospace systems. Yet, recent studies have shown that the engineering "discipline" required to manage faults is not widely recognized nor evenly practiced within the NASA community. Attempts to simply name this discipline in recent years has been fraught with controversy among members of the Integrated Systems Health Management (ISHM), Fault Management (FM), Fault Protection (FP), Hazard Analysis (HA), and Aborts communities. Approaches to managing space system faults typically are unique to each organization, with little commonality in the architectures, processes and practices across the industry.

Muirhead, Brian↗
NASA NTRS2010

Reactive Sequencing for Autonomous Navigation Evolving from Phoenix Entry, Descent, and Landing

Virtual Machine Language (VML) is an award-winning advanced procedural sequencing language in use on NASA deep-space missions since 1997, and was used for the successful entry, descent, and landing (EDL) of the Phoenix spacecraft onto the surface of Mars. Phoenix EDL utilized a state-oriented operations architecture which executed within the constraints of the existing VML 2.0 flight capability, compatible with the linear "land or die" nature of the mission. The intricacies of Phoenix EDL included the planned discarding of portions of the vehicle, the complex communications management for relay through on-orbit assets, the presence of temporally indeterminate physical events, and the need to rapidly catch up four days of sequencing should a reboot of the spacecraft flight computer occur shortly before atmospheric entry. These formidable operational challenges led to new techniques for packaging and coordinating reusable sequences called blocks using one-way synchronization via VML sequencing global variable events. The coordinated blocks acted as an ensemble to land the spacecraft, while individually managing various elements in as simple a fashion as possible. This paper outlines prototype VML 2.1 flight capabilities that have evolved from the one-way synchronization techniques in order to implement even more ambitious autonomous mission capabilities. Target missions for these new capabilities include autonomous touch-and-go sampling of cometary and asteroidal bodies, lunar landing of robotic missions, and ultimately landing of crewed lunar vehicles. Close proximity guidance, navigation, and control operations, on-orbit rendezvous, and descent and landing events featured in these missions require elaborate abort capability, manifesting highly non-linear scenarios that are so complex as to overtax traditional sequencing, or even the sort of one-way coordinated sequencing used during EDL. Foreseeing advanced command and control needs for small body and lunar landing guidance, navigation and control scenarios, work began three years ago on substantial upgrades to VML that are now being exercised in scenarios for lunar landing and comet/asteroid rendezvous. The advanced state-based approach includes coordinated state transition machines with distributed decision-making logic. These state machines are not merely sequences - they are reactive logic constructs capable of autonomous decision making within a well-defined domain. Combined with the JPL's AutoNav software used on Deep Space 1 and Deep Impact, the system allows spacecraft to autonomously navigate to an unmapped surface, soft-contact, and either land or ascend. The state machine architecture enabled by VML 2.1 has successfully performed sampling missions and lunar descent missions in a simulated environment, and is progressing toward flight capability. The authors are also investigating using the VML 2.1 flight director architecture to perform autonomous activities like rendezvous with a passive hypothetical Mars sample return capsule. The approach being pursued is similar to the touch-and-go sampling state machines, with the added complications associated with the search for, physical capture of, and securing of a separate spacecraft. Complications include optically finding and tracking the Orbiting Sample Capsule (OSC), keeping the OSC illuminated, making orbital adjustments, and physically capturing the OSC. Other applications could include autonomous science collection and fault compensation.

asteroid↗
NASA NTRS2015

The Mission Accessibility of Near-Earth Asteroids

Astrodynamical Earth departure dates; mission v; mission duration; stay time; etc. Physical I NEO size(?); rotation rate; dust satellites environment; chemistry; etc. Architectural Launch vehicle(s); crew vehicle(s); habitat module(s); budget; etc. Operational Operations experience; abort options profiles; etc. Astrodynamical Accessibility is the starting point for understanding the options and opportunities available to us. Here we shall focus on. Astrodynamical Accessibility.2 Earth departure date between 2015-01-01 and 2040-12-31 Earth departure C3 60 km2s2. Total mission v 12 kms. The total v includes (1) the Earth departure maneuver from a 400 km altitude circular parking orbit, (2) the maneuver to match the NEAs velocity at arrival, (3) the maneuver to depart the NEA and, (4) if necessary, a maneuver to control the atmospheric re-entry speed during Earth return. Total round trip mission duration 450 days. Stay time at the NEA 8 days Earth atmospheric entry speed 12 kms at an altitude of 125 km. A near-Earth asteroid (NEA) that offers at least one trajectory solution meeting those criteria is classified as NHATS-compliant.

Trajectory Optimization↗
NASA NTRS2016

Concept of Operations for a Prospective "Proving Ground" in the Lunar Vicinity

NASA is studying conceptual architectures for a "Proving Ground" near the Moon or in high lunar orbit to conduct human space exploration missions that bridge the gap between today's operations with the International Space Station (ISS) and future human exploration of Mars beginning in the 2030s. This paper describes the framework of a concept of operations ("Conops") for candidate activities in the Proving Ground. The Conops discusses broad goals that the Proving Ground might address, such as participation from commercial entities, support for human landings on the Moon, use of mature technologies, and growth of capability through a steady cadence of increasingly ambitious piloted missions. Additional Proving Ground objectives are outlined in a companion paper. Key elements in the Conops include the Orion spacecraft (with mission kits for docking and other specialized operations) and the Space Launch System (SLS) heavy-lift rocket. Potential additions include a new space suit, commercial launch vehicles and logistics carriers, Solar Electric Propulsion (SEP) stages to move elements between different orbits and eventually take them on excursions to deep space, a core module with multiple docking ports, a habitation block, and robotic and piloted lunar landers. The landers might include reusable ascent modules which could remain docked to in-space elements between lunar sorties. A module providing advanced regenerative life support functions could launch to the ISS, and later move to the Proving Ground. The architecture will include infrastructure for launch preparation, communication, mission control, and range safety. The Conops describes notional missions chosen to guide the design of the architecture and its elements. One such mission might be the delivery of a approximately 10-t Transit Habitat element, comanifested with Orion on a Block 1B SLS launcher, to the Proving Ground. In another mission, the architecture might participate in direct human exploration of an asteroidal boulder brought to high lunar orbit by the Asteroid Redirect Mission. The Proving Ground stack could serve as a staging point and tele-operation center for robotic and piloted Moon landings. With the addition of a SEP stage, the architecture could support months-long excursions within and beyond the Earth's sphere of influence, possibly culminating in a year-long mission to land humans on a near-Earth asteroid. In the last case, after returning to near-lunar space, two of the asteroid explorers could join two crewmembers freshly arrived from Earth for a Moon landing, helping to quantify the risk of landing deconditioned crews on Mars. In a conceptual mission particularly stressing to system design, Proving Ground elements could transit to Mars orbit. Other possible design-driving operations include relocation of the stack with no crew on board, the unpiloted journey of the advanced life support module from ISS to the lunar vicinity, excursions to other destinations in near-Earth space, and additional support for Mars exploration in conjunction with the Evolvable Mars Campaign. The Proving Ground Conops concludes with a discussion of aborts and contingency operations

Love, Stanley G.↗
NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗
NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The engineering development of the new Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these spacecraft systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex system engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in specialized Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model based algorithms and their development lifecycle from inception through Flight Software certification are an important focus of this development effort to further insure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. NASA formed a dedicated M&FM team for addressing fault management early in the development lifecycle for the SLS initiative. As part of the development of the M&FM capabilities, this team has developed a dedicated testbed that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. Additionally, the team has developed processes for implementing and validating these algorithms for concept validation and risk reduction for the SLS program. The flexibility of the Vehicle Management End-to-end Testbed (VMET) enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS. The intent of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software development infrastructure and its related testing entities. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test cases into flight software compounded with potential human errors throughout the development lifecycle. Risk reduction is addressed by the M&FM analysis group working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses that can be tested in VMET to ensure that failures can be detected, and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes.

Trevino, Luis↗
NASA NTRS2015

A Free-Return Earth-Moon Cycler Orbit for an Interplanetary Cruise Ship

A periodic circumlunar orbit is presented that can be used by an interplanetary cruise ship for regular travel between Earth and the Moon. This Earth-Moon cycler orbit was revealed by introducing solar gravity and modest phasing maneuvers (average of 39 m/s per month) which yields close-Earth encounters every 7 or 10 days. Lunar encounters occur every 26 days and offer the chance for a smaller craft to depart the cycler and enter lunar orbit, or head for a Lagrange point (e.g., EM-L2 halo orbit), distant retrograde orbit (DRO), or interplanetary destination such as a near-Earth object (NEO) or Mars. Additionally, return-to-Earth abort options are available from many points along the cycling trajectory.

Interplanetary cruise ship↗
NASA NTRS2016

Comparisons Between Pretest Prediction and Flight Test Data of Aerodynamic Loading for EFT-1

Exploration Flight Test One (EFT-1) was an incredible milestone in the development NASA's Orion spacecraft. It incorporated hundreds of articles of flight test instrumentation and returned with a wealth of data. Aerodynamic surface pressures were collected during launch vehicle ascent and capsule reentry and descent. These discrete surface pressure measurements enable comparisons to computational results and ground test data. This paper details the comparisons between pre-test predictions and flight test data for the Orion MPCV Crew Module (CM) and Launch Abort Tower (LAT) during all phases of flight. Regions with strong comparisons, poor predictions, and lessons learned are discussed. 38 pressure measurements were made on the LAT during ascent. Nine of the gauges were Honeywell PPTs and the remainder were Kulite pressure transducers. In order to address bias in the Kulites, a two-point linear calibration was used and the details are discussed. Results from the flight are compared to existing database products. 44 pressure measurements were made on the CM during reentry and descent. Nine of the gauges were Honeywell PPTs and the remainder were Kulite pressure transducers. In order to address bias in the Kulites, a tare was made against the vacuum measurements as described below. Once the bias was removed from the gauges, comparisons between predicted loading and the measured results are compared.

Schwing, Alan M.↗
NASA NTRS2016

Boundary Layer Transition During the Orion Exploration Flight Test 1 (EFT-1)

Boundary layer transition was observed in the thermocouple data on the windside backshell of the Orion reentry capsule. Sensors along the windside centerline, as well as off-centerline, indicated transition late in the flight at approximately Mach 4 conditions. Transition progressed as expected, beginning at the sensors closest to the forward bay cover (FBC) and moving towards the heatshield. Sensors placed in off-centerline locations did not follow streamlines, so the progression of transition observed in these sensors is less intuitive. Future analysis will include comparisons to pre-flight predictions and expected transitional behavior will be investigated. Sensors located within the centerline and off-centerline launch abort system (LAS) attach well cavities on the FBC also showed indications of boundary layer transition. The transition within the centerline cavity was observed in the temperature traces prior to transition onset on the sensors upstream of the cavity. Transition behavior within the off centerline LAS attach well cavity will also be investigated. Heatshield thermocouples were placed within Avcoat plugs to attempt to capture transitional behavior as well as better understand the aerothermal environments. Thermocouples were placed in stacks of two or five vertically within the plugs, but the temperature data obtained at the sensors closest to the surface did not immediately indicate transitional behavior. Efforts to use the in depth thermocouple temperatures to reconstruct the surface heat flux are ongoing and any results showing the onset of boundary layer transition obtained from those reconstructions will also be included in this paper. Transition on additional features of interest, including compression pad ramps, will be included if it becomes available.

Kirk, Lindsay C.↗
NASA NTRS2015

Common Cause Failure Modeling

Space Launch System (SLS) Agenda: Objective; Key Definitions; Calculating Common Cause; Examples; Defense against Common Cause; Impact of varied Common Cause Failure (CCF) and abortability; Response Surface for various CCF Beta; Takeaways.

Hark, Frank↗
NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗
NASA NTRS2016

Evolution of Orion Mission Design for Exploration Mission 1 and 2

The evolving mission design and concepts of NASA's next steps have shaped Orion into the spacecraft that it is today. Since the initial inception of Orion, through the Constellation Program, and now in the Exploration Mission frame-work with the Space Launch System (SLS), each mission design concept and program goal have left Orion with a set of capabilities that can be utilized in many different mission types. Exploration Missions 1 and 2 (EM-1 and EM-2) have now been at the forefront of the mission design focus for the last several years. During that time, different Design Reference Missions (DRMs) were built, analyzed, and modified to solve or mitigate enterprise level design trades to ensure a viable mission from launch to landing. The resulting DRMs for EM-1 and EM-2 were then expanded into multi-year trajectory scans to characterize vehicle performance and Earth-Moon geometry trends. This provides Orion's subsystems with stressing reference trajectories to help design their system. Now that Orion has progressed through the Preliminary and Critical Design Re-views (PDR and CDR) there is a general shift in the focus of mission design from aiding the vehicle design to providing mission specific products needed for pre-flight and real time operations. Some of the mission specific products need-ed include analysis of steering law performance, inputs into navigational accura-cy assessments, abort options at any point in the mission for each valid trajecto-ry in the launch window, recontact avoidance between the upper stage and Orion post nominal separation, etc.

Gutkowski, Jeffrey P.↗
NASA NTRS2016

Evolution of Orion Mission Design for Exploration Mission 1 and 2

The evolving mission design and concepts of NASA’s next steps have shaped Orion into the spacecraft that it is today. Since the initial inception of Orion, through the Constellation Program, and now in the Exploration Mission frame-work with the Space Launch System (SLS), each mission design concept and pro-gram goal have left Orion with a set of capabilities that can be utilized in many different mission types. Exploration Missions 1 and 2 (EM-1 and EM-2) have now been at the forefront of the mission design focus for the last several years. During that time, different Design Reference Missions (DRMs) were built, analyzed, and modified to solve or mitigate enterprise level design trades to ensure a viable mission from launch to landing. The resulting DRMs for EM-1 and EM-2 were then expanded into multi-year trajectory scans to characterize vehicle performance as affected by variations in Earth-Moon geometry. This provides Orion’s subsystems with stressing reference trajectories to help design their system. Now that Orion has progressed through the Preliminary and Critical Design Reviews (PDR and CDR), there is a general shift in the focus of mission design from aiding the vehicle design to providing mission specific products needed for pre-flight and real time operations. Some of the mission specific products needed include, large quantities of nominal trajectories for multiple monthly launch periods and abort options at any point in the mission for each valid trajectory in the launch window.

Gutkowski, Jeffrey P.↗
NASA NTRS2016

Orion Exploration Mission Entry Interface Target Line

The Orion Multi-Purpose Crew Vehicle is required to return to the continental United States at any time during the month. In addition, it is required to provide a survivable entry from a wide range of trans-lunar abort trajectories. The Entry Interface (EI) state must be targeted to ensure that all requirements are met for all possible return scenarios, even in the event of no communication with the Mission Control Center to provide an updated EI target. The challenge then is to functionalize an EI state constraint manifold that can be used in the on-board targeting algorithm, as well as the ground-based trajectory optimization programs. This paper presents the techniques used to define the EI constraint manifold and to functionalize it as a set of polynomials in several dimensions.

Rea, Jeremy R.↗
NASA NTRS2008

Implications of Operational Pressure on CSSE PGS Design

The Constellation Spacesuit Element (CSSE) was required to support crew survival (CS); launch, entry, and abort (LEA) scenarios; zero gravity (0-g) extravehicular activity (EVA) (both unscheduled and contingency); and planetary EVA. Operation of the CSSE in all of these capacities required a pressure garment subsystem (PGS) that would operate efficiently through various pressure profiles. The PGS team initiated a study to determine the appropriate operational pressure profile of the CSSE and how this selection would affect the design of the CSSE PGS. This study included an extensive review of historical PGS operational pressure selection and the operational effects of those pressures, the presentation of four possible pressure paradigm options for use by the CSSE, the risks and design impacts of these options, and the down-selected pressure option.

Lee, Ryan↗
NASA NTRS2016

Overview of the Space Launch System Ascent Aeroacoustic Environment Test Program

Characterization of accurate flight vehicle unsteady aerodynamics is critical for component and secondary structure vibroacoustic design. The Aerosciences Branch at the National Aeronautics and Space Administration (NASA) Marshall Space Flight Center has conducted a test at the NASA Ames Research Center (ARC) Unitary Plan Wind Tunnels (UPWT) to determine such ascent aeroacoustic environments for the Space Launch System (SLS). Surface static pressure measurements were also collected to aid in determination of local environments for venting, CFD substantiation, and calibration of the flush air data system located on the launch abort system. Additionally, this test supported a NASA Engineering and Safety Center study of alternate booster nose caps. Testing occurred during two test campaigns: August - September 2013 and December 2013 - January 2014. Four primary model configurations were tested for ascent aeroacoustic environment definition. The SLS Block 1 vehicle was represented by a 2.5% full stack model and a 4% truncated model. Preliminary Block 1B payload and manned configurations were also tested, using 2.5% full stack and 4% truncated models respectively. This test utilized the 11 x 11 foot transonic and 9 x 7 foot supersonic tunnel sections at the ARC UPWT to collect data from Mach 0.7 through 2.5 at various total angles of attack. SLS Block 1 design environments were developed primarily using these data. SLS Block 1B preliminary environments have also been prepared using these data. This paper discusses the test and analysis methodology utilized, with a focus on the unsteady data collection and processing.

Herron, Andrew J.↗
NASA NTRS2016

Cislunar Near Rectilinear Halo Orbit for Human Space Exploration

In order to conduct sustained human exploration beyond Low Earth Orbit (LEO), spacecraft systems are designed to operate in a series of missions of increasing complexity. Regardless of the destination, Moon, Mars, asteroids or beyond, there is a substantial set of common objectives that must be met. Many orbit characterization studies have endeavored to evaluate the potential locations in cislunar space that are favorable for meeting common human exploration objectives in a stepwise approach. Multiple studies, by both NASA and other international space agencies, have indicated that Earth-­‐moon libration point orbits are attractive candidates for staging operations in the proving ground and beyond. In particular, the Near Rectilinear Orbit (NRO) has been demonstrated to meet multi-­‐mission and multi-­‐destination architectural constraints. However, a human mission to a selected NRO presents a variety of new challenges for mission planning. While a growing number of robotic missions have completed successful operations to various specific libration point orbits, human missions have never been conducted to orbits of this class. Human missions have unique challenges that differ significantly from robotic missions, including a lower tolerance for mission risk and additional operational constraints that are associated only with human spacecraft. In addition, neither robotic nor human missions have been operated in the NRO regime specifically, and NROs exhibit dynamical characteristics that can differ significantly as compared to other halo orbits. Finally, multi-­‐body orbits, such as libration point orbits, are identified to exist in a simplified orbit model known as the Circular Restricted Three Body Problem (CRTBP) and must then be re-­‐solved in the full ephemeris model. As a result, the behavior of multi-­‐body orbits cannot be effectively characterized within the classical two-­‐body orbit dynamics framework more familiar to the human spaceflight community. In fact, a given NRO is not identified by a set of Keplerian orbit parameters, and a valid epoch specific state vector must be first obtained from a multi-body dynamical model. In this paper, the significant performance and operational challenges of conducting human missions to the NRO are evaluated. First, a systematic process for generating full ephemeris based ballistic NROs of various families is outlined to demonstrate the relative ease in which a multi-­‐revolution orbit can be found for any epoch and for various orbit geometries. In the Earth-­‐Moon system, NROs, which are halo orbits with close passage over a lunar pole, can exist with respect to libration point 1 (L1) or libration point 2 (L2) and are either from a North or South family orbit class with respect to the ecliptic. Second, the ability to maintain the orbit over the lifetime of a habitat mission by applying a reliable station-keeping strategy is investigated. The NRO, while similar to the quasi-­‐halo orbits that the Artemis mission flew, requires an updated station keeping strategy. This is due to several dynamical differences such as the increased relative stability of the NRO compared to other halo orbits and the close passage over the lunar surface as shown in Figure 1. Multiple station-keeping strategies are being investigated to ensure a human spacecraft remains on a predictable path. As the NRO is not described in simple two-­‐body parameters, analysis must determine the best strategy for targeting a reference NRO as well as how closely a future state should be constrained. In addition, costs will be minimized by determining maneuver directionality based on an identified pattern in the optimal station-keeping solutions or an analytically derived relationship. The candidate station-keeping algorithm must be stable and robust to environmental and vehicle uncertainties as well to navigation estimation and flight control execution errors. To that end, navigation accuracies, the impact on the station-keeping execution errors as well as other vehicle uncertainties need to be assessed. Starting with Orion, current navigation accuracies are evaluated and then navigation requirements are derived assuming a desired station-keeping propellant budget. Third, the performance requirements to and from the NRO are evaluated. Important parameters for developing expected propellant costs include epoch of operation, size and type of NRO, Earth departure and return constraints, as well as abort or early-­‐return capability. Finally, rendezvous and proximity operations are vital aspects of multi-­‐mission human exploration endeavors. The ability to conduct rendezvous and the associated propellant costs are assessed as well as the impacts of various profile assumptions including the location within the NRO the rendezvous is performed. The results of these studies will influence plans for international cooperation on both nearer term proving ground missions and beyond.

Whitley, Ryan↗
NASA NTRS2015

SLS-SPEC-159 Cross-Program Design Specification for Natural Environments (DSNE) Revision D

This document is derived from the former National Aeronautics and Space Administration (NASA) Constellation Program (CxP) document CxP 70023, titled "The Design Specification for Natural Environments (DSNE), Revision C." The original document has been modified to represent updated Design Reference Missions (DRMs) for the NASA Exploration Systems Development (ESD) Programs. The DSNE completes environment-related specifications for architecture, system-level, and lower-tier documents by specifying the ranges of environmental conditions that must be accounted for by NASA ESD Programs. To assure clarity and consistency, and to prevent requirements documents from becoming cluttered with extensive amounts of technical material, natural environment specifications have been compiled into this document. The intent is to keep a unified specification for natural environments that each Program calls out for appropriate application. This document defines the natural environments parameter limits (maximum and minimum values, energy spectra, or precise model inputs, assumptions, model options, etc.), for all ESD Programs. These environments are developed by the NASA Marshall Space Flight Center (MSFC) Natural Environments Branch (MSFC organization code: EV44). Many of the parameter limits are based on experience with previous programs, such as the Space Shuttle Program. The parameter limits contain no margin and are meant to be evaluated individually to ensure they are reasonable (i.e., do not apply unrealistic extreme-on-extreme conditions). The natural environments specifications in this document should be accounted for by robust design of the flight vehicle and support systems. However, it is understood that in some cases the Programs will find it more effective to account for portions of the environment ranges by operational mitigation or acceptance of risk in accordance with an appropriate program risk management plan and/or hazard analysis process. The DSNE is not intended as a definition of operational models or operational constraints, nor is it adequate, alone, for ground facilities which may have additional requirements (for example, building codes and local environmental constraints). "Natural environments," as the term is used here, refers to the environments that are not the result of intended human activity or intervention. It consists of a variety of external environmental factors (most of natural origin and a few of human origin) which impose restrictions or otherwise impact the development or operation of flight vehicles and destination surface systems. These natural environments include the following types of environments: Terrestrial environments at launch, abort, and normal landing sites (winds, temperatures, pressures, surface roughness, sea conditions, etc.); Space environments (ionizing radiation, orbital debris, meteoroids, thermosphere density, plasma, solar, Earth, and lunar-emitted thermal radiation, etc.); Destination environments (Lunar surface and orbital, Mars atmosphere and surface, near Earth asteroids, etc.). Many of the environmental specifications in this document are based on models, data, and environment descriptions contained in the CxP 70044, Constellation Program Natural Environment Definition for Design (NEDD). The NEDD provides additional detailed environment data and model descriptions to support analytical studies for ESD Programs. For background information on specific environments and their effects on spacecraft design and operations, the environment models, and the data used to generate the specifications contained in the DSNE, the reader is referred to the NEDD paragraphs listed in each section of the DSNE. Also, most of the environmental specifications in this document are tied specifically to the ESD DRMs in ESD-10012, Revision B, Exploration Systems Development Concept of Operations (ConOps). Coordination between these environment specifications and the DRMs must be maintained. This document should be compatible with the current ESD DRMs, but updates to the mission definitions and variations in interpretation may require adjustments to the environment specifications.

Roberts, Barry C.↗