Search NASA⌕ Search

SEARCH · Search NASA

Results for “Mission manager software”

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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

An agent-oriented approach to automated mission operations

As we plan for the next generation of Mission Operations Control Center (MOCC) systems, there are many opportunities for the increased utilization of innovative knowledge-based technologies. The innovative technology discussed is an advanced use of agent-oriented approaches to the automation of mission operations. The paper presents an overview of this technology and discusses applied operational scenarios currently being investigated and prototyped. A major focus of the current work is the development of a simple user mechanism that would empower operations staff members to create, in real time, software agents to assist them in common, labor intensive operations tasks. These operational tasks would include: handling routine data and information management functions; amplifying the capabilities of a spacecraft analyst/operator to rapidly identify, analyze, and correct spacecraft anomalies by correlating complex data/information sets and filtering error messages; improving routine monitoring and trend analysis by detecting common failure signatures; and serving as a sentinel for spacecraft changes during critical maneuvers enhancing the system's capabilities to support nonroutine operational conditions with minimum additional staff. An agent-based testbed is under development. This testbed will allow us to: (1) more clearly understand the intricacies of applying agent-based technology in support of the advanced automation of mission operations and (2) access the full set of benefits that can be realized by the proper application of agent-oriented technology in a mission operations environment. The testbed under development addresses some of the data management and report generation functions for the Explorer Platform (EP)/Extreme UltraViolet Explorer (EUVE) Flight Operations Team (FOT). We present an overview of agent-oriented technology and a detailed report on the operation's concept for the testbed.

Truszkowski, Walt↗
NASA NTRS1980

STS-1 operational flight profile. Volume 5: Descent, cycle 3

The trajectory data presented are to be used for orbiter systems and subsystems evalation, flight and mission control center software verification, flight techniques and timeline development, crew training, and evaluation of operational mission suitability. The entry profile is very similar to cycle 2, however, elevon and body flap temperature margins have increased and the elevon schedule was changed. The terminal area energy management (TAEM) profile was completely reshaped to conform with new angle of attack constraints and left hand turn around the heading alignment cylinder. Also, the entry/TAEM interface was adjusted to minimize guidance induced angle of attack transients across the interface. The approach and landing phase was reshaped for a 20 deg glideslope and reduced velocity at touchdown. The definition of the runway threshold was standardized for all landing sites. This results in a shift at Edwards Air Force Base in aim points and touchdown relative to the threshold of 1000 feet. The rollout remains essentially unchanged with the exception of the speedbrake, which is now deployed to 50 percent at touchdown.

Moore, R.↗
NASA NTRS2018

Development of a Ground Test and Analysis Protocol for NASA's NextSTEP Phase 2 Habitation Concepts

The NASA Next Space Technologies for Exploration Partnerships (NextSTEP) program is a public-private partnership model that seeks commercial development of deep space exploration capabilities to support human spaceflight missions around and beyond cislunar space. NASA first issued the Phase 1 NextSTEP Broad Agency Announcement to U.S. industries in 2014, which called for innovative cislunar habitation concepts that leveraged commercialization plans for low-Earth orbit. These habitats will be part of the Deep Space Gateway (DSG), the cislunar space station planned by NASA for construction in the 2020s. In 2016, Phase 2 of the NextSTEP program selected five commercial partners to develop ground prototypes. A team of NASA research engineers and subject matter experts (SMEs) have been tasked with developing the ground-test protocol that will serve as the primary means by which these Phase 2 prototypes will be evaluated. Since 2008, this core test team has successfully conducted multiple spaceflight analog mission evaluations utilizing a consistent set of operational tools, methods, and metrics to enable the iterative development, testing, analysis, and validation of evolving exploration architectures, operations concepts, and vehicle designs. The purpose of implementing a similar evaluation process for the Phase 2 Habitation Concepts is to consistently evaluate different commercial partner ground prototypes to provide data-driven, actionable recommendations for Phase 3. This paper describes the process by which the ground test protocol was developed and the objectives, methods, and metrics by which the NextSTEP Phase 2 Habitation Concepts will be rigorously and systematically evaluated. The protocol has been developed using both a top-down and bottom-up approach. Top-down development began with the Human Exploration and Operations Mission Directorate (HEOMD) exploration objectives and ISS Exploration Capability Study Team (IECST) candidate flight objectives. Strategic questions and associated rationales, derived from these candidate architectural objectives, provide the framework by which the ground-test protocol will address the DSG stack elements and configurations, systems and subsystems, and habitation, science, and EVA functions. From these strategic questions, high-level functional requirements for the DSG were drafted and associated ground-test objectives and analysis protocols were established. Bottom-up development incorporated objectives from NASA SMEs in autonomy, avionics and software, communication, environmental control and life support systems, exercise, extravehicular activity, exploration medical operations, guidance navigation and control, human factors and behavioral performance, human factors and habitability, logistics, Mission Control Center operations, power, radiation, robotics, safety and mission assurance, science, simulation, structures, thermal, trash management, and vehicle health. Top-down and bottom-up objectives were integrated to form overall functional requirements - ground-test objectives and analysis mapping. From this mapping, ground-test objectives were organized into those that will be evaluated through inspection, demonstration, analysis, subsystem standalone testing, and human-in-the-loop (HITL) testing. For the HITL tests, mission-like timelines, procedures, and flight rules have been developed to directly meet ground test objectives and evaluate specific functional requirements. Data collected from these assessments will be analyzed to determine the acceptability of habitation element configurations and the combinations of capabilities that will result in the best habitation platform to be recommended by the test team for Phase 3.

Gernhardt, Michael L.↗
NASA NTRS2013

Managing the Risk of Command File Errors

Command File Error (CFE), as defined by the Jet Propulsion Laboratory's (JPL) Mission Operations Assurance (MOA) is, regardless of the consequence on the spacecraft, either: an error in a command file sent to the spacecraft, an error in the process for developing and delivering a command file to the spacecraft, or the omission of a command file that should have been sent to the spacecraft. The risk consequence of a CFE can be mission ending and thus a concern to space exploration projects during their mission operations. A CFE during space mission operations is often the symptom of some kind of imbalance or inadequacy within the system that comprises the hardware & software used for command generation and the human experts involved in this endeavour. As we move into an era of enhanced collaboration with other NASA centers and commercial partners, these systems become more and more complex and hence it is all the more important to formally model and analyze CFEs in order to manage the risk of CFEs. Here we will provide a summary of the ongoing efforts at JPL in this area and also explain some more recent developments in the area of developing quantitative models for the purpose of managing CFE's.

Bayesian Belief Networks↗
NASA NTRS1990

Operations management system

The objective of an operations management system is to provide an orderly and efficient method to operate and maintain aerospace vehicles. Concepts are described for an operations management system and the key technologies are highlighted which will be required if this capability is brought to fruition. Without this automation and decision aiding capability, the growing complexity of avionics will result in an unmanageable workload for the operator, ultimately threatening mission success or survivability of the aircraft or space system. The key technologies include expert system application to operational tasks such as replanning, equipment diagnostics and checkout, global system management, and advanced man machine interfaces. The economical development of operations management systems, which are largely software, will require advancements in other technological areas such as software engineering and computer hardware.

Brandli, A. E.↗
NASA NTRS1991

Information Flow Analysis of Level 4 Payload Processing Operations

The Level 4 Mission Sequence Test (MST) was studied to develop strategies and recommendations to facilitate information flow. Recommendations developed as a result of this study include revised format of the Test and Assembly Procedure (TAP) document and a conceptualized software based system to assist in the management of information flow during the MST.

Danz, Mary E.↗
NASA NTRS1995

Flight dynamics software in a distributed network environment

As with all NASA facilities, the announcement of reduced budgets, reduced staffing, and the desire to implement smaller/quicker/cheaper missions has required the Agency's organizations to become more efficient in what they do. To accomplish these objectives, the FDD has initiated the development of the Flight Dynamics Distributed System (FDDS). The underlying philosophy of FDDS is to build an integrated system that breaks down the traditional barriers of attitude, mission planning, and navigation support software to provide a uniform approach to flight dynamics applications. Through the application of open systems concepts and state-of-the-art technologies, including object-oriented specification concepts, object-oriented software, and common user interface, communications, data management, and executive services, the FDD will reengineer most of its six million lines of code.

Jeletic, J.↗
NASA NTRS2005

Path Planning Algorithms for the Adaptive Sensor Fleet

The Adaptive Sensor Fleet (ASF) is a general purpose fleet management and planning system being developed by NASA in coordination with NOAA. The current mission of ASF is to provide the capability for autonomous cooperative survey and sampling of dynamic oceanographic phenomena such as current systems and algae blooms. Each ASF vessel is a software model that represents a real world platform that carries a variety of sensors. The OASIS platform will provide the first physical vessel, outfitted with the systems and payloads necessary to execute the oceanographic observations described in this paper. The ASF architecture is being designed for extensibility to accommodate heterogenous fleet elements, and is not limited to using the OASIS platform to acquire data. This paper describes the path planning algorithms developed for the acquisition phase of a typical ASF task. Given a polygonal target region to be surveyed, the region is subdivided according to the number of vessels in the fleet. The subdivision algorithm seeks a solution in which all subregions have equal area and minimum mean radius. Once the subregions are defined, a dynamic programming method is used to find a minimum-time path for each vessel from its initial position to its assigned region. This path plan includes the effects of water currents as well as avoidance of known obstacles. A fleet-level planning algorithm then shuffles the individual vessel assignments to find the overall solution which puts all vessels in their assigned regions in the minimum time. This shuffle algorithm may be described as a process of elimination on the sorted list of permutations of a cost matrix. All these path planning algorithms are facilitated by discretizing the region of interest onto a hexagonal tiling.

Stoneking, Eric↗
NASA NTRSDate not supplied

Open Science in Action: The Role of SWxSOC in Expedited Data Release and Cloud-based Data Processing for Heliophysics Missions

NASA's Space Weather Science Operations Center (SWxSOC) is an effort to develop a multi-mission Science Operations Center for the community and specifically Space Weather missions that require data products to be released consistently and quickly. The SWxSOC is committed to Open Science in its approach to software development and data product releases. We are currently supporting the Heliophysics Environmental and Radiation Measurement Experiment Suite (HERMES) that will fly on the Lunar Gateway and the PADRE Small Sat mission. SWxSOC has established an open-source, reusable solution for transitioning data management from on-premises to the cloud, processing data files, and setting up a cloud-based analysis environment to monitor instrument anomalies. Leveraging Amazon Web Services (AWS) and making open-source tools available on GitHub, HERMES exemplifies NASA's commitment to open-source standardization, showcasing the real-world effectiveness of cloud technology in data processing, analysis, and observability. This enhances current operations and ensures faster, standardized deployments for future missions.

hermes↗
NASA NTRS2006

Spitzer Space Telescope Sequencing Operations Software, Strategies, and Lessons Learned

The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.

missions operations↗
NASA NTRS2014

Evolution of Software-Only-Simulation at NASA IV and V

Software-Only-Simulations have been an emerging but quickly developing field of study throughout NASA. The NASA Independent Verification Validation (IVV) Independent Test Capability (ITC) team has been rapidly building a collection of simulators for a wide range of NASA missions. ITC specializes in full end-to-end simulations that enable developers, VV personnel, and operators to test-as-you-fly. In four years, the team has delivered a wide variety of spacecraft simulations that have ranged from low complexity science missions such as the Global Precipitation Management (GPM) satellite and the Deep Space Climate Observatory (DSCOVR), to the extremely complex missions such as the James Webb Space Telescope (JWST) and Space Launch System (SLS).This paper describes the evolution of ITCs technologies and processes that have been utilized to design, implement, and deploy end-to-end simulation environments for various NASA missions. A comparison of mission simulators are discussed with focus on technology and lessons learned in complexity, hardware modeling, and continuous integration. The paper also describes the methods for executing the missions unmodified flight software binaries (not cross-compiled) for verification and validation activities.

Embedded↗
NASA NTRS1997

Managing Satellites

Integral Systems, Inc.'s EPOCH 2000 forms the core of NASA's Near Earth Asteroid Rendezvous (NEAR) mission's command and control center. EPOCH 2000, which allows ground operators to monitor and control satellites over a wide area network, owes part of its heritage from work completed to support Goddard Space Flight Center. The software automates telemetry processing, commanding, anomaly detection, and archiving collected data. The NEAR spacecraft, launched in February 1996, will rendezvous in early 1999 and orbit the Asteroid Eros for a year. Integral Systems also provided Low Earth Orbit Autonomous Ground Terminals (LEO-Ts) to NASA. The LEO-T is designed to make it easier and less expensive for principal investigators to obtain telemetry, tracking and control services for their science missions. The company products have supported well over 70 satellite missions aimed at scientific research, meteorology, or communications applications.

Source record↗
NASA NTRS2004

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗
NASA NTRS2006

Flight-Tested Prototype of BEAM Software

Researchers at JPL have completed a software prototype of BEAM (Beacon-based Exception Analysis for Multi-missions) and successfully tested its operation in flight onboard a NASA research aircraft. BEAM (see NASA Tech Briefs, Vol. 26, No. 9; and Vol. 27, No. 3) is an ISHM (Integrated Systems Health Management) technology that automatically analyzes sensor data and classifies system behavior as either nominal or anomalous, and further characterizes anomalies according to strength, duration, and affected signals. BEAM (see figure) can be used to monitor a wide variety of physical systems and sensor types in real time. In this series of tests, BEAM monitored the engines of a Dryden Flight Research Center F-18 aircraft, and performed onboard, unattended analysis of 26 engine sensors from engine startup to shutdown. The BEAM algorithm can detect anomalies based solely on the sensor data, which includes but is not limited to sensor failure, performance degradation, incorrect operation such as unplanned engine shutdown or flameout in this example, and major system faults. BEAM was tested on an F-18 simulator, static engine tests, and 25 individual flights totaling approximately 60 hours of flight time. During these tests, BEAM successfully identified planned anomalies (in-flight shutdowns of one engine) as well as minor unplanned anomalies (e.g., transient oil- and fuel-pressure drops), with no false alarms or suspected false-negative results for the period tested. BEAM also detected previously unknown behavior in the F- 18 compressor section during several flights. This result, confirmed by direct analysis of the raw data, serves as a significant test of BEAM's capability.

Mackey, Ryan↗
NASA NTRS2009

Dshell++: A Component Based, Reusable Space System Simulation Framework

This paper describes the multi-mission Dshell++ simulation framework for high fidelity, physics-based simulation of spacecraft, robotic manipulation and mobility systems. Dshell++ is a C++/Python library which uses modern script driven object-oriented techniques to allow component reuse and a dynamic run-time interface for complex, high-fidelity simulation of spacecraft and robotic systems. The goal of the Dshell++ architecture is to manage the inherent complexity of physicsbased simulations while supporting component model reuse across missions. The framework provides several features that support a large degree of simulation configurability and usability.

Software↗
NASA NTRS2015

Navigation Operations for the Magnetospheric Multiscale Mission

The Magnetospheric Multiscale (MMS) mission employs four identical spinning spacecraft flying in highly elliptical Earth orbits. These spacecraft will fly in a series of tetrahedral formations with separations of less than 10 km. MMS navigation operations use onboard navigation to satisfy the mission definitive orbit and time determination requirements and in addition to minimize operations cost and complexity. The onboard navigation subsystem consists of the Navigator GPS receiver with Goddard Enhanced Onboard Navigation System (GEONS) software, and an Ultra-Stable Oscillator. The four MMS spacecraft are operated from a single Mission Operations Center, which includes a Flight Dynamics Operations Area (FDOA) that supports MMS navigation operations, as well as maneuver planning, conjunction assessment and attitude ground operations. The System Manager component of the FDOA automates routine operations processes. The GEONS Ground Support System component of the FDOA provides the tools needed to support MMS navigation operations. This paper provides an overview of the MMS mission and associated navigation requirements and constraints and discusses MMS navigation operations and the associated MMS ground system components built to support navigation-related operations.

Navigation↗
NASA NTRS2018

High-Performance Spaceflight Computing (HPSC) Project Overview

The High Performance Spaceflight Computing (HPSC) multi-core processor Chiplet will provide a nearly two orders-of-magnitude improvement above the current state of the art for spaceflight processors, while also providing an unprecedented flexibility to tailor performance, power consumption, and fault tolerance to meet widely varying mission needs. These advancements will provide game changing improvements in computing performance, power efficiency, and flexibility, which will significantly improve the onboard processing capabilities of future NASA and Air Force space missions. HPSC is funded by NASA's Space Technology Mission Directorate (STMD), Science Mission Directorate (SMD), and the United States Air Force. The HPSC project is managed by Jet Propulsion Laboratory, and the HPSC contract is managed by NASA Goddard Space Flight Center (GSFC). Within the HPSC project, Boeing is under contract to NASA to develop prototype Chiplets, system software, and evaluation boards. As another development within the project, NASA Goddard Space Flight Center (GSFC) and the Jet Propulsion Laboratory (JPL) are developing middleware that will simplify application development for HPSC-based onboard processors.

multi-core processor↗
NASA NTRSDate not supplied

Crew Health and Performance Integrated Data System Platform Project Updates

Future human exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting crew autonomy for future exploration missions. An integrated data system platform is needed to mitigate these risks by supporting a new generation of technologies and employing advanced analytical and predictive modeling techniques to enable crew autonomy for future exploration missions. The Crew Health and Performance Integrated Data System Platform (CHP-IDSP) project is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. This cohesive integration point will streamline the management of CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.) and facilitate situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the ongoing development effort of the path-to-flight CHP-IDSP software and the demonstration of its core capabilities. This includes a brief history of the project, the human-centered process used to identify data needs and workflows feeding the development of scenarios and requirements, and current subsystem development status. Current integrations, including the Chiron exploration electronic health record application, will be discussed. Future work includes collaboration with additional CHP domains and a flight technology demonstration.

Data integration↗