Search NASA⌕ Search

SEARCH · Search NASA

Results for “Distribution Operations”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

Distributed operations as applied in a large multi-instrument space mission: lessons learned from the Cassini-Huygens Program

Launched in 1997, the Cassini-Huygens Mission sent the largest interplanetary spacecraft ever built in the service of science. Carrying a suite of 12 scientific instruments and an atmospheric entry probe, this complex spacecraft to explore the Saturn system may not have gotten off the ground without undergoing significant design changes and cost reductions.

distributed↗
NASA NTRS1990

A development framework for artificial intelligence based distributed operations support systems

Advanced automation is required to reduce costly human operations support requirements for complex space-based and ground control systems. Existing knowledge based technologies have been used successfully to automate individual operations tasks. Considerably less progress has been made in integrating and coordinating multiple operations applications for unified intelligent support systems. To fill this gap, SOCIAL, a tool set for developing Distributed Artificial Intelligence (DAI) systems is being constructed. SOCIAL consists of three primary language based components defining: models of interprocess communication across heterogeneous platforms; models for interprocess coordination, concurrency control, and fault management; and for accessing heterogeneous information resources. DAI applications subsystems, either new or existing, will access these distributed services non-intrusively, via high-level message-based protocols. SOCIAL will reduce the complexity of distributed communications, control, and integration, enabling developers to concentrate on the design and functionality of the target DAI system itself.

Adler, Richard M.↗
NASA NTRS1990

Telescience - Optimizing aerospace science return through geographically distributed operations

The paper examines the objectives and requirements of teleoperations, defined as the means and process for scientists, NASA operations personnel, and astronauts to conduct payload operations as if these were colocated. This process is described in terms of Space Station era platforms. Some of the enabling technologies are discussed, including open architecture workstations, distributed computing, transaction management, expert systems, and high-speed networks. Recent testbedding experiments are surveyed to highlight some of the human factors requirements.

Rasmussen, Daryl N.↗
NASA NTRS2002

A Ground Systems Architecture Transition for A Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the ISS payloads program, and the resulting functional breakdown of the products that support that architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗
NASA NTRS2003

A Ground Systems Architecture Transition for a Distributed Operations System

The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the International Space Station (ISS) payloads program, and the resulting functional breakdown of the products that support this architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.

Sellers, Donna↗
NASA NTRS2008

Linking and Combining Distributed Operations Facilities using NASA's "GMSEC" Systems Architectures

NASA's Goddard Mission Services Evolution Center (GMSEC) ground system architecture has been in development since late 2001, has successfully supported eight orbiting satellites and is being applied to many of NASA's future missions. GMSEC can be considered an event-driven service-oriented architecture built around a publish/subscribe message bus middleware. This paper briefly discusses the GMSEC technical approaches which have led to significant cost savings and risk reduction for NASA missions operated at the Goddard Space Flight Center (GSFC). The paper then focuses on the development and operational impacts of extending the architecture across multiple mission operations facilities.

Smith, Danford↗
NASA NTRS2003

Software Supports Distributed Operations via the Internet

Multi-mission Encrypted Communication System (MECS) is a computer program that enables authorized, geographically dispersed users to gain secure access to a common set of data files via the Internet. MECS is compatible with legacy application programs and a variety of operating systems. The MECS architecture is centered around maintaining consistent replicas of data files cached on remote computers. MECS monitors these files and, whenever one is changed, the changed file is committed to a master database as soon as network connectivity makes it possible to do so. MECS provides subscriptions for remote users to automatically receive new data as they are generated. Remote users can be producers as well as consumers of data. Whereas a prior program that provides some of the same services treats disconnection of a user from the network of users as an error from which recovery must be effected, MECS treats disconnection as a nominal state of the network: This leads to a different design that is more efficient for serving many users, each of whom typically connects and disconnects frequently and wants only a small fraction of the data at any given time.

Norris, Jeffrey↗
NASA NTRS1990

Distributed planning and scheduling for instrument and platform operations

Distributed planning and scheduling for instruments and platform operations in resource constrained environments are discussed. NASA has repeatedly faced the situation of multiple users having differing goals, objectives, and requirements interacting with a planning and scheduling system. Current examples include the Hubble Space Telescope and Space Station Freedom. The paper provides a brief description of the instrument and platform operations domain, discusses both traditional and distributed planning and scheduling in the context of this domain, and looks at examples of NASA environments in which planning and scheduling is or will be performed in a distributed system.

Hull, Larry G.↗
NASA NTRS1993

Distributed science operations for JPL planetary missions

Advances in spacecraft, flight instruments, and ground systems provide an impetus and an opportunity for scientific investigation teams to take direct control of their instruments' operations and data collection while at the same time, providing a cost effective and flexible approach in support of increasingly complex science missions. Operations of science instruments have generally been integrated into planetary flight and ground systems at a very detailed level. That approach has been successful, but the cost of incorporating instrument expertise into the central mission operations system has been high. This paper discusses an approach to simplify planetary science operations by distributing instrument computing and data management tasks from the central mission operations system to each investigator's home center of observational expertise. Some early results of this operations concept will be presented based on the Mars Observer (MO) Project experience and Cassini Project plans.

Benson, Richard D.↗
NASA NTRS2006

Cassini distributed instrument operations – what we’ve learned since Saturn orbit insertion

The Cassini mission to Saturn is complex with 12 science teams conducting distributed operations across the United States and Europe. Each Team includes scientists from around the world who actively participate in operations, including observation design, instrument commanding, downlink processing, and archiving. This represents a change in how JPL complex deep-space missions have been operated. Since Saturn Orbit Insertion (SOI), the Cassini Project has spent 17 months conducting science operations and has gained realworld experience that has tested the assumptions and rationale for this approach. We have learned that many of the expected benefits have been realized, but there were numerous unexpected challenges as well. This paper will discuss the lessons learned from the Cassini Tour experience to date. It will revisit the assumptions and rationale behind the distributed instrument operations design and will describe the results, good and bad, of implementing this method of operations. We will describe how Instrument Teams are structured, their roles and responsibilities, what challenges they faced going into orbital operations (the “tour”) and what creative solutions were proposed when funding limitations and schedule milestones prevented optimum solutions. We will also discuss the problems that have been encountered both on the ground and with the instruments, how these problems and anomalies were overcome, and what was learned along the way about the characteristics of distributed instrument operations.

Woncik, Pam↗
NASA NTRS2006

Cassini Distributed Instrument Operations: What We've Learned Since Saturn Orbit Insertion

The Cassini mission to Saturn is complex with 12 science teams conducting distributed operations across the United States and Europe. Each Team includes scientists from around the world who actively participate in operations, including observation design, instrument commanding, downlink processing, and archiving. This represents a change in how JPL complex deep-space missions have been operated. Since Saturn Orbit Insertion (SOI), the Cassini Project has spent 17 months conducting science operations and has gained real-world experience that has tested the assumptions and rationale for this approach. We have learned that many of the expected benefits have been realized, but there were numerous unexpected challenges as well. This paper will discuss the lessons learned from the Cassini Tour experience to date. It will revisit the assumptions and rationale behind the distributed instrument operations design and will describe the results, good and bad, of implementing this method of operations. We will describe how Instrument Teams are structured, their roles and responsibilities, what challenges they faced going into orbital operations (the 'tour') and what creative solutions were proposed when funding limitations and schedule milestones prevented optimum solutions. We will also discuss the problems that have been encountered both on the ground and with the instruments, how these problems and anomalies were overcome, and what was learned along the way about the characteristics of distributed instrument operations.

Cassini↗
NASA NTRS1986

EOS: A project to investigate the design and construction of real-time distributed embedded operating systems

The EOS project is investigating the design and construction of a family of real-time distributed embedded operating systems for reliable, distributed aerospace applications. Using the real-time programming techniques developed in co-operation with NASA in earlier research, the project staff is building a kernel for a multiple processor networked system. The first six months of the grant included a study of scheduling in an object-oriented system, the design philosophy of the kernel, and the architectural overview of the operating system. In this report, the operating system and kernel concepts are described. An environment for the experiments has been built and several of the key concepts of the system have been prototyped. The kernel and operating system is intended to support future experimental studies in multiprocessing, load-balancing, routing, software fault-tolerance, distributed data base design, and real-time processing.

Campbell, R. H.↗