SEARCH · Search NASA

Results for “mission operations system engineering”

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 145 records · Page 8

All sources NASA NTRS DOE OSTI

NASA NTRS2015

Software Innovation in a Mission Critical Environment

Operating in mission-critical environments requires trusted solutions, and the preference for "tried and true" approaches presents a potential barrier to infusing innovation into mission-critical systems. This presentation explores opportunities to overcome this barrier in the software domain. It outlines specific areas of innovation in software development achieved by the Johnson Space Center (JSC) Engineering Directorate in support of NASA's major human spaceflight programs, including International Space Station, Multi-Purpose Crew Vehicle (Orion), and Commercial Crew Programs. Software engineering teams at JSC work with hardware developers, mission planners, and system operators to integrate flight vehicles, habitats, robotics, and other spacecraft elements for genuinely mission critical applications. The innovations described, including the use of NASA Core Flight Software and its associated software tool chain, can lead to software that is more affordable, more reliable, better modelled, more flexible, more easily maintained, better tested, and enabling of automation.

Fredrickson, Steven↗

NASA NTRS1985

Thermal arcjet technology for space propulsion

Advanced space propulsion systems are required to meet projected Air Force needs through the year 2000. Most of these missions require a large, on-orbit impulse capability. High specific impulse (I sub sp) electric engines can provide this impulse while consuming relatively little propellant. An arcjet engine system, which operates in the range of 800 to 2000 s I sub sp, is a promising candidate to meet these projected Air Force mission needs. This electric propulsion system is ideally suited to missions currently under consideration, such as the Space-based Radar and other space platforms, because sufficient power is already installed for other functions on the spacecraft. Also, arcjet systems are attractive for NASA near-term, low-cost Mariner Mark II missions to Saturn and Uranus. Development of arcjet engines was an Air Force and NASA-sponsored activity that proceeded vigorously from its inception during the late 1950's up to the mid-1960's when the programs were terminated. This paper describes thermal arcjet technology as it was developed over two decades ago and points to the direction this technology development should proceed in the future. In particular, operation with storable propellants such as ammonia and hydrazine are considered. The performance, applicability and advantages of these systems in terms of increased payload and/or decreased trip times are discussed.

Pivirotto, T. J.↗

NASA NTRS1994

Re-Engineering the Multimission Command System at the Jet Propulsion Laboratory

This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use in JPL's Advanced Multimission Operations System.The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

re-engineering↗

NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

NASA NTRS1977

Viking 75 project: Viking lander system primary mission performance report

Viking Lander hardware performance during launch, interplanetary cruise, Mars orbit insertion, preseparation, separation through landing, and the primary landed mission, with primary emphasis on Lander engineering and science hardware operations, the as-flown mission are described with respect to Lander system performance and anomalies during the various mission phases. The extended mission and predicted Lander performance is discussed along with a summary of Viking goals, mission plans, and description of the Lander, and its subsystem definitions.

Cooley, C. G.↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

NASA NTRS2006

Advances in Distributed Operations and Mission Activity Planning for Mars Surface Exploration

A centralized mission activity planning system for any long-term mission, such as the Mars Exploration Rover Mission (MER), is completely infeasible due to budget and geographic constraints. A distributed operations system is key to addressing these constraints; therefore, future system and software engineers must focus on the problem of how to provide a secure, reliable, and distributed mission activity planning system. We will explain how Maestro, the next generation mission activity planning system, with its heavy emphasis on portability and distributed operations has been able to meet these design challenges. MER has been an excellent proving ground for Maestro's new approach to distributed operations. The backend that has been developed for Maestro could benefit many future missions by reducing the cost of centralized operations system architecture.

Mars Exploration Rover (MER)↗

NASA NTRS2006

Advances in distributed operations and mission activity planning for Mars surface exploration

Shams, Khawaja↗

NASA NTRS2010

Systems Engineering and Application of System Performance Modeling in SIM Lite Mission

The SIM Lite Astrometric Observatory will be the first space-based Michelson interferometer operating in the visible wavelength, with the ability to perform ultra-high precision astrometric measurements on distant celestial objects. SIM Lite data will address in a fundamental way questions such as characterization of Earth-mass planets around nearby stars. To accomplish these goals it is necessary to rely on a model-based systems engineering approach - much more so than most other space missions. This paper will describe in further detail the components of this end-to-end performance model, called "SIM-sim", and show how it has helped the systems engineering process.

Exoplanet↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗

NASA NTRSDate not supplied

Mission Operations, Cubed: NASA Marshall Operations Support for SmallSats

SmallSats have come a long way since the Huntsville Operations Support Center (HOSC) at NASA’s Marshall Space Flight Center supported its first “minisatellite” mission in 2010. And just as SmallSats themselves have evolved in those 12 years, so too has the HOSC’s mission support for SmallSats. Marshall Space Flight Center has a long history with payload and mission operations, including support for the Apollo missions to the moon, the Space Shuttle program, and 21 years of continuous around-the-clock science operations support for research aboard the International Space Station. Today, the HOSC is a multi-tenant facility, supporting not only ISS, but also NASA’s Commercial Crew program, the Space Launch System, the Hubble and Chandra observatories and others – including multiple SmallSat missions. Two SmallSat solar sail missions will be among those taking advantage of the HOSC’s resources for planning, training for and executing mission operations – the Near Earth Asteroid (NEA) Scout and Solar Cruiser missions. One of 10 6U CubeSats manifest on the Artemis I launch of NASA’s Space Launch System rocket this year, NEA Scout’s three-year mission will be supported through a more traditional operations concept, with a dedicated Flight Controller staff operating within the HOSC. Scheduled to launch as part of the Interstellar Mapping and Acceleration Probe (IMAP) in February 2025, Solar Cruiser’s 11-month mission will take a next-generation approach to operations by utilizing a multi-mission flight controller concept, as well as Marshall’s Telescience Resource Kit (TreK). TreK provides a suite of software applications and libraries that allow the Mission Operations Center to serve as an in-house ground system which incorporates remote and automation capability options for engineers and scientists. This presentation will compare the approaches the HOSC will use to support these two missions as a way of demonstrating the array of options NASA MSFC offers for operations support for CubeSat and SmallSat missions.

Darren S Wallace↗

NASA NTRSDate not supplied

Biological Research and Space Health Enabled by Machine Learning to Support Deep Space Missions

A key science goal of the NASA “Moon to Mars” campaign is to understand how biology responds to the Lunar, Martian, and deep space environments in order to advance fundamental knowledge and support human space missions. Through artificial intelligence (AI) and machine learning (ML), a paradigm shift has begun in space biosciences and engineered astronaut health systems, to enable Earth-independence and mission operations autonomy. We describe current AI/ML methods to support 1) fundamental biology, 2) in situ analytics, 3) high performance computing, 4) automated science, 5) self-driving labs, 6) remote data management, 7) integrated mission biomonitoring, and 8) a Precision Space Health system. AI/ML approaches that can be integrated to support these domains include active learning, explainable AI, adaptive learning, causal inference, knowledge graphs, federated learning, transfer learning, and large language models. Finally, we present results from several current ML projects that are underway in the space biology field to address key challenges of small sample n, high feature count, heterogeneity, and sparse data. These include 1) connecting omics to phenotypic data using an ensemble model to infer causality of rodent liver health disruption, 2) usage of explainable ML to interrogate muscular underpinnings of muscle atrophy, 3) ML models analyzing and determining directed acyclic graphs of human health risk leveraging rodent bone datasets, 4) usage of large pre-trained models connecting biomedical knowledgebases with small spaceflight datasets to understand gene-to-gene interactions, and 5) a suite of benchmarked open science datasets enabling programmers to identify best algorithms to answer space biology questions.

space biology↗

NASA NTRS2010

An Operations Concept for Integrated Model-Centric Engineering at JPL

As JPL's missions grow more complex, the need for improved systems engineering processes is becoming clear. Of significant promise in this regard is the move toward a more integrated and model-centric approach to mission conception, design, implementation and operations. The Integrated Model-Centric Engineering (IMCE) Initiative, now underway at JPL, seeks to lay the groundwork for these improvements. This paper will report progress on three fronts: articulating JPL's need for IMCE; characterizing the enterprise into which IMCE capabilities will be deployed; and constructing an operations concept for a flight project development in an integrated model-centric environment.

Bayer, Todd J.↗

NASA NTRS2019

Landsat 9 Micrometeoroid and Orbital Debris (MMOD) Mission Success Approach

Landsat 9* (L9) is the successor mission to Landsat 8 (L8) previously known as Landsat Data Continuity Mission (LDCM). Both missions are large unmanned remote sensing satellites operating in sunsynchronous polar orbits. As opposed to L8/LDCM, systems engineers for L9 incorporated Micrometeoroid/Orbital Debris (MMOD) protection for small object collisions as part of the L9’s mission success criteria. In other words, the NASA Process for Limiting Orbital Debris (NASA-STD-8719.14A) only calls for analyses of the protection of disposal-critical hardware, but L9 opted to also assess and provide small particle penetration protections for all observatory components including instruments that are not part of the spacecraft components needed for controlled reentry. Systems engineers at Goddard developed a design process to protect against MMOD during the life of Low Earth Orbit (LEO) observatories, and in particular the Landsat 9 Mission. Simply stated, this design process enhanced the effectiveness of existing Multi-Layer Insulation (MLI) to provide the needed protection. The end goal of the design process was to establish a necessary blanket areal density for a given electronics box or instrument wall thickness and a separation between the outer MLI blanket and the structure underneath. The trade space was presented as a set of design curves for different combinations of blanket density, box wall thickness, and separation distance between MLI and structure. An advantage of this process was that it is largely independent of MMOD flux data on a surface-by surface basis. Ultimately, cost savings should result from incorporating small object penetration protection early in the design cycle, rather than adding spot shielding blankets later as needed to meet an overall penetration risk standard (the more traditional approach). The approach and implementation to the L9 Observatory design will be addressed in this paper. *L9 is a joint mission being formulated, implemented, and operated by the National Aeronautics and Space Administration (NASA) and the Department of the Interior’s (DOI) United States Geological Survey (USGS).

Approach↗

NASA NTRS1987

Thermal barrier coating life-prediction model development

The primary objective of this program was to develop an operative thermal barrier coating (TBC) design model for life prediction. The objective was successfully accomplished with the development, calibration, and demonstration of a mechanistic thermochemical model which rapidly predicts TBC life as a function of engine, mission, and materials system parameters. This thermochemical design model accounts for the three operative TBC damage modes (bond coating oxidation, zirconia toughness reduction, and molten salt film damage), which all contribute to spalling of the insulating zirconia layer.

Strangman, T. E.↗

NASA NTRS1993

Making adaptable systems work for mission operations: A case study

The Advanced Multimission Operations System (AMMOS) at NASA's Jet Propulsion Laboratory is based on a highly adaptable multimission ground data system (MGDS) for mission operations. The goal for MGDS is to support current flight project science and engineering personnel and to meet the demands of future missions while reducing associated operations and software development costs. MGDS has become a powerful and flexible mission operations system by using a network of heterogeneous workstations, emerging open system standards, and selecting an adaptable tools-based architecture. Challenges in developing adaptable systems for mission operations and the benefits of this approach are described.

Holder, Barbara E.↗

NASA NTRS1992

Mission operations technology

Developments in the area of spacecraft operations are examined that can be utilized in mission and spacecraft designs to enhance the efficiency of planetary and other mission operations. The technology enhancements described address four major systems: the spacecraft, the tracking and data system, the spaceflight operations center, and the flight projects. Specific technological advances are detailed in the areas of telemetry monitoring and fault analysis, scheduling systems, and scientific data analysis. The Spacecraft Health Automated Reasoning Prototype and the Engineering Analysis Subsystem Environment can provide real-time monitoring and analysis with limited workforce resources. The Multimission Automation for Real-time Verification of Spacecraft Engineering Link, the Operation Mission Planner, and the Sky Image Classification and Archiving Tool are other examples of systems developed by NASA that enhance operations technology by reducing the need for human input.

Varsi, Giulio↗

NASA NTRS2008

Human Rating Requirements for NASA's Constellation Program

NASA s Constellation Program (CxP) will conduct a series of human space expeditions of increasing scope, starting with missions supporting the International Space Station and expanding to encompass the Moon and Mars. Although human-rating is an integral part of all CxP activities throughout their life cycle, NASA Procedural Requirements document NPR 8705.2B, Human-Rating Requirements (HRR) for Space Flight Systems, defines the additional processes, procedures, and requirements necessary to produce human-rated space systems that protect the safety of crew members and passengers on these NASA missions. In order to be in compliance with 8705.2B the CxP must show appropriate implementation or progression toward the HRR, or justification for an exception. Compliance includes an explanation of how the CxP intends to meet the HRR, analyses to be performed to determine implementation; and a matrix to trace the HRR to CxP requirements. The HRR requires the CxP to establish a human system integration team (HSIT), consisting of astronauts, mission operations personnel, training personnel, ground processing personnel, human factors personnel, and human engineering experts, with clearly defined authority, responsibility, and accountability to lead the human-system integration. For example, per the HRR the HSIT is involved in the evaluation of crew workload, human-in-the-loop usability evaluations, determining associated criteria, and in assessment of how these activities influenced system design. In essence, the HSIT is invaluable in CxP s ability to meet the three fundamental tenets of human rating: the process of designing, evaluating, and assuring that the total system can safely conduct the required human missions; the incorporation of design features and capabilities that accommodate human interaction with the system to enhance overall safety and mission success; and the incorporation of design features and capabilities to enable safe recovery of the crew from hazardous situations.

Berdich, Debbie↗