Search NASA⌕ Search

SEARCH · Search NASA

Results for “mission operations system”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

MOS 2.0: The Next Generation in Mission Operations Systems

A Mission Operations System (MOS) or Ground System constitutes that portion of an overall space mission Enterprise that resides here on Earth. Over the past two decades, technological innovations in computing and software technologies have allowed an MOS to support ever more complex missions while consuming a decreasing fraction of Project development budgets. Despite (or perhaps, because of) such successes, it is routine to hear concerns about the cost of MOS development. At the same time, demand continues for Ground Systems which will plan more spacecraft activities with fewer commanding errors, provide scientists and engineers with more autonomous functionality, process and manage larger and more complex data more quickly, all while requiring fewer people to develop, deploy, operate and maintain them. One successful approach to such concerns over this period is a multimission approach, based on the reuse of portions (most often software) developed and used in previous missions. The Advanced Multi-Mission Operations System (AMMOS), developed for deep-space science missions, is one successful example of such an approach. Like many computing-intensive systems, it has grown up in a near-organic fashion from a relatively simple set of tools into a complexly interrelated set of capabilities. Such systems, like a city lacking any concept of urban planning, can and will grow in ways that are neither efficient nor particularly easy to sustain. To meet the growing demands and unyielding constraints placed on ground systems, a new approach is necessary. Under the aegis of a multi-year effort to revitalize the AMMOS's multimission operations capabilities, we are utilizing modern practices in systems architecting and model-based engineering to create the next step in Ground Systems: MOS 2.0. In this paper we outline our work (ongoing and planned) to architect and design a multimission MOS 2.0, describe our goals and measureable objectives, and discuss some of the benefits that this top-down, architectural approach holds for creating a more flexible and capable MOS for Missions while holding the line on cost.

ground systems↗
NASA NTRS1973

Mariner Mars 1971 project. Volume 3: Mission operations system implementation and standard mission flight operations

The Mariner Mars 1971 mission which was another step in the continuing program of planetary exploration in search of evidence of exobiological activity, information on the origin and evolution of the solar system, and basic science data related to the study of planetary physics, geology, planetology, and cosmology is reported. The mission plan was designed for two spacecraft, each performing a separate but complementary mission. However, a single mission plan was actually used for Mariner 9 because of failure of the launch vehicle for the first spacecraft. The implementation is described, of the Mission Operations System, including organization, training, and data processing development and operations, and Mariner 9 spacecraft cruise and orbital operations through completion of the standard mission from launch to solar occultation in April 1972 are discussed.

Source record↗
NASA NTRS2010

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗
NASA NTRS2014

A Multifaceted Approach to Modernizing NASA's Advanced Multi-Mission Operations System (AMMOS) System Architecture

The Advanced Multi-Mission Operations Systems (AMMOS) is NASA's premier space mission operations product line offering for use in deep-space robotic and astrophysics missions. The general approach to AMMOS modernization over the course of its 29-year history exemplifies a continual, evolutionary approach with periods of sponsor investment peaks and valleys in between. Today, the Multimission Ground Systems and Services (MGSS) office-the program office that manages the AMMOS for NASA-actively pursues modernization initiatives and continues to evolve the AMMOS by incorporating enhanced capabilities and newer technologies into its end-user tool and service offerings. Despite the myriad of modernization investments that have been made over the evolutionary course of the AMMOS, pain points remain. These pain points, based on interviews with numerous flight project mission operations personnel, can be classified principally into two major categories: 1) information-related issues, and 2) process-related issues. By information-related issues, we mean pain points associated with the management and flow of MOS data across the various system interfaces. By process-related issues, we mean pain points associated with the MOS activities performed by mission operators (i.e., humans) and supporting software infrastructure used in support of those activities. In this paper, three foundational concepts-Timeline, Closed Loop Control, and Separation of Concerns-collectively form the basis for expressing a set of core architectural tenets that provides a multifaceted approach to AMMOS system architecture modernization intended to address the information- and process-related issues. Each of these architectural tenets will be further explored in this paper. Ultimately, we envision the application of these core tenets resulting in a unified vision of a future-state architecture for the AMMOS-one that is intended to result in a highly adaptable, highly efficient, and highly cost-effective set of multimission MOS products and services.

Estefan, Jeff A.↗
NASA NTRS2012

Re-Engineering the Mission Operations System (MOS) for the Prime and Extended Mission

One of the most challenging tasks in a space science mission is designing the Mission Operations System (MOS). Whereas the focus of the project is getting the spacecraft built and tested for launch, the mission operations engineers must build a system to carry out the science objectives. The completed MOS design is then formally assessed in the many reviews. Once a mission has completed the reviews, the Mission Operation System (MOS) design has been validated to the Functional Requirements and is ready for operations. The design was built based on heritage processes, new technology, and lessons learned from past experience. Furthermore, our operational concepts must be properly mapped to the mission design and science objectives. However, during the course of implementing the science objective in the operations phase after launch, the MOS experiences an evolutional change to adapt for actual performance characteristics. This drives the re-engineering of the MOS, because the MOS includes the flight and ground segments. Using the Spitzer mission as an example we demonstrate how the MOS design evolved for both the prime and extended mission to enhance the overall efficiency for science return. In our re-engineering process, we ensured that no requirements were violated or mission objectives compromised. In most cases, optimized performance across the MOS, including gains in science return as well as savings in the budget profile was achieved. Finally, we suggest a need to better categorize the Operations Phase (Phase E) in the NASA Life-Cycle Phases of Formulation and Implementation

Extended Mission↗
NASA NTRS2014

Lean Mission Operations Systems Design - Using Agile and Lean Development Principles for Mission Operations Design and Development

The Resource Prospector Mission seeks to rove the lunar surface with an in-situ resource utilization payload in search of volatiles at a polar region. The mission operations system (MOS) will need to perform the short-duration mission while taking advantage of the near real time control that the short one-way light time to the Moon provides. To maximize our use of limited resources for the design and development of the MOS we are utilizing agile and lean methods derived from our previous experience with applying these methods to software. By using methods such as "say it then sim it" we will spend less time in meetings and more time focused on the one outcome that counts - the effective utilization of our assets on the Moon to meet mission objectives.

Operations↗
NASA NTRS2011

MOS 2.0: Modeling the Next Revolutionary Mission Operations System

Designed and implemented in the 1980's, the Advanced Multi-Mission Operations System (AMMOS) was a breakthrough for deep-space NASA missions, enabling significant reductions in the cost and risk of implementing ground systems. By designing a framework for use across multiple missions and adaptability to specific mission needs, AMMOS developers created a set of applications that have operated dozens of deep-space robotic missions over the past 30 years. We seek to leverage advances in technology and practice of architecting and systems engineering, using model-based approaches to update the AMMOS. We therefore revisit fundamental aspects of the AMMOS, resulting in a major update to the Mission Operations System (MOS): MOS 2.0. This update will ensure that the MOS can support an increasing range of mission types, (such as orbiters, landers, rovers, penetrators and balloons), and that the operations systems for deep-space robotic missions can reap the benefits of an iterative multi-mission framework.12 This paper reports on the first phase of this major update. Here we describe the methods and formal semantics used to address MOS 2.0 architecture and some early results. Early benefits of this approach include improved stakeholder input and buy-in, the ability to articulate and focus effort on key, system-wide principles, and efficiency gains obtained by use of well-architected design patterns and the use of models to improve the quality of documentation and decrease the effort required to produce and maintain it. We find that such methods facilitate reasoning, simulation, analysis on the system design in terms of design impacts, generation of products (e.g., project-review and software-delivery products), and use of formal process descriptions to enable goal-based operations. This initial phase yields a forward-looking and principled MOS 2.0 architectural vision, which considers both the mission-specific context and long-term system sustainability.

ground support systems↗
NASA NTRS1992

Mission operations system for Russian space Very-Long-Baseline Interferometry mission

A mission operations system developed to meet the unique requirements of the prospective Russian space VLBI mission Radioastron is described. The challenges associated with the Radioastron operations are mainly due to the interrelationship between the space-based telescope and the ground observatories, and the mission's international character. The Radioastron project includes radio observatories located in 17 different countries, tracking facilities in possibly seven different countries, orbit determination centers in Russia and USA, and widely located data processing facilities. In addition, unique scheduling constraints arise from the competing demands placed on the ground observatory time by earth-based VLBI experiments, and the tracking station time by a Japanese space interferometry mission VSOP, which is expected to be in orbit concurrently with Radioastron. A diagram illustrating the organizational structure of the Radioastron project during operations is presented.

Altunin, V. I.↗
NASA NTRS2012

Hierarchthis: An Interactive Interface for Identifying Mission-Relevant Components of the Advanced Multi-Mission Operations System

Even though NASA's space missions are many and varied, there are some tasks that are common to all of them. For example, all spacecraft need to communicate with other entities, and all spacecraft need to know where they are. These tasks use tools and services that can be inherited and reused between missions, reducing systems engineering effort and therefore reducing cost.The Advanced Multi-Mission Operations System, or AMMOS, is a collection of multimission tools and services, whose development and maintenance are funded by NASA. I created HierarchThis, a plugin designed to provide an interactive interface to help customers identify mission-relevant tools and services. HierarchThis automatically creates diagrams of the AMMOS database, and then allows users to show/hide specific details through a graphical interface. Once customers identify tools and services they want for a specific mission, HierarchThis can automatically generate a contract between the Multimission Ground Systems and Services Office, which manages AMMOS, and the customer. The document contains the selected AMMOS components, along with their capabilities and satisfied requirements. HierarchThis reduces the time needed for the process from service selections to having a mission-specific contract from the order of days to the order of minutes.

Advanced Multi-Mission Operations System (AMMOS)↗
NASA NTRS1991

Design of mission operations systems for scientific remote sensing

The present work describes the mission operations system (MOS) design process for remote-sensing missions. A MOS is defined as the system required to perform, monitor, and control an operation, encompassing personnel, hardware, software and/or documentation. Attention is given to telecommunications and remote-sensing instrumentation, MOS definition program phases and reviews, and MOS organization, management, and staffing. Also treated are the uplink and downlink processes, anomalies and contingency plans, the illustrative case of the MOS for the Magellan radar sensing mission, and a projection of future MOSs incorporating AI.

Wall, Stephen D.↗
NASA NTRS1994

Concurrent engineering: Spacecraft and mission operations system design

Despite our awareness of the mission design process, spacecraft historically have been designed and developed by one team and then turned over as a system to the Mission Operations organization to operate on-orbit. By applying concurrent engineering techniques and envisioning operability as an essential characteristic of spacecraft design, tradeoffs can be made in the overall mission design to minimize mission lifetime cost. Lessons learned from previous spacecraft missions will be described, as well as the implementation of concurrent mission operations and spacecraft engineering for the Near Earth Asteroid Rendezvous (NEAR) program.

Landshof, J. A.↗
NASA NTRS2008

A Scenario-Based Process for Requirements Development: Application to Mission Operations Systems

The notion of using operational scenarios as part of requirements development during mission formulation (Phases A & B) is widely accepted as good system engineering practice. In the context of developing a Mission Operations System (MOS), there are numerous practical challenges to translating that notion into the cost-effective development of a useful set of requirements. These challenges can include such issues as a lack of Project-level focus on operations issues, insufficient or improper flowdown of requirements, flowdown of immature or poor-quality requirements from Project level, and MOS resource constraints (personnel expertise and/or dollars). System engineering theory must be translated into a practice that provides enough structure and standards to serve as guidance, but that retains sufficient flexibility to be tailored to the needs and constraints of a particular MOS or Project. We describe a detailed, scenario-based process for requirements development. Identifying a set of attributes for high quality requirements, we show how the portions of the process address many of those attributes. We also find that the basic process steps are robust, and can be effective even in challenging Project environments.

MOS↗
NASA NTRS2006

Spitzer Pre Launch Mission Operations System - The Road to Launch

Spitzer Space Telescope was launched on 25 August 2003 into an Earth-trailing solar orbit to acquire infrared observations from space. Development of the Mission Operations System (MOS) portion prior to launch was very different from planetary missions from the stand point that the MOS teams and Ground Data System had to be ready to support all aspects of the mission at launch (i.e., no cruise period for finalizing the implementation). For Spitzer, all mission-critical events post launch happen in hours or days rather than months or years, as is traditional with deep space missions. At the end of 2000 the Project was dealt a major blow when the Mission Operations System (MOS) had an unsuccessful Critical Design Review (CDR). The project made major changes at the beginning of 2001 in an effort to get the MOS (and Project) back on track. The result for the Spitzer Space Telescope was a successful launch of the observatory followed by an extremely successful In Orbit Checkout (IOC) and operations phase. This paper describes how the project was able to recover the MOS to a successful Delta (CDR) by mid 2001, and what changes in philosophies, experiences, and lessons learned followed. It describes how projects must invest early or else invest heavily later in the development phase to achieve a successful operations phase.

observatory↗
NASA NTRS2010

Spitzer Mission Operation System Planning for IRAC Warm-Instrument Characterization

This paper will describe how the Spitzer Mission Operations System planned and executed the characterization phase between Spitzer's cryogenic mission and its warm mission. To the largest extend possible, the execution of this phase was done with existing processing and procedures. The modifications that were made were in response to the differences of the characterization phase compared to normal phases before and after. The primary two categories of difference are: unknown date of execution due to uncertainty of knowledge of the date of helium depletion, and the short cycle time for data analysis and re-planning during execution. In addition, all of the planning and design had to be done in parallel with normal operations, and we had to transition smoothly back to normal operations following the transition. This paper will also describe the re-planning we had to do following an anomaly discovered in the first days after helium depletion.

IWIC↗