SEARCH · Search NASA

Results for “Communication Network Scheduling”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 91 records · Page 5

All sources NASA NTRS DOE OSTI

NASA NTRS2010

Secure Autonomous Automated Scheduling (SAAS)

This report describes network-centric operations, where a virtual mission operations center autonomously receives sensor triggers, and schedules space and ground assets using Internet-based technologies and service-oriented architectures. For proof-of-concept purposes, sensor triggers are received from the United States Geological Survey (USGS) to determine targets for space-based sensors. The Surrey Satellite Technology Limited (SSTL) Disaster Monitoring Constellation satellite, the UK-DMC, is used as the space-based sensor. The UK-DMC's availability is determined via machine-to-machine communications using SSTL's mission planning system. Access to/from the UK-DMC for tasking and sensor data is via SSTL's and Universal Space Network's (USN) ground assets. The availability and scheduling of USN's assets can also be performed autonomously via machine-to-machine communications. All communication, both on the ground and between ground and space, uses open Internet standards

Walke, Jon G.↗

NASA NTRS2001

Advanced Communication and Networking Technologies for Mars Exploration

Next-generation Mars communications networks will provide communications and navigation services to a wide variety of Mars science vehicles including: spacecraft that are arriving at Mars, spacecraft that are entering and descending in the Mars atmosphere, scientific orbiter spacecraft, spacecraft that return Mars samples to Earth, landers, rovers, aerobots, airplanes, and sensing pods. In the current architecture plans, the communication services will be provided using capabilities deployed on the science vehicles as well as dedicated communication satellites that will together make up the Mars network. This network will evolve as additional vehicles arrive, depart or end their useful missions. Cost savings and increased reliability will result from the ability to share communication services between missions. This paper discusses the basic architecture that is needed to support the Mars Communications Network part of NASA's Space Science Enterprise (SSE) communications architecture. The network may use various networking technologies such as those employed in the terrestrial Internet, as well as special purpose deep-space protocols to move data and commands autonomously between vehicles, at disparate Mars vicinity sites (on the surface or in near-Mars space) and between Mars vehicles and earthbound users. The architecture of the spacecraft on-board local communications is being reconsidered in light of these new networking requirements. The trend towards increasingly autonomous operation of the spacecraft is aimed at reducing the dependence on resource scheduling provided by Earth-based operators and increasing system fault tolerance. However, these benefits will result in increased communication and software development requirements. As a result, the envisioned Mars communications infrastructure requires both hardware and protocol technology advancements. This paper will describe a number of the critical technology needs and some of the ongoing research activities.

Bhasin, Kul↗

NASA NTRS2010

MaROS Strategic Relay Planning and Coordination Interfaces

The Mars Relay Operations Service (MaROS) is designed to provide planning and analysis tools in support of ongoing Mars Network relay operations. Strategic relay planning requires coordination between lander and orbiter mission ground data system (GDS) teams to schedule and execute relay communications passes. MaROS centralizes this process, correlating all data relevant to relay coordination to provide a cohesive picture of the relay state. Service users interact with the system through thin-layer command line and web user interface client applications. Users provide and utilize data such as lander view periods of orbiters, Deep Space Network (DSN) antenna tracks, and reports of relay pass performance. Users upload and download relevant relay data via formally defined and documented file structures including some described in Extensible Markup Language (XML). Clients interface with the system via an http-based Representational State Transfer (ReST) pattern using Javascript Object Notation (JSON) formats. This paper will provide a general overview of the service architecture and detail the software interfaces and considerations for interface design.

Allard, Daniel A.↗

NASA NTRS2010

Virtual Mission Operations of Remote Sensors With Rapid Access To and From Space

This paper describes network-centric operations, where a virtual mission operations center autonomously receives sensor triggers, and schedules space and ground assets using Internet-based technologies and service-oriented architectures. For proof-of-concept purposes, sensor triggers are received from the United States Geological Survey (USGS) to determine targets for space-based sensors. The Surrey Satellite Technology Limited (SSTL) Disaster Monitoring Constellation satellite, the United Kingdom Disaster Monitoring Constellation (UK-DMC), is used as the space-based sensor. The UK-DMC s availability is determined via machine-to-machine communications using SSTL s mission planning system. Access to/from the UK-DMC for tasking and sensor data is via SSTL s and Universal Space Network s (USN) ground assets. The availability and scheduling of USN s assets can also be performed autonomously via machine-to-machine communications. All communication, both on the ground and between ground and space, uses open Internet standards.

Ivancic, William D.↗

NASA NTRS2015

An Updated Process for Automated Deepspace Conjunction Assessment

There is currently a high level of interest in the areas of conjunction assessment and collision avoidance from organizations conducting space operations. Current conjunction assessment activity is mainly focused on spacecraft and debris in the Earth orbital environment [1]. However, collisions are possible in other orbital environments as well [2]. This paper will focus on the current operations of and recent updates to the Multimission Automated Deep Space Conjunction Assessment Process (MADCAP) used at the Jet Propulsion Laboratory for NASA to perform conjunction assessment at Mars and the Moon. Various space agencies have satellites in orbit at Mars and the Moon with additional future missions planned. The consequences of collisions are catastrophically high. Intuitive notions predict low probability of collisions in these sparsely populated environments, but may be inaccurate due to several factors. Orbits of scientific interest often tend to have similar characteristics as do the orbits of spacecraft that provide a communications relay for surface missions. The MADCAP process is controlled by an automated scheduler which initializes analysis based on a set timetable or the appearance of new ephemeris files either locally or on the Deep Space Network (DSN) Portal. The process then generates and communicates reports which are used to facilitate collision avoidance decisions. The paper also describes the operational experience and utilization of the automated tool during periods of high activity and interest such as: the close approaches of NASA's Lunar Atmosphere & Dust Environment Explorer (LADEE) and Lunar Reconnaissance Orbiter (LRO) during the LADEE mission. In addition, special consideration was required for the treatment of missions with rapidly varying orbits and less reliable long term downtrack estimates; in particular this was necessitated by perturbations to MAVEN's orbit induced by the Martian atmosphere. The application of special techniques to non-operational spacecraft with large uncertainties is also studied. Areas for future work are also described. Although the applications discussed in this paper are in the Martian and Lunar environments, the techniques are not unique to these bodies and could be applied to other orbital environments.

collision↗

NASA NTRS1993

Scheduling the future NASA Space Network: Experiences with a flexible scheduling prototype

NASA's Space Network (SN) provides telecommunications and tracking services to low earth orbiting spacecraft. One proposal for improving resource allocation and automating conflict resolution for the SN is the concept of flexible scheduling. In this concept, each Payload Operations Control Center (POCC) will possess a Space Network User POCC Interface (SNUPI) to support the development and management of flexible requests. Flexible requests express the flexibility, constraints, and repetitious nature of the user's communications requirements. Flexible scheduling is expected to improve SN resource utilization and user satisfaction, as well as reduce the effort to produce and maintain a schedule. A prototype testbed has been developed to better understand flexible scheduling as it applies to the SN. This testbed consists of a SNUPI workstation, an SN scheduler, and a flexible request language that conveys information between the two systems. All three are being evaluated by operations personnel. Benchmark testing is being conducted on the scheduler to quantify the productivity improvements achieved with flexible requests.

Happell, Nadine↗

NASA NTRS2012

Architecting the Human Space Flight Program with Systems Modeling Language (SysML)

The next generation of missions in NASA's Human Space Flight program focuses on the development and deployment of highly complex systems (e.g., Orion Multi-Purpose Crew Vehicle, Space Launch System, 21st Century Ground System) that will enable astronauts to venture beyond low Earth orbit and explore the moon, near-Earth asteroids, and beyond. Architecting these highly complex system-of-systems requires formal systems engineering techniques for managing the evolution of the technical features in the information exchange domain (e.g., data exchanges, communication networks, ground software) and also, formal correlation of the technical architecture to stakeholders' programmatic concerns (e.g., budget, schedule, risk) and design development (e.g., assumptions, constraints, trades, tracking of unknowns). This paper will describe how the authors have applied System Modeling Language (SysML) to implement model-based systems engineering for managing the description of the End-to-End Information System (EEIS) architecture and associated development activities and ultimately enables stakeholders to understand, reason, and answer questions about the EEIS under design for proposed lunar Exploration Missions 1 and 2 (EM-1 and EM-2).

scheduling↗

NASA NTRS2016

A Network Scheduling Model for Distributed Control Simulation

Distributed engine control is a hardware technology that radically alters the architecture for aircraft engine control systems. Of its own accord, it does not change the function of control, rather it seeks to address the implementation issues for weight-constrained vehicles that can limit overall system performance and increase life-cycle cost. However, an inherent feature of this technology, digital communication networks, alters the flow of information between critical elements of the closed-loop control. Whereas control information has been available continuously in conventional centralized control architectures through virtue of analog signaling, moving forward, it will be transmitted digitally in serial fashion over the network(s) in distributed control architectures. An underlying effect is that all of the control information arrives asynchronously and may not be available every loop interval of the controller, therefore it must be scheduled. This paper proposes a methodology for modeling the nominal data flow over these networks and examines the resulting impact for an aero turbine engine system simulation.

distributed control↗

NASA NTRS1991

Distributed scheduling with COMPASS

COMPASS (COMPuter Aided Scheduling System) is a sophisticated, interactive scheduling tool used within NASA. Like most existing tools, however, COMPASS is a single-user application. There is a large class of scheduling problems which may be better solved by allowing several people at various locations to build separate schedules with shared resources. DISCORS (DIStributed COmputer Resource Scheduling) is a set of services which support a distributed version of COMPASS. This architecture naturally accommodates the integration of user-defined resource models without modifying COMPASS. DISCORS services include the ability to establish and manage communications, to code messages in efficient formats, to provide fault detection and recovery, and to configure schedulers across a network. In its present form, DISCORS effectively supports distributed COMPASS, but fails to run fast and to guarantee efficient schedules. Further enhancements may allow several users to simultaneously and interactively work together to create complex schedules while COMPASS detects and coordinates the resolution of conflicting requests.

Rufat-Latre, Jorge↗

NASA NTRS1993

FASTER - A tool for DSN forecasting and scheduling

FASTER (Forecasting And Scheduling Tool for Earth-based Resources) is a suite of tools designed for forecasting and scheduling JPL's Deep Space Network (DSN). The DSN is a set of antennas and other associated resources that must be scheduled for satellite communications, astronomy, maintenance, and testing. FASTER consists of MS-Windows based programs that replace two existing programs (RALPH and PC4CAST). FASTER was designed to be more flexible, maintainable, and user friendly. FASTER makes heavy use of commercial software to allow for customization by users. FASTER implements scheduling as a two pass process: the first pass calculates a predictive profile of resource utilization; the second pass uses this information to calculate a cost function used in a dynamic programming optimization step. This information allows the scheduler to 'look ahead' at activities that are not as yet scheduled. FASTER has succeeded in allowing wider access to data and tools, reducing the amount of effort expended and increasing the quality of analysis.

Werntz, David↗

NASA NTRS2008

System Engineering on the Use for Ares I,V - the Simpler, the Better

The Ares I and Ares V Vehicles will utilize the J-2X rocket engine developed for NASA by the Pratt & Whitney Rocketdyne Company. The J-2X is an improved higher power version of the original J-2 engine used during the Apollo program. With higher power and updated requirements for safety and performance, the J-2X becomes a new engine using state-of-the-art design methodology, materials and manufacturing processes. The implementation of Systems Engineering (SE) principles enables the rapid J-2X development program to remain aligned with the ARES I and V vehicle programs, Meeting the aggressive development schedule is a challenge. Coordinating the best expertise thai NASA and PWR have to offer requires effectively utilizing resources at multiple sites. This presents formidable communication challenges. SE allows honest and open discussions of issues and problems. This simple idea is often overlooked in large and complex SE programs. Regular and effective meetings linking SE objectives to component designs are used to voice differences of opinions with customer and contractor in attendance so that the best mutual decisions can be made on the shortest possible schedule. Regular technical interchange meetings on secure program wide computer networks and CM processes are effective,in the "Controlled Change" process that exemplifies good SE. Good communication is a key effective SE implementation. The System of Systems approach is the vision of the Orion program which facilitates the establishment of dynamic SE processes at all levels including the engine. SE enables requirements evolution by facilitating organizational and process agility. Flow down and distribution of requirements is controlled by Allocation Reports which breakdown numerical design objectives (weight, reliability, etc.) into quanta goals for each component area. Linked databases of design and verification requirements helps eliminate redundancy and potential mistakes inherent m separated systems. Another tool, the Architecture Design Description, is being used to control J-2X system architecture and effectively communicate configuration changes to those involved in the design process. But the proof is in successful program accomplishment. The SE is the methodology being used to meet the challenge of completing J-2X engine certification 2 years ahead of any engine program ever developed at PWR. The Ares I SE system of systems has delivered according to expectations thus far. All major design reviews (SRR. PDR, CDR) have been successfully conducted to satisfy overall program objectives using SE as the basis for accomplishment. The paper describes SE tools and techniques utilized to achieve this success.

Kelly, William↗

NASA NTRS1999

A Study of Quality of Service Communication for High-Speed Packet-Switching Computer Sub-Networks

In this thesis, we analyze various factors that affect quality of service (QoS) communication in high-speed, packet-switching sub-networks. We hypothesize that sub-network-wide bandwidth reservation and guaranteed CPU processing power at endpoint systems for handling data traffic are indispensable to achieving hard end-to-end quality of service. Different bandwidth reservation strategies, traffic characterization schemes, and scheduling algorithms affect the network resources and CPU usage as well as the extent that QoS can be achieved. In order to analyze those factors, we design and implement a communication layer. Our experimental analysis supports our research hypothesis. The Resource ReSerVation Protocol (RSVP) is designed to realize resource reservation. Our analysis of RSVP shows that using RSVP solely is insufficient to provide hard end-to-end quality of service in a high-speed sub-network. Analysis of the IEEE 802.lp protocol also supports the research hypothesis.

Cui, Zhenqian↗

NASA NTRS1984

ISEE-3/ICE navigation analysis

Efforts to assure communications continuity and navigational accuracy for the ISEE-3 (now called the International Cometary Explorer - ICE) spacecraft as it heads toward a passage through the Giacobini-Zimmer (G-Z) comet tail are reviewed. Sufficient energy was gained with a series of lunar swingbys to take the rendezvous attempt possible. Communications will be by an S-band link though the upgraded Deep Space Network. The G-Z encounter is scheduled for September 1983. A 512 bps data rate will be supported by 64-3 m dishes at various global sites. The tracking will continue for 6 mos as the spacecraft moves into an orbit that parallels that of Halley's Comet. Ground-based recovery of the G-Z location in the spring of 1984 provided data for calculating the ephemerides required for configuring a major course correction for ICE 100 days before rendezvous.

Efron, L.↗

NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗

NASA NTRS2023

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↗

NASA NTRS2024

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

Delay Tolerant Networking↗

NASA NTRS2006

The Mars Reconnaissance Orbiter Mission Operations: Architecture and Approach

The Mars Reconnaissance Orbiter (MRO) was launched on August 12, 2005 by an Atlas V launch vehicle from Cape Canaveral Air Force Station. MRO will carry a rich set of science instruments to Mars and provide global, regional survey, and targeted observations. In addition, a set of engineering instruments providing optical navigation, Ka band telecommunication and UHF relay services to future Mars missions are part of the MRO payload. During the mission, the MRO operations teams are presented with two major challenges - unprecedented high data rate and data volumes, and complex science planning and resource sharing. MRO has the capability to communicate with earth at a maximum of six Megabits per second (> 50 times any previous Mars missions). With the current Deep Space Network (DSN) contact schedule of 19 eight-hour tracks per week, the baseline mission plan is for MRO to return 34 Terabits of raw science data during the two year primary science phase. Each of the science instruments has its unique requirements for global mapping, regional survey, and targeted observations. Some instruments prefer nadir-only observations, while others require off-nadir observations (especially for stereo viewing). The requirements from these Mars viewing instruments presented a significant challenge for the operations team to design the complex science planning and resource sharing/allocation process. This paper describes what MRO project is implementing to solve these challenges.

Mars Reconnaissance Orbiter (MRO)↗

NASA NTRS1991

Analysis of Issues for Project Scheduling by Multiple, Dispersed Schedulers (distributed Scheduling) and Requirements for Manual Protocols and Computer-based Support

Although computerized operations have significant gains realized in many areas, one area, scheduling, has enjoyed few benefits from automation. The traditional methods of industrial engineering and operations research have not proven robust enough to handle the complexities associated with the scheduling of realistic problems. To address this need, NASA has developed the computer-aided scheduling system (COMPASS), a sophisticated, interactive scheduling tool that is in wide-spread use within NASA and the contractor community. Therefore, COMPASS provides no explicit support for the large class of problems in which several people, perhaps at various locations, build separate schedules that share a common pool of resources. This research examines the issue of distributing scheduling, as applied to application domains characterized by the partial ordering of tasks, limited resources, and time restrictions. The focus of this research is on identifying issues related to distributed scheduling, locating applicable problem domains within NASA, and suggesting areas for ongoing research. The issues that this research identifies are goals, rescheduling requirements, database support, the need for communication and coordination among individual schedulers, the potential for expert system support for scheduling, and the possibility of integrating artificially intelligent schedulers into a network of human schedulers.

Richards, Stephen F.↗