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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

Developing a corss-project support system during mission operations: Deep Space 1 extended mission flight control

NASA is focusing on small, low-cost spacecraft for both planetary and earth science missions. Deep Space 1 (DS1) was the first mission to be launched by the NMP. The New Millennium Project (NMP) is designed to develop and test new technology that can be used on future science missions with lower cost and risk. The NMP is finding ways to reduce cost not only in development, but also in operations. DS 1 was approved for an extended mission, but the budget was not large, so the project began looking into part time team members shared with other projects. DS1 launched on October 24, 1998, in it's primary mission it successfully tested twelve new technologies. The extended mission started September 18, 1999 and ran through the encounter with Comet Borrelly on September 22,2001. The Flight Control Team (FCT) was one team that needed to use part time or multi mission people. Circumstances led to a situation where for the few months before the Borrelly encounter in September of 2001 DSl had no certified full time Flight Control Engineers also known as Aces. This paper examines how DS 1 utilized cross-project support including the communication between different projects, and the how the tools used by the Flight Control Engineer fit into cross-project support.

New Millennium Project NMP DS flight control↗
NASA NTRS2010

Re-Engineering Complex Legacy Systems at NASA

The Flight Production Process (FPP) Re-engineering project has established a Model-Based Systems Engineering (MBSE) methodology and the technological infrastructure for the design and development of a reference, product-line architecture as well as an integrated workflow model for the Mission Operations System (MOS) for human space exploration missions at NASA Johnson Space Center. The design and architectural artifacts have been developed based on the expertise and knowledge of numerous Subject Matter Experts (SMEs). The technological infrastructure developed by the FPP Re-engineering project has enabled the structured collection and integration of this knowledge and further provides simulation and analysis capabilities for optimization purposes. A key strength of this strategy has been the judicious combination of COTS products with custom coding. The lean management approach that has led to the success of this project is based on having a strong vision for the whole lifecycle of the project and its progress over time, a goal-based design and development approach, a small team of highly specialized people in areas that are critical to the project, and an interactive approach for infusing new technologies into existing processes. This project, which has had a relatively small amount of funding, is on the cutting edge with respect to the utilization of model-based design and systems engineering. An overarching challenge that was overcome by this project was to convince upper management of the needs and merits of giving up more conventional design methodologies (such as paper-based documents and unwieldy and unstructured flow diagrams and schedules) in favor of advanced model-based systems engineering approaches.

Ruszkowski, James↗
NASA NTRS2016

Agile: From Software to Mission System

The Resource Prospector (RP) is an in-situ resource utilization (ISRU) technology demonstration mission, designed to search for volatiles at the Lunar South Pole. This is NASA's first near real time tele-operated rover on the Moon. The primary objective is to search for volatiles at one of the Lunar Poles. The combination of short mission duration, a solar powered rover, and the requirement to explore shadowed regions makes for an operationally challenging mission. To maximize efficiency and flexibility in Mission System design and thus to improve the performance and reliability of the resulting Mission System, we are tailoring Agile principles that we have used effectively in ground data system software development and applying those principles to the design of elements of the mission operations system.

software engineering↗
NASA NTRS1994

The NASA Mission Operations and Control Architecture Program

The conflict between increases in space mission complexity and rapidly declining space mission budgets has created strong pressures to radically reduce the costs of designing and operating spacecraft. A key approach to achieving such reductions is through reducing the development and operations costs of the supporting mission operations systems. One of the efforts which the Communications and Data Systems Division at NASA Headquarters is using to meet this challenge is the Mission Operations Control Architecture (MOCA) project. Technical direction of this effort has been delegated to the Mission Operations Division (MOD) of the Goddard Space Flight Center (GSFC). MOCA is to develop a mission control and data acquisition architecture, and supporting standards, to guide the development of future spacecraft and mission control facilities at GSFC. The architecture will reduce the need for around-the-clock operations staffing, obtain a high level of reuse of flight and ground software elements from mission to mission, and increase overall system flexibility by enabling the migration of appropriate functions from the ground to the spacecraft. The end results are to be an established way of designing the spacecraft-ground system interface for GSFC's in-house developed spacecraft, and a specification of the end to end spacecraft control process, including data structures, interfaces, and protocols, suitable for inclusion in solicitation documents for future flight spacecraft. A flight software kernel may be developed and maintained in a condition that it can be offered as Government Furnished Equipment in solicitations. This paper describes the MOCA project, its current status, and the results to date.

Ondrus, Paul J.↗
NASA NTRS2006

Spitzer Observatory Operations -- Increasing Efficiency in Mission Operations

This paper explores the how's and why's of the Spitzer Mission Operations System's (MOS) success, efficiency, and affordability in comparison to other observatory-class missions. MOS exploits today's flight, ground, and operations capabilities, embraces automation, and balances both risk and cost. With operational efficiency as the primary goal, MOS maintains a strong control process by translating lessons learned into efficiency improvements, thereby enabling the MOS processes, teams, and procedures to rapidly evolve from concept (through thorough validation) into in-flight implementation. Operational teaming, planning, and execution are designed to enable re-use. Mission changes, unforeseen events, and continuous improvement have often times forced us to learn to fly anew. Collaborative spacecraft operations and remote science and instrument teams have become well integrated, and worked together to improve and optimize each human, machine, and software-system element.

operational efficiency↗
NASA NTRS1985

Planetary mission operations - An overview

An overview of the missions operations systems (MOS) used to support NASA planetary missions is given. The principal factors governing the design characteristics of MOS are discussed, including: the communications requirements of spacecraft over long distance from the earth, the fragility of the scientific payloads, and the inability to carry out planetary missions more than a few times a decade. The uplink and downlink parts of the MOS of Galileo and Voyager spacecraft are illustrated as examples of successful MOS design. A black and white photograph of the operations control center of JPL is provided.

Haynes, N. R.↗
NASA NTRS1994

Shared mission operations concept

Historically, new JPL flight projects have developed a Mission Operations System (MOS) as unique as their spacecraft, and have utilized a mission-dedicated staff to monitor and control the spacecraft through the MOS. NASA budgetary pressures to reduce mission operations costs have led to the development and reliance on multimission ground system capabilities. The use of these multimission capabilities has not eliminated an ongoing requirement for a nucleus of personnel familiar with a given spacecraft and its mission to perform mission-dedicated operations. The high cost of skilled personnel required to support projects with diverse mission objectives has the potential for significant reduction through shared mission operations among mission-compatible projects. Shared mission operations are feasible if: (1) the missions do not conflict with one another in terms of peak activity periods, (2) a unique MOS is not required, and (3) there is sufficient similarity in the mission profiles so that greatly different skills would not be required to support each mission. This paper will further develop this shared mission operations concept. We will illustrate how a Discovery-class mission would enter a 'partner' relationship with the Voyager Project, and can minimize MOS development and operations costs by early and careful consideration of mission operations requirements.

Spradlin, Gary L.↗
NASA NTRS1993

Toward lowering the cost of mission operations

The mission operations system is one of the more significant drivers of the cost of the mission operations and data analysis segment of missions. In large or long-lived projects, the MOS can also be a driver in total mission cost. Larger numbers of missions, together with an increasingly cost-conscious environment, dictate that future missions must more strictly control costs as they perform to their requirements. It is therefore prudent to examine the conduct of past missions for ways to conserve resources. In this paper we review inputs made to past projects' 'lessons-learned' activities, in which personnel from past projects (among other things) identified major cost drivers of MOS's and considered how economies were or might have been realized in both design and performance of their MOS. Common themes among four such reviews are summarized in an attempt to provide suggestions for cost reduction in future missions.

Wall, S. D.↗
NASA NTRS1993

Mission Operations and Command Assurance: Flight Operations Quality Improvements

Flight mission operations systems place human operators in demanding, high risk environments. The objective of Mission Operations and Command Assurance (MO&CA) is to help improve the operational reliability of flight projects by reducing error -- Pareto Analysis shows that the human is the largest error category. MO&CA is a system level task reporting to project flight management and JPL Systems Assurance Division. MO&CA provides direct transfer of knowledge, continuous process improvement, and communication facilitation.

mission↗
NASA NTRS1994

Renaissance architecture for Ground Data Systems

The Mission Operations and Data Systems Directorate (MO&DSD) has embarked on a new approach for developing and operating Ground Data Systems (GDS) for flight mission support. This approach is driven by the goals of minimizing cost and maximizing customer satisfaction. Achievement of these goals is realized through the use of a standard set of capabilities which can be modified to meet specific user needs. This approach, which is called the Renaissance architecture, stresses the engineering of integrated systems, based upon workstation/local area network (LAN)/fileserver technology and reusable hardware and software components called 'building blocks.' These building blocks are integrated with mission specific capabilities to build the GDS for each individual mission. The building block approach is key to the reduction of development costs and schedules. Also, the Renaissance approach allows the integration of GDS functions that were previously provided via separate multi-mission facilities. With the Renaissance architecture, the GDS can be developed by the MO&DSD or all, or part, of the GDS can be operated by the user at their facility. Flexibility in operation configuration allows both selection of a cost-effective operations approach and the capability for customizing operations to user needs. Thus the focus of the MO&DSD is shifted from operating systems that we have built to building systems and, optionally, operations as separate services. Renaissance is actually a continuous process. Both the building blocks and the system architecture will evolve as user needs and technology change. Providing GDS on a per user basis enables this continuous refinement of the development process and product and allows the MO&DSD to remain a customer-focused organization. This paper will present the activities and results of the MO&DSD initial efforts toward the establishment of the Renaissance approach for the development of GDS, with a particular focus on both the technical and process implications posed by Renaissance to the MO&DSD.

Perkins, Dorothy C.↗
NASA NTRS1988

Artificial intelligence in a mission operations and satellite test environment

A Generic Mission Operations System using Expert System technology to demonstrate the potential of Artificial Intelligence (AI) automated monitor and control functions in a Mission Operations and Satellite Test environment will be developed at the National Aeronautics and Space Administration (NASA) Jet Propulsion Laboratory (JPL). Expert system techniques in a real time operation environment are being studied and applied to science and engineering data processing. Advanced decommutation schemes and intelligent display technology will be examined to develop imaginative improvements in rapid interpretation and distribution of information. The Generic Payload Operations Control Center (GPOCC) will demonstrate improved data handling accuracy, flexibility, and responsiveness in a complex mission environment. The ultimate goal is to automate repetitious mission operations, instrument, and satellite test functions by the applications of expert system technology and artificial intelligence resources and to enhance the level of man-machine sophistication.

Busse, Carl↗
NASA NTRS1989

Shuttle remote manipulator system mission preparation and operations

The preflight planning, analysis, procedures development, and operations support for the Space Transportation System payload deployment and retrieval missions utilizing the Shuttle Remote Manipulator System are summarized. Analysis of the normal operational loads and failure induced loads and motion are factored into all procedures. Both the astronaut flight crews and the Mission Control Center flight control teams receive considerable training for standard and mission specific operations. The real time flight control team activities are described.

Smith, Ernest E., Jr.↗
NASA NTRS2018

Ground Software Technologies – Embracing Change: Mission Drivers and Technology Opportunities to Enable Long Lived Missions

Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.

Giovannoni, Brian J.↗
NASA NTRS2011

Mission Operations Planning and Scheduling System (MOPSS)

MOPSS is a generic framework that can be configured on the fly to support a wide range of planning and scheduling applications. It is currently used to support seven missions at Goddard Space Flight Center (GSFC) in roles that include science planning, mission planning, and real-time control. Prior to MOPSS, each spacecraft project built its own planning and scheduling capability to plan satellite activities and communications and to create the commands to be uplinked to the spacecraft. This approach required creating a data repository for storing planning and scheduling information, building user interfaces to display data, generating needed scheduling algorithms, and implementing customized external interfaces. Complex scheduling problems that involved reacting to multiple variable situations were analyzed manually. Operators then used the results to add commands to the schedule. Each architecture was unique to specific satellite requirements. MOPSS is an expert system that automates mission operations and frees the flight operations team to concentrate on critical activities. It is easily reconfigured by the flight operations team as the mission evolves. The heart of the system is a custom object-oriented data layer mapped onto an Oracle relational database. The combination of these two technologies allows a user or system engineer to capture any type of scheduling or planning data in the system's generic data storage via a GUI.

Wood, Terri↗