Automating Mid- and Long-range Scheduling for NASA's Deep Space Network
No abstract available
SEARCH · Engineering Papers
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.
No abstract available
Sensor Web observing systems may have the potential to significantly improve our ability to monitor, understand, and predict the evolution of rapidly evolving, transient, or variable environmental features and events. This improvement will come about by integrating novel data collection techniques, new or improved instruments, emerging communications technologies and protocols, sensor mark-up languages, and interoperable planning and scheduling systems. In contrast to today's observing systems, "event-driven" sensor webs will synthesize real- or near-real time measurements and information from other platforms and then react by reconfiguring the platforms and instruments to invoke new measurement modes and adaptive observation strategies. Similarly, "model-driven" sensor webs will utilize environmental prediction models to initiate targeted sensor measurements or to use a new observing strategy. The sensor web concept contrasts with today's data collection techniques and observing system operations concepts where independent measurements are made by remote sensing and in situ platforms that do not share, and therefore cannot act upon, potentially useful complementary sensor measurement data and platform state information. This presentation describes NASA's view of event-driven and model-driven Sensor Webs and highlights several research and development activities at the Goddard Space Flight Center.
The Space Communication and Navigation (SCaN) program office owns the assets and services provided by the Deep Space Network (DSN), Near Earth Network (NEN), and Space Network (SN). At present, these individual networks are operated by different NASA centers--JPL for DSN--and Goddard Space Flight Center (GSFC) for NEN and SN--with separate commitments offices for each center. In the near future, SCaN's program office would like to deploy an integrated service portal which would merge the two commitments offices with the goal of easing the task of user planning for space missions requiring services of two or more of these networks. Following interviews with subject matter experts in this field, use cases were created to include the services and functionality mission users would like to see in this new integrated service portal. These use cases provide a guideline for a mock-up of the design of the user interface for the portal. The benefit of this work will ease the time required and streamline/standardize the process for planning and scheduling SCAN's services for future space missions.
This paper describes technology to support a new paradigm of space science campaigns. These campaigns enable opportunistic science observations to be autonomously coordinated between multiple spacecraft. Coordinated spacecraft can consist of multiple orbiters, landers, rovers, or other in-situ vehicles (such as an aerobot). In this paradigm, opportunistic science detections can be cued by any of these assets where additional spacecraft are requested to take further observations characterizing the identified event or surface feature. Such coordination will enable a number of science campaigns not possible with present spacecraft technology. Examples from Mars include enabling rapid data collection from multiple craft on dynamic events such as new Mars dark slope streaks, dust-devils or trace gases. Technology to support the identification of opportunistic science events and/or the re-tasking of a spacecraft to take new measurements of the event is already in place on several individual missions such as the Mars Exploration Rover (MER) Mission and the Earth Observing One (EO1) Mission. This technology includes onboard data analysis techniques as well as capabilities for planning and scheduling. This paper describes how these techniques can be cue and coordinate multiple spacecraft in observing the same science event from their different vantage points.
The Nuclear Thermal Rocket (NTR) derives its energy from fission of uranium-235 atoms contained within fuel elements that comprise the engine's reactor core. It generates high thrust and has a specific impulse potential of approximately 900 seconds - a 100% increase over today's best chemical rockets. The Nuclear Thermal Propulsion (NTP) project, funded by NASA's AES program, includes five key task activities: (1) Recapture, demonstration, and validation of heritage graphite composite (GC) fuel (selected as the "Lead Fuel" option); (2) Engine Conceptual Design; (3) Operating Requirements Definition; (4) Identification of Affordable Options for Ground Testing; and (5) Formulation of an Affordable Development Strategy. During FY'14, a preliminary DDT&E plan and schedule for NTP development was outlined by GRC, DOE and industry that involved significant system-level demonstration projects that included GTD tests at the NNSS, followed by a FTD mission. To reduce cost for the GTD tests and FTD mission, small NTR engines, in either the 7.5 or 16.5 klbf thrust class, were considered. Both engine options used GC fuel and a "common" fuel element (FE) design. The small approximately 7.5 klbf "criticality-limited" engine produces approximately 157 megawatts of thermal power (MWt) and its core is configured with parallel rows of hexagonal-shaped FEs and tie tubes (TTs) with a FE to TT ratio of approximately 1:1. The larger approximately 16.5 klbf Small Nuclear Rocket Engine (SNRE), developed by LANL at the end of the Rover program, produces approximately 367 MWt and has a FE to TT ratio of approximately 2:1. Although both engines use a common 35 inch (approximately 89 cm) long FE, the SNRE's larger diameter core contains approximately 300 more FEs needed to produce an additional 210 MWt of power. To reduce the cost of the FTD mission, a simple "1-burn" lunar flyby mission was considered to reduce the LH2 propellant loading, the stage size and complexity. Use of existing and flight proven liquid rocket and stage hardware (e.g., from the RL10B-2 engine and Delta Cryogenic Second Stage) was also maximized to further aid affordability. This paper examines the pros and cons of using these two small engine options, including their potential to support future human exploration missions to the Moon, near Earth asteroids, and Mars, and recommends a preferred size. It also provides a preliminary assessment of the key activities, development options, and schedule required to affordably build, ground test and fly a small NTR engine and stage within a 10-year timeframe.
The Nuclear Thermal Rocket (NTR) derives its energy from fission of uranium-235 atoms contained within fuel elements that comprise the engine's reactor core. It generates high thrust and has a specific impulse potential of approximately 900 specific impulse - a 100 percent increase over today's best chemical rockets. The Nuclear Thermal Propulsion (NTP) project, funded by NASA's Advanced Exploration Systems (AES) program, includes five key task activities: (1) Recapture, demonstration, and validation of heritage graphite composite (GC) fuel (selected as the Lead Fuel option); (2) Engine Conceptual Design; (3) Operating Requirements Definition; (4) Identification of Affordable Options for Ground Testing; and (5) Formulation of an Affordable Development Strategy. During fiscal year (FY) 2014, a preliminary Design Development Test and Evaluation (DDT&E) plan and schedule for NTP development was outlined by the NASA Glenn Research Center (GRC), Department of Energy (DOE) and industry that involved significant system-level demonstration projects that included Ground Technology Demonstration (GTD) tests at the Nevada National Security Site (NNSS), followed by a Flight Technology Demonstration (FTD) mission. To reduce cost for the GTD tests and FTD mission, small NTR engines, in either the 7.5 or 16.5 kilopound-force thrust class, were considered. Both engine options used GC fuel and a common fuel element (FE) design. The small approximately 7.5 kilopound-force criticality-limited engine produces approximately157 thermal megawatts and its core is configured with parallel rows of hexagonal-shaped FEs and tie tubes (TTs) with a FE to TT ratio of approximately 1:1. The larger approximately 16.5 kilopound-force Small Nuclear Rocket Engine (SNRE), developed by Los Alamos National Laboratory (LANL) at the end of the Rover program, produces approximately 367 thermal megawatts and has a FE to TT ratio of approximately 2:1. Although both engines use a common 35-inch (approximately 89-centimeters) -long FE, the SNRE's larger diameter core contains approximately 300 more FEs needed to produce an additional 210 thermal megawatts of power. To reduce the cost of the FTD mission, a simple one-burn lunar flyby mission was considered to reduce the liquid hydrogen (LH2) propellant loading, the stage size and complexity. Use of existing and flight proven liquid rocket and stage hardware (e.g., from the RL10B-2 engine and Delta Cryogenic Second Stage) was also maximized to further aid affordability. This paper examines the pros and cons of using these two small engine options, including their potential to support future human exploration missions to the Moon, near Earth asteroids (NEA), and Mars, and recommends a preferred size. It also provides a preliminary assessment of the key activities, development options, and schedule required to affordably build, ground test and fly a small NTR engine and stage within a 10-year timeframe.
CubeSats have grown in sophistication to the point that relatively low-cost mission solutions could be undertaken for planetary exploration. There are unique considerations for lunar and L1/L2 CubeSat communication and navigation compared with low earth orbit CubeSats. This paper explores those considerations as they relate to the Lunar IceCube Mission. The Lunar IceCube is a CubeSat mission led by Morehead State University with participation from NASA Goddard Space Flight Center, Jet Propulsion Laboratory, the Busek Company and Vermont Tech. It will search for surface water ice and other resources from a high inclination lunar orbit. Lunar IceCube is one of a select group of CubeSats designed to explore beyond low-earth orbit that will fly on NASA’s Space Launch System (SLS) as secondary payloads for Exploration Mission (EM) 1. Lunar IceCube and the EM-1 CubeSats will lay the groundwork for future lunar and L1/L2 CubeSat missions. This paper discusses communication and navigation needs for the Lunar IceCube mission and navigation and radiation tolerance requirements related to lunar and L1/L2 orbits. Potential CubeSat radios and antennas for such missions are investigated and compared. Ground station coverage, link analysis, and ground station solutions are also discussed. This paper will describe modifications in process for the Morehead ground station, as well as further enhancements of the Morehead ground station and NASA Near Earth Network (NEN) that are being considered. The potential NEN enhancements include upgrading current NEN Cortex receiver with Forward Error Correction (FEC) Turbo Code, providing X-band uplink capability, and adding ranging options. The benefits of ground station enhancements for CubeSats flown on NASA Exploration Missions (EM) are presented. This paper also describes how the NEN may support lunar and L1/L2 CubeSats without any enhancements. In addition, NEN is studying other initiatives to better support the CubeSat community, including streamlining the compatibility testing, planning and scheduling associated with CubeSat missions. Because of the lower cost, opportunity for simultaneous multipoint observations, it is inevitable that CubeSats will continue to increase in popularity for not only LEO missions, but for lunar and L1/L2 missions as well. The challenges for lunar and L1/L2 missions for communication and navigation are much greater than for LEO missions, but are not insurmountable. Advancements in flight hardware and ground infrastructure will ease the burden.
CubeSats have grown in sophistication to the point that relatively low-cost mission solutions could be undertaken for planetary exploration. There are unique considerations for Lunar and L1L2 CubeSat communication and navigation compared with low earth orbit CubeSats. This paper explores those considerations as they relate to the MoreheadGSFC Lunar IceCube Mission. The Lunar IceCube is a CubeSat mission led by Morehead State University with participation from NASA Goddard Space Flight Center, JPL, the Busek Company and Vermont Tech. It will search for surface water ice and other resources from a high inclination lunar orbit. Lunar IceCube is one of a select group of CubeSats designed to explore beyond low-earth orbit that will fly on NASAs Space Launch System (SLS) as secondary payloads for Exploration Mission (EM) 1. Lunar IceCube and the EM-1 CubeSats will lay the groundwork for future lunar and L1L2 CubeSat missions. This paper discusses communication and navigation needs for the Lunar IceCube mission and navigation and radiation tolerance requirements related to lunar and L1L2 orbits. Potential CubeSat radio and antennas for such missions are investigated and compared. Ground station coverage, link analysis, and ground station solutions are also discussed. There are currently modifications in process for the Morehead ground station. Further enhancement of the Morehead ground station and the NASA Near Earth Network (NEN) are being examined. This paper describes how the NEN may support Lunar and L1L2 CubeSats without any enhancements and potential expansion of NEN to better support such missions in the future. The potential NEN enhancements include upgrading current NEN Cortex receiver with Forward Error Correction (FEC) Turbo Code, providing X-band Uplink capability, and adding ranging options. The benefits of ground station enhancements for CubeSats flown on NASA Exploration Missions (EM) are presented. The paper also discusses other initiatives that the NEN is studying to better support the CubeSat community, including streamlining the compatibility test, planning and scheduling associated with CubeSat missions.
This paper offers a comprehensive view of flight system integration and test (I&T) lessons learned related to mishaps and close calls, focusing on what can be done to improve the I&T process to avoid recurrence. Specific areas within the realm of I&T that are covered in this paper include: I&T team communication and training; design of flight and ground systems for I&T; planning and scheduling; configuration management and process documentation; ground support equipment and tools; cleanrooms and contamination; mechanical integration, handling, and deployments; electrical integration and electrostatic discharge; functional testing and troubleshooting; environmental testing and facilities; and launch site operations. To illustrate "real-world" lessons learned for I&T, examples from throughout the history of the U.S. space program are presented. Also presented are some best practices for I&T that can help mitigate mishaps and close calls on the ground or during flight.
Implementation of Urban Air Mobility (UAM) operations, or air passenger transportation systems within densely populated metropolitan areas, seeks to mitigate increasing traffic congestion. However, the development and integration of UAM operations into the national airspace system comes with its own unique challenges, such as vehicle requirements, flight planning and scheduling, and coordination between UAM flights and air traffic controllers. In particular, verbal coordination will play an integral part in the determined success of UAM operations and its ability to meet projected high consumer demands. In order to meet demands and higher traffic volumes on UAM routes, verbal communication between the UAM pilot and controller must be streamlined to reduce the controller's workload while helping to maintain safety within a given airspace. One method of reducing verbal workload are Letters Of Agreement (LOAs) that outline responsibilities and procedures for operations in an airspace. These LOAs will specify the operations, procedures, and routes for UAM flights. The proposed study will examine the usability of two route formatting styles for LOAs; (i) Verbal route descriptions and (ii) Tower En Route Control (TECs) routes. Verbal route descriptions will include the route name and associated visual cues on the route. The TEC route versions will include relevant waypoints and charts outlining the route with waypoints marked. The study will be part of a UAM X1 human in the loop (HITL) simulation. Controller participants will handle traditional air traffic including moderate levels of UAM traffic on current and modified helicopter routes within the Dallas Fort-Worth area. Scenarios will be counterbalanced and repeated to test both route formatting versions. After each trial, participants will rate the usability of the LOA used in the previous trial via a subjective questionnaire. We expect that controllers will prefer the LOA with TEC routes due to simplicity and visual elements available.
This work introduces an approach to estimate the complexity of a low-altitude air traffic scenario involving multiple UASs using mathematical programming. Given a set of multi-point UAS flight trajectories, vehicle dynamics, and a conflict resolution algorithm, an abstract model is developed such that it can be solved quickly using a mathematical programming optimization software without running high-fidelity simulations that can be computationally expensive and may not suit real-time apA quick and accurate assessment of complexity for a given traffic scenario can help plan and schedule flights to alleviate traffic bottleneck and mitigate operation risks, especially for unmanned aerial system traffic management where high traffic density or complexity is expected. This work introduces a traffic scenario complexity metric that was constructed based on the number of potential conflicts weighted by the conflict resolution cost associated. The cost associated with a conflict is calculated based on the corresponding conflict resolution maneuvers. To obtain the conflict resolution maneuvers, a MILP-based optimization was formulated with the vehicle model and conflict management parameters incorporated. To evaluate the complexity metrics, an approach of using measurements from high-fidelity simulations was proposed. The scenario complexity measurements for 920 random-generated scenarios were obtained through high-fidelity simulations and treated as the ground truth. Two statistics methods: Pearson and Alternative Conditional Expectations were applied for analysis. The results showed that the number of flights has low correlation with the scenario complexity according to the correlation coefficients calculated by both methods. The Alternative Conditional Expectations method shows that the proposed scenario complexity metric has better correlation with the ground truth than the number of potential conflicts.plications. In the abstract model, each vehicle is represented by a time-varied vector associated with position, speed, and heading information. The total extra distance that aircraft need to divert from their original routes to avoid collisions is computed and used to setup a quadratic programming formula. The metrics including the number of conflicts and extra distances travelled by all vehicles are then utilized to estimate the complexity of a given UAS flight scenario. Results and verification against high-fidelity simulations will be provided in the final draft.
NASA has developed methods and algorithms for autonomous spacecraft operations,including automated planning and scheduling, fault diagnostics and impact determination,procedure management and display. Making the transition from technology research tooperational flight software requires overcoming significant technical, programmatic andcultural challenges. Technology research is aimed at developing methods that performspecific functions correctly, but the resulting software may not be designed for flightprocessors with limited CPU, memory and network resources, and may not be easilyintegrated into spacecraft flight software. Our objective in the Autonomous Systems andOperations Project is to make significant strides toward the transformation from technologyto operational use. Our focus was twofold: maturing research grade autonomy software intoa flight software environment using broadly accepted languages and tools; and integratingautonomy applications with each other and with representative systems and their data andcommand interfaces. For a target flight software environment, we chose Core FlightSoftware, developed by Goddard Space Flight Center as a common operating systemindependent framework. Our hardware integration environment was provided by theIntegrated Power and Avionics Systems (iPAS) Lab at Johnson Space Center, in whichvarious subsystem development has been conducted to address engineering challenges forthe vehicles and systems required for long-duration missions into the solar system. The iPASand its network of connected facilities provides realistic subsystem hardware or simulationsof spacecraft power, life support, guidance, navigation and control, and command and datahandling subsystems. Interfaces between autonomy applications and the subsystems beingassessed and controlled were developed, assessed and refined. The hardware and softwareenvironment using CFS and the iPAS facility has proven to be a highly flexible and realisticenvironment in which to rapidly integrate applications in an iterative, low cost setting. Usingthe integration environment we have developed, we will turn our focus to performance andsizing analysis to determine the computational requirements for full-scale deployment ofautonomy technology. Scalability of reasoners and the spacecraft models upon which theyoperate, and robustness across the full range of spacecraft conditions and environments willbe explored and improved. We are making significant contributions to the future programsthat will build the spacecraft that will take humans beyond the Earth-Moon system, in whichprogram Systems Engineers will be able to accurately and confidently design in accurate,robust and mature autonomous operations systems.
In the present-day National Airspace System, the air traffic management system attempts to predict the trajectory for each flight based on the flight plan and scheduled or controlled departure time. However, gaps in trajectory data and models, coupled with tactical control actions that are not communicated to automation systems or other stakeholders, lead to trajectory predictions that are less accurate than they could be. This affects traffic flow management performance. Management by Trajectory (MBT) is a NASA concept for air traffic management in which every flight operates in accordance with a 4D trajectory that is negotiated between the airspace user and the FAA to account for the airspace user’s goals while complying with NAS constraints. The primary benefit of MBT is an improvement in system performance due to increased trajectory predictability and stability, which result from managing traffic in all four dimensions (2D route, vertical, and time), ensuring that changes to the flight’s trajectory are incorporated into the assigned trajectory, and utilizing improved time or arrival control standards. Importantly, the performance improvements support increasing efficiency without increasing collision risk. This paper provides an overview of MBT and describes fast-time simulation results evaluating the safety, performance, and efficiency effects of MBT.
This paper will discuss a proof-of-concept prototype for automatic generation of validated rover command sequences from high-level science and engineering activities.
This paper compares and contrasts several coordination schemes for a system that continuously plans to control collections of rovers or spacecraft using collective mission goals instead of goals or command sequences for each spacecraft.
This paper describes an integrated system for coordinating multiple rover behavior with the overall goal of collecting planetary surface data.
This paper describes an architecture for an autonomous deep space tracking station (DS-T).